Açık kaynak, açık topluluk anlamına gelmez
(blog.feld.me)- Açık kaynak yazılım, (D)VCS öncesinde de yalnızca HTML sayfaları, txt dosyaları, FTP tarball'ları ve e-posta iletişim bilgileriyle dağıtılabiliyordu; kamusal bir topluluk olmasa da yine açık kaynaktı
- Bir mailing listesi ya da IRC kanalı varsa şanslı sayılırdınız; ancak pull request, issue, wiki, core team ve Code of Conduct açık kaynağın zorunlu koşulları değildi
- Sourceforge, CVS/SVN ve mailing listelerini neredeyse ücretsiz sunarak kamusal geliştirmeyi kolaylaştırdı; ardından git, DVCS rekabetini kazandı ve dünya GitHub etrafında yakınsadı
- GitHub sonrasında açık kaynak bakımı; issue'lar, kapsam dışı pull request'ler, şikayetler ve talepler, hatta sohbet grubu yönetimini de üstlenen ücretsiz emek gibi bir şeye dönüştü ve bu durum tükenmişliğe ve kontrol kaybına yol açabiliyor
- Bir projenin mutlaka kamusal olarak geliştirilmesi gerekmez; issue tracker ve pull request'i kapatabilir, bare git sunucusu kullanabilir, güvendiğiniz küçük bir grupla ya da tek başınıza açık kaynak yürütebilirsiniz
GitHub sonrası bakım yükü
- GitHub, açık kaynağı bakımcılar için ücretsiz emek gibi hissettirdi
- İşte ticket'lar, paydaş toplantıları, roadmap, politika, dikkat dağıtıcı unsurlar, son tarihler, metrikler, KPI'lar, değişen gereksinimler, standup, one-on-one, Agile ve Waterfall ile uğraştıktan sonra bile eve gelince açık kaynak bildirimlerinin biriktiği bir yapı oluştu
- issue'lar birikiyor, yazılımı projenin kapsamı dışındaki yönlere doğru yeniden tasarlayan pull request'ler geliyor, şikayetler ve talepler artıyor
- Sohbet grupları ve “topluluk” oluşunca, bakımcılar sabırsız insanları yönetme ve bire bir ilgilenme sorumluluğunu da üstlenmek zorunda kalıyor
- Sonuç olarak açık kaynak ikinci bir işe dönüşüyor ve bakımcılar tükenmişlik yaşayarak kendi projelerinin kontrolünü ve yönünü bile kaybedebiliyor
Yeniden sade işletmek
- Bazı projeler ekip yönetimi gerektirecek kadar büyük ve karmaşıktır; ancak bu istisnadır, genel durum değildir
- Yeni insanlar ve yapay zeka botları dikkatinizi dağıttığı için öfkeleniyorsanız, eski yönteme dönebilirsiniz
- issue tracker ve pull request'i kapatabilir ya da kodu yayımlamak için bare git sunucusu işletebilirsiniz
- Gerçekten tanıdığınız ve güvendiğiniz küçük bir grupla çalışabilir ya da projeyi tamamen tek başınıza yürütebilirsiniz
- Yabancıların kendi alanınıza müdahale etmesine izin vermek zorunda değilsiniz; göstermelik bir Code of Conduct ya da LLM politikası da şart değildir
- Açık kaynağın “açık kaynak” olması için mutlaka kamusal olarak geliştirilmesi gerekmez
- İstediğiniz araçları kullanın, sevdiğiniz şeyleri üretin; sabah 2'de bir code drop da yapabilirsiniz, teknoloji inkübatörüyle kreş karışımı bir işletim modeline sürüklenmek zorunda değilsiniz
1 yorum
Lobste.rs görüşleri
Bu düşünce yüzünden https://casuallymaintained.tech/ sitesini yaptım ve çok hoşuma gidiyor
En bilinen örnek SQLite; dış katkıları kabul etmiyor
Airbus uçakları gibi görev kritik uygulamalarda da kullanıldığını düşününce bu makul bir politika
SQLite açık kaynak olduğu için istediğiniz kadar kopyalayabilir ve herhangi bir kısıtlama olmadan kullanabilirsiniz, ancak açık katkı (open-contribution) projesi değildir
SQLite'ı public domain olarak tutmak ve içine sahipli/lisanslı kod karışmasını önlemek için, katkısını public domain'e adadığını beyan etmeyen kişilerin patch'lerini kabul etmiyorlar
Oldukça taze bir bakış açısı
Belki de yazar haklıdır ve bakımcılardan fazlasını bekliyoruzdur
Bozulan şey belki açık kaynağın kendisi değil, açık kaynağın ne sunması gerektiğine dair beklenti enflasyonudur
GitHub'ın sosyal yönü de bunda etkili olabilir. Yıldızlar ve sıradan kullanıcılar arttıkça, projeye bakmaya gelen yeni insanları memnun etme baskısı da büyüyor
Özellikle topluluğun ilgisi ve talepleri, projeyi yaratan kişinin ilk vizyonuyla uyuşmadığında riskli hale geliyor
İlgili yazı: Git without a Forge: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/
Sağlam bir yaklaşım; keşke daha fazla kişi bunu varsayılan olarak benimsese
Topluluk oluşturmak ya da bir tür sorumluluğu üstlenmek istisnai ve bilinçli bir tercih olmalı
Davranış kuralları ve LLM politikalarını göstermelik olarak nitelemesi biraz kopuk geliyor, ama konu hassas olduğu için anlayabiliyorum
Ama kullanıcısı da topluluğu da olmayan ve ileride de olmasını istemeyen tek kişilik bir depoya eklendiğinde göstermelik hale geliyor
Sadece kendim için kullandığım bir depoda kendime yönelik bir davranış kurallarına ihtiyacım yok
Bu tartışmanın güç kazanıp gerçekten işe yarayan bir uzlaşıya dönüşmesi harika olurdu
Yazılım üretmenin ve sağlıklı katkı vermenin pek çok yolu var
Ancak bunlar birbirleriyle uyumlu olmayabilir, açık kaynağın yüksek standartlarıyla örtüşmeyebilir, görünürlük ve popülerliğin maliyetini gerektirebilir ya da lisans, self-hosting, kod katkısı kabul etmeme gibi farklı araçlara dayanabilir
Topluluk yazılımlarında eğlence ve adaleti öne koyan iyi bir yolu birlikte bulabilsek keşke
Yazıda tarif edilen durum, ünlü olmayan birinin yeni başlattığı hemen her kişisel açık kaynak projesinin doğal hali
Hepimizin bu şekilde yürüyen epey projesi var
Sorun, insanların projelerden ne elde etmek istediklerini bilmemeleri ya da popüler bir proje yürütmenin havalı olacağını düşünüp bunun maliyetini gerçekten hesaba katmamaları
Sonra da bilinçli ya da bilinçsiz şekilde ilgi peşinde koşma başlıyor
“GitHub açık kaynağın tamamını bakımcılar için ücretsiz işe çevirdi” sözü ancak siz izin verirseniz doğrudur
Belirsiz bir ün vaadini çıkarınca, çoğu durumda GitHub'ın size aslında yapmak istemediğiniz şeyleri yaptıracak pek bir kozu yok
Doğru bir tespit
Eskiden biraz popüler olmuş bir projem vardı ve istemediğim özelliklerle ilgili bug raporlarıyla pull request'leri ele almak zorunda kaldığım için strese giriyordum
Keşke o zaman böyle bir yazıyı okuyabilseydim
Ek olarak https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 bağlantısına da bakmaya değer
Küçük projeler söz konusu olduğunda bu yazıya güçlü biçimde katılıyorum
Daha büyük projelerde bile en başarılı olanlar çoğu zaman baştan açık bir topluluk olarak başlamadı
Sevdiğim projelerin çoğu büyük kurumlarda geliştirilmeye başlandı ve asıl kilit nokta, o yazılımın kurum içinde gerçekten aktif biçimde kullanılıyor olmasıydı
Yani bakımcılar zaten bunun için maaş alıyordu
İster kişisel proje olsun ister iç ekip işi, geliştiricinin kendi gündelik sorunlarını çözmek için yaptığı yazılımlar; şöhret veya ticarileştirme amacıyla yapılanlara kıyasla daha başarılı ve daha az sömürücü görünüyor