क्या मुझे अपनी कंपनी को open source में बदल देना चाहिए? (2022)

क्या मेरा कोड खराब है

• डेवलपर्स का अपने कोड की आलोचना होने से डरना एक आत्मकेंद्रित सोच है।
• अगर खराब कोड से कोई तनाव महसूस करता है, तो यह ऐसी चीज़ है जिस पर ध्यान देना सार्थक है।
• कम्युनिटी खराब कोड को refactor करने और नए code quality guidelines लागू करने में मदद करती है, जिससे प्रोजेक्ट बेहतर होता है।

सुरक्षा तक पहुँचना

• यह डर कि कोई सार्वजनिक कोड में security vulnerabilities ढूँढकर हैक कर लेगा, एक आम चिंता है।
• Linus's Law, कि पर्याप्त ध्यान होने पर सभी bugs स्पष्ट हो जाते हैं, security issues पर भी लागू होता है।
• Bitcoin जैसे open source प्रोजेक्ट security issues को जल्दी खोजकर patch कर सकते हैं, इसलिए वे अधिक सुरक्षित हो सकते हैं।

प्रतिस्पर्धियों को हराना

• software में ideas सस्ते होते हैं, और असली मूल्य ideas के execution से बनता है।
• ideas साझा करने से दिमाग़ मुक्त होता है और आप महत्वपूर्ण चीज़ों पर ध्यान केंद्रित कर सकते हैं।
• प्रतिस्पर्धियों का आपके कोड में झाँकना लंबे समय में महत्वपूर्ण नहीं है, और open source कम्युनिटी आपकी openness पर सकारात्मक प्रतिक्रिया देगी।

विशेषज्ञ कम्युनिटी का विकास

• एक सफल कंपनी बनाने के लिए लंबे समय तक अच्छा execution करना और customer base बढ़ाना ज़रूरी है।
• प्रतिस्पर्धियों का कोड में झाँकना लंबे समय में महत्वपूर्ण नहीं है।

बाज़ार में जीतना

• बड़े और बढ़ते बाज़ारों में winner-takes-all स्थिति कम ही होती है; users को प्रभावित करना और तेज़ी से iterate करना ज़्यादा महत्वपूर्ण है।
• भले ही कोई प्रतिस्पर्धी open source प्रोजेक्ट को fork कर ले, अगर वह आपसे तेज़ ship नहीं कर सकता, तो वह वैसे भी प्रतिस्पर्धा हार जाएगा।

बाद का चरण

• जब प्रोजेक्ट काफ़ी बड़े पैमाने पर पहुँच जाता है, तो ऐसी स्थिति आ सकती है जहाँ बड़े cloud providers बेहतर distribution model के साथ आपका product पेश करें।
• अगर AWS आपके product को host करने में आपसे प्रतिस्पर्धा शुरू करता है, तो इसका मतलब है कि आप बहुत सही काम कर रहे हैं।
• आपको developer experience जैसी उन जगहों पर competitive advantage ढूँढना चाहिए जहाँ cloud providers अच्छे नहीं होते।

चिंता छोड़ें

• अगर प्रतिस्पर्धी आपके ideas ढूँढ रहे हैं, तो वे हमेशा आपसे एक कदम पीछे रहेंगे।

डेवलपर हायरिंग

• startups की सबसे बड़ी शिकायतों में से एक यह है कि डेवलपर्स को hire करना मुश्किल है।
• open source डेवलपर hiring की समस्या हल कर सकता है।

सार्वजनिक रूप से talent ढूँढना

• सभी डेवलपर्स open source से लाभ उठाते हैं, और बहुत से डेवलपर्स दिलचस्प open source projects में योगदान देना चाहते हैं।
• अगर आप open source प्रोजेक्ट में योगदान करने की बाधाएँ कम कर देते हैं, तो बेहतरीन डेवलपर्स के उस प्रोजेक्ट तक पहुँचने की संभावना बढ़ जाती है।

नहीं, हम आपका take-home test नहीं लेंगे

• डेवलपर्स interview process में LeetCode problems हल करने या take-home tests करने को लेकर असंतुष्ट रहते हैं।
• अगर कोई आपके repository में योगदान देता है, तो आप पहले से उसके वास्तविक code contributions और team/कम्युनिटी सदस्यों के साथ उसके communication style को देख सकते हैं।

क्या यह Excel के साथ integrate होता है?

• startup चलाते समय आपके पास केवल सबसे बड़ी समस्याएँ हल करने का समय हो सकता है, और कुछ ही users द्वारा माँगी गई features अनिश्चित समय तक टल सकती हैं।
• अगर system open source है, तो ऐसे users स्वयं features contribute कर सकते हैं, जिससे software की उपयोगिता बढ़ सकती है।

यह 2022 है। flying cars कहाँ हैं?

• open source के बिना दुनिया में tech कंपनियाँ बार-बार वही wheel reinvent करती रहती हैं।
• Supabase नए projects को open source करने से पहले मौजूदा open source projects को support करने की कोशिश करता है।

मुझे और सबूत चाहिए

• अगला हफ़्ता Supabase launch week है, और यह team तथा कम्युनिटी द्वारा पिछले 3 महीनों में किए गए सभी काम का चरम बिंदु है।
• Supabase कम्युनिटी की तेज़ प्रगति इस बात का प्रमाण है कि open source कंपनी चलाने के सभी फायदे वास्तविक हैं।

GN⁺ की राय

• open source रणनीति code quality सुधारने, security मज़बूत करने, और कम्युनिटी निर्माण के ज़रिए collaboration व innovation को बढ़ावा देने में योगदान देती है।
• open source डेवलपर hiring की समस्या को हल कर सकता है, कंपनी की transparency और trust बढ़ा सकता है, और तकनीकी प्रगति में योगदान देता है।
• Supabase का उदाहरण दिखाता है कि open source मॉडल software development और business growth पर कैसे सकारात्मक प्रभाव डाल सकता है।

[GN⁺]

Hacker News राय

• मान्यताओं की समस्या

  टिकाऊ लाभप्रदता को लेकर बनाई गई मान्यताएँ वास्तविकता को ठीक से नहीं दर्शातीं। खासकर जब अमेरिकी डेवलपर्स की ऊँची सैलरी जैसी चुनौतियों को ध्यान में रखा जाए, तो open source software (OSS) कंपनियों को दो बार सफल होना पड़ता है। पहली सफलता OSS की होती है, और दूसरी कंपनी की।

• Graphistry टीम का अनुभव

  Graphistry टीम OSS को लेकर बेहद उत्साही है, और उसने लोकप्रिय Apache Arrow तथा Nvidia RAPIDS प्रोजेक्ट्स की शुरुआत में मदद की। वे Python और JS clients को OSS के रूप में देते हैं, और PyGraphistry[AI] कई तरह के tools से लैस graphs के लिए एक Swiss Army knife जैसा है। लेकिन उनकी sustainable growth मुख्य रूप से enterprise, government, और data कंपनियों को GPU graph visualization server के cloud/on-premise self-hosting licenses बेचकर होती है। वैकल्पिक SaaS hosting revenue छोटी टीम को सहारा देता है, लेकिन अधिकांश टीमें self-hosting license revenue के बिना innovation जारी नहीं रख सकतीं।

• open source business model को लेकर शिकायतें

  दूसरे founders के साथ open source business model पर चर्चा करते समय, बार-बार तीन शिकायतें सामने आती हैं:

  • code गंदा, खराब या अधूरा होने की आलोचना
  • hackers security vulnerabilities ढूँढकर उनका फायदा उठाएँगे
  • competitors intellectual property चुरा लेंगे

  चौथा छूटा हुआ बिंदु यह है: "Amazon/AWS मेरे code के आधार पर service को commercialize कर देगा और मुझे कुछ भी भुगतान नहीं करेगा।"

• अर्ध-सरकारी संस्थाओं को बेचना

  एक बात जो कई projects मिस कर देते हैं, वह है अर्ध-सरकारी संस्थाओं को बेचना। अमेरिकी सरकार के पास technology के लिए बहुत से programs हैं, और private agencies, intelligence community, तथा state governments के बँटवारे के कारण वे बड़ी मात्रा में तरह-तरह का software खरीदती हैं। regulation और compliance requirements उतनी ऊँची नहीं होतीं जितना लोग सोचते हैं, खासकर जब शुरुआती कुछ contracts टीम खुद संभाल रही हो। इससे project के लिए ठोस और सुनिश्चित revenue मिलता है, और आमतौर पर 3-5 साल की commitments के साथ यह काफी लाभदायक होता है।

• open source software का मूल्य

  software ideas सस्ते होते हैं, लेकिन value लगभग हमेशा उन ideas के execution से बनती है। जब आप open source software जारी करते हैं, तो आप सिर्फ idea ही नहीं बल्कि उस idea के execution का एक बड़ा हिस्सा भी दे रहे होते हैं। code पूरा execution नहीं है, लेकिन यह sales, marketing, support आदि तक फैलता है। लेख code की value को कम करके दिखाने की प्रवृत्ति रखता है, लेकिन यह सही नहीं है।

• Supabase का business model

  Supabase खुद को open source कंपनी के रूप में market करता है, लेकिन वास्तव में self-hosting आज़माना व्यावहारिक नहीं है। इसलिए उसे open source होने की सराहना तो मिलती है, पर वास्तव में यह सिर्फ एक marketing strategy है।

• open source products का चयन

  व्यक्तिगत रूप से मैं open source products को alternatives की तुलना में हमेशा चुनता हूँ। source code तक बिना सीमा पहुँच होना महत्वपूर्ण है, और यह समाज के लिए भी महत्वपूर्ण है। इसी mindset से बना software open source होता है, और कभी-कभी लोग इसके लिए भुगतान भी करते हैं।

• open source business की कठिनाई

  PostgreSQL, Python, Bitcoin, React जैसे open source projects अच्छे हैं, लेकिन अच्छे business नहीं हैं। MongoDB और Elastic अपवाद हैं। open source database कंपनियों की तुलना में closed-source database कंपनियाँ अधिक सफल हुई हैं। open source कंपनियाँ चलाना कठिन है, लेकिन users के लिए उनका मूल्य बहुत अधिक है।

• brand और community का महत्व

  Google जैसे स्थापित vendors के साथ प्रतिस्पर्धा करते समय, brand, community, team, और developer experience (DX) का महत्व compliance जैसी चीज़ों की तुलना में लगभग नहीं के बराबर होता है।

• open source code को सार्वजनिक करना और license

  code को सार्वजनिक रूप से उपलब्ध कराएँ ताकि लोग उसे पढ़ सकें और उसमें योगदान दे सकें। commercial use के लिए paid license माँगें, लेकिन निचले tiers में उसे free रखें। business के भीतर ऐसी संस्कृति बनानी चाहिए जहाँ paid customers ही सारे development को fund करें।

• open source कंपनी की व्यवहार्यता

  open source कंपनी तभी समझ में आती है जब कंपनी developers को target करती हो, या ऐसा product बनाती हो जिसे वास्तव में self-host करना संभव न हो। Supabase दोनों ही बातों का उदाहरण है।