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

सितंबर 2001

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

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

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

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

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

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

अगली चीज़?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

कोड का शहर

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

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

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

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

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

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

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

रिलीज़

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

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

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

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

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

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

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

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

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

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

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

बग्स

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

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

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

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

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

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

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

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

समर्थन

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

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

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

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

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

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

मनोबल

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

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

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

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

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

ब्रूक्स के विपरीत

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

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

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

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

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

उपयोगकर्ताओं को देखना

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

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

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

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

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

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

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

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

पैसा

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

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

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

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

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

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

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

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

ग्राहक

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

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

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

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

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

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

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

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

सर्वर का बेटा

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

बस पर्याप्त

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

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

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

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

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

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

क्यों नहीं?

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

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

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

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

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

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

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

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

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

नोट्स

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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