अन्य सड़क आगे

सितंबर 2001

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

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

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

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

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

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

अगला क्या?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

कोड का शहर

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

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

यह सॉफ्टवेयर पर समाप्त नहीं हुआ। हमने

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

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

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

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

रिलीज़

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

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

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

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

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

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

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

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

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

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

बग

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

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

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

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

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

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

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

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

समर्थन

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

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

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

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

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

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

मनोबल

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

धन

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

होस्टिंग अनुप्रयोग एक ऐसा क्षेत्र है जहां कंपनियां एक भूमिका निभाएंगी जिसे मुफ्त सॉफ्टवेयर द्वारा भरा नहीं जा सकता। होस्टिंग

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

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

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

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

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

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

ग्राहक

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

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

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

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

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

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

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

सर्वर का बेटा

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

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

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

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

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

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

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

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

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

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

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

**माइक्रो

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

क्यों नहीं?

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

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

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

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

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

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

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

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

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

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

नोट्स

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

आप इस निबंध और 14 अन्य को Hackers & Painters में पाएंगे।