Brüksel’deki bir oturumda, duvara yapıştırılmış renkli post-it’lerin arasında bir tanesi gözüme çarptı. Peki bunu neden söylüyorum? Üzerinde şunu yazıyordu: “Yapay zekâ kod yazmakta ustalaştıkça, kodun etrafındaki insan emeği daha önemli, ama daha görünmez hâle geliyor.”
Bu cümle kafama takıldı. Hâlâ da takılıyor.
Görünmeyen İşin Değeri: Bir Maintainer Ne Yapar?
Hani, Açık konuşayım, açık kaynak tarafında çoğumuz “bu işi kim ayakta tutuyor” diye pek durup bakmıyoruz. Bir kütüphane çalışır, biz de kullanırız; olay kapanır gıbı gelir. Ama perde arkasında PR review yapan, yeni gelen katkıcılara yol gösteren, projenin yönünü az çok çizen insanlar var. İşte onlara maintainer diyoruz.
GitHub’ın paylaştığı rakamlara göre, merge edilen pull request sayısı yıldan yıla neredeyse iki katına çıkmış. Üstüne bir de agentic workflow’lar geldi — yanı AI ajanları artık kod yazıp PR açıyor. Bak şimdi, siz bir maintainer olarak sadece insanlardan gelen katkıları değil, otonom ajanların bıraktığı işleri de tek tek süzmek zorundasınız; bu asimetri var ya, baya can sıkıcı.
Bunu biraz açayım.
“Senin hiç vakit harcamadığın bir şeye ben ne kadar vakit harcamalıyım?”
Bu soru bana kalırsa 2025’in en sert açık kaynak sorularından biri. AI bir saniyede PR açıyor, maintainer önü değerlendirmek için belki yarım saatini veriyor. Denge tuhaf. Hatta biraz adaletsiz.
Eternal September: Açık Kaynağın Bitmeyen Eylülü
Tuhaf ama, Şubat ayında Ashley Wolf, GitHub bloğunda bu tabloyu “açık kaynağın Eternal September’ı” diye tarif etmişti. Terim eski internet kültüründen geliyor; 1993’te AOL kullanıcıları Usenet’e akın edince, her ay üniversiteye yeni başlayanların yarattığı içerik dalgası artık hiç bitmiyormuş gıbı olmuştu. Şimdi benzerini yaşıyoruz, sadece bu kez düşük kaliteli katkılar AI yardımıyla daha hızlı geliyor.
Araya gireyim: Geçen ay Logosoft’ta bir müşterinin internal tooling repo’sunda tam olarak bunu gördük. Ekipten bir geliştirici Copilot CLI ile bir özelliği “hızlıca” hallettim diyerek 14 PR açmıştı. İlk bakışta fena değil gibiydi. Yarısı duplicate’ti, üçü test bile içermiyordu, biri de zaten var olan bir şeyi başka isimle yeniden yazmıştı. Review’a giren senior kişi buna tam 3 saat verdi. Üç saat! Yazanın harcadığı süre belki 20 dakikaydı.
Bunu biraz açayım.
Bence, İşte bu yüzden GitHub’ın Maintainer Month kapsamında duyurduğu yeni özellikler — biraz gecikmiş olsalar da — baya iş görüyor.
Yeni Araçlar: Maintainer’ın Elindeki Kontroller
Granular Contribution Limits
Bence ayın en işe yarar özelliği bu. Artık repo sahibi, “yeni — en azından ben öyle düşünüyorum — veya bilinmeyen kullanıcı”ların belirli bir süre içinde kaç PR açabileceğini sınırlayabiliyor. Kapıyı tamamen kapatmıyorsunuz; ama sel gelince önüne küçük de olsa bir bent koymuş oluyorsunuz.
Pratik örnek vereyim: Diyelim popüler bir Türkçe NLP kütüphanesini maintain ediyorsunuz. Daha önce iki seçeneğiniz vardı — ya repo’yu herkese açıp spam’e boğulacaktınız ya da sadece collaborator’lara izin verip topluluğun büyümesini frenleyecektiniz. Şimdi üçüncü yol var:
- Yeni kullanıcılar haftada en fazla 2 PR açabilir
- İlk PR’ı merge olan otomatik olarak trusted sayılır
- Spam tespitinde bulk archive ile temizlik yapılabilir
Pull Request Archiving
Yıllarca destek ekibine mail atıp “şu spam PR’ları silebilir mısınız” diye uğraşan çok kişi öldü. Şimdi bunları arşive atıp gözden uzak tutabiliyorsunuz. Ufak gıbı duran bir özellik ama psikolojik (söylemesi ayıp) etkisi baya büyük. Temiz bir liste görmek insanın omzundan yük alıyor, öyle diyeyim. SQL MCP Server’ı App Service’te Çalıştırmak: Container’sız yazımızda bu konuya da değinmiştik.
Diğer Şubat’tan Bu Yana Gelen Şeyler
Liste uzun aslında; hepsini tek tek dökmeyeyim ama önemli olanlar şöyle:
| Özellik | Ne işe yarıyor? | Kim için kritik? |
|---|---|---|
| PR Creation Controls | PR açmayı sadece collaborator’lara kısıtlama | Mirror repo’lar, roadmap repo’ları |
| Pinned Comments | Issue thread’inde önemli yorumu yukarı sabitleme | Uzun tartışmalı issue’lar |
| Notifications oldest-first | Bildirimleri en eskiden başlayarak işleme | Backlog temizleyenler |
| File upload in issue forms | Structured template’lerde dosya yükleme | Bug report’lar |
“Oldest-first” sıralaması ilk bakışta minicik görünüyor olabilir ama maintainer açısından fark ediyor (ciddiyim). Çünkü en eski bildirimler genelde en çok sürüncemede kalanlar oluyor. Yeni gelenleri kovalamak yerine eskileri kapatmaya başlamak, insana nefes aldırıyor.
agents.md: Standart Geliyor mu?
Son dönemde Maintainer Month çevresinde en çok konuşulan konulardan biri agents.md. Mantık basit aslında: CONTRIBUTING.md, insan katkıcılara nasıl PR açacaklarını anlatıyorsa; agents.md de AI ajanlarına bu repoda nasıl davranmaları gerektiğini söylüyor.
Böyle bir dosyanın içeriği mesela şöyle olabilir: Bu konuyla ilgili mssql-python’da Apache Arrow Desteği: Sahadan Notlar yazımıza da göz atmanızı tavsiye ederim.
# Agent Guidelines
## Test Requirements
- Tüm PR'larda unit test zorunlu
- Coverage %80'in altına düşmemeli
## Style
- Black formatter kullan
- Docstring NumPy stilinde
## Forbidden
- Yeni dependency eklemeden önce issue aç
- Public API değişikliği için RFC süreci
## Commit
- Conventional Commits formatı
- Her commit tek bir mantıksal değişiklik içermeli
Daha resmî bir standart değil ama işin kokusu geliyor diyeyim (en azından benim deneyimim böyle). Microsoft Agent Framework:.NET’te Akıllı Ajan Devri yazımda da değinmiştim; agentic AI ekosistemi büyüdükçe böyle “ajan-okunabilir” konfigürasyonlara ihtiyaç artıyor (ki bu çoğu kişinin gözünden kaçıyor)
Türkiye’deki Açık Kaynak Maintainer’ları İçin Durum Ne?
Neyse biraz yerel tarafa gelelim. Türkiye’de aktif şekilde açık kaynak proje maintain eden insan sayısı açıkçası hak ettiğinden az kalıyor. Bunun birkaç nedeni var bence: Bu konuyla ilgili Cosmos DB Azure RBAC Entegrasyonu: İki Dünya Birleşti yazımıza da göz atmanızı tavsiye ederim.
Peki neden?
Birinçisi, çoğu Türk geliştirici “açık kaynağa katkı” deyince aklına hemen dev projeler getiriyor — React, Kubernetes, Linux kernel falan. Halbuki kendi projenizi açıp beş kişiyle başlamak da gayet açık kaynak oluyor. Bir telekom firmasındaki müşterimde internal caching kütüphanesini açık kaynağa açmaya ikna etmiştim, tarih de net: 2022 (evet, doğru duydunuz). Bugün haftada ortalama 30 PR alıyorlar ve ekip işe alımında bile bundan fayda gördü. Daha fazla bilgi için Visual Studio 2026 Nisan: Copilot Agent’ları Devreye Girdi yazımıza bakabilirsiniz.
İkinci mesele kurumsal yapıların çoğunda açık kaynak katkı politikası olmaması. Yanı çalışan mesai saatlerinde kendi GitHub hesabından PR açabilir mi? Şirket buna nasıl bakıyor? Hâlâ pek çok KOBİ. Orta-büyük şirket bu konuda net olmadığı için çalışanlarını istemeden geriyor.
Dördüncüsü yok tabii; üçüncüsü şu: AI ile gelen düşük kaliteli katkı sorunu burada daha da büyüyebilir gıbı duruyor. Stajyer ve junior tarafında Copilot kullanımı yaygınlaştıkça “CV için PR yapayım” akımı tekrar canlanacak gıbı geliyor bana. O yüzden Maintainer Month’un getirdiği rate limit araçları Türk maintainer’lar için ciddi derecede işe yarayabilir.
Küçük Ekip mi Kurumsal mı?
Küçük bir detay: Böyle durumlarda strateji projeye göre değişiyor tabii. Eğer 1-3 kişilik hobi projeniz varsa benim yaklaşımım şu ölür:
- Ilk gün: Granular contribution limits’i açın — yeni kullanıcılara haftada 1 PR yeterli ölür
- Ilk hafta: CONTRIBUTING.md ve agents.md yazın
- Ilk ay: Issue template’leri structured form hâline getirin
Hani, Ama kurumsal bir projeyse işler değişiyor; mesela bankacılık tarafında SDK yayımlıyorsanız ki Türkiye’de nadir ama oluyor, o zaman Code of conduct, security policy ve CLA gıbı şeyler şart hâle geliyor. Ben Bankacılıkta Customer 360: Azure DocumentDB ile Pratik Yol yazımda değindiğim bir projede hukuk ekibiyle tam 3 ay CLA hazırlamıştık. Kolay iş değildi.
Kişisel Bir Hikâye: Maintainer Burnout
Yanı, Madem konu buraya geldi, küçük bir şey anlatayım. 2021’de Python ile ufak bir CLI aracı yazmıştım; Azure resource’ları için hızlı tag atmaya yarayan kişisel bir araçtı aslında. GitHub’a koydum, README ekledim, “tamam bu artık açık kaynak” dedim kendi kendime. Azure Cosmos DB Conf 2026: Notlarım, İzlenimlerim ve yazımızda bu konuya da değinmiştik.
İlk altı ay tatlı geçti — haftada bir iki star geliyordu, ara sıra issue düşüyordu ve hayat idare eder gidiyordu.
Şahsen, Sonra proje bir blog yazısında anıldı ve gece içinde her şey değişti: 1.200 star geldiğini gördüm… Ertesi hafta işe tablo biraz dağıldı; 47 issue ve 23 PR oluştu bunların yarısı typo düzeltmesiydi, üçte biri feature request’i doğrudan kod olarak göndermişti, geri kalanı işe gerçekten faydalıydı.
Kısacası, küçük bir detay: “Hmm” dedirten dönemlerden biri buydu işte… O sırada iş yerinde de yoğundum ve üç hafta boyunca projeye hiç bakamadım sonra dönüp baktığımda karşıma 73 açık issue çıktı Suçluluk hissi başladı Tek tek cevaplamaya çalıştım ama yetişemedim Sonunda projeyi archive ettim Maalesef.
Neyse uzatmayalım bunu yaşayınca anladım ki maintainer olmak sadece kod yazmak değilmiş; üstüne insanların sandığından daha duygusal ve yorucu bir yük de taşıyor O gün bugündür düşünüyorum eğer o zaman bu özellikler olsaydı rate limit archive oldest-first notifications acaba projeyi kapatmak zorunda kalır mıydım Belki kalmazdım.
Peki Bugün Ne Yapmalısınız?Eğer siz de bir repo maintain ediyorsanız bu hafta atabileceğiniz somut adımlar şunlar:
Sıkça Sorulan Sorular
Maintainer Month ne, ne zaman oluyor?
Maintainer Month, GitHub’ın 2020’den beri her Mayıs’ta düzenlediği bir etkinlik — açık kaynak proje sürdürücülerini kutlamak için. Bu yıl aslında 6. yılı. Yıl boyunca yeni özellikler, kaynaklar ve topluluk etkinlikleri duyuruluyor.
Granular contribution limits özelliğini nasıl açıyorum?
Repo’nuzun Settings sekmesine gidin, orada Moderation altında “Contribution limits” başlığını göreceksiniz. Yeni veya bilinmeyen kullanıcıların belirli bir sürede açabileceği maksimum PR sayısını oradan ayarlayabiliyorsunuz. Şu an yalnızca public repo’larda kullanılabiliyor.
agents.md dosyasını eklemek zorunda mıyım?
Hayır, zorunlu değil. Yanı resmî bir GitHub standardı da değil açıkçası. Ama Copilot Coding Agent ve bazı üçüncü parti AI araçları bu dosyayı okuyup uyguluyor. Bence repo’nuzda AI kaynaklı katkıların belirli kurallara uymasını istiyorsanız eklemeye değer.
Eternal September ne demek, açık kaynakla ne ilgisi var?
Eski bir internet terimi. 1993’te AOL kullanıcıları Usenet’e akın etmişti. “yeni gelenlerin yarattığı düşük kaliteli içerik dalgasının bir türlü bitmemesi” durumunu anlatıyor. Açık kaynak dünyasında da mesela AI destekli düşük kaliteli PR akışı için aynı benzetme kullanılıyor — tecrübeme göre bu sorunun geçici olmadığını, kalıcı olduğunu kabul etmek işleri epey kolaylaştırıyor.
Türkiye’de açık kaynağa katkıya nereden başlamalıyım?
Bence klasik “good first issue” etiketli issue’larla başlamak yerine, hâli hazırda kullandığınız bir kütüphanenin dokümantasyonundaki bir eksiği giderin. Hem daha az rekabet var hem çok daha fazla şey öğreniyorsunuz (ciddiyim). Ayrıca Türkçe NLP araçları gıbı Türkçe açık kaynak projelere katkı sağlamak, teknik açıdan olduğu kadar topluluk açısından da gerçekten değerli.
Kaynaklar ve İleri Okuma
Tuhaf ama, GitHub Blog: Welcome to Maintainer Month (Orijinal Yazı)
Open Source Guides: Açık Kaynak Maintainer Rehberleri
GitHub Docs: Maintaining Your Safety on GitHub
İlginç olan şu ki, Open Source’s Eternal September — Ashley Wolf
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
