क्या मुझे अपनी कंपनी को ओपन सोर्स में बदलना चाहिए? (2022)
(supabase.com)- Supabase ने शुरुआत से ही open source चुना, और public रूप से product बनाते हुए community, hiring और product expansion में उम्मीद से बड़े फायदे पाए
- मुख्य चिंताएँ code quality पर आलोचना, security vulnerabilities के उजागर होने और competitors द्वारा copy किए जाने की होती हैं, लेकिन openness सुधार में भागीदारी और तेज़ iteration भी ला सकती है
- hiring में repository contributions उम्मीदवार का असली code और collaboration style दिखाते हैं; Supabase ने 32 developers को hire करने के बाद ही outbound hiring शुरू की
- niche user features, integrations और adapters community खुद बना सकती है, जिससे product scope बढ़ता है और internal team की priority limits पूरी होती हैं
- open source company की defensibility code छिपाने से ज्यादा execution speed, brand, team और community को लंबे समय तक बनाने से आती है
Supabase ने शुरुआत से open source क्यों चुना
- Supabase पहले दिन से ही open source था, और founders PostgreSQL, Python, Bitcoin, React जैसे public projects के लंबे समय से users और supporters थे, इसलिए उस समय यह कोई कठिन निर्णय नहीं लगा
- public रूप से business बनाने पर बहुत pressure होगा, ऐसा अनुमान था, लेकिन product और company को बढ़ाने की प्रक्रिया में कई अप्रत्याशित फायदे सामने आए
- यह developer tools या PaaS company का अनुभव है, लेकिन इसकी कई बातें software companies के व्यापक संदर्भ में भी लागू हो सकती हैं
- open source में बदलने से रोकने वाली बार-बार आने वाली चिंताएँ मुख्यतः तीन हैं
- लोग messy या अधूरे code की आलोचना कर सकते हैं
- hackers security holes ढूंढकर उनका दुरुपयोग कर सकते हैं
- competitors intellectual property चुरा सकते हैं
“मेरा code खराब है” वाली चिंता
- खराब code को लेकर बेचैनी अक्सर ego का मामला होती है, और अगर कोई समय निकालकर उसे देख रहा है, तो संभव है कि उसे उसमें आगे बढ़ाने लायक कुछ मिला हो
- Stone Soup की कहानी की तरह, अच्छा idea community के साथ share करने पर दूसरे लोग उसे अपनाकर साथ में सुधार सकते हैं
- community खराब code को refactor या replace कर सकती है, और नए code quality guidelines लाकर आगे की contribution process को भी बेहतर बना सकती है
- जो toxic members code पर सिर्फ शिकायत करते हैं और improvement suggestions नहीं देते, वे शुरू से ही उस community के इच्छित सदस्य नहीं हैं
- open source contributors के पास पुराने projects की “कब्रगाह” होती है, जो मिलती-जुलती चीज़ बनाने वालों के लिए ideas और approaches की library बन जाती है
- कोई किसी खास problem-solving approach से प्रेरणा ले सकता है
- कम से कम वही गलतियाँ दोहराने में लगने वाला समय घट सकता है
- पुराने projects से reputation खराब होने की संभावना से ज्यादा संभावना यह है कि वे उपयोगी साबित हों या बिल्कुल ध्यान में न आएँ
public code और security
- public code के साथ hosted solution चलाते समय सबसे बड़ा डर यह होता है कि malicious actors code पढ़कर vulnerabilities ढूंढेंगे और service hack कर देंगे
- Supabase के अनुभव में Linus's law की यह बात कि “enough eyeballs हों तो सभी bugs shallow होते हैं” security issues पर भी लागू होती है
- शुरुआती दौर से ही security researchers, जो अक्सर anonymous होते हैं, code और platform की जाँच करते हुए potential issues खोजने में मदद करते रहे
- अगर आप SaaS देते हैं, तो
/.well-known/security.txtपर simple guidance दें, ताकि good-faith researchers जान सकें कि potential issues कैसे disclose करने हैं - public project proprietary codebase से अधिक सुरक्षित हो सकता है, इसके उदाहरण के रूप में Bitcoin दिया गया है
- Andreas M. Antonopoulos ने 2015 के lecture में कहा कि closed banking systems का software immune system कमजोर होता है
- closed systems में बड़े security holes लंबे समय तक छिपे रह सकते हैं, और अंततः exploit होने पर बड़ा नुकसान कर सकते हैं
- Bitcoin जैसे open source protocols में security holes सभी को दिखते हैं, exploits जल्दी और बार-बार मिलते हैं, फिर patch हो जाते हैं
- सफल software company 10 साल से अधिक समय में बन सकती है, इसलिए long term में open source system किसी secretive proprietary system की तुलना में अधिक सुरक्षित अवस्था के करीब पहुँच सकता है
- जब बेहतरीन security engineers को hire करने की competition बहुत तीव्र हो, तब public review की value और बढ़ जाती है
competitors और intellectual property की चिंताएँ
- software में ideas सस्ते होते हैं, value लगभग हमेशा idea के execution से बनती है
- idea को दुनिया के साथ share करने पर codebase तक कौन पहुँचेगा, इसकी चिंता करने के बजाय आप तेज़ iteration पर focus कर सकते हैं
-
experts की community बनाना
- सफल company बनाने के लिए लंबे समय, जैसे 10 साल, तक अच्छा execution करना और customer base बढ़ाना पड़ता है
- इस long-distance race में competitors को codebase देखकर मिलने वाला लाभ पूरे 10 साल के संदर्भ में शायद बड़ा न हो
- उस अवधि में codebase कई बार iterate और refactor होने की संभावना रहती है
- long term में जीतने का तरीका अपनी solution को दुनिया में सबसे बेहतर तरीके से repeatedly improve करने वाली team और community बनाना है
-
market में जीतना
- अगर बड़ा और बढ़ता हुआ total addressable market (TAM) सच में pursue करने लायक है, तो winner-takes-all situation होने की संभावना कम है
- पहले ऐसा user segment खोजें जिसे आप impress कर सकें, और तेजी से iterate करें
- competitors पर focus करने में लगा समय product या team सुधारने में लग सकता है
- अगर competitor open source project को fork करके अधिक तेजी से launch कर सकता है, तो उस competition में वैसे भी हार तय थी
- software में IP और patents को enforce करना notoriously कठिन है, इसलिए lawyers के जरिए software ideas बचाने की चिंता घटाने से समय, पैसा और mental energy बच सकती है
- business को software idea को दुनिया में सबसे बेहतर तरीके से implement करके अधिक अच्छी तरह protect किया जा सकता है
-
later-stage cloud competition
- जब project काफी scale तक पहुँचता है, तो Elastic या Mongo की तरह बड़े cloud providers stronger distribution model के साथ product offer कर सकते हैं
- अभी शुरू कर रही company की सबसे बड़ी problem पहले उस point तक पहुँचना है
- अगर AWS अपनी multi-billion-dollar product line में से किसी एक से resources हटाकर hosted product में competition करे, तो इसका मतलब है कि आप पहले से ही बहुत अच्छा कर रहे हैं
- अधिक constructive response यह है कि पहले से ऐसे areas खोजे जाएँ जहाँ आप किसी से भी competition में आगे रह सकें
- कई cloud providers का developer experience (DX) अक्सर अच्छा नहीं होता, इसलिए DX को core competency बनाया जा सकता है
- अगर 6 साल बाद Google आपका lunch छीनने की कोशिश करे, तो उससे पहले के वर्षों में आपका brand, team और community David vs Goliath जैसी fight के लिए तैयार होना चाहिए
- ऐसी स्थिति से अचानक चौंकने से बचने के लिए शुरुआत से plan करना चाहिए, और time व focus का उपयोग करके winning strategy बनाई जा सकती है
- अगर competitors ideas खोजने आएँ, तो वे हमेशा एक कदम पीछे होंगे; खासकर शुरुआती दौर में, जब resources कम होते हैं, competition की चिंता में और ज्यादा energy खर्च होने लगती है
developer hiring में असर
- startups को scale से अलग, जिन बड़े problems का सामना करना पड़ता है, उनमें से एक developer hiring की कठिनाई है
- sourcing कठिन है
- developers का assessment कठिन है
- future colleagues के स्तर के बारे में convince करना कठिन है
- open source developer hiring problem को कम करने में मदद कर सकता है
-
public sourcing
- सभी developers open source से लाभ लेते हैं, और कई developers interesting open source projects में contribute करके उस benefit को वापस देना चाहते हैं
- contribution के कारण अच्छे community, नई technology सीखना, unfamiliar codebase में कठिन technical problems हल करने का आनंद आदि हो सकते हैं
- open source project में code contribution की barrier कम करने पर अच्छे developers के project तक पहुँचने की संभावना होती है
- contributors issue discussions, bug fixes, problem identification और PR review में भाग ले सकते हैं
- सभी contributors job नहीं खोज रहे होते, लेकिन कई लोग full-time open source code पर काम करने की संभावना से आकर्षित हो सकते हैं
- Supabase ने 2 साल से अधिक operate करने और 32 developers को hire करने के बाद ही outbound hiring शुरू की
- open source Supabase का मुख्य talent discovery channel था और आगे भी रहेगा
- remote और asynchronous company में open source hiring strategy उम्मीदवार की क्षमता को खुद सामने आने देती है, जिससे उस क्षमता को verify करना आसान हो जाता है
-
LeetCode और take-home tests की जगह real contributions
- developers को अगली job खोजते समय interview process में LeetCode problems solve करने या take-home tests करने से सबसे अधिक शिकायत होती है
- ये तरीके time-consuming और थकाऊ होते हैं, और अक्सर actual work में किए जाने वाले काम को represent नहीं करते
- अगर कोई repository में contribute करता है, तो पहले से ये materials मिल जाते हैं
- remote और asynchronous environment में team और community members के साथ कैसे communicate करता है, इसके examples
- real code contribution के examples
- उम्मीदवार भी company को देख सकता है
- देख सकता है कि team code quality को महत्व देती है या नहीं
- देख सकता है कि communication प्रभावी है या नहीं
- judge कर सकता है कि अच्छे technical decisions लिए जाते हैं या नहीं
- Supabase repositories के जरिए hire हुए लोग खुद indispensable बन गए, और कुछ ने existing repositories का development lead किया या नई client libraries और SDKs शुरू किए
- उन्हें Zoom पर LeetCode problems solve करने की जरूरत नहीं पड़ी
niche user features और integrations का विस्तार
- startup बनाते समय अक्सर आपके पास सिर्फ सबसे बड़ी problems हल करने का समय होता है
- तेजी से आगे बढ़ने के लिए user base के 80% द्वारा request की गई चीज़ों पर focus करना पड़ता है {p:80}
- minority users द्वारा request किए गए features अनिश्चित समय तक पीछे धकेले जा सकते हैं
- अगर system open source है, तो ऐसे users खुद features contribute कर सकते हैं, जिससे software की usefulness बढ़ती है
- यह असर integrations और adapters में अक्सर दिखता है
- users Azure या Vercel integration चाह सकते हैं
- अगर कोई और उस connection को बनाने के लिए development resources देता है, तो project के सभी users को फायदा होता है
वही पहिया बार-बार न बनाना
- open source के बिना दुनिया में technology companies बार-बार wheel reinvent करती रहेंगी
- Supabase नए projects को open source के रूप में release करने के अलावा, नया बनाने से पहले existing open source projects को support करने की कोशिश करता है
- car companies proprietary functions, proprietary UI elements, proprietary windowing libraries, proprietary operating systems और proprietary drivers का उपयोग करके मुश्किल से दिखने वाले error messages दिखाएँ—यह developer time और effort की बर्बादी है
- Supabase Launch Week team और community द्वारा पिछले 3 महीनों में किए गए काम का collection है, और open source company चलाने के फायदे community की progress speed में दिखते हैं
- अधिक जानकारी Launch Week 4 post में देखी जा सकती है, और भाग लेने के लिए Supabase GitHub visit कर सकते हैं
1 टिप्पणियां
Hacker News की रायें
इसमें टिकाऊ profitability को लेकर एक बड़ा assumption छिपा है, और खासकर अमेरिकी developers की salaries जैसी वास्तविकताओं को देखते हुए यह असल अनुभव से कुछ हद तक मेल नहीं खाता।
संक्षेप में, किसी open source कंपनी पर बिजली दो बार गिरनी चाहिए: एक बार open source project पर, और एक बार कंपनी पर।
Graphistry टीम हर दिन open source को पसंद करती है और उस पर काम करती है; हमने Apache Arrow और Nvidia RAPIDS तक पहुँचे project की शुरुआत में मदद की, और Python/JS clients भी open source किए। PyGraphistry[AI] graphs के लिए Swiss army knife जैसा tool है, और इसमें GFQL जैसे tools भी शामिल हैं—जैसे Cypher graph query language को embeddable, dataframe-native और GPU-accelerated रूप में implement करना।
लेकिन टिकाऊ growth मुख्य रूप से enterprises, governments और data companies को GPU graph visualization server के cloud/on-premises self-hosting licenses बेचने से आती है। कई साल टिके रहने के बाद, सौभाग्य से यह business अच्छी तरह बढ़ रहा है, और सिर्फ SaaS hosting revenue से भी छोटी team चल सकती है, लेकिन team के अधिकांश हिस्से को sustain नहीं किया जा सकता। self-hosting license revenue न हो तो innovation cycle का बड़ा हिस्सा गायब हो जाएगा।
ऐसा लगता है कि यह लेख lottery जीतने जैसी किस्मत, SaaS market की प्रकृति, और technical defensibility के intersection को miss कर रहा है। Louie.AI और GFQL का launch हमारे case में open source की business viability को बदल रहा है, इसलिए मेरा मतलब यह नहीं कि यह असंभव है; लेकिन यहाँ तक पहुँचने के अनुभव को देखते हुए, यह लेख पढ़ने वाले नए founders को लेकर चिंता होती है।
[1] https://graphviz.org/
यानी असली सवाल यह है कि अगर कहा जाए “अब हम source खोल रहे हैं”, तो क्या वे customers कहेंगे, “अच्छा है, तो हम contract cancel करते हैं।”
इसमें कहा गया है, “जब open source business model पर दूसरे founders से बात करते हैं, तो तीन चिंताएँ बार-बार आती हैं: लोग गंदे, खराब या अधूरे code की आलोचना कर सकते हैं; hackers security holes ढूँढकर exploit कर सकते हैं; competitors intellectual property चुरा सकते हैं।” मुझे लगता है चौथी बात छूट गई है।
Amazon/AWS मेरे code के आधार पर service commercialize करके बेच सकता है और कुछ भी pay नहीं कर सकता।
users और feedback देने वालों से बातचीत में शिष्टता रखता हूँ, लेकिन अंदर से सोचता हूँ, “बोलना आसान है। मैंने सच में बनाया है। चुप रहो या PR भेजो।” हैरानी की बात नहीं कि ऐसे लोग लगभग कभी PR नहीं भेजते।
वास्तव में बनाते रहने का काम करते रहो, और criticize करने वालों को झाड़ दो।
[0] - https://heywillow.io/
अगर बड़ी कंपनियाँ copy करने की कोशिश कर रही हैं, तो आप पहले ही जीत रहे हैं, और इसे mitigate करने के लिए upfront plan चाहिए। हालांकि अगर मैंने लेख को सही समझा है, तो इसका मतलब है कि शुरुआती stage में यह focus करने या चिंता करने वाला issue नहीं है।
cloud companies दूसरे open source products को निगल लेती हैं क्योंकि उन products ने अपने काम को ठीक से protect करने वाले licenses नहीं चुने।
सचमुच गहराई वाला अच्छा लेख है, लेकिन एक बात बहुत से projects miss करते हैं: civilian government sector को बेचो।
अमेरिकी सरकार में NSF grants जैसे कई technical programs हैं, और civilian agencies, intelligence agencies व state governments आपस में fragmented हैं, जिससे अंततः software procurement का बहुत बड़ा landscape बनता है। regulation और compliance की entry barriers भी उतनी ऊँची नहीं हैं जितनी लगती हैं, खासकर अगर शुरुआती कुछ deals partners के साथ जीत ली जाएँ। आम तौर पर 3–5 साल की commitments के साथ projects को fund करने वाला stable और guaranteed revenue होता है, और profitability भी बेहद ऊँची होती है।
काश और open source companies इसका फायदा उठाएँ। क्योंकि अक्सर पूरी तरह private companies open source libraries को अपने products में डालकर भारी margins के साथ बेचती हैं और सब कुछ अपने पास रख लेती हैं।
उदाहरण: https://x.com/ssankar/status/1749202248700420587?s=20
सरकार में रहते हुए मैंने कई ऐसे software देखे जो असल में open source maps + open source DB का combination थे, लेकिन कीमत 12 million dollars थी। दूसरे benchmarks में PDF OCR पर 2 million dollars प्रति वर्ष, और weights & biases जैसे tools पर 30 million dollars प्रति वर्ष भी देखा।
software distribution के अलावा भी incentives हैं। उदाहरण के लिए किसी खास bug या security flaw को priority से fix कराना। intelligence agencies ने safetensors के लिए शायद काफी पैसा दिया होगा।
Supabase के लिए चार रास्ते हो सकते हैं: Cybercom को direct sales, DOS को direct या team contract, VA को PWS के ज़रिए sale, या बड़े government contract software vendors को direct sale।
execution का तरीका है GS 14/15 या समकक्ष को cold email भेजना, या किसी पूर्व GS15 को hire करना, या SAM.gov पर उपयुक्त bids ढूँढकर GovPro.ai के साथ full-service तरीके से और rogue के साथ खुद संभालकर proposals बनाना।
जब तक government bureaucracy contract को final approval देती है, तब तक ज्यादातर startups के पैसे खत्म हो चुके होने की संभावना होती है।
contracts profitable हो सकते हैं, लेकिन bureaucratic process बहुत भारी होता है और इसे handle करने का अनुभव रखने वाला व्यक्ति चाहिए। यह रास्ता सबके लिए नहीं है, और इसमें काफी time और negotiation लगती है।
विशाल bureaucracy को छोड़ भी दें, तो federal government सबसे बड़ी, सबसे धीमी और सबसे कठिन government organization है। सिर्फ अमेरिका में ही schools, cities, counties, states, water/fire districts, libraries आदि जैसे दसियों हजार अन्य government entities हैं।
अगर public sector में जाना है, तो सबसे बड़े target पर all-in करने के बजाय छोटे और व्यापक तरीके से approach करना बेहतर है।
दुनिया का सबसे profitable government sector U.S. Department of Defense है।
लेकिन Department of Defense अविश्वसनीय रूप से bureaucratic, schedule-sensitive और secrecy-obsessed है।
Supabase का बिज़नेस मॉडल खुद को open source कंपनी के रूप में market करना है, लेकिन असल में सही दिमाग वाला कोई भी व्यक्ति इसे production के लिए खुद host करने की कोशिश नहीं करेगा
इसकी वजह है थोड़ी-थोड़ी अधूरी documentation, subtle bugs, और हल्की-सी छूटी हुई अहम functionality जैसी चीज़ें। इसलिए open source होने की तारीफ़ तो मिलती है, लेकिन व्यवहार में यह practical नहीं है; मुझे यह बस marketing tool लगता है
पहला है मन की शांति। भले ही आप अभी खुद host न करें, अगर service पसंद न आए तो निकलने का एक और रास्ता रहता है। बेशक raw data access भी देना चाहिए
दूसरा है code quality। अगर आपने ऐसा code संभाला है जो ऊपर से ठीक चलता दिखता है लेकिन अंदर से वाकई खराब है, तो आप समझेंगे कि publicly दिखाने लायक code होना कितना अहम है
तीसरा है योगदान की संभावना। पहले मुझे यह कोई बड़ी बात नहीं लगती थी, लेकिन कई बार अनुभव करने के बाद लगा कि feature missing हो, bug हो, performance issue हो, तो request कर पाना या खुद contribute कर पाना बहुत मायने रखता है। ज्यादातर closed-source projects में तो feature request के लिए transparent channel होना भी किस्मत की बात होती है
किसी threshold के बाद लोग fork में मेहनत लगाने का फैसला कर सकते हैं। MariaDB इसका उदाहरण है
कुछ लोगों ने सीधे कहा था कि वे हमारी कंपनी की managed service इसी वजह से भरोसे के साथ इस्तेमाल करते हैं
वैध और असली open source कंपनी बनना कहीं आसान लगता है
अगर आपका मतलब यह नहीं था और मैंने गलत पढ़ा, तो बाकी बातों से तो Supabase बहुत सकारात्मक दिखता है
व्यावसायिक रूप से यह संभव न भी हो, लेकिन मौजूदा स्थिति open source software से अपेक्षित standards को बहुत कमजोर कर रही है, और जिन कंपनियों ने यह तरीका चुना है उन्हें भी कोई साफ long-term फायदा दिखता नहीं
यह developers को, भले वे खुद run न करें, असल में चल रहे code को देखने देता है
Supabase भी अच्छा है, commercial open source सामान्य तौर पर भी अच्छा है, और लेख के कई हिस्सों से सहमत हूं
लेकिन “software में ideas सस्ते होते हैं। value लगभग हमेशा ideas के execution से बनती है” वाला हिस्सा थोड़ा अजीब लगा
यह expression मैंने “मेरे पास शानदार startup idea है, बताने से पहले NDA sign करोगे?” जैसी situations में सुना है
लेकिन अगर आप software को open source में जारी करते हैं, तो आप सिर्फ idea नहीं दे रहे होते, बल्कि उस idea का काफी बड़ा executed परिणाम भी दे रहे होते हैं
बेशक code execution का पूरा हिस्सा नहीं है; यह sales, marketing, support आदि तक फैलता है। फिर भी यह लेख code की value को बहुत हल्के में लेता है और संकेत देता है कि sales/marketing वगैरह के बिना यह बेकार है, जो मुझे सच नहीं लगता
value बांटनी हो तो मैं इसे करीब sales/marketing/customer validation 90%, code 10% मानूंगा। मैं 7-figure के शुरुआती revenue वाला bootstrapped SaaS चला रहा हूं, और कह सकता हूं कि code आम तौर पर बिखरा हुआ है और लगातार evolve होता रहता है
घर को मुफ्त में copy नहीं किया जा सकता, लेकिन software को किया जा सकता है
developers को पैसे code बनाने की प्रक्रिया और दिखाई न देने वाली छोटी-छोटी problems को हल करने के लिए मिलते हैं
इसी वजह से software बेचना इतना profitable है। अगर आप software नहीं बेचते, तो उससे पैसा नहीं कमा सकते। Software हमारी साझा reality की physical चीजों जैसा नहीं है
मेरे लिए मुख्य सवाल यह नहीं कि code काफी अच्छा है या competitor नकल करेगा, बल्कि यह है कि क्या sustainable business बनाने लायक पैसा कमाया जा सकता है
जिन open source projects को quote किया जाता है और प्यार मिलता है, वे अच्छे businesses नहीं हैं: PostgreSQL, Python, Bitcoin, React
Mongo और Elastic शानदार हैं, लेकिन exceptions हैं। सफल closed-source database companies, open source database companies से ज्यादा हैं
Open source company बनाना कठिन है। लेकिन users के लिए यह बहुत valuable है
कौन सा license “open source” है, इस बहस को छोड़ दें, तो अहम बात यह है कि इन companies ने माना कि व्यापक रूप से इस्तेमाल होने वाले (A)GPL, Apache, MIT जैसे licenses competitors को managed/hosting services बनाने और scale पर compete करने की काफी गुंजाइश देते हैं। उदाहरण के लिए Amazon के OpenSearch ने ElasticSearch को सस्ते में उपलब्ध कराया
[1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
लगता है यह सवाल “क्या हमारी कंपनी को software का source public करना चाहिए?” के अर्थ में इस्तेमाल हुआ है
लेकिन मेरे लिए मूल सवाल का जवाब देना, बदले हुए सवाल का जवाब देने का रास्ता देता है। मूल सवाल कंपनी द्वारा बेचे जाने वाले software का नहीं, बल्कि इस्तेमाल किए जाने वाले software की प्रकृति का है
निजी तौर पर, अगर विकल्प हो तो मैं हमेशा open source product चुनूंगा। support cost देने या project को donate करने के लिए भी तैयार रहूंगा। Source को freely देख पाने की access, ऐसे software में भी fundamentally important है जिसे मैं कभी modify करने का इरादा नहीं रखता
मुझे पता है कि बहुत लोगों को यह extreme position लगेगी। लेकिन मुझे यह विचार पसंद नहीं कि microwave, door handle, या transmission को खोलकर देखा ही न जा सके। हो सकता है मैं उसे वापस ठीक से assemble न कर पाऊं, लेकिन शायद कोई टूटा gear ढूंढकर 90 dollar replacement के बजाय 2 dollar repair कर दूं। या transmission वाला Frankenstein microwave बना दूं
Web server की functionality बढ़ाना या यह समझना कि मेरा plugin host app को crash क्यों कर रहा है, मेरे लिए महत्वपूर्ण है। मुझे लगता है समाज के लिए भी महत्वपूर्ण है। इसलिए मैं अपने open source extremism से चिपका हुआ हूं। अगर built-in AI के साथ 5KB में HTTPS/4 संभालने वाला आधुनिक ultra-tiny web server दिखा दें तो दिलचस्पी जरूर होगी, लेकिन अगर वह open source नहीं है, तो मैं existing stack ही इस्तेमाल करता रहूंगा
इसी mindset की वजह से मैं जो software बनाता हूं वह open source होता है, और कभी-कभी लोग उसके लिए भुगतान भी करते हैं
“अगर 6 साल बाद Google आपका लंच चुराने की कोशिश करे, तो आपके पास एक ऐसा brand, team और community होनी चाहिए जो पिछले कुछ सालों से David बनाम Goliath की लड़ाई की तैयारी कर रही हो” वाले हिस्से पर, मेरे अनुभव में procurement वालों के लिए brand, community, team, developer experience जैसी चीज़ें compliance की तुलना में लगभग कोई मायने नहीं रखतीं
खासकर अगर आप Google जैसे मौजूदा supplier से सीधे टकरा रहे हों
Supabase के मामले में यह सटीक बात है, क्योंकि वास्तव में वे पिछले कुछ वर्षों से ऐसी requirements पूरी करने के लिए SOC2, HIPAA, GDPR जैसी compliance तैयार कर रहे हैं
हमारा product भी इस समस्या पर सोचता रहा है। किसी दिन हम इसे पूरा MIT या Apache में से उस समय जो license पसंद आए, उसके तहत open source कर देंगे, और यह बात site पर भी public कर रखी है। यह AGPL या open core जैसा model नहीं है
लेकिन मुझे लगा कि ऐसी structure में product से पैसा कमाना पूरी तरह असंभव है, और पिछले अनुभव में भी ऐसा ही था। Consulting संभव है, लेकिन product अलग चीज़ है। Supabase ने भारी venture funding ली है, और लगभग हर “बड़ा” open source project भी ऐसा ही है
अगर आप bootstrapped हैं, खासकर किसी महत्वाकांक्षी और कठिन project में, तो आप काफी समय तक bills नहीं भर पाएंगे। लोग मुफ्त में काम कर सकने की अवधि सीमित होती है, और private code पर एक छोटी team लगातार closely communicate करे तो सफल open source project के लिए जरूरी overhead घटाकर बहुत तेज़ी से आगे बढ़ सकती है
मैं ऐसे project के उदाहरण सुनना चाहूंगा जो similar scale का हो, investment $0 हो, पिछले 5 सालों में शुरू हुआ हो, full-time team members 2 या उससे ज़्यादा हों, 3 साल से ज़्यादा चला हो, और अभी भी इस approach की recommendation करता हो। जानना चाहूंगा कि वे अपनी livelihood कैसे चला रहे हैं। मुझे लगता है Redis जैसा काम अब नहीं होता। कम से कम मैंने तो नहीं देखा। यहां तक कि langchain जैसा simple project भी करोड़ों डॉलर की venture funding लेता है, जबकि मुझे लगा था कि ऐसा project तो कुछ लोगों की team कई revenue streams से पैसा कमाते हुए कर सकती है
मेरा सारा software public domain में, यानी free software के रूप में release होता है, लेकिन उनमें से कोई भी successful open source project या community नहीं बना। Free software सबसे पहले ideology है, उसके बाद practice या feature
किसी company को open source बनाना मेरे हिसाब से समझ में नहीं आता, जब तक कि वह developers को target न करती हो, या ऐसा product न बना रही हो जिसे realistically कोई खुद host नहीं करेगा
Supabase इन दोनों का representative example है। बाद वाले का example Plausible Analytics है, जिसे खुद host किया जा सकता है। मैं भी Coolify.io से ऐसा कर रहा हूं। लेकिन अगर आप releases से updates लाकर merge करने वाला अपना CI/CD system नहीं बनाते, तो updates miss हो जाएंगे