Rug Pull, Fork, और Open Source सामंतवाद

• ओपन सोर्स ecosystem में power dynamics कंपनी, डेवलपर और यूज़र के बीच कैसे काम करती है, और इसे हिलाने वाली rug pull (relicensing) और fork जैसी रणनीतियों का क्या असर होता है, इसका एक संक्षिप्त विश्लेषण
• बड़े cloud providers के भारी प्रभाव के बीच, single-company केंद्रित प्रोजेक्ट relicense करके power को फिर से बाँट सकते हैं, और इसके जवाब में fork उभरते हैं
• केस स्टडी में Elasticsearch→OpenSearch, Terraform→OpenTofu, Redis→Valkey, Puppet→OpenVox आदि में अलग-अलग तरह की community reshaping और contributor migration दिखाई देती है
• CLA अपनाना, single-company control, foundation में हस्तांतरण का समय आदि को rug pull के risk signals के रूप में पेश किया गया है, और neutral governance तथा multi-organization contributor base को response strategy के रूप में सुझाया गया है
• निष्कर्षतः relicensing cloud पर अंकुश लगाने का साधन हो सकता है, लेकिन इससे contributors की शक्ति भी साथ में कमज़ोर होती है, जबकि fork की संभावना कंपनियों के निर्णयों पर रोक लगाने वाली शक्ति की तरह काम करती है

---

Open Source के भीतर power structure, rug pull और fork

• ओपन सोर्स software ecosystem में बड़ी कंपनियाँ, छोटी-मध्यम कंपनियाँ, contributors और users सभी अपने-अपने तरीके से software की दिशा और revenue structure को प्रभावित करने की शक्ति का उपयोग करते हैं
• खास तौर पर बड़े cloud provider काफी ताकतवर हो जाते हैं, और वे छोटी कंपनियों या community की तुलना में बढ़त हासिल करने की प्रवृत्ति रखते हैं
• ऐसी स्थिति में डेवलपमेंट कंपनी या प्रोजेक्ट की मालिक कंपनी software license बदलकर (rug pull), या इसके उलट community या दूसरी company fork करके power shift पैदा करती है

Power dynamics और रणनीतियों का अवलोकन

• ओपन सोर्स दुनिया में बड़े cloud provider सबसे मजबूत channel और distribution power का इस्तेमाल करते हैं, जिससे छोटी कंपनियों, contributors और users के शोषण जैसी संरचना बनती है
  • सामंतवाद के दौर में ज़मीन पर नियंत्रण की तरह, cloud provider open source software को service के रूप में पेश करते हैं लेकिन contribution से बचते हैं
  • ज़्यादातर development का काम छोटी कंपनियाँ करती हैं, लेकिन cloud provider के free use की वजह से वे कमजोर स्थिति में रहती हैं
• Rug pull रणनीति के तहत छोटी कंपनियाँ software को relicense करके cloud provider का मुकाबला करती हैं, लेकिन इससे contributors और users को और अधिक नुकसान होता है
  • cloud provider प्रोजेक्ट को service में बदलते हुए contribution नहीं करते, जिससे छोटी कंपनियों की शक्ति घटती है
  • relicensing से users को नुकसान होता है, लेकिन fork के ज़रिए power balance को फिर से समायोजित किया जा सकता है
• single-company driven प्रोजेक्ट में rug pull risk अधिक होता है, इसलिए company की reputation का आकलन ज़रूरी है, लेकिन acquisition या bankruptcy की स्थिति में यह बेकार साबित हो सकता है
  • investors के दबाव में revenue बढ़ाने के लिए relicensing की जाती है, खासकर cloud provider से प्रतिस्पर्धा के समय यह अधिक दिखता है
  • अधिक restrictive license के ज़रिए दूसरी कंपनियों के monetization को कठिन बनाकर power shift की कोशिश की जाती है
• rug pull से पैदा हुआ fork एक विद्रोही collective action की तरह power वापस पाने का साधन है, लेकिन लोगों और संसाधनों की कमी के कारण इसके विफल होने का जोखिम बड़ा होता है
  • बड़ी कंपनियाँ या cloud provider संसाधनों के बल पर fork को support कर सकते हैं, लेकिन लोकप्रिय fork हमेशा सफल नहीं होते
  • MongoDB या Sentry जैसे उदाहरण भी हैं जहाँ fork नहीं हुआ, जबकि Perforce द्वारा Puppet के अधिग्रहण के बाद development को private करने से OpenVox fork शुरू हुआ

प्रमुख मामलों की तुलना

Dawn Foster ने विभिन्न rug pull, fork और उसके बाद के प्रभाव को data के आधार पर विश्लेषित किया। (Jupyter notebook dataset के रूप में कुछ परिणाम सार्वजनिक किए गए)

• Elasticsearch → OpenSearch
  • 2021 में Elastic की SSPL relicensing के बाद AWS ने OpenSearch fork संगठित किया
  • Elastic में internal contributors का अनुपात fork के पहले और बाद में बहुत नहीं बदला, जबकि OpenSearch में Amazon-led contributions जारी रहीं
  • विश्लेषण के अनुसार 2024 में Linux Foundation में हस्तांतरण के बाद भी external contributions में तेज़ बढ़ोतरी नहीं देखी गई
• Terraform → OpenTofu
  • 2023 में HashiCorp के BSL परिवर्तन के तुरंत बाद OpenTofu को Linux Foundation के तहत शुरू किया गया
  • Terraform में अब भी company-centered contribution बना रहा, लेकिन OpenTofu में कई कंपनियों के नए contributors तेज़ी से आए
  • यह मामला दिखाता है कि user-led fork + neutral foundation launch एक active community बनाने में मददगार रहा
• Redis → Valkey
  • 2024 में Redis के SSPL परिवर्तन के तुरंत बाद कई मौजूदा external contributors Valkey की ओर चले गए
  • Redis fork से पहले external contribution ratio अधिक होने वाला एक अपवादात्मक मामला था, लेकिन fork के बाद external contribution 0 तक गिर गया, जबकि Valkey कई कंपनियों के गठबंधन वाले community के रूप में शुरू हुआ
• Puppet → OpenVox
  • Perforce के अधिग्रहण (2022) के बाद development और release को private किया गया और release frequency कम हुई, जिसके जवाब में community ने OpenVox fork आगे बढ़ाया

Data observations और metrics

• rug pull के बाद GitHub forks की संख्या में तेज़ उछाल अक्सर देखा जाता है, और इसे hard fork पर विचार की गतिविधि का एक proxy signal माना जाता है
  • लंबी अवधि में original और fork साथ-साथ आगे बढ़ते दिखाई देते हैं, लेकिन विश्लेषण बताता है कि relicensed original का usage घटने की प्रवृत्ति देखी जाती है
• foundation umbrella के तहत launch नए प्रोजेक्ट की शुरुआती अवस्था में contribution आकर्षित करने में मददगार होता है, लेकिन बाद में transfer का असर सीमित हो सकता है
  • OpenSearch का मामला दिखाता है कि सिर्फ transfer कर देने से external contributions में तेज़ बढ़ोतरी की गारंटी नहीं होती

Risk signals और guidelines

• CLA(Contributor License Agreement) का उपयोग company के हाथ में relicensing authority को केंद्रित करता है, जो power imbalance बढ़ने का संकेत है
  • DCO(Developers Certificate of Origin) आधारित प्रोजेक्ट अपेक्षाकृत rug pull risk कम रखने की प्रवृत्ति दिखाते हैं
• governance review ज़रूरी है, और single-company control तथा leadership concentration जोखिम कारक हैं
  • neutral foundation, multi-organization leadership, और external contributor base वाले प्रोजेक्ट sustainability के लिहाज़ से अधिक अनुकूल हैं
• contributor base की चौड़ाई और गहराई भी मूल्यांकन का एक महत्वपूर्ण बिंदु है
  • कंपनियों को जिन प्रोजेक्ट्स पर वे निर्भर हैं उनमें सीधे contributors भेजकर influence और sustainability दोनों मज़बूत करने चाहिए
  • CHAOSS की metrics और practitioner guides का उपयोग प्रोजेक्ट की health diagnosis और improvement के लिए किया जा सकता है

Community और governance पर सुझाव

• neutral governance structure की ओर बढ़ना और external contributors बढ़ाना rug pull को रोकने का एक व्यावहारिक साधन है
  • fork की संभावना खुद ही कंपनियों के relicensing निर्णय की लागत बढ़ाकर deterrent की तरह काम करती है
• Hazel Weakly द्वारा सुरक्षात्मक उपायों पर पूछे गए सवाल के जवाब में वक्ता ने Valkey और OpenTofu की सफलता को relicensing पर पुनर्विचार कराने वाले वास्तविक उदाहरण के रूप में बताया
  • Dirk Hohndel ने ज़ोर दिया कि अधिक external contributors को आकर्षित करना rug pull risk बढ़ाकर management decision की risk को बड़ा बनाता है

निष्कर्ष

• बड़े cloud operators के प्रभाव बढ़ने के साथ ओपन सोर्स ecosystem धीरे-धीरे सामंतवादी संरचना में बदलता दिख रहा है
• license change cloud कंपनियों की ताकत को सीमित करता है, लेकिन इस प्रक्रिया में community contributors की शक्ति कम होने का दुष्प्रभाव भी पैदा होता है
• लेकिन contributors और users के पास 'fork' जैसा जवाबी साधन मौजूद है, और यही ओपन सोर्स की वह अलग ताकत है जो सामंतवाद से इसे अलग बनाती है
• fork की वास्तविक संभावना कंपनियों की भविष्य की नीतिगत निर्णय-प्रक्रिया को प्रभावित करती है, और Valkey, OpenTofu जैसी सफलताओं से प्रेरित होकर कुछ कंपनियों ने rug pull योजनाएँ वापस भी लीं
• अंततः किसी प्रोजेक्ट की governance neutrality और external contributors की सक्रियता ही rug pull रोकने और स्वस्थ ecosystem बनाए रखने की कुंजी है

संदर्भ सामग्री

• प्रस्तुति स्लाइड्स: Power Dynamics, Rug Pulls & Other Impact on Sustainability

[ndrgrd]

अभी भी fork करना आसान नहीं है, इसलिए अच्छा होगा अगर open source से जुड़ी संस्थाओं में से कोई इसे आसान बनाने में मदद करे।

[GN⁺]

Hacker News राय

• मेरा मानना है कि CLAs(Contributor License Agreement) इस्तेमाल करने वाले प्रोजेक्ट्स में rug pull(ऐसी स्थिति जहाँ contributors की मेहनत कुछ लोगों द्वारा निजी बना ली जाती है) ज़्यादा होता है, जबकि DCO(Developers Certificate of Origin) इस्तेमाल करने वाले प्रोजेक्ट्स में यह असंतुलन कम होता है। CLA पर साइन करने से आप प्रोजेक्ट को अपने contributed code को relicense करने का अधिकार दे देते हैं। यानी GPL प्रोजेक्ट में GPL contribution देने पर भी license बदला जा सकता है। अगर पहले से permissive license है तो CLA का असर बड़ा नहीं होता, लेकिन copyleft(जैसे GPL) में यह अनुचित हो जाता है क्योंकि CLA पर साइन करवाने वाला पक्ष ही exclusive ownership ले सकता है। rug pull रोकना हो तो copyleft license इस्तेमाल करना और CLA signing से बचना बेहतर है। permissive license में यह समझना चाहिए कि rug pull "game का हिस्सा" है
  • GNU प्रोजेक्ट्स भी CLA मांगते हैं, लेकिन मुझे नहीं लगता कि वे rug pull करने की मंशा से ऐसा करते हैं
  • यह स्पष्ट करना चाहता हूँ कि CLA पर साइन करने का मतलब हमेशा पूरा relicensing अधिकार देना नहीं होता; यह हर CLA पर निर्भर करता है। उदाहरण के लिए Canonical का CLA(लिंक) कहता है कि मेरी contribution मौजूदा license के तहत भी उपलब्ध कराई जाएगी। CLA को पढ़ना और समझना ज़रूरी है। ज़्यादातर CLA copyright contributor के पास ही रहने देते हैं, इसलिए अपनी contribution के साथ जो चाहें करने का अधिकार आपके पास रहता है। मूल समस्या यह है कि project owner पर भरोसा टूट सकता है। CLA owner को control देता है, इसलिए rug pull का जोखिम बढ़ता है। rug pull से निपटने के लिए व्यवहार में fork करके खुद collaboration करना ही फ़ायदेमंद होता है। जब copyleft license के साथ CLA भी जुड़ जाता है(जैसे AGPL + CLA), तो यह permissive license + CLA से भी ज़्यादा हानिकारक हो सकता है। AGPL में service deployment पर भी source disclosure की बाध्यता होती है, लेकिन CLA के कारण owner closed service चला सकता है और अपने सुधार सार्वजनिक किए बिना भी काम चला सकता है। Incus और LXD के मामले में भी license combination और CLA की वजह से community split और code sharing restrictions हुई थीं(विस्तृत केस लेख)
  • मेरा मानना है कि open source में rug pull जैसी कोई चीज़ होती ही नहीं। GPL copies हमेशा के लिए मौजूद रहती हैं
  • permissive license इस्तेमाल करने पर rug pull की संभावना ज़रूर बढ़ती है, लेकिन CLA हमेशा सारे अधिकार दे देता है, यह सही नहीं है
  • मेरा मानना है कि open source में "rug pull" जैसी नकारात्मक भाषा को बहुत ज़्यादा purist नज़रिए से देखना स्वस्थ नहीं है। प्रोजेक्ट्स sustainable होने चाहिए। जब बड़े cloud providers ने infrastructure पर कब्ज़ा कर रखा है, तब छोटे developers का open source या CLA आधारित प्रोजेक्ट्स में आपसी विवादों में उलझने से बेहतर है कि वे अपनी ऊर्जा बड़ी कंपनियों के monopoly प्रभाव को कम करने में लगाएँ
• contributors और maintainers अक्सर छोटे व्यवसायों से भी कमज़ोर स्थिति में होते हैं। फिर भी, अगर liberal license हो तो असंतोष होने पर fork करके नई दिशा में जाया जा सकता है। Valkey का मामला Redis के साथ बदलते licensing dynamics का दिलचस्प उदाहरण है। मुझे लगता है कि आजकल developer community कुल मिलाकर cloud services पर बहुत निर्भर हो गई है, इसलिए पहले की तरह OS, compiler, DB वगैरह को नए सिरे से fork या implement करने की सक्रियता कम हो गई है। AWS जैसी cloud कंपनियों ने services के रूप में उपलब्ध कराकर कई projects की visibility भी बढ़ाई है, इसे अक्सर नज़रअंदाज़ किया जाता है(उदाहरण: ElasticSearch AWS पर आने के बाद लोकप्रिय हुआ)। cloud कंपनियाँ kernel, gcc, jdk आदि में contribution करके छोटे व्यवसायों को भी परोक्ष लाभ पहुँचाती हैं। केवल बड़े cloud players को दोष देने के बजाय business model पर फिर से विचार करना अच्छा होगा। अगर शुरू से ही closed source होते, तो शायद कोई ध्यान ही नहीं देता
• अगर आप software को binary के रूप में लेने के बजाय source code से खुद build करें, तो rug pull जैसी घटनाओं के समय आपकी प्रतिक्रिया देने की क्षमता बढ़ जाती है। vendor binaries/images से install करने वाले users के लिए fork पर switch करना कठिन होता है, लेकिन build infrastructure को नए source पर ले जाना अपेक्षाकृत आसान है। ज़रूरी fixes या features खुद शामिल करके इस्तेमाल किए जा सकते हैं, इसलिए maintenance dependency कम हो जाती है
  • यही वजह है कि मुझे Guix पसंद है। source build इसका default है, और caching के ज़रिए binary packages भी मिलते हैं। अगर binary न हो, तो यह source को reproducible तरीके से खुद build करता है। patched versions भी उसी package manager से आसानी से install किए जा सकते हैं, इसलिए अलग build infrastructure की ज़रूरत नहीं पड़ती। बड़े deployment environment में build server रखना अधिक efficient होता है
  • पता नहीं इस पर downvote क्यों हैं, लेकिन मैं सहमत हूँ। source build आम तौर पर मुश्किल नहीं होता(sqlite देखें)
  • व्यवहार में software license के हिसाब से पाबंदियाँ अलग-अलग होती हैं। कुछ commercial software source देते हैं, लेकिन license के तहत उसे स्वतंत्र रूप से modify नहीं किया जा सकता। उदाहरण के लिए script language आधारित commercial products, या consulting कंपनियों के वे मामले जहाँ ग्राहक को source तो मिलता है लेकिन compile करने का अधिकार अलग से पैसे देकर लेना पड़ता है
• Elasticsearch के rug pull के बाद Amazon का खुद open source fork(OpenSearch) में योगदान देना, भले शुरुआती मंशा कुछ भी रही हो, एक हद तक सकारात्मक परिणाम माना जा सकता है। लेकिन contributors और revenue beneficiaries के बीच असंतुलन से बड़े corporations द्वारा project instability पैदा होना भी एक महत्वपूर्ण चर्चा है
  • license का पालन करते हुए software इस्तेमाल करने में कोई समस्या नहीं है, बल्कि developers या startups का सिर्फ adoption और growth के लिए permissive license चुनना और फिर बड़े cloud provider के आने पर उसे समस्या कहना अपने आप में विरोधाभास है। मेरा मानना है कि आप दोनों फायदे एक साथ नहीं ले सकते
  • Elastic जो चाहता था वह अधिक license revenue था, लेकिन बहुत से users fork पर चले गए और Elastic की credibility गिरी। OpenSearch और ElasticSearch की प्रतिस्पर्धा ecosystem के लिए सकारात्मक भी हो सकती है, लेकिन अब दोनों products की compatibility टूट चुकी है और Elastic की स्थिति भी कमज़ोर हुई है
  • AGPL/GPL जैसे copyleft licenses code contribution को मजबूरन वापस माँगते हैं, इसलिए proprietary license के बिना भी feedback loop बनाया जा सकता है
• open source projects में सिर्फ license बदल देने से rug pull आसान नहीं हो जाता। असली समस्या यह है कि हम किसी ऐसी utopian दुनिया में नहीं रहते जहाँ लोग मुफ्त में काम करके भी अच्छी जीवन-गुणवत्ता बनाए रख सकें। maintainers के बिना project का half-life छोटा होना तय है, और sponsorship न होने पर closed licensing की ओर बढ़ना तेज़ होगा
  • इससे Mojang/Microsoft और Bukkit community का मामला याद आता है। developers को hire करने की प्रक्रिया में project को चुपचाप खरीद लिया गया, फिर volunteers से सालों तक बिना भुगतान काम कराया गया, और अंत में उन्हीं में से एक ने DMCA का इस्तेमाल करके project shutdown करवा दिया। अधिक विवरण: blog
  • आखिरकार यह incentives की समस्या है। आप खुद open source software बनाइए, और cloud providers उसे आसानी से उठाकर उससे पैसा कमा लेते हैं। मैं जानता हूँ कि FOSS(Fully Open Source Software) licensing structure का मतलब यही है, लेकिन लगता है कि समाज मुफ्त श्रम का बहुत आदी हो गया है। इसलिए SSPL(Source-available licensing) जैसे नए तरीके आगे चलकर आकर्षक लग सकते हैं। सिर्फ एक clause के फ़र्क से AGPL को foss और SSPL को foss नहीं कहना मुझे terminology confusion जैसा लगता है
• मैं समझ सकता हूँ कि users rug pull से क्यों आहत होते हैं, लेकिन जो कंपनियाँ वास्तव में projects को develop और maintain करती हैं, उनकी भी वित्तीय सीमाएँ होती हैं और उनके सामने चुनने के लिए कुछ ही विकल्प बचते हैं। revenue model न हो तो license change भी अपरिहार्य हो सकता है। विकल्प के रूप में crowdfunding, काम कम करना, merchandise बेचना, या अतिरिक्त funding न मिलने पर open model बदलने की पूर्व-घोषणा जैसी संभावनाओं पर विचार किया जा सकता है। संबंधित लेख
  • असली शिकायत यह है कि पहले OSS के रूप में जारी करके users बढ़ाए गए, और बाद में अचानक license को बंद स्वरूप की ओर मोड़ दिया गया। अगर शुरुआत से OSS न होता तो betrayal की भावना भी न होती, लेकिन users लाने के लिए OSS से शुरू करके बाद में बदल देना ही समस्या है
  • Mongo, Elastic, Redis, Hashicorp जैसी कंपनियाँ rug pull के समय किसी गंभीर वित्तीय संकट में नहीं थीं। Hashicorp के मामले में यह acquisition value बढ़ाने की रणनीति भी हो सकती थी
• हाल के वर्षों में governance boards, कड़े नियमन वाली operational policies आदि के नाम पर तकनीकी लोगों को स्वेच्छा से हटने के लिए प्रेरित करना, फिर विरोधी राय दबाना और project permissions छीन लेना जैसी घटनाएँ बढ़ी हैं। वास्तव में community में "safety" के नाम पर एक Orwellian माहौल लाया जा रहा है
• लगभग सभी open source users free riders हैं। हम प्रोजेक्ट्स में कोई योगदान दिए बिना उन्हें स्वतंत्र रूप से इस्तेमाल कर रहे हैं। open source को बिना प्रतिफल वाले उपहार, या किसी और के homework को देखकर सीखने की संस्कृति की तरह देखा जा सकता है। अगर दुनिया में योगदान देना है तो खुशी से करें, लेकिन किसी reward की उम्मीद नहीं करनी चाहिए। सिर्फ license change को rug pull कहना भी एक पक्षपाती नज़रिया है। आखिरकार हमें code मिल चुका था; दिशा बदलना दुर्भाग्यपूर्ण हो सकता है, लेकिन दुनिया में कुछ भी स्थायी नहीं है
  • "हम ज़्यादातर बिना कुछ लौटाए इस्तेमाल करते हैं" यह दावा पूरी तरह सही नहीं है। वास्तव में कई projects में code, tests, documentation, marketing, evangelism आदि कई दिशाओं से योगदान हुआ है। ऐसे projects GitHub पर यूँ ही पड़े शांत development artifacts नहीं थे, बल्कि कंपनियों ने बहुत पैसा लगाकर developer evangelists नियुक्त किए, technology और license के फ़ायदों का प्रचार किया, और user base बढ़ाने में मेहनत की। ऐसे माहौल में बड़े पैमाने पर code और contributions इकट्ठा करने के बाद अचानक license बदल देना, और जब दूसरे FOSS projects उस पर निर्भर हों तब वह वादा तोड़ देना, इसी को rug pull कहकर आलोचना की जाती है। अगर कोई project बिना marketing के बस GitHub पर संयोग से आ गया हो और स्वाभाविक रूप से adopt हुआ हो, तो शायद वह rug pull विवाद का विषय न बने। लेकिन ऐसे उदाहरण मैंने लगभग नहीं देखे
  • मेरा मानना है कि यह अनिवार्य संरचना नहीं है। कंपनियाँ या पर्याप्त संसाधन वाले संगठन जिन open source projects पर निर्भर हैं, उनकी sustainability बढ़ाने के लिए वित्तीय और तकनीकी योगदान कर सकते हैं। Open Source Program Office बनाना, इस्तेमाल हो रहे सभी software और dependencies का विश्लेषण करना, contributors के समय और funding का समर्थन करना, और अपने उद्योग में ऐसी संस्कृति को प्रोत्साहित करना जैसे तरीके मौजूद हैं
• जिस कंपनी में मैं अभी काम करता हूँ, वहाँ भी rug pull मुद्दों के कारण management उलझन में है। हम हमेशा systems के लिए support contracts पर ज़ोर देते आए हैं, लेकिन Chef, CentOS, VMWare, Broadcom आदि में बार-बार ऐसी स्थिति देखी गई है। हम पैसे देकर इस्तेमाल करना चाहते थे, फिर भी basic maintenance services की कीमत सालाना हज़ारों से लेकर दसियों हज़ार डॉलर तक पहुँच जाती है, और उसके बाद भी भरोसा नहीं बनता। ऐसी स्थिति में मुझे लगता है कि किसी foundation को sponsor करना, या नियमित रूप से OSS maintainers को सीधे hire करना ज़्यादा बेहतर है। पहले मैं ऐसे सुझावों को लेकर cynical था, लेकिन अब इनके लिए समर्थन बढ़ता दिख रहा है। व्यक्तिगत रूप से, VMWare को भुगतान करने के बजाय मैं Proxmox या qemu developers को hire करना पसंद करूँगा
  • मुझे लगता है यह सही विचार है। जिन software और dependencies का आप उपयोग करते हैं, उनका ऑडिट करना, development time और funding के माध्यम से योगदान देना, और sustainability सुनिश्चित करना महत्वपूर्ण है; साथ ही अपने उद्योग में इस रवैये को फैलाना भी ज़रूरी है
  • दिलचस्प बात यह है कि जिन कंपनियों का ज़िक्र हुआ, उन्होंने community-oriented बनने के लिए open source program offices बनाए थे, लेकिन जब संगठन बहुत बड़े हो जाते हैं, तो community और corporate interests के बीच दोहरापन पैदा होना शायद स्वाभाविक कीमत है
• fork करना आसान काम नहीं है; उसके सफल होने के लिए लोग और resources चाहिए। open source आखिरकार तभी काम करता है जब contributors की संख्या पर्याप्त हो। अगर कोई fork मर जाता है, तो उसका मतलब है कि उस project में free riders बहुत ज़्यादा थे। मेरे हिसाब से rug pull की सबसे बड़ी समस्या वास्तव में false advertising है। open source के नाम पर customers जुटाकर, और फिर जब वह अपने लिए असुविधाजनक लगे तो उस वादे को तोड़ देना नैतिक रूप से समस्या है। लेकिन contribution बंद हो जाना अपने आप में चिंता की बात नहीं है। कोई भी व्यक्ति या कंपनी हमेशा के लिए किसी project से जुड़े रहने के लिए बाध्य नहीं है, इसलिए उनका हट जाना भी स्वाभाविक है।