Thu Oct 01 2026
Selam! 👋
Bugün açık kaynak sürdürülebilirliği üzerine sohbet edeceğiz — biraz da Polly kütüphanesinin son dönemdeki kararından yola çıkarak. Hazırsan başlayalım.
Açık kaynak dünyasını seven herkes biliyor: kod "ücretsiz" olsa da, bakımı "bedava" değil.
Polly (retry, circuit breaker, timeout vb. resilience pattern'leri için .NET'in go-to kütüphanesi) yıllardır bu ekosistemde kritik bir yer tutuyor. NuGet indirme sayıları milyonları buluyor, hemen her .NET projesi doğrudan veya dolaylı yolda Polly'ye bağlı.
Son dönemde Polly ekibi, bakım ve geliştirme sürecini sürdürülebilir kılmak için yeni bir model duyurdu: Polly.Contrib ve Polly.Core ayrımı, ticari destek paketleri ve "bakım ücreti" (maintenance fee) kavramı gündeme geldi.
Kısaca: popüler bir kütüphane bile "nasıl ayakta kalırım?" sorusuyla yüzleşiyor.
Yazının akışı şöyle olacak:
Hadi derinlemesine inceleyelim! 🚀
Selam! Hadi açık kaynak dünyasının en can alıcı sorunlarından biriyle yüzleşelim: para nereden gelecek? 🤔
Çoğumuz "açık kaynak = bedava" zihniyetiyle büyüdük. Ama gerçeklik şu: kod yazmak bedava değil, zaman ve enerji harcıyor. Ve şu anki bağış tabanlı model... yeterli değil. Neden mi? Gelin beraber irdeleyelim.
1. "Ücretsiz rider" sorunu 🆓
log4j güvenlik açığı çıktığında, binlerce kurum etkilenmişti. Projeyi sürdüren ekip? Birkaç gönüllü. Bağışlar? Peanuts seviyesindeydi.2. Kurumsal onay süreci = kabus 🏢
Geliştirici: "Bu kütüphaneyi kullanıyoruz, 500$ bağış yapalım."
Yönetici: "Bütçe var mı?"
Finans: "Bağış kategorimiz yok."
Hukuk: "Sözleşme lazım, fatura lazım, KVKK uyumluluğu..."
CTO: "Önceliklerimiz başka, sonra bakarız."
Sonuç: 500$ için 3 ay sürüyor, proje o kadar bekleyemez.
3. Bütçe döngüleri uyumsuz 📅
| Proje | Durum | Ne Oldu? |
|---|---|---|
| core-js | Çok yaygın kullanılan polyfill | Yazar "artık bakımı yapamıyorum" dedi, topluluk forkladı |
| colors.js / faker.js | Milyonlarca indirme | Yazar kasıtlı bozdu, "bağış gelmediği için" |
| Babel | JavaScript ekosisteminin kalbi | Yıllar süren finansman krizi, artık sponsorlarla yaşıyor |
Bağış yardımcı olur ama strateji olamaz. Şunlar lazım:
Özetle: Bağış modeli "iyilik duygusu" üzerine kurulu. Kurumlar ise "ROI ve risk yönetimi" dili konuşur. Bu iki dünya birbirini anlayamazsa, açık kaynak sürdürülemez kalır. 🎯
Bir sonraki bölümde kurumsal finansman modellerini ve nasıl çalıştıklarını inceleyeceğiz. Hazırsan hadi devam! 🚀
Hazırsan biraz geriye gidip Polly'nin hikayesini hızlıca özetleyelim. Çünkü bir kütüphaneyi gerçekten anlamak istiyorsak, nereden geldiğini ve nereye gittiğini bilmek lazım 🎯
Polly, 2013'te Michael Wolfenden tarafından bir side project olarak başladı. O dönemde .NET ekosisteminde "retry" veya "circuit breaker" pattern'larını elinizle yazmak ya da Enterprise Library gibi ağır çözümleri çekmek tek seçenekti. Michael, "Basit, fluent ve extensible bir resilience kütüphanesi olsun" diye Polly'yi NuGet'e pushladı.
İlk sürümler sadece retry ve circuit breaker destekliyordu. Ama API tasarımı o kadar temizdi ki (ki hala öyle), topluluk hemen kucakladı.
Bu yıllar Polly için altın çağdı:
IHttpClientFactory ile built-in integration kazandı (Microsoft kendisi Polly'yi resmi olarak önerdi)PolicyWrap ve PolicyRegistry gibi gelişmiş kompozisyon özellikleri geldiBu dönemde haftalık indirme sayısı milyonları buldu. Herkes Polly kullanıyordu, herkes Polly öneriyordu.
İşler karışmaya başladı v7.0 ile:
| Özellik | Ne Değişti? |
|---|---|
| Async-only API | Sync overload'lar kaldırıldı, breaking change yarattı |
| Generic policy execution | ExecuteAsync<TResult> pattern'i standartlaştı |
| Telemetry / Metrics | IAsyncPolicy içine hook'lar eklendi (OpenTelemetry entegrasyonu için) |
Ama asıl tetikleyici şuydu: Enterprise müşteriler artık "Biz Polly kullanıyoruz, ama SLA lazım, commercial support lazım, dedicated maintainer lazım" diyecek kadar bağımlı hale gelmişti.
Michael ve çekirdek takım (o zamanlar zaten gönüllü bazlı çalışıyordu) burnout hissetmeye başladı. Issue kuyruğu büyüdü, PR review'ler aylarca bekledi.
2023'te resmi duyuru geldi: Polly artık "maintenance mode"da.
"Yeni feature eklemeyeceğiz. Sadece security fix, critical bug fix ve .NET version uyumluluğu sağlayacağız."
Neden?
Microsoft.Extensions.Resilience) gelmeye başladıv1.0 (2013) → İlk release, Retry + CircuitBreaker
v4.0 (2017) → PolicyWrap, Registry, HttpClientFactory entegrasyonu
v5.0 (2018) → Fallback, Timeout, Bulkhead, Cache policies
v6.0 (2019) → .NET Standard 2.0, async-only execution context
v7.0 (2021) → Breaking changes, telemetry hooks, generic execution
v8.0 (2023) → Son major release, maintenance mode başlangıcı
Polly yok olmadı. Hala milyonlarca projede çalışıyor, NuGet'indan indiriliyor. Ama:
ChaosPolicy, RateLimiter vb. artık community fork'larda ya da alternatif kütüphanelerdeBenim tavsiyem: Mevcut projelerde Polly kalabilir. Yeni başlayan projelerde ise Microsoft.Extensions.Resilience veya Failsafe gibi aktif geliştirilen alternatiflere göz atmanız faydalı olabilir 🛠
Kısaca: Polly, topluluk sevgisiyle büyüdü, enterprise yükü altına girdi, ve şimdi "tamamlandı" durumunda huzurlu bir emeklilik yaşıyor. Bu bir başarısızlık değil — bir kütüphane için en güzel final bu bazen ✅
Hazırsan bu kısımda Polly'nin yeni lisans modelini kafamızda canlandırmak için biraz daha derine inelim. Önce "ne değişti?" sorusunu cevaplayalım, sonra da ücret yapısına ve kurumsal seçeneklere bakalım 👇
Polly v8 ile birlikte BSD-3-Clause lisansından Polyform Shield License'a geçiş yapıldı. Bu ne anlama geliyor kısaca:
Ne oluyor burada? Polyform Shield, "kaynak kodu açık ama ticari kullanım kısıtlı" bir lisans türüdür. Elastic, MongoDB, Redis gibi projelerde gördüğümüz source-available modelinin bir varyantı diyebiliriz.
Polly'nin yeni modelinde ücret yıllık ve küme (cluster) bazında hesaplanıyor. 2024 verilerine göre grob şöyle bir tablo çıkıyor:
| Plan | Yıllık Ücret (USD) | Kapsam |
|---|---|---|
| Developer | $0 | Geliştirme/test ortamları, non-production |
| Team | ~$2,000 / cluster / yıl | Küçük ekipler, production kullanımı |
| Enterprise | Özel fiyatlandırma | Büyük ölçekli, SLA gerektiren kurumlar |
Önemli detaylar:
Enterprise planını seçen şirketler için ekstra değerler geliyor. Bunlar sadece "lisans kağıdı" değil, operasyonel kolaylıklar sağlıyor:
| Özellik | Team | Enterprise |
|---|---|---|
| Öncelikli destek (SLA) | ❌ | ✅ 24/7, 4 saat cevap süresi |
| Özel yama/backport | ❌ | ✅ Güvenlik yamaları için |
| Yasal koruma (indemnification) | ❌ | ✅ Telif hakkı dava riskine karşı |
| Audit log / compliance raporu | ❌ | ✅ SOC2, ISO27001 uyumu için |
| Özel dağıtım (air-gapped) | ❌ | ✅ İnternetsiz ortamlar için |
| Account manager | ❌ | ✅ |
Benim tavsiyem: Eğer production'da 5+ clusterınız varsa veya regulatory compliance (KVKK, GDPR, PCI-DSS) gereksiniminiz varsa, Enterprise ile doğrudan görüşmek zaman kazandırıyor. Team planı küçük ekipler için mantıklı ama ölçeklendiğinde maliyetler hızla artıyor.
Polly'nin resmi repo'sundaki LICENSE.md ve Polyform Shield 1.0.0 metninden en çok sorulan 4 maddeyi özetledim:
| Madde | Ne Dişiyor? | Pratikte Ne Anlama Gelir? |
|---|---|---|
| §1.1 "Permitted Purpose" | Kodun "non-commercial research, personal use, evaluation" için serbest kullanımı | Local'de deneme, POC yapma, öğrenme = ücretsiz |
| §1.2 "Commercial Use" | "Commercial Use" tanımı: herhangi bir gelir getiren ürün/hizmette kullanım | SaaS satıyorsunuz? E-ticaret siteniz var? İç araçlarınız mı? Hepsi commercial |
| §2.1 "License Fee" | Ticari kullanım için "reasonable fee" ödeme zorunluluğu | Ücret Polly ekibi belirliyor, "makul" kavramı yargıya kalmış — dolayısıyla resmi fiyat listesi geçerli |
| §4.2 "No Warranty / Liability Cap" | Lisans veren taraf hiçbir garanti vermiyor, sorumluluk ödenen ücretle sınırlı | Bir hata yüzünden sisteminiz çökerse, Polly ekibinden tazminat alamazsınız (Enterprise'da indenification var) |
❗️ Dikkat: "Evaluation" süresi lisans metninde belirtilmemiş. Polly ekibi şu an için "makul bir süre" diyor (genelde 30-90 gün anlaşıldı). Uzun vadeli POC'nuz varsa yazılı onay almanız en iyisi.
Basit bir checklist ile kendi durumunuzu test edin:
Bu model geri dönüşsüz — v8'den önceki sürümler (v7.x) hâlâ BSD-3-Clause altında. Eğer geçiş yapmak istemiyorsanız:
# package.json / .csproj / pom.xml ne varsa
"Polly": "7.2.3" # Son BSD-3-Clause sürümü
Ama unutmayın: v7 artık maintenance-only mode. Güvenlik yamaları haricinde yeni feature gelmeyecek. Uzun vadede v8'e geçmek zorunda kalacaksınız.
Sorunuz mu var? Yorumlarda veya DM'de tartışabiliriz. Bir sonraki bölümde geçiş stratejileri ve maliyet optimizasyonu üzerine konuşacağız 🚀
Hazırsan başlayalım 🚀
Yeni model, her kesimde farklı bir titreşim yaratıyor. Kısaca ne olduğunu, kimleri etkilediğini ve topluluk ne diyor buna bir bakalım.
| Strateji | Ne Zaman İşe Yarar? | Dikkat Edilmesi Gerekenler |
|---|---|---|
| Kendi modelinizi eğitme | Özel domain veriniz çok büyükse | GPU bütçesi & MLOps altyapısı şart |
| Hugging Face / Model Hub | Hızlı deneme, küçük veri setleri | Lisans kontrolleri unutulmamalı |
| Hybrid (cloud + on‑prem) | Hassas veri + büyük ölçek | Ağ gecikmesi ve maliyet dengesi |
| Prompt engineering only | Prototip, PoC | Üretimde sınırlı güvenilirlik |
Özetle: Yeni model herkes için bir kapı açıyor ama nasıl girdiğiniz sizin stratejinize kalmış 🎯.
Kendiniz için en uygun yolu seçerken maliyet, güvenlik, hız üçgenini göz önünde bulundurun.
Hadi pratik bir örnek üzerinden anlayalım → bir sonraki bölümde birlikte bir prototype kuracağız 🚀.
Hazırsan CI/CD pipeline'ına Polly paketinin lisansını otomatik doğrulayan küçük bir bash betiği ekleyelim.
Şu adımları izlersen, her build'de lisans uyumsuzluğu anında yakalanır 🚀
# Tüm transitif paketleri listele, Polly içeren satırı yakala
dotnet list package --include-transitive | grep -i polly
Ne oluyor?
dotnet list package --include-transitive → projenin tüm NuGet bağımlılıklarını (transitif dahil) stdout'a basar.grep -i polly → büyük/küçük harf duyarsız olarak Polly geçen satırı süzer.# Polly'nin en son sürümünü al, lisans URL'sini parse et
POLLY_VERSION=$(dotnet list package --include-transitive | grep -i polly | awk '{print $2}' | head -1)
LICENSE_URL=$(curl -s "https://api.nuget.org/v3-flatcontainer/polly/${POLLY_VERSION}/polly.nuspec" \
| grep -oP '(?<=<licenseUrl>).*?(?=</licenseUrl>)')
echo "Polly sürümü: ${POLLY_VERSION}"
echo "Lisans URL: ${LICENSE_URL}"
Nasıl çalışıyor?
awk '{print $2}' → sürüm numarasını alır.curl + grep -oP → .nuspec XML'inden <licenseUrl> etiketini çıkarır.# Lisans metnini geçici dosyaya kaydet
curl -sL "${LICENSE_URL}" -o /tmp/polly-license.txt
# Kabul edilen lisanslar (örnek: MIT, Apache-2.0)
ALLOWED_LICENSES=("MIT" "Apache-2.0")
# Basit anahtar kelime kontrolü
LICENSE_OK=false
for LIC in "${ALLOWED_LICENSES[@]}"; do
if grep -iq "${LIC}" /tmp/polly-license.txt; then
LICENSE_OK=true
break
fi
done
if [[ "${LICENSE_OK}" == true ]]; then
echo "✅ Polly lisansı kabul edilebilir (${LIC})"
exit 0
else
echo "⛔ Polly lisansı **kabul edilemez**! İncele: ${LICENSE_URL}"
exit 1
fi
Bu sayede ne oluyor?
/tmp/polly-license.txt dosyasına indirilir.ALLOWED_LICENSES dizisindeki anahtar kelimelerden herhangi biri geçiyorsa build başarılı olur, aksi halde hata kodu 1 döner ve pipeline durur.- name: Polly Lisans Kontrolü
run: |
chmod +x ./scripts/check-polly-license.sh
./scripts/check-polly-license.sh
İpucu: Betiği
scripts/check-polly-license.sholarak kaydedipchmod +xile çalıştırılabilir yap. Herhangi bir CI sisteminde (GitLab CI, Azure Pipelines, Jenkins…) aynı mantıkla çağırırsın.
Özet:
dotnet list package + grep → Polly'yi bul.Artık projenizde Polly (veya herhangi bir paket) lisans uyumluluğu otomatik ve tekrarlanabilir bir şekilde kontrol ediliyor. Keyifli buildler! 🎉
Hadi durup düşünelim bir saniye: bağış modeli gerçekten bitiyor mu? 🤔
Kısa cevap: Hayır, ama değişiyor. Uzun cevap için beraber keşfedelim.
"Sadece bağış değil, değer değişimi yapalım."
| Model | Ne İşe Yarar? | Örnek |
|---|---|---|
| Freemium + Sponsorluk | Temel içerik ücretsiz, ileri seviye/erken erişim ücretli | Newsletter'lar, video serileri |
| Kurumsal Lisanslama | Şirketler projeyi ticari kullanıyorsa lisans ücreti öder | Açık kaynak kütüphaneler (ör. Sidekiq, Tailwind UI) |
| Danışmanlık / Destek Paketleri | Kod yazmak yerine zaman ve uzmanlık satarsınız | "Bu kütüphaneyi entegre etmem için X ₺" |
Neden işe yarar? → Kullanıcı "bağış yapıyorum" demek yerine "bir şey satın alıyorum" hissine kapılır. Psikolojik bariyer kalkar. ✅
Artık tek bir platforma bağımlı olmak riskli. Akıllı geliştiriciler portföy yaklaşımı benimsiyor:
İpucu: "Destek ol" sayfanızda tek bir buton koymayın. 3–4 seçenek sunun: aylık, yıllık, tek seferlik, kurumsal. 🎯
Bazen tek bir kişinin ombasına yük bindirmek yerine topluluk havuzu oluşturuluyor:
Avantaj: Para kişisel geliri değil, proje sürdürülebilirliğine gider. Vergisel/yasal yük de hafifler. ⚖️
Gitcoin, Optimism RetroPGF, Protocol Guild gibi mekanizmalar bağışı "oylama tabanlı dağıtıma" çeviriyor.
Bu model hâlâ olgunlaşıyor ama açık kaynak için "halk malı fonlama" kavramını yeniden yazıyor. 📝
Tek bir "doğru yol" yok. Ama şu soruları kendine sor:
Bağış modeli bitmiyor — "iyi niyetle verilen para" modeli evriliyor.
Gelecek karma modellerin (hybrid), şeffaflığın ve kullanıcının "ne kazandım?" hissinin merkezde olduğu bir yapı. Senin projen için hangi kombinasyon en mantıklı? 🎯
Sence hangi model gelecekte baskın gelecek?
Yorumlarda tartışalım — belki bir sonraki yazımız senin fikrinden ilham alır. 👇
Hey, projen büyüdü, insanlar kullanıyor, hatta PR'lar gelmeye başladı 🎉 Harika! Ama şimdi asıl soru geliyor: Bu işi nasıl sürdürürsün? Kod yazmak bir şey, projeyi yıllarca ayakta tutmak başka bir iş. Hadi gözden geçirelim ne yapabilirsin 👇
Lisans, projenin "evlilik sözleşmesi"si gibi. Yanlış seçersen ileride ticari kullanım, fork'lar veya katkılar konusunda başını ağrıtır.
LICENSE dosyasını ilk commit'te koy. Sonradan eklemek "ben bunu düşünmemişim" sinyali verir.İnsanlar issue açmadan önce nereden destek alacaklarını bilmek ister. Şeffaf ol:
| Kanal | Ne Zaman Kullanılır? |
|---|---|
| GitHub Issues | Bug report, feature request, dokümantasyon hatası |
| Discord / Slack | Hızlı soru-cevap, topluluk sohbeti, "nasıl yaparım?" |
| GitHub Discussions | Uzun vadeli tartışma, RFC, strateji kararları |
| E-posta / Güvenlik Policy | Güvenlik açığı bildirimi (private disclosure) |
Önemli: SUPPORT.md veya CONTRIBUTING.md dosyasına "Önce burayı oku, sonra issue aç" yaz. Zamanını korur.
Açık kaynak = ücretsiz kod, değil ücretsiz destek. Sürdürülebilirlik için gelir modelleri düşün:
✅ Pratik adım: FUNDING.yml dosyasını repo'ya ekle. GitHub profilinde "Sponsor" butonu otomatik çıkar.
Sen "Benevolent Dictator" olabilirsin ama her işi sen yaparsın bitmez.
merge yetkisine sahip olsun. CODEOWNERS dosyasıyla alan bazlı sorumluluk paylaştır.good first issue etiketi koy.CODE_OF_CONDUCT.md koy. Contributor Covenant şablonu yeterli. "Hoşgörü, saygı, yapıcı eleştiri" kültürü oluşturur.Elle yapılan her iş, bir gün unutulur. Otomatize et:
semantic-release veya changesets ile version bump + changelog + npm publish tek komutla.README.md: Ne işe yarar, nasıl kurulur, 30 saniyede nasıl çalıştırılır?ARCHITECTURE.md: Mimarî kararlar (ADR'ler) neden alındı?CHANGELOG.md: Kullanıcılar "ne değişti?" diye sormasın.examples/ klasörü, docker-compose.yml ile bir komutla ayağa kalkan demo.Her feature request "harika fikir" değil. Proje vizyonuna uymayanları nazikçe reddet:
"Harika bir fikir, teşekkürler! Bu projenin temel kapsamı dışında kalıyor. Eğer fork'layıp ayrı bir paket olarak geliştirirsen, buradan link veririz 🙌"
Bu hem odaklanmanı korur hem de topluluğa "kendi ihtiyaçlarını çözebilirsin" mesajı verir.
Son söz: Açık kaynak bir maraton, sprint değil 🏃♂️💨 Kodun ömrü uzunsun istiyorsan; lisansı erken kilitle, destek yol haritası çiz, topluluk kur, otomatize et ve kendine değer biç. Senin yazdığın kodun üzerinden yıllar sonra biri "bu proje sayede işim kolaylaştı" diyeceğine emin ol. O gün gelince, bugün attığın bu adımların hepsi değmiş olacak. Yola devam et, topluluk seninle! 🚀
Bu içerik tamamen yapay zeka destekli otomasyon sistemi ile üretilmiştir.
All rights reserved