आगे का दूसरा रास्ता

सितंबर 2001

(यह लेख बताता है कि अगली पीढ़ी के अधिकांश सॉफ्टवेयर सर्वर-आधारित क्यों हो सकते हैं, प्रोग्रामर्स के लिए इसका क्या मतलब होगा, और यह नया सॉफ्टवेयर स्टार्टअप्स के लिए एक बेहतरीन अवसर क्यों है। यह लेख BBN लैब्स में दिए गए एक व्याख्यान से लिया गया है।)

1995 की गर्मियों में, मेरे दोस्त रॉबर्ट मॉरिस और मैंने एक स्टार्टअप शुरू करने का फैसला किया। नेटस्केप के आईपीओ से पहले पीआर अभियान उस समय जोरों पर चल रहा था, और प्रेस में ऑनलाइन कॉमर्स के बारे में बहुत चर्चा हो रही थी। उस समय वेब पर शायद तीस वास्तविक स्टोर थे, जो सभी हाथ से बनाए गए थे। अगर बहुत सारे ऑनलाइन स्टोर होने वाले थे, तो उन्हें बनाने के लिए सॉफ़्टवेयर की आवश्यकता होगी, इसलिए हमने कुछ लिखने का फैसला किया।

पहले हफ़्ते तक हम इसे एक साधारण डेस्कटॉप एप्लीकेशन बनाने का इरादा रखते थे। फिर एक दिन हमारे मन में यह विचार आया कि ब्राउज़र को इंटरफ़ेस के रूप में इस्तेमाल करते हुए, सॉफ़्टवेयर को हमारे वेब सर्वर पर चलाया जाए। हमने वेब पर काम करने के लिए सॉफ़्टवेयर को फिर से लिखने की कोशिश की, और यह स्पष्ट था कि यही तरीका था। अगर हम अपने सॉफ़्टवेयर को सर्वर पर चलाने के लिए लिखते हैं, तो यह उपयोगकर्ताओं और हमारे लिए भी बहुत आसान होगा।

यह एक अच्छी योजना साबित हुई। अब, याहू स्टोर के रूप में, यह सॉफ्टवेयर सबसे लोकप्रिय ऑनलाइन स्टोर बिल्डर है, जिसके लगभग 14,000 उपयोगकर्ता हैं।

जब हमने वायावेब की शुरुआत की थी, तो शायद ही कोई समझ पाया कि जब हमने कहा कि सॉफ्टवेयर सर्वर पर चलता है तो हमारा क्या मतलब था। एक साल बाद जब हॉटमेल लॉन्च हुआ, तब लोगों को यह समझ में आया। अब हर कोई जानता है कि यह एक वैध दृष्टिकोण है। अब हम जो थे, उसका एक नाम है: एप्लीकेशन सर्विस प्रोवाइडर, या ASP।

मुझे लगता है कि अगली पीढ़ी के बहुत से सॉफ़्टवेयर इसी मॉडल पर लिखे जाएँगे। यहाँ तक कि Microsoft, जिसके पास खोने के लिए सबसे ज़्यादा है, कुछ चीज़ों को डेस्कटॉप से हटाने की अनिवार्यता को देखता है। अगर सॉफ़्टवेयर डेस्कटॉप से हटकर सर्वर पर चला जाता है, तो इसका मतलब डेवलपर्स के लिए एक बहुत ही अलग दुनिया होगी। यह लेख उन आश्चर्यजनक चीज़ों का वर्णन करता है जो हमने इस नई दुनिया के कुछ पहले आगंतुकों के रूप में देखीं। जिस हद तक सॉफ़्टवेयर सर्वर पर जाता है, मैं यहाँ जो वर्णन कर रहा हूँ वह भविष्य है।

अगली वस्तु?

जब हम डेस्कटॉप सॉफ्टवेयर के युग को देखते हैं, तो मुझे लगता है कि हम उन असुविधाओं पर आश्चर्यचकित होंगे जो लोगों को सहन करनी पड़ती थीं, ठीक वैसे ही जैसे हम आज आश्चर्यचकित हैं कि शुरुआती कार मालिकों को क्या सहन करना पड़ता था। पहले बीस या तीस सालों तक, कार के मालिक होने के लिए आपको कार विशेषज्ञ होना पड़ता था। लेकिन कारें इतनी बड़ी जीत थीं कि बहुत से लोग जो कार विशेषज्ञ नहीं थे, वे भी उन्हें खरीदना चाहते थे।

कंप्यूटर अब इस चरण में हैं। जब आपके पास डेस्कटॉप कंप्यूटर होता है, तो आप इसके अंदर क्या हो रहा है, इसके बारे में जितना जानना चाहते थे, उससे कहीं ज़्यादा सीख जाते हैं। लेकिन अमेरिका में आधे से ज़्यादा घरों में एक ही कंप्यूटर है। मेरी माँ के पास एक कंप्यूटर है जिसका इस्तेमाल वह ईमेल और अकाउंट रखने के लिए करती हैं। लगभग एक साल पहले उन्हें Apple से एक पत्र मिला, जिसमें उन्हें ऑपरेटिंग सिस्टम के नए संस्करण पर छूट की पेशकश की गई थी। जब एक पैंसठ वर्षीय महिला जो ईमेल और अकाउंट के लिए कंप्यूटर का उपयोग करना चाहती है, उसे नए ऑपरेटिंग सिस्टम इंस्टॉल करने के बारे में सोचना पड़ता है, तो कुछ गड़बड़ है। आम उपयोगकर्ताओं को "ऑपरेटिंग सिस्टम" शब्द भी नहीं पता होना चाहिए, "डिवाइस ड्राइवर" या "पैच" तो दूर की बात है।

अब सॉफ्टवेयर डिलीवर करने का एक और तरीका है जो उपयोगकर्ताओं को सिस्टम एडमिनिस्ट्रेटर बनने से बचाएगा। वेब-आधारित अनुप्रयोग ऐसे प्रोग्राम हैं जो वेब सर्वर पर चलते हैं और वेब पेजों को यूजर इंटरफेस के रूप में उपयोग करते हैं। औसत उपयोगकर्ता के लिए यह नया प्रकार का सॉफ्टवेयर डेस्कटॉप सॉफ्टवेयर की तुलना में अधिक आसान, सस्ता, अधिक मोबाइल, अधिक विश्वसनीय और अक्सर अधिक शक्तिशाली होगा।

वेब-आधारित सॉफ़्टवेयर के साथ, अधिकांश उपयोगकर्ताओं को उनके द्वारा उपयोग किए जाने वाले एप्लिकेशन के अलावा किसी और चीज़ के बारे में सोचना नहीं पड़ेगा। सभी अव्यवस्थित, बदलती हुई चीज़ें कहीं न कहीं सर्वर पर बैठी होंगी, जिन्हें ऐसे लोगों द्वारा बनाए रखा जाएगा जो उस तरह की चीज़ों में अच्छे हैं। और इसलिए आपको सॉफ़्टवेयर का उपयोग करने के लिए आमतौर पर कंप्यूटर की ज़रूरत नहीं होगी। आपको बस कीबोर्ड, स्क्रीन और वेब ब्राउज़र वाली किसी चीज़ की ज़रूरत होगी। शायद इसमें वायरलेस इंटरनेट एक्सेस होगा। शायद यह आपका सेल फ़ोन भी हो। जो भी हो, यह उपभोक्ता इलेक्ट्रॉनिक्स होगा: कुछ ऐसा जिसकी कीमत लगभग 200 डॉलर होगी, और जिसे लोग ज़्यादातर केस के दिखने के आधार पर चुनते हैं। आप हार्डवेयर की तुलना में इंटरनेट सेवाओं के लिए ज़्यादा भुगतान करेंगे, ठीक वैसे ही जैसे आप अभी टेलीफ़ोन के लिए करते हैं। [1]

सर्वर पर जाने और वापस आने में क्लिक करने में लगभग दसवां सेकंड लगेगा, इसलिए फ़ोटोशॉप जैसे अत्यधिक इंटरैक्टिव सॉफ़्टवेयर के उपयोगकर्ता अभी भी डेस्कटॉप पर गणनाएँ करना चाहेंगे। लेकिन अगर आप देखें कि ज़्यादातर लोग किस तरह के कामों के लिए कंप्यूटर का इस्तेमाल करते हैं, तो दसवां सेकंड की देरी कोई समस्या नहीं होगी। मेरी माँ को वास्तव में डेस्कटॉप कंप्यूटर की ज़रूरत नहीं है, और उनके जैसे बहुत से लोग हैं।

उपयोगकर्ताओं के लिए जीत

मेरे घर के पास एक कार है जिसके बम्पर पर "असुविधा से पहले मौत" लिखा हुआ है। ज़्यादातर लोग, ज़्यादातर समय, वही विकल्प चुनते हैं जिसमें कम से कम मेहनत लगे। अगर वेब-आधारित सॉफ़्टवेयर जीतता है, तो ऐसा इसलिए होगा क्योंकि यह ज़्यादा सुविधाजनक है। और ऐसा लगता है कि यह उपयोगकर्ताओं और डेवलपर्स दोनों के लिए ही होगा।

पूरी तरह से वेब-आधारित एप्लिकेशन का उपयोग करने के लिए, आपको बस इंटरनेट से जुड़ा एक ब्राउज़र चाहिए। इसलिए आप कहीं भी वेब-आधारित एप्लिकेशन का उपयोग कर सकते हैं। जब आप अपने डेस्कटॉप कंप्यूटर पर सॉफ़्टवेयर इंस्टॉल करते हैं, तो आप इसे केवल उसी कंप्यूटर पर उपयोग कर सकते हैं। इससे भी बदतर, आपकी फ़ाइलें उस कंप्यूटर पर फंस जाती हैं। जैसे-जैसे लोग नेटवर्क के आदी होते जाते हैं, इस मॉडल की असुविधाएँ और अधिक स्पष्ट होती जाती हैं।

यहाँ कील का पतला सिरा वेब-आधारित ईमेल था। लाखों लोग अब महसूस करते हैं कि आपको ईमेल संदेशों तक पहुँच होनी चाहिए, चाहे आप कहीं भी हों। और अगर आप अपना ईमेल देख सकते हैं, तो अपना कैलेंडर क्यों नहीं? अगर आप अपने सहकर्मियों के साथ किसी दस्तावेज़ पर चर्चा कर सकते हैं, तो आप उसे संपादित क्यों नहीं कर सकते? आपका कोई भी डेटा किसी दूर डेस्क पर बैठे कंप्यूटर पर क्यों फंसा होना चाहिए?

"आपके कंप्यूटर" का पूरा विचार खत्म हो रहा है, और उसकी जगह "आपका डेटा" आ रहा है। आपको किसी भी कंप्यूटर से अपना डेटा प्राप्त करने में सक्षम होना चाहिए। या यूँ कहें कि किसी भी क्लाइंट से, और क्लाइंट का कंप्यूटर होना ज़रूरी नहीं है।

क्लाइंट को डेटा स्टोर नहीं करना चाहिए; उन्हें टेलीफोन की तरह होना चाहिए। वास्तव में वे टेलीफोन बन सकते हैं, या इसके विपरीत। और जैसे-जैसे क्लाइंट छोटे होते जाते हैं, आपके पास अपना डेटा उन पर न रखने का एक और कारण होता है: आपके साथ जो कुछ भी होता है वह खो सकता है या चोरी हो सकता है। अपने पीडीए को टैक्सी में छोड़ना डिस्क क्रैश की तरह है, सिवाय इसके कि आपका डेटा वाष्पीकृत होने के बजाय किसी और को सौंप दिया जाता है।

पूरी तरह से वेब-आधारित सॉफ़्टवेयर के साथ, न तो आपका डेटा और न ही एप्लिकेशन क्लाइंट पर रखे जाते हैं। इसलिए आपको इसका उपयोग करने के लिए कुछ भी इंस्टॉल करने की आवश्यकता नहीं है। और जब कोई इंस्टॉलेशन नहीं होता है, तो आपको इंस्टॉलेशन के गलत होने की चिंता करने की ज़रूरत नहीं होती है। एप्लिकेशन और आपके ऑपरेटिंग सिस्टम के बीच असंगतता नहीं हो सकती है, क्योंकि सॉफ़्टवेयर आपके ऑपरेटिंग सिस्टम पर नहीं चलता है।

क्योंकि इसे किसी इंस्टॉलेशन की आवश्यकता नहीं है, इसलिए इसे "खरीदने" से पहले वेब-आधारित सॉफ़्टवेयर को आज़माना आसान और आम बात होगी। आपको किसी भी वेब-आधारित एप्लिकेशन को मुफ़्त में टेस्ट-ड्राइव करने में सक्षम होने की उम्मीद करनी चाहिए, बस उस साइट पर जाकर जहाँ यह ऑफ़र किया गया है। वायावेब पर हमारी पूरी साइट उपयोगकर्ताओं को टेस्ट ड्राइव की ओर इशारा करते हुए एक बड़े तीर की तरह थी।

डेमो आज़माने के बाद, सेवा के लिए साइन अप करने के लिए सिर्फ़ एक संक्षिप्त फ़ॉर्म भरना होगा (जितना संक्षिप्त होगा उतना बेहतर होगा)। और यह आखिरी काम होना चाहिए जो उपयोगकर्ता को करना होगा। वेब-आधारित सॉफ़्टवेयर के साथ, आपको अतिरिक्त भुगतान किए बिना, या कोई काम किए बिना, या संभवतः इसके बारे में जाने बिना भी नई रिलीज़ मिलनी चाहिए।

अपग्रेड अब उतने बड़े झटके नहीं होंगे जितने कि अब हैं। समय के साथ-साथ एप्लिकेशन चुपचाप अधिक शक्तिशाली होते जाएंगे। इसके लिए डेवलपर्स की ओर से कुछ प्रयास करने होंगे। उन्हें सॉफ्टवेयर को इस तरह से डिजाइन करना होगा कि इसे उपयोगकर्ताओं को भ्रमित किए बिना अपडेट किया जा सके। यह एक नई समस्या है, लेकिन इसे हल करने के तरीके हैं।

वेब-आधारित अनुप्रयोगों के साथ, हर कोई एक ही संस्करण का उपयोग करता है, और बग का पता चलते ही उन्हें ठीक किया जा सकता है। इसलिए वेब-आधारित सॉफ़्टवेयर में डेस्कटॉप सॉफ़्टवेयर की तुलना में बहुत कम बग होने चाहिए। वायावेब में, मुझे संदेह है कि हमारे पास कभी भी किसी भी समय दस ज्ञात बग थे। यह डेस्कटॉप सॉफ़्टवेयर की तुलना में कई गुना बेहतर है।

वेब-आधारित अनुप्रयोगों का उपयोग कई लोग एक ही समय में कर सकते हैं। यह सहयोगी अनुप्रयोगों के लिए एक स्पष्ट जीत है, लेकिन मुझे यकीन है कि उपयोगकर्ता इसे अधिकांश अनुप्रयोगों में तब चाहते हैं जब उन्हें पता चलेगा कि यह संभव है। उदाहरण के लिए, दो लोगों को एक ही दस्तावेज़ को संपादित करने देना अक्सर उपयोगी होगा। Viaweb ने कई उपयोगकर्ताओं को एक साथ एक साइट को संपादित करने दिया, अधिक इसलिए क्योंकि यह सॉफ़्टवेयर लिखने का सही तरीका था, न कि इसलिए कि हमने उपयोगकर्ताओं से ऐसा करने की अपेक्षा की थी, लेकिन यह पता चला कि कई लोगों ने ऐसा किया।

जब आप वेब-आधारित एप्लिकेशन का उपयोग करते हैं, तो आपका डेटा सुरक्षित रहेगा। डिस्क क्रैश अतीत की बात नहीं होगी, लेकिन उपयोगकर्ता अब उनके बारे में नहीं सुनेंगे। वे सर्वर फ़ार्म के भीतर होंगे। और वेब-आधारित एप्लिकेशन ऑफ़र करने वाली कंपनियाँ वास्तव में बैकअप लेंगी - न केवल इसलिए कि उनके पास ऐसी चीज़ों के बारे में चिंता करने वाले वास्तविक सिस्टम प्रशासक होंगे, बल्कि इसलिए भी कि एक ASP जो लोगों का डेटा खो देता है, वह बहुत बड़ी मुसीबत में पड़ जाएगा। जब लोग डिस्क क्रैश में अपना डेटा खो देते हैं, तो वे इतना गुस्सा नहीं कर सकते, क्योंकि उन्हें केवल खुद पर गुस्सा करना होता है। जब कोई कंपनी उनके लिए उनका डेटा खो देती है, तो वे बहुत ज़्यादा गुस्सा हो जाते हैं।

अंत में, वेब-आधारित सॉफ़्टवेयर को वायरस के प्रति कम संवेदनशील होना चाहिए। यदि क्लाइंट ब्राउज़र के अलावा कुछ भी नहीं चलाता है, तो वायरस चलने की संभावना कम होती है, और स्थानीय रूप से कोई डेटा क्षतिग्रस्त नहीं होता है। और एक प्रोग्राम जिसने सर्वर पर हमला किया है, उसे बहुत अच्छी तरह से बचाव किया जाना चाहिए। [2]

उपयोगकर्ताओं के लिए, वेब-आधारित सॉफ़्टवेयर कम तनावपूर्ण होगा। मुझे लगता है कि अगर आप औसत विंडोज उपयोगकर्ता के अंदर देखें तो आपको उस विवरण को पूरा करने वाले सॉफ़्टवेयर के लिए एक बड़ी और काफी अप्रयुक्त इच्छा मिलेगी। मुक्त होने पर, यह एक शक्तिशाली शक्ति हो सकती है।

कोड का शहर

डेवलपर्स के लिए, वेब-आधारित और डेस्कटॉप सॉफ़्टवेयर के बीच सबसे स्पष्ट अंतर यह है कि वेब-आधारित एप्लिकेशन कोड का एक टुकड़ा नहीं है। यह एक बड़ी बाइनरी के बजाय विभिन्न प्रकार के कार्यक्रमों का एक संग्रह होगा। और इसलिए वेब-आधारित सॉफ़्टवेयर डिज़ाइन करना एक इमारत के बजाय एक शहर को डिज़ाइन करने जैसा है: इमारतों के साथ-साथ आपको सड़कों, सड़क के संकेतों, उपयोगिताओं, पुलिस और अग्निशमन विभागों और विकास और विभिन्न प्रकार की आपदाओं दोनों के लिए योजनाओं की आवश्यकता होती है।

वायावेब में, सॉफ्टवेयर में काफी बड़े अनुप्रयोग शामिल थे जिनसे उपयोगकर्ता सीधे बात करते थे, वे प्रोग्राम जिनका उपयोग वे प्रोग्राम करते थे, वे प्रोग्राम जो समस्याओं की तलाश में लगातार पृष्ठभूमि में चलते थे, वे प्रोग्राम जो चीजों के खराब होने पर उन्हें पुनः आरंभ करने का प्रयास करते थे, वे प्रोग्राम जो सांख्यिकी संकलित करने या खोजों के लिए अनुक्रमणिका बनाने के लिए कभी-कभी चलते थे, वे प्रोग्राम जिन्हें हम कचरा-संग्रह संसाधनों या डेटा को स्थानांतरित या पुनर्स्थापित करने के लिए स्पष्ट रूप से चलाते थे, वे प्रोग्राम जो उपयोगकर्ता होने का दिखावा करते थे (प्रदर्शन को मापने या बग को उजागर करने के लिए), नेटवर्क समस्याओं के निदान के लिए प्रोग्राम, बैकअप करने के लिए प्रोग्राम, बाहरी सेवाओं के लिए इंटरफेस, सॉफ्टवेयर जो वास्तविक समय सर्वर सांख्यिकी (आगंतुकों के साथ हिट, लेकिन हमारे लिए भी अपरिहार्य) प्रदर्शित करने वाले डायल का एक प्रभावशाली संग्रह चलाते थे, ओपन-सोर्स सॉफ्टवेयर में संशोधन (बग फिक्स सहित), और बहुत सारी कॉन्फ़िगरेशन फ़ाइलें और सेटिंग्स। ट्रेवर ब्लैकवेल ने याहू द्वारा खरीदे जाने के बाद, उन्हें बंद किए बिना, देश भर में स्टोर्स को नए सर्वर पर ले जाने के लिए एक शानदार प्रोग्राम लिखा। प्रोग्राम हमें पेज करते थे, उपयोगकर्ताओं को फैक्स और ईमेल भेजते थे, क्रेडिट कार्ड प्रोसेसर के साथ लेन-देन करते थे, और सॉकेट, पाइप, http अनुरोध, ssh, udp पैकेट, साझा मेमोरी और फ़ाइलों के माध्यम से एक दूसरे से बात करते थे। वायावेब में से कुछ में प्रोग्राम की अनुपस्थिति भी शामिल थी, क्योंकि यूनिक्स सुरक्षा की कुंजी में से एक अनावश्यक उपयोगिताओं को नहीं चलाना है जिसका उपयोग लोग आपके सर्वर में सेंध लगाने के लिए कर सकते हैं।

यह सॉफ्टवेयर तक ही सीमित नहीं था। हमने सर्वर कॉन्फ़िगरेशन के बारे में सोचने में बहुत समय बिताया। हमने सर्वर को खुद ही बनाया, घटकों से - आंशिक रूप से पैसे बचाने के लिए, और आंशिक रूप से वही पाने के लिए जो हम चाहते थे। हमें इस बारे में सोचना था कि क्या हमारे अपस्ट्रीम ISP के पास सभी बैकबोन के लिए पर्याप्त तेज़ कनेक्शन हैं। हमने RAID आपूर्तिकर्ताओं को क्रमिक रूप से दिनांकित किया ।

लेकिन हार्डवेयर सिर्फ़ चिंता की बात नहीं है। जब आप इसे नियंत्रित करते हैं तो आप उपयोगकर्ताओं के लिए ज़्यादा कर सकते हैं। डेस्कटॉप एप्लिकेशन के साथ, आप कुछ न्यूनतम हार्डवेयर निर्दिष्ट कर सकते हैं, लेकिन आप और नहीं जोड़ सकते। यदि आप सर्वर का प्रबंधन करते हैं, तो आप एक ही चरण में अपने सभी उपयोगकर्ताओं को लोगों को पेज करने, या फ़ैक्स भेजने, या फ़ोन द्वारा आदेश भेजने, या क्रेडिट कार्ड प्रोसेस करने आदि में सक्षम कर सकते हैं, बस संबंधित हार्डवेयर इंस्टॉल करके। हम हमेशा हार्डवेयर के साथ सुविधाएँ जोड़ने के नए तरीके खोजते रहते हैं, सिर्फ़ इसलिए नहीं कि इससे उपयोगकर्ता खुश होते हैं, बल्कि खुद को उन प्रतिस्पर्धियों से अलग करने के तरीके के रूप में भी, जिनका (या तो डेस्कटॉप सॉफ़्टवेयर बेचने या ISP के माध्यम से वेब-आधारित एप्लिकेशन को फिर से बेचने के कारण) हार्डवेयर पर सीधा नियंत्रण नहीं था।

क्योंकि वेब-आधारित एप्लिकेशन में सॉफ़्टवेयर एकल बाइनरी के बजाय प्रोग्रामों का एक संग्रह होगा, इसलिए इसे किसी भी संख्या में विभिन्न भाषाओं में लिखा जा सकता है। जब आप डेस्कटॉप सॉफ़्टवेयर लिख रहे होते हैं, तो आपको व्यावहारिक रूप से अंतर्निहित ऑपरेटिंग सिस्टम की भाषा में ही एप्लिकेशन लिखने के लिए बाध्य किया जाता है - जिसका अर्थ है C और C++। और इसलिए इन भाषाओं (विशेष रूप से प्रबंधकों और वीसी जैसे गैर-तकनीकी लोगों के बीच) को "गंभीर" सॉफ़्टवेयर विकास के लिए भाषाओं के रूप में माना जाता है। लेकिन यह डेस्कटॉप सॉफ़्टवेयर को वितरित करने के तरीके का एक आर्टिफैक्ट था। सर्वर-आधारित सॉफ़्टवेयर के लिए आप अपनी इच्छानुसार किसी भी भाषा का उपयोग कर सकते हैं। [3] आज बहुत से शीर्ष हैकर C और C++ से बहुत दूर की भाषाओं का उपयोग कर रहे हैं: पर्ल, पायथन और यहां तक कि लिस्प भी।

सर्वर-आधारित सॉफ़्टवेयर के साथ, कोई भी आपको यह नहीं बता सकता कि आपको कौन सी भाषा का उपयोग करना है, क्योंकि आप पूरे सिस्टम को नियंत्रित करते हैं, हार्डवेयर तक। अलग-अलग कार्यों के लिए अलग-अलग भाषाएँ अच्छी होती हैं। आप प्रत्येक के लिए जो सबसे अच्छा हो उसका उपयोग कर सकते हैं। और जब आपके पास प्रतिस्पर्धी होते हैं, तो "आप कर सकते हैं" का अर्थ है "आपको अवश्य करना चाहिए" (हम बाद में इस पर वापस आएंगे), क्योंकि यदि आप इस संभावना का लाभ नहीं उठाते हैं, तो आपके प्रतिस्पर्धी इसका लाभ उठाएँगे।

हमारे अधिकांश प्रतिस्पर्धियों ने C और C++ का उपयोग किया, और इससे उनका सॉफ़्टवेयर स्पष्ट रूप से घटिया हो गया क्योंकि (अन्य बातों के अलावा), उनके पास CGI स्क्रिप्ट की स्टेटलेसनेस से बचने का कोई तरीका नहीं था। यदि आप कुछ बदलने जा रहे थे, तो सभी परिवर्तन एक पृष्ठ पर होने चाहिए, जिसके नीचे एक अपडेट बटन होना चाहिए। जैसा कि मैंने कहीं और लिखा है, लिस्प का उपयोग करके, जिसे कई लोग अभी भी एक शोध भाषा मानते हैं, हम वायावेब संपादक को डेस्कटॉप सॉफ़्टवेयर की तरह व्यवहार करने में सक्षम बना सकते हैं।

विज्ञप्ति

इस नई दुनिया में सबसे महत्वपूर्ण बदलावों में से एक है रिलीज़ करने का तरीका। डेस्कटॉप सॉफ़्टवेयर व्यवसाय में, रिलीज़ करना एक बहुत बड़ा आघात है, जिसमें पूरी कंपनी कोड के एक बड़े टुकड़े को आगे बढ़ाने के लिए पसीना बहाती है और तनाव में रहती है। प्रक्रिया और परिणामी उत्पाद दोनों के लिए स्पष्ट तुलनाएँ खुद ही सुझाती हैं।

सर्वर-आधारित सॉफ़्टवेयर के साथ, आप लगभग वैसे ही बदलाव कर सकते हैं जैसे आप अपने लिए लिखे गए प्रोग्राम में करते हैं। आप सॉफ़्टवेयर को कभी-कभार बड़े विस्फोट के बजाय वृद्धिशील परिवर्तनों की एक श्रृंखला के रूप में रिलीज़ करते हैं। एक सामान्य डेस्कटॉप सॉफ़्टवेयर कंपनी साल में एक या दो रिलीज़ कर सकती है। वायावेब में हम अक्सर एक दिन में तीन से पांच रिलीज़ करते थे।

जब आप इस नए मॉडल पर स्विच करते हैं, तो आपको पता चलता है कि सॉफ़्टवेयर विकास किस तरह से रिलीज़ होता है, उससे कितना प्रभावित होता है। डेस्कटॉप सॉफ़्टवेयर व्यवसाय में आप जो सबसे खराब समस्याएँ देखते हैं, वे रिलीज़ की भयावह प्रकृति के कारण होती हैं।

जब आप साल में सिर्फ़ एक नया वर्शन रिलीज़ करते हैं, तो आपको बग्स से पूरी तरह निपटना पड़ता है। रिलीज़ की तारीख से कुछ समय पहले आप एक नया वर्शन बनाते हैं जिसमें आधे कोड को फाड़कर बदल दिया जाता है, जिससे अनगिनत बग्स आ जाते हैं। फिर QA के लोगों का एक दल आगे आता है और उन्हें गिनना शुरू कर देता है, और प्रोग्रामर सूची में नीचे की ओर काम करते हैं, उन्हें ठीक करते हैं। वे आम तौर पर सूची के अंत तक नहीं पहुँच पाते हैं, और वास्तव में, कोई भी निश्चित नहीं है कि अंत कहाँ है। यह तालाब से मलबा निकालने जैसा है। आप कभी नहीं जान पाते कि सॉफ़्टवेयर के अंदर क्या हो रहा है। सबसे अच्छी स्थिति में आप एक सांख्यिकीय प्रकार की शुद्धता के साथ समाप्त होते हैं।

सर्वर-आधारित सॉफ़्टवेयर के साथ, ज़्यादातर बदलाव छोटे और वृद्धिशील होते हैं। इससे बग आने की संभावना कम होती है। इसका यह भी मतलब है कि जब आप सॉफ़्टवेयर रिलीज़ करने वाले होते हैं, तो आपको पता होता है कि आपको सबसे ज़्यादा सावधानी से किस चीज़ का परीक्षण करना है: आखिरी चीज़ जिसे आपने बदला है। आप कोड पर ज़्यादा मज़बूत पकड़ बना लेते हैं। एक सामान्य नियम के रूप में, आपको पता होता है कि इसके अंदर क्या हो रहा है। बेशक, आपको सोर्स कोड याद नहीं रहता, लेकिन जब आप सोर्स पढ़ते हैं तो आप इसे एक पायलट की तरह करते हैं जो इंस्ट्रूमेंट पैनल को स्कैन करता है, न कि किसी रहस्य को सुलझाने की कोशिश करने वाले जासूस की तरह।

डेस्कटॉप सॉफ्टवेयर बग के बारे में एक निश्चित भाग्यवाद को जन्म देता है। आप जानते हैं कि आप बग से भरी कोई चीज़ शिप कर रहे हैं, और आपने इसकी भरपाई के लिए तंत्र भी स्थापित कर लिया है (जैसे पैच रिलीज़)। तो कुछ और के बारे में क्यों चिंता करें? जल्द ही आप पूरी सुविधाएँ जारी कर रहे हैं जिनके बारे में आपको पता है कि वे टूटी हुई हैं। Apple ने इस साल की शुरुआत में ऐसा किया था। उन्हें अपने नए OS को रिलीज़ करने का दबाव महसूस हुआ, जिसकी रिलीज़ की तारीख पहले ही चार बार खिसक चुकी थी, लेकिन कुछ सॉफ़्टवेयर (CD और DVD के लिए सपोर्ट) तैयार नहीं थे। समाधान? उन्होंने अधूरे हिस्सों के बिना OS जारी किया, और उपयोगकर्ताओं को उन्हें बाद में इंस्टॉल करना होगा।

वेब-आधारित सॉफ्टवेयर के साथ, आपको सॉफ्टवेयर के काम करने से पहले उसे जारी नहीं करना पड़ता है, तथा जैसे ही वह काम करना शुरू करता है, आप उसे जारी कर सकते हैं।

उद्योग के अनुभवी लोग सोच रहे होंगे कि यह कहना तो ठीक है कि आपको सॉफ़्टवेयर के काम करने से पहले उसे रिलीज़ नहीं करना है, लेकिन तब क्या होगा जब आप किसी निश्चित तिथि तक अपने सॉफ़्टवेयर का नया संस्करण देने का वादा करते हैं? वेब-आधारित सॉफ़्टवेयर के साथ, आप ऐसा वादा नहीं करेंगे, क्योंकि कोई संस्करण नहीं है। आपका सॉफ़्टवेयर धीरे-धीरे और लगातार बदलता रहता है। कुछ बदलाव दूसरों की तुलना में बड़े हो सकते हैं, लेकिन संस्करणों का विचार स्वाभाविक रूप से वेब-आधारित सॉफ़्टवेयर पर फिट नहीं बैठता।

अगर किसी को वायावेब याद है तो यह अजीब लग सकता है, क्योंकि हम हमेशा नए संस्करणों की घोषणा करते रहते थे। यह पूरी तरह से पीआर उद्देश्यों के लिए किया गया था। हमने सीखा कि व्यापार प्रेस संस्करण संख्याओं के बारे में सोचता है। वे आपको एक प्रमुख रिलीज़ के लिए प्रमुख कवरेज देंगे, जिसका अर्थ है संस्करण संख्या पर एक नया पहला अंक, और आम तौर पर एक बिंदु रिलीज़ के लिए अधिकतम एक पैराग्राफ, जिसका अर्थ है दशमलव बिंदु के बाद एक नया अंक।

हमारे कुछ प्रतिस्पर्धी डेस्कटॉप सॉफ़्टवेयर ऑफ़र कर रहे थे और वास्तव में उनके पास संस्करण संख्याएँ थीं। और इन रिलीज़ के लिए, जिनके मात्र तथ्य से हमें उनके पिछड़ेपन का प्रमाण लगता था, उन्हें हर तरह का प्रचार मिलता था। हम चूकना नहीं चाहते थे, इसलिए हमने अपने सॉफ़्टवेयर को भी संस्करण संख्याएँ देना शुरू कर दिया। जब हमें कुछ प्रचार चाहिए होता था, तो हम पिछली "रिलीज़" के बाद से जोड़े गए सभी फ़ीचर की एक सूची बनाते थे, सॉफ़्टवेयर पर एक नया संस्करण नंबर चिपकाते थे, और एक प्रेस विज्ञप्ति जारी करते थे जिसमें कहा जाता था कि नया संस्करण तुरंत उपलब्ध है। आश्चर्यजनक रूप से, किसी ने भी हमें इसके बारे में कभी नहीं बताया।

जब हमें खरीदा गया, तब तक हम ऐसा तीन बार कर चुके थे, इसलिए हम संस्करण 4 पर थे। अगर मुझे सही से याद है तो संस्करण 4.1। वायावेब के याहू स्टोर बनने के बाद, प्रचार की इतनी ज़रूरत नहीं रह गई थी, इसलिए हालाँकि सॉफ़्टवेयर का विकास जारी रहा, लेकिन संस्करण संख्याओं का पूरा विचार चुपचाप छोड़ दिया गया।

कीड़े

वेब-आधारित सॉफ़्टवेयर का दूसरा प्रमुख तकनीकी लाभ यह है कि आप अधिकांश बग को पुन: पेश कर सकते हैं। आपके पास उपयोगकर्ताओं का डेटा आपकी डिस्क पर ही मौजूद है। यदि कोई आपके सॉफ़्टवेयर को तोड़ता है, तो आपको यह अनुमान लगाने की कोशिश नहीं करनी पड़ती कि क्या हो रहा है, जैसा कि आप डेस्कटॉप सॉफ़्टवेयर के साथ करते हैं: आपको उस त्रुटि को पुन: पेश करने में सक्षम होना चाहिए, जबकि वे आपके साथ फ़ोन पर हैं। यदि आपके पास अपने एप्लिकेशन में त्रुटियों को नोटिस करने के लिए कोड है, तो आप इसके बारे में पहले से ही जानते होंगे।

वेब-आधारित सॉफ्टवेयर का उपयोग चौबीसों घंटे किया जाता है, इसलिए आप जो भी करते हैं, उसे तुरंत जांचा जाता है। बग्स जल्दी ही सामने आ जाते हैं।

सॉफ़्टवेयर कंपनियों पर कभी-कभी उपयोगकर्ताओं को अपने सॉफ़्टवेयर को डीबग करने देने का आरोप लगाया जाता है। और यही मैं वकालत कर रहा हूँ। वेब-आधारित सॉफ़्टवेयर के लिए यह वास्तव में एक अच्छी योजना है, क्योंकि बग कम और क्षणिक होते हैं। जब आप सॉफ़्टवेयर को धीरे-धीरे रिलीज़ करते हैं तो आपको शुरू में बहुत कम बग मिलते हैं। और जब आप त्रुटियों को पुन: पेश कर सकते हैं और तुरंत परिवर्तन जारी कर सकते हैं, तो आप अधिकांश बग को तुरंत खोज सकते हैं और ठीक कर सकते हैं। हमारे पास कभी भी एक औपचारिक बग-ट्रैकिंग सिस्टम के लिए परेशान होने के लिए पर्याप्त बग नहीं थे।

आपको परिवर्तनों को रिलीज़ करने से पहले उनका परीक्षण करना चाहिए, ताकि कोई बड़ी बग रिलीज़ न हो। जो कुछ अनिवार्य रूप से छूट जाते हैं, वे सीमावर्ती मामलों को शामिल करेंगे और केवल उन कुछ उपयोगकर्ताओं को प्रभावित करेंगे जो किसी के शिकायत करने से पहले उनका सामना करते हैं। जब तक आप बग को तुरंत ठीक करते हैं, तब तक औसत उपयोगकर्ता के लिए शुद्ध प्रभाव बहुत कम बग होगा। मुझे संदेह है कि औसत Viaweb उपयोगकर्ता ने कभी बग देखा होगा।

नए बग को ठीक करना पुराने बग को ठीक करने से ज़्यादा आसान है। आपके द्वारा अभी-अभी लिखे गए कोड में बग ढूँढ़ना आम तौर पर काफ़ी तेज़ होता है। जब यह सामने आता है तो आप अक्सर स्रोत को देखने से पहले ही जान जाते हैं कि क्या गड़बड़ है, क्योंकि आप अवचेतन रूप से पहले से ही इसके बारे में चिंता कर रहे थे। छह महीने पहले लिखी गई किसी चीज़ में बग को ठीक करना (अगर आप साल में एक बार रिलीज़ करते हैं तो औसत मामला) बहुत ज़्यादा काम है। और चूँकि आप कोड को अच्छी तरह से नहीं समझते हैं, इसलिए आप इसे बदसूरत तरीके से ठीक करने या और भी बग पेश करने की अधिक संभावना रखते हैं। [4]

जब आप बग को जल्दी पकड़ लेते हैं, तो आपको कम मिश्रित बग भी मिलते हैं। मिश्रित बग दो अलग-अलग बग होते हैं जो परस्पर क्रिया करते हैं: आप नीचे जाते समय ठोकर खाते हैं, और जब आप रेलिंग की ओर बढ़ते हैं तो यह आपके हाथ में आ जाता है। सॉफ़्टवेयर में इस तरह के बग को ढूँढना सबसे कठिन होता है, और इसके सबसे बुरे परिणाम भी होते हैं। [5] पारंपरिक "सब कुछ तोड़ो और फिर बग को छान लो" दृष्टिकोण स्वाभाविक रूप से बहुत सारे मिश्रित बग उत्पन्न करता है। और सॉफ़्टवेयर जो छोटे-छोटे बदलावों की एक श्रृंखला में जारी किया जाता है, स्वाभाविक रूप से ऐसा नहीं करता है। फर्श को लगातार किसी भी ढीली वस्तु से साफ किया जाता है जो बाद में किसी चीज़ में फंस सकती है।

यदि आप फंक्शनल प्रोग्रामिंग नामक तकनीक का उपयोग करते हैं तो यह मददगार साबित होता है। फंक्शनल प्रोग्रामिंग का मतलब है साइड-इफेक्ट से बचना। यह कुछ ऐसा है जिसे आप कमर्शियल सॉफ़्टवेयर की तुलना में शोध पत्रों में अधिक देख सकते हैं, लेकिन वेब-आधारित अनुप्रयोगों के लिए यह वास्तव में उपयोगी साबित होता है। पूरे प्रोग्राम को पूरी तरह से फंक्शनल कोड के रूप में लिखना मुश्किल है, लेकिन आप इस तरह से काफी बड़े हिस्से लिख सकते हैं। यह आपके सॉफ़्टवेयर के उन हिस्सों को परीक्षण करना आसान बनाता है, क्योंकि उनकी कोई स्थिति नहीं होती है, और यह उस स्थिति में बहुत सुविधाजनक है जहाँ आप लगातार छोटे-छोटे संशोधन कर रहे हैं और उनका परीक्षण कर रहे हैं। मैंने वायावेब के संपादक का अधिकांश भाग इसी शैली में लिखा, और हमने अपनी स्क्रिप्टिंग भाषा, RTML को पूरी तरह से फंक्शनल भाषा बनाया।

डेस्कटॉप सॉफ्टवेयर व्यवसाय के लोगों को इसका श्रेय देना मुश्किल होगा, लेकिन वायावेब में बग लगभग एक खेल बन गए हैं। चूँकि अधिकांश रिलीज़ किए गए बग सीमावर्ती मामलों से संबंधित थे, इसलिए जिन उपयोगकर्ताओं ने उनका सामना किया, वे संभवतः उन्नत उपयोगकर्ता थे, जो सीमा को आगे बढ़ा रहे थे। उन्नत उपयोगकर्ता बग के बारे में अधिक क्षमाशील होते हैं, खासकर तब जब आपने उन्हें किसी ऐसे फीचर को जोड़ने के दौरान पेश किया हो जिसकी वे मांग कर रहे थे। वास्तव में, क्योंकि बग दुर्लभ थे और उन्हें देखने के लिए आपको परिष्कृत चीजें करनी पड़ती थीं, उन्नत उपयोगकर्ता अक्सर एक को पकड़ने में गर्व महसूस करते थे। वे क्रोध से अधिक विजय की भावना में समर्थन को कॉल करते थे, जैसे कि उन्होंने हमसे अंक अर्जित किए हों।

सहायता

जब आप त्रुटियों को पुन: पेश कर सकते हैं, तो यह ग्राहक सहायता के प्रति आपके दृष्टिकोण को बदल देता है। अधिकांश सॉफ़्टवेयर कंपनियों में, ग्राहकों को बेहतर महसूस कराने के लिए सहायता प्रदान की जाती है। वे या तो आपको किसी ज्ञात बग के बारे में कॉल कर रहे हैं, या वे बस कुछ गलत कर रहे हैं और आपको पता लगाना है कि क्या है। किसी भी मामले में आप उनसे बहुत कुछ नहीं सीख सकते हैं। और इसलिए आप सहायता कॉल को एक परेशानी के रूप में देखते हैं जिसे आप अपने डेवलपर्स से जितना संभव हो उतना अलग रखना चाहते हैं।

वायावेब में चीजें इस तरह से काम नहीं करती थीं। वायावेब में, सहायता निःशुल्क थी, क्योंकि हम ग्राहकों से सुनना चाहते थे। अगर किसी को कोई समस्या थी, तो हम इसके बारे में तुरंत जानना चाहते थे ताकि हम त्रुटि को फिर से बना सकें और उसका समाधान जारी कर सकें।

इसलिए वायावेब में डेवलपर्स हमेशा सपोर्ट के साथ निकट संपर्क में रहते थे। कस्टमर सपोर्ट वाले लोग प्रोग्रामर से लगभग तीस फीट की दूरी पर रहते थे, और जानते थे कि वे हमेशा किसी वास्तविक बग की रिपोर्ट के साथ किसी भी चीज़ को बाधित कर सकते हैं। हम किसी गंभीर बग को ठीक करने के लिए बोर्ड मीटिंग छोड़ देते थे।

सहायता के प्रति हमारे दृष्टिकोण ने सभी को खुश कर दिया। ग्राहक प्रसन्न थे। जरा कल्पना करें कि सहायता लाइन पर कॉल करना और किसी महत्वपूर्ण समाचार को लाने वाले व्यक्ति के रूप में व्यवहार किया जाना कैसा महसूस होगा। ग्राहक सहायता करने वाले लोगों को यह पसंद आया क्योंकि इसका मतलब था कि वे उपयोगकर्ताओं की मदद कर सकते थे, उन्हें स्क्रिप्ट पढ़ने के बजाय। और प्रोग्रामर को यह पसंद आया क्योंकि वे बग को पुन: पेश कर सकते थे, न कि उनके बारे में अस्पष्ट सेकंड-हैंड रिपोर्ट सुनने के बजाय।

बग को तुरंत ठीक करने की हमारी नीति ने ग्राहक सहायता कर्मियों और हैकर्स के बीच के रिश्ते को बदल दिया। अधिकांश सॉफ्टवेयर कंपनियों में, सहायता कर्मियों को कम वेतन वाले मानव ढाल के रूप में रखा जाता है, और हैकर्स दुनिया के निर्माता, गॉड द फादर की छोटी-छोटी नकलें हैं। बग की रिपोर्ट करने की प्रक्रिया चाहे जो भी हो, यह एकतरफा होने की संभावना है: बग के बारे में सुनने वाले सहायता कर्मी कुछ फॉर्म भरते हैं जो अंततः प्रोग्रामर को (संभवतः QA के माध्यम से) दिया जाता है, जो इसे अपने कामों की सूची में डाल देते हैं। वायावेब में यह बहुत अलग था। ग्राहक से बग के बारे में सुनने के एक मिनट के भीतर, सहायता कर्मी प्रोग्रामर के बगल में खड़े होकर उसे यह कहते हुए सुन सकते थे कि "अरे, तुम सही हो, यह एक बग है।" हैकर्स से "तुम सही हो" सुनकर सहायता कर्मियों को खुशी होती थी। वे हमें बग उसी तरह से लाते थे जैसे एक बिल्ली आपके लिए एक चूहा लाती है जिसे उसने अभी-अभी मारा है। इसने उन्हें बग की गंभीरता का आकलन करने में और भी अधिक सावधान बना दिया, क्योंकि अब उनका सम्मान दांव पर था।

याहू द्वारा हमें खरीदे जाने के बाद, ग्राहक सहायता वाले लोगों को प्रोग्रामर से बहुत दूर कर दिया गया। तभी हमें एहसास हुआ कि वे प्रभावी रूप से QA और कुछ हद तक मार्केटिंग भी कर रहे थे। बग पकड़ने के अलावा, वे अस्पष्ट, बग जैसी चीज़ों के ज्ञान के रखवाले थे, जैसे कि ऐसे फ़ीचर जो उपयोगकर्ताओं को भ्रमित करते हैं। [6] वे एक तरह के प्रॉक्सी फ़ोकस ग्रुप भी थे; हम उनसे पूछ सकते थे कि दो नई सुविधाओं में से कौन सी सुविधा उपयोगकर्ताओं को ज़्यादा चाहिए, और वे हमेशा सही होते थे।

हौसला

सॉफ़्टवेयर को तुरंत रिलीज़ करने में सक्षम होना एक बड़ा प्रेरक है। अक्सर जब मैं काम पर जाता था तो मैं सॉफ़्टवेयर में कुछ बदलाव करने के बारे में सोचता था, और उसी दिन उसे कर देता था। यह बड़ी सुविधाओं के लिए भी कारगर रहा। भले ही कुछ लिखने में दो हफ़्ते लगें (कुछ प्रोजेक्ट में ज़्यादा समय लगता है), मुझे पता था कि जैसे ही यह पूरा हो जाएगा, मैं सॉफ़्टवेयर में इसका असर देख पाऊँगा।

अगर मुझे अगली रिलीज़ के लिए एक साल तक इंतज़ार करना पड़ता, तो मैं इनमें से ज़्यादातर विचारों को कम से कम कुछ समय के लिए टाल देता। हालाँकि, विचारों के बारे में बात यह है कि वे और ज़्यादा विचारों को जन्म देते हैं। क्या आपने कभी गौर किया है कि जब आप कुछ लिखने बैठते हैं, तो उसमें आने वाले आधे विचार वे होते हैं जो आपने इसे लिखते समय सोचे थे? सॉफ़्टवेयर के साथ भी यही होता है। एक विचार को लागू करने के लिए काम करने से आपको और ज़्यादा विचार मिलते हैं। इसलिए किसी विचार को टालने से आपको न केवल उसे लागू करने में होने वाली देरी का नुकसान होता है, बल्कि उन सभी विचारों का भी नुकसान होता है जो इसे लागू करने से पैदा होते। वास्तव में, किसी विचार को टालने से शायद नए विचारों में भी बाधा आती है: जैसे ही आप किसी नई सुविधा के बारे में सोचना शुरू करते हैं, आप शेल्फ़ पर नज़र डालते हैं और सोचते हैं "लेकिन मेरे पास पहले से ही बहुत सी नई चीज़ें हैं जो मैं अगली रिलीज़ के लिए करना चाहता हूँ।"

बड़ी कंपनियाँ सुविधाओं को लागू करने के बजाय उनकी योजना बनाती हैं। वायावेब में हम कभी-कभी इस मामले में परेशानी में पड़ जाते थे। निवेशक और विश्लेषक हमसे पूछते थे कि हमने भविष्य के लिए क्या योजना बनाई है। सच्चा जवाब होता कि हमारे पास कोई योजना नहीं है। हमारे पास उन चीज़ों के बारे में सामान्य विचार थे जिन्हें हम सुधारना चाहते थे, लेकिन अगर हमें पता होता कि हम इसे कैसे कर सकते हैं तो हम इसे पहले ही कर चुके होते। अगले छह महीनों में हम क्या करने जा रहे थे? जो भी सबसे बड़ी जीत की तरह दिखता था। मुझे नहीं पता कि मैंने कभी यह जवाब देने की हिम्मत की या नहीं, लेकिन यह सच था। योजनाएँ शेल्फ पर रखे विचारों के लिए बस एक और शब्द हैं। जब हमें अच्छे विचार आए, तो हमने उन्हें लागू किया।

वायावेब में, जैसा कि कई सॉफ्टवेयर कंपनियों में होता है, अधिकांश कोड का एक निश्चित स्वामी होता था। लेकिन जब आप किसी चीज के मालिक होते हैं तो आप वास्तव में उसके मालिक होते हैं: सॉफ्टवेयर के एक हिस्से के मालिक के अलावा किसी को भी रिलीज को मंजूरी देने (या यहां तक कि इसके बारे में जानने) की जरूरत नहीं होती। टूटने के खिलाफ कोई सुरक्षा नहीं थी, सिवाय अपने साथियों के सामने बेवकूफ की तरह दिखने के डर के, और यही काफी था। मैंने शायद यह आभास दिया हो कि हम बस कोड लिखने में आगे बढ़ गए। हमने तेजी से काम किया, लेकिन हमने उन सर्वरों पर सॉफ्टवेयर जारी करने से पहले बहुत सावधानी से सोचा। और धीरे-धीरे आगे बढ़ने की तुलना में विश्वसनीयता के लिए ध्यान देना अधिक महत्वपूर्ण है। क्योंकि वह बारीकी से ध्यान देता है, एक नौसेना पायलट रात में एक पिचिंग कैरियर डेक पर 140 मील प्रति घंटे की गति से 40,000 पाउंड का विमान उतार सकता है, औसत किशोर बैगल काटने की तुलना में अधिक सुरक्षित रूप से।

सॉफ्टवेयर लिखने का यह तरीका बेशक दोधारी तलवार है। यह अच्छे, भरोसेमंद प्रोग्रामर की छोटी टीम के लिए बहुत बेहतर काम करता है, बजाय औसत दर्जे के प्रोग्रामर की बड़ी कंपनी के, जहां खराब विचारों को उन लोगों के बजाय समितियों द्वारा पकड़ा जाता है जिनके पास वे थे।

ब्रूक्स इन रिवर्स

सौभाग्य से, वेब-आधारित सॉफ़्टवेयर के लिए कम प्रोग्रामर की आवश्यकता होती है। मैंने एक बार एक मध्यम आकार की डेस्कटॉप सॉफ़्टवेयर कंपनी के लिए काम किया था, जिसमें इंजीनियरिंग के क्षेत्र में 100 से ज़्यादा लोग काम कर रहे थे। इनमें से सिर्फ़ 13 लोग उत्पाद विकास में थे। बाकी सभी रिलीज़, पोर्ट वगैरह पर काम कर रहे थे। वेब-आधारित सॉफ़्टवेयर के साथ, आपको (ज़्यादा से ज़्यादा) सिर्फ़ 13 लोगों की ज़रूरत होती है, क्योंकि वहाँ कोई रिलीज़, पोर्ट वगैरह नहीं होते।

वायावेब को सिर्फ़ तीन लोगों ने लिखा था। [7] मुझ पर हमेशा ज़्यादा लोगों को काम पर रखने का दबाव रहता था, क्योंकि हम खरीदे जाना चाहते थे, और हम जानते थे कि खरीदारों को सिर्फ़ तीन प्रोग्रामर वाली कंपनी के लिए ज़्यादा कीमत चुकाने में मुश्किल होगी। (समाधान: हमने ज़्यादा लोगों को काम पर रखा, लेकिन उनके लिए नए प्रोजेक्ट बनाए।)

जब आप कम प्रोग्रामर के साथ सॉफ्टवेयर लिख सकते हैं, तो यह आपको पैसे से कहीं ज़्यादा बचाता है। जैसा कि फ्रेड ब्रूक्स ने द मिथिकल मैन-मंथ में बताया है, किसी प्रोजेक्ट में लोगों को जोड़ने से यह धीमा हो जाता है। डेवलपर्स के बीच संभावित कनेक्शन की संख्या समूह के आकार के साथ तेजी से बढ़ती है। समूह जितना बड़ा होगा, वे अपने सॉफ्टवेयर को एक साथ कैसे काम करना है, इस पर बातचीत करने में उतना ही अधिक समय बिताएंगे, और अप्रत्याशित बातचीत से उन्हें उतनी ही अधिक बग मिलेंगी। सौभाग्य से, यह प्रक्रिया विपरीत रूप से भी काम करती है: जैसे-जैसे समूह छोटे होते जाते हैं, सॉफ्टवेयर विकास तेजी से अधिक कुशल होता जाता है। मुझे याद नहीं आता कि वायावेब के प्रोग्रामर कभी वास्तविक बैठक करते थे। हमारे पास कभी भी एक समय में कहने के लिए इतना कुछ नहीं था जितना हम लंच के लिए जाते समय कह सकते थे।

अगर यहाँ कोई नकारात्मक पहलू है, तो वह यह है कि सभी प्रोग्रामर को कुछ हद तक सिस्टम एडमिनिस्ट्रेटर भी होना पड़ता है। जब आप सॉफ़्टवेयर होस्ट कर रहे होते हैं, तो किसी को सर्वर पर नज़र रखनी होती है, और व्यवहार में केवल वही लोग इसे ठीक से कर सकते हैं जिन्होंने सॉफ़्टवेयर लिखा है। वायावेब में हमारे सिस्टम में इतने सारे घटक थे और इतनी बार-बार बदलाव हुए कि सॉफ़्टवेयर और इंफ्रास्ट्रक्चर के बीच कोई निश्चित सीमा नहीं थी। मनमाने ढंग से ऐसी सीमा घोषित करने से हमारे डिज़ाइन विकल्प सीमित हो जाते। और इसलिए हालाँकि हम लगातार उम्मीद कर रहे थे कि एक दिन ("कुछ महीनों में") सब कुछ इतना स्थिर हो जाएगा कि हम किसी ऐसे व्यक्ति को काम पर रख सकें जिसका काम सिर्फ़ सर्वर की चिंता करना हो, ऐसा कभी नहीं हुआ।

मुझे नहीं लगता कि यह किसी और तरीके से हो सकता है, जब तक आप अभी भी सक्रिय रूप से उत्पाद विकसित कर रहे हैं। वेब-आधारित सॉफ़्टवेयर कभी भी ऐसा नहीं होगा जिसे आप लिखें, चेक इन करें और घर चले जाएँ। यह एक लाइव चीज़ है, जो अभी आपके सर्वर पर चल रही है। एक खराब बग सिर्फ़ एक उपयोगकर्ता की प्रक्रिया को क्रैश नहीं कर सकता; यह उन सभी को क्रैश कर सकता है। यदि आपके कोड में कोई बग डिस्क पर कुछ डेटा दूषित करता है, तो आपको इसे ठीक करना होगा। और इसी तरह। हमने पाया कि आपको हर मिनट सर्वर पर नज़र रखने की ज़रूरत नहीं है (पहले साल या उसके बाद), लेकिन आप निश्चित रूप से उन चीज़ों पर नज़र रखना चाहेंगे जिन्हें आपने हाल ही में बदला है। आप देर रात कोड जारी करके घर नहीं चले जाते।

उपयोगकर्ताओं पर नज़र रखना

सर्वर-आधारित सॉफ़्टवेयर के साथ, आप अपने कोड के साथ अधिक निकट संपर्क में रहते हैं। आप अपने उपयोगकर्ताओं के साथ भी अधिक निकट संपर्क में रह सकते हैं। Intuit खुदरा दुकानों पर ग्राहकों से खुद को परिचित कराने और उन्हें घर तक आने के लिए कहने के लिए प्रसिद्ध है। यदि आपने कभी किसी को पहली बार अपने सॉफ़्टवेयर का उपयोग करते हुए देखा है, तो आप जानते हैं कि उन्हें क्या आश्चर्य हुआ होगा।

सॉफ़्टवेयर को वही करना चाहिए जो उपयोगकर्ता सोचते हैं कि वह करेगा। लेकिन आप यह नहीं जान सकते कि उपयोगकर्ता क्या सोच रहे होंगे, मेरा विश्वास करें, जब तक आप उन्हें नहीं देखते। और सर्वर-आधारित सॉफ़्टवेयर आपको उनके व्यवहार के बारे में अभूतपूर्व जानकारी देता है। आप छोटे, कृत्रिम फ़ोकस समूहों तक सीमित नहीं हैं। आप प्रत्येक उपयोगकर्ता द्वारा किए गए प्रत्येक क्लिक को देख सकते हैं। आपको ध्यान से विचार करना होगा कि आप क्या देखने जा रहे हैं, क्योंकि आप उपयोगकर्ताओं की गोपनीयता का उल्लंघन नहीं करना चाहते हैं, लेकिन सबसे सामान्य सांख्यिकीय नमूना भी बहुत उपयोगी हो सकता है।

जब आपके सर्वर पर उपयोगकर्ता होते हैं, तो आपको बेंचमार्क पर निर्भर नहीं रहना पड़ता है, उदाहरण के लिए। बेंचमार्क सिम्युलेटेड उपयोगकर्ता होते हैं। सर्वर-आधारित सॉफ़्टवेयर के साथ, आप वास्तविक उपयोगकर्ताओं को देख सकते हैं। यह तय करने के लिए कि क्या ऑप्टिमाइज़ करना है, बस सर्वर में लॉग इन करें और देखें कि कौन-सी चीज़ CPU का पूरा उपयोग कर रही है। और आपको यह भी पता है कि ऑप्टिमाइज़ करना कब बंद करना है: हमने आखिरकार वायावेब एडिटर को उस बिंदु पर पहुँचाया जहाँ यह CPU-बाउंड के बजाय मेमोरी-बाउंड था, और चूँकि उपयोगकर्ताओं के डेटा के आकार को कम करने के लिए हम कुछ नहीं कर सकते थे (अच्छा, आसान कुछ भी नहीं), हमने सोचा कि हमें यहीं रुकना चाहिए।

सर्वर-आधारित सॉफ़्टवेयर के लिए दक्षता मायने रखती है, क्योंकि आप हार्डवेयर के लिए भुगतान कर रहे हैं। प्रति सर्वर आप जितने उपयोगकर्ताओं का समर्थन कर सकते हैं, वह आपकी पूंजीगत लागत का विभाजक है, इसलिए यदि आप अपने सॉफ़्टवेयर को बहुत कुशल बना सकते हैं तो आप प्रतिस्पर्धियों से कम कीमत पर बेच सकते हैं और फिर भी लाभ कमा सकते हैं। वायावेब में हमने प्रति उपयोगकर्ता पूंजीगत लागत को लगभग $5 तक कम कर दिया है। यह अब कम होगा, शायद उन्हें पहले महीने का बिल भेजने की लागत से भी कम। यदि आपका सॉफ़्टवेयर उचित रूप से कुशल है, तो हार्डवेयर अब मुफ़्त है।

उपयोगकर्ताओं को देखना आपको डिज़ाइन के साथ-साथ अनुकूलन में भी मार्गदर्शन कर सकता है। Viaweb के पास RTML नामक एक स्क्रिप्टिंग भाषा थी जो उन्नत उपयोगकर्ताओं को अपनी स्वयं की पृष्ठ शैलियाँ परिभाषित करने देती थी। हमने पाया कि RTML एक तरह का सुझाव बॉक्स बन गया, क्योंकि उपयोगकर्ता इसका उपयोग केवल तब करते थे जब पूर्वनिर्धारित पृष्ठ शैलियाँ वह नहीं कर पाती थीं जो वे चाहते थे। मूल रूप से संपादक ने पूरे पृष्ठ पर बटन बार लगाए, उदाहरण के लिए, लेकिन जब कई उपयोगकर्ताओं ने बाईं ओर बटन लगाने के लिए RTML का उपयोग किया, तो हमने इसे पूर्वनिर्धारित पृष्ठ शैलियों में एक विकल्प (वास्तव में डिफ़ॉल्ट) बना दिया।

अंत में, उपयोगकर्ताओं को देखकर आप अक्सर बता सकते हैं कि वे कब परेशानी में हैं। और चूंकि ग्राहक हमेशा सही होता है, इसलिए यह किसी ऐसी चीज का संकेत है जिसे आपको ठीक करने की जरूरत है। वायावेब में उपयोगकर्ताओं को पाने की कुंजी ऑनलाइन टेस्ट ड्राइव थी। यह मार्केटिंग लोगों द्वारा बनाई गई स्लाइडों की एक श्रृंखला मात्र नहीं थी। हमारे टेस्ट ड्राइव में, उपयोगकर्ताओं ने वास्तव में सॉफ़्टवेयर का उपयोग किया। इसमें लगभग पाँच मिनट लगे, और इसके अंत में उन्होंने एक वास्तविक, काम करने वाला स्टोर बना लिया था।

टेस्ट ड्राइव के ज़रिए ही हमने अपने लगभग सभी नए उपयोगकर्ता प्राप्त किए। मुझे लगता है कि यह अधिकांश वेब-आधारित अनुप्रयोगों के लिए भी ऐसा ही होगा। यदि उपयोगकर्ता सफलतापूर्वक टेस्ट ड्राइव से गुज़र सकते हैं, तो उन्हें उत्पाद पसंद आएगा। यदि वे भ्रमित या ऊब जाते हैं, तो उन्हें यह पसंद नहीं आएगा। इसलिए हम टेस्ट ड्राइव के ज़रिए ज़्यादा से ज़्यादा लोगों को जोड़ने के लिए जो कुछ भी कर सकते हैं, उससे हमारी वृद्धि दर बढ़ेगी।

मैंने टेस्ट ड्राइव लेने वाले लोगों के क्लिक ट्रेल्स का अध्ययन किया और पाया कि एक निश्चित चरण पर वे भ्रमित हो जाते हैं और ब्राउज़र के बैक बटन पर क्लिक कर देते हैं। (यदि आप वेब-आधारित एप्लिकेशन लिखने का प्रयास करते हैं, तो आप पाएंगे कि बैक बटन आपकी सबसे दिलचस्प दार्शनिक समस्याओं में से एक बन जाता है।) इसलिए मैंने उस बिंदु पर एक संदेश जोड़ा, जिसमें उपयोगकर्ताओं को बताया गया कि वे लगभग समाप्त हो चुके हैं, और उन्हें बैक बटन पर क्लिक न करने की याद दिलाई गई। वेब-आधारित सॉफ़्टवेयर के बारे में एक और बढ़िया बात यह है कि आपको परिवर्तनों से तुरंत प्रतिक्रिया मिलती है: टेस्ट ड्राइव को पूरा करने वाले लोगों की संख्या तुरंत 60% से 90% तक बढ़ गई। और चूंकि नए उपयोगकर्ताओं की संख्या पूरी की गई टेस्ट ड्राइव की संख्या का एक कार्य थी, इसलिए हमारे राजस्व में वृद्धि 50% बढ़ गई, बस उस बदलाव से।

धन

1990 के दशक की शुरुआत में मैंने एक लेख पढ़ा था जिसमें किसी ने कहा था कि सॉफ्टवेयर एक सदस्यता व्यवसाय है। पहले तो यह एक बहुत ही सनकी बयान लगा। लेकिन बाद में मुझे एहसास हुआ कि यह वास्तविकता को दर्शाता है: सॉफ्टवेयर विकास एक सतत प्रक्रिया है। मुझे लगता है कि अगर आप खुले तौर पर सदस्यता शुल्क लेते हैं, तो यह अधिक साफ-सुथरा है, बजाय इसके कि लोगों को नए संस्करण खरीदने और इंस्टॉल करने के लिए मजबूर किया जाए ताकि वे आपको भुगतान करते रहें। और सौभाग्य से, सदस्यताएँ वेब-आधारित अनुप्रयोगों के लिए बिल करने का स्वाभाविक तरीका है।

एप्लीकेशन होस्टिंग एक ऐसा क्षेत्र है जहाँ कंपनियाँ ऐसी भूमिका निभाएँगी जो फ्रीवेयर द्वारा पूरी नहीं की जा सकती। एप्लीकेशन होस्टिंग बहुत तनावपूर्ण है, और इसमें बहुत ज़्यादा खर्च भी होता है। कोई भी इसे मुफ़्त में नहीं करना चाहेगा।

कंपनियों के लिए, वेब-आधारित एप्लिकेशन राजस्व का एक आदर्श स्रोत हैं। प्रत्येक तिमाही को खाली स्लेट से शुरू करने के बजाय, आपके पास एक आवर्ती राजस्व धारा है। चूँकि आपका सॉफ़्टवेयर धीरे-धीरे विकसित होता है, इसलिए आपको इस बात की चिंता करने की ज़रूरत नहीं है कि कोई नया मॉडल फ्लॉप हो जाएगा; वास्तव में, किसी नए मॉडल की कभी ज़रूरत नहीं होती, और यदि आप सॉफ़्टवेयर के साथ कुछ ऐसा करते हैं जिससे उपयोगकर्ता नफ़रत करते हैं, तो आपको तुरंत पता चल जाएगा। आपको बिलों की वसूली न होने की कोई समस्या नहीं है; यदि कोई भुगतान नहीं करता है तो आप बस सेवा बंद कर सकते हैं। और पायरेसी की कोई संभावना नहीं है।

वह अंतिम "लाभ" एक समस्या बन सकता है। कुछ हद तक पायरेसी सॉफ्टवेयर कंपनियों के लिए फायदेमंद होती है। यदि कोई उपयोगकर्ता वास्तव में किसी भी कीमत पर आपका सॉफ़्टवेयर नहीं खरीदता, तो यदि वह पायरेटेड कॉपी का उपयोग करता है, तो आपको कुछ भी नुकसान नहीं होगा। वास्तव में आपको लाभ होगा, क्योंकि वह एक और उपयोगकर्ता है जो आपके सॉफ़्टवेयर को मानक बनाने में मदद कर रहा है - या जो बाद में हाई स्कूल से स्नातक होने पर एक कॉपी खरीद सकता है।

जब वे कर सकते हैं, तो कंपनियाँ मूल्य भेदभाव नामक कुछ करना पसंद करती हैं, जिसका अर्थ है प्रत्येक ग्राहक से उतना ही शुल्क लेना जितना वे वहन कर सकते हैं। [8] सॉफ़्टवेयर विशेष रूप से मूल्य भेदभाव के लिए उपयुक्त है, क्योंकि सीमांत लागत शून्य के करीब है। यही कारण है कि कुछ सॉफ़्टवेयर इंटेल बॉक्स की तुलना में सन पर चलने के लिए अधिक खर्च करते हैं: सन का उपयोग करने वाली कंपनी पैसे बचाने में दिलचस्पी नहीं रखती है और उससे सुरक्षित रूप से अधिक शुल्क लिया जा सकता है। पाइरेसी प्रभावी रूप से मूल्य भेदभाव का सबसे निचला स्तर है। मुझे लगता है कि सॉफ़्टवेयर कंपनियाँ इसे समझती हैं और जानबूझकर कुछ प्रकार की पाइरेसी पर आँखें मूंद लेती हैं। [9] सर्वर-आधारित सॉफ़्टवेयर के साथ उन्हें किसी अन्य समाधान के साथ आना होगा।

वेब-आधारित सॉफ़्टवेयर अच्छी तरह से बिकता है, खासकर डेस्कटॉप सॉफ़्टवेयर की तुलना में, क्योंकि इसे खरीदना आसान है। आप सोच सकते हैं कि लोग कुछ खरीदने का फैसला करते हैं, और फिर इसे दो अलग-अलग चरणों के रूप में खरीदते हैं। यही मैंने वायावेब से पहले सोचा था, इस हद तक कि मैंने इस सवाल के बारे में सोचा था। वास्तव में दूसरा चरण पहले चरण में वापस फैल सकता है: यदि कोई चीज़ खरीदना मुश्किल है, तो लोग इस बारे में अपना विचार बदल देंगे कि उन्हें वह चाहिए या नहीं। और इसके विपरीत: जब कोई चीज़ खरीदना आसान होगा तो आप उसकी ज़्यादा बिक्री करेंगे। मैं ज़्यादा किताबें खरीदता हूँ क्योंकि Amazon मौजूद है। वेब-आधारित सॉफ़्टवेयर दुनिया में खरीदने के लिए सबसे आसान चीज़ है, खासकर अगर आपने अभी-अभी ऑनलाइन डेमो किया है। उपयोगकर्ताओं को क्रेडिट कार्ड नंबर दर्ज करने से ज़्यादा कुछ नहीं करना चाहिए। (उन्हें ज़्यादा कुछ करने के लिए मजबूर करना आपके जोखिम पर है।)

कभी-कभी वेब-आधारित सॉफ़्टवेयर पुनर्विक्रेताओं के रूप में कार्य करने वाले ISP के माध्यम से पेश किए जाते हैं। यह एक बुरा विचार है। आपको सर्वर का प्रबंधन करना होगा, क्योंकि आपको हार्डवेयर और सॉफ़्टवेयर दोनों में लगातार सुधार करने की आवश्यकता होती है। यदि आप सर्वर का सीधा नियंत्रण छोड़ देते हैं, तो आप वेब-आधारित एप्लिकेशन विकसित करने के अधिकांश लाभों को खो देते हैं।

हमारे कई प्रतिस्पर्धियों ने इस तरह से खुद को नुकसान पहुंचाया--आमतौर पर, मुझे लगता है, क्योंकि वे सूट से घिरे हुए थे जो इस विशाल संभावित चैनल के बारे में उत्साहित थे, और उन्हें एहसास नहीं था कि यह उस उत्पाद को बर्बाद कर देगा जिसे वे इसके माध्यम से बेचने की उम्मीद कर रहे थे। आईएसपी के माध्यम से वेब-आधारित सॉफ़्टवेयर बेचना वेंडिंग मशीनों के माध्यम से सुशी बेचने जैसा है।

ग्राहकों

ग्राहक कौन होंगे? वायावेब में वे शुरू में व्यक्ति और छोटी कंपनियाँ थीं, और मुझे लगता है कि वेब-आधारित अनुप्रयोगों के साथ भी यही नियम होगा। ये वे उपयोगकर्ता हैं जो नई चीज़ों को आज़माने के लिए तैयार हैं, आंशिक रूप से इसलिए क्योंकि वे अधिक लचीले हैं, और आंशिक रूप से इसलिए क्योंकि वे नई तकनीक की कम लागत चाहते हैं।

वेब-आधारित अनुप्रयोग अक्सर बड़ी कंपनियों के लिए भी सबसे अच्छी चीज होंगे (हालांकि उन्हें इसे समझने में देर लगेगी)। सबसे अच्छा इंट्रानेट इंटरनेट है। यदि कोई कंपनी सच्चे वेब-आधारित अनुप्रयोगों का उपयोग करती है, तो सॉफ्टवेयर बेहतर काम करेगा, सर्वर बेहतर तरीके से संचालित होंगे, और कर्मचारियों को कहीं से भी सिस्टम तक पहुंच प्राप्त होगी।

इस दृष्टिकोण के खिलाफ तर्क आमतौर पर सुरक्षा पर टिका होता है: यदि कर्मचारियों के लिए पहुँच आसान है, तो यह बुरे लोगों के लिए भी आसान होगा। कुछ बड़े व्यापारी वायावेब का उपयोग करने के लिए अनिच्छुक थे क्योंकि उन्हें लगता था कि ग्राहकों की क्रेडिट कार्ड की जानकारी उनके अपने सर्वर पर सुरक्षित होगी। कूटनीतिक रूप से यह बात कहना आसान नहीं था, लेकिन वास्तव में डेटा उनके हाथों की तुलना में हमारे हाथों में लगभग निश्चित रूप से अधिक सुरक्षित था। सुरक्षा का प्रबंधन करने के लिए कौन बेहतर लोगों को नियुक्त कर सकता है, एक प्रौद्योगिकी स्टार्टअप जिसका पूरा व्यवसाय सर्वर चलाना है, या एक कपड़ा खुदरा विक्रेता? न केवल हमारे पास सुरक्षा के बारे में चिंता करने वाले बेहतर लोग थे, बल्कि हम इसके बारे में अधिक चिंतित थे। अगर कोई कपड़ा खुदरा विक्रेता के सर्वर में सेंध लगाता है, तो यह अधिकतम एक व्यापारी को प्रभावित करेगा, संभवतः इसे दबाया जा सकता है, और सबसे खराब स्थिति में एक व्यक्ति को नौकरी से निकाला जा सकता है। अगर कोई हमारे सर्वर में सेंध लगाता है, तो यह हजारों व्यापारियों को प्रभावित कर सकता है, संभवतः CNet पर समाचार के रूप में समाप्त हो सकता है, और हमें व्यवसाय से बाहर कर सकता है।

अगर आप अपना पैसा सुरक्षित रखना चाहते हैं, तो क्या आप इसे घर में गद्दे के नीचे रखते हैं या बैंक में जमा करते हैं? यह तर्क सर्वर प्रशासन के हर पहलू पर लागू होता है: सिर्फ़ सुरक्षा ही नहीं, बल्कि अपटाइम, बैंडविड्थ, लोड प्रबंधन, बैकअप, आदि। हमारा अस्तित्व इन चीज़ों को सही तरीके से करने पर निर्भर करता है। सर्वर की समस्याएँ हमारे लिए बिलकुल भी ज़रूरी नहीं थीं, जैसे खिलौना बनाने वाले के लिए कोई ख़तरनाक खिलौना या फ़ूड प्रोसेसर के लिए साल्मोनेला का प्रकोप।

वेब-आधारित अनुप्रयोगों का उपयोग करने वाली एक बड़ी कंपनी इस हद तक आईटी आउटसोर्सिंग कर रही है। सुनने में भले ही यह बहुत कठोर लगे, लेकिन मुझे लगता है कि यह आम तौर पर एक अच्छा विचार है। कंपनियों को इन-हाउस सिस्टम प्रशासकों की तुलना में इस तरह से बेहतर सेवा मिलने की संभावना है। सिस्टम प्रशासक चिड़चिड़े और अनुत्तरदायी हो सकते हैं क्योंकि वे सीधे प्रतिस्पर्धी दबाव के संपर्क में नहीं आते हैं: एक सेल्समैन को ग्राहकों से निपटना पड़ता है, और एक डेवलपर को प्रतिस्पर्धियों के सॉफ़्टवेयर से निपटना पड़ता है, लेकिन एक सिस्टम प्रशासक, एक बूढ़े कुंवारे की तरह, उसे लाइन में रखने के लिए बहुत कम बाहरी ताकतें होती हैं। [10] वायावेब में हमें लाइन में रखने के लिए बहुत सारी बाहरी ताकतें थीं। हमें कॉल करने वाले लोग ग्राहक थे, न कि केवल सहकर्मी। अगर कोई सर्वर फंस जाता, तो हम कूद पड़ते; बस इसके बारे में सोचने से मुझे सालों बाद एड्रेनालाईन का झटका लगता है।

इसलिए वेब-आधारित अनुप्रयोग आम तौर पर बड़ी कंपनियों के लिए भी सही उत्तर होंगे। हालाँकि, उन्हें इसका एहसास सबसे आखिर में होगा, जैसा कि डेस्कटॉप कंप्यूटर के मामले में हुआ था। और आंशिक रूप से इसी कारण से: बड़ी कंपनियों को यह समझाने में बहुत पैसा खर्च होगा कि उन्हें कुछ ज़्यादा महंगी चीज़ की ज़रूरत है।

अमीर ग्राहकों में हमेशा महंगे समाधान खरीदने की प्रवृत्ति होती है, भले ही सस्ते समाधान बेहतर हों, क्योंकि महंगे समाधान देने वाले लोग उन्हें बेचने के लिए अधिक खर्च कर सकते हैं। वायावेब में हम हमेशा इसके खिलाफ़ थे। हमने कई उच्च-स्तरीय व्यापारियों को वेब कंसल्टिंग फ़र्मों के हाथों खो दिया, जिन्होंने उन्हें आश्वस्त किया कि अगर वे अपने स्वयं के सर्वर पर कस्टम-मेड ऑनलाइन स्टोर के लिए आधा मिलियन डॉलर का भुगतान करते हैं तो वे बेहतर स्थिति में होंगे। वे, एक नियम के रूप में, बेहतर स्थिति में नहीं थे, जैसा कि एक से अधिक लोगों ने पाया जब क्रिसमस की खरीदारी का मौसम आया और उनके सर्वर पर लोड बढ़ गया। वायावेब इन व्यापारियों की तुलना में बहुत अधिक परिष्कृत था, लेकिन हम उन्हें यह बताने का जोखिम नहीं उठा सकते थे। $ 300 प्रति माह पर, हम ग्राहकों को प्रस्तुतियाँ देने के लिए अच्छी तरह से तैयार और आधिकारिक-ध्वनि वाले लोगों की एक टीम भेजने का जोखिम नहीं उठा सकते थे।

बड़ी कंपनियों द्वारा अतिरिक्त भुगतान का एक बड़ा हिस्सा उन्हें महंगी चीजें बेचने की लागत है। (यदि रक्षा विभाग शौचालय की सीटों के लिए एक हजार डॉलर का भुगतान करता है, तो इसका आंशिक कारण यह है कि शौचालय की सीटों को एक हजार डॉलर में बेचने में बहुत अधिक लागत आती है।) और यही एक कारण है कि इंट्रानेट सॉफ्टवेयर का विकास जारी रहेगा, भले ही यह शायद एक बुरा विचार हो। यह बस अधिक महंगा है। इस पहेली के बारे में आप कुछ नहीं कर सकते, इसलिए सबसे अच्छी योजना यह है कि पहले छोटे ग्राहकों के लिए जाएं। बाकी सब समय के साथ आ जाएगा।

सर्वर का बेटा

सर्वर पर सॉफ़्टवेयर चलाना कोई नई बात नहीं है। वास्तव में यह पुराना मॉडल है: मेनफ़्रेम अनुप्रयोग सभी सर्वर-आधारित हैं। यदि सर्वर-आधारित सॉफ़्टवेयर इतना अच्छा विचार है, तो पिछली बार यह क्यों हार गया? डेस्कटॉप कंप्यूटर मेनफ़्रेम को क्यों पीछे छोड़ गए?

पहले डेस्कटॉप कंप्यूटर बहुत ज़्यादा ख़तरा नहीं लगते थे। पहले उपयोगकर्ता सभी हैकर थे - या शौकिया, जैसा कि उन्हें तब कहा जाता था। उन्हें माइक्रो कंप्यूटर पसंद थे क्योंकि वे सस्ते थे। पहली बार, आप अपना खुद का कंप्यूटर रख सकते थे। "पर्सनल कंप्यूटर" वाक्यांश अब भाषा का हिस्सा है, लेकिन जब इसे पहली बार इस्तेमाल किया गया था, तो यह जानबूझकर दुस्साहसी लगता था, जैसे कि आज "पर्सनल सैटेलाइट" वाक्यांश।

डेस्कटॉप कंप्यूटर ने क्यों बाजी मारी? मुझे लगता है कि ऐसा इसलिए हुआ क्योंकि उनके पास बेहतर सॉफ्टवेयर था। और मुझे लगता है कि माइक्रो कंप्यूटर सॉफ्टवेयर बेहतर इसलिए था क्योंकि इसे छोटी कंपनियां लिख सकती थीं।

मुझे नहीं लगता कि बहुत से लोग यह समझते हैं कि शुरुआती चरण में स्टार्टअप कितने नाजुक और अनिश्चित होते हैं। कई स्टार्टअप लगभग दुर्घटना से शुरू होते हैं - एक जोड़े के रूप में, या तो दिन की नौकरी के साथ या स्कूल में, किसी चीज़ का प्रोटोटाइप लिखना जो अगर आशाजनक लगे, तो एक कंपनी बन सकती है। इस लार्वा चरण में, कोई भी महत्वपूर्ण बाधा स्टार्टअप को उसके रास्ते में ही रोक देगी। मेनफ्रेम सॉफ़्टवेयर लिखने के लिए बहुत अधिक प्रतिबद्धता की आवश्यकता होती है। विकास मशीनें महंगी थीं, और क्योंकि ग्राहक बड़ी कंपनियाँ होती थीं, इसलिए आपको उन्हें बेचने के लिए एक प्रभावशाली दिखने वाले बिक्री दल की आवश्यकता होती थी। मेनफ्रेम सॉफ़्टवेयर लिखने के लिए स्टार्टअप शुरू करना शाम को अपने Apple II पर कुछ हैक करने की तुलना में बहुत अधिक गंभीर कार्य होगा। और इसलिए आपको मेनफ्रेम एप्लिकेशन लिखने वाले बहुत से स्टार्टअप नहीं मिले।

डेस्कटॉप कंप्यूटर के आगमन ने बहुत सारे नए सॉफ़्टवेयर को प्रेरित किया, क्योंकि उनके लिए एप्लिकेशन लिखना लार्वल स्टार्टअप के लिए एक प्राप्त करने योग्य लक्ष्य लगता था। विकास सस्ता था, और ग्राहक व्यक्तिगत लोग होंगे जिन तक आप कंप्यूटर स्टोर या मेल-ऑर्डर के माध्यम से पहुँच सकते हैं।

डेस्कटॉप कंप्यूटर को मुख्यधारा में लाने वाला एप्लीकेशन विजीकैल्क था, जो पहली स्प्रेडशीट थी। इसे अटारी में काम करने वाले दो लोगों ने लिखा था, और फिर भी इसने ऐसी चीजें कीं जो कोई मेनफ्रेम सॉफ्टवेयर नहीं कर सकता था। [11] विजीकैल्क अपने समय में इतना आगे बढ़ चुका था कि लोग इसे चलाने के लिए Apple II खरीदते थे। और यह एक ट्रेंड की शुरुआत थी: डेस्कटॉप कंप्यूटर इसलिए जीते क्योंकि स्टार्टअप ने उनके लिए सॉफ्टवेयर लिखा था।

ऐसा लगता है कि इस बार सर्वर-आधारित सॉफ़्टवेयर अच्छा रहेगा, क्योंकि स्टार्टअप इसे लिखेंगे। कंप्यूटर अब इतने सस्ते हैं कि आप डेस्कटॉप कंप्यूटर को सर्वर के रूप में इस्तेमाल करके काम शुरू कर सकते हैं, जैसा कि हमने किया था। सस्ते प्रोसेसर ने वर्कस्टेशन बाज़ार को खा लिया है (अब आप शायद ही कभी इस शब्द को सुनते हों) और सर्वर बाज़ार में सबसे ज़्यादा जगह बना चुके हैं; याहू के सर्वर, जो इंटरनेट पर किसी भी सर्वर से ज़्यादा लोड को संभालते हैं, उन सभी में वही सस्ते इंटेल प्रोसेसर हैं जो आपके डेस्कटॉप मशीन में हैं। और एक बार जब आप सॉफ़्टवेयर लिख लेते हैं, तो आपको इसे बेचने के लिए बस एक वेबसाइट की ज़रूरत होती है। हमारे लगभग सभी उपयोगकर्ता सीधे हमारी साइट पर मौखिक रूप से और प्रेस में संदर्भों के माध्यम से आए। [12]

वायावेब एक आम लार्वल स्टार्टअप था। हम एक कंपनी शुरू करने से डरे हुए थे, और पहले कुछ महीनों तक हमने खुद को इस बात से सांत्वना दी कि हम इस पूरी चीज़ को एक प्रयोग के रूप में ले सकते हैं जिसे हम किसी भी समय बंद कर सकते हैं। सौभाग्य से, तकनीकी बाधाओं को छोड़कर कुछ ही बाधाएँ थीं। जब हम सॉफ़्टवेयर लिख रहे थे, तो हमारा वेब सर्वर वही डेस्कटॉप मशीन थी जिसका इस्तेमाल हम विकास के लिए करते थे, जो डायलअप लाइन द्वारा बाहरी दुनिया से जुड़ा हुआ था। उस चरण में हमारा एकमात्र खर्च भोजन और किराया था।

स्टार्टअप्स के लिए अब वेब-आधारित सॉफ़्टवेयर लिखना और भी ज़्यादा ज़रूरी हो गया है, क्योंकि डेस्कटॉप सॉफ़्टवेयर लिखना अब पहले से कम मज़ेदार हो गया है। अगर आप अब डेस्कटॉप सॉफ़्टवेयर लिखना चाहते हैं तो आपको इसे Microsoft की शर्तों पर करना होगा, उनके API को कॉल करना होगा और उनके बग वाले OS के हिसाब से काम करना होगा। और अगर आप कुछ ऐसा लिखने में कामयाब हो जाते हैं जो सफल हो जाता है, तो आपको लगेगा कि आप Microsoft के लिए सिर्फ़ मार्केट रिसर्च कर रहे थे।

अगर कोई कंपनी ऐसा प्लैटफ़ॉर्म बनाना चाहती है जिस पर स्टार्टअप काम करेंगे, तो उन्हें इसे कुछ ऐसा बनाना होगा जिसे हैकर खुद इस्तेमाल करना चाहें। इसका मतलब है कि यह सस्ता और अच्छी तरह से डिज़ाइन किया हुआ होना चाहिए। मैक जब पहली बार आया था, तब हैकर्स के बीच लोकप्रिय था और उनमें से बहुत से लोगों ने इसके लिए सॉफ़्टवेयर लिखा था। [13] आप इसे विंडोज के साथ कम देखते हैं, क्योंकि हैकर इसका इस्तेमाल नहीं करते हैं। जो लोग सॉफ़्टवेयर लिखने में अच्छे हैं, वे अब लिनक्स या फ्रीबीएसडी चला रहे हैं।

मुझे नहीं लगता कि हम डेस्कटॉप सॉफ्टवेयर लिखने के लिए स्टार्टअप शुरू करते, क्योंकि डेस्कटॉप सॉफ्टवेयर को विंडोज पर चलना होता है, और विंडोज के लिए सॉफ्टवेयर लिखने से पहले हमें इसका इस्तेमाल करना होता। वेब ने हमें विंडोज के इर्द-गिर्द घूमने और ब्राउज़र के माध्यम से सीधे उपयोगकर्ताओं को यूनिक्स पर चलने वाले सॉफ्टवेयर देने की अनुमति दी। यह एक मुक्तिदायक संभावना है, जो पच्चीस साल पहले पीसी के आगमन की तरह है।

माइक्रोसॉफ्ट

जब डेस्कटॉप कंप्यूटर आए, तो IBM एक ऐसी दिग्गज कंपनी थी जिससे हर कोई डरता था। अब इसकी कल्पना करना मुश्किल है, लेकिन मुझे वह एहसास बहुत अच्छी तरह याद है। अब सबसे भयावह दिग्गज कंपनी माइक्रोसॉफ्ट है, और मुझे नहीं लगता कि वे अपने सामने आने वाले खतरे के प्रति उतने अंधे हैं, जितने कि IBM थे। आखिरकार, माइक्रोसॉफ्ट ने जानबूझकर अपना व्यवसाय IBM की अंधी जगह पर बनाया है।

मैंने पहले बताया था कि मेरी माँ को डेस्कटॉप कंप्यूटर की ज़रूरत नहीं है। ज़्यादातर उपयोगकर्ताओं को शायद इसकी ज़रूरत नहीं है। यह माइक्रोसॉफ्ट के लिए एक समस्या है, और वे इसे जानते हैं। अगर एप्लीकेशन रिमोट सर्वर पर चलते हैं, तो किसी को भी विंडोज की ज़रूरत नहीं है। माइक्रोसॉफ्ट क्या करेगा? क्या वे डेस्कटॉप पर अपने नियंत्रण का इस्तेमाल करके इस नई पीढ़ी के सॉफ़्टवेयर को रोक पाएंगे या बाधित कर पाएंगे?

मेरा अनुमान है कि Microsoft किसी तरह का सर्वर/डेस्कटॉप हाइब्रिड विकसित करेगा, जहाँ ऑपरेटिंग सिस्टम उन सर्वरों के साथ मिलकर काम करेगा जिन्हें वे नियंत्रित करते हैं। कम से कम, फ़ाइलें उन उपयोगकर्ताओं के लिए केंद्रीय रूप से उपलब्ध होंगी जो ऐसा चाहते हैं। मुझे उम्मीद नहीं है कि Microsoft सर्वर पर गणना करने की चरम सीमा तक जाएगा, क्लाइंट के लिए केवल एक ब्राउज़र के साथ, अगर वे इससे बच सकते हैं। यदि आपको क्लाइंट के लिए केवल एक ब्राउज़र की आवश्यकता है, तो आपको क्लाइंट पर Microsoft की आवश्यकता नहीं है, और यदि Microsoft क्लाइंट को नियंत्रित नहीं करता है, तो वे उपयोगकर्ताओं को अपने सर्वर-आधारित अनुप्रयोगों की ओर नहीं धकेल सकते हैं।

मुझे लगता है कि माइक्रोसॉफ्ट को बोतल में जिन्न को बंद रखने में मुश्किल होगी। उनके पास इतने सारे अलग-अलग प्रकार के क्लाइंट होंगे कि वे उन सभी को नियंत्रित नहीं कर पाएंगे। और अगर माइक्रोसॉफ्ट के एप्लिकेशन केवल कुछ क्लाइंट के साथ काम करते हैं, तो प्रतिस्पर्धी किसी भी क्लाइंट से काम करने वाले एप्लिकेशन पेश करके उन्हें मात दे पाएंगे। [14]

वेब-आधारित अनुप्रयोगों की दुनिया में, माइक्रोसॉफ्ट के लिए कोई स्वचालित स्थान नहीं है। वे खुद के लिए जगह बनाने में सफल हो सकते हैं, लेकिन मुझे नहीं लगता कि वे इस नई दुनिया पर उसी तरह हावी हो पाएंगे जैसे उन्होंने डेस्कटॉप अनुप्रयोगों की दुनिया पर किया था।

यह इतना नहीं है कि कोई प्रतियोगी उन्हें फँसा देगा, बल्कि यह कि वे खुद ही फँस जाएँगे। वेब-आधारित सॉफ़्टवेयर के उदय के साथ, उन्हें न केवल तकनीकी समस्याओं का सामना करना पड़ेगा, बल्कि अपनी स्वयं की इच्छाधारी सोच का भी सामना करना पड़ेगा। उन्हें जो करने की ज़रूरत है, वह है अपने मौजूदा व्यवसाय को नष्ट करना, और मैं उन्हें ऐसा करते हुए नहीं देख सकता। वही एकनिष्ठता जिसने उन्हें यहाँ तक पहुँचाया है, अब उनके विरुद्ध काम करेगी। IBM बिल्कुल उसी स्थिति में थी, और वे इसमें महारत हासिल नहीं कर सके। IBM ने माइक्रोकंप्यूटर व्यवसाय में देर से और आधे-अधूरे मन से प्रवेश किया क्योंकि वे अपने नकदी गाय, मेनफ़्रेम कंप्यूटिंग को खतरे में डालने के बारे में अनिश्चित थे। Microsoft भी डेस्कटॉप को बचाने की चाहत में बाधा उत्पन्न करेगा। नकदी गाय आपकी पीठ पर एक शापित भारी बंदर हो सकती है।

मैं यह नहीं कह रहा हूँ कि सर्वर-आधारित अनुप्रयोगों पर कोई हावी नहीं होगा। शायद कोई अंततः हावी हो जाएगा। लेकिन मुझे लगता है कि खुशियों से भरी अराजकता का एक अच्छा लंबा दौर होगा, जैसा कि माइक्रो कंप्यूटर के शुरुआती दिनों में था। वह स्टार्टअप के लिए एक अच्छा समय था। बहुत सी छोटी कंपनियाँ फली-फूलीं, और उन्होंने शानदार चीज़ें बनाकर ऐसा किया।

स्टार्टअप्स लेकिन और भी बहुत कुछ

क्लासिक स्टार्टअप तेज़ और अनौपचारिक होता है, जिसमें कम लोग और कम पैसा होता है। वे कुछ लोग बहुत मेहनत करते हैं, और तकनीक उनके द्वारा लिए गए निर्णयों के प्रभाव को बढ़ा देती है। अगर वे जीतते हैं, तो वे बड़ी जीत हासिल करते हैं।

वेब-आधारित एप्लिकेशन लिखने वाले स्टार्टअप में, स्टार्टअप से जुड़ी हर चीज़ को चरम पर ले जाया जाता है। आप कम लोगों और कम पैसे के साथ भी उत्पाद लिख और लॉन्च कर सकते हैं। आपको और भी तेज़ होना होगा, और आप अधिक अनौपचारिक होने के साथ भी बच सकते हैं। आप सचमुच अपने उत्पाद को अपार्टमेंट के लिविंग रूम में बैठे तीन लोगों और एक ISP पर एक सर्वर के रूप में लॉन्च कर सकते हैं। हमने ऐसा किया।

समय के साथ टीमें छोटी, तेज़ और अधिक अनौपचारिक होती गईं। 1960 में, सॉफ़्टवेयर डेवलपमेंट का मतलब था सींग के आकार के चश्मे और पतली काली नेकटाई वाले पुरुषों से भरा कमरा, जो मेहनत से IBM कोडिंग फ़ॉर्म पर प्रतिदिन दस लाइन कोड लिखते थे। 1980 में, यह आठ से दस लोगों की टीम थी जो जींस पहनकर दफ़्तर जाते थे और vt100 में टाइप करते थे। अब यह लैपटॉप के साथ लिविंग रूम में बैठे कुछ लोग हैं। (और जींस अनौपचारिकता में अंतिम शब्द नहीं है।)

स्टार्टअप तनावपूर्ण होते हैं, और दुर्भाग्य से, वेब-आधारित अनुप्रयोगों के साथ यह चरम पर भी पहुँच जाता है। कई सॉफ़्टवेयर कंपनियों में, विशेष रूप से शुरुआती दौर में, ऐसे समय होते हैं जब डेवलपर्स अपने डेस्क के नीचे सोते थे और इसी तरह की अन्य चीजें भी होती हैं। वेब-आधारित सॉफ़्टवेयर के बारे में चिंताजनक बात यह है कि इसे डिफ़ॉल्ट बनने से रोकने के लिए कुछ भी नहीं है। डेस्क के नीचे सोने की कहानियाँ आमतौर पर समाप्त हो जाती हैं: फिर आखिरकार हमने इसे भेज दिया और हम सभी घर चले गए और एक सप्ताह तक सोए। वेब-आधारित सॉफ़्टवेयर कभी भी शिप नहीं होता है। आप जब तक चाहें 16 घंटे काम कर सकते हैं। और क्योंकि आप कर सकते हैं, और आपके प्रतिस्पर्धी भी कर सकते हैं, इसलिए आप मजबूर होते हैं। आप कर सकते हैं, इसलिए आपको करना चाहिए। यह पार्किंसन का नियम उल्टा चल रहा है।

सबसे बुरी बात घंटे नहीं बल्कि जिम्मेदारी है। प्रोग्रामर और सिस्टम एडमिनिस्ट्रेटर परंपरागत रूप से अपनी-अपनी अलग-अलग चिंताएँ रखते हैं। प्रोग्रामर को बग के बारे में चिंता करनी पड़ती है, और सिस्टम एडमिनिस्ट्रेटर को इंफ्रास्ट्रक्चर के बारे में चिंता करनी पड़ती है। प्रोग्रामर अपना पूरा दिन सोर्स कोड में बिता सकते हैं, लेकिन किसी समय वे घर जाकर इसके बारे में भूल जाते हैं। सिस्टम एडमिनिस्ट्रेटर कभी भी काम को पीछे नहीं छोड़ते, लेकिन जब उन्हें सुबह 4:00 बजे पेज किया जाता है, तो उन्हें आमतौर पर कुछ भी जटिल नहीं करना पड़ता। वेब-आधारित अनुप्रयोगों के साथ, ये दो तरह के तनाव एक साथ मिल जाते हैं। प्रोग्रामर सिस्टम एडमिनिस्ट्रेटर बन जाते हैं, लेकिन बिना किसी स्पष्ट रूप से परिभाषित सीमाओं के जो आमतौर पर काम को सहनीय बनाती हैं।

वायावेब में हमने पहले छह महीने सिर्फ़ सॉफ़्टवेयर लिखने में बिताए। हमने शुरुआती स्टार्टअप की तरह ही लंबे समय तक काम किया। डेस्कटॉप सॉफ़्टवेयर कंपनी में, यह वह हिस्सा होता जहाँ हम कड़ी मेहनत करते, लेकिन अगले चरण की तुलना में यह छुट्टी जैसा लगता, जब हमने उपयोगकर्ताओं को अपने सर्वर पर लिया। वायावेब को याहू को बेचने का दूसरा सबसे बड़ा लाभ (पैसे के बाद) यह था कि पूरी चीज़ की अंतिम ज़िम्मेदारी एक बड़ी कंपनी के कंधों पर डाल दी गई।

डेस्कटॉप सॉफ्टवेयर उपयोगकर्ताओं को सिस्टम प्रशासक बनने के लिए मजबूर करता है। वेब-आधारित सॉफ्टवेयर प्रोग्रामर को ऐसा करने के लिए मजबूर करता है। कुल मिलाकर तनाव कम होता है, लेकिन प्रोग्रामर के लिए ज़्यादा। यह ज़रूरी नहीं कि बुरी खबर हो। अगर आप एक स्टार्टअप हैं जो किसी बड़ी कंपनी के साथ प्रतिस्पर्धा कर रहे हैं, तो यह अच्छी खबर है। [15] वेब-आधारित एप्लिकेशन आपके प्रतिस्पर्धियों को मात देने का एक सीधा तरीका प्रदान करते हैं। कोई भी स्टार्टअप इससे ज़्यादा की मांग नहीं करता।

बस काफी अच्छा

एक चीज़ जो आपको वेब-आधारित एप्लिकेशन लिखने से रोक सकती है, वह है UI के रूप में वेब पेजों की कमी। यह एक समस्या है, मैं मानता हूँ। कुछ चीज़ें थीं जिन्हें हम HTML और HTTP में जोड़ना चाहते थे। हालाँकि, जो बात मायने रखती है वह यह है कि वेब पेज बस अच्छे हैं।

यहाँ पहले माइक्रो कंप्यूटर के साथ एक समानता है। उन मशीनों में प्रोसेसर वास्तव में कंप्यूटर के CPU होने के लिए नहीं थे। उन्हें ट्रैफ़िक लाइट जैसी चीज़ों में इस्तेमाल करने के लिए डिज़ाइन किया गया था। लेकिन एड रॉबर्ट्स जैसे लोगों ने, जिन्होंने अल्टेयर को डिज़ाइन किया था, महसूस किया कि वे पर्याप्त अच्छे थे। आप इनमें से किसी एक चिप को कुछ मेमोरी (पहले अल्टेयर में 256 बाइट्स) और फ्रंट पैनल स्विच के साथ जोड़ सकते हैं, और आपके पास एक काम करने वाला कंप्यूटर होगा। अपना खुद का कंप्यूटर रखने में सक्षम होना इतना रोमांचक था कि बहुत से लोग थे जो उन्हें खरीदना चाहते थे, हालाँकि सीमित संख्या में।

वेब पेजों को अनुप्रयोगों के लिए UI के रूप में डिज़ाइन नहीं किया गया था, लेकिन वे पर्याप्त अच्छे हैं। और उपयोगकर्ताओं की एक महत्वपूर्ण संख्या के लिए, सॉफ़्टवेयर जिसे आप किसी भी ब्राउज़र से उपयोग कर सकते हैं, UI में किसी भी अजीबोगरीब चीज़ को मात देने के लिए अपने आप में पर्याप्त होगा। हो सकता है कि आप HTML का उपयोग करके सबसे अच्छी दिखने वाली स्प्रेडशीट न लिख सकें, लेकिन आप एक स्प्रेडशीट लिख सकते हैं जिसे कई लोग विशेष क्लाइंट सॉफ़्टवेयर के बिना अलग-अलग स्थानों से एक साथ उपयोग कर सकते हैं, या जो लाइव डेटा फ़ीड को शामिल कर सकता है, या जो कुछ शर्तों के ट्रिगर होने पर आपको पेज कर सकता है। इससे भी महत्वपूर्ण बात यह है कि आप नए प्रकार के अनुप्रयोग लिख सकते हैं जिनके अभी तक नाम भी नहीं हैं। VisiCalc केवल मेनफ़्रेम अनुप्रयोग का एक माइक्रोकंप्यूटर संस्करण नहीं था, आखिरकार - यह एक नए प्रकार का अनुप्रयोग था।

बेशक, सर्वर-आधारित अनुप्रयोगों को वेब-आधारित होने की आवश्यकता नहीं है। आप किसी अन्य प्रकार का क्लाइंट रख सकते हैं। लेकिन मुझे पूरा यकीन है कि यह एक बुरा विचार है। यह बहुत सुविधाजनक होगा यदि आप मान सकें कि हर कोई आपका क्लाइंट इंस्टॉल करेगा - इतना सुविधाजनक कि आप आसानी से खुद को यह विश्वास दिला सकें कि वे सभी करेंगे - लेकिन अगर वे ऐसा नहीं करते हैं, तो आप बर्बाद हो जाएँगे। चूँकि वेब-आधारित सॉफ़्टवेयर क्लाइंट के बारे में कुछ नहीं मानता है, यह वेब के काम करने वाली हर जगह काम करेगा। यह पहले से ही एक बड़ा लाभ है, और जैसे-जैसे नए वेब डिवाइस बढ़ते जाएँगे, यह लाभ बढ़ता जाएगा। उपयोगकर्ता आपको पसंद करेंगे क्योंकि आपका सॉफ़्टवेयर बस काम करता है, और आपका जीवन आसान हो जाएगा क्योंकि आपको हर नए क्लाइंट के लिए इसे ट्वीक नहीं करना पड़ेगा। [16]

मुझे लगता है कि मैंने वेब के विकास को किसी और की तरह करीब से देखा है, और मैं यह अनुमान नहीं लगा सकता कि क्लाइंट के साथ क्या होने वाला है। अभिसरण शायद आ रहा है, लेकिन कहाँ? मैं विजेता नहीं चुन सकता। एक बात जो मैं भविष्यवाणी कर सकता हूँ वह है AOL और Microsoft के बीच संघर्ष। Microsoft का .NET जो भी हो, इसमें संभवतः डेस्कटॉप को सर्वर से जोड़ना शामिल होगा। जब तक AOL जवाबी कार्रवाई नहीं करता, तब तक उन्हें या तो किनारे कर दिया जाएगा या Microsoft क्लाइंट और सर्वर सॉफ़्टवेयर के बीच एक पाइप में बदल दिया जाएगा। यदि Microsoft और AOL क्लाइंट युद्ध में उतरते हैं, तो दोनों पर काम करने वाली एकमात्र चीज़ वेब ब्राउज़िंग होगी, जिसका अर्थ है कि वेब-आधारित अनुप्रयोग ही एकमात्र प्रकार होंगे जो हर जगह काम करेंगे।

यह सब कैसे होगा? मुझे नहीं पता। और अगर आप वेब-आधारित अनुप्रयोगों पर दांव लगाते हैं तो आपको यह जानने की ज़रूरत नहीं है। ब्राउज़िंग को तोड़े बिना कोई भी इसे तोड़ नहीं सकता। वेब सॉफ़्टवेयर वितरित करने का एकमात्र तरीका नहीं हो सकता है, लेकिन यह एक ऐसा तरीका है जो अभी काम करता है और लंबे समय तक काम करना जारी रखेगा। वेब-आधारित अनुप्रयोग विकसित करना सस्ता है, और सबसे छोटे स्टार्टअप के लिए भी वितरित करना आसान है। वे बहुत काम के होते हैं, और विशेष रूप से तनावपूर्ण किस्म के होते हैं, लेकिन इससे स्टार्टअप के लिए संभावनाएँ और बेहतर हो जाती हैं।

क्यों नहीं?

ईबी व्हाइट को एक किसान मित्र से यह जानकर बहुत खुशी हुई कि बहुत सी विद्युतीकृत बाड़ों में करंट नहीं बहता। जाहिर है गायें उनसे दूर रहना सीख जाती हैं, और उसके बाद आपको करंट की जरूरत नहीं पड़ती। "उठो गायों!" उन्होंने लिखा, "अपनी आज़ादी का आनंद लो, जबकि तानाशाह खर्राटे ले रहे हैं!"

अगर आप एक हैकर हैं और आपने कभी स्टार्टअप शुरू करने के बारे में सोचा है, तो शायद दो चीजें आपको ऐसा करने से रोक रही हैं। एक तो यह कि आपको बिजनेस के बारे में कुछ नहीं पता। दूसरी बात यह कि आपको प्रतिस्पर्धा से डर लगता है। इनमें से किसी भी बाड़ में कोई करंट नहीं है।

व्यवसाय के बारे में आपको सिर्फ़ दो बातें जाननी चाहिए: कुछ ऐसा बनाएँ जो उपयोगकर्ताओं को पसंद आए और जितना खर्च करें उससे ज़्यादा कमाएँ। अगर आप इन दोनों बातों को सही से समझ लेते हैं, तो आप ज़्यादातर स्टार्टअप से आगे रहेंगे। बाकी आप आगे बढ़ते हुए समझ सकते हैं।

हो सकता है कि आप शुरू में जितना खर्च करते हैं, उससे ज़्यादा न कमा पाएं, लेकिन जब तक यह अंतर तेज़ी से कम होता रहेगा, तब तक आप ठीक रहेंगे। अगर आप कम पैसे में शुरू करते हैं, तो यह कम से कम मितव्ययिता की आदत को बढ़ावा देगा। आप जितना कम खर्च करेंगे, उतना ही ज़्यादा कमाना आपके लिए आसान होगा। सौभाग्य से, वेब-आधारित एप्लिकेशन लॉन्च करना बहुत सस्ता हो सकता है। हमने $10,000 से कम में लॉन्च किया, और आज यह और भी सस्ता होगा। हमें सर्वर पर हज़ारों खर्च करने पड़े, और SSL पाने के लिए हज़ारों और खर्च करने पड़े। (उस समय SSL सॉफ़्टवेयर बेचने वाली एकमात्र कंपनी नेटस्केप थी।) अब आप SSL के साथ एक बहुत ज़्यादा शक्तिशाली सर्वर किराए पर ले सकते हैं, जो सिर्फ़ बैंडविड्थ के लिए दिए गए हमारे भुगतान से भी कम है। आप अब एक वेब-आधारित एप्लिकेशन को एक फैंसी ऑफ़िस कुर्सी की कीमत से भी कम में लॉन्च कर सकते हैं।

जहाँ तक उपयोगकर्ताओं को पसंद आने वाली कोई चीज़ बनाने की बात है, तो यहाँ कुछ सामान्य सुझाव दिए गए हैं। कुछ ऐसा साफ और सरल बनाकर शुरू करें जिसे आप खुद इस्तेमाल करना चाहेंगे। जल्दी से 1.0 संस्करण प्राप्त करें, फिर सॉफ़्टवेयर में सुधार करना जारी रखें, उपयोगकर्ताओं की बात ध्यान से सुनते रहें। ग्राहक हमेशा सही होता है, लेकिन अलग-अलग ग्राहक अलग-अलग चीज़ों के बारे में सही होते हैं; सबसे कम परिष्कृत उपयोगकर्ता आपको दिखाते हैं कि आपको क्या सरल और स्पष्ट करने की आवश्यकता है, और सबसे परिष्कृत उपयोगकर्ता आपको बताते हैं कि आपको कौन सी सुविधाएँ जोड़ने की आवश्यकता है। सॉफ़्टवेयर के लिए सबसे अच्छी चीज़ आसान हो सकती है, लेकिन ऐसा करने का तरीका डिफ़ॉल्ट को सही करना है, न कि उपयोगकर्ताओं की पसंद को सीमित करना। अगर आपके प्रतिस्पर्धियों का सॉफ़्टवेयर खराब है, तो संतुष्ट न हों; आपके सॉफ़्टवेयर की तुलना करने का मानक वह है जो वह हो सकता है, न कि वह जो आपके वर्तमान प्रतिस्पर्धियों के पास है। अपने सॉफ़्टवेयर का हमेशा खुद इस्तेमाल करें। Viaweb को एक ऑनलाइन स्टोर बिल्डर माना जाता था, लेकिन हमने इसका इस्तेमाल अपनी साइट बनाने के लिए भी किया। मार्केटिंग के लोगों या डिज़ाइनरों या उत्पाद प्रबंधकों की सिर्फ़ उनके पद के कारण न सुनें। अगर उनके पास अच्छे विचार हैं, तो उनका इस्तेमाल करें, लेकिन यह तय करना आपके ऊपर है; सॉफ्टवेयर को ऐसे हैकर्स द्वारा डिजाइन किया जाना चाहिए जो डिजाइन को समझते हों, न कि ऐसे डिजाइनर जो सॉफ्टवेयर के बारे में थोड़ा बहुत जानते हों। अगर आप सॉफ्टवेयर को डिजाइन करने के साथ-साथ उसे लागू भी नहीं कर सकते, तो स्टार्टअप शुरू न करें।

अब बात करते हैं प्रतिस्पर्धा की। आप जिस चीज से डरते हैं, वह शायद आप जैसे हैकर्स का समूह नहीं है, बल्कि वास्तविक कंपनियां हैं, जिनके पास कार्यालय और व्यावसायिक योजनाएं और सेल्समैन आदि हैं, है न? खैर, वे आपसे ज़्यादा डरते हैं, जितना आप उनसे डरते हैं, और वे सही हैं। किसी भी आकार की कंपनी के लिए सॉफ़्टवेयर लिखवाना जितना आसान है, उससे कहीं ज़्यादा आसान है कि कुछ हैकर्स के लिए ऑफ़िस स्पेस किराए पर लेना या सेल्समैन को काम पर रखना है। मैं दोनों तरफ़ रहा हूँ, और मैं जानता हूँ। जब वायावेब को याहू ने खरीद लिया, तो मैंने अचानक पाया कि मैं एक बड़ी कंपनी के लिए काम कर रहा हूँ, और यह कमर तक पानी में दौड़ने जैसा था।

मेरा मतलब याहू की निंदा करना नहीं है। उनके पास कुछ अच्छे हैकर थे, और शीर्ष प्रबंधन वास्तव में बहुत बढ़िया था। एक बड़ी कंपनी के लिए, वे असाधारण थे। लेकिन फिर भी वे एक छोटे स्टार्टअप के मुकाबले केवल दसवें हिस्से के बराबर उत्पादक थे। कोई भी बड़ी कंपनी उससे बेहतर नहीं कर सकती। माइक्रोसॉफ्ट के बारे में जो बात डरावनी है वह यह है कि इतनी बड़ी कंपनी सॉफ्टवेयर विकसित कर सकती है। वे एक पहाड़ की तरह हैं जो चल सकता है।

डरो मत। आप उतना कर सकते हैं जो माइक्रोसॉफ्ट नहीं कर सकता और वे उतना कर सकते हैं जो आप नहीं कर सकते। और कोई भी आपको रोक नहीं सकता। आपको वेब-आधारित एप्लिकेशन विकसित करने के लिए किसी की अनुमति लेने की आवश्यकता नहीं है। आपको लाइसेंसिंग डील करने, या रिटेल स्टोर में शेल्फ स्पेस लेने, या अपने एप्लिकेशन को ओएस के साथ बंडल करने के लिए गिड़गिड़ाने की आवश्यकता नहीं है। आप ब्राउज़र को सीधे सॉफ़्टवेयर डिलीवर कर सकते हैं, और कोई भी आपके और संभावित उपयोगकर्ताओं के बीच उन्हें वेब ब्राउज़ करने से रोके बिना नहीं आ सकता।

शायद आपको यकीन न हो, लेकिन मैं आपसे वादा करता हूँ कि माइक्रोसॉफ्ट आपसे डरता है। हो सकता है कि आत्मसंतुष्ट मध्य प्रबंधक आपसे डरे न हों, लेकिन बिल डरता है, क्योंकि वह भी एक बार आप ही थे, 1975 में, जब आखिरी बार सॉफ्टवेयर देने का कोई नया तरीका सामने आया था।

नोट्स

[१] यह समझते हुए कि अधिकांश पैसा सेवाओं में है, हल्के क्लाइंट बनाने वाली कंपनियों ने आमतौर पर हार्डवेयर को एक ऑनलाइन सेवा के साथ जोड़ने की कोशिश की है। यह दृष्टिकोण अच्छी तरह से काम नहीं कर रहा है, आंशिक रूप से क्योंकि आपको उपभोक्ता इलेक्ट्रॉनिक्स बनाने और ऑनलाइन सेवा चलाने के लिए दो अलग-अलग प्रकार की कंपनियों की आवश्यकता है, और आंशिक रूप से क्योंकि उपयोगकर्ता इस विचार से नफरत करते हैं। रेजर देना और ब्लेड पर पैसा कमाना जिलेट के लिए काम कर सकता है, लेकिन एक रेजर एक वेब टर्मिनल की तुलना में बहुत छोटी प्रतिबद्धता है। सेल फोन हैंडसेट निर्माता सेवा राजस्व पर कब्जा करने की कोशिश किए बिना हार्डवेयर बेचने से संतुष्ट हैं। शायद इंटरनेट क्लाइंट के लिए भी यही मॉडल होना चाहिए। अगर कोई सिर्फ एक अच्छा दिखने वाला छोटा बॉक्स बेचता है जिसमें एक वेब ब्राउज़र है जिसका उपयोग आप किसी भी आईएसपी के माध्यम से कनेक्ट करने के लिए कर सकते हैं,

[2] सुरक्षा हमेशा किसी भी डिज़ाइन निर्णय से ज़्यादा गड़बड़ न करने पर निर्भर करती है, लेकिन सर्वर-आधारित सॉफ़्टवेयर की प्रकृति डेवलपर्स को गड़बड़ न करने पर ज़्यादा ध्यान देगी। सर्वर से समझौता करने से इतना नुकसान हो सकता है कि ASP (जो व्यवसाय में बने रहना चाहते हैं) सुरक्षा के बारे में सावधान रहने की संभावना रखते हैं।

[3] 1995 में, जब हमने वायावेब की शुरुआत की थी, तो जावा एप्लेट्स को ऐसी तकनीक माना जाता था जिसका इस्तेमाल हर कोई सर्वर-आधारित एप्लिकेशन विकसित करने के लिए करने वाला था। एप्लेट्स हमें पुराने ज़माने का विचार लगा। क्लाइंट पर चलाने के लिए प्रोग्राम डाउनलोड करें? बस इतना आसान है कि प्रोग्राम को सर्वर पर चलाएँ। हमने एप्लेट्स पर बहुत कम समय बर्बाद किया, लेकिन अनगिनत अन्य स्टार्टअप इस टार पिट में फंस गए होंगे। शायद ही कोई ज़िंदा बच पाया हो, या Microsoft एक्सप्लोरर के सबसे हाल के संस्करण में जावा को छोड़कर बच नहीं सकता था।

[4] यह बात ट्रेवर ब्लैकवेल के कारण है, जो कहते हैं कि "सॉफ्टवेयर लिखने की लागत उसके आकार के साथ रैखिक रूप से अधिक बढ़ जाती है। शायद यह मुख्य रूप से पुरानी बग्स को ठीक करने के कारण है, और यदि सभी बग्स जल्दी से मिल जाएं तो लागत अधिक रैखिक हो सकती है।"

[5] सबसे मुश्किल किस्म का बग कंपाउंड बग का एक प्रकार हो सकता है, जिसमें एक बग दूसरे की भरपाई करता है। जब आप एक बग को ठीक करते हैं, तो दूसरा दिखाई देने लगता है। लेकिन ऐसा लगेगा कि फिक्स में ही गलती है, क्योंकि यह आखिरी चीज थी जिसे आपने बदला था।

[6] वायावेब के भीतर हमने एक बार अपने सॉफ़्टवेयर के बारे में सबसे खराब बात बताने के लिए एक प्रतियोगिता आयोजित की थी। दो ग्राहक सहायता लोगों ने प्रथम पुरस्कार के लिए बराबरी की, जिनकी प्रविष्टियाँ मुझे आज भी याद आती हैं। हमने दोनों समस्याओं को तुरंत ठीक कर दिया।

[7] रॉबर्ट मॉरिस ने ऑर्डरिंग सिस्टम लिखा, जिसका इस्तेमाल दुकानदार ऑर्डर देने के लिए करते थे। ट्रेवर ब्लैकवेल ने इमेज जनरेटर और मैनेजर लिखा, जिसका इस्तेमाल व्यापारी ऑर्डर प्राप्त करने, सांख्यिकी देखने और डोमेन नाम आदि को कॉन्फ़िगर करने के लिए करते थे। मैंने एडिटर लिखा, जिसका इस्तेमाल व्यापारी अपनी साइट बनाने के लिए करते थे। ऑर्डरिंग सिस्टम और इमेज जनरेटर C और C++ में लिखे गए थे, मैनेजर ज़्यादातर Perl में था और एडिटर Lisp में था।

[8] मूल्य भेदभाव इतना व्यापक है (आपने कितनी बार किसी खुदरा विक्रेता को यह दावा करते सुना है कि उनकी क्रय शक्ति का मतलब आपके लिए कम कीमतें हैं?) कि मुझे यह जानकर आश्चर्य हुआ कि इसे 1936 के रॉबिन्सन-पैटमैन अधिनियम द्वारा अमेरिका में गैरकानूनी घोषित कर दिया गया था। यह कानून सख्ती से लागू नहीं होता है।

[9] नो लोगो में, नाओमी क्लेन कहती हैं कि "शहरी युवाओं" द्वारा पसंद किए जाने वाले कपड़ों के ब्रांड दुकानदारी को रोकने के लिए बहुत अधिक प्रयास नहीं करते हैं क्योंकि उनके लक्षित बाजार में दुकानदार फैशन के नेता भी हैं।

[10] कंपनियाँ अक्सर सोचती हैं कि क्या आउटसोर्स किया जाए और क्या नहीं। एक संभावित उत्तर: किसी भी नौकरी को आउटसोर्स करें जो सीधे प्रतिस्पर्धी दबाव के संपर्क में नहीं है, क्योंकि इसे आउटसोर्स करने से यह प्रतिस्पर्धी दबाव के संपर्क में आ जाएगी।

[11] वे दो लोग थे डैन ब्रिकलिन और बॉब फ्रैंकस्टन। डैन ने कुछ दिनों में बेसिक में एक प्रोटोटाइप लिखा, फिर अगले साल के दौरान उन्होंने 6502 मशीन भाषा में लिखे गए एक अधिक शक्तिशाली संस्करण को बनाने के लिए एक साथ (ज्यादातर रात में) काम किया। डैन उस समय हार्वर्ड बिजनेस स्कूल में थे और बॉब का नाममात्र का दिन का काम सॉफ्टवेयर लिखना था। बॉब ने लिखा, "व्यवसाय करने में कोई बड़ा जोखिम नहीं था," "अगर यह विफल हुआ तो विफल हो गया। कोई बड़ी बात नहीं।"

[12] यह उतना आसान नहीं है जितना मैं इसे बता रहा हूँ। मुंह से प्रचार होने में बहुत लंबा समय लगा, और हमें तब तक बहुत ज़्यादा प्रेस कवरेज नहीं मिल पाया जब तक कि हमने एक पीआर फ़र्म (जो कि व्यवसाय में सबसे अच्छी थी) को $16,000 प्रति माह पर काम पर नहीं रखा। हालाँकि, यह सच था कि एकमात्र महत्वपूर्ण चैनल हमारी अपनी वेबसाइट थी।

[13] अगर मैक इतना बढ़िया था, तो यह क्यों हार गया? फिर से, लागत। माइक्रोसॉफ्ट ने सॉफ्टवेयर व्यवसाय पर ध्यान केंद्रित किया, और एप्पल हार्डवेयर पर सस्ते घटक आपूर्तिकर्ताओं की भीड़ को छोड़ दिया। यह भी मदद नहीं की, कि एक महत्वपूर्ण अवधि के दौरान सूट ने कब्जा कर लिया।

[14] एक चीज़ जो वेब-आधारित अनुप्रयोगों में मदद करेगी, और अगली पीढ़ी के सॉफ़्टवेयर को Microsoft द्वारा छायांकित होने से बचाने में मदद करेगी, वह एक अच्छा ओपन-सोर्स ब्राउज़र होगा। मोज़िला ओपन-सोर्स है, लेकिन ऐसा लगता है कि इतने लंबे समय तक कॉर्पोरेट सॉफ़्टवेयर होने के कारण इसे नुकसान उठाना पड़ा है। एक छोटा, तेज़ ब्राउज़र जिसे सक्रिय रूप से बनाए रखा गया हो, अपने आप में एक बड़ी बात होगी, और संभवतः कंपनियों को छोटे वेब उपकरण बनाने के लिए भी प्रोत्साहित करेगी।

अन्य बातों के अलावा, एक उचित ओपन-सोर्स ब्राउज़र HTTP और HTML को विकसित करना जारी रखेगा (जैसे कि Perl ने किया है)। यह वेब-आधारित अनुप्रयोगों को लिंक को चुनने और उसका अनुसरण करने के बीच अंतर करने में सक्षम होने में बहुत मदद करेगा; आपको बस HTTP में एक मामूली वृद्धि करने की आवश्यकता होगी, ताकि अनुरोध में कई URL की अनुमति मिल सके। कैस्केडिंग मेनू भी अच्छे होंगे।

अगर आप दुनिया को बदलना चाहते हैं, तो एक नया मोज़ेक लिखें। क्या आपको लगता है कि अब बहुत देर हो चुकी है? 1998 में बहुत से लोगों को लगा कि नया सर्च इंजन लॉन्च करने में बहुत देर हो चुकी है, लेकिन Google ने उन्हें गलत साबित कर दिया। अगर मौजूदा विकल्प काफी खराब हैं, तो हमेशा कुछ नया करने की गुंजाइश होती है। सुनिश्चित करें कि यह पहले सभी मुफ़्त OS पर काम करे-- नई चीज़ें अपने उपयोगकर्ताओं से शुरू होती हैं।

[15] ट्रेवर ब्लैकवेल, जो शायद व्यक्तिगत अनुभव से इस बारे में किसी से भी अधिक जानते हैं, लिखते हैं:

"मैं यह कहना चाहूंगा कि चूंकि सर्वर-आधारित सॉफ़्टवेयर प्रोग्रामर के लिए बहुत कठिन है, इसलिए यह बड़ी कंपनियों से दूर एक मौलिक आर्थिक बदलाव का कारण बनता है। इसके लिए प्रोग्रामर से उस तरह की तीव्रता और समर्पण की आवश्यकता होती है जो वे केवल तभी देने के लिए तैयार होंगे जब यह उनकी अपनी कंपनी होगी। सॉफ़्टवेयर कंपनियाँ कम मांग वाले वातावरण में काम करने के लिए कुशल लोगों को काम पर रख सकती हैं, और कठिनाइयों को सहने के लिए अकुशल लोगों को काम पर रख सकती हैं, लेकिन वे अपने काम के लिए अत्यधिक कुशल लोगों को काम पर नहीं रख सकती हैं। चूंकि अब पूंजी की आवश्यकता नहीं है, इसलिए बड़ी कंपनियों के पास लाने के लिए बहुत कम है।"

[16] इस निबंध के मूल संस्करण में, मैंने जावास्क्रिप्ट से बचने की सलाह दी थी। 2001 में यह एक अच्छी योजना थी, लेकिन अब जावास्क्रिप्ट काम करती है।

इस पेपर के ड्राफ्ट पढ़ने के लिए सारा हार्लिन, ट्रेवर ब्लैकवेल, रॉबर्ट मॉरिस, एरिक रेमंड, केन एंडरसन और डैन गिफिन को धन्यवाद ; विजीकैल्क के बारे में जानकारी के लिए डैन ब्रिकलिन और बॉब फ्रैंकस्टन को धन्यवाद; और बीबीएन में बोलने के लिए मुझे आमंत्रित करने के लिए केन एंडरसन को भी धन्यवाद।

आपको यह निबंध और 14 अन्य निबंध हैकर्स और पेंटर्स में मिलेंगे।