Açık kaynak yazılımları, son dönemde yaşanan tedarik zinciri saldırıları ve yapay zekâ destekli keşif araçları nedeniyle kurumsal dünyada yeni bir eşik aşımına zorlanıyor. 2020’den bu yana SolarWinds, Log4Shell, TeamPCP ve Shai-Hulud gibi olaylar, işletmelerin yıllardır güvenerek kullandığı projelerin bakım, yama ve sahiplik tarafında ne kadar kırılgan olduğunu yeniden gündeme taşıdı.
Yayımlanan değerlendirmelerde, bu kırılmanın açık kaynağın tanımını değiştirmeyeceği; buna karşın büyük kurumların hangi projelere güvenip hangilerine güvenemeyeceğinin ayrışacağı aktarılıyor. Buna göre asıl değişim, lisans metinlerinde değil, bir projenin erişilebilir, yamalanabilir, hesap verebilir ve hâlâ ayakta olduğunu kanıtlayabilmesinde olacak.
Son analizlerde çizilen tabloya göre açık kaynak dünyası ikiye ayrılıyor. Bir yanda kurumsal kullanım için belirli bir bakım ve sürdürülebilirlik düzeyini karşılayan projeler yer alacak. Diğer yanda ise bu koşulları sağlamayan, sağlamayı reddeden ya da hiç hedeflemeyen projeler açık kaynak olmaya devam edecek; ancak regüle edilen işletmeler için doğrudan dayanak noktası olmaktan çıkacak.
Metinde, bu yeni çizginin özellikle düzenlemeye tabi sektörleri ilgilendirdiği vurgulanıyor. Önümüzdeki birkaç yıl içinde, bu eşikleri karşılayan yazılımların birçok kurum için bir tercih değil, fiilî bir uyum şartı haline gelmesi bekleniyor. Avrupa Birliği’nin Cyber Resilience Act düzenlemesinde yer alan steward tanımı da tam bu noktada öne çıkarılıyor; düzenleme, ticari kullanımda açık kaynağa süreklilik kazandıracak bir sahiplik rolünü hukuki çerçeveye yerleştiriyor.
Değerlendirmede, “açık kaynak” tanımının değişmeyeceği özellikle belirtiliyor. OSI’nin yıllardır yönettiği lisans tanımı yerinde kalacak; esas kırılma, işletmelerin hangi projeleri tüketmeye istekli olduğu ve kısa süre içinde hangi projeleri tüketmeye zorlanacağı tarafında yaşanacak. Bu nedenle metin, bir lisans savaşından değil, kullanım koşullarının sertleşmesinden söz ediyor.
Bu yeni düzende ayakta kalması beklenen projeler için temel ölçüt lisans değil, canlılık olacak. Projenin erişilebilir olması, açık bildirim kanalı bulunması, bakımcısının hâlâ görevde olduğunu gösterebilmesi ve gelecek salı yapay zekâ tarafından bulunacak yeni bir açığa karşı yama çıkarabilecek durumda olması beklenecek. Tek bakımcılı küçük projeler, topluluk projeleri, vakıf projeleri ve şirket destekli projeler arasında bu eşiği karşılayabilenler olacak; karşılayamayanlar ise yine açık kaynak kalacak ama kurumsal bağımlılık açısından farklı bir konuma düşecek.
Yazıda, bu geçişin şirketlere yeni bir lisans dayatması getirmeyeceği de net biçimde anlatılıyor. Proje bu modele katılmayı seçerse, bu bir durum beyanı olacak; seçmezse de kimse onu zorlamayacak. Ancak düzenlemeye tabi bir kurum, artık buna göre plan yapmadan bu yazılımı doğrudan temel alamayacak.
Metin, açık kaynak ekosisteminde yıllardır tartışılan bakımcı tükenmişliği ve sahiplik sorununun da altını çiziyor. İyi bilinen örneklerden biri olarak xz-utils bakımcısının anahtarları devredecek uygun bir yapı bulamaması hatırlatılıyor. Yazar, projenin sahipsiz kalmasının teknik değil, organizasyonel bir boşluk olduğunu vurguluyor ve bunun için “proof of life” yani yaşam kanıtı mantığında çalışan bir model önerildiğini aktarıyor.
Bu modelde proje, belirli aralıklarla hâlâ ayakta olduğunu ve kritik anda da ulaşılabilir olacağını göstermek zorunda kalacak. Sadece bir zamanlar bakımcıya sahip olmak yeterli sayılmayacak; üyelik, bir kez kazanılıp duvara asılan bir rozet değil, sürekli yeniden doğrulanan bir durum olacak. Böylece bir proje bugün güvenli görünse bile, bakımcı ayrıldığında ya da ilgisini kaybettiğinde bir sonraki yama anına kadar fark edilmemiş bir boşluk oluşmasının önüne geçilmesi hedefleniyor.
Ancak aynı metin, bakımcıların da süresiz çalışmak zorunda olmadığını açık biçimde kayda geçiriyor. On beş yıl boyunca kritik bir kütüphaneyi taşıyan bir kişinin projeyi bırakabilmesi gerektiği, bunun da insan onurunu zedelemeden yapılabilmesi gerektiği anlatılıyor. Bu noktada önerilen yapı, bakımcının projeyi bıraktığında downstream kullanıcıları ortada kalmadan devralacak bir emeklilik ya da devretme mekanizması. Chainguard’ın EmeritOSS yaklaşımı da bu çerçevede örnek gösteriliyor.
Yazıda en çok yanlış anlaşılan kısım ise “ücretsiz” kullanım meselesi. Metne göre bu alt kümedeki yazılımlar için kimseye tek kuruş ödemek zorunlu olmayacak. Ancak buradaki “free” kelimesi, klasik anlamda bedava değil; yazar bunu “free as in puppy” benzetmesiyle açıklıyor. Yani yazılımı edinmek ücretsiz, fakat onu beslemek, yürütmek, güncel tutmak ve bir gün elden çıkarmaya hazır olmak sürekli emek gerektiriyor.
Bu benzetme, yazının teknik tarafında da karşılık buluyor. “Puppy”yi beslemek, bu durumda son sürümde kalmak anlamına geliyor; çünkü söz edilen güvenilir proje kümesi yalnızca güncel sürümleri yamalayacak. Üç yıl önce dondurulmuş bir sürüm için artık kimsenin düzeltme üretmeyeceği, bakım desteğinin geçmişe dönmeyeceği açıkça ifade ediliyor. Dolayısıyla kurumların, projeyi kullanmaya devam ederken güncelleme yükünü de taşımayı kabul etmesi gerekiyor.
Bir başka nokta da bu yükün nasıl paylaşılacağı. Yazı, bunun açık kaynağın ölüm ilanı değil, farklı bir dağıtım modeli olduğunu savunuyor. Vendor tarafı burada kapı bekçisi gibi konumlanmıyor; yazılım yine ücretsiz kalıyor. Fakat ticarî sağlayıcılar, bir kurumun kendi başına üstlenmek istemeyeceği iki yükü devralıyor: sürekli güncel kalmanın maliyeti ve bir proje aniden güvenilmez hale geldiğinde onu canlı tutacak tampon.
Metinde bu yüzden ticarî sağlayıcının rolü, acil servis ile köpek bakıcısı arasında bir yere oturtuluyor. Proje düşerse onu anında stabilize edecek taraf vendor oluyor; proje hâlâ güvenilir ama artık kurumsal bir taahhüt gerektiriyorsa destek ve LTS dalları devreye giriyor. Böylece bir kurum, yazılımı kendi başına takip etmek yerine bu sürtünmeyi satın alabiliyor.
“Sadece bakımcılara ödeme yapılsın” itirazı da metinde ayrı bir başlık altında ele alınıyor. Yazar bu öneriye mesafeli değil; tersine, bakımcılara ödeme yapılması gerektiğini kabul ediyor. Ancak asıl sorunun para olmadığını, dağıtım problemi olduğunu söylüyor. Binlerce şirket ile binlerce bağımlılığın tek tek eşleşmesi, bakımcının ne istediğinin ve neyi kabul ettiğinin yönetilmesi, toplu ölçekte kolay çözülmüyor.
Bu noktada Filippo Valsorda’nın profesyonel bakımcılara ödeme yapmaya dair kılavuzuna da atıf yapılıyor. Yazıda, o kılavuzdaki ön koşul listesinin uzunluğunun bile meselenin ölçeklenebilir olmadığını gösterdiği söyleniyor. İsteyen bakımcılar kendi ticari katmanlarını kurabiliyor; sözleşmeli destek verebiliyor, backport hizmeti satabiliyor, kendi vendor’ına dönüşebiliyor. Fakat bu seçenek tek başına, on bin şirketin aynı anda aynı bağımlılıkla nasıl eşleşeceği sorununu çözmüyor.
Metin, bunun “commons tragedy” yani ortak alan felaketi olmadığını özellikle vurguluyor. Burada tükenen bir kaynak yok; kaynak olarak kullanılan kod, başkası kullandığı için azalıyor değil. Asıl problem, kodun altında görünmeyen bakım ve güven ilişkisinin hiç kurulmamış ya da büyüklüğe uygun biçimde örgütlenmemiş olması. Yazar bunu bir dağıtım sorunu olarak tanımlıyor.
Çözüm olarak işaret edilen yapı ise vakıflar ve büyük topluluklar. Tek tek on binlerce karşı taraf yerine tek bir muhatap, tek bir sözleşme imzalanabilen yapı, yönetişimin parayla karışmadığı bir model ve projenin hâlâ canlı olduğuna dair inandırıcı bir sinyal. Metin, Avrupa Birliği’nin Cyber Resilience Act düzenlemesindeki steward rolünü de bu yeni yapının hukuki karşılığı olarak gösteriyor.
Yazı, bu gelişmelerin açık kaynak topluluğunun çocukluk dönemini bitirdiği fikriyle kapanıyor. Çocukluk güzel geçmiş olabilir, ancak ardından gelen dönem sert olmuş; projeler artık invulnerable değil, bakımın ve sahipliğin bedelini daha görünür biçimde ödemek zorunda. Buna rağmen açık kaynak ortadan kalkmıyor. Sadece, kurumsal dünyanın üzerinde yıllardır taşıdığı yükü daha dürüst bir çerçevede yeniden tanımlıyor.
Metnin son bölümlerinde, yıllardır “özgür yazılım” çizgisinde duran toplulukların bu tartışmayı uzaktan izlediği de aktarılıyor. Commercial open source dünyasının kurucuları ve yatırım destekli ekipler, GPL çizgisindeki “özgürlük, fiyat değil” yaklaşımını uzun süre ideolojik buldu. Şimdi ise yazar, o grubun bu yeni muhasebeye en baştan beri taraf olmadığını, skora hiç girmediklerini söylüyor. Onların bakışıyla bu süreç zaten bir yarış değildi.
Yine de ortada bir isim sorunu kaldığı not ediliyor. “Enterprise Source” fazla satış kokuyor, “Resilient Source” fazla yumuşak kalıyor, “Load-bearing Source” ise ağırlığı anlatıp sözleşmeyi tarif etmiyor. Yazar, yeni kategorinin bir ad bulmak zorunda olduğunu, aksi halde düzenleyicilerin ve piyasadaki aktörlerin kendi terimlerini dayatacağını söylüyor. Şimdilik adı konmamış olsa da, metin açık kaynak ekosisteminde kurumsal kullanım için yeni bir dayanıklılık katmanının şekillendiğini açık biçimde ortaya koyuyor.