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

सितंबर 2001

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

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

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

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

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

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

अगली चीज?

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

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

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

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

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

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

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

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

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

"आपका कंप्यूटर" का पूरा विचार गायब हो रहा है, और "आपका डेटा" के साथ बदल रहा है। आपको अपने डेटा तक किसी भी कंप्यूटर से पहुंच प्राप्त करनी चाहिए। या बल्कि, किसी भी क्लाइंट से, और एक क्लाइंट को कंप्यूटर होना आवश्यक नहीं है।

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

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

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

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

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

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

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

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

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

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

कोड का शहर

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

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

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

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

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

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

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

रिलीज़

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

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

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

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

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

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

वेब-आधारित सॉफ्टवेयर के साथ, आपको कभी भी सॉफ्टवेयर जारी करने की आवश्यकता नहीं होती है इससे पहले कि यह काम करे, और आप इसे जैसे ही काम करता है, जारी कर सकते हैं।

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

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

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

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

बग

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

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

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

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

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

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

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

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

समर्थन

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

Viaweb में चीजें इस तरह से काम नहीं करती थीं। Viaweb में, समर्थन मुफ्त था, क्योंकि हम ग्राहकों से सुनना चाहते थे। यदि किसी के पास कोई समस्या थी, तो हम इसके बारे में तुरंत जानना चाहते थे ताकि हम त्रुटि को पुन: उत्पन्न कर सकें और एक सुधार जारी कर सकें।

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

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

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

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

मोराल

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

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

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

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

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

ब्रूक्स उल्टा

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

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

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

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

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

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

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

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

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

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

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

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

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

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

पैसा

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

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

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

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

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

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

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

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

ग्राहक

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

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

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

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

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

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

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

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

सर्वर का पुत्र

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

स्टार्टअप लेकिन अधिक

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

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

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

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

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

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

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

बस पर्याप्त अच्छा

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

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

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

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

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

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

क्यों नहीं?

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

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

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

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

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

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

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

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

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

नोट्स

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

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

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

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

[5] सबसे कठिन प्रकार का बग ढूंढना एक यौगिक बग का एक रूप हो सकता है जहाँ एक बग दूसरे के लिए मुआवजा देता है। जब आप एक बग को ठीक करते हैं, तो दूसरा दिखाई देता है। लेकिन ऐसा लगेगा जैसे कि ठीक करना दोषी है, क्योंकि यह आखिरी चीज थी जिसे आपने बदला।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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