- gem.coop adalah server gem baru untuk ekosistem Ruby
- Dibangun oleh mantan tim operasional RubyGems.org untuk komunitas
- Menyediakan semua gem publik dari RubyGems.org melalui sinkronisasi real-time
- Mengutamakan transparansi dan partisipasi komunitas dengan tata kelola yang terinspirasi dari Homebrew
- Bertujuan menjadi hosting gem yang berkelanjutan dan diperkuat keamanannya
Pengenalan gem.coop
- gem.coop adalah server gem baru yang dirancang untuk ekosistem Ruby, dengan tujuan menyediakan lingkungan hosting yang lebih cepat dan sederhana
- Sambil mempertahankan kompatibilitas penuh dengan Bundler, layanan ini menekankan performa dan stabilitas yang dioptimalkan untuk lingkungan pengembangan generasi berikutnya
- Proyek ini dikembangkan sebagai layanan untuk komunitas dengan keterlibatan langsung dari mantan administrator dan tim operasional RubyGems.org
- Semua gem publik disinkronkan dari RubyGems.org secara real-time sehingga langsung dapat digunakan juga di gem.coop
- Dapat digunakan hanya dengan mengganti alamat source di Gemfile yang sudah ada, sehingga cara penerapannya sangat mudah
Tata kelola dan partisipasi komunitas
- Mengadopsi struktur yang transparan dan mudah diikuti dengan merujuk pada model tata kelola proyek Homebrew
- Dengan dukungan Mike McQuaid, penyiapan organisasi dan metode operasional sedang dipersiapkan, dan bentuk tata kelola resminya dijadwalkan diumumkan sebelum 10 Oktober
- Direncanakan untuk beroperasi sebagai struktur terbuka agar siapa pun di komunitas Ruby dapat berkontribusi dan berpartisipasi
Tujuan layanan dan rencana ke depan
- Tujuan akhir gem.coop adalah menyediakan platform hosting gem milik komunitas yang cepat, transparan, berkelanjutan, dan memiliki keamanan yang ditingkatkan
- Pada tahap awal, layanan ini mendukung bundling dan instalasi semua gem publik, lalu akan terus meningkatkan fitur dan kualitasnya ke depannya
- Pembaruan bulanan dapat diterima melalui newsletter gem.coop
Susunan tim
- Pengembangan dan operasional dijalankan oleh Gem Cooperative, dipimpin oleh deivid-rodriguez, duckinator, indirect, martinemde, segiddins, dan simi
1 komentar
Opini Hacker News
Terlepas dari semua kontroversi, saat ini semua maintainer RubyGems yang lama sudah pergi, dan tampaknya sebagian besar kontributor inti sebelumnya kini terlibat dalam proyek baru ini. Dulu hanya deivid yang terlihat menonjol, tetapi sekarang sepertinya sebagian besar tokoh utama sudah pindah ke sini. Sekarang fork ini terasa seperti software yang dikelola dengan lebih baik. Saya penasaran apakah orang-orang akan segera berpindah ke sini, dan apakah ada informasi tentang model pendanaan atau beban biaya hosting. Info tambahan juga ada di sini
Saat ini fork ini memang tampak seperti software yang lebih terkelola, tetapi yang benar-benar penting mungkin bukan softwarenya sendiri melainkan penyimpanan dan bandwidth layanan indexing. Saya membayangkan mesin pencarian gem cukup menyimpan hash dan mengarahkan unduhan ke repo eksternal seperti GitHub, dan itu mungkin sudah bisa berjalan dengan baik
Situasi ini agak pahit. Jika fork ini berhasil, maka Ruby bisa menjadi seperti dunia JS, di mana orang harus berpikir "pakai package manager yang mana?" Kesederhanaan indah dari "cukup pakai bundler dan rubygems" akan hilang. Meski begitu, saya sangat memuji para maintainer lama RubyGems yang merasa diperlakukan tidak adil karena mereka lebih dulu menyuarakan masalah ini secara terbuka lalu diam-diam mulai mengerjakan fork. Fork RubyGems dulu terasa mustahil, tetapi sekarang mereka setidaknya sedang membuka kemungkinan kecil itu. Perusahaan-perusahaan besar kemungkinan besar akan tetap berada di RC yang didukung Shopify, dan organisasi seperti itu mungkin juga akan memperketat audit keamanan, tetapi saya rasa inovasinya akan minim. Sebaliknya, jika gems.coop berhasil, itu karena ia benar-benar menjadi "alat yang lebih baik". Misalnya, rv.dev buatan André tampaknya akan unggul dari sisi developer experience (DX) sebagai alat "cepat dan all-in-one" yang mendukung manajemen versi Ruby, dependensi gem, bahkan fitur seperti npx. Namespace, checksum, dan pendekatan keamanan yang secara teknis lebih agresif juga sedang dibahas, dan jika RC terus berjalan seperti sekarang, saya rasa pihak yang secara teknis lebih unggul bisa saja menang pada akhirnya. Dari sisi pendanaan, André tampaknya berpendapat bahwa "organisasi yang mampu menanggung biaya infrastruktur OSS memang harus membayar", dan saya setuju. Dengan begitu, biayanya bisa diprediksi dengan akurat dan dibagi secara transparan berdasarkan jumlah perusahaan yang membayar. Terakhir, saya rasa akar masalah RC yang rusak seperti sekarang adalah karena pendanaan terlalu terkonsentrasi pada sedikit sponsor, dan saya berharap Ruby Co-op bisa membangun model pendanaan yang lebih terdistribusi dengan 100 atau 1000+ pendukung
Sebagai catatan, model pendanaannya masih belum ditentukan. Tautan terkait
Informasi di halaman resminya terlalu minim. Jadi kalau diasumsikan secara logis: 1) distribusi pada akhirnya tetap harus bergantung pada RubyGems. 2) Tidak ada UI untuk pencarian dan tampilan gem, jadi tetap bergantung pada RubyGems. Terlepas dari detail teknisnya, secara praktis saya tidak punya alasan sama sekali untuk beralih kecuali saya sepakat secara ideologis dengan para maintainer fork ini. Untuk tujuan profesional, tidak ada alasan untuk pindah, dan kalau secara pribadi tertarik mungkin cukup diingat saja. Seperti kebanyakan fork, nanti hasil akhirnya biasanya salah satu dari tiga: tujuan tercapai lalu digabung kembali, menjadi standar baru, atau dilupakan. Kalau saya tidak terdampak langsung, saya akan menonton saja dari jauh. Ini bukan untuk meremehkan masalah yang mereka angkat atau kerja yang mereka lakukan, dan situasinya jauh lebih meyakinkan daripada misalnya mem-fork Rails karena DHH
Selama 10 tahun terakhir, saya tidak bisa mengingat fitur baru di ruby gems atau bundler yang benar-benar menonjol atau terasa perlu. Pasti ada fitur baru, tetapi saya sendiri tidak menyadarinya
Melihat reputasi Andre Arko (seperti yang dirangkum dalam tulisan ini baru-baru ini), saya agak waspada soal apa sebenarnya motivasi di balik langkah ini
Tulisan itu terlihat seperti serangan yang didasari dendam pribadi. Saya sarankan jangan memberi bobot terlalu besar saat menilainya
Kalau dilihat dari skenario paling negatif, gambarnya seperti ini: uv adalah alat yang keren, tetapi Astral jelas berencana mengaitkannya dengan layanan berbayar. Itu semacam menciptakan hambatan masuk. Lalu ada pandangan bahwa Andre dan timnya mendapat inspirasi dari dunia Python (seperti keberhasilan uv) dan ingin melakukan hal yang sama di Ruby. Dengan mengumumkan rv, mereka ingin membuat Ruby Gems bergantung pada mereka, dan jika melihat kasus seperti Hashicorp, makin sering kita melihat pola menarik pengguna dengan versi gratis lalu menaruh fitur penting di balik paywall enterprise. Menurut saya, ekosistem Ruby menjadi bergantung pada satu orang atau kelompok kecil akan sama berbahayanya dengan kondisi Ruby Central saat ini
Melihat komunitas open source bisa bersatu seperti ini untuk mencari solusi sungguh mengagumkan. Saya ingin mengucapkan terima kasih kepada semua yang sudah berkontribusi dalam proses ini
Ini cuma pendapat saya, tetapi saya penasaran kenapa tidak memindahkan standar baru ke git saja. Bukankah itu tampak seperti alternatif yang jauh lebih baik dengan commit signing, tag signing, dan sifatnya yang terdistribusi?
Protokol git punya kompleksitas tinggi dan skalabilitasnya kurang baik. Terutama jika semua paket harus diunduh ulang di CI setiap kali, itu jadi tidak efisien. Arsip file tunggal jauh lebih mudah didistribusikan. Digest dan algoritma tanda tangan juga bukan sesuatu yang eksklusif milik git, dan bagian yang lebih sulit justru manajemen kunci dan identitas, yang juga tidak sepenuhnya diselesaikan oleh git (maksudnya jangan mencampuradukkan git dengan GitHub)
Tetap harus ada seseorang yang menjalankan server git, lalu untuk tiap gem harus ditemukan dan di-pull dari server git tersebut. Tidak semua server git juga akan memiliki versi terbaru, jadi masing-masing harus melakukan scaling sendiri. Keuntungan sentralisasi adalah semuanya berada di satu tempat, scaling cukup dilakukan sekali, dan pembaruan bisa diterapkan bersamaan. Dulu saya pernah memakai proxy seperti artifactory untuk NPM, package manager, dan container docker, jadi walaupun layanan perantara mati, deployment tetap bisa dilakukan tanpa masalah. Tetapi bagi developer atau tim kecil, pengelolaan seperti ini terasa sebagai overhead yang tidak perlu
Sebenarnya rubygems (softwarenya) sudah bisa mengambil paket dari repo git mana pun. Sampai tingkat tertentu, ini memang sudah didukung
Bahasa Go sudah lebih dulu mengadopsi pendekatan seperti itu
Setelah melihat ekosistem packaging Go, saya ragu beralih ke git itu benar-benar ide yang bagus
Hal terpenting bagi saya adalah mereka setidaknya bisa menaruh tautan ke repo git agar orang luar bisa melihat bagaimana proyek ini dipelihara, tetapi sekarang itu tidak ada. Ada daftar maintainer, tetapi tidak ada tautan ke repo git, jadi saya mendapat kesan bahwa ini lebih berpusat pada orang daripada kode
Kalau ini gudang paket, saya rasa tautan seperti repo Ansible tidak harus ada di pengumuman pertama. Hal terpenting dari package repository adalah kepercayaan. Pengambilalihan paksa yang terjadi pada RubyGems merusak kepercayaan itu, dan alternatif yang dijalankan langsung oleh maintainer asli yang disingkirkan justru merupakan perubahan yang baik. Malah terkesan kamu sudah lebih dulu menarik kesimpulan lalu hanya mencari-cari alasan. Sebagai referensi, di halaman utama rubygems.org juga tautan repo git tidak terlalu terlihat
Sumbernya ada di sini
Kalau mengesampingkan kontroversi baru-baru ini, saya jadi berpikir apakah sumber paket, manager, atau version manager alternatif yang kompatibel itu netral, positif, atau negatif bagi ekosistem open source
Saya paham ada kalanya fork memang diperlukan, tetapi tetap terasa agak pahit bahwa mereka tidak bisa menyelaraskan diri. Jika semua punya tujuan bersama untuk memajukan ekosistem Ruby, saya pikir seharusnya mereka masih bisa bekerja sama meskipun ada latar belakang politik atau perbedaan pendapat pribadi. Merb dan Rails, Bundler dan RubyGems, RubyTogether dan RubyCentral pada akhirnya juga menyatu, jadi saya berharap suatu hari ini pun akan terselesaikan
Saya rasa masalah seperti ini bisa diselesaikan jika cara distribusi dan pengunduhan gem dirombak. Hanya saja, pihak yang bisa mendorong perubahan itu adalah mereka yang saat ini mengendalikan software dan infrastrukturnya, dan masalahnya mereka tampaknya tidak punya banyak motivasi untuk memperbaikinya. Situasi seperti ini sendiri terasa tidak masuk akal, dan saya juga tidak mengerti asal sentimen negatif terhadap DHH. Sangat disayangkan, karena drama dan fork seperti ini adalah cara termudah untuk merusak proyek open source. Ruby sudah bahasa yang tua dan basis penggunanya juga tidak terlalu besar, jadi kontroversi seperti ini merugikan seluruh ekosistem. Sebagai mantan developer Ruby, saya merasa sedih melihatnya
Menurut saya ini langkah yang sangat baik untuk merespons secara efektif situasi ketika repo dan organisasi GitHub RubyGems diambil alih secara paksa oleh Ruby Central. Semoga ada dukungan finansial untuk biaya hosting