Açık Kaynak Yazılım Seçerken Dikkat Edilmesi Gerekenler

Yazar:komut.io ekibi Rehber & İpuçları
0 Yorum

Üretim ortamına yeni bir araç almadan önce şunu düşün: bu yazılım yarın sabah saat 03:00’te seni uyandırabilir mi? Eğer cevabın “evet, ama bilmiyorum nasıl müdahale edeceğimi” ise, seçim sürecini atlamışsın demektir. Açık kaynak dünyası inanılmaz fırsatlar sunuyor, bunu kimse inkâr etmez. Ama “ücretsiz” kelimesi bazen gerçek maliyeti gizliyor. Lisans bedeli ödemiyorsun, doğru. Ama öğrenme süresi, entegrasyon çabası, bakım yükü ve olası kurtarma operasyonları için harcanan mesai ücretsiz değil. Bu yazıda sana bir kontrol listesi vermeyeceğim. Bunun yerine, yıllarca farklı ortamlarda açık kaynak araçları değerlendirirken öğrendiğim şeyleri paylaşacağım.

Projenin Sağlığını Nasıl Ölçersin

İlk baktığın şey GitHub yıldız sayısı olmamalı. Yıldız sayısı popülerliği gösterir, sağlığı değil. Bir projenin gerçekten canlı olup olmadığını anlamak için commit geçmişine ve issue kapatma hızına bakman gerekiyor.

# Projenin son 6 aydaki commit aktivitesini kontrol et
git clone --depth=1 https://github.com/ornek/proje.git
cd proje
git log --oneline --since="6 months ago" | wc -l

# Son commit tarihini gör
git log -1 --format="%ci %s"

# Katkı yapan benzersiz kişi sayısı (son 1 yıl)
git log --since="1 year ago" --format="%ae" | sort -u | wc -l

Eğer son 6 ayda 10’dan az commit varsa ve tek bir kişi her şeyi yapıyorsa, bu bir uyarı işareti. Söz konusu kişi burnout yaşarsa, iş değiştirirse ya da hayatında başka öncelikler çıkarsa proje öylece durur. Buna “bus factor” deniyor: kaç kişi projeyi terk ederse proje ölür sorusunun cevabı. Tek kişilik projeler için bu sayı birdir.

Issue tracker’a bakarak açık sorunların yaşına dikkat et. Kritik bir bug 2 yıldır açıksa ve kimse yanıt vermediyse, o projenin bakımcıları ya çok meşgul ya da artık ilgisiz demektir.

# GitHub CLI ile açık issue sayısını ve ortalama kapanma süresini kontrol edebilirsin
gh issue list --repo ornek/proje --state open --limit 100 | head -20

# Belirli etiketlere sahip kritik issueları filtrele
gh issue list --repo ornek/proje --label "bug,critical" --state open

Lisans Tuzaklarına Dikkat

“Açık kaynak” demek her zaman “istediğin gibi kullan” demek değil. Bu konuda birçok sistem yöneticisinin düştüğü tuzakları bizzat gördüm. Bir şirkette internal tooling için kullandıkları bir araç AGPL lisanslıydı. AGPL, network üzerinden sunduğun bir serviste bile kaynak kodu paylaşmayı zorunlu kılar. Hukuk departmanı devreye girince epey bir kargaşa yaşandı.

Temel lisans kategorileri şöyle:

  • MIT / BSD / Apache 2.0: En permissive lisanslar. Ticari kullanım, modifikasyon, dağıtım serbesttir. Çoğu kurumsal ortam için sorun çıkarmaz.
  • GPL v2 / GPL v3: Copyleft lisanslar. Kodu değiştirip dağıtırsan sen de kaynak kodunu paylaşmalısın. Internal kullanımda genellikle sorun yok.
  • AGPL: En kısıtlayıcı copyleft. Network servisleri için bile geçerli. SaaS ürünlerde risk yaratır.
  • SSPL (MongoDB): Açık kaynak mı değil mi tartışmalı. OSI tarafından onaylı değil. Dikkatli ol.
  • BSL (Business Source License): Belirli bir süre sonra açık kaynağa dönüşen hibrit lisans. HashiCorp bu yola gitti, topluluk tepkisi büyük oldu.
# Bir projenin tüm bağımlılıklarının lisanslarını kontrol et (Node.js örneği)
npx license-checker --summary

# Python için
pip install pip-licenses
pip-licenses --format=markdown

# Go projeleri için
go-licenses report ./...

Özellikle kurumsal ortamlarda çalışıyorsan, hukuk ekibinle konuşmadan AGPL veya SSPL lisanslı bir şeyi üretim ortamına alma. Bu söz kulağa gereksiz yere bürokratik gelebilir, ama bir kez yaşarsan anlarsın.

Güvenlik Geçmişini Araştır

Bir yazılımın geçmişte güvenlik açığı yaşaması onu kötü yapmaz. Önemli olan o açıklara nasıl tepki verildiği. Açıkların geç fark edilmesi, CVE yayınlandıktan sonra yamaların haftalar sonra gelmesi, güvenlik araştırmacılarına soğuk davranılması, bunlar ciddi kırmızı bayraklardır.

# Belirli bir paketin bilinen CVE'lerini kontrol et
# grype ile container image tarama
grype ubuntu:22.04

# trivy ile
trivy image nginx:latest

# Belirli bir paket için NVD'yi sorgula
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=paket-adi&resultsPerPage=10" | 
  python3 -c "import sys,json; data=json.load(sys.stdin); [print(v['cve']['id'], v['cve']['descriptions'][0]['value'][:100]) for v in data.get('vulnerabilities',[])]"

Bunun yanında projenin güvenlik politikası dökümanını ara. SECURITY.md dosyası var mı? Güvenlik açıklarını nasıl bildireceğini açıklıyor mu? Bu basit bir dosya ama projenin güvenliğe verdiği önemi gösterir.

# Proje reposunda güvenlik politikası var mı kontrol et
curl -s https://api.github.com/repos/ornek/proje/contents/SECURITY.md | 
  python3 -c "import sys,json; d=json.load(sys.stdin); print('Mevcut' if 'content' in d else 'Yok')"

Bağımlılık Zinciri: Görünmeyen Risk

Bir aracı değerlendirirken sadece o araca değil, onun bağımlılıklarına da bakman gerekiyor. Log4Shell’i hatırla. Log4j doğrudan kullanmıyordun, ama kullandığın bir Java uygulaması kullanıyordu ve sen de etkilendin.

# Docker image içindeki tüm paketleri ve bağımlılıklarını listele
docker run --rm -it ubuntu:22.04 dpkg -l | awk '{print $2, $3}' | grep -v "^ii|^rc|^+" | head -50

# Bir npm paketinin bağımlılık ağacını görselleştir
npm ls --depth=3 2>/dev/null | head -50

# Python bağımlılıklarını düz liste olarak çıkar
pip freeze > requirements.txt
safety check -r requirements.txt

Supply chain saldırıları giderek artıyor. event-stream, node-ipc, colors, faker gibi popüler paketlerin başına gelenleri düşün. Bu yüzden bağımlılık sayısı az olan, well-known paketlere dayanan projeleri tercih etmek mantıklı. Eğer bir araç 200 tane bağımlılık çekiyorsa, her birinin güvenliğini takip etmen gerekiyor demektir.

Topluluk ve Destek Ekosistemi

Sorun yaşadığında nereye gideceksin? Bu sorunun cevabı olmayan bir aracı üretime almanın anlamı yok. Topluluk değerlendirmesinde şunlara bakıyorum:

  • Stack Overflow tag: Kaç soru var, güncel mi, cevaplar kaliteli mi?
  • Discourse / Reddit: Aktif bir forum var mı?
  • Discord / Slack: Gerçek zamanlı yardım alabilir misin?
  • Ticari destek seçeneği: Kritik sistemler için önemli. Red Hat, Elastic, HashiCorp gibi şirketlerin açık kaynak araçlarında bu avantaj var.
# Stack Overflow API ile soru sayısını kontrol et
curl -s "https://api.stackexchange.com/2.3/tags/proje-adi/info?site=stackoverflow" | 
  python3 -c "import sys,json; d=json.load(sys.stdin); print('Soru sayisi:', d['items'][0]['count'] if d['items'] else 0)"

Türkiye’deki bir başka gerçeklik şu: İngilizce dokümantasyonu olan ama Türkçe kaynak bulamadığın araçlarda sorun yaşadığında, ekibindeki herkesin İngilizce kaynaktan beslenmesi gerekiyor. Bu bir engel değil ama planlamanın parçası olmalı.

Performans ve Ölçeklenebilirlik Testleri

“Biz küçük bir ortamız, performans sorun olmaz” diyerek almaya başladığın bir araç 6 ay sonra seni mahvedebilir. Büyüme planını baştan düşünmek lazım.

# Basit bir HTTP servis için yük testi
# wrk ile
wrk -t12 -c400 -d30s http://localhost:8080/api/test

# Apache Bench ile
ab -n 10000 -c 100 http://localhost:8080/

# Bellek kullanımını izle
while true; do
  ps aux | grep "proje-adi" | grep -v grep | awk '{print $2, $4, $6}' >> memory_log.txt
  sleep 5
done
# Disk I/O yoğun uygulamalar için
iostat -x 1 10

# Ağ yoğun servisler için
iftop -i eth0 -t -s 10 2>/dev/null | tail -20

Gerçek dünya senaryosunda bir izleme aracını değerlendirirken, önce kendi lab ortamında prodüksiyonun %110’u kadar yük oluşturmayı dene. Çoğu araç normal yükte güzel çalışır, pik anında çöker. Bu testi yapmadan üretime çıkmak Rus ruleti oynamak gibidir.

Dağıtım ve Paketleme Kalitesi

Bir yazılımı nasıl dağıttığı, o projenin olgunluğu hakkında çok şey söyler. Şöyle bir kontrol listesi işime yarıyor:

  • Resmi Docker image var mı? Düzenli güncelleniyor mu? Minimal base image kullanıyor mu?
  • Paket yöneticisi desteği: apt, yum, brew, snap gibi kaynaklardan kurulabiliyor mu?
  • Helm chart: Kubernetes ortamı için resmi veya topluluk destekli chart mevcut mu?
  • Binary release: Platforma özgü derlenmiş binary var mı?
# Docker image kalitesini kontrol et
# Image boyutunu gör
docker pull proje:latest
docker image inspect proje:latest | python3 -c "
import sys, json
d = json.load(sys.stdin)
print('Size:', round(d[0]['Size']/1024/1024, 2), 'MB')
print('Created:', d[0]['Created'][:10])
print('Layers:', len(d[0]['RootFS']['Layers']))
"

# Image içindeki güvenlik açıklarını tara
trivy image --severity HIGH,CRITICAL proje:latest

# Gereksiz yere root çalışıyor mu?
docker run --rm proje:latest whoami
# Helm chart kalitesini kontrol et
helm lint ./chart-dizini

# Helm Hub'dan chart bilgisi al
helm search hub proje-adi --max-col-width=80

Root olarak çalışan, gereksiz büyük image’lar, yıllardır güncellenmemiş base image’lar, bunlar bakım kalitesinin göstergesi.

Konfigürasyon ve Operasyonel Olgunluk

Bir aracın operasyonel olgunluğunu anlamak için şu sorulara cevap arar:

  • Health check endpoint’i var mı?
  • Prometheus/OpenTelemetry metrikleri sunuyor mu?
  • Structured logging yapıyor mu (JSON log)?
  • Graceful shutdown destekliyor mu?
  • Konfigürasyon değişikliği için restart gerekiyor mu, hot reload var mı?
# Servisin health check endpoint'ini test et
curl -sf http://localhost:8080/health | python3 -m json.tool

# Prometheus metriklerini kontrol et
curl -s http://localhost:9090/metrics | grep -v "^#" | head -20

# JSON log üretip üretmediğini kontrol et
journalctl -u servis-adi -n 50 --no-pager | head -5 | python3 -c "
import sys, json
for line in sys.stdin:
    try:
        # Sadece JSON kısmını bul
        start = line.find('{')
        if start >= 0:
            json.loads(line[start:])
            print('JSON log: EVET')
            break
    except:
        pass
else:
    print('JSON log: HAYIR - plain text log')
"

Structured logging neden önemli? Çünkü Elasticsearch’e, Loki’ye ya da herhangi bir log aggregation sistemine atmak istediğinde parse etmen gerekmez. Bunu bilmeden log analizi yapılamayan bir araçla birkaç ay geçirmek, insan yaşlandırır.

Gerçek Dünya: Değerlendirme Süreci Nasıl Yürütülür

Teorik bilgiden pratiğe geçelim. Yeni bir araç değerlendirirken izlediğim süreci paylaşayım.

İlk aşama: Hızlı eleme (1-2 saat)

GitHub/GitLab reposuna bak, son commit tarihini gör, lisansa bak, açık kritik issue sayısına bak. Bu aşamada elenen çok proje oluyor. Hızlı karar ver.

İkinci aşama: Lab kurulumu (yarım gün)

# Vagrant ile izole test ortamı kur
vagrant init ubuntu/jammy64
vagrant up
vagrant ssh

# Ya da Docker Compose ile hızlı test ortamı
cat > docker-compose.test.yml << 'EOF'
version: '3.8'
services:
  test-app:
    image: proje:latest
    ports:
      - "8080:8080"
    environment:
      - LOG_LEVEL=debug
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 10s
      timeout: 5s
      retries: 3
EOF

docker-compose -f docker-compose.test.yml up -d
docker-compose -f docker-compose.test.yml ps

Üçüncü aşama: Yük ve dayanıklılık testi (1 gün)

Minimum 4 saat sürekli yük altında çalıştır. Bellek sızıntısı var mı? CPU zamanla artıyor mu? Bağlantı havuzu tükeniyor mu?

# Uzun süreli bellek takibi
watch -n 30 'docker stats --no-stream --format "{{.Container}}: CPU={{.CPUPerc}} MEM={{.MemUsage}}"'

# 4 saatlik yük testi scripti
for i in $(seq 1 48); do
  ab -n 1000 -c 20 -q http://localhost:8080/api/test >> load_test_results.txt 2>&1
  sleep 300  # 5 dakika bekle
  echo "$(date): Iterasyon $i tamamlandi" >> load_test_results.txt
done

Dördüncü aşama: Failure senaryoları

Ağı kes, bağımlı servisi öldür, disk doldur, belleği tüket. Nasıl tepki veriyor? Graceful mı, panic mi?

Sürüm Politikası ve Upgrade Yolu

Uzun vadeli kullanım için sürüm politikası kritik. Şunlara bakıyorum:

  • Semantic versioning kullanıyor mu? (semver.org standardı)
  • LTS (Long Term Support) sürümleri var mı?
  • Changelog düzenli ve anlamlı mı? “Bug fixes and improvements” yazan changelog’u olan proje beni tedirgin eder.
  • Upgrade migration kılavuzu var mı? Major sürüm geçişlerinde ne kadar acı çekeceksin?
  • Deprecation süreci iyi tanımlanmış mı?
# Şu an kullandığın versiyonu ve son versiyonu karşılaştır
# Örnek: Helm chart için
helm version --short
helm repo update
helm search repo stable/proje-adi

# Kubernetes operator için
kubectl get deployment proje-operator -n proje-system -o jsonpath='{.spec.template.spec.containers[0].image}'

HashiCorp’un geçen yıl Terraform ve diğer araçlarını BSL’e geçirme kararı, sürüm politikasını ve vendor lock-in riskini ne kadar ciddiye almak gerektiğini bir kez daha gösterdi. OpenTofu çatalı ortaya çıktı, topluluk ikiye bölündü. Bu tür kırılmaları tamamen engelleyemezsin, ama risk değerlendirmeni buna göre yapabilirsin.

Fork ve Alternatif Analizi

Seçtiğin araç için sağlıklı alternatifler biliyor musun? Herhangi bir sebepten o araçtan çıkman gerekirse ne yapacaksın? Bu soruyu baştan sormak sağlıklı bir yaklaşım.

Her değerlendirme sürecinde en az 2-3 alternatifi kıyaslamaya çalış. Bunu yaparken aynı scriptleri her alternatife uygula, kıyaslamanı veriye dayandır. “Bence bu daha iyi görünüyor” yerine “bu 30ms daha az latency üretiyor ve bellek kullanımı %40 daha az” demek çok daha güçlü bir argüman.

# İki farklı araç için basit performans karşılaştırması
# Araç A testi
time for i in $(seq 1 100); do
  curl -sf http://localhost:8081/api/endpoint > /dev/null
done

# Araç B testi
time for i in $(seq 1 100); do
  curl -sf http://localhost:8082/api/endpoint > /dev/null
done

Sonuç

Açık kaynak yazılım seçimi, tek seferlik bir karar değil. Başlangıçta yaptığın değerlendirme önemli, ama asıl iş zamanla değişen koşullara, güvenlik güncellemelerine ve topluluk dinamiklerine ayak uydurmak. Seçtiğin araç için bir sahip çıkın olmalı. Bu kişi hem teknik derinliğe hem de takip sorumluluğuna sahip olmalı.

Bir kontrol noktası olarak şunu öner: her 6 ayda bir kullandığın açık kaynak araçların listesini gözden geçir. Projenin hâlâ aktif olup olmadığına, bilinen güvenlik açıklarına ve yeni alternatiflere bak. Bu 2-3 saatlik periyodik inceleme, sürpriz bir krizden çok daha ucuza mal olur.

Son olarak şunu söylemeliyim: Mükemmel araç diye bir şey yoktur. Her seçim bir denge oyunudur. Önemli olan bu dengelerin farkında olarak bilinçli kararlar vermek. “Herkes kullanıyor” ya da “GitHub’da 30 bin yıldız var” gibi sosyal kanıtlar seni yanıltabilir. Kendi ortamının gereksinimlerini, ekibinin kapasitesini ve operasyonel bağlamını en iyi sen biliyorsun. Değerlendirme sürecini bu bağlama göre şekillendir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir