Ruby çekirdek ekibi, RubyGems ve Bundler’ın sahipliğini devraldı

• Ruby dilinin paket yöneticisi RubyGems ve Bundler depolarının sahipliği Ruby Central’dan Ruby çekirdek ekibine devredildi
• Bu adım, uzun vadeli istikrar ve topluluk sürekliliğini güvence altına almak için Matz’in (Yukihiro Matsumoto) liderliğinde alınan bir karar
• RubyGems ve Bundler, açık kaynak lisansları aynen korunarak devam edecek; mevcut katkı sağlayıcıların telif hakları ve katkı geçmişi de aynı şekilde korunacak
• Operasyon modeli, Ruby Central ile Ruby çekirdek ekibinin birlikte yönettiği bir yapıya dönüşecek ve topluluk odaklı geliştirme yaklaşımı sürecek
• Bu, Ruby ekosisteminin sürdürülebilir gelişimini ve bütünlüğünü güçlendirmeyi amaçlayan yapısal bir dönüşüm olup, gelecekteki uzun vadeli istikrar açısından önemli anlam taşıyor

---

RubyGems ve Bundler’ın önemi

• RubyGems, Ruby ekosisteminin temel paket yönetim aracıdır; Bundler ise bağımlılık yönetimi ve dağıtım için kritik bir bileşendir
• Her iki proje de Ruby dağıtımına dahil edilen standart araçlar olup, Ruby diliyle yakından entegredir
• Ancak RubyGems ve Bundler şimdiye kadar Ruby organizasyonu yerine Ruby Central tarafından bağımsız olarak yönetiliyordu ve
  Ruby dilinin standart bileşenleri olmalarına rağmen GitHub’da ayrı bir organizasyon altında işletilmeleri yapısal tutarlılığı zayıflatıyordu
• Bu nedenle Ruby çekirdek ekibi, depo yönetimi ve bakım yetkisini resmen devralmaya karar verdi
• Amaç, projenin uzun vadeli istikrarını ve Ruby ekosistemiyle uyumunu (alignment) güvence altına almak

Başlıca değişiklikler

• Depoların resmî sahipliği Ruby çekirdek ekibine devrediliyor ve Ruby Central ile ortak yönetim modeline geçiliyor
• Mevcut açık kaynak lisans koşulları değişmiyor; ticari veya hukuki yapıda da bir değişiklik yok
• Mevcut tüm katkı sağlayıcıların fikri mülkiyet ve telif hakları korunuyor; kod sahipliğinde bir değişiklik bulunmuyor
• Topluluk odaklı geliştirme modeli sürdürülecek ve katkı sunmak herkes için açık olacak

Topluluk iş birliği ve gelecek planları

• Ruby çekirdek ekibi, Ruby Central ve dünya genelindeki geliştiricilerle sürekli bir iş birliği yapısını sürdürmeyi planlıyor
• Bu adım, Ruby ekosisteminin istikrarını ve güvenilirliğini artırmak için uzun vadeli bir temel oluşturma hamlesi olarak değerlendiriliyor
• Matz, açıklamasında Ruby Central’ın bağlılığı için teşekkür ederken, “Ruby’nin daha parlak geleceğini birlikte kuralım” ifadesini kullandı

Çıkarımlar

• Bu devir, Ruby dilinin temel altyapısını resmî organizasyon içinde yeniden yapılandıran sembolik bir gelişme
• Dil düzeyinde bakımın bütünleştirilmesi ve ekosistemin tek çatı altında hizalanması, Ruby’nin sürdürülebilirliğini artıracak bir dönüm noktası olarak görülebilir

[GN⁺]

Hacker News görüşleri

• Bunun doğru yönde atılmış bir karar olduğunu düşünüyorum; Ruby Core ve Matz’ın devreye girip tüm dil ve topluluk için istikrar sağlamasına minnet duyuyorum
  • Matz’ın gerçekten merkezi bir figür olduğunu vurguluyorum; eskiden söylenen “Matz is nice and so we are nice” sözünün artık “nazik ve sorumluluk sahibi” olarak değiştirilmesi gerektiğini düşünüyorum
• Uzun vadede gem.coop gibi birden fazla kaynağın bulunmasının daha güvenli ve daha sağlam bir yapı olacağını düşünüyorum, ancak RubyGems tarafında çeşitli katmanlarda (yöneticiler, topluluk üyeleri, sponsorlar vb.) güven tamamen sarsıldı; finansman ve veri gizliliği gibi konular da hâlâ çözülmesi gereken sorunlar olarak duruyor, yine de Ruby topluluğundaki çoğu kişinin bu değişimi destekleyeceği görülüyor
  • Gerçekte neler olduğunu özetleyebilir misiniz? Son zamanlarda Ruby haberlerini takip edemedim, merak ediyorum
  • Katılıyorum, artık gem.coop’un ne kadar destek toplayacağını biraz daha izlemek gerektiğini düşünüyorum; geleceğe dair söz verdiler ve muhtemelen sonunda sonuç da üretecekler. Beta hizmet açıldığında daha önce yayımladığım gem’lerin en azından bir kısmını (önemli olanları) yeniden yüklemeyi düşünüyorum. Geliştirilmesi gereken noktalar var; bunların başında dokümantasyon geliyor (Ruby dokümantasyonuyla da ilişkili, ayrı durması sorun yaratıyor). Namespacing eksikliği de bir sorun (Ruby’de resmi olarak namespacing yok; bu hem bir özellik hem de bir problem, ama ilgi alanlarına göre ayırmanın bir yolu olmalı diye düşünüyorum). Önümüzdeki yaklaşık altı ay sonra, yani 2026 Mayıs sonu gibi yeniden değerlendirmek daha gerçekçi olur. DHH blogunda sert çıkışlarını sürdürürse, gem.coop’tan hoşnutsuz olan kişilerin yeni katkı sağlayıcılar olarak gelmesi ve bunun fayda üretmesi de mümkün olabilir. Kullanıcı açısından daha fazla özgürlük ve esneklik sağlayan bir win-win durumu olabilir. rubygems.org’da kalacak çok kişi olur ama gem.coop’u tercih edenler de artabilir. İkisini birden kullananlar da olacaktır (bu biraz karmaşık, bu yüzden gem.coop tarafında gem bazında kaynak belirtme özelliği düşünülmeli). Yapılacak çok iş var
  • Bakımı bırakmış bir yöneticinin hâlâ root yetkisine sahip olması bana inanılmaz geliyor; böylesine kritik bir platform üzerinde herhangi bir düzeyde yetkisinin kalmış olması şaşırtıcı. Son dönemde Ruby topluluğundan bazı kişilerin, web için önemli bir platform olmasına rağmen modern (ve zaten yaygın şekilde benimsenmiş) güvenlik standartlarına karşı çıkmasını görmek beni şoke etti. Artık 2006’da değiliz; curl komutuyla sadece Rails kurulan bir çağda yaşamıyoruz. Bu tür tepkilerin naifliği ürkütücü geliyor. Bakımsız bir güvenlik duruşuyla tedarik zinciri saldırılarına açık kalınması da sarsıcı. Hiç değilse artık birilerinin günümüz koşullarına uygun güvenliği ciddiye alması sevindirici
  • Birden fazla kaynak olmasının daha güvenli olduğu iddiasına karşılık, saldırı yüzeyinin 3 kat büyüyerek daha fazla güvenlik açığı doğurabileceğini düşünüyorum
  • Bu sadece Ruby araç zinciriyle ilgili bir değişiklik; rubygems.org’un kendisi ise (bakış açısına göre) hâlâ düşmanca bir yapı tarafından sahipleniliyor, bu yüzden bunun güveni ne kadar geri getireceğinden emin değilim
• Ruby Central’ın görüşü burada görülebilir https://rubycentral.org/news/ruby-central-statement-on-rubygems-bundler/
  • Karşılaştırma için 19 Eylül tarihli önceki açıklamaya da bakmak faydalı olur; burada “Ruby ekosisteminin uzun vadeli istikrarı ve büyümesine yönelik ortak taahhüdü yansıtmak” ifadesi yer alıyor https://rubycentral.org/news/strengthening-the-stewardship-of-rubygems-and-bundler/
• Matz’ın böylesine zor bir durumda bizzat liderlik göstermesine içtenlikle minnettarım; Japon bir geliştirici olarak son olayların nereye varacağı konusunda çok endişeliydim ama bu açıklamayla rahatladım
  • Nasıl bir liderlik gösterdiğini merak ediyorum; Hiroshi Shibata’nın her zaman tek başına hareket etmediği zaten açıktı. Gem ve Bundler’ı devralma kararının aslında aylar önce içeride alınmış olmasından şüpheleniyorum. Japon bir geliştirici olarak rahatladığını söyleyen görüşe gelince, ben tam tersine daha çok endişeleniyorum. ABD ya da Japonya’da yaşamıyorum, bu yüzden Ruby ekosisteminin ABD ve Japonya tarafından aşırı derecede kontrol ediliyor gibi görünmesi beni rahatsız ediyor ve kızdırıyor (Japonya tarafını yerel topluluk olduğu için anlayabiliyorum). Ama ABD’nin etkisinin de bu kadar büyük olması bana fazla geliyor. Python’da da benzer bir durum var ve bu açıdan üzücü
• Ruby’ye az da olsa dokunmuş herkes için bunun kimsenin itiraz etmeyeceği bir sonuç olduğunu düşünüyorum
  • Bence sadece Ruby Central kazandı. Hiçbir taviz vermeden, üstelik Ruby Core’un resmi desteğini alarak RubyGems’in bakımcısı olarak tanındı. Repository mülkiyeti devredildi ama Ruby Central işletme ve yönetişim sorumluluğunu elinde tutup Ruby Core ile yakın çalışmaya devam ediyor. Andre’nin Bundler ticari markasına sahip olduğu ve bunu Ruby Central’a karşı kullanacağını açıkladığı biliniyor https://andre.arko.net/2025/09/25/bundler-belongs-to-the-ruby-community/, Ruby Central ise Bundler’ın sahipliğini Ruby Core’a devredip bakımı sürdürmeye devam ediyor; bu da Ruby Core’u hukuki risklere açık hale getiriyor. Andre dava açarsa Japonya’daki Ruby Core ile karşı karşıya gelecek ve imaj daha da kötüleşecek
  • İnsanlar sadece Matz’ın göçmenlik hukuku gibi toplumsal konularda görüş belirtmemiş olması nedeniyle memnuniyetsizlik göstermiyor
  • Gerçekten kimsenin itirazı olmadığını mı söylüyorsunuz?
  • Neden kimsenin itiraz etmediğini merak ediyorum; bence hâlâ cevaplanmamış pek çok soru var. Asıl mesele gem.coop’un ne kadar popüler olacağı gibi görünüyor (gerçekten büyüyüp büyümeyeceği). Belki de Ruby projelerini kurmanın yepyeni bir yolunu yapmak daha iyi olabilirdi (Rust+cargo örneğinde olduğu gibi), ama hizmet sağlayıcı ile gerçek geliştirme tartışmalarını birbirinden ayırarak düşünmek gerektiğini savunuyorum. Hem gem hem bundle ikili dosyalarının var olması pek iyi bir durum değil. API’nin tek bir yapıda birleşmesi gerektiğini düşünüyorum (ya da Ruby Core’un bakımını yaptığı basit bir API olur, ek özellikler ise herkes tarafından özgürce geliştirilebilir). Sonunda birçok proje xkcd çizgi romanındaki gibi bir hale gelme riski taşıyor. bin/gem komutunun sadeliği güzeldi ve Bundler birkaç kullanışlı özellik ekliyordu. gem komutunun farklı kaynakları kolayca belirlemeye izin vermesi iyi olurdu (gem.coop dahil)
• Ruby Core’un Ruby Central’dan daha iyi bir seçenek olduğuna katılıyorum, ama tam olarak ne yaşandığını hâlâ merak ediyorum ve Ruby ekosisteminin genel imajı biraz bulanıklaştı
  • Genelde çoğunlukla Go olmak üzere çeşitli dillerle geliştiriyorum; Go’nun paket ekosistemindeki dağıtık yapı bana büyük bir avantaj gibi geliyor (tabii dezavantajları da var). NPM’de ve açık paket ekosistemlerinde tedarik zinciri krizleri tekrar tekrar yaşanmasına rağmen neden daha fazla topluluk odaklı dağıtıklaşma ya da deney yapılmadığını merak ediyorum
• Bunun en basit ve güveni yeniden tesis edebilecek seçenek olduğunu düşündüğüm için bu kararı bekliyordum; iyi niyetli liderlerin topluluğu hâlâ kurtarabileceğine inanıyorum
• Son dönemde olup bitenleri bir dizi izler gibi ilgiyle takip ettim; Ruby topluluğunda zarar gören kişiler için üzgünüm. Son olarak, Matz’ın harika olduğunu düşünüyorum
  • Tüm bunların çıkış noktasının DHH’ye yönelik antipati olup olmadığını merak ediyorum; rubygems.org için gerekli güvenlik ve yönetişim iyileştirmeleri bağımsız bir fork ile uygulanamaz mıydı? Böyle durumlarda açık kaynak dünyasında çatışmayı fork ile çözmek standart yaklaşım değil midir diye düşünüyorum
• Matz’ın tavrı ve açıklama biçimi gerçekten etkileyici ve saygı uyandırıcıydı; büyüklüğün ne demek olduğunu yeniden hatırlattı
  • Saldırgan tarafta olan Ruby Central’ı kollayıp, yıllardır katkı veren eski yöneticilere teşekkür etmemesi hoşuma gitmedi
  • Projenin RC (Ruby Central) tarafına nasıl geçtiğinden söz etmemesi, bana göre bu süreci olduğundan daha iyi gösterme çabası gibi görünüyor
• Dışarıdan bakan biri için bu olayı kısaca açıklayabilecek biri var mı?
  • Şu başlığa bakmak faydalı olabilir https://news.ycombinator.com/item?id=45299170#45300774, özellikle Mike McQuaid’in özeti çok yardımcı oluyor. Arabuluculuk ve iletişimi kolaylaştırma rolü oynadı; son sosyal medya paylaşımlarına da bakılabilir https://bsky.app/profile/mikemcquaid.com
  • Sahiplik birkaç kez el değiştirdi ve sürecin ayrıntıları hiç şeffaf değildi. Topluluk içindeki gerilim büyüdü; en yüksek sesli ve en tanınmış figürlerden biri de popüler olmayan ama güçlü görüşleri açıkça dile getiren bir tarz benimsediği için çatışma daha da büyüdü
  • Kimsenin bunu gerçekten net biçimde açıklayamadığını düşünüyorum; her şey kafa karıştırıcı ve çıkışsız görünüyor