Open source का मतलब open community नहीं होता

 (blog.feld.me)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 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 का मिश्रण लगता हो

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 1 시간 전
Lobste.rs की राय

  • इसी सोच की वजह से https://casuallymaintained.tech/ बनाया था, और यह बहुत पसंद आया

  • सबसे मशहूर उदाहरण SQLite है, जो बाहरी योगदान स्वीकार नहीं करता
    यह देखते हुए कि इसका इस्तेमाल Airbus विमान जैसे mission-critical applications में भी होता है, यह एक उचित नीति लगती है

    • SQLite बाहरी योगदान को अस्वीकार नहीं करता. copyright page पर यह बात साफ़ लिखी है
      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 को दिखावे का हिस्सा कहने वाली बात थोड़ी अलग-सी लगी, लेकिन विषय संवेदनशील है इसलिए समझ में आता है

    • इसका मतलब यह नहीं कि हर 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 लगता है