रोमांस खत्म हो चुका है: open source (OSS) का critical point और survival strategy

📌 मुख्य बिंदु (TL;DR)

• Open source आमतौर पर “बड़ी” तरह से fail नहीं होता। लेकिन maintenance चुपचाप रुकने से यह धीरे-धीरे टूट रहा है।

• maintenance resources की कमी + कंपनियों का license transition + AI-आधारित ‘extraction’ एक साथ हो रहे हैं

• Open source के survival की शर्तें: fair charging (license/commercial policy) + public infrastructure funding + AI-आधारित defense और operations automation.

व्यावहारिक दृष्टिकोण: जोखिम यह नहीं है कि “क्या यह टूटेगा”, बल्कि यह है कि “टूटने पर कौन/कब/कैसे इसे ठीक करेगा।”

---

📉 मुख्य दावे (DEV/operations दृष्टिकोण)

• sustainability collapse: “ऑफिस के बाद के शौक” की तरह चलने वाला OSS हमारी services की supply chain ज़िम्मेदारी उठा रहा है

• security incidents संरचनात्मक समस्या का संकेत हैं: xz backdoor attempt जैसी घटनाएँ “असामान्य case” नहीं, बल्कि maintenance ecosystem के अपनी सीमा पर पहुँचने का प्रतिनिधि लक्षण हैं

• कंपनियों की दीवार खड़ी करना: Terraform/Redis की तरह ‘source-available’ श्रेणी में बदलकर margin और control वापस लेने की प्रवृत्ति बार-बार दिख रही है.

• pricing weapon (free dumping) से market की सफाई: “free distribution” users को मीठा लग सकता है, लेकिन यह प्रतिस्पर्धी ecosystem को सुखा देता है और लंबी अवधि में vendor lock-in बढ़ाता है

• AI era OSS patterns को बड़े पैमाने पर सीखता और reproduce करता है, लेकिन reward/credit का flow-back कमजोर है. खासकर license का अर्थ धुंधला होता जा रहा है

• इससे बचाव के लिए vulnerability patching, dependency PR, triage automation अनिवार्य हैं

• open-washing: केवल “weights को public करना” अक्सर reproducibility/auditability/supply chain verification के लिए पर्याप्त नहीं होता

व्यावहारिक दृष्टिकोण: अब license/governance/automation ‘operations option’ नहीं, बल्कि शुरुआती design से ही ज़रूर शामिल किए जाने वाले अनिवार्य तत्व हैं!

---

Open source जोखिम (manipulation की संभावना सहित)

• bus factor जोखिम: एकल maintainer पर निर्भरता सीधे patch delay, security gap और operational outage तक ले जाती है

• license जोखिम: सफलता के बाद re-licensing लंबी अवधि का TCO बढ़ाती है और fork/migration cost को विस्फोटक बना देती है

• pricing weapon जोखिम: “free” से margin को 0 कर देने पर alternative ecosystem सूखकर मर जाता है, और अंततः विकल्प गायब हो जाते हैं

• AI extraction जोखिम: contribution incentive (reputation/credit) कमजोर होने पर public contributions घटते हैं, और voluntary PR भागीदारी गायब हो जाती है

• open-washing जोखिम: non-reproducible/non-auditable models regulation, audit और security verification में व्यावहारिक latent risk बनते हैं

व्यावहारिक दृष्टिकोण: star count से ज़्यादा महत्वपूर्ण हैं maintenance capacity (bus factor), release discipline, security process, और “replaceability”

---

🔎DEV के लिए 5-minute practical checklist

• top 20 dependencies (transitive सहित) निकालें → इस हफ्ते audit tool कम से कम एक बार चलाएँ.

  • उदाहरण: npm audit / cargo audit / pip-audit, SBOM generation + dependency graph export

• 72 घंटे के भीतर replacement/fork possibility को document करें (top 5).

  • fork तैयारी: mirror, build/release pipeline, owner assignment

• single maintainer dependency को technical debt नहीं, बल्कि operational risk item के रूप में उठाएँ.

  • “bus factor audit” को risk register में दर्ज करें

• organization स्तर पर contribution/sponsorship की minimum limit को rule बनाइए.

  • उदाहरण: engineering budget का 2% sponsorship, हर महीने 1 दिन contribution slot (working hours)

• security automation को default ON रखें.

  • Dependabot, security scanning, automated PR/triage workflow

व्यावहारिक दृष्टिकोण: “incident होने पर response” नहीं, बल्कि सामान्य समय में fork/replacement route तैयार रखना total cost कम करता है.

---

###📊 निष्कर्ष (Bottom line)

• Open source “खत्म” नहीं हो रहा, बल्कि उसका operating model ‘charity’ से ‘infrastructure’ की ओर शिफ्ट हो रहा है.

• OSS को बचाए रखने के लिए 3 स्तंभों वाली अनिवार्य शर्तें पहले से चाहिए:

  • fair charging (scale/commercial basis)
  • public/shared infrastructure funding
  • AI-आधारित defense और operations automation

• अगर यह नहीं हुआ, तो नतीजा होगा

  • patch देर से आएँगे, license बदलेंगे, और supply chain risk बढ़ेगा
  • और उसका नुकसान सभी developers को उठाना पड़ेगा

व्यावहारिक दृष्टिकोण: “free” अब default assumption नहीं है. contract, budget और automation को design में शामिल करना होगा. अभी से तैयारी करें.