Nereden nereye geldik. Açık kaynak projelerinde katkı politikalarındaki agresif değişiklikler, PR’ların açılmasına izin verilmemesi, issue’ların kolayca anlaşılmayacak kadar karışık yazılması ve paragraflarca okuyup hiçbir şey anlayamayan maintainer’ların öfkesi, tükenmişliği… Bu sanki açık kaynak projeler önemini yitirmiş gibi bir izlenim bırakıyor. Aslında kısmen doğru, eğer açık kaynak katkıcılığını sadece diff, commit sayısı üzerinden değerlendiriyorsanız öyle. Artık kod çok ucuz, bizim daha fazla konuşmamız, tartışmamız, ne olup bittiğini anlamamız, neyin sorumluluğunu üstlendiğimizi bilmemiz gerekiyor.

Bir Zamanlar Katkıcılık

Çok aktif bir katkıcı değildim ama bu işlere Pardus adında bir Linux dağıtımına uygulama paketleyerek bulaştım. Üniversitede öğrenciydim, uğraşacak bir şeyler arıyordum ve Pardus ekibi üniversitemde bir etkinlik düzenliyordu. Bu benim toplulukla ilk temasım olmuştu. Birileri sizin için sunum hazırlıyor, etkinlik için mekan ayarlanıyor, dağıtım cd’leri basılıyor, etkinlik için gerekli panolar, yaka kartları, hediyeler, çantalar için masraflar yapılıyor ve ben oraya bedavaya girip bu insanlarla ilk diyaloğumu kuruyordum. Sonra, sizi kendi açık kaynak projelerine katkıda bulunmaya veya onların ürünlerini kullanmaya davet ediyorlardı. Şimdi anlatınca hem duygulanıyorum hem de komik geliyor. Çok zor ve emek isteyen süreçlerdi bunlar. Ama siz ilk kez katkıcı olmak istediğinizde yazılı olmayan basit ilkeler vardı:

flowchart TB
OS((Açık Kaynak
Katkısı))

OS --> R[Sorumluluk Almak]
OS --> D[Bir Alanı Sahiplenmek]
OS --> M[Bakımını Üstlenmek]

Katkıda bulunduğun projedeki her sorunun sahipliği belli bir hiyerarşi içinde paylaşılır. Hiyerarşiden kastım, gönüllü/çalışan veya katkıcı/geliştirici gibi, biraz da parasal ilişkiye ve lisansa dayalı bir hiyerarşi. Sonuç olarak ortada bir issue varsa, bu bir katkıcı için kendi yazdığın kodu göndermenin en güzel fırsatlarından biriydi. Fakat o kodun repoya girme şansı, o projeyi geliştiren insanların veya topluluğun kültürüne ne kadar aşina olduğunuza göre değişirdi. Bazen hemen bir PR açmak, bazen önce haber verip issue’nun atanmasını beklemek, bazen sadece çözümü anlatmak gerekirdi.

Zaman geçtikçe, topluluk ya da projenin maintainer’ları senin belli konularla ilgili olduğunu görürlerdi. Bir süre sonra onların güvenini kazanıp artık onlar bu belli konularda sana danışmaya başlardı. Bazen yeni bir özelliğin tasarlanmasında ve geliştirilmesinde, bazen sorunların anlaşılmasında senden katkı beklenirdi. Bu konular bir proje, bir proje grubu, projenin bir parçası vs. olabilirdi.

Bu açık kaynak katkıcılığının en zevkli kısmı ise bana göre belli bir domainin bakımını üstlendiğin kişi olmaktı. Core developer’ların karar verdiği tasarımı, bakımını üstlendiğin projede uygulamak; örneğin hangi ses kütüphanelerini veya video codec’lerini desteklemeye karar verildiyse, XFCE masaüstü ortamını ona uygun parametrelerle derlemek, test etmek gerekiyordu ve bundan sen sorumlu oluyordun.

Yüzlerce geliştirici, bir çatı projeye aynı anda belli ilkeler ve hiyerarşi içinde, belli süreçlere uyarak kod değişiklikleri gönderiyordu ve bu, kısa zamanda çok fazla değişikliği mümkün kıldığı için çok değerli bir katkıydı. Kod pahalıydı.

Şimdi resme buradan bakılınca, kod yazmanın, AI araçları sayesinde ne kadar ucuzladığını çok net bir şekilde görebiliyoruz. Kod artık ucuz, tasarım pahalı!

Şimdi Anlatmak Daha Önemli

Tarafımı şu noktada belirtmek istiyorum. Ben açık kaynak yazılımın, katkıcılığın önemini yitirmediğini düşünüyorum. Fakat yöntemler ve roller kesinlikle değişti. Evet, bu kadar çok insan gücüne belki ihtiyaç yok; ama bir kaptana, kukla ustasına, karar vericiye ihtiyaç hâlâ var. İleride nasıl olacağını bilmiyorum; ama şu an var.

Şu an açık kaynak projelere baktığımda gördüğüm şey, henüz tam oturmuş bir context paylaşım altyapısının olmaması. Yani içinde wiki’yi, kod yazım kurallarını, planları, tartışma ve operasyon notlarını, verilen kararları, gelecek planlamaları içeren bir hafıza. Jira/Confluence gibi araçlar agent’lar için yeterli kullanışlılığı sağlamıyorlar, onlar da tıpkı editörler gibi insan odaklı yazılımlar. Başka bir çözüm gerekli. Bu en az formatter’lar, linter’lar, CI/CD yapılandırmaları kadar önemli. Örnek veriyorum, ben agent’la bir özelliğin geliştirilmesi konusunda tartışma yürüttüğümde, bana neden container’daki file system’in read-only olamayacağını, çünkü ses ve görüntü dosyalarını geçici olarak file system’da sakladığımı hatırlatması gerekiyor. Veya bu file system’da bir dosyanın hep var olduğunu düşünerek bir sistem tasarımı yapmaya kalktığımda, o dosyanın session state ile ilişkili olduğunu ve bir ömrü olduğunu, belli durumlarda dosyanın varlığını garanti edilemeyeceği konusunda uyarması gerekiyor. Eğer projenin Kubernetes desteği varsa ve HPA kullanımını desteklemek istiyorsak, SessionState’i memory’de tutarken nelerle karşılaşabileceğimizi hatırlatması gerekiyor. Artık kod ucuz, artık agent’a tasarım anlatmamız ve agent’ın dediklerini anlamamız gerekiyor. Bunun için de ortak bir hafıza gerekiyor. Açık kaynak geliştiricileri, ortak hafıza sisteminin oluşturulmasında doğal olarak kontrolü elde tutmak isteyeceklerdir; ancak bir özellik geliştirirken implementasyondan önce tasarımı iyi anlatabilirseniz bu tarz katkılara açık olabileceklerini düşünüyorum.

İkinci olarak soru sormaya değinmek istiyorum. İyi sorular sormak, projenin gerçek bir müşterisi gibi olmakla ilişkili, veya o kullanıcının açık kaynak projeyi entegre ederken yaşadığı sıkıntıları iyi anlamakla ilişkili. Bunun için en iyi kaynak, o açık kaynak projelerin Discord/Slack kanalları. Örneğin benim bir speech-to-text uygulamasına ihtiyacım var, kısmen duyabildiğim için word accuracy’nin %80 olmasına katlanabilirim ama 300ms gecikme benim için kabul edilebilir bir şey değil! Her yerde iyi bir internetim yok, acaba bu uygulamanın offline çalışmasını sağlayabilir miyiz? Donanım buna ne kadar izin veriyor, eldeki seçenekler neler, bunu yapmaya değer mi? Bu tarz soruların teknik çözümlerle birlikte ticket olarak açılması hala çok değerli bir katkı ve gördüğüm kadarıyla açık kaynak proje yöneticileri ticket açmaya izin veriyor.

Bunun dışında, ilk bölümde anlattığım eski usül topluluk buluşmalarının, yüz yüze görüşmelerin hala bir işlevi olduğunu düşünüyorum. Zaman, emek gerektiriyor, bir de coğrafi kısıtlamalar mevcut; ama geliştirdiğiniz bir projenin geliştiricisini karşınızda görmek, gerçek bir motivasyon sağlıyor. Hele ki o kişi orada yaşamayıp, sizin için oraya bir şeyler anlatmak için gelmişse.