Açık kaynak tek kişiden ibaret

• Son haberlerde Rus bir geliştiricinin yaptığı açık kaynak yazılımın kullanımı eleştirildi
• Gerçekte neredeyse tüm açık kaynak projelerinin büyük çoğunluğu, tek bir bireysel bakımcı tarafından yürütülüyor
• Yalnızca NPM değil, çeşitli ekosistemlerde de popüler paketleri yöneten tek bakımcı örnekleri çok yaygın
• Bu yapının sorunu, tek bir bakımcının üzerindeki aşırı yük ve tedarik zinciri riski
• Sorunun özü milliyet değil, gerçekte yetersiz olan kaynak ve destek

---

Giriş: Açık kaynak ve son tartışma

• The Register'da, Rus bir geliştiricinin yaptığı açık kaynak yardımcı aracın kullanımında ABD Savunma Bakanlığı bağımlılığını sorun eden bir yazı yayımlandı
• Söz konusu açık kaynak geliştiricisi haksız eleştirilere maruz kalıyor
• Yazının içeriği, açık kaynağın gerçekliğini yanlış anlıyor ve bu yaklaşımın sınırlarına işaret ediyor

Açık kaynağın gerçeği: 'tek kişi' yapısı

• Verilere göre, açık kaynak projelerinin neredeyse tamamı tek kişi tarafından yönetiliyor
• ecosyste.ms projesinde yaklaşık 11,8 milyon açık kaynak proje verisi toplanıyor
  • Bunların yaklaşık 7 milyonu tek bakımcılı
  • Kalan yaklaşık 4 milyon projenin bakımcı sayısı bilinmiyor, ancak önemli bir kısmının yine tek kişi olduğu tahmin ediliyor
  • Yalnızca çok az sayıdaki projede yüzlerce bakımcı bulunuyor

Popüler projeler de istisna değil

• Birçok kişi, "önemli açık kaynak ya da popüler projeler birkaç kişi tarafından yönetiliyordur" diye düşünüyor; ancak gerçekte NPM gibi başlıca ekosistemler de farklı değil
• NPM ekosisteminde 4 milyondan fazla tek bakımcılı proje bulunuyor
• Aylık 1 milyonun üzerinde indirilen NPM paketleri arasında bile yaklaşık yarısı tek bakımcı tarafından yürütülüyor
  • İndirme sayısı 1 milyara çıkarıldığında bazı farklar ortaya çıkıyor, ancak yine de tek bakımcılı paketler mevcut
• NPM içindeki 4 milyon tek bakımcılı projeyi fiilen yöneten kişi sayısı yaklaşık 900 bin (yani bir kişinin birden fazla projeden sorumlu olduğu bir yapı)

Sorunun özü: ülke değil, kaynak eksikliği

• Açık kaynağın ekonomik ölçeği trilyonlarca dolarlık bir temel oluşturuyor (Harvard araştırmasına göre 8,8 trilyon dolar)
• Tek bakımcılı projelerin çoğunda kaynak eksikliği var ve tedarik zinciri riski bulunuyor
• En büyük risk, bir ülke değil; aşırı çalışan ve emeğinin karşılığını doğru dürüst alamayan 'tek bir bakımcı'
• Medya vb. aktörlerin bireysel bakımcıları hedefe koyması çözüm değil

Sonuç ve eylem noktaları

• Mevcut sorunun nedeni tek bakımcılı yapı; odağı ülkelere çevirmek anlamsız
• Bireysel bakımcıları şeytanlaştırmak ya da tespit etmeye çalışmak çözüm değil
• Bu sorun karmaşık ve ortada hemen uygulanabilecek bir çözüm yok
  • İlgili tartışma, Hobbyist Maintainers with Thomas DePierre podcast'inde de ele alındı
• Tek bakımcıları işaret edip suçlamak yerine, yapısal sorunlar ve destek yolları üzerine düşünmek gerekiyor

[GN⁺]

Hacker News görüşleri

• Yazılım topluluğunda bu konuda çok fazla yanlış anlama var gibi geliyor; aslında tedarik zinciri riski yazılım ya da mühendislik meselesinden çok bir yönetişim meselesi diye düşünüyorum
  Kötü niyetli kimse olmasa bile bir projede tedarik zinciri riski oluşabilir ve tedarik zinciri riskini değerlendiren herkesin güvenlik bakışı ve ölçütleri farklıdır
  DoD (ABD Savunma Bakanlığı), sıradan geliştiricilerden tamamen farklı bir açıdan risklere bakar ve birçok tek kişilik proje, sırf sorumlu kişi sayısı bir olduğu için risk sayılır
  “Bus factor” 1 ise, bu başlı başına bir tedarik zinciri riskidir
  Çoğu insan paket seçerken savaş durumunu hesaba katmaz ama ordu bunu hesaba katabilir
  Savaş çıkarsa, normalde özerk biçimde yürütülen açık kaynak projelerde bile durum hızla değişebilir
  Gerçekten de birçok ülke savaş zamanında yasayla özel şirketlerin ya da bireysel projelerin işbirliğini isteyebildiği için, bunu bile güvenlik riski hesabına katan yerler vardır (DoD gibi)

  • Millet, hep birlikte haykıralım: paketleri mutlaka vendor edin! Vendor edin!
  • Buna rağmen “tek bir geliştirici yakında milyar dolarlık bir yazılım şirketi kurabilir” türü abartılı pazarlamanın sürmesi üzücü
  • DoD olsaydı, ilgili paketin tüm kodunu tek tek okumaya, güncellemeleri kilitlemeye ve gerekirse kendisi yamamaya hazır değilse onu hiç kullanmazdı diye düşünüyorum
    Savaş ortamında “keşke hiç güvenmediğimiz bir kişi daha olsaydı” gibi bir anlayışla hareket etmezdi

• NPM’de 4 milyon tek kişilik proje olduğu ve bu projeleri yaklaşık 900 bin kişinin yönettiğine dair veri vardı; bunun gerçekten önemli nokta olup olmadığını merak ettim

  • Açıkça söylenmedi ama sanırım kastedilen şuydu
    Yani açık kaynağın ekonomik değerinin büyük kısmını (Harvard bunu 8,8 trilyon dolar olarak tahmin ediyor) çoğunlukla “tek kişilik projeler” üretiyor ve bunların hiçbiri düzgün kaynak desteği almıyor
    Tedarik zinciri riskinden söz ederken asıl tehlikeli olan, düşük ücretle aşırı çalışan tek kişilik bakımcıdır
    O kişinin hangi ülkeden geldiği aslında o kadar da önemli değil diye düşünüyorum

• Tek kişilik bir bakımcı aniden kaza geçirirse ya da projeyi bırakırsa ne olduğuna dair istatistik olup olmadığını merak ediyorum
  Bu kadar veri varsa araştırmaya değer görünüyor
  Yeni bir geliştirici projeyi devralıyor mu, benzer başka bir projeyle mi yer değiştiriyor, yoksa tamamen mi yok oluyor bilmek isterdim

  • Duruma göre değişir
    Gerçekte otobüs kazasından çok, “bakımcının ilgisini kaybetmesi ya da zamanı kalmaması nedeniyle elini çekmesi” daha yaygındır
    Böyle durumlarda sık görülen senaryolar şunlardır
    1. birinin fork açıp sonunda o fork’un asıl projeyi değiştirmesi
    2. aynı işi yapan yeni bir projenin popülerleşip mevcut projenin yerini alması
    3. asıl bakımcının proje yönetimini başka birine devretmesi
    4. kimse bakım yapmasa da projenin kullanılmaya devam etmesi; sorun çıktığında herkesin kendi fork’unu açıp çözmesi ama bu fork’ların ana akım hâline gelmemesi
       Açık kaynağın gücü şurada: üreticisi ortadan kaybolsa, tuhaflaşsa ya da lisansı değiştirse bile, birileri fork’layıp onu yaşatabilir
       Buna karşılık ticari yazılımda üretici ister şirket ister kişi olsun ortadan kaybolur ya da içeriği değiştirirse, iş biter
       Geriye sadece alternatif ürün aramak kalır
  • Böyle popüler açık kaynak kütüphane/araç/uygulama/site’ların bir yöneticiden diğerine geçiş sürecini ele alan bir bölüm serisi olsa kesin izlerdim
    Zaten Netflix işletmiyor oluşumun sebebi de bu
  • Benim deneyimime göre üç durumun da gerçekten yaşandığını gördüm
    Sonuçta kullanıcı sayısına, kod tabanının karmaşıklığına ve alternatiflerin olup olmamasına bağlı bir mesele
  • Buna en yakın örnek olarak Hans Reiser/Reiserfs aklıma geliyor
    Sadece “otobüs çarpması”ndan çok daha garip bir hikâye ve sonuçta o proje yok oldu
  • İnsanların gözden kaçırdığı şey şu: kod açık kaynaksa, zaman alsa bile en kötü durumda her zaman fork’lanabilir

• İki ya da daha fazla kişinin bakım yaptığı projelerde bile, fiilî commit’lerin büyük kısmını sonunda yine tek bir kişi yapıyor

  • Bu yüzden kişisel web sitemde 11ty kullanmaktan kaçınıp Jekyll’i seçtim
    İlgili bağlantı: https://github.com/11ty/eleventy/graphs/contributors

• Sadece etkinlik kontrolü yapılmış olsaydı bile, tüm projelerin yarısında bakımcı sayısının 0 olduğu hemen görülürdü diye düşünüyorum

  • Yazılım bir kez “mükemmelleşti” gibi hissedildiğinde artık bakım gerektirmediği durumlar da olabilir
    Yani temizlik, ince ayar ya da kalibrasyon gerektirmeden öylece bırakılabilir
    Hatta bazen sorun projenin kendisi değil, güncellemelerin kendisidir

• DoD’nin node kullandığını bilmek daha da endişe verici
  npm gibi platformların saldırı yüzeyinin fazla geniş olduğu hissi var

  • Neden diye merak ediyorum
    DoD, dünyadaki en büyük kurumlardan biri olduğu için bülten gönderimi ya da izci kampı turu rezervasyonu için web sayfası gibi pek çok işi vardır
    Böyle yerlerde node kullanılmasının sakıncası olmayabilir
    Bu tür sistemler füze fırlatma gibi kritik sistemlerden ayrı işletilir ve sadece etkinlik başvuru sayfası bozulsa da büyük sorun olmaz
  • DoD o kadar büyük ölçekli ki muhtemelen neredeyse tüm önemli platformları kullanıyordur

• Birçok tek kişilik GitHub projesinin aslında “hello world” tarzı kişisel deneyler ya da şakalardan ibaret olduğunu düşünüyorum
  npm’de durum nasıldır bilmiyorum ama PyPI’da da benzer örnekler dolu
  Kendim “browse projects”e tıklayınca şu çıktı: https://pypi.org/project/helloworld-eduardo/
  İnsan ne kadar sarhoş olursa olsun bunu üründe kullanmayı düşünmez herhalde

• DoD, bir şeyi bedavaya alabiliyorsa herkesi “bundan hepimiz kazançlı çıkarız” diye ikna edip sonunda işi para verip taşerona yaptırmakta oldukça iyidir

  • Truva atı olayını düşününce, bedavanın her zaman iyi bir şey olmadığı anlaşılıyor

• “Tek kişilik bakımcısı olan ve 1 milyardan fazla indirilen paket” dendi ama bunun tam olarak ne anlatmak istediğini merak ediyorum

• Linus adlı kişinin yaptığı iş hakkında çok iyi şeyler duydum ve muhtemelen oldukça fazla kullandım
  Kendisi Rusya ile sınırı olan bir ülkeden geliyor; bu da ayrıca hesaba katılması gereken bir şey mi diye düşündürüyor
  Onlarca yıldır açık kaynak geliştiriyorum; bunu ya neredeyse tek başıma yaptım ya da bazen gönüllü bir ekip kurdum
  Gönüllü ekipte çalışmış olanlar bunun gerçekten kolay olmadığını bilir
  Elbette tamamen imkânsız değil ama düşündüğümüz kadar sık sorunsuz yürümüyor
  İyi işlediğinde genelde ya bir “BDFL (benevolent dictator for life)” vardır ya da herkes tek bir hedef doğrultusunda hareket eder
  Benim durumum çoğunlukla ikincisiydi

  • (Konu dışı) Linus’un ebeveynleri de siyasi olarak aktifmiş ve Linus’un kendisi de çocukluğunda komünist gençlik örgütünde (izcilere benzeyen bir yapı) yer almış
    Babası da birkaç yıl Moskova’da yaşamış
  • Linux, geniş bir bakımcı ve destek ağına sahip bir proje; Linus’un tek başına geliştirdiği bir tek kişilik projeyle tamamen farklı