RethinkDB: हम क्यों बंद कर दिया

लेख का अनुवाद लेखक की अनुमति से प्रकाशित किया गया था।

जब हमने घोषणा की कि RethinkDB बंद हो रहा है, तो मैंने मरणोपरांत आलोचना लिखने का वादा किया। मुझे अनुभव पर पुनर्विचार करने में कुछ समय लगा, और अब मैं इसे स्पष्ट रूप से बता सकता हूं।

HN चर्चा सूत्र में, लोगों ने कई कारणों का वर्णन किया कि क्यों RethinkDB विफल रहा है, मानव प्रकृति के अकथनीय विकृति से लेकर, MongoDB विपणक की चालाक निर्माण और बाजार में प्रवेश करने के लिए तैयार एक अनुभवी टीम का निर्माण करने में विफलता, 64-बिट फ्लोट से बड़े संख्यात्मक प्रकारों के समर्थन की कमी के साथ समाप्त हुई। मैंने उन असफलताओं के कारणों की सूची पर टिप्पणियों को संक्षेप में प्रस्तुत किया है जो सुझाए गए हैं।

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

पीछे देखते हुए, मैं निष्कर्ष निकालता हूं कि दो चीजें गलत हो गईं - हमने एक कठिन बाजार चुना और उपयोगकर्ता के लिए उपयोगिता के गलत मानदंडों के अनुसार उत्पाद को अनुकूलित किया। इन त्रुटियों में से प्रत्येक ने परिमाण के एक या दो आदेशों द्वारा शायद RethinkDB के मूल्य को कम कर दिया। इसलिए, अगर हमने इन दो चीजों में से एक को सही ढंग से किया, RethinkDB MongoDB के आकार तक पहुंच गई होगी, और अगर हमें दोनों चूक का एहसास हुआ था, तो हम अंततः Red Hat [1] के आकार तक पहुंच गए होंगे।

कठिन बाजार

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

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

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

यह पता लगाने के लिए कि यह अन्य कंपनियों को कैसे प्रभावित करता है, MongoDB (लगभग $ 1.6 बिलियन ~ 700 कर्मचारी) और डॉकर (लगभग $ 1 बिलियन ~ 300 कर्मचारियों की कीमत) को देखें। दोनों कंपनियां अपने बाजारों पर पूरी तरह से हावी हैं। आम तौर पर स्वीकार किए गए दो नियमों के अनुसार, बढ़ती निजी सॉफ्टवेयर कंपनियों का अनुमान वार्षिक आय से दस गुना है, और प्रति कर्मचारी आय लगभग $ 200 हजार / वर्ष है। जिसका अर्थ है कि MongoDB का वार्षिक राजस्व लगभग $ 140- $ 160 मिलियन है और डॉकर का वार्षिक राजस्व लगभग $ 60- $ 100 मिलियन है।

यह बहुत अच्छा लग रहा है जब तक हम बाजारों में प्रचलित बी 2 बी टेक कंपनियों को नहीं देखते हैं जो विकास उपकरण बाजार नहीं हैं। SalesForce, Palantir या Box (जो कड़ी प्रतिस्पर्धा का सामना करते हैं) जैसी कंपनियां। और अचानक, MongoDB और Docker छोटे लगने लगते हैं।

हालांकि ये बेहद सफल कंपनियां हैं। यदि साझेदारी, वितरण अवसंरचना और प्रभावशाली खातों तक पहुंच रखने वाली अपेक्षाकृत स्थापित कंपनियां विकास की चुनौतियों का सामना करती हैं, तो स्टार्टअप के लिए इसका क्या मतलब है जो अंकुरण की प्रक्रिया में है?

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

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

गलत उपयोगिता मानदंड

ठीक है, बाजार खराब है, लेकिन विकास उपकरण में शामिल अन्य कंपनियां अभी भी बड़ी मात्रा में बेचती हैं। क्यों नहीं RethinkDB?

यद्यपि हम बाजार की गतिशीलता के साथ कुछ नहीं कर सकते थे (कुछ और करने के अलावा), उत्पाद निर्णय पूरी तरह से हमारे ऊपर थे। हम एक सुंदर, विश्वसनीय और सुंदर उत्पाद बनाना चाहते थे, इसलिए हमें निम्नलिखित मीट्रिक के लिए अनुकूलित किया गया।

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

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

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

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

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

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

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

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

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

बादल के बारे में क्या?

कई लोगों ने सुझाव दिया कि हमें क्लाउड सेवा बनाने की आवश्यकता है। हमारे पास वास्तव में विकास में एक ऐसी परियोजना थी, इसलिए यह एक दिलचस्प विषय है जिसे मैं कवर करना चाहूंगा।

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

हमारा तर्क इस प्रकार था। एक डेटाबेस प्रस्ताव का मतलब तीन चीजों में से एक हो सकता है: प्रबंधित होस्टिंग, एक सेवा के रूप में एक डेटाबेस (DBaaS), या सेवा के रूप में एक उन्नत मंच (PaaS)। आइए घुटने पर लिखे गए मार्केटिंग विश्लेषण पर लौटते हैं, जहां हमने वार्षिक राजस्व में $ 200 हजार / कर्मचारी के पैरामीटर का उपयोग किया है, वही नियम जो हमने पहले इस्तेमाल किया था:

	प्रबंधित होस्टिंग	DBaaS	PaaS
कंपनी	कम्पोज़.आईओ, mLab	FaunaDB	पार्स, फायरबेस, उल्का
स्टाफ़	~ ३०	~ ३०	~ ३०
कमाई	<$ 10M	<$ 10M	<$ 10M

ये बाजार डेटाबेस मार्केट के मुकाबले छोटे, छोटे भी हैं। हो सकता है कि आपको उनमें से किसी एक को पसंद करना चाहिए था?

प्रबंधित होस्टिंग मूल रूप से लोगों के लिए AWS डेटाबेस को बनाए रखने के होते हैं। इन सेवाओं का उपयोग करने का एक विकल्प अपना स्वयं का AWS डेटाबेस बनाना है। यह एक दर्द है, लेकिन यह इतना मुश्किल नहीं है। इसलिए, प्रबंधित होस्टिंग सेवाओं का मूल्यांकन कैसे करें, इस पर गंभीर प्रतिबंध है। इस तथ्य को देखते हुए कि Compose.io और mLab, MongoDB की पेशकश करते हैं, जिसमें RethinkDB की तुलना में अधिक ग्राहकों का परिमाण है, हमने यह माना कि प्रबंधित होस्टिंग के प्रस्ताव का अधिक प्रभाव नहीं होगा।

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

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

इसलिए, हमने क्षितिज का विकास किया और क्षितिज क्लाउड पर काम करना शुरू कर दिया, जिसके साथ उपयोगकर्ताओं को RethinkDB / GHz अनुप्रयोगों को तैनात करने और स्केल करने का अवसर मिलेगा। एक बहुत छोटी टीम के साथ तीन बड़ी परियोजनाओं (रैथिनबीडी, क्षितिज और क्षितिज क्लाउड) के विकास ने अंततः हमें पछाड़ दिया, और हम पैसे से बाहर भागने से पहले अभी भी क्लाउड सेवा जारी नहीं कर सके। हालांकि, विकास टीम का सम्मान। वे बहुत, बहुत करीब थे।

मेटा सवाल

मूल कारणों के विश्लेषण का एक और स्तर है जिसे हम इंगित कर सकते हैं। हमने गलत बाज़ार क्यों चुना और गलत मेट्रिक्स के अनुसार उत्पाद का अनुकूलन किया?

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

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

क्या हम इन गलतियों से बचने के लिए कुछ कर सकते हैं? इससे अधिक नहीं कि मैं उस रेडियो वाले बच्चे के रूप में कर सकता था। हमें एहसास नहीं था कि हम अक्षम थे, और इस अक्षमता को सचेत होने में कई साल लग गए।

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

अलविदा विचार

कई लोग डेवलपर टूल के लिए बाजार के बारे में नाराज हैं। डेवलपर्स डेवलपर्स के लिए उपकरण बनाना पसंद करते हैं, इसलिए वे वास्तव में ऐसी कंपनियां चाहते हैं जो डेवलपर्स को पनपने के लिए उपकरण बनाते हैं।

मैं इस बाजार को पूरी तरह से छोड़ना नहीं चाहता हूं - आंशिक रूप से क्योंकि मैं एक अनुभव के आधार पर सामान्यीकरण नहीं करना चाहता हूं, और आंशिक रूप से क्योंकि मुझे यह कहना पसंद नहीं है कि "यह करना असंभव है" और आंशिक रूप से क्योंकि काफी कुछ अपवाद हैं। GitHub, MongoDB, और Docker ने प्रभावशाली कंपनियां बनाई हैं। GitLab और Unity भी अच्छा कर रही हैं।

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

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

मैं तीन प्रमुख बिंदुओं को समाप्त करूंगा जो याद रखने योग्य हैं। यदि इस लेख से कुछ याद रखने योग्य है, तो यह इसको याद रखने योग्य है:

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

[१] इन संख्याओं को बहुत अधिक न पढ़ें। मैंने बहुत मोटा अनुमान दिया, लेकिन अभी भी इन त्रुटियों की कीमत का एक सामान्य विचार देना था।

[2] , , , , , , .