GitHub Öncesi Açık Kaynak Dünyası

• Açık kaynak bağımlılıkları yalnızca bir paket seçimi değil, projenin itibarı ve sürdürülebilirliği ile bakım biçimini de birlikte değerlendirme işiydi
• Dağıtık sürüm kontrol sistemleri yaygınlaşsa da, gerçek işbirliğinin merkezi yeniden GitHub’da toplandı ve bu durum modern açık kaynağın büyük ironilerinden biri olarak kaldı
• GitHub, issue tracker, pull request ve release sayfası gibi özelliklerle kamusal işbirliğinin varsayılanlarını değiştirdi; proje keşfini ve katkı akışını da büyük ölçüde kolaylaştırdı
• Aynı zamanda GitHub, terk edilmiş depoları ve tartışma kayıtlarını bile saklayan bir arşiv görevi görerek, kolayca kaybolabilecek ortak yazılım varlıklarının hafızasını korudu
• Son dönemde GitHub’ın merkeziliğinin zayıfladığına dair işaretlerle birlikte, açık kaynak için tek bir şirketin iş modelinden bağımsız olarak hafızayı koruyan ve bağımlılığı azaltan kamusal arşivler daha da önemli hale geliyor

---

GitHub Öncesi Açık Kaynak Ortamı

• GitHub’dan önce güvenle bağımlı olunabilecek proje sayısı sınırlıydı ve her projenin itibarı ile sürdürülebilirliği, bağımlılık seçimleriyle doğrudan bağlantılıydı
• Bağımlılık yalnızca bir paket adı değil; projenin geçmişi, web sitesi, bakımcıları, release süreci ve topluluk bağlamını da beraberinde getiriyordu
• Büyük projeler çoğu zaman kendi altyapılarını işletirken, küçük projeler üniversite sunucularında ya da SourceForge üzerinde yer alabiliyordu
• Debian paketleme sürecinde olduğu gibi lisans ve telif hakkı başlıklarının bile incelendiği sürtünmeler vardı ve bu sürtünmeler de güven değerlendirmesinin bir parçası olarak işliyordu

Kendi Altyapısını İşletmek ve Dağıtık Sürüm Kontrolünün Paradoksu

• Erken dönem açık kaynak projelerinin Trac, Subversion, tarball ve belgeleri doğrudan kendilerinin işlettiği sunucular üzerinde yürütmesi yaygındı
• Pocoo gibi örneklerde birden çok proje, sunucu maliyetlerini ve Subversion, Trac, e-posta listesi işletme yükünü birlikte paylaşıyordu
• Subversion merkezi bir depo olduğu için sunucu işletmek doğal olarak bunun parçasıydı; projenin evi de host adı, dizin, Trac instance’ı ve e-posta listesi arşivi gibi unsurlarla fiziksel olarak açıktı
• Mercurial ve Git, herkesin deponun tamamına, branch’lere ve geçmişe sahip olabildiği dağıtık sistemlerdi; ancak pratikte merkez yeniden GitHub’da toplandı
• Dağıtık sürüm kontrol sistemleri kazandıktan sonra tüm dünyanın tek bir dev merkezi hizmet üzerinde standartlaşması, modern açık kaynağın büyük ironilerinden biri olarak kaldı

GitHub’ın Yarattığı Değişim

• GitHub, proje oluşturmayı ve keşfetmeyi kolaylaştırdı; geliştirme e-posta listesi deneyimi olmayan kişilerin bile katkı akışını daha kolay anlamasını sağladı
• Issue tracker, pull request, release sayfaları, wiki, organization sayfaları, API, webhook ve daha sonra CI sunarak kamusal işbirliğinin varsayılanlarını değiştirdi
• Açık kaynak işbirliği, görünür geçmiş ve görünür tartışmalar üzerinde ilerleyen bir biçim olarak yaygınlaştı
• Bir dönem GitHub, açık kaynak projeleri barındırmak için son derece makul varsayılan seçenek işlevi gördü
• ABD yaptırımlarına tabi ülkelerde bile GitHub erişilebilirliğini korumaya çalışan politika gibi örneklerle, merkezileşme yalnızca hosting’in ötesinde erişilebilir ortak bir altyapı rolü de oynadı

Arşiv Olarak GitHub

• GitHub’ın daha az dikkat çeken işlevi arşiv rolüydü; terk edilmiş projeler bile aranabilir biçimde kaldı ve ortak yazılım varlıklarının bir indeksi gibi çalıştı
• Fork’ların, eski issue’ların ve tartışma kayıtlarının kalıcı olması, merkezileşmenin keşfedilebilir bir hafıza üretmesini sağladı
• Buna karşılık büyük platformlardan önce, kişisel domain’in süresinin dolması, VPS’in kapanması ya da geliştiricinin ortadan kaybolmasıyla birlikte proje dosyalarının ve hizmetlerin yok olması yaygındı
• PyPI’de yalnızca metadata’sı kalıp gerçek paketi kaybolmuş erken dönem projeler örneğinde olduğu gibi, depo adresinin eski kişisel sunucuları işaret edip kopması sık görülüyordu
• Geçmişteki pek çok proje sonunda Internet Archive gibi harici koruma araçlarına ciddi biçimde bağımlı hale geldi

npm ve Bağımlılık Patlaması

• Micro dependency sorunu, yalnızca küçük paketlerin çoğalmasıyla sınırlı kalmadı; GitHub ve npm’in oluşturma, dağıtma, arama, kurulum ve bağımlılık maliyetini neredeyse yokmuş gibi göstermesiyle daha da büyüdü
• GitHub’dan önce güven ve sürdürülebilirlik bağımlılık seçiminde zorunlu unsurlardı; başka hizmetlerin erişilebilirliğine güvenmek zor olduğundan, kodu doğrudan depoya dahil etme yani vendoring de yaygındı
• API öncesi dönemde harici kod getiren script’leri sürdürmek zahmetliydi ve bu sürtünme, yeni bir bağımlılık eklemeden önce bir kez daha düşünmeye zorluyordu
• npm tarzı ekosistemlerde paket grafiği, insanların akıl yürütebildiği hızdan daha hızlı büyüyebiliyor
• Lisans durumunun belirsizleşmesi sorununa yanıt olarak GitHub, hizmet şartlarını güncellemeyi de denedi
• Küçük bir pakete bağımlı olunurken bile depo, bakımcıların varlığı, issue’lar, son değişiklikler, başka projelerde kullanılıp kullanılmadığı ve kodla paket açıklamasının örtüşüp örtüşmediğini GitHub’da kontrol etme kültürü yerleşti
• GitHub, npm gibi registry’ler için trusted publishing sağlayan az sayıdaki sistemden biri haline geldi; GitHub’a duyulan güvenin zayıflaması, kaynak kodu barındırmanın ötesinde tüm tedarik zinciri kültürünü de etkiliyor

GitHub’ın Zayıflaması ve Göç İşaretleri

• GitHub son dönemde istikrarsızlık, sürekli ürün değişiklikleri, Copilot AI gürültüsü ve belirsiz liderlik nedeniyle eski kaçınılmazlığının bir kısmını kaybediyor
• Agentic coding akımının tam ortasında yer almasıyla iç baskılar da arttı; ancak şu anda durum, liderlik eksikliğinin güçlü biçimde hissedildiği bir tablo olarak anlatılıyor
• Bir süre GitHub’dan ayrılmak daha çok sembolik bir hareket gibiydi; artık etkisi büyük projeler de taşınmayı açıkça değerlendirmeye ya da uygulamaya başladı
• Ghostty’nin GitHub’dan ayrılma duyurusu, varış noktası henüz net olmasa bile güçlü bir sinyal olarak görülüyor
• Strudel Codeberg’e taşındı
• Tenacity Codeberg’e taşındı
• Henüz büyük bir yön değişimi yaratacak düzeyde olmayabilir; ancak GitHub dışındaki barındırma alanlarını yeniden daha sık görmeye başladığımız bir eğilim ortaya çıkıyor
• Git’in kendisi zaten baştan birden fazla ev varsayımıyla tasarlandığı için, tek bir şirketin her şeyin varsayılan evi olması durumunun sona ermesi açık kaynak için sağlıklı olabilir

Dağıtıma Geri Dönüşün Maliyeti

• Birden fazla forge, birden fazla sunucu ve birçok küçük topluluğa geri dönülürse merkezsizlik ve özerklik artabilir; Microsoft yönetimindeki değişimlere bağımlılık da azalabilir
• Her topluluğun kendi iş akışını seçebilmesi de bir avantajdır
• Pi üzerindeki mevcut issue tracker sorunu, GitHub’ın ürün tercihinin bugün açık kaynak bakım gerçekliğiyle uyuşmayan sonuçlara yol açtığını gösteriyor
• GitHub’ın, bakımcıların ruh sağlığından çok engagement odaklı tasarlandığı yönü daha görünür hale geldi
• Buna karşılık self-hosted forge’lara, kendi Mercurial sunucularına ya da cgit sunucularına geçildiğinde kodun kendisi dağılsa bile sosyal bağlam kolayca dağılabiliyor
• Issue’lar, review’lar, tasarım tartışmaları, release notları, güvenlik duyuruları ve eski tarball’lar sanıldığından çok daha kolay kayboluyor
• Geçmişte bu bağlamı taşıyan e-posta listeleri, bugünün ihtiyaçlarına ayak uyduramadı ve kullanıcı deneyimi de iyi değil
• Yazılımın unutulabilir olmasında bir tür arındırıcı etki olabilir; ancak kayıp riski büyüdüğünde, dağıtık sürüm kontrol sistemlerini pratikte nasıl kullandığımızı yeniden düşünmek gerekiyor

Gerekli Olan: Kamusal Bir Arşiv

• GitHub kalsa da projeler başka yerlere gitse de, açık kaynağın kamusal, sıkıcı ama istikrarlı bir arşive ihtiyacı var
• Geliştirici üretkenliği pazarında kazanmayı hedefleyen bir hizmetten ziyade, önemli yazılımların kaybolmamasını sağlayacak bir yapıya ihtiyaç duyuluyor
• Bu yapı, endowment ya da kamu fonu gibi uzun vadede sürdürülebilir bir temel üzerinde çalışmalı
• Kaynak kodu arşivleri, release çıktıları, metadata ve proje bağlamı tek bir şirketin iş modeline ya da liderlik ruh haline bağlı olmayan yerlerde korunmalı
• GitHub, açık kaynak faaliyetinin merkezi haline gelirken tesadüfen bu arşiv rolünü de üstlendi; ancak merkeziliği zayıfladığında bu işlevin otomatik olarak süreceğini varsayamayız
• Kişisel sunucular ve iyi niyet tek başına koruma için yeterli olmadı; Google Code ve Bitbucket’ta da platform kapandıktan sonraki boşluk zaten görüldü
• Gelecekteki sistemler hafızayı koruyup bağımlılığı azaltma yönünde ilerlemeli; proje taşımak, sosyal bağlamı mirror etmek ve release’leri korumak kolaylaşmalı, tek bir şirketin savrulması herkes için kültürel bir krize dönüşmemeli
• Ne kırık tarball bağlantılarına ve terk edilmiş Trac instance’larına geri dönmek istiyoruz, ne de son 20 yılın GitHub merkezli yapısını kalıcı normal durum olarak kabul edebiliyoruz; bu gerilim varlığını sürdürüyor

[GN⁺]

Hacker News yorumları

• GitHub'ın getirdiği en büyük değişimlerden birinin proje merkezli değil insan merkezli bir yapı olduğunu düşünüyorum
  Depoyu doğrudan kendi adıma bağlayıp hızlıca bir şeyler oluşturabilmek, SourceForge'da proje adı belirleyip rezerve ederek CVS ya da SVN deposu, web sitesi, posta listesi ve sorun takip sistemi kurmayı gerektiren ağır süreçten çok daha özgürleştiriciydi
  "Bu sadece kısa süreliğine yaptığım bir şey" hissinin yarattığı zihinsel yükü ciddi biçimde azalttı
  GitHub da aslında sorun takip sistemi, PR, sürüm sayfaları, wiki, organizasyon sayfaları, API, webhook ve CI'ı tek seferde sunmadı
  Eskiden organizasyon özelliği bile yoktu; bu yüzden yeni kullanıcı hesapları açıp organizasyon taklidi yapardık, "GitHub bunu birkaç ay içinde çıkarır herhalde" diyerek ayrı bir bug tracker kurmayı erteler, sonunda işleri depodaki metin dosyalarıyla yönettiğimiz bile olurdu
• Çoğu projede Git'in Fossil'e galip gelmiş olmasına hâlâ üzülüyorum
  Linux çekirdeği gibi aşırı büyük kod tabanlarında Git'in performans avantajı olabilir ama projelerin büyük çoğunluğu neredeyse hiçbir zaman bir VCS'nin performans sınırına dayanmaz
  Fossil'de wiki, forum ve ticket gibi yerleşik araçların kodla birlikte tek bir dosyada sürüm kontrolüne tabi olması gerçekten çok kullanışlı
  Serbest çalışmalarda Fossil sayesinde proje bağlamını, ayrıntıları ve müşteriyle yapılan anlaşmaları yeniden kavramak çok kolay oluyor
  Kod tabanını kirletmeye ya da bağlamı yeniden kurmak için e-postalarla not araçlarını didik didik etmeye gerek kalmıyor
  Git kültürel olarak fazla derine yerleşti diye bunun değiştirilemeyeceğini düşünülmesinden de hoşlanmıyorum
  Fossil'e geçmek kolay ve Git'ten geçince iş akışı hatta daha da basit oluyor
  • Git protokolü ve depoları temel alınarak da benzer araçlar yapılabilirdi; nitekim dağıtık kod inceleme gibi şeyler de vardı
    Ama çoğunluk bunları istemedi, bu yüzden güç kazanamadılar
    Sorunları projeyle birlikte saklamanın problemli olduğu epey çok durum da var
    Müşteriler hata üretimi için çok sayıda ekran görüntüsü ya da video dosyası gönderdiğinde depo hızla şişiyor; bunları kodla birlikte tutarsanız herkesin ticket'lara yerelde bakabilmek için bu şişkin depoyu indirmesi gerekiyor ve bu çok zahmetli oluyor
    Sonunda da kolayca "bunu kullanmayalım, çok karmaşık ve sadece depoyu büyütüyor" noktasına varılıyor
    Fossil'in özelliklerinin çoğu Git backend'i üzerinde de uygulanabilir görünüyor; wiki ve sorunlar da ayrı paralel branch katmanları olarak tutulabilir gibi
  • Sanırım zamanlama da etkiliydi
    Hatırladığım kadarıyla Git zaten kararlı ve günlük kullanım için yeterince uygun hâle gelmişken, Fossil'de sürüm güncellemesi sırasında tüm depoyu baştan oluşturmak gereken durumlar olabiliyordu
    Git'in UX'i daha kötüydü, hatta bugün bile öyle olabilir ama sonuçta çalışıyordu ve gerçek işlerde kullanılabilecek hissini daha güçlü veriyordu
    Üstelik dünyanın en büyük açık kaynak projelerinden biri tarafından kullanılıyordu; algı açısından farkı belirleyen de buydu
  • Şu an tam da birinin fossilhub.com'u satın alıp yeni bir topluluk kurması için doğru zaman gibi geliyor
  • Büyük depolarda Git'in neden daha hızlı olduğunu merak ediyorum
    Yine de bir süre boyunca büyük blob'ların işlenmesinde bu avantajın pek görünmediğini hatırlıyorum
• GitHub'ın bir arşiv işlevi görmesinin aslında kötü olduğunu düşünüyorum
  Zamanın %99'unda kullanışlı bir merkezi hizmet olduğunda, topluluğun bütün olarak koruma yeteneği köreliyor
  Bir şeyi canlı tutmak için birilerinin gerçekten seed etmesi gereken bir yapı olsaydı, insanlar gerçekten önem verdikleri şeylerin kopyalarını daha iyi saklıyor olurdu
  "Sonra tekrar checkout ederim" diye rahatça varsayabilmek bence asıl sorun
  Bir şeyleri indirebileceğiniz tek bir yer olmamalı
  Bir GitHub projesi DMCA yediğinde fork'ları da onunla birlikte yok olabiliyor
  Nintendo 2024'te popüler bir Switch emülatörünü kaldırtınca da koruma ve devam ettirme ancak birinin en güncel revizyonu checkout etmiş olmasını bulup onun üzerinden ilerleyerek mümkün oldu
  Bunun bile mümkün olabilmesi, o projenin zaten çok popüler olmasındandı: https://news.ycombinator.com/item?id=40254602
  Bu arada, bu sitenin Splatoon havası veren header/footer animasyonu gerçekten çok güzel
  Rahatsız etmiyor, atmosferi güçlendiriyor ve scroll yapınca hemen kenara çekiliyor; ben de bunu aynen çalmak istiyorum
  • Bu yüzden bir şey GitHub'da değilse yokmuş gibi hissedilen bir hava da oluştu
    Kodun başka yerlerde de barınabileceğini bilmeyen geliştirici sayısı bence fazla
  • Arşivleme kendi başına kolay ama telif hakkı ve fikri mülkiyet hukuku engel oluyor
    Bilgiyi erişilebilir kılmanın önündeki engeller azalsa, güç yoğunlaşması da daha düşük olurdu
  • Buna katılmıyorum
    GitHub'ın yıllar içinde güven kazanmasının nedenlerinden biri, bu arşiv rolünü şimdiye kadar doğrudan gelir modeline dönüştürmemiş olması
    Tabii Copilot'la ilgili yeni özelliklere bakınca ileride ne olur bilinmez
    Alternatif birden fazla siteye bölünmekse, o zaman da sadece farklı farklı DMCA kurallarıyla uğraşırsınız
    Bundan daha iyi alternatifin tam olarak ne olduğunu tekrar sormak gerekiyor
• Böyle yazılar okuyunca katkıda bulunduğum projelerin yolculuğunu düşünüyorum
  Açık kaynak çalışmalarımın çoğu self-hosted altyapı üzerinde yapıldı; bunun başlıca örneği de Xfce
  2004'te ilk katıldığımda sanırım bir SVN sunucusu ve muhtemelen CVSweb'in yeni SVN destekli web arayüzü vardı
  Çekirdek ekibe girdikten sonra Bugzilla'yı ben kurmuş da olabilirim ama başka biri de olabilir
  Git yaygınlaşmaya başladığında büyük SVN deposunu birden çok Git deposuna taşımaya öncülük ettim ve cgit web arayüzünü de ekledim
  O zamana kadar hâlâ Bugzilla kullanılıyordu
  2009-2010 civarında küçük bir startup'a geçince OSS için ayırabildiğim zaman azaldı ve projeden ayrıldım; 2022'de geri döndüğümde bu arada bir GitLab instance'ı ve CI runner'ları kurulmuş, Bugzilla da GitLab issue'larına taşınmıştı
  Hâlâ aktif kişi sayısı bir avuç ve altyapı yönetimi de neredeyse tek kişinin omzunda ama küçük bir ekip için gayet yürütülebilir
  Altyapının sponsorlukla sağlanıyor olması büyük şans; gerekirse düzenli bağışlarla masraflar doğrudan karşılanabilecek gibi de görünüyor
  En önemlisi, GitHub/Microsoft'a bağımlı olmamak gerçekten çok güzel
  20 yıl önce biri Microsoft'un dünyanın en büyük OSS kod forge'unu satın alacağını söyleseydi kusacak gibi olurdum; bugün de bu hâlâ rahatsız edici geliyor
• Sık gözden kaçıyor ama ortak giriş sistemi de gerçekten çok önemliydi
  Rust, crater adlı araçla bilinen Rust projelerinin tamamını testten geçiriyor; Cargo'nun iç uygulamasına bağımlı projeleri bulup yüzlerce sorunu tek tek açarken sürtünmesi düşük bir akış büyük fayda sağladı
  Sitenin kimlik bilgilerine zaten sahip olmak ve boş şablonlara da izin verilmesi, 200 issue açmayı çok daha kolay hâle getiriyor
  Tersine, bir self-hosted instance'a denk gelince çoğu zaman orada vazgeçiyorum
• SourceForge ortaya çıkmadan önce bile Planet Source Code'a yazı gönderiyordum
• Ben Trac'i gerçekten çok severdim
  Yeni bir açık kaynak proje başlatırken ilk adım olarak Trac kurmak inanılmaz derecede sürtünmeli bir işti ama yine de güzeldi
  Django hâlâ 20 yılı aşkın süredir Trac üzerinde çalışıyor: https://code.djangoproject.com/timeline
  Onu ben kurmadım ama daha önce kullanılan özel bir Trac'ın ayağa kaldırılmasına yardım etmiş olabilirim
  • Trac gerçekten çok iyiydi
    Ama benim ilk issue tracker'ım Bugzilla'ydı; kurulumu epey sancılıydı ve diğer araçlarla entegrasyonu da iyi değildi
    Yine de Zarro Boogs görmek başlı başına ayrı bir keyifti
  • Trac birçok açıdan dağıtım uygulamalarını PHP yerine Python ile yazmaya başlamama neden oldu
    Eklenti sistemi gerçekten harikaydı
  • Ben Bitbucket'ı severdim
    Ne yapması gerekiyorsa onu iyi yapıyordu, benim için özellikle bozulduğu da olmadı; ayrıca Mercurial tarafı bana daha çok hitap ediyordu
    Şirketler GitHub kullandığı için ben de geçtim ama bugün bile GitHub'ı sadece kaba bir Git endpoint'i gibi kullanıyor, build/deploy işlerini Docker ve shell script'lerle yaptığım için geçiş maliyetim çok düşük kalıyor
    İş tarafında da karar verici ben değilsem, SVN dönemindeki gibi ücretini ödeyip kullanılan aracı kullanmanın yeterli olduğunu düşünüyorum
  • İlginç şekilde o zamanlar Trac'ten nefret ederdim ama şimdi iyi anılarla hatırlıyorum
    Her şeyi biraz yapmaya çalışıp hiçbir şeyi mükemmel yapamadığını düşünürdüm
    Sanırım bugün o rolü GitLab aldı; ileride onu da muhtemelen iyi hatırlayacağız
• Kod arşiv hizmetlerini merak edip baktığımda birkaç tane gördüm
  GitHub'ın kendi programı da var: https://archiveprogram.github.com/
  UNESCO destekli kâr amacı gütmeyen Software Heritage da var: https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/
  Ama burası daha çok kodu ve commit geçmişini korumaya odaklı; issue, PR, tartışmalar ve wiki gibi çevresel metadata'yı pek ele almıyor
• Sanırım Flask'ı neredeyse en başında kullananlardan biriydim
  Ücretsiz ve kullanımı kolay modern bir hosting seçeneği olan AppEngine'den yararlanmak için Python öğrendim; bu sayede Flask çıktığında tam doğru yerdeydim
  Armin'e uzun zamandır hayrandım; bağlantıya tıklamadan önce bile alan adını görür görmez tanıdım
  O dönemde varsayılan seçeneğin GitHub olmadığına dair söylediklerine de katılıyorum
  Bu yazının birkaç saat önceki Mitchell yazısına bir yanıt olması da etkileyici; bu kadar hızlı şekilde uzun, iyi yapılandırılmış ve yüksek kaliteli bir metin yazmış olması şaşırtıcı
• Bu bana code.google.com'u hatırlattı
  Google'ın böylesine büyük bir fırsatı kaçırmış olması hâlâ inanılmaz geliyor
  • Gerçekten nostaljik
    O hizmet kapanmadan önce ben o ekipteydim