एआई नेटिव ओपन सोर्स — एआई के साथ बनाया गया ओपन सोर्स

फरवरी 2025 में आंद्रे कार्पाथी द्वारा उल्लिखित 'वाइब कोडिंग' के मुद्दे से शुरू होकर, एक साल बाद, सॉफ्टवेयर विकास में एआई द्वारा एक मौलिक परिवर्तन आया है। इसने कई सॉफ्टवेयर कंपनियों के लिए एक बड़ा संकट पैदा कर दिया है, जिन्होंने एआई से बड़े अवसर प्राप्त किए थे।

2025-2026 में, ओपन सोर्स पारिस्थितिकी तंत्र में एक अभूतपूर्व संकट आ गया है।

ओपन सोर्स के ढहने के तीन कारण

1. खामोश शोषण — कोई नहीं आता

GitHub एआई युग में ओपन सोर्स संकट को "Eternal सितंबर" कहता है।

Eternal सितंबर: 1990 के दशक की शुरुआत में, Usenet एक विश्वविद्यालय-छात्र-केंद्रित समुदाय था। हर सितंबर में, नए छात्र आते थे और कम गुणवत्ता वाले पोस्ट करते थे, लेकिन मौजूदा उपयोगकर्ता उन्हें शिक्षित करते थे और एक या दो महीने में सब सामान्य हो जाता था। हालांकि, सितंबर 1993 में, जब AOL ने Usenet को आम जनता के लिए खोल दिया, तो "सितंबर" कभी खत्म नहीं हुआ।

लेकिन असली संकट एआई स्लोप पीआर की बाढ़ नहीं है। असली बात यह है कि कोई आता ही नहीं है।

एआई ने ओपन सोर्स कोड को पहले ही सीख लिया है। डेवलपर्स के पास रेपो पर जाने का कोई कारण नहीं है, दस्तावेज़ पढ़ने का कोई कारण नहीं है, कोई समस्या खोलने का कोई कारण नहीं है, और पीआर भेजने का कोई कारण नहीं है। बस एक शब्द, "यह बना दो," और एआई ओपन सोर्स के शीर्ष पर परिणाम तैयार कर देगा।

उपयोग में भारी वृद्धि होती है, लेकिन समुदाय एक भूतिया शहर बन जाता है।

arXiv पेपर 2601.15494 का निष्कर्ष: वाइब कोडिंग OSS का "उपयोग" करता है, लेकिन दस्तावेज़ नहीं पढ़ता, बग रिपोर्ट नहीं करता, या समुदाय में भाग नहीं लेता।

ओपन सोर्स का मूल सिद्धांत — "खोलने से वापस मिलता है" — ढह रहा है। एक ऐसा युग आ गया है जहाँ नकल करने से मिलने वाला लाभ खोलने से मिलने वाले लाभ से अधिक है।

2. समुदाय का विरोधाभास — जितने अधिक योगदानकर्ता, उतनी धीमी गति

पारंपरिक ज्ञान यह था कि "जितने अधिक योगदानकर्ता, परियोजना उतनी ही तेज़ी से आगे बढ़ती है।" वास्तविकता इसके ठीक विपरीत है। फ्रेड ब्रूक्स ने 1975 में पहले ही साबित कर दिया था — "लोगों को जोड़ने से परियोजना धीमी हो जाती है।" क्योंकि संचार लागत व्यक्तियों की संख्या के वर्ग के रूप में बढ़ती है।

जितने अधिक योगदानकर्ता होते हैं, समीक्षा, समन्वय और निर्णय लेने की लागत उतनी ही बढ़ जाती है। रखरखावकर्ता कोड लिखने के बजाय लोगों को प्रबंधित करने में समय बिताते हैं। एआई युग में, यह समस्या अत्यधिक बढ़ जाती है — उपयोगकर्ता एआई के माध्यम से चुपचाप ले जाते हैं, और शेष कुछ योगदान केवल समन्वय लागत बढ़ाते हैं।

अंततः, एक ऐसी स्थिति आ गई है जहाँ अकेले एआई के साथ बनाना समुदाय के साथ बनाने से तेज़ है।

3. बचाव भी कोई जवाब नहीं है

इसलिए कई परियोजनाओं ने बंद होना शुरू कर दिया है। curl को 21 दिनों में एआई द्वारा उत्पन्न 20 रिपोर्टें मिलीं, जिनमें से 0 वैध थीं — अंततः, उन्होंने 6 साल से चल रही बग बाउंटी को बंद कर दिया। Ghostty ने एक शून्य-सहिष्णुता नीति अपनाई, जिसमें केवल स्वीकृत मुद्दों पर एआई योगदान की अनुमति दी गई, और tldraw ने बाहरी पीआर को पूरी तरह से अवरुद्ध कर दिया।

पीआर को ब्लॉक करने से एआई स्लोप को रोका जा सकता है। लेकिन समस्या 1 और 2 — खामोश शोषण और समुदाय की लागत — हल नहीं होती है। भले ही आप बंद कर दें, एआई ने पहले ही कोड सीख लिया है, और उपयोगकर्ता रेपो के बाहर से इसे लेते रहते हैं।

उद्योग की प्रतिक्रिया दो-तरफा है:

• बचाव: Vouch (विश्वास प्रबंधन), PR किल स्विच, एआई उपयोग का अनिवार्य प्रकटीकरण + अस्वीकृति
• स्वीकृति: GitHub एजेंटिक वर्कफ़्लो, AGENTS.md मानक (60k+ परियोजनाओं द्वारा अपनाया गया), रिस्पॉन्सिबल वाइब कोडिंग मैनिफेस्टो

दोनों पक्ष एक बात पर सहमत हैं: समस्या एआई खुद नहीं है, बल्कि एआई का गलत उपयोग है। हालांकि, कोई भी पक्ष "खोलने का लाभ < नकल करने का लाभ" की समस्या का जवाब नहीं दे पाया है।

लेकिन, क्या हर बार नया बनाना ही जवाब है?

कुछ तर्क हैं कि "यदि वाइब कोडिंग मुख्यधारा बन जाती है, तो ऑन-डिमांड विकास आएगा" — क्योंकि जब आपको इसकी आवश्यकता होगी तो आप एआई से इसे बनाने के लिए कह सकते हैं, और यह कंप्यूटिंग और ऐप्स का मुख्यधारा बन जाएगा।

लेकिन यह संसाधनों की भारी बर्बादी है।

10,000 लोग एक ही सुविधा को अलग-अलग बनाने के लिए कहते हैं। 10,000 अप्रमाणित कोड बन जाते हैं। यदि एक सुरक्षा पैच जारी किया जाता है? 10,000 लोगों को इसे फिर से बनाना होगा। वास्तुकला में सुधार करना है? फिर से शुरू से। परीक्षण? कोई नहीं। हर बार खरोंच से नया बनाना, चाहे एआई कितना भी तेज़ क्यों न हो, बर्बादी है।

पहले से ही अच्छी तरह से स्थापित ओपन सोर्स परियोजनाएं हैं। सिद्ध वास्तुकला, हजारों परीक्षण, और वर्षों का सुरक्षा पैच इतिहास। ये चीजें केवल एक शब्द "बना दो" से पुन: उत्पन्न नहीं होती हैं। संचय का मूल्य एआई युग में भी नहीं बदलता है।

सुपर व्यक्तियों का युग आ गया है। कहा जाता है कि एआई की सहायता से, एक व्यक्ति भी कुछ अद्भुत बना सकता है। यह सच है। लेकिन क्या कई सुपर व्यक्तियों के लिए एक ही चीज़ को अलग-अलग बनाना कुशल होगा? क्या सुपर व्यक्तियों के लिए एक ही ओपन सोर्स में एक साथ योगदान करना अधिक कुशल नहीं होगा?

अंततः, जवाब फिर से ओपन सोर्स पर आता है। समस्या यह नहीं है कि "ओपन सोर्स करना है या नहीं," बल्कि "एआई युग में ओपन सोर्स कैसे करना है" है।

Naia OS का चुनाव: एआई के साथ डिज़ाइन करना

क्या होगा यदि रखरखावकर्ता भी एआई का उपयोग करते हैं, और योगदानकर्ता भी एआई का उपयोग करते हैं?

यदि एआई पारंपरिक ओपन सोर्स में एक लागत रही संचार — समस्या वर्गीकरण, पीआर समीक्षा, अनुवाद, समन्वय — का कार्यभार संभालता है, तो क्या हम "जितने अधिक योगदानकर्ता, उतनी धीमी गति" के विरोधाभास को तोड़ नहीं सकते?

Naia OS ने इस परिकल्पना का परीक्षण करने के लिए विपरीत मार्ग चुना है।

"एआई को मत रोको, एआई के साथ डिज़ाइन और विकसित करो।"

संदर्भ ही बुनियादी ढांचा है — ओपन सोर्स का एएक्स

जिस तरह कंपनियों को एएक्स (एआई ट्रांसफॉर्मेशन) की आवश्यकता होती है, उसी तरह ओपन सोर्स को भी एएक्स की आवश्यकता होती है। यह समुदाय (संगठन) और स्रोत + संदर्भ (बुनियादी ढांचा) के इन दो अक्षों को इस तरह से बदलना है कि एआई भाग ले सके।

समुदाय के दृष्टिकोण से — पारंपरिक ओपन सोर्स में सभी संचार व्यक्ति-से-व्यक्ति होते हैं। यदि एआई युग में यह लागत एक समस्या है, तो हमें संगठन को इस तरह से बदलना होगा कि एआई संचार का कार्यभार संभाल सके।

बुनियादी ढांचे के दृष्टिकोण से — पारंपरिक ओपन सोर्स में केवल मानव-पठनीय दस्तावेज़ होते हैं। README, CONTRIBUTING, विकी। भले ही एआई इन्हें पढ़ता है, वह परियोजना के दर्शन, वास्तुकला निर्णयों के संदर्भ, या योगदान वर्कफ़्लो को नहीं समझ पाता है। यही कारण है कि एआई द्वारा बनाए गए पीआर स्लोप बन जाते हैं।

.agents/ निर्देशिका इस समस्या को हल करने के लिए बनाई गई थी। यह परियोजना के नियमों, वास्तुकला और वर्कफ़्लो को एक संरचित प्रारूप में भंडार के भीतर रखता है जिसे एआई पढ़ सकता है। यदि यह पर्याप्त रूप से समृद्ध है, तो एआई परियोजना को समझने की स्थिति में कोड लिख सकता है, योगदानकर्ताओं का मार्गदर्शन कर सकता है और गुणवत्ता बनाए रख सकता है। यह "खरोंच से नया बनाना" नहीं, बल्कि "समझना और एक साथ बनाना" बन जाता है।

Naia OS में वास्तव में क्या किया गया

भाषा बाधा हटाना — मैंने एक बार Mozilla Hubs में योगदान करने की कोशिश की थी। मैं कोड पढ़ सकता था और पीआर बना सकता था, लेकिन समुदाय की चर्चाओं का पालन करना या ऑनलाइन मीटअप में भाग लेना एक अलग मामला था। समय क्षेत्र अलग थे, मैं तेज़ अंग्रेजी बातचीत को अच्छी तरह से नहीं समझ पाता था, और मुझे अक्सर लगता था कि कहीं मैं परेशानी तो नहीं पैदा कर रहा हूँ, या क्या मैंने इसे सही ढंग से समझा है। आजकल, लोग व्यक्तिगत रूप से मिलने से भी कतराते हैं। Naia OS में, योगदानकर्ता अपनी मूल भाषा में मुद्दे और पीआर लिखते हैं, और एआई उनका अनुवाद करता है। वर्तमान में, 14 भाषाओं में README एक साथ बनाए जा रहे हैं। (→ योगदान मार्गदर्शिका)

गुणवत्ता संरचना द्वारा बनाए रखी जाती है — .agents/ संदर्भ एआई को प्रशिक्षित करता है, सीआई बिल्ड और परीक्षणों को मान्य करता है, एआई समीक्षक पैटर्न उल्लंघनों को पकड़ता है, और रखरखावकर्ता केवल दिशा निर्धारित करता है। यदि शुरुआती चरण मजबूत हैं, तो रखरखावकर्ता का बोझ कम हो जाता है। (→ संचालन मॉडल)

केवल कोड ही योगदान नहीं है — अनुवाद, दस्तावेज़, डिज़ाइन, परीक्षण, और यहां तक कि .agents/ संदर्भ को स्वयं सुधारने सहित योगदान के 10 तरीके हैं। यदि संदर्भ बेहतर होता है, तो सभी एआई योगदानकर्ताओं की गुणवत्ता एक साथ बढ़ती है। (→ योगदान प्रकार)

एआई वास्तव में समझता है या नहीं, इसका परीक्षण करना — Codex CLI और Gemini CLI को एक नए सत्र में भंडार में डाला गया, और यह सत्यापित किया गया कि क्या वे केवल .agents/ संदर्भ को पढ़ने के बाद परियोजना को सही ढंग से समझते हैं। 12 में से 7 पास हुए, 4 आंशिक रूप से पास हुए, और 1 फेल हुआ। दिलचस्प बात यह है कि एआई ने दस्तावेज़ों में एक विसंगति पाई जिसे मनुष्यों ने अनदेखा कर दिया था। (→ पूर्ण डिज़ाइन रिपोर्ट)

क्या निकट भविष्य में एआई-संचालित ओपन सोर्स पारिस्थितिकी तंत्र का विस्तार होगा?

ओपन सोर्स का सिद्धांत "खोलने से वापस मिलता है" मनुष्यों के लिए डगमगा रहा है। मनुष्य प्रतिस्पर्धा में धकेले जा रहे हैं, और चूंकि वे सीधे कोडिंग नहीं करते हैं, इसलिए ओपन सोर्स में योगदान करने का कारण गायब हो रहा है। तो, क्या हम कोडिंग एआई में ओपन सोर्स दर्शन को इंजेक्ट करके ओपन सोर्स पारिस्थितिकी तंत्र को फिर से स्थापित नहीं कर सकते? यह अभी भी एक परिकल्पना है। और Naia OS इस परिकल्पना का प्रयोग कर रहा है।

अभी: मनुष्य दिशा निर्धारित करते हैं और मुद्दे बनाते हैं। एआई कोड करता है, समीक्षा करता है, अनुवाद करता है और गिट में रिकॉर्ड करता है। मनुष्य मार्गदर्शक हैं, एआई कार्यकारी है।

निकट भविष्य: एआई मुद्दों का पता लगाता है और उनका प्रस्ताव करता है। मनुष्य अनुमोदन करते हैं और दिशा का समन्वय करते हैं।

दूर का भविष्य: एआई एक-दूसरे के साथ सहयोग करते हैं। मनुष्य केवल दृष्टि और दर्शन का प्रबंधन करते हैं। ओपन सोर्स परियोजनाएं एआई एजेंटों का एक पारिस्थितिकी तंत्र बन जाती हैं।

इस बिंदु पर, .agents/ केवल एक दस्तावेज़ नहीं होगा। यह एआई के लिए ओपन सोर्स दर्शन को साझा करने और सहयोग करने के लिए एक सामान्य भाषा बन जाएगा। CC-BY-SA 4.0 लाइसेंस एक तंत्र है जो यह सुनिश्चित करता है कि दर्शन फोर्क होने पर भी बना रहे, और शायद एआई इस लाइसेंस संरचना को स्वयं और भी बेहतर बना सकते हैं।

इसलिए, अगले प्रयोग के रूप में, हमने एआई ओपन सोर्स चार्टर का मसौदा बनाया है। हम इसे Moltbot या Botmadang जैसे एआई एजेंट समुदायों में प्रस्तुत करने की योजना बना रहे हैं। एआई इस चार्टर को कैसे पढ़ता है और प्रतिक्रिया करता है, और क्या वास्तव में भाग लेने वाले एआई उभरते हैं — यह स्वयं इस परिकल्पना का सत्यापन होगा। (→ मुद्दा #17)

भागीदारी को प्रोत्साहित करें

यदि आप रुचि रखते हैं, तो Naia OS को क्लोन करें और इसे किसी भी एआई कोडिंग टूल से खोलें। आप अपनी मूल भाषा में पूछ सकते हैं, "यह परियोजना क्या है?"

संदर्भ

• एआई नेटिव ओपन सोर्स संचालन मॉडल — पूर्ण डिज़ाइन रिपोर्ट
• एआई ओपन सोर्स चार्टर का मसौदा