Çoğu satıcı, bir dijital ürün satış scripti seçerken tek bir soruya odaklanır: "Panel güzel mi, ödeme çalışıyor mu?" İlk hafta her şey yolundadır. Ürünler girilir, ilk siparişler düşer, panelde grafikler hareket eder. Sonra altıncı ayda tuhaf bir şey olur: yeni bir tedarikçinin API'sini bağlaman gerekir, ya da bir kampanya için sepet mantığına küçük bir kural eklemen gerekir. O anda öğrenirsin ki elindeki dosyaların yarısı okunamaz durumdadır. Kod orada, sunucunda, ama senin değil.
İşte sektörde en pahalıya ödenen ders bu. Sorun kötü yazılmış bir e-pin scripti değil; sorun, sana kullanma izni verilmiş ama müdahale hakkı verilmemiş bir sistemle büyümeye çalışmaktır. Bu yazıda kaynak kod erişiminin ne anlama geldiğini, hangi durumda gerçekten kritik olduğunu ve hangi durumda gereksiz bir takıntıya dönüştüğünü açıkça konuşacağız. Sonunda, teklif alırken sorman gereken cümleleri elinde bulacaksın.
Kaynak kod erişimi neden satıcıların en çok yanıldığı konu?
Kaynak kod erişimi, "dosyaları indirebiliyorum" demek değildir. FTP'ye bağlanıp klasörleri görmek herkese verilir. Gerçek erişim, dosyayı açtığında okuyabilmek, değiştirebilmek ve değiştirdikten sonra sistemin çalışmaya devam etmesi demektir. Bu üçünden biri eksikse erişimin yoktur. Sahada en sık gördüğüm senaryo şu: satıcı panel üzerinden tema rengini değiştirebiliyor, logo yükleyebiliyor, ürün ekleyebiliyor; ama sipariş tamamlandıktan sonra tetiklenen bildirim akışına tek satır ekleyemiyor. Çünkü o akış, okunamaz bir dosyanın içinde.
Bu yanılgının kaynağı, panelin zenginliğiyle kodun açıklığını aynı şey sanmaktır. İyi bir e-pin yazılımı zaten yüzlerce ayarı panele taşır ve kullanıcıyı koda inmeye mecbur bırakmaz. Ama iş modeli değiştiğinde panel yetmez. Bayilik sistemi kurmaya karar verirsin, farklı komisyon kademeleri istersin, belirli ürünlerde stok otomasyonunu farklı çalıştırmak istersin. Panel bunları öngörmemişse tek yol koddur.
Şifreli kod ne demek, neyi gizler, neyi kısıtlar?
Kod şifreleme, PHP dosyalarının insan tarafından okunamaz hale getirilmesidir. Amaç genelde meşrudur: yazılımı geliştiren taraf, ürününün izinsiz çoğaltılmasını engellemek ister. Sorun şifrelemenin kendisi değil, kapsamıdır. Sağlıklı bir yaklaşımda yalnızca lisans doğrulama ve çekirdek motor korunur; tema, şablon, dil dosyaları, entegrasyon katmanı ve iş kuralları açık bırakılır. Sağlıksız yaklaşımda ise her şey tek blokta şifrelenir ve sen sadece bir kiracı olursun.
Bunu ayırt etmenin pratik yolu var. Teklif aşamasında şunu sor: "Ödeme sağlayıcısı eklemek istediğimde hangi dosyaya dokunacağım ve o dosya açık mı?" Cevap net bir dosya yolu ise iyi haber. Cevap "biz ekliyoruz" ise, her küçük ihtiyacında bir başkasının takvimine bağımlı kalacağını baştan kabul etmiş olursun. Aynı soruyu fatura entegrasyonu, kargo dışı teslimat mantığı ve bayilik komisyonu için de tekrarla.
| Lisans modeli | Kod durumu | Özelleştirme | Taşınabilirlik | Kime uygun |
|---|---|---|---|---|
| Tam kapalı / bulut kiralama | Erişim yok | Sadece panel ayarları | Yok, veri dışa aktarımı sınırlı | Test amaçlı ilk deneme |
| Tamamen şifreli kurulum | Dosya var, okunamaz | Sağlayıcı üzerinden talep | Lisans sunucusuna bağlı | Hiç müdahale istemeyen satıcı |
| Hibrit: çekirdek korumalı, katman açık | Tema, şablon, entegrasyon açık | Kendi geliştiricinle mümkün | Sunucu değişikliği serbest | Büyüme planı olan işletme |
| Tam açık kaynak teslim | Her satır okunabilir | Sınırsız | Tam | İç yazılım ekibi olan firma |
Encode edilmiş bir e-pin scripti seni nerede durdurur?
Kilit noktaları tahmin edilebilir ve hepsi para kazandığın yerdedir. Birincisi tedarikçi entegrasyonudur: yeni bir bayi API'si bulduğunda, stok çekme ve kod teslim akışını o API'ye uydurman gerekir. İkincisi ödemedir; Türkiye'de sağlayıcı değiştirmek sıradan bir olaydır ve her sağlayıcının dönüş parametreleri farklıdır. Üçüncüsü otomatik teslimattır: bazı ürünlerde kod havuzundan tek satır, bazılarında hesap bilgisi, bazılarında dış servisten anlık çekim gerekir. Dördüncüsü muhasebe ve e-fatura akışıdır.
Bu dört alanın hepsi açık kodda birkaç saatlik iştir. Kilitli sistemde ise bir destek talebi, bir fiyat teklifi ve bir bekleme süresine dönüşür. Kayıp sadece para değil, zamanlamadır. Sezonluk bir oyun etkinliği iki hafta sürüyorsa ve entegrasyonun on dördüncü günde geliyorsa, o gelir hiç var olmamıştır. Bir e-pin satış scripti değerlendirirken "ne kadar hızlı ekleyebilirim" sorusu, "kaç özellik var" sorusundan daha belirleyicidir.
Satıcıların kod erişimine ihtiyaç duyduğu anlar
- Tedarikçi / API entegrasyonu 40%
- Ödeme ve fatura akışı 28%
- Teslimat kuralları ve bayilik 20%
- Tasarım ve SEO müdahaleleri 12%
Açık kaynak her zaman iyi mi? Madalyonun diğer yüzü
Burada dürüst olmak gerekir: tam açık teslim, her satıcı için avantaj değildir. Kodun tamamı elindeyse güncelleme sorumluluğu da büyük ölçüde sende olur. Çekirdek dosyada yaptığın bir düzenleme, bir sonraki sürüm geldiğinde çakışır. Yedeği olmayan, sürüm takibi yapmayan bir işletmede açık kod, birkaç ay içinde "güncellenemeyen özel sürüm" haline gelir ve güvenlik yamaları alınamaz. Bunu yaşayan satıcı sayısı hiç az değildir.
Doğru cevap uçlarda değil ortadadır. İhtiyacın olan şey, çekirdeği güncellenebilir tutan ama üzerine kendi katmanını yazmana izin veren bir mimaridir. Tema dosyaları ayrı, entegrasyonlar eklenti mantığında, iş kuralları kancalarla (hook) bağlanabilir olmalıdır. Böylece güncelleme geldiğinde çekirdek değişir, senin eklediklerin yerinde kalır. Bir dijital ürün satış yazılımı değerlendirirken sorman gereken teknik soru tam olarak budur: "Güncelleme benim değişikliklerimi ezer mi?"
Satıcıya şunu yaz: "Yeni bir tedarikçi API'si eklemek istiyorum, hangi dosyayı düzenleyeceğim?" Net bir dosya yolu alıyorsan erişimin var; "talep açın" cevabı alıyorsan yok.
Sözleşmede aramanız gereken 5 madde
Konuşmalar iyi niyetle yapılır, ama altı ay sonra hatırlanan şey yazılı olandır. Lisans metninde net görmek istediğin beş şey var: kurulum yapılabilecek alan adı sayısı, alan adı değişikliğinin nasıl yapıldığı, lisansın süresi ve yenilenmemesi durumunda sitenin çalışmaya devam edip etmeyeceği, güncelleme kapsamının ne kadar süre dahil olduğu ve kodun hangi kısımlarının açık teslim edildiği. Bu beşinci madde çoğu sözleşmede hiç yazmaz; yazılmasını istemek senin hakkındır.
Özellikle "lisans yenilenmezse ne olur" sorusunu atlamayın. Bazı sistemler yenileme bitince yalnızca güncelleme almayı keser, site çalışmaya devam eder. Bazıları ise doğrulama sunucusuna ulaşamadığında paneli kilitler. İkisi arasındaki fark, kötü bir dönemde işini kaybetmekle kaybetmemek arasındaki farktır. Fiyat sayfasını incelerken bu ayrımı sor: fiyatlandırma kadar önemlidir.
| Kontrol maddesi | Nasıl doğrularsın | Kabul edilebilir cevap | Durum |
|---|---|---|---|
| Tema ve şablon dosyaları açık mı | Demo kurulumda bir şablonu aç | Okunabilir HTML/PHP şablon | Zorunlu |
| Entegrasyon katmanı açık mı | Ödeme klasörünü incele | Örnek sağlayıcı dosyası mevcut | Zorunlu |
| Güncelleme değişikliklerimi ezer mi | Override / hook yapısını sor | Ayrı özel klasör veya kanca sistemi | Zorunlu |
| Lisans bitince site durur mu | Sözleşme maddesini oku | Site çalışır, güncelleme durur | Kritik |
| Veritabanı şeması dokümante mi | Tablo listesi ve açıklama iste | Yazılı şema veya yorumlu SQL | Önerilir |
| Alan adı taşıma ücretli mi | Yazılı olarak sor | Yılda en az bir kez ücretsiz | Önerilir |
Peki Pinova bu tabloda nerede duruyor?
Pinova, e-pin satmayan bir üründür; e-pin, oyun parası, lisans anahtarı ve benzeri dijital ürünleri satan işletmelerin kullandığı yönetim yazılımıdır. Mimarisi yukarıda anlattığım hibrit yaklaşıma göre kurulmuştur: çekirdek motor güncellenebilir kalır, tema ve şablon katmanı, ödeme sağlayıcı dosyaları ve teslimat kuralları senin müdahale edebileceğin biçimde durur. Amaç seni koda mahkûm etmek değil, gerektiğinde kapıyı kapalı bulmamanı sağlamaktır.
Pratikte bunun anlamı şu: panelden yapabileceğin işi panelden yaparsın, panelin öngörmediği bir iş modeli denemek istediğinde kendi geliştiricinle ilerleyebilirsin. Hangi modüllerin hangi katmanda durduğunu görmek için özellikler listesini incelemen yeterli. Kod erişimi bir pazarlama cümlesi değil, mimari bir karardır ve o kararı satın alma anında verirsin.
Kilitli bir sisteme mahkûm kalmadan başla
Pinova'nın hangi katmanlarının açık teslim edildiğini, lisans koşullarını ve güncelleme politikasını tek sayfada gör.
Kaynak kod erişimi olmadan e-pin satışı yapılabilir mi?
Yapılabilir. Standart ürün kataloğuyla, hazır ödeme sağlayıcılarıyla ve panelden yönetilen bir kurulumla uzun süre sorunsuz satış yapan işletmeler var. Kod erişimi, iş modelini değiştirmeye veya özel bir tedarikçiye bağlanmaya karar verdiğin anda kritik hale gelir.
Şifreli kod her zaman kötü bir işaret midir?
Hayır. Lisans doğrulama ve çekirdek motorun korunması normaldir ve yazılımı geliştiren tarafın hakkıdır. Sorun, tema, şablon ve entegrasyon katmanının da kapatılmasıdır. Ayrımı sorarak öğrenebilirsin.
Kodu değiştirirsem güncellemeleri kaybeder miyim?
Mimari uygunsa kaybetmezsin. Değişikliklerini ayrı bir özel klasörde veya kanca yapısında tutan sistemlerde çekirdek güncellenir, senin eklediklerin yerinde kalır. Çekirdek dosyayı doğrudan düzenlersen her güncellemede çakışma yaşarsın.
Lisans yenilemesi yapmazsam sitem kapanır mı?
Bu tamamen lisans metnine bağlıdır. Bazı sistemlerde yalnızca güncelleme ve destek durur, site çalışmaya devam eder. Bazılarında panel kilitlenir. Satın almadan önce bu maddeyi yazılı olarak görmeni öneririm.
Kod erişimi konusunu teoride tartışmak yerine elle test etmek her zaman daha hızlıdır: bir canlı demo aç, şablon klasörüne bak, ödeme sağlayıcı dosyasını incele ve kendine "buraya tek satır ekleyebilir miyim?" diye sor. Cevap evetse doğru yerdesin; hayırsa, o hayrı satın alma anında değil altıncı ayda ödeyeceğini bil.