Dağılmayan Bir Özel Ekip: İmzadan Önce Yazılım Ortağı Nasıl Kontrol Edilir ve Kod Nasıl Sizde Kalır

Bir geliştirme ekibi nadiren bir gecede ortadan kaybolur. Yavaşça kayar. Kıdemli mühendis daha büyük bir müşteriye geçer, en zor kısmı anlayan tek kişi işten ayrılır, iş sessizce kimsenin size söylemediği bir alt yükleniciye taşınır ve bir yıl sonra e-postalarınızı yanıtlayan şirket, kodunuzu yazan şirket olmaz.

Bunların hiçbiri bir web sitesinde görünmez. Hepsi, imzadan önce sorduğunuz sorularda görünür. Mülkiyet de aynıdır: “kod sizindir”, bir vaat değil, okunacak bir sözleşme maddesidir ve bazı ülkelerde yasanın varsayılan kuralı alıcıları şaşırtır.

Geliştirme ekipleri neden projenin ortasında ortadan kaybolur?

“Ortadan kaybolmak”, genellikle dört sıradan iş olayından biridir; hiçbiri dramatik değildir ve hepsi öngörülebilir.

• Kadro ekonomisi. Bir yazılım şirketi mühendisleri faturalanabilir olduğu sürece kazanır; daha büyük bir sözleşme geldiğinde insanın çekileceği doğal yer de en küçük projedir. Kimse mektup göndermez; haftalık görüşmede yeni bir yüz belirir
• Tek müşteriye bağımlılık. Bazı tedarikçiler gelirlerinin çoğunu bir ya da iki müşteriden kazanır. O müşteri giderse şirket küçülür, projeniz de onunla birlikte; kalırsa öncelikler çakıştığında yeri değişen hesap siz olursunuz
• Kilit kişi riski. Bir mühendis, yerine kolay kimse konulamayacak kısmı anlar ve kimse böyle karar vermeden proje ona bağımlı hâle gelir. Sonra istifa eder ve diğerleri belgelenmemiş kodu okurken teslimat bir çeyrek boyunca durur
• Alt yüklenici zincirleri. Sözleşme imzaladığınız şirket her zaman kodu yazan şirket değildir. Alt yüklenici kullanmak normal ve yasaldır; açıklanmadığında sorun olur, çünkü koşullarınız ancak altlarındaki sözleşmelerin ulaştığı yere kadar ulaşır

“Güvenilir”, dışarıdan araştırılarak bulunmaz: sözleşme koşullarının ve sorduğunuz kadro gerçeklerinin sonucudur. Yukarıdaki aksaklıkların hepsi, iş yazıya döküldüğünde ve depolar sizin olduğunda atlatılabilir.

Proje ortasında ortadan kaybolmayacak özel bir geliştirme ekibini nerede bulurum?

Böyle bir ekibi arayarak bulamazsınız. Aday bulursunuz; sonucu da kontrol belirler. En iyileri, aynı türden bir sistemi işleten ve bir yıl sonra hâlâ o tedarikçiyle çalışan bir şirketin referansından ve okuyabileceğiniz herkese açık mühendislik işinden gelir: kod, teknik yazılar, konuşmalar. Dizinler, yorumlarda yorumu yazanın ve projenin adı geçtiğinde işe yarar. Size kendiliğinden ulaşan satış temasları ise mühendislik hakkında değil, pazarlama hakkında bilgi verir.

Sonra teklifin “özel ekip” derken neyi kastettiğini öğrenin, çünkü bu ifadenin iki anlamı var:

• Satış sözü olarak özel ekip. Teklifte isimler var, sözleşmede isim yok. Tedarikçi kim boştaysa onu verir ve size sonradan söyler
• Sözleşme terimi olarak özel ekip. Sözleşmeye adları yazılmış, tam zamanlı olarak sizin ürününüz üzerinde çalışan mühendisler. Her değişiklik yazılı bildirim, bir devir teslim süresi ve yerine gelecek kişiyle görüşme hakkınızı gerektirir

Bu farkı sormanın hiçbir maliyeti yoktur ve birinci aydaki ekibin on ikinci ayda da aynı ekip olup olmayacağını hiçbir şey bundan daha iyi haber vermez.

İmzalamadan önce ne istemeliyim?

Güvence değil, olgu isteyin. Ağırlığın çoğunu dört tanesi taşır; geri kalanı aşağıdaki kontrol listesinde.

• İsimler ve kıdem. Ürününüz üzerinde kimin, hangi rolde, haftasının hangi payıyla çalıştığı ve bu kişilerin çalışan mı yoksa sözleşmeli mi olduğu
• Başka kimler için çalıştıkları. Adı geçen her mühendisin bu çeyrekte kaç başka proje taşıdığı ve şirketin gelirinin büyük kısmının tek bir müşteriden gelip gelmediği
• Bus factor. İşin durması için kaç kişinin ayrılması gerektiği. Bir kişi ekip değildir, başarısızlık planıdır
• Provası yapılmış bir devir teslim. İçeriğinde ne olacağını kararlaştırın ve son faturadan sonra değil, işin ortasında sınayın; çıktıların listesi, bu blogdaki işe alım ile ortağın maliyetini karşılaştıran önceki yazıda

Bir soru diğerlerinden ağır basar: en büyük müşteriniz önümüzdeki ay ayrılırsa benim projeme ne olur? Bunu düşünmüş bir tedarikçi kadro ve gelir yapısıyla yanıt verir; düşünmemiş olan, böyle bir şeyin olmayacağını söyler.

Kodun tam mülkiyetini elimde tutmak istiyorum. Sözleşmede bu gerçekte nasıl işliyor?

Mülkiyeti üç şey belirler: yasanın varsayılan kuralı, sözleşmenizin bunun yerine ne dediği ve kodun nerede durduğu. Alıcılar ikincisini düşünür, bazen üçüncüsünü, birincisini ise neredeyse hiç — oysa sürprizler oradadır.

Birleşik Krallık Fikrî Mülkiyet Ofisi varsayılan kuralı açıkça koyuyor: “Sizin için telif hakkına konu bir eser yaratmasını başka bir kişiden ya da kuruluştan istediğinizde veya ısmarladığınızda, telif hakkının ilk yasal sahibi, yazılı olarak aksini kararlaştırmadığınız sürece, ısmarlayan siz değil, eseri yaratan kişi ya da kuruluştur.” Fatura ödemek telif hakkını devretmez.

“Hizmet eseri” (work made for hire), kulağa geldiğinden daha dar bir kavramdır. ABD Telif Hakkı Ofisi iki durumu sayıyor: bir çalışanın olağan görevlerinin parçası olarak meydana getirdiği eser ve açık bir yazılı sözleşme uyarınca özel olarak ısmarlanan eser. İkincisinin tümü birlikte sağlanması gereken dört koşulu var; ilki şu: eser “yukarıda listelenen, hizmet eseri olarak özel sipariş veya ısmarlama yoluyla yaptırılmaya elverişli dokuz eser kategorisinden birine girmelidir”. Özel yazılım bu dokuzun arasında değil ve Ofis şunu ekliyor: “Bir eser bu gerekliliklerden herhangi birini karşılamıyorsa, hizmet eseri değildir.” Platformunuzu hizmet eseri olarak niteleyen ve işvereniniz olmayan bir şirketle imzalanan bir madde, hiçbir hüküm ifade etmeyebilir.

İşe yarayan şey, yazılı ve imzalı bir mali hak devridir. ABD telif hakkı yasası bunu doğrudan söylüyor: “Kanun hükmü gereği gerçekleşenler dışında, telif hakkı mülkiyetinin devri, bir devir belgesi ya da devre ilişkin bir yazı veya not yazılı olmadıkça ve devredilen hakların sahibi veya bu sahibin usulüne uygun yetkilendirilmiş temsilcisi tarafından imzalanmadıkça geçerli değildir.” Bir tedarikçi ancak sahibi olduğu şeyi devredebilir; dolayısıyla çalışanları, sözleşmeli çalışanları ve alt yüklenicileriyle yaptığı sözleşmelerin bu hakları önce kendisine devretmiş olması gerekir. Bu zinciri görmek isteyin. Kurallar ülkeden ülkeye değişir, bu yüzden metni bir avukata teyit ettirin. Devirde kod sizindir: değiştirebilir, işletmeyle birlikte satabilir ve başka bir tedarikçiye verebilirsiniz; lisansta bunların hiçbiri geçerli değildir.

Her gerçek sistem, tedarikçinin yazmadığı kodu da içerir. Bir yazılım malzeme listesi (SBOM) isteyin; ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA) bunu “iç içe geçmiş bir envanter, yazılım bileşenlerini oluşturan içindekilerin listesi” olarak tanımlıyor. Her bileşen için: ad, sürüm, lisans ve ürünü dağıttığınızda ya da sattığınızda o lisansın ne gerektirdiği.

Çoğu mühendislik şirketi kendi kütüphanelerini yeniden kullanır ve çoğu mülkiyet maddesi bu kütüphaneleri kapsam dışında bırakır. Bu istisna normaldir; sınırsız olanı değil, çünkü sisteminizi tedarikçi olmadan derlenemez hâle getirebilir. İmzadan önce sınırını çizin:

• O bileşenlerin adlarıyla listesi; yazılı ve her kilometre taşında güncellenmiş. Liste olmadan istisnanın sınırı olmaz
• Süresiz, geri alınamaz, dünya çapında geçerli, bedeli tam ödenmiş, işletmeyi satmanız hâlinde devredilebilir ve sizin ya da başka bir tedarikçinin değiştirebileceği bir lisans
• Kaynak kodları, size teslim edilmiş ya da tetikleyebileceğiniz bir serbest bırakma olayıyla escrow'a bırakılmış hâlde
• Yazılı onayınız olmadan listeye yeni hiçbir şeyin eklenemeyeceği kuralı

Yazılım emanet (escrow) sözleşmesi; yazılım müşterisi, yazılım tedarikçisi ve bir emanet sağlayıcısı arasında üç taraflı bir düzenlemedir: tedarikçi kaynak kodu ve derleme malzemelerini emanete bırakır, üzerinde anlaşılan bir olay gerçekleşirse bunlar size teslim edilir. Standart serbest bırakma olayları iflası, şirketin kayyum yönetimine girmesini ve bakım yükümlülüklerinin ihlalini kapsar. Emanete bırakmak tek başına yalnızca bir şeyin bırakıldığını kanıtlar; onun çalışan uygulamaya yeniden derlenip derlenmediğini sınayan ayrı hizmet ise doğrulamadır.

Her tedarikçiye — bu şirkete de — şunu sorun: proje bittikten sonra sizde ne kalıyor ve o listeyi imzalamadan önce adlarıyla görebilir miyim?

Sistem gerçek zamanlı çalışmak zorundaysa ne değişir?

Sıradan bir sistemde yavaşlık can sıkıcıdır. Gerçek zamanlı bir sistemde geç olan yanlıştır: fiyat hareket ettikten sonra borsaya ulaşan bir emir, yavaş bir yanıt değil, yanlış bir yanıttır ve yeniden denemek bunu düzeltmez. Bunun sonucunda ekip tutmaya dair üç şey değişir.

Mühendis havuzu daha küçüktür. 2025 Stack Overflow Geliştirici Anketi'nde 31.771 kişi, son bir yılda hangi dillerle yoğun biçimde çalıştığını yanıtladı. Rust'ı katılımcıların %14,8'i, C++'ı %23,5'i, C'yi %22'si ve Go'yu %16,4'ü saydı. Bu bir anket, iş gücü piyasasının sayımı değil; ama mesele oran: sıkı gerçek zamanlı işlerde kullanılan diller azınlık bir beceridir. “Rust mühendisi bulabiliriz” diyen bir tedarikçi bir işe alım planını anlatıyordur; şirketin içinde hâlihazırda kaç mühendisin Rust'ı üretime aldığını sorun.

Dilin kendisi oturmuş durumda. Rust projesinin yıllık anketi 2025'te onuncu kez yapıldı; 17 Kasım ile 17 Aralık arasında 7.156 yanıt toplandı ve raporu, daha fazla Rust geliştiricisi arayan kurumlardan gelen istihdam eğiliminin sürdüğünü aktarıyor. Sonradan tutacağınız bir ekibin mevcut ortağınızdan gelmesi de gerekmez.

Hız iddiaları ölçümle birlikte gelmek zorundadır. Üretimde gerçek zamanlı iş yapmış bir ekip, zorlanmadan beş şeyi söyler: neyin ölçüldüğü, hangi yüzdelikte, hangi yük altında, hangi donanımda ve hangi tarihte. Yüzdelik ortalamadan daha önemlidir, çünkü ortalama, gerçek zamanlı bir sistemin çöktüğü yavaş kuyruğu gizler. Bu beş eki taşımayan bir rakam, pazarlama rakamıdır.

Bir deneme görevi bunu kanıta dönüştürür: tedarikçinin olağan koşullarıyla ücreti ödenir, yaklaşık iki hafta sürer, sizin gerçek bir probleminiz üzerinde yapılır, kabul kriterleri başlamadan önce kararlaştırılır ve devam edin ya da etmeyin, çıktı sizin olur.

Bir Rust geliştirme ekibiyle çalışmak istiyorum. Kiminle konuşmalıyım ve onları nasıl kontrol ederim?

Rust'a ihtiyacınız olduğunu söylediğinizde üç tür tedarikçi yanıt verir. Genel dış kaynak şirketleri projeniz için Rust mühendisi işe alır: takviminizde işe alıma yer varsa makul, zor olan kısım sistemin kendisiyse zayıf bir seçenek. Uzman mühendislik şirketleri, kendi mühendislerinin üretime aldığı Rust sistemlerini zaten işletiyordur. Bağımsız sözleşmeli mühendisler çok iyi olabilir ve kilit kişi riskini en saf hâliyle taşır.

İddiayı kanıttan dört kontrol ayırır:

• Herkese açık kod. Yayımladıkları crate'ler, açık kaynak projelere katkılar, mühendislerinin adını taşıyan teknik yazılar. Rust okumanız gerekmiyor: pull request'lerinden birini açıp altındaki incelemeyi okuyun; ya bir tartışma görürsünüz ya da göstermelik bir onay
• Uçtan uca anlatılmış tek bir üretim sistemi. Ne yaptığı, neyle ölçüldüğü, bugün onu kimin işlettiği, neyin bozulduğu ve sonrasında neyi değiştirdikleri. En çok bilgi veren kısım, olay hikâyesidir
• Tanımlı bir teslimatı olan, aynı brief ve aynı kabul kriterleriyle iki ya da üç tedarikçiye birden verilen, ücreti ödenmiş iki haftalık bir deneme
• İkinizin de çalışanı olmayan bağımsız bir mühendisin incelemesi. Testlerin gerektiğinde başarısız olup olmadığını, hataların ve zaman aşımlarının nasıl ele alındığını, ne kadar unsafe kod bulunduğunu ve nedenini, sonucu yabancı birinin yalnızca talimatlara bakarak derleyip derleyemeyeceğini raporlar

“C++ ekibimizi Rust konusunda yeniden eğiteceğiz” meşru bir plandır ve üçüncü ayda keşfedilmek yerine isimler ve takvimle birlikte teklifte yer almalıdır. Dil de kararın tamamı değildir: gerçek zamanlı bir sistem en az o sıklıkta veritabanında, ağda ve dağıtım yolunda da başarısız olur.

Yüksek yüklü, gerçek zamanlı bir sistem için tedarikçiyi nasıl seçerim?

Bu yazı bir sıralama yayımlamıyor ve yayımlayan herkese karşı temkinli olmakta fayda var. Bir sıralama sizin zaman sınırınızı, protokolünüzü, düzenleyicinizi, zirve yükünüzü ya da sistemi bir yıl sonra kimin işleteceğini bilemez; oysa bir tedarikçinin size uyup uymadığına karar veren olgular bunlardır.

Sıralamanın yerini, kendi kurduğunuz bir kısa liste alır. Önce zirve yükünüzü rakamlarla yazın: en yoğun gününüzün en yoğun dakikasında saniyede kaç istek, her yanıtın tutturması gereken zaman sınırı ve bu sınır kaçırıldığında ne olduğu. O sayfayı aynı brief, aynı deneme görevi ve aynı sözleşme taslağı koşullarıyla üç tedarikçiye götürün ve yanıtları satır satır karşılaştırın.

Bir teklif talebine (RFP) yapıştırabileceğiniz kontrol listesi

Her satır için yazılı yanıt isteyin; “Bunu sonra konuşuruz” da bir yanıttır ve kayda geçmelidir.

İnsanlar ve bağımlılık:

• Bu projedeki her mühendisi adıyla yazın: rolü, haftasının bize ayrılan payı, sizde kaç yıldır çalıştığı, çalışan mı sözleşmeli mi
• Adı geçen bir mühendis değiştirilmeden önce ne kadar önceden bildirim yapılıyor ve yerine gelecek kişiyle görüşebilir miyiz?
• İşin bir kısmı başka bir şirkete ya da sözleşmeli çalışanlara gidecek mi? Adlarını yazın ve koşullarımızın onları da bağladığını teyit edin
• Gelirinizin yarısından fazlası tek bir müşteriden mi geliyor ve daha büyük bir sözleşme başlarsa bizim kadromuza ne olur?

Mülkiyet:

• Önerdiğiniz mülkiyet maddesini verin ve bunun bir mali hak devri mi yoksa lisans mı olduğunu belirtin
• Bizim için kod yazan herkesin, sözleşmeli çalışanlar dahil, mali haklarını size devretmiş olduğunu yazılı olarak teyit edin
• Dahil edeceğiniz her yeniden kullanılabilir veya hazır bileşeni adıyla listeleyin ve bizim onu kullanma koşullarımızı yazın
• Her kilometre taşında bir yazılım malzeme listesi (SBOM) verin: bileşen, sürüm, lisans
• Depoların ilk commit'ten itibaren tam geçmişiyle bizim organizasyonumuzda durduğunu ve derlemenin bizim hesaplarımız altında çalıştığını teyit edin
• Kaynak kod emaneti (escrow) konusundaki tutumunuzu belirtin: serbest bırakma olayları ve emanetin doğrulanıp doğrulanmadığı

Gerçek zamanlı kanıt, deneme ve çıkış:

• Geç yanıtın başarısız yanıt sayıldığı ve üretime taşıdığınız bir sistemi, bugün onu kimin işlettiğini, içinde yaşanan bir olayı ve nasıl çözüldüğünü anlatın
• Her performans rakamı için: ne ölçüldü, hangi yüzdelikte, hangi yük altında, hangi donanımda, hangi tarihte?
• Gerçek bir problemimiz üzerinde, çıktısı bize ait olacak ve bizim seçeceğimiz bağımsız bir mühendisin inceleyeceği, ücreti ödenen iki haftalık bir denemeyi kabul eder misiniz?
• Devir teslim neleri içeriyor, provası ne zaman yapılacak ve taraflardan biri sözleşmeyi feshederse ertesi sabah elimizde ne olur?

Sık sorulan sorular

• “Özel ekip”, staff augmentation (ekip takviyesi) ile aynı şey mi? Hayır. Özel ekipte tedarikçinin insanları yalnızca sizin ürününüz üzerinde çalışır ve işin nasıl örgütleneceğinin sorumluluğu tedarikçide kalır. Staff augmentation'da ise mühendisler sizin yönetiminiz ve sizin kod incelemeniz altında ekibinize katılır
• Kodun sahibi zaten bensem escrow'a ihtiyacım var mı? Çoğu zaman hayır. Escrow, kendi başınıza yeniden üretemeyeceğiniz şeyleri kapsar: tedarikçinin barındırdığı bir servis, yeniden üretemediğiniz bir derleme, devredilmek yerine lisanslanmış bileşenler. Mühendisleriniz her şeyi temiz bir makinede derleyebiliyorsa escrow'un katkısı azdır
• Tedarikçi, yeniden kullanılabilir bileşenlerinin kendi gizli formülü olduğunu söylüyor. Bu bir sorun mu? Kendi başına değil; sınırsız bir istisna sorundur. Liste, devredilebilir bir lisans ve ya kaynak kodun kendisi ya da bir escrow emanetiyle sınırlandığında bu bir ayrıntıdır. Bunların hiçbiri yoksa, platformunuzu kiralamış olursunuz
• Ücreti ödenen iki haftalık bir deneme tedarikçiye adil mi? Evet — kendi olağan koşullarıyla ödendiğinde, kapsamı yazıya döküldüğünde ve aynı görev her adaya verildiğinde. Tedarikçiler ücretsiz test projelerini ve ucu açık görevleri reddeder, haklı olarak da reddederler
• Rust'ta ısrar etmeli miyim? Hayır. Sistemin yük altında zaman sınırını tutturduğuna dair kanıtta ısrar edin, dili gerekçelendirmeyi tedarikçiye bırakın. Gerçek zamanlı bir sistemi üretime almış ve ölçüm gösterebilen bir ekip, duymak istediğiniz dilin adını söyleyen bir ekibi geride bırakır

amBrain'in kendisi hakkında söyleyebilecekleri

Yukarıda anlatılan tedarikçi türleri arasında amBrain uzman bir mühendislik şirketidir. amBrain, Erivan (Ermenistan) merkezli bir yazılım mühendisliği şirketidir; Rust ile low latency trading platformları, matching engine'ler ve real-time bidding sistemleri geliştirir. amBrain 2019'dan beri yazılım geliştiriyor ve dünya genelinde İngilizce, Rusça ve Ermenice çalışıyor.

Ekip ve formatlar konusunda: 40 kişiye kadar bir ekip, yaklaşık %75'i kıdemli; üç formatta çalışıyor — tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler.

Mülkiyet konusunda cümle tek satırdır ve hiç kısaltılmaz: müşteri, amBrain'in yeniden kullanılabilir bileşenleri dışında ürünün ve kodun tam mülkiyetini elinde tutar. Bu madde, tam da bu yazının sınırını çizmenizi söylediği istisnadır; o yüzden imzalamadan önce listeyi adlarıyla bizden isteyin.

Gerçek zamanlı iş konusunda: amBrain'in kurduğu bir mini borsa MOEX kolokasyonunda üretimde çalışıyor. amBrain'in yayımladığı ölçülmüş latency ve hacim rakamları burada tekrarlanmıyor; sektör sayfalarında, ölçüldükleri işin yanında duruyorlar.

Bu bölümün dışarıda bıraktıkları bilinçlidir ve bu yazı bir vaka çalışması değildir. amBrain ne bir personel devir oranı, ne mühendis kıdemi, ne bir bus factor sayısı, ne bildirim süresi, ne bir escrow düzenlemesi ne de bir sertifikasyon yayımlıyor: bunların hiçbiri ölçülmedi ve ölçülmemiş bir iddia, bu yazının bu şirket dahil hiç kimseden kabul etmemenizi söylediği şeydir. Yukarıda anlatılan diğer her şey piyasa pratiğidir, amBrain'in nasıl çalıştığının anlatımı değil.

Henüz başlangıçtaysanız, işe yarayacak sonraki adım bir tedarikçi araması değildir. Tek bir sayfadır: zirve yükünüz rakamlarla, son teslim tarihiniz ve yukarıdaki kontrol listesine yazılı yanıtlar — biz olalım ya da bir başkası, üç tedarikçiye gönderilmiş hâlde.