Web'in büyük kısmını çalıştıran bir programlama dili, neredeyse tek bir kişinin omzunda duruyor. PHP Foundation'ın paylaştığı tabloya göre dilin sürekli bakımını üstlenen tam zamanlı çalışan sayısı bir. Bu, açık kaynak dünyasının yıllardır konuştuğu bağımlılık sorununu somut bir örnekle masaya yatırıyor.

Ne oldu?

PHP, otuz yılı aşkın geçmişiyle web sunucularının temel dillerinden biri. İçerik yönetim sistemlerinden e-ticaret altyapılarına kadar geniş bir alanda çalışıyor. PHP Foundation ise dilin geliştirilmesini, güvenlik yamalarını ve sürüm yönetimini koordine eden kuruluş. Açıklanan rakama göre vakıf bünyesinde dile tam zamanlı olarak yalnızca bir geliştirici bakıyor; geri kalan katkılar gönüllüler ve sponsor şirketlerin kısmi desteğiyle geliyor.

Neden önemli?

Yazılım dünyasında buna "otobüs faktörü" deniyor: bir projenin kaç kişi işten ayrılırsa ya da ortadan kaybolursa duracağını ölçen kaba bir gösterge. Faktör bire düştüğünde proje, tek bir kişinin zamanına, sağlığına ve motivasyonuna bağlı hale gelir. Milyarlarca isteğe hizmet veren bir dilin bu kırılganlıkta olması, teknik bir ayrıntı değil sistemik bir risk.

Sorun PHP'ye özgü değil. 2021'de Log4j güvenlik açığı patladığında, kütüphanenin dünya genelindeki kritik Java sistemlerinde çalıştığı ama avuç dolusu gönüllüyle sürdürüldüğü görüldü. OpenSSL'in şifreleme altyapısı yıllarca yetersiz bütçeyle, birkaç kişiyle yürütüldü; Heartbleed açığı bu tablonun bedeliydi. 2024'teki xz Utils vakası daha da çarpıcıydı: tükenmiş tek bir bakımcının üzerine yıllarca süren bir sosyal mühendislik operasyonuyla kod tabanına arka kapı sızdırılmaya çalışıldı. Her örnekte ortak payda aynı: devasa kurumsal kullanımın altında ince bir insan katmanı.

Buradaki asıl mesele bir paradoks. Büyük teknoloji şirketleri bu altyapıları ücretsiz tüketiyor, üzerine milyarlarca dolarlık ürün kuruyor; ama kaynak koduna geri katkı çoğu zaman sembolik kalıyor. Açık kaynak bir ortak mal gibi davranılıyor fakat ortak malın bakım maliyetini kimse tek başına üstlenmek istemiyor. Sonuç, kamusal değeri çok yüksek ama finansmanı kronik olarak eksik bir yapı.

Kime nasıl yansır?

Bir dilin bakım kapasitesi daraldığında etki zincirleme ilerler. Güvenlik yamaları yavaşlar, yeni sürümler gecikir, eski sürümlerin desteği erken biter. Bu da altyapıyı kullanan herkese bir maliyet olarak döner.

TarafOlası etki
Büyük şirketlerKendi yığınlarını korumak için iç ekip kurma ya da sponsorluk baskısı
Küçük işletmelerGüvenlik açıklarına karşı daha savunmasız, geç gelen yamalar
GeliştiricilerBelirsiz yol haritası, yavaşlayan dil gelişimi
Son kullanıcıVeri güvenliği riskinin dolaylı artışı

Karşılaştırma için bakıldığında, bazı diller bu riski kurumsal sahiplikle çözüyor. Go'nun arkasında Google, Rust'ın arkasında geniş bir vakıf ve çok sayıda sponsor var. PHP ise tarihsel olarak daha dağınık, gönüllü ağırlıklı bir modelle büyüdü. Bu model dili bugünlere taşıdı; ama ölçek büyüdükçe gönüllülüğün sınırları da görünür hale geliyor.

Sırada ne var?

İzlenmesi gereken birkaç başlık var. Vakfın sponsor tabanını genişletip genişletemeyeceği ilk sırada; birkaç büyük şirketin tek seferlik bağışı değil, sürdürülebilir ve kurumsallaşmış bir finansman akışı belirleyici olacak. İkincisi, çalışan sayısının artıp artmayacağı: bakım yükünü tek kişiden birkaç tam zamanlı geliştiriciye dağıtmak, otobüs faktörünü düşürmenin en doğrudan yolu.

Daha geniş çerçevede, açık kaynak finansmanı için kurumsal ve kamusal mekanizmaların olgunlaşıp olgunlaşmayacağı asıl soru. xz vakasından sonra bu tartışma hükümet ve büyük şirket gündemlerine de girdi, ancak somut ve kalıcı adımlar hâlâ sınırlı.

PHP'nin yarın çökeceğini düşünmek abartı olur; dilin geniş bir gönüllü topluluğu ve olgun bir kod tabanı var. Ama "tek çalışan" tablosu, modern internetin ne kadar kırılgan temeller üzerinde yükseldiğini net biçimde gösteriyor. Asıl risk ani bir çöküş değil; sessiz bir yıpranma, yani bakımın ağır ağır geride kalması. Bu yüzden bu, bir dilin değil bütün bir açık kaynak modelinin finansman sorunu olarak okunmalı.