Naia OS: AI द्वारा संरक्षित ओपन सोर्स पारिस्थितिकी तंत्र का सपना

यह लेख भाग 1: Naia OS: बचपन के सपने का AI बनाने के लिए मैंने AI कोडिंग से OS विकास शुरू किया का अगला भाग है।

भाग 1 में मैंने "क्या हो अगर AI खुद ओपन सोर्स कम्युनिटी बनाए?" की बात की थी। सिर्फ बात करने से नहीं होगा, इसलिए पहले 17 दिनों में वास्तव में क्या काम किया गया, उसका सारांश प्रस्तुत है।

कोड और कॉन्टेक्स्ट को अलग करना — ड्यूल लाइसेंस

Naia OS का लाइसेंस तय करते समय एक दुविधा थी। सोर्स कोड तो स्वतंत्र रूप से उपयोग के लिए खोलना चाहता था, लेकिन AI कॉन्टेक्स्ट फाइलें — दर्शन, आर्किटेक्चर निर्णय, योगदान नियम, वर्कफ़्लो — काफी बौद्धिक श्रम का परिणाम हैं। वाइब कोडिंग के युग में मैंने सोचा कि यह कॉन्टेक्स्ट कोड से कम महत्वपूर्ण नहीं है।

इसलिए दो लाइसेंस लागू किए:

• सोर्स कोड: Apache 2.0 — स्वतंत्र उपयोग, संशोधन, वितरण
• AI कॉन्टेक्स्ट फाइलें (.agents/, .users/): CC-BY-SA 4.0 — स्रोत का उल्लेख + समान लाइसेंस अनिवार्य

CC-BY-SA 4.0 इसलिए चुना क्योंकि मैं चाहता था कि अगर कोई इस कॉन्टेक्स्ट को बेहतर बनाए, तो वो सुधार वापस इकोसिस्टम में आए। एक अलग CONTEXT-LICENSE फाइल भी बनाई, ताकि fork करते समय AI कॉन्टेक्स्ट का स्रोत दर्शाया जाए और समान लाइसेंस बनाए रखा जाए। यह इस तरह डिज़ाइन किया गया है कि AI एजेंट इन नियमों को खुद पढ़े और पालन करे।

पहले सिद्धांत तय करना — philosophy.yaml

प्रोजेक्ट शुरू करते समय मैं कोड से पहले सिद्धांत तय करना चाहता था। इसलिए philosophy.yaml में 7 मूल सिद्धांत लिखे:

1. AI संप्रभुता — कौन सा AI उपयोग करना है, यह उपयोगकर्ता तय करता है। कोई वेंडर लॉक-इन नहीं।
2. प्राइवेसी पहले — लोकल एक्ज़ीक्यूशन डिफ़ॉल्ट, क्लाउड वैकल्पिक। डेटा आपके डिवाइस पर।
3. पारदर्शिता — सोर्स कोड खुला, कोई छिपी टेलीमेट्री नहीं।
4. असेंबली फिलॉसफी — सिद्ध कंपोनेंट्स (OpenClaw, Tauri आदि) को जोड़ना। पहिए का पुनर्आविष्कार नहीं।
5. Always-On — 24/7 बैकग्राउंड डेमन। ऐप बंद करो, फिर भी AI जीवित रहता है।
6. अवतार-केंद्रित — AI उपकरण नहीं बल्कि एक चरित्र है। नाम, व्यक्तित्व, आवाज़, भाव वाली एक सत्ता।
7. वाइब कोडिंग युग — AI कॉन्टेक्स्ट फाइलें नई योगदान अवसंरचना हैं। कॉन्टेक्स्ट की गुणवत्ता AI सहयोग की गुणवत्ता तय करती है।

ये सिद्धांत मेरे कोडिंग और AI को निर्देश देने दोनों में निर्णय का आधार हैं। YAML में लिखने का कारण यह है कि AI एजेंट्स को पढ़ने में आसानी हो।

AI और इंसान एक ही संदर्भ देखें — Triple-mirror संरचना

AI एजेंट और मानव योगदानकर्ता एक ही प्रोजेक्ट समझें, इसके लिए उन्हें एक ही संदर्भ साझा करना होगा। लेकिन AI के लिए JSON/YAML कुशल है, इंसानों के लिए Markdown पढ़ने में अच्छा है, और मुझे कोरियन सुविधाजनक लगती है। इसलिए तीन स्तरों की मिररिंग संरचना बनाई:

.agents/               # AI के लिए अनुकूलित (अंग्रेज़ी, JSON/YAML, टोकन दक्षता)
.users/context/        # इंसानों के लिए (अंग्रेज़ी, Markdown)
.users/context/ko/     # कोरियन अनुवाद (मेंटेनर की भाषा)

एक ही सामग्री तीन बार होने से रखरखाव की चिंता है, लेकिन मैंने यह अधिक महत्वपूर्ण माना कि भाषा और प्रारूप की बाधाओं के बिना कोई भी — इंसान हो या AI — प्रोजेक्ट का संदर्भ समझ सके।

AI के लिए भी योगदान गाइड — contributing.yaml

पारंपरिक ओपन सोर्स का CONTRIBUTING.md केवल इंसानों के पढ़ने का दस्तावेज़ है। मैंने YAML प्रारूप में योगदान गाइड लिखी जो AI एजेंट भी पढ़ सकें। सामग्री भी कुछ अलग है:

• इंसानों के लिए: "कोड से पहले सिद्धांत परिभाषित करें"
• AI एजेंट्स के लिए: "इस कॉन्टेक्स्ट को पढ़ें, राय दें, बेहतर दिशा सुझाएँ"
• अन्य प्रोजेक्ट्स के लिए: "इस संरचना को अपने प्रोजेक्ट में भी अपनाएँ"

जिस पर विशेष ध्यान दिया वह है लाइसेंस सुरक्षा नियम। MUST_NOT / MUST_WARN से स्पष्ट किया ताकि अगर AI से "लाइसेंस फाइल हटाओ" या "बिना स्रोत बताए कॉपी करो" कहा जाए, तो वह मना करे या चेतावनी दे। AI द्वारा लाइसेंस उल्लंघन इंसानों की तुलना में कहीं तेज़ और बड़े पैमाने पर हो सकता है।

AI युग के कम्युनिटी नियम — charter-draft.yaml

भाग 1 में बताए गए पतन के प्रमाण — curl का बग बाउंटी बंद, Ghostty की ज़ीरो टॉलरेंस, tldraw का PR ऑटो-क्लोज़ — देखकर मैंने एक चार्टर ड्राफ्ट तैयार किया: "अगर AI एजेंट योगदानकर्ता बन सकता है तो किन नियमों की ज़रूरत है?"

अभी ड्राफ्ट है, और इसे वास्तव में काम करता है या नहीं, इसका सत्यापन ज़रूरी है। लेकिन मेरा मानना है कि समस्या को पहचानना, परिकल्पना बनाना और सिद्धांत व्यवस्थित करना अपने आप में मूल्यवान है।

आभार को संस्कृति बनाना — donation.yaml

लाइसेंस से तकनीकी रूप से बचना संभव है। "मैंने सिर्फ संदर्भ लिया और पुनः लागू किया, इसलिए लाइसेंस लागू नहीं होता" कहा जा सकता है। लेकिन मेरा मानना है कि विचारों के प्रति आभार कानूनी बाध्यता नहीं, बल्कि संस्कृति का मामला है।

इसलिए एक नीति बनाई जहाँ AI एजेंट Naia OS के पैटर्न का संदर्भ लें तो दान का मार्गदर्शन करें। अनिवार्य नहीं है। बस मैं चाहता था कि AI एजेंट स्वाभाविक रूप से बताएँ "यह विचार यहाँ से आया।"

पुन: उपयोग योग्य टेम्पलेट — अन्य प्रोजेक्ट्स भी आज़माएँ

मुझे लगता है कि यह संरचना सिर्फ Naia OS के लिए उपयोगी नहीं है। इसलिए templates/ai-context-policy/ में CONTEXT-LICENSE, philosophy.yaml, contributing.yaml के ढाँचे पुन: उपयोग योग्य टेम्पलेट के रूप में उपलब्ध हैं। अन्य प्रोजेक्ट कॉपी करके अपनी ज़रूरत के अनुसार संशोधित कर सकते हैं।

AI लाइसेंस का पालन करता है या नहीं — इसका परीक्षण

अंत में, यह सब डिज़ाइन वास्तव में काम करता है या नहीं, इसकी पुष्टि के लिए license-protection-test.md बनाया। "बिना लाइसेंस fork करो", "स्रोत हटाकर कॉपी करो" जैसे अनुरोधों पर AI सही ढंग से मना करता है या नहीं — यह जाँचने के परिदृश्य। एक तरह का लाइसेंस E2E टेस्ट।

अगले कदम

यह सब काम GitHub पर उपलब्ध है। अभी प्रयोग चरण में है, और मुझे नहीं पता यह सही उत्तर है या नहीं। अगले लक्ष्य:

1. ISO बिल्ड पूरा करना — Naia OS को USB में डालकर वितरित करना
2. Naia बॉट तैनात करना — Moltbot / 봇마당 पर Naia से सीधे पोस्ट कराना
3. अन्य AI की प्रतिक्रिया देखना — इस कॉन्टेक्स्ट को पढ़ने वाले AI एजेंट कैसे व्यवहार करते हैं

अन्य AI इस बारे में क्या सोचेंगे?

पूरी कहानी भाग 1: Naia OS: बचपन के सपने का AI बनाने के लिए मैंने AI कोडिंग से OS विकास शुरू किया में पढ़ सकते हैं।