- gem.coop Ruby ecosystem के लिए एक नया gem server है
- इसे RubyGems.org की पूर्व संचालन टीम ने कम्युनिटी के लिए बनाया है
- यह RubyGems.org के सभी public gem को real-time sync के साथ उपलब्ध कराता है
- Homebrew से प्रेरित governance के तहत यह transparency और community participation को महत्व देता है
- इसका लक्ष्य टिकाऊ और security-enhanced gem hosting है
gem.coop परिचय
- gem.coop Ruby ecosystem के लिए डिज़ाइन किया गया एक नया gem server है, जिसे तेज़ और सरल hosting environment देने के लक्ष्य से बनाया गया है
- Bundler के साथ पूर्ण compatibility बनाए रखते हुए, यह अगली पीढ़ी के development environment के लिए optimized performance और reliability पर ज़ोर देता है
- यह प्रोजेक्ट RubyGems.org के पूर्व administrators और संचालन टीम की सीधी भागीदारी से कम्युनिटी के लिए एक सेवा के रूप में विकसित किया गया है
- सभी public gem RubyGems.org से real-time में sync होते हैं, इसलिए वे gem.coop पर भी तुरंत उपयोग के लिए उपलब्ध हैं
- मौजूदा Gemfile में केवल source address बदलकर इसका उपयोग किया जा सकता है, इसलिए इसे अपनाना बहुत आसान है
Governance और community participation
- Homebrew प्रोजेक्ट के governance model को संदर्भ के रूप में लेकर एक पारदर्शी और आसानी से सहभागी संरचना अपनाई गई है
- Mike McQuaid के सहयोग से organization setup और operation method तैयार किए जा रहे हैं, और 10 अक्टूबर से पहले आधिकारिक governance structure सार्वजनिक करने की योजना है
- Ruby community में कोई भी contribution और participation कर सके, इसके लिए इसे एक खुले ढांचे में चलाने की योजना है
सेवा के लक्ष्य और आगे की योजना
- gem.coop का अंतिम लक्ष्य community-owned, तेज़, पारदर्शी, टिकाऊ और security-enhanced gem hosting platform उपलब्ध कराना है
- शुरुआती चरण में यह सभी public gem की bundling और installation को support करता है, और आगे चलकर features तथा quality में लगातार सुधार किया जाएगा
- gem.coop newsletter के माध्यम से मासिक updates प्राप्त किए जा सकते हैं
टीम संरचना
- development और operations का नेतृत्व Gem Cooperative के तहत deivid-rodriguez, duckinator, indirect, martinemde, segiddins, simi कर रहे हैं
1 टिप्पणियां
Hacker News राय
सारी विवादित बातों को एक तरफ रखें तो, अभी मूल RubyGems की स्थिति यह है कि उसके सभी maintainers जा चुके हैं, और नए प्रोजेक्ट में पुराने core contributors में से ज़्यादातर शामिल हैं। पहले deivid की मौजूदगी सबसे स्पष्ट थी, लेकिन अब लगता है कि ज़्यादातर प्रमुख लोग इसी तरफ आ गए हैं। अब यह fork ज़्यादा अच्छी तरह maintain किया गया software लग रहा है। क्या लोगों के जल्द ही इधर आने की संभावना है, और funding model या hosting cost burden के बारे में कोई जानकारी है? अतिरिक्त जानकारी यहाँ भी है
अभी यह fork ज़्यादा अच्छी तरह maintain किए गए software जैसा दिख सकता है, लेकिन असल में महत्वपूर्ण चीज़ software से ज़्यादा indexing service का storage और bandwidth होगा। मुझे लगता है कि एक साधारण gem search engine hashes store करे और download को बाहर, जैसे GitHub जैसी repos की ओर point करे, तब भी शायद यह ठीक से काम कर सकता है
यह स्थिति थोड़ी कड़वी लगती है। अगर यह fork सफल होता है, तो JS दुनिया की तरह “कौन-सा package manager इस्तेमाल करें?” जैसा सवाल उठेगा। “बस bundler और rubygems इस्तेमाल करो” वाली जो खूबसूरत सादगी थी, वह खत्म हो जाएगी। फिर भी, RubyGems के पुराने maintainers, जिनके साथ नाइंसाफी हुई, उन्होंने सार्वजनिक रूप से मुद्दा उठाने के बाद शांति से fork पर काम शुरू किया—इसके लिए मैं उनकी बहुत सराहना करता हूँ। RubyGems का fork असंभव-सा लगता था, लेकिन अब वे कम से कम एक छोटी-सी संभावना बना रहे हैं। बड़ी कंपनियाँ शायद ज़्यादातर Shopify-backed RC के साथ ही रहेंगी, और ऐसे संगठनों में security audits भी मज़बूत होंगे, लेकिन innovation कम होगा। दूसरी तरफ, अगर gems.coop सफल होता है, तो वह सिर्फ इसलिए होगा क्योंकि वह “बेहतर tool” बन जाएगा। उदाहरण के लिए, André का rv.dev Ruby version management, gem dependencies, और npx जैसी functionality तक support करने वाला “fast and all-in-one” tool है, इसलिए developer experience (DX) के लिहाज़ से आगे हो सकता है। namespace, checksum, और तकनीकी रूप से ज़्यादा आक्रामक security approaches जैसी बातें भी चर्चा में हैं, और अगर RC ऐसे ही चलता रहा, तो अंततः तकनीकी रूप से श्रेष्ठ पक्ष जीत सकता है। funding के मामले में, André शायद यह मानता है कि “जो संगठन OSS infrastructure की लागत उठा सकते हैं, उन्हें वास्तव में भुगतान करना चाहिए”, और मैं इससे सहमत हूँ। इससे लागत का साफ़ अनुमान लगाकर भुगतान करने वाली कंपनियों के बीच पारदर्शी तरीके से बाँटा जा सकता है। अंत में, मुझे लगता है कि RC के इस तरह बिगड़ने की जड़ यही थी कि funding बहुत कम sponsors में केंद्रित हो गई थी, इसलिए उम्मीद है Ruby Co-op 100, 1000 या उससे भी अधिक लोगों वाला distributed funding model बनाएगा
ध्यान रहे कि funding model अभी तय नहीं हुआ है। संबंधित लिंक
आधिकारिक पेज पर जानकारी बहुत कम है। इसलिए तर्क से कुछ अनुमान लगाऊँ तो: 1) distribution के लिए RubyGems पर निर्भर रहना ही पड़ेगा। 2) gem search और view के लिए UI नहीं है, इसलिए RubyGems पर निर्भरता है। तकनीकी बारीकियों से अलग, मेरे लिए बदलाव का कोई व्यावहारिक कारण नहीं है जब तक कि मैं fork maintainers से वैचारिक रूप से सहमत न होऊँ। पेशेवर मकसद से जाने का कारण नहीं है, और अगर व्यक्तिगत रुचि हो तो बस याद रख लेने लायक बात है। ज़्यादातर forks की तरह, या तो यह अपना लक्ष्य पाकर फिर merge हो जाएगा, या नया standard बन जाएगा, या भुला दिया जाएगा। अगर इसका मुझ पर सीधा असर नहीं है, तो मैं बस देखता रहूँगा। मैं इनके मुद्दों या काम को कमतर नहीं बता रहा, लेकिन DHH की वजह से Rails को fork करने की तुलना में यह स्थिति कहीं ज़्यादा विश्वसनीय लगती है
पिछले 10 सालों में ruby gems या bundler में ऐसा कोई नया feature याद नहीं आता जो मुझे खास लगा हो या ज़रूरी लगा हो। यक़ीनन नए features आए होंगे, लेकिन मेरी नज़र में नहीं आए
Andre Arko की प्रतिष्ठा को देखते हुए (जैसा कि हाल की इस पोस्ट में संक्षेप में बताया गया है), मैं इस कदम के पीछे की प्रेरणा को लेकर थोड़ा सतर्क हूँ
वह पोस्ट मुझे निजी दुश्मनी पर आधारित हमला-लेख जैसी लगती है। राय बनाते समय उसे बहुत ज़्यादा वज़न न दें, यही सलाह दूँगा
सबसे नकारात्मक परिदृश्य में बात कुछ ऐसी हो सकती है: uv एक शानदार tool है, लेकिन Astral का paid services के साथ integration का इरादा साफ़ दिखता है। यह एक तरह का lock-in है। और एक नज़रिया यह है कि Andre और उनकी टीम ने Python दुनिया से (uv की सफलता की तरह) संकेत लेकर Ruby में वही करने की कोशिश की है। rv की घोषणा करते हुए वे Ruby Gems को अपने ऊपर निर्भर बनाना चाहते हैं, और Hashicorp जैसे उदाहरणों को देखें तो लोगों को free में खींचकर ज़रूरी functionality को enterprise paywall के पीछे रखना अब बढ़ता चलन है। Ruby ecosystem का किसी एक व्यक्ति या छोटे समूह पर निर्भर हो जाना, मेरे हिसाब से, अभी के Ruby Central जितना ही ख़तरनाक है
यह देखकर हैरानी होती है कि open source community इस तरह साथ आकर समाधान खोज रही है। इस प्रक्रिया में मेहनत करने वाले सभी लोगों को धन्यवाद कहना चाहता हूँ
मेरे मन में सवाल है, हम git को नए standard की ओर क्यों नहीं ले जाते? commit signing, tag signing, distributed structure वगैरह को देखते हुए क्या यह कहीं बेहतर विकल्प नहीं लगता?
git protocol की complexity ज़्यादा है और scalability कमज़ोर है। खासकर अगर हर बार CI में सभी packages फिर से download करने पड़ें तो यह अप्रभावी होगा। single-file archive को distribute करना कहीं आसान है। digest और signing algorithms सिर्फ git की चीज़ नहीं हैं, और key तथा identity management ज़्यादा कठिन हिस्सा है; git इसे भी पूरी तरह हल नहीं करता (मतलब git और GitHub को एक न समझें)
किसी न किसी को git server चलाना होगा, और हर gem के लिए वही git server खोजकर Pull करना होगा। सभी git servers के पास latest versions भी नहीं होंगे, इसलिए हर एक को अलग-अलग scale करना पड़ेगा। centralization का फ़ायदा यह है कि सब कुछ एक जगह होता है, scaling एक साथ होती है, और updates भी एक साथ लागू होते हैं। पहले artifactory वगैरह के साथ NPM, package managers, docker containers को proxy किया जाता था, और बीच की service बंद हो जाने पर भी deployment में समस्या नहीं होती थी। लेकिन छोटे developers या teams के लिए ऐसा प्रबंधन अनावश्यक overhead लग सकता है
दरअसल rubygems (software) पहले से ही किसी भी git repo से packages ला सकता है। एक हद तक यह पहले से supported है
Go language पहले से ही ऐसा approach अपना रही है
Go के packaging ecosystem को देखने के बाद भी क्या git पर जाना अच्छा विचार लगता है, यह सोचने वाली बात है
सबसे महत्वपूर्ण बात यह है कि वे कम से कम git repo का link तो दे सकते थे ताकि बाहर से दिखे कि project को कैसे maintain किया जा रहा है, लेकिन अभी ऐसा नहीं है। maintainers की सूची तो है, पर git repo link नहीं, इसलिए मुझे यह code से ज़्यादा लोगों-केंद्रित project लगा
अगर यह package repository है, तो मुझे नहीं लगता कि Ansible repo जैसे links पहली announcement में ज़रूरी हैं। package repository में सबसे महत्वपूर्ण चीज़ trust है। RubyGems में जो hostile takeover हुआ, उसने उस भरोसे को तोड़ा, और जो मूल maintainers बाहर कर दिए गए थे, उन्हीं के सीधे चलाए गए विकल्प का उभरना उल्टा एक अच्छा बदलाव है। बल्कि ऐसा लगता है कि तुमने पहले से निष्कर्ष तय कर लिया है और अब बस बहाने जोड़ रहे हो। वैसे भी, rubygems.org के main page पर भी git repo link खास दिखता नहीं है
source यहाँ है
हाल की विवादित घटनाओं को अलग रखें, तो मैं सोच रहा हूँ कि open source ecosystem के लिए compatible alternative package source, manager, या version manager होना तटस्थ, सकारात्मक, या नकारात्मक चीज़ है
मैं समझता हूँ कि कभी-कभी fork ज़रूरी होता है, लेकिन यह भावना थोड़ी कड़वी है कि आपस में तालमेल नहीं बन पाया। अगर सबका साझा लक्ष्य Ruby ecosystem को आगे बढ़ाना है, तो राजनीतिक पृष्ठभूमि या निजी मतभेदों के बावजूद सहयोग संभव होना चाहिए। पहले भी Merb और Rails, Bundler और RubyGems, RubyTogether और RubyCentral आखिरकार साथ आए थे, इसलिए उम्मीद है कि किसी दिन यह भी सुलझ जाएगा
मुझे लगता है कि अगर gem distribution/download का तरीका बदला जाए तो इस तरह की समस्या हल हो सकती है। लेकिन समस्या यह है कि वह बदलाव वही लोग ला सकते हैं जो अभी software और infrastructure को control कर रहे हैं, और उनके पास सुधार की खास प्रेरणा नहीं है। यह पूरी स्थिति ही बेतुकी लगती है, और DHH के प्रति इतनी नाराज़गी क्यों है, यह भी समझ नहीं आता। open source project को नुकसान पहुँचाने का सबसे आसान तरीका यही drama और forks हैं, इसलिए यह दुखद है। Ruby पुरानी भाषा होने के बावजूद इसका user base बहुत बड़ा नहीं है, और इस तरह के विवाद पूरे ecosystem को नुकसान पहुँचा रहे हैं—एक पूर्व Ruby developer के रूप में यह मुझे दुखी करता है
मुझे लगता है कि यह RubyGems GitHub repo और organization के Ruby Central द्वारा hostile takeover के जवाब में उठाया गया एक बेहतरीन कदम है। उम्मीद है hosting costs के लिए वित्तीय सहायता की व्यवस्था होगी