- कमर्शियल open source कंपनियां सिर्फ मौजूदा paid products के MIT license वाले विकल्प भर बनकर लंबे समय तक टिक नहीं सकतीं; open source होने की ठोस वजह या बेहतर product quality चाहिए
- गैर-लाभकारी या sponsorship-आधारित projects से अलग, open source business को hiring, growth और लगातार development जारी रखने के लिए revenue चाहिए
- शुरुआती stage की कंपनियां free tier या open source version चुनने की ओर झुकती हैं, और बड़ी कंपनियां SaaS cost को budget item की तरह संभालती हैं, इसलिए सिर्फ सस्ता होना खरीद निर्णय पलटने के लिए काफी नहीं होता
- open source वहां मजबूत होता है जहां closed source ग्राहकों के भरोसे को हिलाने वाली transparency समस्या पैदा करता है, और जहां बहुत सारे integrations व plugins की जरूरत वाली extensibility समस्या होती है
- PostHog, Medplum, SuperTokens, TableFlow, Minio, Airbyte, Elastic के उदाहरण दिखाते हैं कि open source auditability, self-hosting और community contribution के जरिए बेहतर product में विकसित हो सकता है
सिर्फ open source विकल्प होना काफी नहीं
- “Stripe Billing का open source version”, “Chargebee का open source version” जैसी व्याख्याएं product को जल्दी समझाने में उपयोगी हैं, लेकिन business को टिकाए रखने की बुनियाद के रूप में कमजोर हैं
- कमर्शियल open source tools के लिए खुद को सिर्फ पहले से सफल paid products के open source alternative के रूप में पेश करना टिकाऊ नहीं है
- किसी developer का product की नकल करके उस पर MIT license लगा देना काफी नहीं होता, और open source होना भी अपने-आप सफलता की गारंटी नहीं है
- यहां चर्चा उन commercial open source projects की है जो लोकप्रिय paid solutions से प्रतिस्पर्धा करते हैं
- React, TypeORM, VSCode जैसे community-driven या sponsorship पाने वाले products की प्राथमिकताएं अलग हैं
- React को Meta जैसी बड़ी organization का support मिलता है, और TypeORM donations से development funding जुटाता है
- ऐसे projects मूल रूप से business entities नहीं हैं
- open source company को सफल होना है तो या तो open source होने की साफ वजह होनी चाहिए, या उसे competitors से बेहतर होना होगा
सफलता का मानक उपयोग नहीं, revenue है
- donations या parent company support पाने वाले गैर-लाभकारी projects को छोड़ दें, तो सामान्य open source business का अंतिम मानक revenue है
- for-profit companies revenue के जरिए hiring, growth, sustainability और continuous development के लिए संसाधन जुटाती हैं
- free software बनाते हुए भी revenue कमाने वाली कंपनियां एक सकारात्मक उदाहरण हैं; open source companies भी ग्राहकों का अत्यधिक शोषण नहीं, बल्कि business जारी रखना चाहती हैं
- MongoDB 4,600 से अधिक कर्मचारियों वाली बड़ी database company बन गई
- बाद में उसने cloud providers को बिना project में योगदान दिए service deploy करने से रोकने के लिए SSPL license अपनाया
- SSPL को OSI approval नहीं मिला, लेकिन व्यवहार में इसे open source के काफी करीब कहा जाता है
- दीर्घकालिक सफलता मापते समय adoption और revenue में फर्क करना चाहिए
- किसी project की adoption ऊंची हो सकती है, लेकिन अगर वह revenue न बना सके तो गायब हो सकता है
- यह उम्मीद कि community project को अपने हाथ में लेकर चलाती रहेगी, उसके समर्थन में बहुत कम सबूत हैं
सस्ता होना टिकाऊ प्रतिस्पर्धी बढ़त नहीं है
- सिर्फ price-sensitive customers को target करने वाली strategy लगभग हारने वाली लड़ाई है
- Amplitude का open source version बनाने वाले एक काल्पनिक उदाहरण में यह तर्क दिया जा सकता है कि Amplitude महंगा है, शुरुआती कंपनियों पर बोझ है, और बड़ी कंपनियां भी लागत बचा सकती हैं
- लेकिन शुरुआती कंपनियां कीमत को लेकर संवेदनशील होती हैं, इसलिए उनके open source version या free tier चुनने की संभावना अधिक होती है, और यह business को संभालने के लिए काफी नहीं होता
- सस्ता alternative बनाने की strategy अक्सर भविष्य की विफलता का टिकट साबित होती है
- बड़ी कंपनियां भी आम तौर पर यह सोचकर परेशान नहीं होतीं कि Amplitude की cost से कंपनी डूब जाएगी
- contract negotiation में वे budget के भीतर price पर बात कर सकती हैं
- लेकिन ज्यादातर SaaS आखिरकार सिर्फ cost items में से एक होते हैं
- ज्यादा अहम सवाल यह हैं कि क्या यह अच्छा solution है, क्या यह लंबी अवधि तक टिकेगा, और क्या इसे manage करना आसान है
- open source solution को deploy करना management के लिहाज से जटिल हो सकता है
- अपवाद तब होता है जब किसी solution की cost पूरे budget का बहुत बड़ा हिस्सा बन जाए
- जैसे वे कंपनियां जिन्हें database usage की वजह से Oracle cost बहुत बढ़ने पर Oracle कम करना पड़ा
- लेकिन ज्यादातर open source solutions top 3 cost items को replace नहीं करते, इसलिए price का प्राथमिक निर्णय कारक बनना मुश्किल है
open source के जीतने का पहला तरीका: transparency
- open source solution खास तौर पर तब मजबूत होता है जब closed source, customer और vendor के बीच अविश्वास पैदा करने वाली transparency समस्या पैदा करे
- Amplitude के open source alternative के रूप में PostHog है
- PostHog ने Airbus, DHL, Staples जैसे ग्राहकों के साथ growth की है
- यह कई product SaaS solutions को जोड़ता है और open source के रूप में उपलब्ध है
- इसका blog source code और roadmap तक सार्वजनिक है
- PostHog analytics tool होने के नाते IP address, नाम, session recordings जैसे sensitive customer data को संभालता है, और इसी वजह से यह प्रतिस्पर्धियों की तुलना में बेहतर product की स्थिति बना पाता है
- GDPR, CCPA जैसे data regulations बढ़ने वाले माहौल में तीसरे पक्ष द्वारा ऐसे data को store करना बोझिल लग सकता है
- PostHog दो विकल्प देता है
- analytics solution को सीधे self-host करें
- या PostHog को तीसरे पक्ष के रूप में रखें, लेकिन data storage के तरीके और भविष्य में self-hosting पर जाने की प्रक्रिया में transparency बनाए रखें
- भले ही सबसे privacy-friendly तरीका self-hosting हो, कई कंपनियां फिर भी hosted model चुन सकती हैं
- तब भी वे line-by-line देख सकती हैं कि software कैसे काम करता है
- और जरूरत पड़ने पर self-hosted model में migrate करने की प्रक्रिया समझ सकती हैं
- open source companies तीसरे पक्ष की जरूरत खत्म करके नहीं जीततीं, बल्कि अपने कामकाज को public audit के लिए खोलकर भरोसा कमाती हैं
वे products जहां transparency अहम है
- Medplum बंद ecosystem वाले incumbents से प्रतिस्पर्धा करने वाला open source electronic health record platform है
- open source होने की वजह से users देख सकते हैं कि platform वास्तव में क्या support करता है और क्या नहीं
- SuperTokens, Auth0 जैसे authentication solutions का open source alternative है
- login में नाम, email, password जैसे sensitive data शामिल होते हैं
- open source होना अधिक भरोसा हासिल करने में मदद करता है
- TableFlow, Flatfile जैसे CSV import platforms का open source alternative है
- यहां import होने वाले data का sensitive होना महत्वपूर्ण है
- Minio, AWS S3 storage का open source alternative है
- S3 में screenshots या structured JSON files के जरिए customer PII store हो सकता है
- user data तक किसकी पहुंच है, इस पर ध्यान देने वाली कंपनियों के लिए Minio एक विकल्प हो सकता है
- AWS कहता है कि AWS कर्मचारी ग्राहक data को सीधे access नहीं करते, लेकिन closed source में यह दावा भरोसे का विषय बना रहता है
- Lago भी billing और product usage information संभालता है, और यह जानकारी sensitive content के करीब होती है, इसलिए open source के जरिए user trust बेहतर बनाया जा सकता है
open source के जीतने का दूसरा तरीका: extensibility
- open source की बड़ी ताकतों में से एक यह है कि यह niche features के development को community के लिए खोल देता है
- core product को आम तौर पर central engineering team maintain करती है, लेकिन integrations या plugins community developers बनाते हैं और कभी-कभी उन्हें main branch में merge भी किया जाता है
- closed source solutions को अपनी internal engineering team पर निर्भर रहना पड़ता है, इसलिए वे इसी तरह scale नहीं कर पाते
- बहुत सारी libraries, frameworks और applications से जुड़ने वाली systems बनाने वाली open source companies के लिए यह खास फायदा है
- Airbyte एक open source ELT platform है, जो community द्वारा जोड़े गए connectors की वजह से बहुत बढ़ा
- Elastic भी मूल रूप से open source रही एक बड़ी company है, जो कई data integrations देती है
- SuperTokens ने extensibility को अपनी core value proposition बनाया, और community members uncommon authentication providers के साथ integrations बना सकते हैं, जिससे सबको फायदा होता है
open source के जीतने का तीसरा तरीका: बेहतर product
- transparency और extensibility, commercial open source को लंबे समय में बेहतर product बनने में मदद करती हैं
- open source projects community feedback और मदद का उपयोग करके closed source solutions की तुलना में तेजी से विकसित हो सकते हैं
- PostHog ने Amplitude और FullStory के alternative के रूप में शुरुआत की, लेकिन बाद में LaunchDarkly और Pendo से प्रतिस्पर्धा करने वाला बड़ा व्यापक solution बन गया
- PostHog ने 15 million dollar की Series B funding जुटाई
- यह growth पिछले कुछ वर्षों में हुई, और PostHog community को इसकी प्रमुख वजहों में से एक मानता है
- open source projects सिर्फ commercial open source तक सीमित नहीं हैं; वे दशकों से product improvement की एक अहम ताकत रहे हैं
- कुछ software first-mover advantage की प्रकृति के कारण closed source ही बने रह सकते हैं
- लेकिन जिन क्षेत्रों में transparency और extensibility समस्या हैं, वहां open source latecomers वास्तविक खतरा बन सकते हैं
3 टिप्पणियां
खोजते-खोजते यह संयोग से मिला, और सोचने लगा कि English का इस तरह का शाब्दिक अनुवाद (
저렴함으로써) AI आखिर कब ठीक करेगा।आज (2026-01-12) Claude 4.5 Sonnet चलाने का परिणाम है
"Open Source सस्ता होने की वजह से नहीं जीतता"
प्रॉम्प्ट
Open Source सिर्फ़ कीमत सस्ती होने की वजह से नहीं जीतता।
Open Source की सफलता का कारण कम लागत नहीं, बल्कि कहीं और है।
Open Source कम कीमत की वजह से बढ़त नहीं बनाता।
Hacker News की राय
यहाँ profit शब्द अजीब और अस्पष्ट है
करीब 24 साल से open source/free software प्रोजेक्ट चला रहा हूँ, और उनमें से लगभग 17 साल तक revenue भी आया, लेकिन “profit” नहीं था, सिर्फ revenue था
आम तौर पर कंपनियाँ या accountants जिस तरह देखते हैं, profit वह पैसा है जो प्रोजेक्ट में शामिल लोगों के compensation और costs घटाने के बाद बचता है
इस अर्थ में profit की ज़रूरत किसी open source प्रोजेक्ट को तभी होती है जब उसने ऐसे investors से capital investment ली हो जो “return on investment” की उम्मीद करते हों; ऐसे प्रोजेक्ट हैं, लेकिन अधिकांश नहीं हैं
साथ ही, HN पर आने वाली पोस्ट जैसी ही, कुल मिलाकर यह web/SaaS पक्ष की ओर बहुत ज़्यादा झुकी हुई है। यकीन करना मुश्किल होगा, लेकिन open source प्रोजेक्ट दूसरे तरह के भी होते हैं
उस context में revenue लेने और costs चुकाने के बाद जो बचता है वह profit है, और उन costs में fixed salaries, employment contracts, payslips जैसी चीज़ें शामिल होती हैं
business profit का उपयोग कैसे करता है, यह अलग-अलग हो सकता है। उसे cash reserves के रूप में रख सकता है ताकि कम revenue वाले महीनों में भी costs चुकाई जा सकें, नए hardware जैसे assets खरीद सकता है, या extra hiring संभव कर सकता है। जितना आम लोग सोचते हैं उतना आम नहीं, लेकिन owners को dividend के रूप में भी दे सकता है
आपकी स्थिति के बारे में अधिक details नहीं हैं, इसलिए अनुमान ही लगाना पड़ेगा, लेकिन अगर आप अकेले चला रहे हैं और project इतना छोटा है कि staff बढ़ाने की ज़रूरत या इच्छा नहीं है, तो revenue असल में personal income के करीब है। कुछ महीनों में ज़्यादा मिलता है और कुछ महीनों में कम, इसलिए इस context में इसे “profit” नहीं बल्कि revenue मानना सही है
खासकर अगर यह ऐसा software है जिसमें बाकी overhead लगभग नहीं है और tax purposes के लिए cost tracking का भी बहुत मतलब नहीं है, तो और भी। हो सकता है कि आप properly books भी न रखते हों। ऐसी स्थिति हो तो समझ आता है कि लेख क्यों resonate नहीं करता। लेख काफी अलग स्थिति की बात कर रहा है
अगर pure investors लगातार returns की मांग नहीं करते, तो pressure काफी कम हो जाता है और project के लिए सही काम करना आसान होता है
लेकिन उन product क्षेत्रों में जहाँ ambitious companies से competition है, growth भी ज़रूरी है और reasonable भी हो सकती है
मंदी, opportunities और बड़े खर्चों के लिए profit बचाकर रखना सिर्फ reasonable भर नहीं है। जितने अधिक लोग और customers involved होते जाते हैं, incoming revenue को पूरा जला न देने के reasons उतने ही बढ़ते जाते हैं
असल में बड़ी companies में ये दोनों अक्सर एक-दूसरे से असंबंधित numbers होते हैं, और हर एक इस बात से define होता है कि उसे किसे communicate किया जा रहा है और उस communication पर कौन-से rules लागू होते हैं
“management profit” जैसा भी कुछ हो सकता है, जो standardized/regulated न होने वाले metrics के लिए umbrella term है। उदाहरण के लिए, कोई business tax और investor reporting purposes के लिए cash accounting से आगे निकल चुका हो, फिर भी existing management के लिए पुराने तरीके की profit definition track करना useful हो सकता है। यह आदत की वजह से हो सकता है, या इसलिए कि वह cash flow को अच्छी तरह दिखाता है या किसी और तरीके से useful है
यह postmodern समस्याओं में से एक है। SEC, IRS, bank officer “SEC profit” जैसी expression स्वीकार नहीं करते और “real” profit मांगते हैं। यह वैसा ही है जैसे कोई local politician भोलेपन से hospital से पूछे कि contractor को “सच में” कितना खर्च आया
वैसे भी लेखक SEC या IRS की तरह अपने perspective की terminology इस्तेमाल कर रहा है। जब वह कहता है “open source सस्ता होने से नहीं जीतता,” तो वहाँ “open source” MongoDB जैसे model वाले open source business को refer करता है। इसलिए investors, growth goals जैसी चीज़ें assumed हैं
लेख में भी इस बात को खुद स्पष्ट किया गया है, इसलिए semantic growling में जाने की ज़रूरत बहुत कम है
इस business model की समस्या यह है कि यह OSS version और paid version के बीच तनाव पैदा करता है
आप चाहते हैं कि OSS version अच्छा हो, लेकिन इतना अच्छा नहीं कि किसी को SaaS या consulting वगैरह के लिए पैसे देने की ज़रूरत ही महसूस न हो
यह तनाव आखिरकार इस तरफ जाता दिखता है कि साफ़ तौर पर ज़रूरी features गायब रहते हैं, या scale पर चलाने के लिए ज़रूरी features और knowledge sponsor company के monetization के लिए closed source में छिपा दी जाती है
अगर product infrastructure जैसा है, तो Elastic, Hashicorp की तरह बड़े cloud providers उसे one-click service बनाकर खा न जाएँ, इसके लिए ऐसे license में बदलना जिसे सिर्फ देखा जा सके, छुआ नहीं जा सके वाला pattern भी अब स्थापित हो चुका है
मेरा मतलब यह नहीं कि लेख गलत है, लेकिन commercial backing वाला OSS सबके लिए अच्छा kumbaya-style win-win है, ऐसा दिखावा न किया जाए। असल में यह उस structure के करीब है जहाँ startup trust बढ़ाने के लिए इसे growth hacking की तरह इस्तेमाल करता है, और जब revenue निकालने का समय आता है तो growth में मदद करने वाली community को किसी न किसी तरह कसने लगता है
एक छोटा module maintain करते हुए कई सालों तक बहुत सारी feature requests और support requests मिली हैं। जब तक इससे किराया देने लायक कमाई न हो, ऐसी चीज़ों के लिए पैसे लेने में मुझे ज़रा भी guilt नहीं है
यहाँ तक कि Pull Request merge button दबाने तक में अगर मेरा 1 सेकंड भी लगता है तो मैं charge करता हूँ। Code पर मैंने महीनों, सालों लगाए हैं और उस code को दुनिया के लिए free में release किया है
अगर extra features या मेरा समय चाहिए, तो पैसे देने होंगे
बहुत-सी companies ऐसा नहीं कर पातीं, इसका मतलब यह नहीं कि यह business model काम नहीं करता; बल्कि इसका मतलब यह है कि इसे ठीक से करना बहुत मुश्किल है
फिर भी अगर मानें कि ज़्यादातर लोग आम तौर पर अच्छे होते हैं, तो यह संभावना भी सोचने लायक है कि ऐसी companies या लोग market approach में गलती कर गए हों। यह बुरी नीयत से ज़्यादा अक्षमता हो सकती है
अगर पहले दिन से ही transparent तरीके से बता दिया जाए कि क्या हमेशा free रहेगा और क्या अंततः paid हो जाएगा, तो मैं इसे community के साथ विश्वासघात नहीं मानूँगा
बेशक शर्त यह है कि roadmap का पालन किया जाए और feedback तथा contributions के हिसाब से adjustments किए जाएँ
Paid support या extensions को वैसे भी commercial क्षेत्र में रखा जा सकता है, जहाँ software ज़्यादातर पैसा कमाता है
यह हर use case के लिए fit नहीं होगा, लेकिन इसकी ज़रूरत भी नहीं है। अधिकतर computing personal होनी चाहिए
कहा गया है कि “MinIO उन companies के लिए अच्छा alternative है जो user data तक कौन access करता है, इसकी परवाह करती हैं”, लेकिन क्या कोई company यह दावा नहीं कर सकती कि वह open source software से hosting कर रही है, जबकि असल में वही API endpoints imitate करने वाला in-house closed source software इस्तेमाल कर रही हो?
तब भी AWS जैसी ही तरह का trust चाहिए होगा
यह assume नहीं करना चाहिए कि self-hosting का मतलब high security awareness है। अधिकांश businesses में on-premises IT को HVAC या electrical setup की तरह treat किया जाता है, बस यह ज़्यादा झंझट वाला होता है
work clothes पहने कोई भी व्यक्ति reception से server room की चाबी झांसा देकर ले सकता है
इसका मतलब सिर्फ इतना है कि provider वह source code share करता है जिसके बारे में वह कहता है कि वह उसकी service के पीछे चल रहा है
भले ही वह code बिल्कुल सही हो, फिर भी उसके “official” service के पीछे चलने वाला एकमात्र code होने की संभावना कम है। और user खुद build करके उसे उनके servers पर deploy भी नहीं कर सकता
Open source का असली मतलब केवल self-hosting में होता है; वरना यह practically proprietary software से अलग नहीं है। सब कुछ provider पर trust, और संभव हो तो contract, पर निर्भर करता है
उदाहरण के लिए, अगर contract में लिखा है कि data इस open source code में जाता और बाहर आता है और कहीं और नहीं जाता, और इसे guarantee करने की procedures list की गई हैं, लेकिन वह पूरा दावा साफ़-साफ़ झूठ है, तो यह स्पष्ट और enforceable तरीके से बड़ी समस्या बन जाता है
इसे internal employees से छिपाना भी मुश्किल है, और लोग आते-जाते रहते हैं। अगर यह सच न हो तो ऐसा claim करने की संभावना कम है
लेखक स्पष्ट करता है कि वह paid products से प्रतिस्पर्धा करने वाले open source solutions की बात कर रहा है
निजी तौर पर, मुझे लगता है कि इस संदर्भ में open source “जीतता” है या नहीं, इस पर अभी फैसला नहीं हुआ है
पिछले 10 सालों में open source products बहुत बढ़े हैं, और हाल के करीब 5 सालों में उनमें से कई को open source से दूर जाते भी देखा है। MongoDB, Hashicorp stack, Elastic, Red Hat, MinIO आदि इसके उदाहरण हैं
सचमुच open source होने के साथ commercially competitive products बहुत ज्यादा नहीं बचे हैं, और उनमें से कई यह साबित करने की कोशिश कर रहे हैं कि यह एक viable business model है
कुछ हफ्ते पहले कंपनी के internal event में मैंने इसी विषय पर presentation दी थी, और कुछ हफ्तों बाद GoWest में फिर से देने वाला हूं
मूल premise यह है कि open source license सचमुच freedom देता है, लेकिन वह बाकी वे चीजें नहीं देता जिनके लिए कंपनियां पैसे देने को तैयार हों। proprietary license कंपनी की जरूरत की चीजें देता है, लेकिन freedom की कीमत पर
मेरा विश्वास है कि freedom या reliability से समझौता किए बिना बीच में काम करने वाला एक तीसरा model है। open source बने रहते हुए, कंपनियों की जरूरत वाली खाई को sponsorship से भरा जाए तो कुछ projects के लिए यह संभव हो सकता है
अभी Caddy website को इसी message के अनुरूप redesign कर रहे हैं, और उम्मीद है कि यह अच्छी तरह काम करेगा
MinIO के बारे में कहा गया “open source से दूर जाना” क्या इसी का मतलब है?
title बेवकूफाना है। जाहिर है, open source इसलिए जीतता है क्योंकि वह सस्ता है
लेखक जो कहना चाहता है वह यह है कि open source business सस्ता होने की वजह से नहीं जीतता
open source codebase हमेशा सस्ता होने की वजह से जीतता है। compression algorithms, network time daemon, media transcoder के लिए कोई पैसे नहीं देता। open source ने ऐसे markets को पूरी तरह खत्म कर दिया है
बस title literally एक शब्द की वजह से गलत है, यही चिढ़ाता है
मुझे लगा कहीं मैंने कुछ miss तो नहीं कर दिया, इसलिए शुरू के paragraphs फिर से पढ़े
technology adoption को प्रभावित करने वाले engineer के नजरिए से, open source समझ में आने योग्य होने की वजह से जीतता है
अगर मेरे colleagues और मैं source code देख सकते हैं, तो हम तय कर सकते हैं कि product अपने दावे वाले functions कर पाएगा या नहीं
इस्तेमाल के दौरान bug या unexpected use case मिले, तो कम-से-कम solution investigate करके bug report में suggest कर सकते हैं, या फिर PR भी खोल सकते हैं
इससे quick workaround बनाया जा सकता है, और आम तौर पर bug report भी की जा सकती है
companies code itself की बहुत परवाह नहीं करतीं। अगर करती भी हों तो business continuity clause closed source को लेकर अधिकतर चिंताएं कम कर सकता है
आखिर Excel के बजाय OpenOffice Calc पर कितनी financial firms switch हुई हैं?
AWS की go-to-market strategy startups और individual developers को low-cost pay-as-you-go services देकर आकर्षित करने पर निर्भर थी, और यह हिस्सा बहुत अच्छे से fit हुआ। क्योंकि Airbnb, Stripe, Twitch आदि large companies बनते हुए AWS के साथ बड़े हुए
low-cost या free से compete कर पाने वाली चीजें ज्यादा नहीं हैं। बाद में upper market में जाया जा सकता है। ARM और Intel से पूछ लीजिए
developer tools startups के लिए open source practically default go-to-market strategy बन गया है। जैसा कि लेख सही कहता है, यह business model नहीं है
इसलिए अगर आप Snowflake जितने शानदार नहीं हैं और Databricks जैसी free/open source camp से भी मुकाबला नहीं कर सकते, तो open core model बेहतर है
अगर वे खुद compile कर सकें तो वे इसे कहीं ज्यादा prefer करती हैं
अगर आप physical server पर खुद Postgres चला रहे हैं, तो investors या तो परवाह नहीं करेंगे, या यह मुश्किल सवाल पूछेंगे कि आपने कितना time waste किया। तब आपके पास काफी अच्छा जवाब या sympathetic investor होना चाहिए
vendor lock-in का जिक्र न होना हैरानी की बात है। यह open source का clear selling point है
बेशक organization और लोगों के हिसाब से अलग होता है, और अगर trusted company हो तो कई लोग lock-in की परवाह नहीं करते, लेकिन यह कभी 0 नहीं होता
Red Hat में OpenShift consultant के तौर पर काम करते समय मैंने vendor lock-in की चिंता करने वाले बहुत से executives से मुलाकात की। उनके लिए OpenShift चुनना obvious decision था
software sales के क्षेत्र से ही थोड़ा जुड़ी बात है: बहुत पहले मैंने खराब design वाले एक game के लिए user interface update बेचा था
price game itself की price से 2 गुना रखी, फिर भी लोगों ने खरीदा। क्योंकि वह professionally designed था
professional designer होने के नाते मैंने अपने main work time में से समय निकालकर वह किया था जो वह developer शायद नहीं कर पाया था
उस समय जिस digital distribution platform पर इसे बेचा जा रहा था, वहां comments में सबसे स्पष्ट complaint यह थी कि update बहुत महंगा है, और लोगों ने स्वाभाविक रूप से price positioning पर comment किया
लेकिन एक बात साफ थी। game itself बहुत सस्ता था
अगर लोग सिर्फ price की शिकायत करते हुए भी लगातार खरीद रहे हैं, तो मतलब बाकी कुछ complaint करने लायक नहीं है
पक्षी हमेशा free food चाहते हैं। पक्षियों के हिसाब से नहीं चलना चाहिए
साथ ही, वह update अवैध रूप से distribute भी हुआ और pirate users के बीच काफी फैला। चूंकि ज्यादातर customers ने पैसे दिए थे, इसलिए मुझे बल्कि खुशी हुई
यह भी साफ था कि मैं उन desired features के bundle को पूरा कर रहा था जो कहीं और उपलब्ध नहीं थे। ऐसी समस्या, इस बात के symptom के रूप में कि आपने वह बनाया है जो लोग चाहते हैं, काफी अच्छी समस्या है
कई open source projects पसंद से नहीं, बल्कि ज़रूरत के कारण open source बनते हैं
कुछ products को अपनाए जाने की थोड़ी-सी भी संभावना तभी मिलती है जब उन्हें open source बनाया जाए
लेखक कुछ चुनिंदा elite open source projects पर ध्यान दे रहे हैं, और वे ज़्यादातर open source projects का प्रतिनिधित्व नहीं करते
कुछ कंपनियों के पास सही business और सरकारी connections होते हैं, इसलिए वे product licenses आसानी से महंगे दाम पर बेच सकती हैं, लेकिन ऐसी जगहें बहुत कम हैं
ज़्यादातर लोगों और छोटी कंपनियों के पास ऐसे networks नहीं होते। सही business network न हो तो थोड़ा-सा भी पैसा कमाना मुश्किल होता है
इससे फर्क नहीं पड़ता कि product कितना अच्छा है, या वह किसी की cost कितनी घटा सकता है। कोई भरोसा नहीं करता, और कोई try भी नहीं करता। लंबे समय का फायदा बहुत बड़ा हो सकता है, फिर भी adoption barrier बहुत ऊँचा होता है
product को open source बनाना ही किसी तरह अंदर घुसने का एकमात्र तरीका है। क्योंकि इससे product के नज़र आने की बहुत छोटी-सी संभावना मिलती है, और कभी-कभी बस वही सब कुछ होता है