Open source का मतलब open community नहीं होता
(blog.feld.me)- Open source software को (D)VCS से पहले भी HTML pages, txt files, FTP tarballs और सिर्फ email contact के जरिए वितरित किया जा सकता था, और public community न होने पर भी वह open source ही था
- अगर mailing list या IRC channel होता था तो इसे अच्छी किस्मत माना जाता था, लेकिन pull request, issue, wiki, core team, Code of Conduct open source की अनिवार्य शर्तें नहीं थीं
- Sourceforge ने CVS/SVN और mailing lists लगभग मुफ्त में देकर public development को आसान बनाया, और उसके बाद git ने DVCS प्रतिस्पर्धा जीत ली तथा दुनिया GitHub पर सिमट गई
- GitHub के बाद open source maintenance issue, दायरे से बाहर जाने वाले pull requests, शिकायतों और मांगों, और chat groups के प्रबंधन तक उठाने वाले बिना वेतन के काम जैसी चीज़ में बदल गया, जो burnout और control खोने तक ले जा सकता है
- किसी project का public रूप से develop होना ज़रूरी नहीं है; आप issue tracker और pull request बंद कर सकते हैं, bare git server इस्तेमाल कर सकते हैं, और किसी भरोसेमंद छोटे group के साथ या अकेले open source चला सकते हैं
GitHub के बाद maintenance का बोझ
- GitHub ने open source को maintainers के लिए बिना वेतन की नौकरी जैसा महसूस कराया
- दफ़्तर में tickets, stakeholder meetings, roadmap, politics, distractions, deadlines, metrics, KPI, बदली हुई requirements, standup, one-on-one, Agile, Waterfall संभालने के बाद भी, घर लौटने पर open source notifications जमा मिलती हैं
- issues बढ़ते जाते हैं, software को project के scope से बाहर की दिशा में redesign करने वाले pull requests आते हैं, और शिकायतें व मांगें बढ़ती जाती हैं
- जब chat groups और “community” बन जाते हैं, तो maintainers पर अधीर लोगों को manage करने और one-on-one जवाब देने की ज़िम्मेदारी भी आ जाती है
- नतीजतन open source दूसरी नौकरी जैसा बन जाता है, और maintainers burnout का शिकार होकर अपने ही project पर control और direction तक खो सकते हैं
फिर से सरल तरीके से चलाना
- कुछ projects इतने बड़े और जटिल होते हैं कि team management की ज़रूरत पड़ती है, लेकिन यह अपवाद है, सामान्य स्थिति नहीं
- अगर नए लोगों और AI bots द्वारा ध्यान भटकाए जाने से गुस्सा आता है, तो आप पुराने तरीके पर लौट सकते हैं
- आप issue tracker और pull request बंद कर सकते हैं, या code publish करने के लिए bare git server चला सकते हैं
- आप सचमुच जानने और भरोसा करने वाले छोटे group के साथ काम कर सकते हैं, या project पूरी तरह अकेले भी चला सकते हैं
- अजनबियों को अपनी जगह में दखल देने की अनुमति देना ज़रूरी नहीं है, और दिखावे के Code of Conduct या LLM policy भी अनिवार्य नहीं हैं
- “Open source” होने के लिए open source को public रूप से develop किया जाना ज़रूरी नहीं है
- आप अपनी पसंद के tools इस्तेमाल करें, अपनी पसंद की चीज़ें बनाएं, और Christmas की रात 2 बजे भी code drop करें; आपको किसी ऐसे operating system में घसीटे जाने की ज़रूरत नहीं है जो technical incubator और childcare facility का मिश्रण लगता हो
2 टिप्पणियां
Lobste.rs की राय
इसी सोच की वजह से https://casuallymaintained.tech/ बनाया था, और यह बहुत पसंद आया
सबसे मशहूर उदाहरण SQLite है, जो बाहरी योगदान स्वीकार नहीं करता
यह देखते हुए कि इसका इस्तेमाल Airbus विमान जैसे mission-critical applications में भी होता है, यह एक उचित नीति लगती है
SQLite open source है, इसलिए आप इसे जितना चाहें कॉपी कर सकते हैं और बिना किसी पाबंदी के इस्तेमाल कर सकते हैं, लेकिन यह open-contribution project नहीं है
SQLite को public domain में बनाए रखने और proprietary या licensed code के मिल जाने से बचाने के लिए, वे उन लोगों के patches स्वीकार नहीं करते जिन्होंने यह बयान जमा नहीं किया कि उनका योगदान public domain को समर्पित है
यह काफ़ी ताज़ा नज़रिया है
शायद लेखक सही है, और हम maintainers से बहुत ज़्यादा उम्मीद कर रहे हैं
हो सकता है टूटा हुआ open source नहीं, बल्कि इस बात को लेकर उम्मीदों की inflation हो कि open source को क्या-क्या देना चाहिए
GitHub का social पहलू भी इसमें भूमिका निभा सकता है. जैसे-जैसे stars और सामान्य users बढ़ते हैं, project देखने आने वाले नए लोगों को संतुष्ट करने का दबाव भी बढ़ता है
यह ख़ास तौर पर तब ख़तरनाक हो जाता है जब community की दिलचस्पी और माँगें, बनाने वाले की शुरुआती vision से मेल नहीं खातीं
संबंधित लेख: Git without a Forge: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/
यह एक मज़बूत approach है, और काश ज़्यादा लोग इसे default मानें
community बनाना या किसी तरह की ज़िम्मेदारी उठाना, अपवादस्वरूप और जानबूझकर किया गया काम होना चाहिए
code of conduct और LLM policy को दिखावे का हिस्सा कहने वाली बात थोड़ी अलग-सी लगी, लेकिन विषय संवेदनशील है इसलिए समझ में आता है
लेकिन अगर उसे ऐसे one-person repo पर चिपका दिया जाए जहाँ न users हैं, न community, और न आगे बनाने का इरादा, तो वह दिखावटी बन जाता है
सिर्फ़ अपने इस्तेमाल के repo में मुझे अपने ही लिए code of conduct की ज़रूरत नहीं है
अच्छा होगा अगर यह चर्चा गति पकड़े और किसी ऐसी सहमति तक पहुँचे जो सच में काम करे
software बनाने और स्वस्थ तरीके से योगदान देने के कई तरीके हैं
बस वे हमेशा एक-दूसरे के साथ compatible नहीं होते, या open source के ऊँचे मानकों से मेल नहीं खाते, या visibility और popularity की कीमत माँगते हैं, या फिर license, self-hosting, और code contribution स्वीकार न करने जैसे अलग-अलग साधनों का इस्तेमाल करते हैं
उम्मीद है कि हम community software में मज़ा और fairness को आगे रखने का अच्छा रास्ता खोज पाएँगे
लेख में बताई गई स्थिति, किसी गैर-प्रसिद्ध व्यक्ति द्वारा अभी-अभी शुरू किए गए लगभग हर व्यक्तिगत open source project की स्वाभाविक स्थिति है
हम सबके पास ऐसे काफ़ी project हैं जो इसी तरह चलते हैं
समस्या यह है कि लोगों को पता नहीं होता कि वे अपने project से क्या चाहते हैं, या वे सोचते हैं कि किसी लोकप्रिय project को चलाना शानदार होगा, लेकिन उसकी लागत को ठीक से नहीं तौलते
फिर चाहे जानबूझकर हो या नहीं, attention-seeking शुरू हो जाता है
“GitHub ने पूरे open source को maintainers के लिए unpaid job बना दिया” — यह बात तभी सही है जब आप उसे ऐसा करने दें
धुंधली-सी शोहरत के वादे को छोड़ दें तो ज़्यादातर हालात में GitHub के पास आपको वह काम करवाने की ज़्यादा leverage नहीं होती जो आप मूल रूप से करना ही नहीं चाहते थे
बिल्कुल सही बात
पहले मेरा एक project था जो थोड़ा लोकप्रिय हो गया था, और उसमें ऐसे features के bug reports और pull requests आने लगे जिन्हें मैं चाहता ही नहीं था; उन्हें संभालते-संभालते तनाव होने लगा
काश उस समय मुझे ऐसा लेख पढ़ने को मिला होता
साथ ही https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 भी देखने लायक है
छोटे projects के बारे में मैं इस लेख से मज़बूती से सहमत हूँ
बड़े projects में भी सबसे सफल project अक्सर शुरुआत से open community के रूप में शुरू नहीं होते
जिन projects को मैं पसंद करता हूँ, उनमें से कई बड़े संगठनों के भीतर विकसित होने शुरू हुए, और अहम बात यह थी कि उस software का अंदरूनी तौर पर सचमुच सक्रिय इस्तेमाल हो रहा था
इसलिए maintainers को पहले से ही भुगतान मिल रहा था
चाहे व्यक्तिगत project हो या internal team, डेवलपर की अपनी रोज़मर्रा की समस्या हल करने के लिए बनाया गया software, शोहरत या monetization के लिए बनाए गए software की तुलना में ज़्यादा सफल और कम exploitative लगता है
Hacker News की राय
सबसे बंद समुदाय भी अक्सर योगदान स्वीकार कर लेते हैं, अगर आप शिष्ट ईमेल भेजें
एक open source डेवलपर कभी उत्पीड़न से तंग आकर अपने repository के pull request और कई फीचर बंद कर चुका था, और उस दौरान उसकी छवि बहुत मुश्किल इंसान जैसी बन गई थी
मुझे वह पृष्ठभूमि नहीं पता थी, इसलिए मैंने बस यही समझा कि प्रोजेक्ट का तरीका ही ऐसा है, ईमेल पता थोड़ा खोजा, फिर बिना दबाव डाले विनम्र मेल में एक अनौपचारिक patch भेज दिया, और साफ कहा कि चाहें तो इस्तेमाल करें, चाहें तो अनदेखा कर दें
उस डेवलपर ने धन्यवाद कहते हुए जवाब दिया, स्थिति समझाई, मुझे असुविधा देने के लिए माफ़ी भी मांगी, कहा कि उसे ऐसे लॉक करने के अलावा और कोई तरीका नहीं सूझा, और फिर स्वाभाविक रूप से वह fix भी शामिल कर लिया
मुझे लगा था यह लेख उस व्यापक समस्या पर है जिसमें free software projects चर्चा या bug report के लिए Discord को मजबूर करते हैं
एक-दो हफ्ते तक इसे दूसरे टूल पर ले जाने में थोड़ी दिलचस्पी दिखी, लेकिन अब वह ठंडी पड़ गई लगती है, और आखिर में सबने हार मानकर फिर Discord पर लौट आए हैं
Discord पूरी तरह भयानक नहीं है, लेकिन यह क्षणभंगुर है और एक विशाल, फूला हुआ web app मांगता है
एक greybeard के नज़रिए से, मुझे लेखक का रवैया पसंद है
मैं इतना पुराना हूं कि ARPANET के दिग्गजों के सामने बैठने के दिन याद हैं, जब बस 1 होता था और उसका लगभग आधा हिस्सा हाथ से घिसकर 0 बनाना पड़ता था
पुराने software development तरीके में, projects आमतौर पर एक-दो लोगों द्वारा लिखे या maintain किए जाते थे, और पूरा internet उनके email addresses जानता था और सीधे bug report भेजता था
कुछ projects पर IRC या mailing list में चर्चा होती थी, लोग आम तौर पर पेशेवर व्यवहार करते थे, और नहीं करते तो mailing list से हटा दिए जाते थे या iirc और pine की block files में चले जाते थे
मुख्य बात यह थी कि किसी भी समय active developers का समूह बहुत छोटा होता था
मैं मुख्यतः make, Sendmail, sed, awk जैसी छोटी utilities की बात कर रहा हूं, और 1990 से पहले Perl भी ज़्यादातर बस Larry Wall और tchrist का ही लगता था
gcc एक पागलपन भरा अपवाद था, जहां हज़ारों लोग patch भेजते थे और upstream में डालने के लिए RMS के साथ भी अच्छी तालमेल रखनी पड़ती थी
नए टूल इस बात को support करते हैं कि बड़ी टीमें लगातार interact करें, और उस मॉडल के भी बड़े फ़ायदे हैं जिसमें छोटी टीम internet के किसी भी व्यक्ति की तब तक परवाह नहीं करती जब तक वह अपनी एक किडनी दांव पर लगाकर patch न भेजे
लेकिन लोगों को काम से जोड़ने के मामले में वह तरीका फ़ायदेमंद नहीं है, इसलिए पुराना तरीका अपनाया जा सकता है, पर टीम छोटी रहेगी और users को खींचना मुश्किल हो सकता है
फिर भी users को इससे क्या, मैं software अपने use case को support करने के लिए इस्तेमाल करता हूं, और बस इस उम्मीद में open source के रूप में जारी करता हूं कि शायद यह किसी और के भी काम आ जाए
और अधिक सटीक रूप से कहें तो, open source सिर्फ चार बुनियादी स्वतंत्रताओं का वादा करता है(https://en.wikipedia.org/wiki/The_Free_Software_Definition)
उसके अलावा यह शाब्दिक रूप से कुछ भी वादा नहीं करता, मुफ़्त होना भी नहीं
free/open source software के लिए पैसे लिए जा सकते हैं, और लेने भी चाहिए; यहां “free” का मतलब पैसे से नहीं है
हाल में कई communities में हुए open source “supply chain” हमलों को मैं काफ़ी सकारात्मक रूप से देखता हूं, क्योंकि आशावादी रूप से मुझे उम्मीद है कि इससे लोग समझेंगे कि open source supply chain नहीं है
अधिक विवरण यहां है: https://lobste.rs/s/cxwidw/no_one_owes_you_supply_chain_secu...
अगर आप किसी vendor को पैसे नहीं दे रहे, या आपके पास schedule guarantee वाला contract नहीं है, तो आपके पास supply chain है ही नहीं
लगभग सभी FOSS licenses में “यह software बिना warranty के दिया जाता है” जैसी शर्त होती है, और supply chain warranty का संकेत देती है, इसलिए FOSS supply chain नहीं है
यहां आकर यह देख-देखकर थक गया हूं कि “open source” को किसी “नैतिक मूल्य” वाला माना जाता है और free software से चुराए गए विचारों को ऐसे मिलाया जाता है जैसे दोनों एक ही हों
open source बस बड़ी software कंपनियों का असंख्य volunteers से लेना भर है
Code of Conduct वाले लोग बस समस्या पैदा करने के लिए होते हैं
red button/blue button बहस को ही देख लें; वह उग्र ज़हर तो तभी समझ आता है जब सचमुच कोई बटन हो या लोग बदतमीज़ी करना पसंद करते हों
अच्छे इरादे वाले Code of Conduct समर्थक association की स्वतंत्रता और अभिव्यक्ति की स्वतंत्रता की बात करते हैं
सवाल यह है कि अगर platform किसी पक्ष को नापसंद करता है तो क्या उसे ban करना ठीक है, या इसे mailing list की व्यावहारिक “शिष्ट रहो” परंपरा तक सीमित रखना चाहिए
बेशक यह इस पर निर्भर करता है कि निर्णय की शक्ति किसके हाथ में है, लेकिन यह तो किसी भी project में सच है
आप किसी और के project में भाग लेने की मांग करते हुए, project leadership की इच्छा के विपरीत शर्तें भी नहीं थोप सकते और साथ ही association की स्वतंत्रता का दावा भी नहीं कर सकते
मेरा अनुमान है कि लेखक का “दिखावटी Code of Conduct की ज़रूरत नहीं” कहने का मतलब यह हो सकता है कि अगर छोटा project बस दुनिया के साथ साझा करना चाहता है और बाद में बाहरी योगदान लेने का विकल्प खुला रखना चाहता है, तो वास्तविक स्थिति आने से पहले ही Code of Conduct तैयार रखना ज़रूरी नहीं
पूरी तरह काल्पनिक समस्याओं पर सिर खपाने की ज़रूरत नहीं
Code of Conduct होने का कारण यह है कि उसका विकल्प या तो मनमानी उल्लंघनों पर मनमाना दंड है, या फिर पूरी spam अराजकता
पहले जो लोग netiquette का उपदेश देते थे, अब वही स्पष्टता और स्वस्थ community के इतने खिलाफ़ हैं, यह समझ नहीं आता
दोबारा सोचूं तो शायद यह Goomba fallacy हो, और Code of Conduct से नफ़रत करने वाले वही लोग हों जो 1990s के Usenet पर लगातार flame wars और spam फैलाते थे
open source सिर्फ license चुनने का मामला नहीं है
यह free software का ऐसा पुनर्पैकेजिंग है जिसे कंपनियों के लिए अधिक आकर्षक बनाया गया, और open source का मूल यह है कि software को private तरीके से बनाने की तुलना में जनता के साथ मिलकर बनाना अधिक प्रभावी है
इसलिए open source खुली community का संकेत देता है
अगर आप permissive license के साथ code जनता के सामने रख दें लेकिन collaborative development न करना चाहें, तो बेशक ऐसा कर सकते हैं, और वह code open source code ही रहेगा
code खोलना अच्छी बात है और उससे ज़्यादा करने की कोई बाध्यता नहीं, लेकिन यह open source को उसके डिज़ाइन किए गए उद्देश्य के अनुसार करना नहीं है, बल्कि उसके एक मुख्य हिस्से को नज़रअंदाज़ करना है
open source code देखकर collaborative development मान लेना लोगों की तरफ़ से अविवेकपूर्ण नहीं है
क्योंकि open source movement का उद्देश्य यही था
अगर आपके software पर यह मान्यता लागू नहीं होती तो भी ठीक है, लेकिन सामाजिक मानक तोड़ने वाले वे नहीं, आप हैं
मुझे Stallman, printer driver, और users का अपने काम पर मालिकाना हक़ याद आता है, इसलिए open source के उद्देश्य पर ऐसा दावा मुझे सही नहीं लगता
https://en.wikipedia.org/wiki/The_Open_Source_Definition
वहां collaborative development के बारे में कुछ भी नहीं कहा गया है
लोग भावुक हो जाते हैं, और अक्सर नए users को संभालने लगते हैं जो basics सीखना नहीं चाहते
support forum से अलग लेकिन सख्त, समय पर जवाब देने वाला पर उदासीन संबंध बनाए रखना अच्छा है
coreboot या MrChromebox इसके अच्छे उदाहरण हैं; वह ज़रूरत पड़ने पर ही जवाब देता है
सहमत हूं, और एक बात और जोड़ूंगा: लोगों को software इस्तेमाल करने के लिए मनाने वाला marketing page बनाना भी ज़रूरी नहीं
इसके बजाय, या उसके साथ, यह बताना बेहतर हो सकता है कि यह software क्यों नहीं इस्तेमाल करना चाहिए
जितने ज़्यादा users, उतनी ज़्यादा समस्याएं
FOSS application का सार्वजनिक रूप से वितरित होना ज़रूरी नहीं है; यह बस एक आम सामाजिक अपेक्षा है
FOSS होने का मतलब यह भी नहीं कि code उन लोगों को दिया जाए जो customer नहीं हैं, और customer कौन है यह developer तय करता है
FOSS पैसे लेकर बेचने को प्रोत्साहित करता है, और आप किसी दूसरे का वह software भी बेच सकते हैं जो पहले से मुफ्त था (https://www.gnu.org/philosophy/selling.en.html देखें)
non-free license वाला open source अभी भी open source हो सकता है लेकिन non-FOSS होगा, और अगर developer software से अधिक पैसे कमाना चाहता है या अपने पक्ष में अतिरिक्त पाबंदियां लगाना चाहता है, तो non-free open source license चुनने में उसे शर्मिंदा होने की ज़रूरत नहीं
वह copyleft भी हो सकता है
सार यह है कि हम LICENSE.md बनाते हैं और उस पर बहुत निर्भर रहते हैं, लेकिन SOCIAL.md बनाने के बारे में किसी ने सोचा ही नहीं
जब कोई “open source” कहता है, तो बहुत से लोग मान लेते हैं, “लेखक लोगों, समाज और अपने आसपास की दुनिया के लिए बना रहा है, और project development, नए features जोड़ने, खासकर वे features जिनकी मुझे ज़रूरत है, और सभी users के फ़ायदे के लिए सुधारों में रुचि रखता है. नहीं तो फिर इसे public क्यों करता?”
लेकिन यह FOSS के बारे में बस सबसे आम सामाजिक अपेक्षा है, और एकमात्र स्थिति होने से बहुत दूर है
technical open source और social open source के बीच फ़र्क़ न होना असहमति, बहस, और अंततः ग़लत सामाजिक अपेक्षाओं से पैदा होने वाले burnout का मुख्य कारण है
पहले मुझे गुस्साई भीड़ को यह समस्या और यह फ़र्क़ समझाना पड़ता था, लेकिन हाल में Jeffrey Paul के लेख https://sneak.berlin/20250720/the-agpl-is-nonfree/ में open source code की तुलना gift से की हुई देखी
मेरी अपनी व्याख्या आख़िरकार यही थी: “अगर gift पसंद नहीं और फिट नहीं बैठता, तो उसे फेंक दो और भूल जाओ”
OSI द्वारा approved लेकिन free software न मानी जाने वाली licenses बस कुछ ही हैं
https://www.gnu.org/licenses/license-list.html में GPL-compatible न होने वाली free software licenses की लंबी सूची देखी जा सकती है
और फिर “non-FOSS open source” कहना भी बेमानी है, क्योंकि FOSS का शाब्दिक अर्थ ही Free and Open Source Software है
अब तो लगभग सीधे GitHub पर executable के साथ चीज़ें डाल दी जाती हैं, बिना किसी संदिग्ध website या अजीब build pipeline से गुज़रे, और कोई भी उन्हें इस्तेमाल कर सकता है
न “community”, न politics, न Code of Conduct, न pull request या issue, न wiki, न core team — सुनने में तो स्वर्ग जैसा लगता है
आजकल लगता है कि ऐसी community बहुत ज़्यादा हैं जो खुद project के लिए नुकसानदेह होती हैं
इससे भी आगे बढ़कर, मुझे एक भी बार याद नहीं आता कि किसी community ने किसी open source project की किसी भी तरह मदद की हो
अगर लक्ष्य quality की कीमत पर control को अधिकतम करना है, तो ठीक है
लेकिन उस स्थिति में यह सवाल उठता है कि क्या आप सच में FLOSS ढूंढ़ रहे हैं