महान हैकर
Originalजुलाई 2004
(यह निबंध ओसकॉन 2004 में एक वार्ता से लिया गया है।)
कुछ महीने पहले मैंने एक नई पुस्तक पूरी की, और समीक्षाओं में मुझे "उत्तेजक'' और "विवादास्पद'' जैसे शब्द बार-बार दिखाई दे रहे हैं। "बेवकूफी'' का तो कुछ कहना ही नहीं।
मैंने पुस्तक को विवादास्पद बनाने का इरादा नहीं किया था। मैं इसे प्रभावी बनाने की कोशिश कर रहा था। मैं नहीं चाहता था कि लोगों का समय बर्बाद हो, उन्हें ऐसी बातें बताकर जो वे पहले से जानते थे। उन्हें बस डिफ्स देना अधिक प्रभावी है। लेकिन मुझे लगता है कि इससे एक चिंताजनक पुस्तक निकलने वाली है।
एडिसन
इस बारे में कोई विवाद नहीं है कि कौन सा विचार सबसे विवादास्पद है: यह सुझाव कि धन में भिन्नता शायद उतनी बड़ी समस्या नहीं है जितनी हम सोचते हैं।
मैंने पुस्तक में नहीं कहा कि धन में भिन्नता अपने आप में एक अच्छी चीज है। मैंने कहा कि कुछ परिस्थितियों में यह अच्छी चीजों का संकेत हो सकता है। एक धड़कता सिरदर्द अच्छी चीज नहीं है, लेकिन यह एक अच्छी चीज का संकेत हो सकता है-- उदाहरण के लिए, यह कि आप सिर पर चोट लगने के बाद होश में आ रहे हैं।
धन में भिन्नता उत्पादकता में भिन्नता का संकेत हो सकती है। (एक व्यक्ति के समाज में, वे समान होते हैं।) और यह लगभग निश्चित रूप से एक अच्छी चीज है: यदि आपके समाज में उत्पादकता में कोई भिन्नता नहीं है, तो शायद इसका कारण यह नहीं है कि हर कोई थॉमस एडिसन है। शायद इसका कारण यह है कि आपके पास कोई थॉमस एडिसन नहीं है।
एक निम्न-तकनीकी समाज में आप उत्पादकता में ज्यादा भिन्नता नहीं देखते हैं। यदि आपके पास एक जनजाति है जो आग के लिए लकड़ी इकट्ठा कर रही है, तो सबसे अच्छे लकड़ी इकट्ठा करने वाले की उत्पादकता सबसे खराब से कितनी अधिक होगी? दो का गुणांक? जबकि जब आप लोगों को एक जटिल उपकरण जैसे कंप्यूटर देते हैं, तो वे इसके साथ जो कर सकते हैं, उसमें भिन्नता विशाल होती है।
यह एक नया विचार नहीं है। फ्रेड ब्रूक्स ने 1974 में इसके बारे में लिखा, और जिस अध्ययन का उन्होंने उल्लेख किया, वह 1968 में प्रकाशित हुआ था। लेकिन मुझे लगता है कि उन्होंने प्रोग्रामरों के बीच भिन्नता को कम आंका। उन्होंने कोड की पंक्तियों में उत्पादकता के बारे में लिखा: सबसे अच्छे प्रोग्रामर एक दिए गए समस्या को एक-तिहाई समय में हल कर सकते हैं। लेकिन अगर समस्या दी गई नहीं है तो क्या? प्रोग्रामिंग में, जैसे कई क्षेत्रों में, कठिनाई यह नहीं है कि समस्याओं को हल करना है, बल्कि यह तय करना है कि कौन सी समस्याओं को हल करना है। कल्पना को मापना कठिन है, लेकिन व्यावहारिक रूप से यह उस प्रकार की उत्पादकता पर हावी है जो कोड की पंक्तियों में मापी जाती है।
किसी भी क्षेत्र में उत्पादकता भिन्न होती है, लेकिन कुछ ही ऐसे हैं जिनमें यह इतनी भिन्न होती है। प्रोग्रामरों के बीच भिन्नता इतनी बड़ी है कि यह एक प्रकार का अंतर बन जाती है। मुझे नहीं लगता कि यह प्रोग्रामिंग के लिए कुछ अंतर्निहित है। हर क्षेत्र में, प्रौद्योगिकी उत्पादकता में भिन्नताओं को बढ़ाती है। मुझे लगता है कि प्रोग्रामिंग में जो हो रहा है, वह बस यह है कि हमारे पास बहुत अधिक तकनीकी लाभ है। लेकिन हर क्षेत्र में लीवर लंबा हो रहा है, इसलिए जो भिन्नता हम देखते हैं, वह समय के साथ अधिक से अधिक क्षेत्रों में देखने को मिलेगी। और कंपनियों और देशों की सफलता इस पर निर्भर करेगी कि वे इसके साथ कैसे निपटते हैं।
यदि उत्पादकता में भिन्नता प्रौद्योगिकी के साथ बढ़ती है, तो सबसे उत्पादक व्यक्तियों का योगदान न केवल असमान रूप से बड़ा होगा, बल्कि वास्तव में समय के साथ बढ़ेगा। जब आप उस बिंदु पर पहुंचते हैं जहां एक समूह का 90% उत्पादन उसके 1% सदस्यों द्वारा बनाया जाता है, तो यदि कुछ (चाहे वह वाइकिंग हमले हों, या केंद्रीय योजना) उनकी उत्पादकता को औसत पर खींच लेता है, तो आप बड़े नुकसान में होते हैं।
यदि हम उनसे अधिकतम लाभ उठाना चाहते हैं, तो हमें इन विशेष रूप से उत्पादक लोगों को समझने की आवश्यकता है। उन्हें क्या प्रेरित करता है? उन्हें अपने काम करने के लिए क्या चाहिए? आप उन्हें कैसे पहचानते हैं? आप उन्हें अपने लिए काम करने के लिए कैसे लाते हैं? और फिर निश्चित रूप से सवाल है, आप एक कैसे बनते हैं?
पैसे से अधिक
मैं कुछ सुपर-हैकरों को जानता हूं, इसलिए मैंने बैठकर सोचा कि उनमें क्या समानता है। उनकी परिभाषित गुणवत्ता शायद यह है कि वे वास्तव में प्रोग्रामिंग से प्यार करते हैं। साधारण प्रोग्रामर बिलों का भुगतान करने के लिए कोड लिखते हैं। महान हैकर इसे एक मजेदार काम के रूप में सोचते हैं, और उन्हें खुशी होती है कि लोग इसके लिए उन्हें भुगतान करेंगे।
कहा जाता है कि महान प्रोग्रामर पैसे के प्रति उदासीन होते हैं। यह पूरी तरह से सच नहीं है। यह सच है कि वे वास्तव में केवल दिलचस्प काम करने की परवाह करते हैं। लेकिन यदि आप पर्याप्त पैसा कमाते हैं, तो आप जो चाहें उस पर काम कर सकते हैं, और इस कारण से हैकर हैं वास्तव में बड़े पैमाने पर पैसे कमाने के विचार से आकर्षित होते हैं। लेकिन जब तक उन्हें हर दिन काम पर आना पड़ता है, वे वहां जो करते हैं, उसकी तुलना में उन्हें इसके लिए कितना भुगतान किया जाता है, इसकी अधिक परवाह होती है।
आर्थिक रूप से, यह सबसे महत्वपूर्ण तथ्यों में से एक है, क्योंकि इसका मतलब है कि आपको महान हैकरों को उनके मूल्य के अनुसार कुछ भी भुगतान करने की आवश्यकता नहीं है। एक महान प्रोग्रामर साधारण एक की तुलना में दस या सौ गुना अधिक उत्पादक हो सकता है, लेकिन वह खुद को तीन गुना अधिक भुगतान पाने के लिए भाग्यशाली मानता है। जैसा कि मैं बाद में समझाऊंगा, यह आंशिक रूप से इसलिए है क्योंकि महान हैकर नहीं जानते कि वे कितने अच्छे हैं। लेकिन यह भी इसलिए है क्योंकि पैसा मुख्य चीज नहीं है जो वे चाहते हैं।
हैकरों को क्या चाहिए? सभी कारीगरों की तरह, हैकरों को अच्छे उपकरण पसंद हैं। वास्तव में, यह एक कम शब्द है। अच्छे हैकर खराब उपकरणों का उपयोग करना असहनीय मानते हैं। वे गलत बुनियादी ढांचे के साथ परियोजनाओं पर काम करने से बस इनकार कर देंगे।
एक स्टार्टअप में जहां मैंने एक बार काम किया, हमारे सूचना पट्ट पर जो चीजें चिपकी थीं, उनमें से एक आईबीएम का विज्ञापन था। यह एक AS400 की तस्वीर थी, और शीर्षक पढ़ा, मुझे लगता है, "हैकर इसे नफरत करते हैं।'' [1]
जब आप किसी परियोजना के लिए किस बुनियादी ढांचे का उपयोग करना है, यह तय करते हैं, तो आप केवल एक तकनीकी निर्णय नहीं ले रहे हैं। आप एक सामाजिक निर्णय भी ले रहे हैं, और यह दोनों में से अधिक महत्वपूर्ण हो सकता है। उदाहरण के लिए, यदि आपकी कंपनी कुछ सॉफ़्टवेयर लिखना चाहती है, तो यह जावा में लिखना एक विवेकपूर्ण विकल्प लग सकता है। लेकिन जब आप एक भाषा चुनते हैं, तो आप एक समुदाय भी चुन रहे होते हैं। प्रोग्रामर जिन्हें आप जावा परियोजना पर काम करने के लिए नियुक्त कर सकेंगे, वे उतने स्मार्ट नहीं होंगे जितने कि वे लोग जो एक परियोजना पर काम करने के लिए मिल सकते हैं जो पायथन में लिखी गई है। और आपके हैकरों की गुणवत्ता शायद उस भाषा की तुलना में अधिक महत्वपूर्ण है जिसे आप चुनते हैं। हालांकि, ईमानदारी से, अच्छे हैकरों का जावा की तुलना में पायथन को पसंद करना आपको उन भाषाओं के सापेक्ष गुणों के बारे में कुछ बताना चाहिए।
व्यापारिक प्रकार सबसे लोकप्रिय भाषाओं को पसंद करते हैं क्योंकि वे भाषाओं को मानकों के रूप में देखते हैं। वे कंपनी को Betamax पर दांव नहीं लगाना चाहते। हालांकि, भाषाओं के बारे में बात यह है कि वे केवल मानक नहीं हैं। यदि आपको नेटवर्क पर बिट्स को स्थानांतरित करना है, तो निश्चित रूप से TCP/IP का उपयोग करें। लेकिन एक प्रोग्रामिंग भाषा केवल एक प्रारूप नहीं है। एक प्रोग्रामिंग भाषा अभिव्यक्ति का एक माध्यम है।
मैंने पढ़ा है कि जावा ने हाल ही में कोबोल को सबसे लोकप्रिय भाषा के रूप में पीछे छोड़ दिया है। एक मानक के रूप में, आप और अधिक की कामना नहीं कर सकते। लेकिन अभिव्यक्ति के एक माध्यम के रूप में, आप बहुत बेहतर कर सकते हैं। सभी महान प्रोग्रामरों में से जिनके बारे में मैं सोच सकता हूं, मुझे केवल एक ही पता है जो स्वेच्छा से जावा में प्रोग्राम करेगा। और सभी महान प्रोग्रामरों में से जिनके बारे में मैं सोच सकता हूं जो सन के लिए काम नहीं करते, मैं शून्य जानता हूं।
महान हैकर आमतौर पर ओपन-सोर्स सॉफ़्टवेयर का उपयोग करने पर जोर देते हैं। न केवल इसलिए कि यह बेहतर है, बल्कि इसलिए कि यह उन्हें अधिक नियंत्रण देता है। अच्छे हैकर नियंत्रण पर जोर देते हैं। यह उन्हें अच्छे हैकर बनाने का एक हिस्सा है: जब कुछ टूट जाता है, तो उन्हें इसे ठीक करने की आवश्यकता होती है। आप चाहते हैं कि वे आपके लिए जो सॉफ़्टवेयर लिख रहे हैं, उसके बारे में ऐसा महसूस करें। जब वे ऑपरेटिंग सिस्टम के बारे में ऐसा महसूस करते हैं, तो आपको आश्चर्य नहीं होना चाहिए।
कुछ साल पहले एक उद्यम पूंजीपति मित्र ने मुझे एक नए स्टार्टअप के बारे में बताया जिसमें वह शामिल था। यह आशाजनक लग रहा था। लेकिन जब मैंने उनसे अगली बार बात की, तो उन्होंने कहा कि उन्होंने अपने सॉफ़्टवेयर को विंडोज NT पर बनाने का निर्णय लिया है, और उन्होंने अपने मुख्य तकनीकी अधिकारी के रूप में एक बहुत अनुभवी NT डेवलपर को नियुक्त किया है। जब मैंने यह सुना, तो मैंने सोचा, ये लोग बर्बाद हो गए हैं। एक, CTO पहले श्रेणी का हैकर नहीं हो सकता, क्योंकि एक प्रमुख NT डेवलपर बनने के लिए उसे स्वेच्छा से NT का उपयोग करना पड़ा होगा, कई बार, और मैं एक महान हैकर को ऐसा करते हुए नहीं देख सकता; और दो, भले ही वह अच्छा हो, यदि परियोजना को NT पर बनाना है तो उसे किसी अच्छे को काम पर रखने में कठिनाई होगी। [2]
अंतिम सीमा
सॉफ़्टवेयर के बाद, एक हैकर के लिए सबसे महत्वपूर्ण उपकरण शायद उसका कार्यालय है। बड़ी कंपनियां सोचती हैं कि कार्यालय स्थान का कार्य रैंक को व्यक्त करना है। लेकिन हैकर अपने कार्यालयों का उपयोग इससे अधिक के लिए करते हैं: वे अपने कार्यालय का उपयोग सोचने के स्थान के रूप में करते हैं। और यदि आप एक तकनीकी कंपनी हैं, तो उनके विचार आपका उत्पाद हैं। इसलिए हैकरों को एक शोर, विकर्षक वातावरण में काम करने के लिए मजबूर करना ऐसा है जैसे एक पेंट फैक्ट्री हो जहां हवा धुएं से भरी हो।
कार्टून स्ट्रिप डिल्बर्ट में क्यूबिकल्स के बारे में बहुत कुछ कहा गया है, और अच्छे कारण के साथ। सभी हैकर जिन्हें मैं जानता हूं, उन्हें नफरत करते हैं। बाधित होने की केवल संभावना ही हैकरों को कठिन समस्याओं पर काम करने से रोकने के लिए पर्याप्त है। यदि आप एक कार्यालय में क्यूबिकल्स के साथ वास्तविक काम करना चाहते हैं, तो आपके पास दो विकल्प हैं: घर पर काम करें, या जल्दी या देर से या सप्ताहांत पर आएं, जब कोई और वहां नहीं होता। क्या कंपनियों को यह एहसास नहीं होता कि यह एक संकेत है कि कुछ टूट गया है? एक कार्यालय वातावरण ऐसा होना चाहिए जो आपकी मदद करे, न कि ऐसा कुछ जिससे आप काम करें।
सिस्को जैसी कंपनियां गर्व करती हैं कि वहां हर किसी के पास एक क्यूबिकल है, यहां तक कि CEO के पास भी। लेकिन वे उतने उन्नत नहीं हैं जितना वे सोचते हैं; स्पष्ट रूप से वे अभी भी कार्यालय स्थान को रैंक के बैज के रूप में देखते हैं। यह भी ध्यान दें कि सिस्को अपने घर में बहुत कम उत्पाद विकास करने के लिए प्रसिद्ध है। वे नई तकनीकें उन स्टार्टअप्स को खरीदकर प्राप्त करते हैं जिन्होंने इसे बनाया-- जहां शायद हैकरों के पास काम करने के लिए कहीं शांत जगह थी।
एक बड़ी कंपनी जो हैकरों की जरूरतों को समझती है, वह माइक्रोसॉफ्ट है। मैंने एक बार माइक्रोसॉफ्ट के लिए एक भर्ती विज्ञापन देखा जिसमें एक दरवाजे की बड़ी तस्वीर थी। हमारे लिए काम करें, यह था, और हम आपको काम करने के लिए एक जगह देंगे जहां आप वास्तव में काम कर सकते हैं। और आप जानते हैं, माइक्रोसॉफ्ट बड़ी कंपनियों में अद्वितीय है कि वे घर में सॉफ़्टवेयर विकसित करने में सक्षम हैं। शायद अच्छी तरह से नहीं, लेकिन पर्याप्त रूप से।
यदि कंपनियां चाहती हैं कि हैकर उत्पादक हों, तो उन्हें देखना चाहिए कि वे घर पर क्या करते हैं। घर पर, हैकर चीजों को इस तरह से व्यवस्थित कर सकते हैं कि वे अधिकतम काम कर सकें। और जब वे घर पर काम करते हैं, तो हैकर शोरगुल वाले, खुले स्थानों में काम नहीं करते; वे दरवाजों वाले कमरों में काम करते हैं। वे आरामदायक, पड़ोसी स्थानों में काम करते हैं जहां लोग होते हैं और जब उन्हें कुछ सोचने की आवश्यकता होती है तो कहीं चलने के लिए होता है, बजाय इसके कि वे पार्किंग स्थलों के एकड़ में सेट कांच के बक्सों में हों। उनके पास एक सोफा होता है जिस पर वे थक जाने पर झपकी ले सकते हैं, बजाय इसके कि वे अपने डेस्क पर कोमा में बैठकर काम करने का दिखावा करें। हर शाम प्रमुख हैकिंग घंटों के दौरान वैक्यूम क्लीनर के साथ एक दल नहीं होता है। वहां कोई बैठकें नहीं होती हैं या, भगवान न करे, कॉर्पोरेट रिट्रीट या टीम-बिल्डिंग अभ्यास नहीं होते हैं। और जब आप देखते हैं कि वे उस कंप्यूटर पर क्या कर रहे हैं, तो आप पाएंगे कि यह उस बारे में जो मैंने पहले कहा था, उसे मजबूत करता है कि उपकरणों के बारे में। उन्हें काम पर जावा और विंडोज का उपयोग करना पड़ सकता है, लेकिन घर पर, जहां वे अपने लिए चुन सकते हैं, आप उन्हें पर्ल और लिनक्स का उपयोग करते हुए अधिक संभावना से पाएंगे।
वास्तव में, कोबोल या जावा के सबसे लोकप्रिय भाषा होने के बारे में ये आंकड़े भ्रामक हो सकते हैं। यदि हम यह जानना चाहते हैं कि कौन से उपकरण सबसे अच्छे हैं, तो हमें यह देखना चाहिए कि हैकर स्वतंत्र रूप से क्या चुनते हैं-- अर्थात्, अपने स्वयं के परियोजनाओं में। जब आप उस प्रश्न को पूछते हैं, तो आप पाते हैं कि ओपन-सोर्स ऑपरेटिंग सिस्टम पहले से ही एक प्रमुख बाजार हिस्सेदारी रखते हैं, और नंबर एक भाषा शायद पर्ल है।
दिलचस्प
अच्छे उपकरणों के साथ, हैकरों को दिलचस्प परियोजनाएं चाहिए। एक परियोजना को दिलचस्प क्या बनाता है? खैर, स्पष्ट रूप से स्पष्ट रूप से आकर्षक अनुप्रयोग जैसे स्टेल्थ प्लेन या विशेष प्रभाव सॉफ़्टवेयर पर काम करना दिलचस्प होगा। लेकिन कोई भी अनुप्रयोग दिलचस्प हो सकता है यदि यह नए तकनीकी चुनौतियों को प्रस्तुत करता है। इसलिए यह भविष्यवाणी करना कठिन है कि हैकरों को कौन सी समस्याएं पसंद आएंगी, क्योंकि कुछ केवल तब दिलचस्प हो जाती हैं जब उन पर काम करने वाले लोग एक नए प्रकार का समाधान खोजते हैं। ITA से पहले (जिसने Orbitz के अंदर सॉफ़्टवेयर लिखा), एयरलाइन किराया खोजों पर काम करने वाले लोग शायद सोचते थे कि यह सबसे उबाऊ अनुप्रयोगों में से एक है। लेकिन ITA ने इसे दिलचस्प बना दिया समस्या को एक अधिक महत्वाकांक्षी तरीके से फिर से परिभाषित करके।
मुझे लगता है कि यही चीज गूगल में हुई। जब गूगल की स्थापना हुई, तो तथाकथित पोर्टलों के बीच सामान्य ज्ञान था कि खोज उबाऊ और महत्वहीन थी। लेकिन गूगल के लोग नहीं सोचते थे कि खोज उबाऊ है, और यही कारण है कि वे इसे इतनी अच्छी तरह से करते हैं।
यह एक ऐसा क्षेत्र है जहां प्रबंधक अंतर बना सकते हैं। जैसे एक माता-पिता बच्चे से कहता है, मैं शर्त लगाता हूं कि आप अपने पूरे कमरे को दस मिनट में साफ नहीं कर सकते, एक अच्छा प्रबंधक कभी-कभी एक समस्या को एक अधिक दिलचस्प समस्या के रूप में फिर से परिभाषित कर सकता है। स्टीव जॉब्स इस मामले में विशेष रूप से अच्छे लगते हैं, आंशिक रूप से बस उच्च मानकों के कारण। मैक से पहले कई छोटे, सस्ते कंप्यूटर थे। उन्होंने समस्या को फिर से परिभाषित किया: एक ऐसा बनाएं जो सुंदर हो। और शायद इससे डेवलपर्स को किसी भी गाजर या डंडे से अधिक कठिनाई हुई।
उन्होंने निश्चित रूप से इसे पूरा किया। जब मैक पहली बार आया, तो आपको यह जानने के लिए इसे चालू करने की भी आवश्यकता नहीं थी कि यह अच्छा होगा; आप केस से बता सकते थे। कुछ हफ्ते पहले मैं कैम्ब्रिज में सड़क पर चल रहा था, और किसी के कचरे में मैंने एक मैक कैरींग केस देखा। मैंने अंदर देखा, और वहां एक मैक SE था। मैंने इसे घर ले जाकर प्लग किया, और यह बूट हो गया। खुश मैकिंटॉश चेहरा, और फिर फाइंडर। हे भगवान, यह इतना सरल था। यह बस ... गूगल की तरह था।
हैकर उच्च मानकों वाले लोगों के लिए काम करना पसंद करते हैं। लेकिन केवल सटीक होना पर्याप्त नहीं है। आपको सही चीजों पर जोर देना होगा। जिसका आमतौर पर मतलब है कि आपको खुद एक हैकर होना चाहिए। मैंने कभी-कभी प्रोग्रामरों को प्रबंधित करने के बारे में लेख देखे हैं। वास्तव में, दो लेख होने चाहिए: एक उस बारे में जो आप करें यदि आप स्वयं एक प्रोग्रामर हैं, और एक उस बारे में जो आप करें यदि आप नहीं हैं। और दूसरा शायद दो शब्दों में संक्षिप्त किया जा सकता है: हार मान लें।
समस्या दिन-प्रतिदिन के प्रबंधन में नहीं है। वास्तव में अच्छे हैकर लगभग स्व-प्रबंधित होते हैं। समस्या यह है कि यदि आप एक हैकर नहीं हैं, तो आप यह नहीं बता सकते कि अच्छे हैकर कौन हैं। एक समान समस्या यह बताती है कि अमेरिकी कारें इतनी बदसूरत क्यों हैं। मैं इसे डिजाइन विरोधाभास कहता हूं। आप सोच सकते हैं कि आप अपने उत्पादों को सुंदर बना सकते हैं बस एक महान डिजाइनर को उन्हें डिजाइन करने के लिए नियुक्त करके। लेकिन यदि आपके पास खुद अच्छा स्वाद नहीं है, तो आप एक अच्छे डिजाइनर को कैसे पहचानेंगे? परिभाषा के अनुसार, आप उसके पोर्टफोलियो से नहीं बता सकते। और आप उसके द्वारा जीते गए पुरस्कारों या उसके द्वारा किए गए कामों के आधार पर नहीं जा सकते, क्योंकि डिजाइन में, जैसे अधिकांश क्षेत्रों में, वे आमतौर पर फैशन और चापलूसी द्वारा संचालित होते हैं, जिसमें वास्तविक क्षमता तीसरे स्थान पर होती है। इसके चारों ओर कोई रास्ता नहीं है: आप सुंदर चीजें उत्पन्न करने के लिए एक प्रक्रिया का प्रबंधन नहीं कर सकते बिना यह जाने कि सुंदर क्या है। अमेरिकी कारें बदसूरत हैं क्योंकि अमेरिकी कार कंपनियों का संचालन उन लोगों द्वारा किया जाता है जिनका स्वाद खराब होता है।
इस देश में कई लोग स्वाद को कुछ अदृश्य या यहां तक कि तुच्छ मानते हैं। यह न तो है। डिजाइन को चलाने के लिए, एक प्रबंधक को कंपनी के उत्पादों का सबसे मांग करने वाला उपयोगकर्ता होना चाहिए। और यदि आपके पास वास्तव में अच्छा स्वाद है, तो आप, जैसे स्टीव जॉब्स करते हैं, अपने आप को संतुष्ट करने की समस्या को ऐसा बना सकते हैं कि अच्छे लोग उस पर काम करना पसंद करें।
खराब छोटे समस्याएं
यह कहना काफी आसान है कि किस प्रकार की समस्याएं दिलचस्प नहीं हैं: वे जहां आपको कुछ बड़े, स्पष्ट समस्याओं को हल करने के बजाय बहुत सारी खराब छोटी समस्याओं को हल करना होता है। सबसे खराब प्रकार की परियोजनाओं में से एक एक सॉफ़्टवेयर के लिए एक इंटरफ़ेस लिखना है जो बग से भरा हुआ है। एक और तब होती है जब आपको किसी व्यक्तिगत ग्राहक की जटिल और अस्पष्ट आवश्यकताओं के लिए कुछ अनुकूलित करना होता है। हैकरों के लिए, इस प्रकार की परियोजनाएं हजारों कटों की मौत होती हैं।
खराब छोटी समस्याओं की विशेषता यह है कि आप उनसे कुछ नहीं सीखते हैं। एक कंपाइलर लिखना दिलचस्प है क्योंकि यह आपको सिखाता है कि कंपाइलर क्या है। लेकिन एक बग-युक्त सॉफ़्टवेयर के लिए एक इंटरफ़ेस लिखना आपको कुछ नहीं सिखाता, क्योंकि बग यादृच्छिक होते हैं। [3] इसलिए यह केवल बारीकी से नहीं है जो अच्छे हैकरों को खराब छोटी समस्याओं से बचाता है। यह अधिक आत्म-रक्षा का सवाल है। खराब छोटी समस्याओं पर काम करना आपको बेवकूफ बना देता है। अच्छे हैकर इसे उसी कारण से बचते हैं जिस कारण मॉडल चीज़बर्गर से बचते हैं।
बेशक कुछ समस्याएं स्वाभाविक रूप से इस चरित्र की होती हैं। और आपूर्ति और मांग के कारण, वे विशेष रूप से अच्छी तरह से भुगतान करते हैं। इसलिए एक कंपनी जो महान हैकरों को थकाऊ समस्याओं पर काम करने के लिए लाने का एक तरीका खोजती है, वह बहुत सफल होगी। आप इसे कैसे करेंगे?
एक जगह जहां यह होता है, वह स्टार्टअप में है। हमारे स्टार्टअप में रॉबर्ट मॉरिस एक सिस्टम प्रशासक के रूप में काम कर रहे थे। यह ऐसा है जैसे रोलिंग स्टोन्स को एक बार मित्ज्वा पर खेलते हुए देखना। आप उस प्रकार की प्रतिभा को नियुक्त नहीं कर सकते। लेकिन लोग किसी कंपनी के लिए किसी भी मात्रा में श्रम करेंगे जिसके वे संस्थापक हैं। [4]
बड़ी कंपनियां समस्या को कंपनी को विभाजित करके हल करती हैं। वे स्मार्ट लोगों को काम पर रखने के लिए एक अलग अनुसंधान और विकास विभाग स्थापित करते हैं जहां कर्मचारियों को ग्राहकों की खराब छोटी समस्याओं पर सीधे काम नहीं करना पड़ता। [5] इस मॉडल में, अनुसंधान विभाग एक खदान की तरह कार्य करता है। वे नए विचार उत्पन्न करते हैं; शायद कंपनी का बाकी हिस्सा उनका उपयोग कर सकेगा।
आपको इस चरम पर जाने की आवश्यकता नहीं है। बॉटम-अप प्रोग्रामिंग कंपनी को विभाजित करने का एक और तरीका सुझाता है: स्मार्ट लोगों को उपकरण निर्माताओं के रूप में काम करने दें। यदि आपकी कंपनी x करने के लिए सॉफ़्टवेयर बनाती है, तो एक समूह बनाएं जो उस प्रकार के सॉफ़्टवेयर को लिखने के लिए उपकरण बनाता है, और दूसरा जो इन उपकरणों का उपयोग करके अनुप्रयोग लिखता है। इस तरह आप स्मार्ट लोगों को 99% कोड लिखने के लिए प्राप्त कर सकते हैं, लेकिन फिर भी उन्हें उपयोगकर्ताओं से लगभग उतना ही अलग रख सकते हैं जितना वे पारंपरिक अनुसंधान विभाग में होते। उपकरण निर्माताओं के पास उपयोगकर्ता होंगे, लेकिन वे केवल कंपनी के अपने डेवलपर्स होंगे। [6]
यदि माइक्रोसॉफ्ट इस दृष्टिकोण का उपयोग करता, तो उनका सॉफ़्टवेयर सुरक्षा छिद्रों से भरा नहीं होता, क्योंकि वास्तविक अनुप्रयोगों को लिखने वाले कम स्मार्ट लोग निम्न-स्तरीय चीजें जैसे मेमोरी आवंटित नहीं कर रहे होते। सीधे C में Word लिखने के बजाय, वे Word-भाषा के बड़े लेगो ब्लॉकों को एक साथ जोड़ रहे होते। (डुप्लो, मुझे लगता है, तकनीकी शब्द है।)
क्लंपिंग
दिलचस्प समस्याओं के साथ, अच्छे हैकरों को अन्य अच्छे हैकर पसंद हैं। महान हैकर आमतौर पर एक साथ क्लंप करते हैं-- कभी-कभी तो विशेष रूप से, जैसे कि ज़ेरॉक्स पार्क में। इसलिए आप अच्छे हैकरों को आकर्षित नहीं करेंगे कि आप उनके लिए कितना अच्छा वातावरण बनाते हैं। क्लंपिंग की प्रवृत्ति का मतलब है कि यह उनके वातावरण का वर्ग अधिक है। इसलिए यह विजेता सब कुछ ले जाता है। किसी भी समय, केवल लगभग दस या बीस स्थान होते हैं जहां हैकर सबसे अधिक काम करना चाहते हैं, और यदि आप उनमें से एक नहीं हैं, तो आपके पास केवल कम महान हैकर नहीं होंगे, बल्कि शून्य होंगे।
महान हैकरों का होना, अपने आप में, एक कंपनी को सफल बनाने के लिए पर्याप्त नहीं है। यह गूगल और ITA के लिए अच्छी तरह से काम करता है, जो अभी दो हॉट स्पॉट हैं, लेकिन यह थिंकिंग मशीनों या ज़ेरॉक्स के लिए मददगार नहीं था। सन ने एक समय के लिए अच्छा प्रदर्शन किया, लेकिन उनका व्यापार मॉडल एक डाउन एलेवेटर है। उस स्थिति में, यहां तक कि सबसे अच्छे हैकर भी आपको बचा नहीं सकते।
हालांकि, मुझे लगता है कि सभी अन्य चीजें समान होने पर, एक कंपनी जो महान हैकरों को आकर्षित कर सकती है, उसे एक बड़ा लाभ होगा। ऐसे लोग हैं जो इससे असहमत होंगे। जब हम 1990 के दशक में उद्यम पूंजी फर्मों के दौरों पर थे, तो कई ने हमें बताया कि सॉफ़्टवेयर कंपनियां महान सॉफ़्टवेयर लिखकर नहीं जीततीं, बल्कि ब्रांड, और चैनलों पर प्रभुत्व, और सही सौदों के माध्यम से।
वे वास्तव में इस पर विश्वास करते थे, और मुझे लगता है कि मैं जानता हूं क्यों। मुझे लगता है कि बहुत से VCs जो खोज रहे हैं, कम से कम अवचेतन रूप से, अगला माइक्रोसॉफ्ट है। और निश्चित रूप से यदि माइक्रोसॉफ्ट आपका मॉडल है, तो आपको उन कंपनियों की तलाश नहीं करनी चाहिए जो महान सॉफ़्टवेयर लिखकर जीतने की उम्मीद करती हैं। लेकिन VCs अगली माइक्रोसॉफ्ट की तलाश में गलत हैं, क्योंकि कोई भी स्टार्टअप अगली माइक्रोसॉफ्ट नहीं हो सकता जब तक कि कोई अन्य कंपनी सही समय पर झुकने के लिए तैयार न हो और अगली IBM बन जाए।
माइक्रोसॉफ्ट को एक मॉडल के रूप में उपयोग करना एक गलती है, क्योंकि उनकी पूरी संस्कृति उस एक भाग्यशाली ब्रेक से उत्पन्न होती है। माइक्रोसॉफ्ट एक खराब डेटा बिंदु है। यदि आप उन्हें बाहर फेंक देते हैं, तो आप पाएंगे कि अच्छे उत्पाद वास्तव में बाजार में जीतने की प्रवृत्ति रखते हैं। VCs को अगली एप्पल, या अगली गूगल की तलाश करनी चाहिए।
मुझे लगता है कि बिल गेट्स इसे जानते हैं। गूगल के बारे में उन्हें जो चिंता है, वह उनके ब्रांड की शक्ति नहीं है, बल्कि यह है कि उनके पास बेहतर हैकर हैं। [7]
पहचान
तो महान हैकर कौन हैं? आप कैसे जानते हैं कि जब आप एक से मिलते हैं? यह बहुत कठिन साबित होता है। यहां तक कि हैकर भी नहीं बता सकते। मुझे अब यह निश्चित है कि मेरा दोस्त ट्रेवर ब्लैकवेल एक महान हैकर है। आप शायद स्लैशडॉट पर पढ़ चुके होंगे कि उसने अपना स्वयं का सेगवे बनाया। इस परियोजना की उल्लेखनीय बात यह थी कि उसने एक दिन में सारा सॉफ़्टवेयर लिखा (संयोगवश, पायथन में)।
ट्रेवर के लिए, यह सामान्य बात है। लेकिन जब मैं पहली बार उससे मिला, तो मैंने सोचा कि वह एक पूर्ण बेवकूफ है। वह रॉबर्ट मॉरिस के कार्यालय में खड़ा था और किसी न किसी चीज के बारे में उससे बड़बड़ कर रहा था, और मुझे याद है कि मैं उसके पीछे खड़ा था और रॉबर्ट को इशारे कर रहा था कि इस पागल को उसके कार्यालय से बाहर निकालें ताकि हम लंच के लिए जा सकें। रॉबर्ट कहते हैं कि उन्होंने भी पहले ट्रेवर का गलत आकलन किया। स्पष्ट रूप से जब रॉबर्ट ने पहली बार उससे मिला, ट्रेवर ने एक नई योजना शुरू की थी जिसमें उसने अपने जीवन के हर पहलू के बारे में सब कुछ एक ढेर में लिखने का निर्णय लिया था, जिसे वह हर जगह अपने साथ ले जाता था। वह कनाडा से हाल ही में आया था, और उसकी एक मजबूत कनाडाई लहजा और एक मलेट था।
समस्या इस तथ्य से बढ़ जाती है कि हैकर, अपनी सामाजिक अज्ञानता की प्रतिष्ठा के बावजूद, कभी-कभी स्मार्ट दिखने के लिए काफी प्रयास करते हैं। जब मैं ग्रैड स्कूल में था, तो मैं कभी-कभी MIT AI लैब में घूमता था। यह पहले थोड़ा डराने वाला था। वहां हर कोई बहुत तेजी से बोलता था। लेकिन कुछ समय बाद मैंने तेज़ बोलने की चाल सीख ली। आपको किसी भी तेजी से सोचने की आवश्यकता नहीं है; बस हर चीज़ कहने के लिए दो बार अधिक शब्दों का उपयोग करें।
सिग्नल में इस मात्रा के शोर के साथ, यह बताना कठिन है कि जब आप अच्छे हैकरों से मिलते हैं। मैं अब भी नहीं बता सकता। आप उनके रिज़्यूमे से भी नहीं बता सकते। ऐसा लगता है कि हैकर का मूल्यांकन करने का एकमात्र तरीका है कि आप उसके साथ कुछ पर काम करें।
और यही कारण है कि उच्च-तकनीकी क्षेत्र केवल विश्वविद्यालयों के चारों ओर होते हैं। यहां सक्रिय तत्व प्रोफेसरों की तुलना में छात्रों का अधिक होता है। स्टार्टअप विश्वविद्यालयों के चारों ओर विकसित होते हैं क्योंकि विश्वविद्यालयों में वे युवा लोग एकत्र होते हैं जो वादा करते हैं और उन्हें एक ही परियोजनाओं पर काम करने के लिए मजबूर करते हैं। स्मार्ट लोग यह सीखते हैं कि अन्य स्मार्ट लोग कौन हैं, और एक साथ वे अपनी नई परियोजनाओं को तैयार करते हैं।
क्योंकि आप एक महान हैकर को केवल उसके साथ काम करके पहचान सकते हैं, हैकर खुद नहीं जानते कि वे कितने अच्छे हैं। यह अधिकांश क्षेत्रों में एक हद तक सच है। मैंने पाया है कि जो लोग किसी चीज़ में महान होते हैं, वे अपनी महानता के बारे में उतने आश्वस्त नहीं होते जितने कि वे इस बात से चकित होते हैं कि बाकी सभी लोग इतने अक्षम क्यों लगते हैं।
लेकिन हैकरों के लिए यह जानना विशेष रूप से कठिन है कि वे कितने अच्छे हैं, क्योंकि उनके काम की तुलना करना कठिन है। यह अधिकांश अन्य क्षेत्रों में आसान है। सौ मीटर में, आप 10 सेकंड में जानते हैं कि कौन सबसे तेज है। यहां तक कि गणित में भी ऐसा लगता है कि यह आम सहमति है कि कौन सी समस्याएं हल करने में कठिन हैं, और क्या एक अच्छा समाधान है। लेकिन हैकिंग लेखन की तरह है। कौन कह सकता है कि दो उपन्यासों में से कौन सा बेहतर है? निश्चित रूप से लेखक नहीं।
कम से कम हैकरों के साथ, अन्य हैकर बता सकते हैं। इसका कारण यह है कि, उपन्यासकारों के विपरीत, हैकर परियोजनाओं पर सहयोग करते हैं। जब आप किसी पर कुछ कठिन समस्याओं को नेट पर हिट करते हैं, तो आप जल्दी से सीखते हैं कि वे उन्हें कितनी कठिनाई से वापस हिट करते हैं। लेकिन हैकर अपने काम पर खुद को नहीं देख सकते। इसलिए यदि आप एक महान हैकर से पूछते हैं कि वह कितना अच्छा है, तो वह लगभग निश्चित रूप से जवाब देगा, मुझे नहीं पता। वह केवल विनम्र नहीं हो रहा है। वह वास्तव में नहीं जानता।
और हम में से कोई भी नहीं जानता, सिवाय उन लोगों के साथ जिनके साथ हमने वास्तव में काम किया है। जो हमें एक अजीब स्थिति में डालता है: हम नहीं जानते कि हमारे नायक कौन होने चाहिए। जो हैकर प्रसिद्ध होते हैं, वे आमतौर पर PR के यादृच्छिक दुर्घटनाओं के माध्यम से प्रसिद्ध होते हैं। कभी-कभी मुझे एक महान हैकर का उदाहरण देना होता है, और मुझे कभी नहीं पता होता कि किसका उपयोग करना है। पहले नाम जो मेरे दिमाग में आते हैं, वे हमेशा वे लोग होते हैं जिन्हें मैं व्यक्तिगत रूप से जानता हूं, लेकिन उन्हें उपयोग करना बेकार लगता है। तो, मैं सोचता हूं, शायद मुझे रिचर्ड स्टॉलमैन, या लिनस टॉर्वाल्ड्स, या एलेन के, या किसी प्रसिद्ध व्यक्ति का नाम लेना चाहिए। लेकिन मुझे नहीं पता कि ये लोग महान हैकर हैं या नहीं। मैंने उनके साथ कुछ पर काम नहीं किया है।
यदि हैकिंग का कोई माइकल जॉर्डन है, तो कोई नहीं जानता, जिसमें वह भी शामिल है।
संवर्धन
अंत में, हैकरों के लिए एक सवाल है जिसका वे सभी इंतजार कर रहे हैं: आप एक महान हैकर कैसे बनते हैं? मुझे नहीं पता कि क्या यह संभव है कि आप खुद को एक बना सकें। लेकिन निश्चित रूप से ऐसी चीजें करना संभव है जो आपको बेवकूफ बना देती हैं, और यदि आप खुद को बेवकूफ बना सकते हैं, तो आप शायद खुद को स्मार्ट भी बना सकते हैं।
एक अच्छे हैकर होने की कुंजी शायद इस पर काम करना है जो आपको पसंद है। जब मैं उन महान हैकरों के बारे में सोचता हूं जिन्हें मैं जानता हूं, तो एक चीज जो उनके पास समान होती है, वह है उन्हें किसी भी चीज़ पर काम करने में अत्यधिक कठिनाई होना। मुझे नहीं पता कि यह कारण है या प्रभाव; यह दोनों हो सकता है।
कुछ अच्छा करने के लिए आपको इसे प्यार करना होगा। इसलिए जिस हद तक आप हैकिंग को कुछ ऐसा बनाए रख सकते हैं जिसे आप प्यार करते हैं, आप इसे अच्छी तरह से करने की संभावना रखते हैं। 14 वर्ष की आयु में प्रोग्रामिंग के बारे में आपके पास जो आश्चर्य था, उसे बनाए रखने की कोशिश करें। यदि आप चिंतित हैं कि आपकी वर्तमान नौकरी आपके मस्तिष्क को सड़ रही है, तो शायद यह सच है।
सर्वश्रेष्ठ हैकर आमतौर पर स्मार्ट होते हैं, लेकिन यह कई क्षेत्रों में सच है। क्या हैकरों के लिए कोई विशेष गुणवत्ता है? मैंने कुछ दोस्तों से पूछा, और उन्होंने जो नंबर एक चीज का उल्लेख किया, वह थी जिज्ञासा। मैंने हमेशा सोचा था कि सभी स्मार्ट लोग जिज्ञासु होते हैं-- कि जिज्ञासा ज्ञान का केवल पहला व्युत्क्रम है। लेकिन स्पष्ट रूप से हैकर विशेष रूप से जिज्ञासु होते हैं, विशेष रूप से यह जानने के लिए कि चीजें कैसे काम करती हैं। यह समझ में आता है, क्योंकि कार्यक्रम प्रभावी रूप से यह बताते हैं कि चीजें कैसे काम करती हैं।
कई दोस्तों ने हैकरों की ध्यान केंद्रित करने की क्षमता का उल्लेख किया-- उनकी क्षमता, जैसा कि एक ने कहा, "अपने सिर के बाहर की हर चीज़ को ट्यून आउट करने की।'' मैंने निश्चित रूप से इसे देखा है। और मैंने कई हैकरों को यह कहते सुना है कि आधा बीयर पीने के बाद वे बिल्कुल भी प्रोग्राम नहीं कर सकते। इसलिए शायद हैकिंग के लिए ध्यान केंद्रित करने की कुछ विशेष क्षमता की आवश्यकता होती है। शायद महान हैकर अपने सिर में एक बड़ी मात्रा में संदर्भ लोड कर सकते हैं, ताकि जब वे कोड की एक पंक्ति को देखें, तो वे केवल उस पंक्ति को नहीं देखते बल्कि उसके चारों ओर पूरे कार्यक्रम को देखते हैं। जॉन मैकफी ने लिखा कि बिल ब्रैडली की बास्केटबॉल खिलाड़ी के रूप में सफलता आंशिक रूप से उसकी असाधारण परिधीय दृष्टि के कारण थी। "संपूर्ण'' दृष्टि का मतलब लगभग 47 डिग्री की ऊर्ध्वाधर परिधीय दृष्टि है। बिल ब्रैडली के पास 70 था; वह फर्श को देखते समय बास्केट देख सकता था। शायद महान हैकरों में कुछ इसी तरह की जन्मजात क्षमता होती है। (मैं एक बहुत घने भाषा का उपयोग करके धोखा देता हूं, जो कोर्ट को संकुचित करता है।)
यह क्यूबिकल्स के बारे में डिस्कनेक्ट को समझा सकता है। शायद सुविधाओं के प्रभारी लोग, जिनके पास कोई ध्यान केंद्रित करने की चीज नहीं है, यह नहीं जानते कि क्यूबिकल में काम करना हैकर के लिए ऐसा लगता है जैसे किसी के मस्तिष्क को ब्लेंडर में डाल दिया गया हो। (जबकि बिल, यदि ऑटिज़्म की अफवाहें सच हैं, तो वह बहुत अच्छी तरह से जानता है।)
महान हैकरों और सामान्य रूप से स्मार्ट लोगों के बीच मैंने जो एक अंतर देखा है, वह यह है कि हैकर अधिक राजनीतिक रूप से गलत होते हैं। जिस हद तक अच्छे हैकरों के बीच एक गुप्त हाथ मिलाना होता है, यह तब होता है जब वे एक-दूसरे को इतनी अच्छी तरह से जानते हैं कि वे ऐसे विचार व्यक्त कर सकते हैं जो उन्हें आम जनता द्वारा पत्थर मारने के लिए ले जा सकते हैं। और मैं देख सकता हूं कि राजनीतिक रूप से गलत होना प्रोग्रामिंग में एक उपयोगी गुण क्यों होगा। कार्यक्रम बहुत जटिल होते हैं और, कम से कम अच्छे प्रोग्रामरों के हाथों में, बहुत तरल होते हैं। ऐसी स्थितियों में, धारणाओं पर सवाल उठाने की आदत होना सहायक होता है।
क्या आप इन गुणों को विकसित कर सकते हैं? मुझे नहीं पता। लेकिन आप कम से कम उन्हें दबा नहीं सकते। तो यहां मेरी एक बेहतरीन कोशिश है। यदि यह संभव है कि आप खुद को एक महान हैकर बना सकें, तो इसे करने का तरीका यह हो सकता है कि आप अपने साथ निम्नलिखित सौदा करें: आपको कभी भी उबाऊ परियोजनाओं पर काम नहीं करना है (जब तक कि आपके परिवार को अन्यथा भूखा न रहना पड़े), और इसके बदले, आप कभी भी आधे-अधूरे काम की अनुमति नहीं देंगे। सभी महान हैकरों ने ऐसा सौदा किया है, हालांकि शायद उनमें से कोई भी इस मामले में कोई विकल्प नहीं था।
नोट्स
[1] निष्पक्षता में, मुझे कहना होगा कि आईबीएम decent हार्डवेयर बनाता है। मैंने यह एक आईबीएम लैपटॉप पर लिखा।
[2] वे वास्तव में बर्बाद हो गए। उन्होंने कुछ महीने बाद बंद कर दिया।
[3] मुझे लगता है कि यही वह है जो लोग "जीवन के अर्थ" के बारे में बात करते समय मतलब रखते हैं। इसके चेहरे पर, यह एक अजीब विचार लगता है। जीवन एक अभिव्यक्ति नहीं है; इसका अर्थ कैसे हो सकता है? लेकिन इसमें एक गुणवत्ता हो सकती है जो बहुत कुछ अर्थ की तरह महसूस होती है। एक कंपाइलर जैसी परियोजना में, आपको बहुत सारी समस्याओं को हल करना होता है, लेकिन सभी समस्याएं एक पैटर्न में गिरती हैं, जैसे एक सिग्नल में। जबकि जब आपको हल करने के लिए समस्याएं यादृच्छिक होती हैं, तो वे शोर की तरह लगती हैं।
[4] आइंस्टीन ने एक समय पर रेफ्रिजरेटर डिजाइन करने का काम किया। (उसके पास शेयर था।)
[5] यह कहना कठिन है कि कंप्यूटर की दुनिया में अनुसंधान क्या है, लेकिन पहले के अनुमान के रूप में, यह सॉफ़्टवेयर है जिसका उपयोगकर्ता नहीं होता है।
मुझे नहीं लगता कि यह प्रकाशन है जो सबसे अच्छे हैकरों को अनुसंधान विभागों में काम करना चाहता है। मुझे लगता है कि यह मुख्य रूप से इस बारे में नहीं है कि एक उत्पाद प्रबंधक के साथ तीन घंटे की बैठक करने की आवश्यकता नहीं है कि वर्ड 13.27 के कोरियाई संस्करण को टॉकिंग पेपरक्लिप के साथ एकीकृत करने में समस्याएं हैं।
[6] कुछ समान लंबे समय से निर्माण उद्योग में हो रहा है। जब आपने कुछ सौ साल पहले एक घर बनवाया, तो स्थानीय निर्माणकर्ताओं ने इसमें सब कुछ बनाया। लेकिन बढ़ती हुई, निर्माणकर्ता जो करते हैं वह किसी और द्वारा डिज़ाइन और निर्मित घटकों को इकट्ठा करना है। यह, जैसे डेस्कटॉप प्रकाशन की आगमन, लोगों को विनाशकारी तरीकों से प्रयोग करने की स्वतंत्रता दी है, लेकिन यह निश्चित रूप से अधिक प्रभावी है।
[7] गूगल माइक्रोसॉफ्ट के लिए नेटस्केप से कहीं अधिक खतरनाक है। शायद किसी अन्य कंपनी की तुलना में अधिक खतरनाक। कम से कम क्योंकि वे लड़ने के लिए दृढ़ हैं। उनकी नौकरी की सूची पृष्ठ पर, वे कहते हैं कि उनके "कोर मूल्यों'' में से एक है "बुरा मत बनो।'' सोयाबीन का तेल या खनन उपकरण बेचने वाली कंपनी से, ऐसा बयान केवल अजीब होगा। लेकिन मुझे लगता है कि हम सभी कंप्यूटर की दुनिया में पहचानते हैं कि यह किसके खिलाफ युद्ध की घोषणा है।
धन्यवाद जेसिका लिविंगस्टन, रॉबर्ट मॉरिस, और सारा हार्लिन को इस वार्ता के पहले संस्करणों को पढ़ने के लिए।