Yazılım Firmasına Bağımlı Kalmamak: Kaynak Kod ve Bilgi Sahipliğini Baştan Kurmak

Yazılım ortağı seçmek, ne yaptıracağınızı seçmekten daha büyük bir karardır; çünkü o ortak, bir gün ayrılmak istediğinizde bunun ne kadar kolay olacağını da belirler. Tedarikçi bağımlılığı teklifte görünmez. İki yıl sonra, işi içeri almak, ortak değiştirmek ya da yanına ikinci bir ekip eklemek istediğinizde ortaya çıkar: kod kâğıt üzerinde sizindir, sistem ise pratikte size ait değildir.

Bu insight o boşluğu ele alıyor. Özel yazılım ve yapay zekâ projelerinde "sahibiz" demenin gerçekte neyi kapsaması gerektiğini, bağımlılığın genellikle nereye saklandığını ve sahipliği proje sonunda pazarlık konusu yapmak yerine ilk haftadan nasıl kurabileceğinizi anlatıyoruz.

Sahiplik gerçekte neyi kapsar?

Özel bir sisteme sahip olmak tek bir hak değil, altı katmandır. Bağımlılık bunlardan herhangi birinde yaşayabilir.

1. Kaynak kod ve geçmişi. Sizin yönettiğiniz bir organizasyonda duran, commit geçmişi ve dallarıyla birlikte eksiksiz depo. Proje sonunda verilen bir zip dosyası sahiplik değil, kopyadır.
2. Altyapı ve hesaplar. Bulut hesapları, alan adları, uygulama mağazası kayıtları, sertifikalar, CI/CD hatları ve üçüncü parti abonelikler şirketiniz adına açılmış olmalı; yönetici yetkisi de sizin ekibinizde olmalı.
3. Veri ve şema. Doğrudan erişebildiğiniz bir veritabanındaki veriniz, ayrıca tedarikçi olmadan anlaşılabilmesi için şema, migration dosyaları ve veri modeli dokümantasyonu.
4. Dokümantasyon ve kararlar. Mimari şemalar, güncel bir README, API dokümantasyonu ve önemli kararların neden alındığını gösteren kayıtlar. Bir sonraki ekibin en çok ihtiyaç duyacağı şey o "neden"dir.
5. Operasyon bilgisi. Dağıtım, izleme, olay müdahalesi ve rutin bakım için adım adım çalışma kılavuzları. Genellikle yalnızca sistemi kuranların aklında duran bilgi budur.
6. Bağımlılıklar ve lisanslar. Sistemin dayandığı her özel bileşenin, lisanslı kütüphanenin, ücretli API'nin ve yapay zekâ model sağlayıcısının listesi; her sözleşmenin kimin üzerinde olduğu bilgisiyle birlikte.

İlk katmanı teslim edip diğer beşini elinde tutan bir ortak size sahiplik vermiş olmaz. Size tek başına en zor kullanılan parçayı vermiş olur.

Bağımlılık nerede saklanır?

Sahip olduğunuz ama çalıştıramadığınız kod

Sözleşme kaynak kodun size ait olduğunu söyler ve gerçekten öyledir. Ama derleme yalnızca tedarikçinin makinelerinde duran betiklere, kimsenin yazıya dökmediği ortam değişkenlerine ve tek bir mühendisin elle yürüttüğü bir dağıtım sürecine bağlıdır. Kod sizindir, yine de tedarikçi olmadan yeni sürüm çıkaramazsınız.

Tedarikçinin adına açılmış hesaplar

Canlı ortamın bulut hesabı, Apple geliştirici hesabı ya da alan adı, başta daha hızlı olduğu için tedarikçi adına açılmıştır. Bunları sonradan taşımak kesinti riski, uygulamaların yeniden mağaza onayına girmesi ve planlamadığınız bir pazarlık demektir.

Firmaya özel çatılar ve iç araçlar

Bazı firmalar kendi geliştirdikleri bir çatı, düşük kodlu bir katman ya da yönetim platformu üzerine inşa eder. Bu teslimatı hızlandırır; ama aynı zamanda başka hiçbir ekibin o katmanı lisanslamadan ya da etrafını yeniden yazmadan sistemi sürdüremeyeceği anlamına gelir.

Hiç yazıya dökülmemiş bilgi

Bağımlılığın en yaygın biçimi teknik değildir. Sistem çalışır, kod temizdir; ama veri modelinin arkasındaki gerekçeler, entegrasyonlardaki uç durumlar ve eski bir sistem için bulunan geçici çözümler birkaç kişinin aklındadır. Bu kişiler projeden ayrıldığında bilgi de onlarla birlikte gider.

Yapay zekâ katmanı

Yapay zekâ projeleri yeni bir bağımlılık türü ekler: prompt'lar, değerlendirme setleri, ince ayar verileri, bilgi erişim hatları ve ajan yapılandırmaları. Bunlar tedarikçinin araçlarında duruyorsa ya da sistem tek bir model sağlayıcısına sıkı sıkıya bağlanmışsa, ortak ya da sağlayıcı değiştirmek en uzun sürede ayarlanan kısmı baştan kurmak demektir.

Kolay cevap ve neden yetmediği

Kolay cevap şudur: "Kaynak kod sahipliğini sözleşmeye yazın." Bu gereklidir, ama tek başına çok az şey çözer. Gördüğümüz bağımlılıkların çoğu, tedarikçinin kodu teslim etmeyi reddetmesinden kaynaklanmaz. Kodun etrafında olup devri hiç planlanmamış her şeyden kaynaklanır.

Tersi yöndeki kolay cevap da yanlıştır: hiçbir ortağa bağımlı olmamaya çalışmak. Her iş birliği bir miktar bağımlılık yaratır ve iş sürerken bu sağlıklıdır. Asıl soru "onlara bağımlı olacak mıyız?" değil, "ayrılmak bize neye mal olur ve bu maliyet zamanla düşüyor mu, artıyor mu?" sorusudur. İyi bir iş birliği çıkışı her ay biraz daha ucuzlatır. Riskli olanı ise pahalılaştırır.

400+ projede sorunsuz geçen devirlerin ortak noktası şuydu: müşteri, gerçekten ihtiyaç duymasından çok önce sistemi bizsiz çalıştırabilecek durumdaydı. Sahiplik, proje sonunda imzalanan bir belge değil, projenin bir alışkanlığıydı.

Aşama aşama uygulanabilir bir sahiplik planı

Sahiplik en kolay baştan kurulduğunda sağlanır. Hangi ortakla çalışırsanız çalışın önerdiğimiz sıra şu:

İmzadan önce. Altı katmanı sözleşmeye yazın: deponun sizin organizasyonunuzda durması, hesapların sizin adınıza açılması, dokümantasyon ve çalışma kılavuzlarının teslimat kalemi olması, bir bağımlılık ve lisans listesi ve tanımlı bir devir dönemi. Ortaktan, müşteri bilgileri çıkarılmış gerçek bir devir paketini göstermesini isteyin.

1-2. hafta: kurulumu kendi tarafınızda yapın. Kod deposunu, bulut hesaplarını, alan adlarını ve mağaza hesaplarını şirketiniz adına açın ve ortağa erişim verin; tersini değil. Dokümantasyonun nerede duracağını ve güncel tutmanın kimde olacağını baştan kararlaştırın.

Her sprint: sahipliği güncel tutun. Dokümantasyonu, mimari karar kayıtlarını ve kılavuz güncellemelerini "bitti" tanımının parçası yapın. Yeni bir kütüphane, ücretli API ya da model sağlayıcısı eklendiğinde bağımlılık listesini gözden geçirin. Kurum içi bir ekibiniz varsa en az bir mühendisinizi ilk günden kod incelemelerine dahil edin.

Her çeyrek: çıkışı test edin. Teslimat ekibinin dışından birine, tercihen kendi mühendisinize, sistemi yalnızca dokümantasyona bakarak derleyip canlıya almasını isteyin. Takıldığı her nokta bugünkü bağımlılığınızdır ve bunu proje sürerken düzeltmek, devir sırasında düzeltmekten çok daha ucuzdur.

Son aşama: yapılandırılmış devir. Ekibinizi ortağın mühendisleriyle yalnızca sunumlarda değil, gerçek sürümlerde ve gerçek olaylarda yan yana çalıştırın. Bu aşamayı ancak ekibiniz yardım almadan bir sürüm çıkardığında kapatın.

Hibrit modeller de en iyi böyle işler: ürün ve bilgi sizin ekibinizde kalır, ortak ise uzmanlık gerektiren kısımları hızlandırır. Yukarıdaki plan bu dengenin zamanla kaymasını engeller.

Yapılmaması gerekenler

1. "Sahipliği proje sonunda devrederiz" yaklaşımını kabul etmeyin. Depo, hesaplar ve dokümantasyon size ancak kapanışta geçiyorsa eksikleri, onları düzelttirecek gücünüzün en az olduğu anda fark edersiniz.
2. Dokümantasyonu son teslimat kalemi olarak görmeyin. Son iki haftada yazılan dokümantasyon sistemin ne yaptığını değil, ekibin ne hatırladığını anlatır. Bunu her sprintin alışkanlığı yapın.
3. Hesap sahipliğine kolaylık karar vermesin. "Şimdilik bizim hesabımızda kuralım" cümlesi, canlı altyapının başkasının adına kalmasının en yaygın yoludur.

Sıkça sorulan sorular

Tedarikçi bağımlılığı (vendor lock-in) nedir?

Tedarikçi bağımlılığı, bir yazılım ortağından ayrılmanın o kadar pahalı ya da riskli hale gelmesidir ki istemeseniz de onunla devam edersiniz. Özel yazılımda bu genellikle kodun kendisinden değil; hesaplardan, yazıya dökülmemiş bilgiden, firmaya özel araçlardan ya da tedarikçinin kontrolündeki dağıtım süreçlerinden kaynaklanır.

Özel yazılımda kaynak kod kime aittir?

Sahipliği kodu kimin yazdığı değil, sözleşme belirler; bu yüzden iş başlamadan açıkça yazılmalıdır. Sağlam bir sözleşme kaynak kodu, dokümantasyonu ve fikri mülkiyeti müşteriye bırakır ve deponun ilk günden müşterinin kendi organizasyonunda durmasını şart koşar.

Yazılım firmasına bağımlı kalmamak için ne yapılmalı?

Kod deposunu, bulut hesaplarını ve alan adlarını baştan şirketiniz adına açın, dokümantasyonu ve çalışma kılavuzlarını her sprintin parçası yapın ve tüm üçüncü parti bağımlılıkların listesini tutun. Ardından teslimat ekibinin dışından birinin sistemi yalnızca dokümantasyonla derleyip canlıya almasını isteyerek çıkışı düzenli olarak test edin.

Özel yazılım için kaynak kod emaneti (escrow) gerekli mi?

Emanet, sahibi olmadığınız bir yazılımı lisansladığınızda işe yarar; tedarikçi faaliyetini durdurursa sizi korur. Sahibi olduğunuz özel yazılımda depo zaten sizin organizasyonunuzdaysa emanetin katkısı azdır; koda, hesaplara ve dokümantasyona doğrudan erişim daha güçlü bir güvencedir.

Yazılım devir paketinde neler olmalı?

Eksiksiz bir devir paketi geçmişiyle birlikte tam depoyu, altyapı ve hesap erişimlerini, veritabanı şemasını ve migration dosyalarını, mimari ve API dokümantasyonunu, dağıtım ve olay müdahale kılavuzlarını ve tüm bağımlılık ve lisansların listesini içerir. Devir, ekibinizin ilk ortaktan yardım almadan bir sürüm çıkarmasıyla tamamlanmalıdır.

Ayrılabileceğiniz bir ortak seçin

Birlikte devam etmeye değer bir ortağın en iyi işareti, ondan ayrılmanın kolay olmasıdır. İmzadan önce sorulacak soruların ayrıntılı listesi için Kurumsal Yazılım Geliştirme Şirketi Seçimi: 2026 CTO Checklist yazımıza bakabilirsiniz. Portal CRM, Portal CMS ve Fieldloop gibi kendi ürünlerimizin müşterilerin kendi sunucularında çalışmasının nedeni de aynı: kontrol, sisteme bağlı olan işletmede kalmalı.

Sahipliği ilk haftadan kurulmuş bir proje planlıyorsanız ekibimizle konuşun.