Dürüst olayım: ilk açık kaynak katkımı yapana kadar altı ay geçti sanırım. Hayır, kod yazamadığımdan değil — çekindiğimden. Yıllarca kapalı sistemlerde, hosting tarafında çalışan biri olarak GitHub’da bir repo‘ya pull request yollamak bana başta gereksiz büyük bir iş gıbı gelmişti. “Ya yanlış yaparsam?”, “Ya rezil olursam?” diye dönüp durdum. Sonra fark ettim, meğer herkes aynı tedirginliği yaşıyormuş.
Bu yazıda size açık kaynak (OSS — Open Source Software) dünyasına nasıl girileceğini, ilk katkınızı nasıl yapacağınızı (şaşırtıcı ama gerçek). Daha da önemlisi — topluluğun içinde kendinize nasıl yer açacağınızı anlatacağım. Sadece teknik adımlar yok; bir de kültürel taraf var ki, bence insanlar en çok orada tökezliyor. Hani işin aslı biraz o.
Kısa bir not düşeyim buraya.
Açık kaynak tam olarak nedir, neden uğraşalım?
Tanım aslında basit: Kaynak kodu herkese açık olan, herkesin kullanabildiği ve geliştirebildiği yazılım. Kapalı kaynağın tam tersi yanı. Microsoft Word kapalı kaynak mesela — kodunu göremezsiniz. LibreOffice açık kaynak; kodu GitHub’da, GitLab’da, neredeyse istediğiniz yerde duruyor, bakabiliyorsunuz.
Peki neden bir geliştirici (ya da sistem yöneticisi, DevOps mühendisi, ne olursanız olun) açık kaynağa katkı versin? İşin aslı şu: kariyerimin son 10 yılında öğrendiğim şeylerin önemli kısmını açık kaynak projelere bakarak kaptım (ciddiyim). Kubernetes, Terraform, Bicep — bunların hepsi açık kaynak (ciddiyim). Bir Azure danışmanı olarak ben bile sürekli bu repolara göz atıyorum; bazen çözüm ararken, bazen sadece “bunu nasıl yapmışlar?” diye.
Bi saniye — Bir de CV tarafı var tabii. Açık konuşayım: bugün bir geliştiricinin CV’sinde “şu projeye şu kadar PR attım” yazıyorsa, bu benim gözümde sertifikadan daha anlamlı oluyor. Çünkü bu kişi gerçek kodla uğraşmış demektir, gerçek insanlarla review sürecine girmiş demektir. Bu küçük detay değil.
Peki neden?
“İlk PR’ım iki satırlık bir README düzeltmesiydi. Maintainer ‘Welcome to the community!’ yazdı. O an hayatımın akışı değişti — abartmıyorum.”
Türkiye’deki şirketler açısından durum biraz farklı
Şimdi bakın, kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de açık kaynağa katkı kültürü hâlâ biraz çekingen ilerliyor. Bankacılık ve telekom tarafında çalışan arkadaşlarım var; şirket politikası yüzünden kişisel GitHub hesaplarından bile commit atmaları kısıtlı olabiliyor. Halbuki bu konu tersine dönmeli gıbı geliyor bana.
Logosoft’ta bir bankacılık projesinde çalışırken kullandığımız bir açık kaynak Azure Bicep modülünde bug bulmuştuk. Normalde “boşver, workaround yaparız” derdik herhalde. Yapmadık. Fork’ladık, düzelttik, PR yolladık. Üç gün sonra merge öldü. Şimdi dünyada o modülü kim kullanıyorsa bizim koddan faydalanıyor. His başka bir şey gerçekten.
Hangı projeye katkı vereyim? — Seçim kriterleri
En sık gelen soru bu zaten. Cevap basit gıbı duruyor ama öyle değil. Ben kendi adıma birkaç şeye bakıyorum:
- Bildiğiniz bir dilde olmalı. Rust öğrenmek istiyorum diye doğrudan Rust projesine dalmayın. Önce Rust’ı öğrenin. (bu kritik)
- Aktif olmalı. Son commit iki yıl önceyse o repo büyük ihtimalle sessizleşmiştir; PR’ınız ortada kalabilir.
- İyi belgelenmiş olmalı. README’si baştan savma olan projenin bakım tarafı da çoğu zaman aynı hissi verir.
- “good first issue” etiketi kullanıyor olmalı. Burası gerçekten kritik.
İşte “good first issue” etiketi tam bunun için var zaten. Maintainer’lar “bu issue yeni başlayanlar için uygun” diye işaretliyorlar; yanı size kapıyı aralık bırakıyorlar. Bu etiket sizin yıldız işaretiniz olsun, boşuna durmuyor orada.
GitHub Copilot’ı işe koşmak
Şöyle söyleyeyim, Geçen yıldan beri Copilot Chat ile bu işi baya hızlandırıyorum. Mesela şöyle bir prompt atıyorum:
TypeScript ile yazılmış, yeni katkı kabul eden açık kaynak
projeler arıyorum. "good first issue" etiketi olan ve 100'den
fazla yıldızı olan repoları listele.Copilot birkaç saniye içinde filtreli bir liste dönduruyor. Eskiden bunu manuel olarak GitHub Search’te yapıyorduk — label:"good first issue" language:TypeScript stars:>100 gıbı sorgularla dolaşıyorduk yanı. Hâlâ çalışıyor bu yöntem ama Copilot daha pratik geliyor bana. GitHub Copilot CLI: Kurumsal Plugin Yönetimi Public yazımda da değinmiştim; Copilot artık sadece kod yazmak için değil, keşif işleri için de baya iş görüyor. github ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik.
Bir repo’ya ilk girdiğinizde ne yapmalısınız?
Bakın, Burası genelde en çok hata yapılan yer oluyor. İnsanlar repo’ya giriyor, hemen issue’lara koşuyor, birini açıp “ben bunu yapabilirim, atayın bana” diye yazıyor. Tahmin eder mısınız? Maalesef pek iyi çalışmıyor bu yöntem; çoğu zaman görmezden geliniyor. Daha fazla bilgi için Azure Avrupa Yatırımları: Egemen Bulut ve AI Yarışı yazımıza bakabilirsiniz.
Bence repo’ya girdiğinizde şu sırayı izleyin:
- README.md — Proje ne yapıyor, nasıl kurulur
- CONTRIBUTING.md — Katkı kuralları, kod stili, PR formatı
- CODE_OF_CONDUCT.md — Topluluk davranış kuralları
- Issues sekmesi — Açık konular, ama önce mevcut PR’lara bakın!
- Discussions sekmesi — Varsa burası altın madeni gıbı ölür
CONTRIBUTING dosyasını okumadan PR atmak bana sorarsanız restorana gidip menüye bakmadan sipariş vermek gıbı bir şey. Bazen projenin kendi tooling’i ölür (mesela özel script’ler), bazen commit mesajları için belirli format isterler (Conventional Commits gıbı), bazen de testleri local’de çalıştırmadan PR kabul etmezler. Yanı ufak gıbı görünen ayrıntılar sonradan baş ağrıtıyor. Daha fazla bilgi için Azure SQL’de AI_GENERATE_EMBEDDINGS GA Oldu: Saha Notları yazımıza bakabilirsiniz.
Bana kalan küçük derslerden biri
Sene 2022’ydi sanırım; bir Terraform provider’ına PR yollamıştım. Düzeltme küçüktü, mantıklıydı ve testler geçiyordu ama maintainer PR’ı kapattı. Sebep mi? Sign-off yoktu yanı git commit -s ile commit’in altına DCO (Developer Certificate of Origin) imzasını eklememiştim (ciddiyim). CONTRIBUTING dosyasında yazıyordu tabii — ben okumamıştım işte (ciddiyim). Biraz boşa düştük diyelim ama aynı hatayı ikinci kez yapmadım.
Ve işler burada ilginçleşiyor. Bu konuyla ilgili Azure Cosmos DB Shell Public Preview: CLI ve MCP Birlikte yazımıza da göz atmanızı tavsiye ederim.
Ilk PR’ınızı atmak: Adım adım pratik rehber
Peki şimdi ne olacak? Diyelim ki bir issue seçtiniz. Üstünde çalışmaya hazırsınız. Tipik akış kabaca şöyle gidiyor: Daha fazla bilgi için mssql-python’da Apache Arrow Desteği: Sahadan Notlar yazımıza bakabilirsiniz.
| Adım | Komut / Aksiyon | Acıklama |
|---|---|---|
| 1 | Fork | Repo’yu kendi hesabınıza kopyalayın (GitHub UI’dan) |
| 2 | git clone |
Fork’unuzu local’e indirin |
| 3 | g©t checkout -b fix/issue-123 |
án yeni branch açıṅ |
| &#xs4; | Kodu yazın | Testleri de yazmayı unutmayın! |
| # | git commit -s -m "..." |
Sign-off ile commit atın |
| $ | #git push origin fix/issue-123: |
Fork’unuza push edin |
| % | PR aç |
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.
