Rug pull, fork ve açık kaynak feodalizmi

• Açık kaynak ekosistemindeki güç dinamiklerinin şirketler, geliştiriciler ve kullanıcılar arasında nasıl işlediğine ve bunu sarsan rug pull (yeniden lisanslama) ile fork taktiklerinin etkisine dair bir derleme
• Büyük bulut sağlayıcıları önemli etki gücü kullanırken, tek bir şirket merkezli projeler yeniden lisanslama ile gücü yeniden dağıtabiliyor; buna karşılık fork ortaya çıkıyor
• Vaka analizlerinde Elasticsearch→OpenSearch, Terraform→OpenTofu, Redis→Valkey, Puppet→OpenVox gibi örneklerde farklı topluluk yeniden yapılanmaları ve katkıcı göçleri görülüyor
• CLA benimsenmesi, tek şirket hâkimiyeti, vakfa devrin zamanlaması gibi unsurlar rug pull için risk sinyalleri olarak sunulurken, tarafsız yönetişim ve çok kurumlu katkı tabanının genişletilmesi karşı stratejiler olarak öneriliyor
• Sonuç olarak yeniden lisanslama, bulut şirketlerini dengeleme aracı olabilir; ancak katkıcıların yetkisini de birlikte zayıflatır ve fork olasılığı şirketlerin kararlarında caydırıcı bir unsur olarak çalışır

---

Açık kaynakta güç yapısı, rug pull ve fork

• Açık kaynak yazılım ekosisteminde büyük şirketler, KOBİ'ler, katkıcılar ve kullanıcılar, kendi yazılımın yönü ve gelir yapısı üzerinde etkili olmak için güç kullanır
• Özellikle büyük bulut sağlayıcıları ciddi bir güç sahibi hâline gelir ve küçük şirketler ya da topluluklara göre üstün konuma geçme eğilimi gösterir
• Bu durumda geliştirici şirket ya da projeyi sahiplenen şirket yazılım lisansını değiştirerek (rug pull), ya da tersine topluluk veya başka şirketler fork başlatarak güç kaymasına yol açar

Güç dinamikleri ve taktiklere genel bakış

• Açık kaynak dünyasında büyük bulut sağlayıcıları en güçlü kanal ve dağıtım gücünü kullanır; bu da küçük şirketleri, katkıcıları ve kullanıcıları sömüren bir yapı oluşturur
  • Feodalizm çağında toprağın kontrolüne benzer şekilde, bulut sağlayıcıları açık kaynak yazılımı hizmetleştirirken katkı yapmaktan kaçınır
  • Geliştirme işinin büyük kısmını küçük şirketler üstlenir; ancak bulut sağlayıcılarının ücretsiz kullanımından dolayı dezavantajlı konuma düşerler
• Rug pull taktiğiyle küçük şirketler, bulut sağlayıcılarına karşılık vermek için yazılımı yeniden lisanslar; ancak bu, katkıcılara ve kullanıcılara daha büyük zarar verir
  • Bulut sağlayıcıları projeyi hizmete dönüştürürken katkı yapmadığı için küçük şirketlerin gücü zayıflar
  • Yeniden lisanslama kullanıcılar için olumsuz sonuçlar doğurur; ancak fork yoluyla güç dengesi yeniden ayarlanabilir
• Tek şirketin yönlendirdiği projelerde rug pull riski yüksektir; bu yüzden şirket itibarı değerlendirilmelidir, ancak birleşme-devralmalar ya da iflas bunu anlamsız kılabilir
  • Yatırımcı baskısıyla geliri artırmak için yeniden lisanslama görülebilir; özellikle bulut sağlayıcılarıyla rekabette bu daha sık yaşanır
  • Daha kısıtlayıcı lisanslarla diğer şirketlerin gelir elde etmesi zorlaştırılarak güç kaydırılmaya çalışılır
• Rug pull sonucu fork oluşumu, gücü geri kazanmak için isyankâr bir kolektif eylem işlevi görebilir; ancak insan gücü ve kaynak eksikliği nedeniyle başarısızlık riski yüksektir
  • Büyük şirketler veya bulut sağlayıcıları kaynaklarıyla fork'ları destekleyebilir; ancak popüler fork'lar her zaman başarılı olmaz
  • MongoDB veya Sentry örneklerinde fork ortaya çıkmamış durumlar da vardır; Perforce'un Puppet'i satın almasının ardından geliştirmeyi kapatması OpenVox fork'unu tetiklemiştir

Başlıca vakaların karşılaştırması

Dawn Foster, çeşitli rug pull'ları, fork'ları ve sonrasındaki etkileri veriler üzerinden analiz ediyor. (Sonuçların bir kısmı Jupyter notebook veri kümesiyle paylaşılıyor)

• Elasticsearch → OpenSearch
  • 2021'de Elastic'in SSPL yeniden lisanslamasının ardından AWS, OpenSearch fork'unu organize etti
  • Elastic'te şirket içi katkıcı oranı fork öncesi ve sonrasında büyük ölçüde değişmedi; OpenSearch'te ise Amazon liderliğindeki katkı sürüyor
  • Analize göre 2024'te Linux Foundation'a devredilmesinin ardından da dış katkılarda belirgin bir sıçrama görülmedi
• Terraform → OpenTofu
  • 2023'te HashiCorp'un BSL'ye geçmesinin hemen ardından OpenTofu, Linux Foundation çatısı altında başlatıldı
  • Terraform hâlâ şirket içi merkezli katkı yapısını korurken, OpenTofu'ya birden çok şirketten yeni katkıcılar hızla akın etti
  • Bu vaka, kullanıcı öncülüğündeki fork + tarafsız vakıf başlangıcının, aktif topluluk oluşumu için elverişli olduğunu gösteriyor
• Redis → Valkey
  • 2024'te Redis'in SSPL'ye geçmesinin hemen ardından mevcut dış katkıcıların büyük bölümü Valkey'e geçti
  • Redis, fork öncesinde dış katkı oranı yüksek olan istisnai bir vakaydı; fork sonrasında dış katkı sıfıra keskin biçimde düştü, Valkey ise çok şirketli bir topluluk ittifakı olarak başladı
• Puppet → OpenVox
  • Perforce satın almasından (2022) sonra geliştirme ve sürümlerin kapalı hâle gelmesi ile sürüm sıklığının azalması yaşandı; buna karşılık topluluk OpenVox fork'unu başlattı

Veri gözlemleri ve metrikler

• Rug pull sonrasında GitHub fork sayısında keskin artış sık görülür; bu, hard fork değerlendirmesi hareketinin bir proxy sinyali olarak yorumlanır
  • Uzun vadede orijinal ile fork'un birlikte ilerleme eğilimi vardır; ancak yeniden lisanslanan orijinal projenin kullanımında düşüş gözlemlendiği belirtiliyor
• Bir vakıf çatısı altında başlatılmak, yeni projelerin erken döneminde katkı çekme açısından avantajlıdır; ancak sonradan devirin etkisi sınırlı kalabilir
  • OpenSearch örneği, tek başına devir işleminin dış katkılarda patlama yaratmayı garanti etmediğini gösteriyor

Risk sinyalleri ve kılavuz ilkeler

• CLA (Contributor License Agreement) kullanımı, şirkette yeniden lisanslama yetkisini yoğunlaştırarak güç dengesizliğini büyüten bir sinyaldir
  • DCO (Developers Certificate of Origin) temelli projelerde rug pull riskinin görece daha düşük olma eğilimi vardır
• Yönetişim denetimi gerekir; tek şirket hâkimiyeti ve liderliğin tek elde toplanması risk faktörleridir
  • Tarafsız vakıf, çok kurumlu liderlik ve geniş dış katkı tabanı olan projeler sürdürülebilirlik açısından daha avantajlıdır
• Katkıcı tabanının genişliği ve derinliği de temel değerlendirme başlıkları arasındadır
  • Şirketler, bağımlı oldukları projelere doğrudan katkıcı göndermeyle hem etki gücünü hem sürdürülebilirliği artırmalıdır
  • CHAOSS'un metrikleri ve uygulayıcı rehberi, proje sağlığını değerlendirme ve iyileştirme için kullanılabilir

Topluluk ve yönetişim önerileri

• Tarafsız yönetişim yapısına yönelmek ve dış katkıcıları artırmak, rug pull'u caydırmanın pratik yollarıdır
  • Fork olasılığının kendisi bile şirketlerin yeniden lisanslama kararının maliyetini yükselterek caydırıcı etki yaratır
• Hazel Weakly'nin koruma mekanizmalarına ilişkin sorusuna yanıt olarak konuşmacı, Valkey ve OpenTofu başarısının şirketleri yeniden lisanslamayı yeniden düşünmeye ittiği gerçek örneklerden söz etti
  • Dirk Hohndel, daha fazla dış katkıcı çekmenin rug pull riskini artırarak yönetim kararlarının riskini büyüttüğünü vurguladı

Sonuç

• Büyük bulut sağlayıcılarının etkisi arttıkça açık kaynak ekosistemi giderek daha feodal bir yapıya dönüşüyor
• Lisans değişikliği, bulut şirketlerinin gücünü dengeleyebilir; ancak bu süreçte topluluk katkıcılarının yetkisini azaltan bir yan etki ortaya çıkar
• Buna karşılık katkıcılarda ve kullanıcılarda 'fork' biçiminde bir karşı hamle aracı vardır; bu da açık kaynağı feodal dönemden ayıran özgün güçtür
• Fork'un gerçek bir olasılık olması, şirketlerin gelecekteki politika kararlarını etkiler; nitekim Valkey ve OpenTofu'nun başarısından etkilenerek bazı şirketler rug pull planlarını geri çekmiştir
• Son tahlilde projenin yönetişim tarafsızlığı ve dış katkıcıların canlandırılması, rug pull'u önlemek ve sağlıklı bir ekosistemi korumak için kilit önemdedir

Kaynaklar

• Sunum slaytları: Power Dynamics, Rug Pulls & Other Impact on Sustainability

[ndrgrd]

Fork hâlâ kolay olmadığından, açık kaynakla ilgili kuruluşlar arasında buna yardımcı olan yerler olsa iyi olurdu.

[GN⁺]

Hacker News görüşü

• CLA(Contributor License Agreement) kullanan projelerde rug pull'un (katkı sunanların emeğinin az sayıda kişi tarafından özelleştirilmesi) daha sık yaşandığı, buna karşılık DCO(Developers Certificate of Origin) kullanan projelerde bu dengesizliğin daha az olduğu belirtiliyor. CLA imzaladığınızda projeye katkı kodumu yeniden lisanslama hakkı vermiş oluyorsunuz. Yani GPL bir projeye GPL katkısı yapsanız bile lisans değişikliği mümkün hale geliyor. Zaten permissive bir lisans varsa CLA'nın etkisi büyük olmayabilir, ancak copyleft (ör. GPL) söz konusuysa CLA'yı imzalayan tarafın münhasır sahiplik elde edebilmesi adaletsiz hale geliyor. Rug pull'u önlemek için copyleft lisans kullanmak ve CLA imzalamaktan kaçınmak daha iyi olur. Permissive lisanslarda ise rug pull'un "oyunun bir parçası" olduğunu anlamak gerekir
  • GNU projeleri de CLA istiyor ama bunu rug pull yapmak niyetiyle yaptıklarını sanmıyorum
  • CLA imzalamanın her zaman yeniden lisanslama haklarının tamamını verdiğini söylemek doğru olmaz; bu CLA'dan CLA'ya değişir. Örneğin Canonical'ın CLA'sındaki (bağlantı) maddeye göre, katkımın mevcut lisans altında da sunulacağını taahhüt ediyor. CLA'yı okuyup anlamak önemli. Çoğu CLA telif hakkını katkı sunanda bırakır, dolayısıyla katkımla istediğimi yapma hakkım da bende kalır. Asıl sorun, proje sahibine duyulan güvenin bozulabilmesidir. CLA, sahibine kontrol verdiği için rug pull riskini artırır. Rug pull'a karşı koymak için fiilen fork'layıp doğrudan işbirliği yapmak gerekir ki bundan fayda sağlanabilsin. Copyleft lisansa CLA eklenmesi durumunda (ör. AGPL + CLA), bu kombinasyon permissive lisans + CLA'dan bile daha zararlı olabilir. AGPL, hizmet olarak dağıtımda da kaynak açma yükümlülüğü doğurur; ama CLA sayesinde proje sahibi kapalı bir hizmet sunup iyileştirmelerini paylaşmak zorunda kalmaz. Gerçekten de Incus ve LXD örneklerinde olduğu gibi, lisans kombinasyonu ve CLA nedeniyle topluluk bölünmesi ve kod paylaşımı kısıtları yaşandı (ayrıntılı vaka yazısı)
  • Açık kaynakta rug pull diye bir olgunun var olmadığını düşünüyorum. GPL kopyaları sonsuza kadar var olur
  • Permissive lisans kullanıldığında rug pull olasılığı yükselir, ama CLA'nın her zaman bütün hakları verdiği söylenemez
  • Açık kaynakta "rug pull" gibi olumsuz bir söylemi aşırı safiyetçi biçimde ele almanın sağlıklı olmadığını düşünüyorum. Projelerin sürdürülebilir olması gerekir. Büyük bulut sağlayıcılarının altyapıyı tekelleştirdiği bir ortamda, küçük geliştiricilerin açık kaynak veya CLA tabanlı projelerde kavga etmesindense enerjilerini büyük şirket tekellerini azaltmaya harcamalarının daha iyi olacağını düşünüyorum
• Katkı sunanlar ve maintainer'lar çoğu zaman küçük şirketlerden bile daha az güce sahip. Yine de liberal lisans varsa memnun değilseniz fork'layıp yeni bir yol çizebilirsiniz. Valkey örneğinde olduğu gibi Redis ile yaşanan dinamik lisans değişimleri ilginç. Geliştirici topluluğunun genelinde bugünlerde bulut servislerine fazla yaslanıldığı için geçmişte olduğu gibi OS, derleyici, DB gibi şeyleri yeniden fork'lama veya baştan uygulama konusunda yeterince atak olunmaması sorun gibi geliyor. AWS gibi bulut şirketlerinin bunları servis olarak sunarak projelerin bilinirliğini artırdığı da sık sık göz ardı ediliyor (ör. ElasticSearch, AWS tarafından sunulduktan sonra daha popüler oldu). Bulut şirketleri kernel, gcc, jdk gibi alanlara katkı yaparak küçük şirketlere de dolaylı yarar sağlıyor. Büyük bulut şirketlerini kolayca suçlamak yerine, iş modelini baştan düşünmek daha iyi olabilir. En baştan kapalı başlasanız kimse umursamazdı
• Kullandığınız yazılımı ikili paket olarak almak yerine kaynak koddan kendiniz derlerseniz, rug pull gibi olaylarda hareket kabiliyetiniz artar. Üreticinin binary/image'larıyla kurulum yapanlar fork'a geçmekte zorlanır; ama build altyapısını yeni kaynağa geçirmek görece daha kolaydır. Gereken düzeltme veya özellikleri doğrudan kendiniz ekleyebileceğiniz için bakım bağımlılığı da azalır
  • Guix'i sevmemin nedeni tam olarak bu yapı. Varsayılan olarak kaynaktan derleme var ve cache sayesinde binary paketler de sunuluyor. Binary yoksa kaynak reproducible biçimde doğrudan derleniyor. Patch sürümleri de aynı paket yöneticisiyle kolayca kurulabildiği için ayrı bir build altyapısı gerekmiyor. Büyük ölçekli dağıtım ortamlarında build sunucusu bulundurmak daha verimli olur
  • Neden eksilendiğini bilmiyorum ama katılıyorum. Kaynaktan derleme genelde zor değil (bkz. sqlite)
  • Pratikte yazılım lisansına göre kısıtların değiştiğini de belirtmek gerekir. Kaynağını veren ticari yazılımlar da var ama lisansları serbestçe değiştirmenize izin vermeyebiliyor. Örneğin script dili tabanlı ticari ürünler veya kurumsal danışmanlıkta müşteriye kaynak verilse de derleme yetkisi için ayrıca ücret istenen durumlar olabiliyor
• Elasticsearch rug pull'undan sonra Amazon'un açık kaynak fork'a (OpenSearch) doğrudan katkı yapmaya başlaması, ilk niyet bu olmasa da bir ölçüde olumlu sonuç sayılabilir. Ancak büyük şirketlerin katkı sunanlarla gelir elde edenler arasındaki dengesizlik nedeniyle projelerde istikrarsızlığa yol açması da önemli bir tartışma başlığı
  • Lisansa uygun biçimde yazılım kullanmak başlı başına sorun değil; asıl çelişki, geliştirici veya girişimlerin yayılma ve büyüme uğruna permissive lisansları benimseyip büyük bulut şirketleri devreye girdiğinde bunu sorun etmeleri. İkisini birden elde etmek mümkün değil gibi görünüyor
  • Elastic'in istediği sonuç daha fazla lisans geliri elde etmekti ama pek çok kullanıcı fork'a geçti ve Elastic'e duyulan güven azaldı. Hatta OpenSearch ile ElasticSearch arasındaki rekabet ekosistem için olumlu bile olabilir; ancak artık iki ürünün uyumluluğu bozuldu ve Elastic'in konumu zayıfladı
  • AGPL/GPL gibi copyleft lisanslar, kod katkısını zorunlu kıldığı için münhasır lisansa ihtiyaç duymadan da bir geri bildirim döngüsü kurabilir
• Açık kaynak projelerde sadece lisansı değiştirerek rug pull yapmak o kadar kolay değil. Daha temel sorun, herkesin ücretsiz çalışsa bile yeterli yaşam kalitesini koruyabildiği ütopik bir ortamda yaşamıyor oluşumuz. Maintainer yoksa projelerin yarı ömrü kısa oluyor ve sponsorluk olmadığı sürece daha kapalı lisanslara geçiş hızlanacak
  • Mojang/Microsoft ile Bukkit topluluğu vakası aklıma geliyor. Geliştirici işe alınırken proje sessizce satın alındı ve bir gönüllü yıllarca ücretsiz çalıştırıldı; sonunda o kişi DMCA kullanarak projeyi kapattı. Daha ayrıntılı örnek: blog
  • Sonuçta mesele teşvik meselesi. Siz açık kaynak yazılım üretirken bulut şirketleri bunu kolayca alıp para kazanabiliyor. FOSS(Fully Open Source Software) lisanslarının anlamının bu olduğunu biliyorum ama toplum ücretsiz emeğe fazla alıştı gibi geliyor. Bu yüzden SSPL(Source-available licensing) gibi yeni yaklaşımlar giderek daha çekici hale gelebilir. Tek bir madde farkıyla AGPL'in FOSS, SSPL'in ise FOSS sayılmaması terminolojik bir karmaşa gibi hissettiriyor
• Rug pull yüzünden canı sıkılan kullanıcıları anlıyorum ama projeyi fiilen geliştiren ve sürdüren şirketlerin de mali sınırları var; bu yüzden önlerinde ancak birkaç seçenek kalıyor. Gelir modeli yoksa lisans değişikliği kaçınılmaz hale gelebiliyor. Alternatif olarak crowdfunding, iş yükünü azaltma, ürün satışı veya ek finansman gelmezse açığı kapatacak değişikliği önceden duyurma gibi seçenekler düşünülüyor. İlgili yazı
  • Şikayetin özü, OSS olarak açılıp kullanıcı toplandıktan sonra lisansın aniden daha kapalı hale getirilmesi. En baştan OSS olmasaydı aynı ihanet hissi oluşmazdı; sorun, kullanıcı çekmek için OSS başlayıp sonra yön değiştirilmesi
  • Mongo, Elastic, Redis, Hashicorp gibi şirketler rug pull anında ciddi mali kriz içinde değildi. Hashicorp örneğinde bu, satın alma değerini artırma stratejisi bile olabilir
• Son dönemde yönetişim kurulları, daha sıkı regülasyonlu işletim modelleri gibi yapılar öne sürülerek teknik insanların gönüllü biçimde uzaklaşması teşvik ediliyor; ardından karşıt görüşler bastırılıyor ve proje yetkileri geri alınıyor. Gerçekten de 'güvenlik' söylemiyle topluluklara Orwellvari bir atmosferin getirildiği örnekler artıyor
• Açık kaynak kullanıcılarının neredeyse tamamı free rider. Projelere hiçbir katkı yapmadan onları özgürce kullanıyoruz. Açık kaynak, karşılıksız bir hediye ya da başkasının ödevinden yararlanma kültürü gibi görülebilir. Dünyaya katkı yapmak istiyorsanız isteyerek yapın ama herhangi bir karşılık beklemeyin. Lisans değişikliği yüzünden buna rug pull demek de önyargılı bir bakış olabilir. Sonuçta kodu zaten aldık; yön değişikliği üzücü olsa da dünyada hiçbir şey sonsuza kadar sürmez
  • "Çoğumuz hiçbir şey geri vermeden kullanıyoruz" iddiası tamamen doğru değil. Pek çok projede kod, test, dokümantasyon, pazarlama ve evangelism dahil pek çok alanda katkı oldu. Bu projeler GitHub'a tesadüfen yüklenmiş sessiz geliştirmeler değildi; şirketler ciddi para harcayıp geliştirici evangelist'ler istihdam ederek teknoloji ve lisansın avantajlarını anlattı, kullanıcı havuzunu büyütmek için uğraştı. Böyle bir ortamda büyük ölçekte kod ve katkı toplayıp sonra aniden lisansı değiştirip başka FOSS projeleri ona bağımlıyken bu sözü bozmak işte bu yüzden rug pull diye eleştiriliyor. Eğer proje ek pazarlama olmadan GitHub'a tesadüfen yüklenmiş ve doğal şekilde benimsenmiş olsaydı rug pull tartışmasının konusu olmazdı. Ama böyle örnekleri neredeyse hiç görmedim
  • Bunun ille de böyle olması gerekmiyor. Şirketler veya finansal gücü olan aktörler bağımlı oldukları açık kaynak projelere mali ve teknik katkı yaparak sürdürülebilirliği artırabilir. Open Source Program Office kurmak, kullanılan tüm yazılım ve bağımlılıkları analiz etmek, katkı için zaman ve finansman ayırmak, benzer sektörlerde de bu kültürü teşvik etmek gibi yollar var
• Şu an çalıştığım şirkette de rug pull konusu yönetimi karıştırıyor. Sistemler için hep destek sözleşmesi istemiştik ama Chef, CentOS, VMWare, Broadcom gibi örneklerde benzer şeyler tekrar tekrar yaşanıyor. Ücret ödeyip kullanmaya hazır olsak bile temel bakım hizmetlerinin yıllık maliyeti binlerce hatta on binlerce dolara çıkıyor ve yine de güven vermiyor. Bu yüzden bir vakfı desteklemek veya düzenli olarak OSS maintainer'larını doğrudan istihdam etmek bana daha mantıklı gelmeye başladı. Eskiden böyle önerilere daha alaycı bakardım ama giderek daha çok destek buluyor. Kişisel olarak VMWare'e ödeme yapmak yerine Proxmox ya da qemu geliştiricisini istihdam etmeyi tercih ederim
  • Bunun doğru fikir olduğunu düşünüyorum. Kullandığınız tüm yazılım ve bağımlılıkları gözden geçirmek, geliştirme zamanı ve maddi katkı vererek sürdürülebilirliği sağlamak ve aynı yaklaşımı sektör geneline yaymak önemli
  • İlginç biçimde adı geçen şirketler topluluk odaklı olmak için open source program office kurdu ama organizasyon büyüdükçe ikiyüzlülük değilse bile topluluk ile şirket çıkarları arasındaki kopuşun ortaya çıkması kaçınılmaz bedel gibi görünüyor
• Fork kolay bir iş değil; insan ve kaynak olmadan başarıya ulaşmaz. Açık kaynak sonuçta ancak çok sayıda katkı sunan olduğunda işler. Eğer fork ölüyorsa bu, o projede free rider sayısının çok fazla olduğu anlamına gelir. Rug pull'daki en büyük sorunun fiilen yanıltıcı reklam olduğunu düşünüyorum. Açık kaynak söylemiyle müşteri toplayıp sonra bu durum kendileri için dezavantaja dönüşünce sözü bozmak ahlaki açıdan sorunlu. Ama katkının kesilmesi kendi başına endişe verici değil. Hiç kimsenin sonsuza kadar bir projede kalma zorunluluğu yok; bu yüzden bir kişinin ya da şirketin bırakması da doğal bir durumdur