GitHub Öncesi Açık Kaynak Dünyası
(lucumr.pocoo.org)- GitHub, açık kaynağın sosyal altyapısı haline gelmeden önce geliştiriciler projelerini kendi işlettikleri Trac, Subversion depoları, e-posta listeleri gibi altyapılar üzerinde yönetiyordu; bir bağımlılık eklemek de ciddi sürtünme ve dikkat gerektiriyordu
- GitHub, proje oluşturmayı, keşfetmeyi ve katkı yapmayı kökten kolaylaştırdı; issue tracker, pull request ve CI gibi bileşenleri standartlaştırırken açık kaynak için bir arşiv işlevi de gördü
- npm gibi paket ekosistemleriyle birleşince mikro bağımlılık patlaması ortaya çıktı; GitHub güven sisteminin temel eksenlerinden biri haline geldi, ancak bugün kararsızlık, ürün yönü karmaşası ve yapay zeka gürültüsü nedeniyle güven aşınıyor
- Ghostty de ayrılıyor; Strudel ve Tenacity gibi projelerin Codeberg'e taşınması yönünde hareketler görülüyor. Dağıtıklaşma özerkliği artırsa da issue, inceleme ve güvenlik duyuruları gibi sosyal bağlamın kaybolması riskini de taşıyor
- Son dönemde GitHub'ın merkeziliğinin zayıfladığına dair işaretlerle birlikte, hafızayı koruyup bağımlılığı azaltan kamusal arşivler daha da önemli hale geliyor. Açık kaynağın bir sonraki dönemi, hafızayı koruyup bağımlılığı azaltan bir yönde ilerlemeli
GitHub Öncesi Açık Kaynak Ortamı
- GitHub öncesinde güvenilebilecek proje sayısı sınırlıydı ve her projenin itibarı ile sürekliliği, bağımlılık seçimleriyle doğrudan bağlantılıydı
- Bağımlılık, sadece bir paket adı değil; projenin geçmişini, web sitesini, bakımcılarını, sürüm sürecini ve topluluk bağlamını da beraberinde getiriyordu
- Büyük projeler çoğu zaman kendi altyapılarını işletiyordu; küçük projeler ise bazen üniversite sunucularında ya da SourceForge üzerinde yer alıyordu
- Debian paketleme sürecinde olduğu gibi lisansların ve telif hakkı başlıklarının bile incelendiği bir sürtünme vardı ve bu sürtünme de güven değerlendirmesinin parçası olarak işliyordu
Kendi Altyapısını İşletmek ve Dağıtık Sürüm Kontrolünün Paradoksu
- İlk dönem açık kaynak projelerinde Trac, Subversion, tarball ve dokümantasyon doğrudan kendilerinin işlettiği sunucularda barındırılıyordu; bu oldukça yaygındı
- Pocoo gibi örneklerde birden çok proje, sunucu maliyetini ve Subversion, Trac, e-posta listesi işletme yükünü birlikte paylaşıyordu
- Subversion, merkezi bir depo yapısına sahipti; bu yüzden sunucu işletmek doğal olarak işin parçasıydı ve bir projenin evi, ana makine adı, dizin, Trac örneği ve e-posta listesi arşivi gibi öğelerle fiziksel olarak belirgindi
- Mercurial ve Git, herkesin tüm depoya, dallara ve geçmişe sahip olabildiği dağıtık sistemlerdi; ama pratikte merkez yeniden GitHub etrafında toplandı
- Dağıtık sürüm kontrol sistemleri kazandıktan sonra dünyanın tek bir dev merkezi hizmet üzerinde standartlaşmış olması, 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ştirici e-posta listesi deneyimi olmayan insanların bile katkı akışını anlamasını kolaylaştırdı
- Issue tracker, pull request, sürüm sayfaları, wiki, organization sayfaları, API, webhook ve sonrasında CI sağlayarak kamusal iş birliğinin varsayılanlarını değiştirdi
- Açık kaynak iş birliği, görülebilen geçmiş ve görülebilen tartışmalar üzerinden yürüyen bir biçim olarak yaygınlaştı
- Uzun süre GitHub, açık kaynak projelerini barındırmak için son derece makul varsayılan seçenek olarak işlev gördü
- ABD yaptırımı altındaki ülkelerde bile GitHub erişimini korumaya çalışan politika örneğinde olduğu gibi, merkezileşme basit barındırmanın ötesinde erişilebilir ortak bir temel işlevi de gördü
Arşiv Olarak GitHub
- GitHub'ın daha az dikkat çeken işlevlerinden biri arşiv rolüydü; terk edilmiş projeler bile aranabilir biçimde kalıyor, yazılım ortak varlıklarının dizini gibi çalışıyordu
- Fork'lar, eski issue'lar ve tartışma kayıtları kalmaya devam ettikçe merkezileşme keşfedilebilir bir hafıza oluşturuyordu
- Buna karşılık büyük platformlar öncesinde kişisel alan adlarının süresinin dolması, VPS'lerin kapanması ya da geliştiricilerin ortadan kaybolmasıyla proje dosyalarının ve hizmetlerinin yok olması yaygındı
- PyPI'da yalnızca metadata'sı kalıp gerçek paketi kaybolan ilk dönem projeler örneğinde olduğu gibi, depo adreslerinin eski kişisel sunuculara işaret edip sonra kırıldığı durumlar yaşanıyordu
- Geçmişte birçok proje sonunda Internet Archive gibi dış koruma araçlarına büyük ölçüde bağımlı hale geldi
npm ve Bağımlılık Patlaması
- Micro dependency sorunu, sadece küçük paketlerin artmasından ibaret değildi; GitHub ve npm'in oluşturma, dağıtma, arama, kurma ve bağımlılık maliyetini neredeyse yokmuş gibi göstermesiyle daha da büyüdü
- GitHub öncesinde güven ve süreklilik, bağımlılık seçiminde zorunlu unsurlardı; başka hizmetlerin erişilebilirliğine güvenmek zor olduğundan kodu doğrudan depoya dahil etmek anlamındaki vendoring de yaygındı
- API öncesi dönemde dış kodu getiren betikleri sürdürmek de zahmetliydi; bu sürtünme, bağımlılık eklemeden önce insanı bir kez daha düşündürüyordu
- npm tarzı ekosistemlerde paket grafiği, insanların akıl yürütebileceği hızdan daha hızlı büyüyebiliyor
- GitHub, lisans durumunun belirsizleşmesi sorununa yanıt olarak hizmet şartlarını revize etmeyi de denedi
- Küçük bir pakete bağımlı olunsa bile, deponun varlığı, bakımcının mevcut olup olmadığı, issue'lar, son değişiklikler, başka projelerde kullanımı ve kod ile paket açıklamasının uyumu gibi unsurları GitHub üzerinden kontrol etme kültürü yerleşti
- GitHub, npm gibi kayıtlar için trusted publishing sağlayan az sayıdaki sistemden biri haline geldi; GitHub'a duyulan güvenin zayıflaması yalnızca kaynak kodu barındırmayı değil, tedarik zinciri kültürünün tamamını da etkiliyor
GitHub'ın Zayıflaması ve Taşınma İşaretleri
- GitHub son dönemde kararsızlık, tekrarlanan ürün değişiklikleri, Copilot AI gürültüsü ve belirsiz liderlik nedeniyle geçmişteki kaçınılmazlığının bir kısmını kaybediyor
- Agentic coding akımının tam ortasında yer aldığı için iç baskılar da arttı; ancak şu anda durum, liderlik eksikliğinin güçlü biçimde hissedildiği bir tablo olarak betimleniyor
- Bir dönem GitHub'dan ayrılış daha çok sembolik bir hareketti; şimdi ise etkisi büyük projeler bile taşınmayı açıkça değerlendiriyor ya da uyguluyor
- Ghostty'nin GitHub'dan ayrılacağını duyurması, varış noktası henüz net olmasa bile güçlü bir sinyal olarak görülüyor
- Strudel moved to Codeberg
- Tenacity moved to Codeberg
- Bu henüz büyük bir yön değişimi yaratacak ölçekte olmayabilir; yine de 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 en başta birden fazla evi varsayacak şekilde tasarlandığından, tek bir şirketin her şeyin varsayılan evi olduğu durumu sona erdirmek açık kaynak için sağlıklı olabilir
Dağıtıma Geri Dönüşün Maliyeti
- Birden çok forge, birden çok sunucu ve birden çok küçük topluluğa dönülürse merkezsizlik ve özerklik artabilir; Microsoft'taki liderlik değişikliklerine bağımlılık azalabilir
- Her topluluğun kendi iş akışını seçebilmesi de bir avantaj
- Pi'nin mevcut issue tracker sorunu, GitHub'ın ürün tercihinin bugün açık kaynak bakımının gerçekleriyle uyuşmayan sonuçlar doğurduğunu gösteriyor
- GitHub'ın, bakımcıların ruh sağlığından çok engagement odaklı tasarlandığı yönü de ortaya çıkıyor
- Öte yandan 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, incelemeler, tasarım tartışmaları, sürüm notları, güvenlik duyuruları ve eski tarball'lar sanılandan çok daha kolay kayboluyor
- Geçmişte bu bağlamı taşıyan e-posta listeleri, bugünün ihtiyaçlarını karşılayamadı; kullanıcı deneyimi de iyi değil
- Yazılımın unutulabilir olmasının arındırıcı bir etkisi olabilir; ama kayıp riski büyüdükçe dağıtık sürüm kontrol sistemlerini pratikte nasıl kullandığımızı yeniden düşünmek gerekiyor
Gereken Şey 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ını kazanmak için yarışan bir hizmete değil, önemli yazılımların ortadan kaybolmamasını sağlayacak bir yapıya ihtiyaç var
- Bu yapı, bir endowment ya da kamu fonu benzeri uzun vadede sürdürülebilir bir temel üzerinde çalışmalı
- Kaynak arşivleri, sürüm çıktıları, metadata ve proje bağlamı; tek bir şirketin iş modeline ya da liderliğinin ruh haline bağlı olmayan bir yerde korunmalı
- GitHub, açık kaynak faaliyetinin merkezi haline gelirken tesadüfen bu arşiv rolünü de üstlendi; ama merkeziliği zayıfladığında bu işlevin otomatik olarak süreceği varsayılamaz
- Kişisel sunucular ve iyi niyet tek başına koruma için yeterli olmadı; Google Code ve Bitbucket örneklerinde de platformlar kapandıktan sonra oluşan boşluk zaten görüldü
- Gelecekteki sistemler hafızayı koruyup bağımlılığı azaltan bir yöne gitmeli; projeleri taşımak, sosyal bağlamı mirror etmek ve sürümleri korumak kolaylaşmalı, tek bir şirketin savrulmasının herkes için kültürel bir krize dönüşmesi zorlaşmalı
- Kırık tarball bağlantılarına ve terk edilmiş Trac örneklerine geri dönmek istemiyoruz; ama son 20 yılın GitHub merkezli yapısını da kalıcı normal durum olarak kabul edemeyiz. Geriye bu gerilim kalıyor
3 yorum
GitHub'ın şimdiye kadar büyük bir rol oynadığı doğru, ancak benim hatırladığıma göre ondan önce açık kaynak projeleri yalnızca bu işle uğraşanların yaptığı şeylerdi ve bireylerin kamuya açık şekilde paylaşım yapması çok yaygın değildi. Hatta şirket içinde bile bazen yalnızca aynı ekipler arasında paylaşıldığı olurdu. Ayrıca açık kaynakta, büyük projelere katkı sunan biri olarak kabul edilmek başlı başına büyük bir onurdu; bireysel küçük projelerle ise ilgilenen pek kimse yoktu.
Geliştirici topluluğunun havası değişti, açık yazılım ortaya koyup bunu kendi yetkinliğini kabul ettirmenin bir aracı olarak kullanma anlayışı yaygınlaştı ve sonunda birkaç DVCS arasından git'in daha geniş kullanılmaya başlaması gibi çeşitli şanslı gelişmeler de buna eşlik etti diye hatırlıyorum. Rakipleri de benzer hizmetler sunuyordu; bence mesele GitHub'ın özellikle olağanüstü iyi olması değildi.
Aslında sorun issue, PR ve tartışmalar;
git’in kendisi ise her zaman başka bir hizmete taşınabilir.gitiçine bu üçünü de ekleyen projeler de vardı, öyle bir şey kullanılırsa istenildiği zaman taşınmak mümkün olur.Hacker News yorumları
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
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
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
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
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
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
Kodun başka yerlerde de barınabileceğini bilmeyen geliştirici sayısı bence fazla
Bilgiyi erişilebilir kılmanın önündeki engeller azalsa, güç yoğunlaşması da daha düşük olurdu
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
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
Rust,
crateradlı 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
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
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 Boogsgörmek başlı başına ayrı bir keyiftiEklenti sistemi gerçekten harikaydı
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
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
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
Ü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ı
Google'ın böylesine büyük bir fırsatı kaçırmış olması hâlâ inanılmaz geliyor
O hizmet kapanmadan önce ben o ekipteydim