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
2 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
Hacker News yorumları
En kapalı topluluklar bile kibar bir e-posta gönderirsen katkıları çoğu zaman kabul eder
Bir açık kaynak geliştiricisinin tacizden bıkıp deposundaki pull request’leri ve çeşitli özellikleri kapattığı bir dönem olmuştu; o sırada çok zor biri olduğuna dair bir ün de edinmişti
Ben arka plandaki durumu bilmeden, projenin zaten böyle işlediğini sandım; biraz araştırıp e-posta adresini bulduktan sonra da baskı yaratmayan, nazik bir e-postayla gayriresmî bir yama gönderdim ve ister kullanabileceğini ister görmezden gelebileceğini açıkça belirttim
Geliştirici teşekkür ederek yanıt verdi, durumu anlattı, hatta rahatsızlık verdiği için özür diledi; böyle kilitlemek dışında nasıl başa çıkacağını bilmediğini söyledi ve elbette düzeltmeyi de içeri aldı
Bu yazının, özgür yazılım projelerinin tartışma ya da hata bildirimini Discord üzerinden zorunlu kılması gibi yaygın sorunu ele alacağını sanmıştım
Bir iki hafta kadar başka araçlara geçme yönünde ilgi vardı ama sanki o da söndü; sonunda herkes pes edip yine Discord’a dönmüş gibi görünüyor
Discord tamamen korkunç değil ama geçici, bir de devasa ve şişkin bir web uygulaması gerektiriyor
Eski kuşaktan biri olarak, yazarın tavrı hoşuma gidiyor
ARPANET emektarlarının karşısında oturduğum günleri hatırlayacak kadar yaşlıyım; hani sadece 1 vardı da onun yarısını elle 0’a yontmak gerekiyordu ya
Eski yazılım geliştirme tarzında projeler genellikle bir ya da iki kişi tarafından yazılır veya sürdürülürdü; bütün internet de onların e-posta adreslerini bilir, hata raporlarını doğrudan onlara yollarıdı
Bazı projeler IRC ya da e-posta listelerinde tartışılırdı; insanlar genelde profesyonel davranırdı, davranmayanlar ise e-posta listesinden atılır ya da iirc ve pine engel dosyalarına girerdi
Asıl mesele, herhangi bir anda aktif geliştirici grubunun çok küçük olmasıydı
Burada daha çok make, Sendmail, sed, awk gibi küçük araçlardan söz ediyorum; Perl bile 1990’dan önce çoğunlukla yalnızca Larry Wall ve tchrist’ten ibaret görünüyordu
gcc ise binlerce kişinin yama gönderdiği ve yukarı akışa girmek için RMS ile de iyi geçinmek zorunda olduğu çılgın bir karşı örnekti
Yeni araçlar, daha büyük ekiplerin sürekli etkileşimini destekliyor; küçük bir ekibin de internetten herhangi biri böbreğini ortaya koyup yama göndermedikçe kimseye aldırmaması modelinin ciddi avantajları var
Ama bu yaklaşım insanları yapılan işe çekmek açısından avantajlı değil; dolayısıyla eski usul ilerleyebilirsin ama ekibin küçük kalır ve kullanıcı çekmen zorlaşabilir
Yine de bu kullanıcıların sorunu değil; ben yazılımı kendi kullanım senaryomu desteklesin diye kullanırım, başkalarına da yararlı olabilir diye açık kaynak olarak yayımlarım
Daha somut konuşursak, açık kaynak yalnızca dört temel özgürlüğü vaat eder(https://en.wikipedia.org/wiki/The_Free_Software_Definition)
Bunun dışında kelimenin tam anlamıyla hiçbir şey vaat etmez; buna ücretsiz olması da dahil değildir
Özgür/açık kaynak yazılım para karşılığında sunulabilir, hatta sunulmalıdır; buradaki “free” para meselesi değildir
Son dönemde çeşitli topluluklarda görülen açık kaynak “tedarik zinciri” saldırılarını epey olumlu görüyorum; çünkü iyimser bir açıdan bakarsak bunun insanlara açık kaynağın bir tedarik zinciri olmadığını fark ettirmesini umuyorum
Ayrıntılar burada: https://lobste.rs/s/cxwidw/no_one_owes_you_supply_chain_secu...
Bir satıcıya para ödemiyorsan ya da takvim güvencesi içeren bir sözleşmen yoksa, ortada bir tedarik zinciri yoktur
Neredeyse tüm FOSS lisanslarında “bu yazılım garanti olmadan sunulur” maddesi vardır; tedarik zinciri ise garanti ima eder, dolayısıyla FOSS bir tedarik zinciri değildir
Buraya gelip “açık kaynak”tan sanki “ahlaki bir değer”miş gibi söz edilmesini ve özgür yazılımdan aşırılmış kavramların ikisi aynı şeymiş gibi karıştırılmasını görmekten bıktım
Açık kaynak, büyük yazılım şirketlerinin sayısız gönüllüden alıp götürmesinden ibaret
Davranış kuralları tayfası sadece sorun çıkarmak için var
Kırmızı düğme/mavi düğme tartışmalarına bakmak bile yeter; o aşırı zehirli dil ancak düğmeler gerçekten varmış ya da insanlar sırf kötü davranmaktan hoşlanıyormuş gibi açıklanabilir
İyi niyetli davranış kuralları savunucuları ise örgütlenme özgürlüğü ile ifade özgürlüğünden söz eder
Bir platform karşı tarafı sevmiyorsa onu yasaklaması makul mudur, yoksa mesele yalnızca e-posta listelerindeki pratik “kibar olalım” geleneğiyle mi ele alınmalıdır?
Elbette karar yetkisinin kimde olduğuna bağlı, ama bu her projede böyledir
Proje liderliğinin istekleriyle çelişen koşullar öne sürüp başkasının projesine katılmayı talep ederken aynı anda örgütlenme özgürlüğü sahibi olamazsın
Tahminimce yazarın “gösterişli bir Code of Conduct gerekli değil” derken kastı, küçük bir projede bir şeyi dünyayla paylaşıp ileride dış katkı alma seçeneğini açık bırakmak istiyorsan, daha ortada somut bir durum yokken davranış kuralları hazırlamak zorunda olmadığın olabilir
Tamamen varsayımsal sorunlar için kafa patlatmaya gerek yok
Davranış kurallarının var olma nedeni, alternatifin ya keyfî ihlallere keyfî cezalar vermek ya da tam bir spam anarşisi olmasıdır
Eskiden netiket dersi veren insanların şimdi açıklığa ve sağlıklı topluluklara bu kadar karşı çıkmasını anlamakta zorlanıyorum
Bir daha düşününce, bu belki de Goomba fallacy’dir; davranış kurallarından nefret edenler belki de 1990’larda Usenet’te sürekli alevli tartışma ve spam saçan kişilerdir
Açık kaynak sadece bir lisans tercihi değildir
Özgür yazılımın şirketlere daha cazip görünmesi için yeniden çerçevelenmiş hâlidir; açık kaynağın özü de şirketlerin kapalı biçimde geliştirmesindense yazılımı kamu ile işbirliği içinde geliştirmenin daha etkili olmasıdır
Bu yüzden açık kaynak, açık bir topluluğu ima eder
İzin verici bir lisansla kodu kamuya bırakıp işbirlikçi geliştirme yapmak istemiyorsan elbette bunu yapabilirsin; o kod yine de açık kaynak koddur
Kodu açmak iyi bir şeydir ve bundan fazlasını yapma yükümlülüğün yoktur; ama bu, açık kaynağın tasarlandığı amaç doğrultusunda hareket etmek değildir ve onun çekirdeğinin bir kısmını göz ardı etmektir
Açık kaynak kodu görüp işbirlikçi geliştirme varsayımında bulunan insanlar mantıksız davranmış olmaz
Çünkü açık kaynak hareketinin amacı budur
Yazılımın için bu varsayım geçerli olmayabilir, sorun değil; ama toplumsal normu bozan taraf onlar değil sensin
Ben Stallman’ı, yazıcı sürücüsünü ve kullanıcının kendi çalışması üzerinde sahiplik kurmasını düşünüyorum; bu yüzden açık kaynağın amacı hakkında böyle kesin bir ifade bana doğru gelmiyor
https://en.wikipedia.org/wiki/The_Open_Source_Definition
Orada işbirlikçi geliştirme hakkında hiçbir şey söylenmiyor
İnsanlar duygusallaşıyor; çoğu zaman da yeni kullanıcıların temelleri öğrenmek istememesi ya da kullanıcıları kollamaya çalışması söz konusu oluyor
Destek forumlarından ayrı ama katı; zamanında yanıt veren ama mesafeli bir ilişki sürdürmek iyi olur
coreboot ya da MrChromebox buna iyi örnek; o da yalnızca gerektiğinde yanıt veriyor
Katılıyorum ve şunu da ekleyeyim: İnsanları yazılımı kullanmaya ikna etmeye çalışan bir pazarlama sayfası oluşturmak zorunda da değilsin
Hatta bunun yerine ya da buna ek olarak, neden bu yazılımı kullanmamaları gerektiğine dair tüm nedenleri anlatmak iyi olabilir
Kullanıcı sayısı arttıkça sorunlar da artar
Bir FOSS uygulamasının mutlaka herkese açık biçimde dağıtılması gerekmez; bu sadece yaygın bir toplumsal beklentidir
FOSS olması, kodun müşteri olmayan kişilere de verilmesi gerektiği anlamına gelmez; kimin müşteri olduğuna da geliştirici karar verir
FOSS, para karşılığında satılmayı teşvik eder; hatta başkasının başlangıçta ücretsiz olan yazılımını da satabilirsin (bkz. https://www.gnu.org/philosophy/selling.en.html)
Özgür olmayan bir lisansla sunulan açık kaynak da hâlâ açık kaynaktır ama FOSS değildir; geliştirici yazılımdan daha fazla para kazanmak ya da kendi lehine ek kısıtlar koymak istiyorsa özgür olmayan açık kaynak lisansı seçmekten utanmak zorunda değildir
Bu copyleft de olabilir
Özetle LICENSE.md hazırlıyor ve ona çok şey bağlıyoruz ama SOCIAL.md hazırlamayı kimsenin akıl etmediğini söyleyebiliriz
Biri “açık kaynak” dediğinde pek çok insan şunu varsayıyor: “Yazar bunu insanlar, toplum ve çevresindeki herkes için yapıyor; projenin geliştirilmesiyle, yeni özellikler eklenmesiyle, özellikle de benim ihtiyaç duyduğum özelliklerle ve tüm kullanıcıların yararına iyileştirmelerle ilgileniyor. Aksi hâlde neden kamuyla paylaşsın ki?”
Oysa bu, FOSS’a dair en yaygın toplumsal beklentidir; tek durum ise kesinlikle bu değildir
Teknik açık kaynak ile toplumsal açık kaynak ayrımının eksikliği; görüş ayrılıklarının, tartışmaların ve sonunda yanlış toplumsal beklentilerden doğan tükenmişliğin başlıca nedenidir
Eskiden öfkeli kalabalıklara bu meseleyi ve farkı açıklamak zorunda kalıyordum; yakın zamanda Jeffrey Paul’un https://sneak.berlin/20250720/the-agpl-is-nonfree/ yazısında açık kaynak kodun bir hediyeye benzetildiğini gördüm
Benim açıklamam sonunda şuna çıkıyordu: “Hediyeyi beğenmediysen ve sana uymuyorsa, at gitsin ve unut.”
OSI tarafından onaylanmış olup özgür yazılım sayılmayan lisansların sayısı çok azdır
https://www.gnu.org/licenses/license-list.html adresindeki GPL ile uyumlu olmayan özgür yazılım lisanslarının uzun listesine bakman yeterli
Ayrıca “FOSS olmayan açık kaynak” ifadesi de anlamsız; çünkü FOSS kelimenin tam anlamıyla Free and Open Source Software demektir
Artık herkes kullanabileceği çalıştırılabilir dosyalarla birlikte neredeyse doğrudan GitHub’a yükleniyor; şüpheli web siteleri ya da tuhaf derleme hatlarından geçmek gerekmiyor
“Topluluk” yok, siyaset yok, davranış kuralları yok, pull request ya da issue yok, wiki yok, çekirdek ekip yok; kulağa cennet gibi geliyor
Günümüzde projenin kendisine zarar veren çok fazla topluluk olduğunu düşünüyorum
Dahası, bir topluluğun açık kaynak projeye herhangi bir şekilde gerçekten yardımcı olduğu tek bir örneği bile hatırlayamıyorum
Hedefin kalite pahasına kontrolü azamiye çıkarmaksa, evet, bu mantıklı
Yalnız böyle bir durumda gerçekten FLOSS arıyor olman ne kadar doğru, emin değilim