Açık Kaynak Yazılım Nasıl Seçilir? 7 Soru ile Karar Ver

GitHub’da 300 yıldızlı bir proje mi, 30.000 yıldızlı bir proje mi? Doğru soru bu değil. Doğru soru şu: “Bu projeyi iki yıl sonra da kullanabilecek miyim?” Yıldız sayısı bunun cevabını vermiyor; ama 7 farklı sinyal birlikte veriyor.

1. Son Commit Ne Zaman?

6 ayı aşkın commit yoksa proje bakımı durmuş sayılabilir. Ancak olgun ve stabil projeler (örneğin SQLite) yıllarca minimal commit alabilir — bu onların kalitesizliğini değil, tamamlandığını gösterir. Bağlam önemli: aktif geliştirme gerektiren bir araç için son 3 ayda commit; stabil altyapı bileşenleri için son 12 ay kabul edilebilir.

2. Issue Kapanma Oranı Nedir?

Açık issue sayısı tek başına anlamsız. 2.000 açık issue, ama aylık 400 kapanıyorsa bu sağlıklı bir ekosistem. 200 açık issue ama aylık 2 kapanıyorsa proje tıkanmış. GitHub’da “Insights → Pulse” sekmesi bu oranı görselleştiriyor.

3. Lisans Kullanım Amacınızla Uyumlu mu?

  • MIT / Apache 2.0: Ticari kullanım dahil neredeyse kısıtsız. Kurumsal tercih bunlar.
  • GPL v3: Türevi çalışmalar da açık kaynak olmak zorunda — ticari ürüne gömüyorsanız hukuki risk.
  • AGPL: Ağ üzerinden sunulan yazılımlar için bile kaynak açma zorunluluğu var. SaaS geliştiriyorsanız dikkatli olun.
  • SSPL / BSL: “Kaynak görünür” ama açık kaynak değil; bazı kullanım senaryolarında ticari lisans gerekiyor.

4. Tek Geliştirici mi, Ekip mi?

“Bus factor 1” projeler risk taşır: tek geliştirici ilgiyi kaybederse veya yaşam koşulları değişirse proje sahipsiz kalır. 2023’te popüler bir Python kütüphanesi olan core-utils-py’nin yazarının projeyi dondurması, binlerce bağımlılık zincirini etkiledi. İdeal senaryo: aktif 3+ geliştirici veya kurumsal sponsor (Red Hat, Google, Mozilla destekli projeler bu açıdan güvenilir).

5. Güvenlik Geçmişi Nasıl?

CVE (Common Vulnerabilities and Exposures) veritabanında projeyi aratın. Önemli olan: güvenlik açıkları kaçınılmaz, ama yamanma hızı kritik. 48 saat içinde yama yayımlayan bir proje, 3 ayda kapatan projeden çok daha güvenilir. NVD (nvd.nist.gov) veya Snyk Advisor bu verileri sunuyor.

6. Dokümantasyon Ne Kadar Kapsamlı?

README’nin dışına çıkın. API referans belgesi var mı? Örnek projeler veya resmi “cookbook” mevcut mu? Söz konusu topluluk tarafından yazılmış blog yazısı veya YouTube içeriği var mı? Topluluğun bilgiyi dışa aktarma isteği, projenin canlılığının dolaylı göstergesi.

7. Çatallama (Fork) Rekabeti Var mı?

Bir proje çok sayıda aktif fork’a sahipse bu iki anlama gelebilir: proje sağlıklı ve ilgi çekici, ya da ana proje yavaş ve topluluk alternatif arıyor. Hangi fork’un daha hızlı geliştiğini görmek, ana projenin geleceği hakkında sinyal verebilir. MariaDB’nin MySQL’den, Libre Office’in OpenOffice’ten ayrılması bu mekanizmanın büyük ölçekli örnekleri.

Bir Araç: Snyk Advisor ve OpenSSF Scorecard

Manuel değerlendirmeye ek olarak iki araç işi hızlandırır. Snyk Advisor (snyk.io/advisor) npm, PyPI ve Go paketleri için sağlık puanı veriyor. OpenSSF Scorecard ise güvenlik pratiklerini 0–10 arasında puanlıyor: branch koruması, bağımlılık güncelleme sıklığı, CI/CD güvenliği gibi kriterleri otomatik kontrol ediyor. İkisi birlikte ilk eleme için güçlü bir başlangıç noktası.