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

सितंबर 2001

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

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

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

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

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

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

अगली चीज़?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

कोड का शहर

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

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

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

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

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

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

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

रिलीज़

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

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

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

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

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

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

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

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

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

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

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

बग्स

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

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

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

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

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

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

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

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

समर्थन

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

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

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

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

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

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

मनोबल

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

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

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

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

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

ब्रूक्स रिवर्स में

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

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

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

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

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

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

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

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

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

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

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

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

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

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

पैसा

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

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

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

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

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

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

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

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

ग्राहक

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

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

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

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

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

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

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

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

सर्वर का बेटा

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

बस काफी अच्छा

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

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

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

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

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

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

क्यों नहीं?

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

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

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

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

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

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

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

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

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

नोट्स

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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