- gem.coop, Ruby ekosistemi için yeni bir gem sunucusudur
- RubyGems.org'un eski operasyon ekibi tarafından topluluk için oluşturuldu
- RubyGems.org’daki tüm herkese açık gem’leri gerçek zamanlı senkronizasyonla sunar
- Homebrew’den ilham alan bir yönetişimle şeffaflık ve topluluk katılımına önem verir
- Sürdürülebilir ve güvenliği güçlendirilmiş bir gem barındırma hizmetini hedefler
gem.coop tanıtımı
- gem.coop, Ruby ekosistemi için tasarlanmış yeni bir gem sunucusudur; daha hızlı ve daha basit bir barındırma ortamı sunmayı hedefler
- Bundler ile tam uyumluluğu korurken, yeni nesil geliştirme ortamlarına uygun performans ve kararlılığı öne çıkarır
- Proje, RubyGems.org'un eski yöneticileri ve operasyon ekibinin doğrudan katılımıyla topluluk için geliştirilen bir hizmettir
- Tüm herkese açık gem’ler RubyGems.org’dan gerçek zamanlı olarak senkronize edilir ve gem.coop üzerinde de hemen kullanılabilir
- Mevcut Gemfile’da yalnızca source adresini değiştirerek kullanılabildiği için geçiş süreci oldukça kolaydır
Yönetişim ve topluluk katılımı
- Homebrew projesinin yönetişim modelini örnek alarak şeffaf ve katılımı kolay bir yapı benimser
- Mike McQuaid’in desteğiyle organizasyon yapısı ve işletim modeli hazırlanıyor; resmi yönetişim yapısının 10 Ekim’den önce açıklanması planlanıyor
- Ruby topluluğundaki herkesin katkı sunabileceği ve sürece dahil olabileceği açık bir yapıyla işletilmesi planlanıyor
Hizmet hedefleri ve gelecek planları
- gem.coop’un nihai hedefi, topluluğun sahip olduğu; hızlı, şeffaf, sürdürülebilir ve güvenliği güçlendirilmiş bir gem barındırma platformu sunmaktır
- İlk aşamada tüm herkese açık gem’lerin bundling ve kurulumunu destekler; ileride özellikler ve kalite sürekli olarak geliştirilecektir
- gem.coop bülteni üzerinden aylık güncellemeler alınabilir
Ekip
- Geliştirme ve operasyon, Gem Cooperative bünyesinde deivid-rodriguez, duckinator, indirect, martinemde, segiddins ve simi tarafından yürütülüyor
1 yorum
Hacker News görüşü
Tüm tartışmaları bir kenara bırakırsak, şu anda asıl RubyGems’in tüm bakımcıları ayrılmış durumda ve yeni projede de eski çekirdek katkıcıların çoğunun yer aldığı görülüyor. Eskiden yalnızca deivid belirgin bir figürdü ama şimdi başlıca isimlerin çoğu bu tarafa geçmiş gibi duruyor. Bu fork artık daha iyi bakılan bir yazılım gibi hissettiriyor. İnsanların yakında buraya geçip geçmeyeceğini ve finansman modeli ya da barındırma maliyetlerinin nasıl karşılanacağına dair bilgi olup olmadığını merak ediyorum. Ek bilgi burada da var
Bu fork şu anda daha iyi yönetilen yazılım gibi görünebilir, ancak asıl önemli olanın yazılımın kendisinden çok indeksleme hizmetinin depolama ve bant genişliği olduğunu düşünüyorum. Basitçe, gem arama motoru yalnızca hash’leri saklayıp indirmeleri GitHub gibi harici bir depoya yönlendirse yine gayet iyi çalışmaz mı diye düşünüyorum
Bu durum biraz buruk hissettiriyor. Eğer bu fork başarılı olursa, JS dünyasındaki gibi “hangi paket yöneticisini kullanalım?” diye düşünmek zorunda kalacağız. Eskiden var olan “sadece bundler ve rubygems kullan” şeklindeki güzel sadelik kaybolacak. Yine de haksızlığa uğrayan eski RubyGems bakımcılarının, sorunu kamuoyu önünde dile getirip ardından sessizce fork üzerinde çalışmaya başlamasını gerçekten takdir ediyorum. RubyGems’i fork etmek imkânsız gibi görünüyordu ama şimdi en azından küçük bir ihtimali gerçeğe dönüştürüyorlar. Büyük şirketlerin çoğu muhtemelen Shopify’ın desteklediği RC’de kalacaktır; bu tür organizasyonlarda güvenlik denetimleri de daha güçlü olabilir ama yenilik az olur diye düşünüyorum. Öte yandan gems.coop başarılı olursa bunun nedeni basitçe “daha iyi araç” haline gelmesi olacaktır. Örneğin André’nin geliştirdiği rv.dev, Ruby sürüm yönetimi, gem bağımlılıkları ve npx benzeri işlevleri destekleyen “hızlı ve hepsi bir arada” bir araç; bu yüzden geliştirici deneyimi (DX) açısından öne çıkacaktır. Namespace’ler, checksum’lar, teknik olarak daha agresif güvenlik yaklaşımları da konuşuluyor ve RC bu şekilde devam ederse sonunda teknik olarak üstün olan tarafın kazanabileceğini düşünüyorum. Finansman tarafında ise André’nin, “OSS altyapısının maliyetini karşılayabilen kuruluşlar gerçekten ödeme yapmalı” görüşünde olduğu anlaşılıyor; ben de buna katılıyorum. Böylece maliyetlerin net biçimde öngörüldüğü ve ödeme yapan şirket sayısına göre paylaştırıldığı şeffaf bir model oluşabilir. Son olarak, RC’nin bu kadar bozulmasının temel nedeninin fonun birkaç sponsorda aşırı yoğunlaşması olduğunu düşünüyorum; Ruby Co-op’un 100, 1000 veya daha fazla kişiye yayılan dağıtık bir finansman modeli kurmasını umuyorum
Finansman modelinin henüz belirlenmediğini not düşeyim. İlgili bağlantı
Resmî sayfada bilgi çok az. O yüzden mantıksal olarak birkaç varsayım yaparsak: 1) Dağıtım için RubyGems’e bağımlı kalmak zorundalar. 2) gem arama ve görüntüleme için bir arayüzleri olmadığından RubyGems’e bağımlılar. Teknik ayrıntıları bir kenara bırakırsak, ben bu fork’un bakımcılarıyla ideolojik olarak aynı fikirde olmadıkça geçiş yapmam için pratikte hiçbir neden yok. Profesyonel amaçlarla geçmek için sebep yok; kişisel olarak ilgimi çekerse aklımın bir köşesinde tutarım. Çoğu fork’ta olduğu gibi ya hedefe ulaşıp yeniden birleşir, ya tamamen yeni standart olur, ya da unutulur gider. Beni doğrudan etkilemiyorsa ben sadece izlerim. Bunu onların ortaya koyduğu sorunları ya da çalışmayı küçümsemek için söylemiyorum; ama bu durum, DHH yüzünden Rails’i fork etme fikrinden çok daha ikna edici
Son 10 yılda ruby gems ya da bundler’da aklımda kalan ya da gerçekten gerekli hissettiren yeni bir özellik hatırlamıyorum. Elbette yeni şeyler olmuştur ama ben fark etmedim
Andre Arko hakkındaki itibara bakınca (yakın zamanda şu yazıda özetlendiği gibi), bu girişimin motivasyonuna biraz temkinli yaklaşıyorum
O yazı kişisel husumete dayalı bir saldırı gibi görünüyor. Değerlendirme yaparken ona fazla ağırlık vermemenizi tavsiye ederim
En olumsuz senaryoya göre durum şu olabilir: uv harika bir araç ama Astral’ın ücretli servislerle entegrasyonu açıkça planladığı görülüyor. Bu tür şeyler bir çeşit giriş engeli yaratıyor. Ve bazıları Andre ile ekibinin Python dünyasından (uv’nin başarısından) esinlenip aynı şeyi Ruby’de yapmaya çalıştığını düşünüyor. rv’yi duyurarak Ruby Gems’i kendilerine bağımlı hale getirmeye çalışıyorlar; Hashicorp ve benzeri örneklerde gördüğümüz gibi, kullanıcıları ücretsiz katmana çekip kritik işlevleri kurumsal ücret duvarının arkasına koymak giderek daha sık görülüyor. Ruby ekosisteminin belirli bir kişiye ya da küçük bir gruba bağımlı hale gelmesi, bugün Ruby Central için geçerli olan riskin aynısını taşır diye düşünüyorum
Açık kaynak topluluğunun böyle bir çözüm bulmak için bu kadar birlik içinde hareket etmesi etkileyici. Bu sürece emek veren herkese teşekkür etmek isterim
Aklıma takılan şu: neden yeni standart olarak git’e geçilmiyor? Commit imzaları, tag imzaları, dağıtık yapı vb. açısından çok daha iyi bir alternatif gibi görünmüyor mu?
git protokolü daha karmaşık ve daha az ölçeklenebilir. Özellikle CI’da her seferinde tüm paketleri yeniden indiriyorsanız verimsiz olur. Tek dosyalı arşivler dağıtım açısından çok daha kolaydır. Digest ve imza algoritmaları git’e özgü şeyler değil; asıl daha zor taraf anahtar ve kimlik yönetimi ve git bunu da tamamen çözmüyor (yani git ile GitHub’ı karıştırmayın)
Birilerinin git sunucularını işletmesi gerekir ve her gem için ilgili git sunucusunu bulup oradan Pull yapmak gerekir. Üstelik tüm git sunucularında en güncel sürüm de bulunmayabilir; dolayısıyla her biri ayrı ayrı ölçeklenmek zorunda kalır. Merkezileşmenin avantajı, her şeyin tek yerde toplanması, ölçeklemenin tek seferde yapılabilmesi ve güncellemelerin eşzamanlı uygulanabilmesidir. Eskiden artifactory vb. ile NPM, paket yöneticileri ve docker container’ları proxy’liyorduk; aradaki servis dursa bile dağıtım yapılabiliyordu. Ama küçük geliştiriciler ya da ekipler için bu tür yönetim gereksiz ek yük gibi gelebilir
Aslında rubygems (yazılım) zaten herhangi bir git reposundan paket çekebiliyor. Yani bu bir ölçüde zaten destekleniyor
Go dili zaten böyle bir yaklaşımı kullanıyor
Go’nun paketleme ekosistemini gördükten sonra hâlâ git’e geçmenin iyi bir fikir olduğunu düşünmek bana garip geliyor
En önemli nokta şu: en azından projenin nasıl sürdürüldüğünü dışarıdan görebilmek için git repo bağlantısı koyabilirlerdi ama şu an yok. Bakımcı listesi var ama git repo bağlantısı yok; bu yüzden koddan çok insanlar etrafında dönen bir proje izlenimi verdi
Eğer bu bir paket deposuysa, Ansible reposu gibi bağlantıların ilk duyuruda özellikle yer alması gerektiğini sanmıyorum. Bir paket deposunda en önemli şey güvendir. RubyGems’te yaşanan düşmanca ele geçirme bu güveni sarstı; şu anda çevrimdışı bırakılan eski bakımcıların bizzat işlettiği bir alternatifin ortaya çıkması ise aksine olumlu bir gelişme. Açıkçası senin önce sonuca karar verip sonra buna gerekçe aradığın izlenimini veriyor. Ayrıca rubygems.org ana sayfasında da git repo bağlantısı çok görünür değil
Kaynak kod burada
Son tartışmaları bir kenara bırakırsak, uyumlu alternatif paket kaynağı, yönetici veya sürüm yöneticilerinin açık kaynak ekosistemi açısından nötr mü, olumlu mu, olumsuz mu olduğu üzerine düşünüyorum
Bazen fork gerekebilir, bunu anlıyorum; ama tarafların uzlaşamamış olması yine de biraz üzücü. Herkesin Ruby ekosistemini geliştirmek gibi ortak bir hedefi varsa, politik arka planlar ya da kişisel fikir ayrılıkları olsa bile birlikte çalışabilmeleri gerekmez miydi diye düşünüyorum. Geçmişte de Merb ile Rails, Bundler ile RubyGems, RubyTogether ile RubyCentral sonunda birleşmişti; umarım bu da bir gün çözülür
gem dağıtım ve indirme yöntemleri yeniden tasarlansa bu tür sorunların çözülebileceğini düşünüyorum. Ama bu değişimi yapabilecek taraflar şu anda yazılımı ve altyapıyı kontrol edenler ve onların da iyileştirme için pek motivasyonu yok. Bu durumun kendisi bana saçma geliyor; DHH’ye yönelik tepkinin nedenini de pek anlamıyorum. Açık kaynak projelerini çökertmenin en kolay yolu bu tür dramalar ve fork’lar olduğu için üzücü. Ruby eski bir dil olmasına rağmen kullanıcı tabanı çok büyük değil; bu tür tartışmalar tüm ekosisteme zarar veriyor ve eski bir Ruby geliştiricisi olarak buna üzülüyorum
Bunun, RubyGems GitHub reposu ve organizasyonunun Ruby Central tarafından düşmanca biçimde ele geçirilmesine karşı etkili ve çok iyi bir hamle olduğunu düşünüyorum. Barındırma maliyetleri için finansal desteğin sağlanmasını umuyorum