GitHub’dan Ayrılıp Forgejo’ya Geçmek
(jorijn.com)- GitHub’dan ayrılmanın doğrudan tetikleyicisi 2026 Nisan’ındaki kesinti değil, GitHub üzerinde çalışan kod ve iş akışlarının mülkiyeti meselesi
- GitHub, 2025 Ağustos’tan sonra kendi CEO’su olmadan Microsoft CoreAI division içine alındı ve kodlar Microsoft’un yapay zeka organizasyonunun altına yerleşti
- Copilot Free, Pro ve Pro+ için 2026 Nisan’ından itibaren etkileşim verileri varsayılan olarak eğitim verisi olarak kullanılan, çıkışın kullanıcı tarafından kapatılması gereken bir yapıya geçti
- GitHub ve Microsoft ABD şirketleri olduğu için FISA 702 ve CLOUD Act yetki alanına giriyor; yalnızca AB veri yerleşikliği bunu çözmüyor
- Forgejo v15 LTS, code.jorijn.com’un tek bir NUC sunucusunda çalışıyor; runner ise KVM, gVisor, haftalık yeniden derleme ve egress filtresiyle izole ediliyor
GitHub’dan ayrılma nedeni kesinti değil, mülkiyet sorunu
- 2026 Nisan’ındaki kesinti geliştiriciler için yeterince ciddiydi, ancak GitHub’dan ayrılmanın temel nedeni kesintinin kendisi değil, GitHub üzerinde çalışan kod ve iş akışlarının mülkiyeti
- 27 Nisan 2026’da Hollanda İçişleri Bakanlığı, devlet kaynak kodları için kendi kendine barındırılan Forgejo örneği olan code.overheid.nl platformunu soft launch ile yayına aldı
- Proje yöneticisi Boris Van Hoytema, platformun bakanlıkların kaynak kodunu hukuken “sahip oldukları bir yerde” yayımlaması gerekliliğinden doğduğunu belirtti
- Forgejo, tamamen açık kaynak olması ve dijital egemenlik için gereken özgürlüğü sağlaması nedeniyle GitLab’a tercih edildi
- Kişisel kodlar için varsayılan Git barındırıcısı da code.jorijn.com adresine taşındı; burada Forgejo v15 LTS, tek bir NUC üzerinde sertleştirilmiş bir yapılandırmada çalışıyor
- Bazı depolar zaten taşındı, kalanlar ise beklemede
- Taşıma tamamlandıktan sonra herkese açık GitHub depolarını arşivleyip her arşivden yeni konumu işaret etme planı var
Kesintiler ve yapay zeka yükü
- 23 Nisan 2026’da merge queue’nun squash-merge kod yolu, özellik bayrağının eksik bir dağıtımının ardından 658 depo ve 2.092 pull request içinde zaten birleştirilmiş commit’leri sessizce geri aldı
- Modal ve Zipline dahil şirketler verileri elle kurtardı
- Dört gün sonra ise aşırı yüklenmiş bir Elasticsearch kümesi nedeniyle Pull Requests, Issues ve Packages 6 saatten fazla kesintiye uğradı
- Yalnızca 2026 Şubat ayında 37 olay kaydedildi; bunlar arasında Actions, Copilot Coding Agent, Code Review, CodeQL, Dependabot ve Pages’in aynı anda çöktüğü 3 saat 40 dakikalık kesinti de var
- 1 Ekim 2025’te 10 saatlik macOS runner kesintisi yaşandı
- IncidentHub verilerine göre GitHub, 2025 Mayıs ile 2026 Nisan arasında 257 olay ve 48 büyük kesinti yaşadı; toplam kesinti süresi yaklaşık 112 saat oldu
- GitHub CTO’su Vlad Fedorov, 28 Nisan’da özür dilerken, 2025 Aralık’tan sonraki “agentic AI workflow growth” kaynaklı yükü karşılamak için kapasitenin 30 kat artırılması gerektiğini söyledi
- Güvenilirlik sorunları, yapay zeka özelliklerinin genişlemesinin bir yan sonucu olarak yorumlanıyor
- GitHub, yapay zeka özelliklerini yavaşlatmak yerine daha da güçlü şekilde itiyor
- The Pragmatic Engineer, GitLab, Bitbucket, Vercel, Linear ve Sentry’nin aynı yılı böyle geçirmediğine dikkat çekiyor
- Bunlar da geliştirici talebi baskısı altında olduğundan, GitHub’daki kesinti örüntüsü GitHub’a özgü bir sorun gibi görünüyor
GitHub’daki organizasyonel değişim
- 11 Ağustos 2025’te Thomas Dohmke GitHub CEO’luğundan ayrıldı ve Microsoft yerine yeni bir CEO atamadı
- GitHub, Microsoft’un CoreAI division’ına dahil edildi
- CoreAI, Satya Nadella’nın 2025 Ocak’ta tanıttığı ve 1st-party ile 3rd-party müşteriler için uçtan uca Copilot ve AI stack oluşturmayı hedefleyen organizasyon
- GitHub’ın gelir, mühendislik ve destek ekipleri Julia Liuson altındaki Microsoft developer division’a raporluyor
- GitHub CPO’su ise Microsoft AI platform VP’sine raporluyor
- Marka kalıyor ama bağımsız liderlik ortadan kalkmış durumda
- 2018’den 2024’e kadar Microsoft’un GitHub’ı belli ölçüde mesafeli yönettiği değerlendirmesi pratikte doğruydu; ancak 2025 Ağustos’tan sonra bu varsayımı sürdürmek zorlaştı
- Artık github.com’a kod push etmek, Microsoft’un yapay zeka organizasyonu altındaki bir birime kod push etmek anlamına geliyor
Copilot eğitim verisi varsayılanının değişmesi
- GitHub, 25 Mart 2026’da 24 Nisan’da yürürlüğe girecek gizlilik politikası değişikliğini duyurdu
- Copilot Free, Pro ve Pro+ kullanıcılarının etkileşim verileri; özellikle girdiler, çıktılar, kod parçaları ve ilgili bağlam, kullanıcı açıkça reddetmediği sürece AI modellerinin eğitimi ve iyileştirilmesinde kullanılıyor
- Temel değişiklik bunun opt-in değil, opt-out olması
- Copilot Free, Pro ve Pro+ kullanıcıları Copilot ayarları sayfasından bunu kapatmazsa model eğitimine katkıda bulunmuş oluyor
- Depo düzeyinde engelleme yok
- Yöneticiler GitHub’a belirli bir depo içindeki etkileşimlerin eğitime dahil edilmemesini belirtemiyor
- Opt-out, kullanıcı hesabı bazında bir ayar olduğu için her katkı sağlayanın bunu kendisinin seçmesi gerekiyor
- Sonuç olarak Copilot Free/Pro/Pro+ kullanan biri bir depoyla çalıştığında, lisansından bağımsız olarak kod tabanı eğitim malzemesine dönüşebiliyor
- Özel depo istisnası da dar uygulanıyor
- GitHub, özel depoların “at rest” durumundaki içeriğini eğitim için kullanmadığını söylüyor
- Ancak özel depolarda Copilot kullanımı sırasında oluşan “code snippets and interaction context” verilerini topluyor
- “Durağan durumdaki kod” ile “düzenleme sırasında oluşan parçalar” arasındaki sınır belirsiz
- Copilot Business ve Copilot Enterprise müşterileri, ayrı Data Protection Agreements kapsamında oldukları için bunun dışında tutuluyor
- Yani yeterince para öderseniz etkileşimleriniz eğitim verisi sayılmıyor; ödemezseniz sayılıyor
- GitHub’ın kullanıcı etkileşim verilerine yönelik stratejik ilgisi artık isteğe bağlı bir unsur değil, yapısal bir unsur haline gelmiş durumda
Yargı yetkisi riski veri konumuyla çözülmez
- GitHub Inc. ve Microsoft Corp. ABD şirketleridir ve bunların elindeki veriler, FISA Section 702 ve 2018 CLOUD Act dahil olmak üzere ABD yasalarının kapsamına girer
- Bu iki yasa, verinin fiziksel olarak nerede bulunduğuna bakılmaksızın uygulanabilir
- Section 702, Nisan 2024’te iki yıllığına yeniden yetkilendirildi ve Nisan 2026 sonunda imzalanan 45 günlük uzatma ile yürürlükte kalmayı sürdürüyor
- ABD’de bulunan elektronik iletişim hizmeti sağlayıcıları üzerinden ABD istihbarat kurumlarının ABD vatandaşı olmayan kişilere yönelik veri toplamasına izin verir
- CLOUD Act, merkezi ABD’de bulunan şirketleri, veriler dünyanın neresinde saklanıyor olursa olsun bunları teslim etmeye zorlayabilir
- GitHub, Ekim 2024’te Enterprise Cloud için AB veri yerleşikliği genel kullanıma sunuldu duyurusunu yaptı
- Bu, veri konumu sorununu ele alır ancak yargı yetkisi sorununu çözmez
- CLOUD Act kapsamındaki maruziyet coğrafi konuma değil, kurumsal kontrol yapısına bağlıdır
- Microsoft tarafının avukatı, Haziran 2025’te Fransız Senatosu oturumunda yemin altında, Avrupa’daki Microsoft veri merkezlerinde saklanan Fransız verilerinin ABD hükümetinin sessiz erişimine karşı güvende olduğunu garanti edemeyeceğini söyledi
- Kod github.com üzerinde olduğu sürece, o kod ABD’nin hukuki alanı içindedir
- AB veri yerleşikliği iç rahatlatıcı olabilir, ancak bir çözüm değildir
Hollanda hükümetinin code.overheid.nl tercihi
- Hollanda hükümetinin bu tercihinin hukuki arka planı, 2020’den beri yürürlükte olan “Open, tenzij” politikasıdır
- Kamu fonuyla geliştirilen yazılımlar, güvenlik veya gizlilik gerektirmediği sürece varsayılan olarak açık kaynak olur
- Buna uymak için bakanlıkların, gerçekten kendi kontrollerinde olan bir yerde kod yayımlayabilecekleri bir alana ihtiyaç vardı
- Avrupa Komisyonu, Eylül 2022’den bu yana kendi barındırdığı GitLab tabanlı code.europa.eu platformunu işletiyor
- Almanya’nın openCode platformu da GitLab tabanlı
- Fransa’nın code.gouv.fr platformu, kendi forge’unu çalıştırmak yerine başka yerlerde barındırılan depoları indeksleyen bir toplayıcı
- Hollanda hükümeti bilinçli olarak GitLab yerine Forgejo’yu seçti
- OSOR’a göre bunun nedeni, Forgejo’nun tamamen açık kaynak olması, open-core ayrımı içermemesi ve dijital özerklik için gereken tüm özgürlükleri sunmasıydı
- Van Hoytema ayrıca Forgejo yol haritasının alternatiflere kıyasla “way more aligned” olduğunu ekledi
- Hollanda hükümeti yalnızca egemen bir forge değil, ticari bir satıcının premium katmanlarının arkasına kilitlenmeyen egemen bir forge istiyordu
- Hükümetler de aynı sorun çerçevesini görüp aynı kararı verdi ve Forgejo tercihini artık marjinal bir seçim olarak görmek zorlaştı
Neden Forgejo seçildi
- GitLab da ciddi biçimde değerlendirildi
- Kendi barındırılan GitLab CE iyi bilinen bir seçenek ve daha büyük bir ticari ekosistem ile daha rafine bir kullanıcı arayüzüne sahip
-
Lisans
- GitLab, open core modelini kullanıyor
- Community Edition MIT lisanslı, ancak üretim ortamında istenen birçok özellik özgür olmayan lisanslı Enterprise katmanında yer alıyor
- Forgejo ise ters yönde ilerliyor
- Ağustos 2024’te v9.0 ile MIT’den GPLv3+ lisansına yeniden geçti
- Açık hedef, copyleft’i korumak ve kod tabanının gelecekte ticari olarak ele geçirilmesini engellemekti
- Forgejo’nun Aralık 2022’de Gitea’dan fork edilmesinin nedeni de, Gitea Ltd’nin topluluğun onayı olmadan marka ve alan adını kontrol etmesiydi
- Bu ders lisans tercihine de yansıdı
- GitLab, open core modelini kullanıyor
-
Yönetişim
- Forgejo, Codeberg e.V. çatısı altında yer alıyor
- Codeberg e.V., Eylül 2018’den beri Berlin’de kayıtlı bir kâr amacı gütmeyen kuruluş
- Üyeler tarafından seçilen bir yönetim kurulu, açık bütçe ve barındırılan örnekte 300.000’den fazla depo bulunuyor
- Üyeler her yıl bütçeye oy veriyor
- 2025 planı 88 evet, 0 hayır ve 1 çekimser oyla onaylandı
- Forgejo, Codeberg e.V. çatısı altında yer alıyor
-
Sürümler ve olgunluk
- Forgejo v15.0 LTS, 16 Nisan 2026’da yayımlandı
- Bu, projenin 100. sürümüydü
- Uzun süreli destek 15 Temmuz 2027’ye kadar sürecek
- Forgejo Actions, v15 ile gerekli seviyeye ulaştı
- ephemeral runner, OpenID Connect ve reusable workflow expansion içeriyor
- Fork sonrasında sürümler düzenli geldi ve aylık raporlar da aktif kaldı
- Forgejo v15.0 LTS, 16 Nisan 2026’da yayımlandı
-
Ticari ekosistemin sınırları
- Forgejo’nun ticari ekosistemi var, ancak zayıf
- Şu anda en derli toplu ticari ürün VSHN tarafından sunulan Codey
- Mart 2025’te Servala’da kullanıma sunulan, İsviçre’de barındırılan yönetimli bir Forgejo hizmeti
- Aylık 19 CHF’den başlıyor
- Red Hat tarzı bir kurumsal destek aboneliği yok
- 7/24 telefon desteği ve sorumluluk alacak bir satıcı gerekiyorsa bunu kendiniz kurmanız ya da beklemeniz gerekir
code.jorijn.com kurulumu
- code.jorijn.com, ev ofisteki tek bir Intel NUC üzerinde çalışıyor
- RAM miktarı 64GB
- Forgejo v15 LTS, Postgres 17 ve Traefik, Docker içinde çalışıyor
- Incus tarafından yönetilen bir KVM sanal makinesi, yanında Forgejo Actions runner’ı çalıştırıyor
- Forgejo, Postgres ve reverse proxy yerleşiminden daha önemli karar, runner yapılandırması
En riskli bölüm runner
- Kendi barındırılan bir forge’da, asıl kolay kısım forge’un kendisi; zor olan kısım CI işlerini çalıştıran ortam
- Runner, her gün Renovate zamanlamasına göre
npm install,composer install,pip installçalıştırmak zorunda- Hedef, kendi depolarında üretilmiş lockfile’lar
- Bu da lifecycle script’lerin çalıştırılması anlamına geliyor
- Her iş potansiyel olarak güvenilmez kod çalıştırabilir
- Bu, yakın zamanda npm worm ve axios tedarik zinciri saldırısında olduğu gibi, bir saat içinde otomatik birleştirme yapan dependency bot’lar üzerinden yayılan riskle aynı
- Runner’ın görevi kod çalıştırmak değil, çalışan kodu izole etmek
- Tek bir savunma katmanının başarısız olabileceği varsayılır ve bir sonraki katman bu başarısızlığı soğuracak şekilde tasarlanır
runner savunma katmanları
-
Kalıcı KVM sanal makinesi
- runner, host üzerindeki bir container’da değil, ayrı bir KVM VM içinde bulunur
- iş ortamı host çekirdeğini paylaşmaz
- runner içindeki Linux çekirdeği CVE’sinin NUC’a ulaşabilmesi için önce KVM sınırını aşması gerekir
-
VM içinde varsayılan Docker runtime olarak gVisor kullanımı
- iş container’ları
runscaltında çalışır runsc, sistem çağrılarını doğrudan host çekirdeğine iletmek yerine kullanıcı alanında yakalar- container’dan kaçış için hem gVisor’ın hem de onu çevreleyen KVM’in aşılması gerekir
- iş container’ları
-
Haftalık yıkıcı yeniden oluşturma
- her pazartesi 02:00 UTC’de tüm VM silinir ve yeni bir Ubuntu base image’dan yeniden oluşturulur
- Forgejo’ya yönelik yeni kalıcı runner kaydı da yeniden verilir
- base image pazar günü yeniden oluşturulduğu için yeni VM, o haftanın apt ve çekirdek yamalarını içerir
- kalıcı durum 7 günden daha uzun süre kalamaz
-
runner bridge için nftables çıkış filtresi
- runner, herkese açık hedeflerin
:443,:80,:22,:53portlarına erişebilir- npm, pypi, ghcr ve hairpin NAT üzerinden herkese açık hostname ile erişilen kendi Forgejo’su buna dahildir
192.168.0.0/16,10.0.0.0/8,172.16.0.0/12aralıklarına erişemez- ele geçirilmiş bir iş, LAN’ı tarayamaz veya router yönetim arayüzüne ya da host’taki diğer servislere erişemez
- runner, herkese açık hedeflerin
-
kapsamı sınırlı runner token’ları
- iki kalıcı runner kaydı sırasıyla tek kullanıcı kapsamına ve tek organizasyon kapsamına bağlıdır
- yönetim için
write:user,write:organizationPAT scope kullanılır - sızdırılmış token’lar kapsam dışına runner kaydedemez ve admin scope gerektiren işlemleri yapamaz
- katmanlar bilerek birbirini örtecek şekilde kurulmuştur
- her katman bir çittir ve birlikte derinlemesine bir sınır oluştururlar
- KVM isolation, gVisor, haftalık yeniden oluşturma ve scope’a bağlı runner kaydı; Forgejo ve Incus’un hazır olarak desteklediği unsurlardır
Vazgeçilenler
-
keşfedilebilirlik ve sosyal grafik
- GitHub, katkıda bulunanların depoları bulduğu yerdir
- herkese açık bir depoya küçük bir düzeltme göndermek isteyen kişiler, alışılmadık bir domain yerine github.com üzerinde çalışmayı bekler
- geçiş tamamlandığında her açık GitHub deposunu arşivleyip README’nin code.jorijn.com’u işaret etmesini planlıyorum
- keşif yolu korunur
- insanlar depoları yine GitHub’da bulur, arşiv yönlendirmesini görür ve ardından asıl adrese geçer
- bu henüz tamamlanmadı; bazı depolar code.jorijn.com’da, geri kalanı ise bekliyor
-
GitHub Actions ekosistemiyle kırılgan uyumluluk
- Forgejo Actions, uyumluluğu değil aşinalığı hedefler
- çoğu şey çalışır ama bazıları çalışmaz
- workflow düzeyindeki
permissions:bloğu sessizce yok sayılır actions/checkout@v6, 2026 başında GitHub dışı runner’larda authenticated checkout’u bozduğu için v5’e sabitlenmiştiractions/upload-artifact@v4, Forgejo tarafından barındırılan bir fork gerektirir- OIDC çalışır, ancak GitHub’daki
permissions: id-token: writeyerineenable-openid-connect: trueadlı farklı bir workflow anahtarı kullanır - workflow’lar GitHub’a özgü özelliklere çok bağımlıysa geçiş, bir akşamda bitecek bir iş değil, başlı başına bir projedir
-
Dependabot’un yokluğu
- Forgejo’da Dependabot yoktur
- Renovate, aynı self-hosted runner üzerinde 3 saatte bir çalıştırılır
- aynı görevi yapar ama daha fazla ayar ister ve yapılandırması bir gün sürer
-
7/24 üretici desteği
- GitHub Enterprise bir telefon numarası ve SLA sağlar
- Forgejo bir issue tracker ve chat room sağlar
- bu, tek kişi tarafından işletim için yeterlidir ama 200 mühendisten oluşan bir organizasyon için yeterli olmayabilir
Ne zaman taşınmaya değmez
- ekipte altyapı işletme isteği ya da kapasitesi hiç yoksa self-hosted Forgejo’ya geçmemek daha iyidir
- yönetilen Forgejo hizmetleri olan Codey ya da FOSS için Codeberg bu farkın çoğunu kapatır, ancak geçiş maliyeti yine de kalır
- GitHub’a özgü özelliklere — GitHub Apps marketplace, Codespaces, Copilot Workspace, Advanced Security gibi — derin yatırım yapıldıysa uygun değildir
- Forgejo bir forge’dur; developer-platform-as-a-service değildir
- katkıcı tabanı GitHub’ın sosyal grafiğine dayanıyorsa keşfedilebilirlik, sahiplikten daha önemli olabilir
- katkıcıların bulunduğu yerde kalmak mümkündür; ya da sürtünmeyi kabul edip taşınma tamamlandıktan sonra herkese açık GitHub depolarını arşivleyerek yeni konumu işaret etmek ve daha sonra yeniden değerlendirmek mümkündür
- runner’lar için güvenilir bir operasyonel yanıt yoksa taşınmak zordur
- en ciddi şekilde ele alınması gereken alan burasıdır
- KVM isolation, gVisor, nftables ve haftalık yeniden oluşturma üzerine düşünmeye hazır değilseniz, CI işlerini yönetilen bir runner host’unda çalıştırmak ya da GitHub’da kalmak daha iyidir
- Hollanda hükümeti bile her şeyi bir anda taşımadı
- code.overheid.nl, bakanlıkların açık kaynak kod paylaşması için yapılan yumuşak lansmanlı bir platformdur; kullandıkları her şeyin tam kapsamlı bir ikamesi değildir
- code.jorijn.com kurulumu da aynı şekildedir
- Forgejo asıl host’tur, GitHub ise mirror’dur; mirror daha sonra yeniden değerlendirilebilir
1 yorum
Hacker News yorumları
Herkes GitHub'dan ayrılırken, sanki git'in asıl ruhunu unutuyor gibi görünüyor
git baştan beri merkeziyetsizlik amacıyla tasarlanmıştı; sorun, GitHub'ın daha temiz, daha iyi ölçeklenen ve daha iyi yönetilen bir yer olması nedeniyle git etrafındaki tüm araçların GitHub'da merkezileşmiş olması
Yine de GitHub'a otomatik senkronlanan bir mirror kalsa iyi olur. Çünkü yıllar boyunca projelerin self-hosting'e ya da niş hosting'lere geçtiğini, ardından GitHub mirror'larının bozulduğunu ya da silindiğini ve sonunda projenin zaman içinde kaybolduğunu gördüm
git merkeziyetsizdir ve GitHub sadece kod yüklenebilecek yerlerden biridir; birden fazla uzak sunucuya push yapılabilir
Bu yüzden artık oraya kişisel kodumu commit etmeyeceğim
Keşfedilebilirlik, yıldızlar, AI botlarının doldurduğu issue'lar gibi sosyal özelliklerle de ilgilenmiyorum. Mevcut hâli benim için yeterli
Ayrıca “Open Source is not about You” sözünü de hatırlamak gerek
Herkesin unuttuğu platformun en önemli yönü sosyal bileşen; kalıcı dış depolar oluşturmayı ve depolar arası işbirliğini çok kolaylaştırdı
Self-hosted forge'ları birbirine bağlamak için açık protokoller ve standartlar kullanıyor
Başta amaçlanan e-posta yama modeli ile kullanmayı deneyen insan çok az; geri kalanların çoğu muhtemelen bunu öğrenmeyi de düşünmüyor
İnsanlar temelde GitHub kullandığı için git kullanıyor ya da biraz daha cömert söylersek GitHub gibi merkezi host'larla birleşince iyi çalıştığı için kullanıyor
İnsanlar yerelde kod geliştirip web portalında issue ve patch tartışma modeline çekiliyor; bunda git'in kendisinin sunduğu kısım küçük
Issue'lar, release'ler, CI, dokümantasyon, güvenlik duyuruları, arama ve keşfedilebilirlik zamanla GitHub'a bağlanma eğilimi gösteriyor
Açık kaynak bir projeyse, self-hosting'i tek gerçek kaynak olarak tutup insanların gerçekten bulabilmesi için salt okunur bir GitHub mirror'ı korumak iyi bir yaklaşım bence
Oyunun kurallarını gerçekten değiştirecek şey, tamamlanmış federasyon desteği olur
Bu yüzden Forgejo'ya ve Codeberg'e bağış yapıyorum; Forgejo ekibinin bunu düzgün biçimde hayata geçirebilmesi için herkesin daha fazla zaman ve kaynak ayırmasını tavsiye ederim
Bir diğer iyi aday da Git üzerinde tamamen merkeziyetsiz olan Radicle
https://codeberg.org/forgejo-contrib/federation/src/branch/m...
https://liberapay.com/forgejo
https://donate.codeberg.org/
https://radicle.dev/
https://radicle.network/nodes/seed.radicle.dev
Ben de git depolarımı self-hosted bir NUC'a taşıdım
Dünyayla paylaşılacak bir HTTP frontend'i henüz eklemedim; çünkü AI scraper'larına içerik sunmak istemiyorum ve onları engellemekle de uğraşmak istemiyorum
Açık kaynaktan faydalanmış şirketlerin sektörü bu kadar kirletmiş olması utanç verici
3 yıldır çalışıyor. Yalnızca LAN'dan erişilecek şekilde kilitleyip internete açmadığınızda sağlam ve uzun ömürlü bir kullanım sunuyor
Depolar birkaç hafta boyunca düzgün mirror'lanıyor, sonra duruyor. Süresi dolmayan bir PAT token verdim ama yine de süresinin dolduğunu iddia ediyor; başka yerde test edince token normal çalışıyor
Bazen log'larda hiçbir şey olmuyor, bazen de veritabanı kilitlenmiş oluyor. Veritabanını kullanan tek şey Forgejo
Şimdiye kadar bunun Forgejo sorunu mu, Pi'nin berbat SD kart G/Ç'si yüzünden oluşan bir veritabanı kilidi mi, yoksa Forgejo'nun mirror rolünde başarısız olması mı olduğunu ayırt edemedim
Tekelci hyperscale bulut şirketleri bedava emek topluyor ve bununla takip-gözetim ağları, istediğiniz şeyi kuramadığınız telefonlar, cihaz doğrulaması ve reklam engellemesiz tarayıcı tek kültürü gibi nefret ettiğimiz dünyayı kuruyor
Google insanların BSD/MIT'i sevmesini sağladı; sonucu ortada
Tipik taktiklerden biri “artık bu bizim” yaklaşımı. Elasticsearch ya da Redis gibi bir şeyi bir üretici yarattığında, hyperscale bulut bunu kendi tekel ürününe çevirip tüm kârı alıyor; asıl yazar ve şirket ise aç kalıyor
Bir diğeri de “benimse, genişlet, yok et”. KHTML ya da Linux gibi açık kaynak projeleri alıp kendi sürümlerini yapıyorlar, pazara sürüp rakipleri eziyorlar, sonra rekabet karşıtı yöntemlerle kendi ürünlerini herkesin önüne koyuyorlar; payı alınca da izleme ekleyip özgürlüğü kaldırıyorlar
Açık kaynak yerine “insanlara özgürlük, şirketler para ödesin” modeli gelmeli. Hyperscale buluta karşı dişi olan, kaynak kodu açık shareware'e ihtiyacımız var
Richard Stallman'ın lisansları bile yeterince güçlü değil; bence CC BY-NC-SA daha iyi
“Saf” açık kaynak kurumsal refahtı ve bir hataydı. Devlerin bizi kendi ipimizle asmasına izin verdi
Ben AI'ın kodumu aktif biçimde okumasını isterim
Yazının “What I gave up” bölümünde yazar kendi sosyal grafiğinden söz etmiş; GitSocial kullanırsanız sosyal grafiğinizi ve işbirliği geçmişinizi de yanınızda götürebilirsiniz
Herhangi iki git host'u arasında forge'lar arası pull request'i mümkün kılıyor ve her şey üçüncü taraf bağımlılığı olmadan çalışıyor
Bu yüzden bu tür alternatifler bir türlü çıkış yapamıyor
“CTO kamuya açık biçimde özür diledi ve AI kaynaklı yükü kaldırabilmek için kapasiteyi 30 kat artırmaları gerektiğini söyledi” kısmını görünce, umarım GitHub normal kullanıma ücret koymaya başlamaz
Ama bazı vibe coder'ların günde binlerce commit ürettiğini görünce giderek daha şüpheci oluyorum
Kodu ücretsiz paylaşmak ve birlikte çalışmak mümkün olmazsa gerçekten üzücü olur
Tecrübeli biri bir deponun böyle bir sorunu olduğunu saniyeler içinde anlayabiliyorsa, ince ayarlı bir sistem de mümkün olmalı
Zor kısım, vibe kotası uygulanabilsin diye hukuki kullanım şartlarını yazmak
Anthropic bunu zaten CC'de yapıyor; GitHub ve GitLab da muhtemelen benzer şeyler yapıyordur. Bedeli Twitter geliştiricileriyle birkaç küçük subreddit'in nefretini çekmek olur ama buna değer gibi
Öte yandan /r/vibecoding gibi yerlerde insanların ayda 200 dolar abonelik ödeyip hobi projeleri ya da oyuncak sitelere yakın şeyler yapmasını sık sık görmek oldukça şaşırtıcı
Kaldırabildiğim dönemlerde ben de aptalca harcamalar yaptım ama bu biraz farklı hissettiriyor
Belki de bu, anlam ve amaç sunan bir hizmete yılda 2400 dolar ödemektir. 40'lı yaşlara gelip zengin ya da ünlü olamayacağını fark edersen, diğer seçeneklere kıyasla karşılanabilir bir bedel olabilir
Bluesky gibi AT Protocol üzerinde kurulu merkeziyetsiz bir hizmet olan Tangled'ı da duydum
GitHub'ın uygulamayı ağırdan alması yüzünden bu özelliği GitHub'a ekleyen şirketlerin bile ortaya çıktığı, pull request yığma gibi gerçekten faydalı özellikleri de var
Kullanan var mı merak ediyorum
https://tangled.org/
https://tangled.org/h14h.com/knot
Genel olarak platform oldukça umut verici görünüyor. AtProto'nun kişisel veri sunucusu, relay ve AppView'i ayırma biçimi yerinde bir orta yol gibi
git depolarını başsız, sadece veri amaçlı bir sunucu olarak barındırabildiğiniz için, self-hosting'e göre neredeyse zahmetsiz
Forgejo gibi ActivityPub çözümleriyle kıyaslayınca, benim önemsediğim şey veri kontrolü; tüm web uygulamasını host etme ve ölçekleme sıkıcılığından kaçınmak güzel
İlk kurulumdan sonra yaptığım tek bakım, knot-server sürümünü yükseltip yeniden deploy etmek oldu. tangled.org eski sürümse uyarı banner'ı gösteriyor
Tangled'ı başka projelerde daha fazla kullanmak ve özelliklerini denemek istiyorum. Özellikle jj ve stacked PR için yerel destek ilgimi çekiyor
Özel CI bağlamak için tack gibi ilginç deneyler de var
ATProto özel veriyi desteklemeye başladığında bir gün özel depoları da destekleyebilir, ama bu biraz zaman alabilir
https://tangled.org/mitchellh.com/tack
Hâlâ iş modeline dair bir şey söylenmedi, o yüzden neye dönüşeceğini gerçekten merak ediyorum
Onun yerine radicle.xyz kullanmak daha iyi
Fossil de değerlendirilebilir
Kod geçmişi, wiki, ticket ve forum dâhil deponun tüm durumunu tek bir dosyada topluyor ve bu durum çoğaltılıyor
Hosting sağlayıcısını değiştirmeniz gerektiğinde bile Fossil'de bu yüzden kaybolan veri olmuyor
https://fossil-scm.org/
Ama sorun ağ etkisi. Ekibi Fossil'e geçiremiyorum
Ekibin başka insanlarla, başka departmanlarla kod paylaşması gerekiyor ve herkes, yani fiilen %99'dan fazlası git kullanıyor
Fossil kullanmalarını dayatmak sanki zarar verici olurdu; tam bir açmaz
Teknolojideki pek çok başka şey gibi. Meslektaş geliştiricilere fonksiyonel stil deyimlerini kullandırmaya ya da değişmezliği zorlamaya çalışmak gibi
Sanki Facebook ya da Google projesi gibi büyük bir şeyin topluluğu zorla hareket ettirmesi gerekiyor
Ama felsefi olarak Fossil bana uymuyor. Geçmişi düzenlemenin bir yolu yok; her şeyi olduğu gibi koruyor
Eğer istediğiniz buysa güzel ama benim git iş akışımda, bir şeyleri denedikten sonra push etmeden önce commit'leri temizleyip düzenlemeyi seviyorum
İnsanlar sürekli merkeziyetsizlik diye bağırıyor
Ama gerçekte çoğu sistem sonunda merkezileşiyor
Belki de insanlar merkeziyetsizlik istediğini söylediğinde, aslında aradıkları şey kendilerinin yeni öncü olabileceği yeni bir merkezdir
Mevcut kurallarla kazanma şansları olmadığını hissediyorlarsa, merkeziyetsizliği gerekçe gösterip oyunu tersine çevirmeye çalışıyor gibi görünüyorlar
İnsanların bunu istemesinin nedeni, o tekil merkezi yönetimin şu ya da bu sebeple yetersiz kalması
İnsanların bunu dillendirmesi ile gerçekten istemesi arasında bir fark yok
Daha kötüsü, merkezi sistemler çoğu zaman harika çalışıyor; acı ise birleşme ya da ani fiyat artışı gibi kısa dönemlerde çok sert geliyor
Merkeziyetsizlik her zaman az da olsa can yakıyor, ama merkezi alternatif çöktüğünde yaşanan nadir anlarda büyük bir mutluluk veriyor
Normal dilde buna boykot denir. “Atıştırmalıklar Nestlé'de fazla merkezileşti, atıştırmalıkları merkeziyetsizleştirmeliyiz” demezsiniz
Tangled'a geçiyorum; AT Protocol üzerinde kurulu olduğu için Bluesky vb. ile aynı hesabı kullanıyor
Denediğim kadarıyla oldukça hoşuma gitti
https://vale.rocks/micros/20260511-0440
Bir yıl önce homelab'de self-hosted Gitea'ya geçtim ve herkese açık erişimi kapattım
HTTPS yok, kayıt olma kapalı ve depolar da herkese açık değil
Herkese açık bir instance kurup HTTPS kullanırken saldırı yüzeyini minimumda tutmalı mıyım diye düşünüyorum; özellikle Gitea/Forgejo için önerileri merak ediyorum
Yerel kayıt olmayı kapatmak önemli. Benim durumda authentik'i IdP olarak kullanıyorum ve ona sadece tailnet üzerinden erişilebiliyor. Ya da kendi hesabınızı oluşturup sonra kayıt olmayı kapatabilirsiniz
robots.txtile tek tek render edilen git commit görünümleri gibi bazı bölümleri engelledim. Yoksa scraper'lar sonsuz döngüye giriyorForgejo paket deposuna erişimi de sıkı şekilde engelledim; çünkü özel paketlerim var ve oradaki izin ayrıntı düzeyi henüz istediğim seviyede değil
Takip etmeye devam ediyorum ve şu ana kadar büyük bir sorun çıkmadı. Ayrıntılar docs.eblu.me'de var; isterseniz doğrudan altyapı koduna da bağlayabilirim
Eskiden iç instance'ı yansıtan, herkese açık salt okunur bir instance kurmuştum; içeriden dışarıya doğru tek bir reverse proxy bağlantısı vardı ve bu sayede dıştaki taraf git verisini çekebiliyordu
Sonrasında büyük ölçüde kendi kendine sorunsuz çalıştı; iç Forgejo'da bir şey değiştiğinde dış tarafta da güncelleniyordu
Issue'lar, CI vb. tamamen özel kalıp LAN içinde tutulabiliyordu
Hâlâ neden Gitea kullandığınızı merak ediyorum. Belki Forgejo yerine yeniden Gitea'yı denemeyi düşünmeliyim