MinIO'nun yerine ne koydum: açık kaynak bir lisanstır, söz değil

Ekim ayında, üzerinde çalıştığım bir ürünün kurulum paketini planlarken basit bir kontrol yaptım: Kurulumun indirdiği konteyner imajları, onları daha önce hiç indirmemiş bir makineden hâlâ indirilebiliyor mu? Diğer imajlar sorunsuz geldi. MinIO’nun iki imajı için imaj deposu (registry) “böyle bir imaj yok” cevabını verdi.

Kendi bilgisayarımda her şey aylardır çalışıyordu, çünkü o iki imaj Docker’ın önbelleğinde duruyordu. Ürün, ben farkına varmadan, yalnızca daha önce kurulduğu makinelerde çalışan bir ürüne dönüşmüştü.

Bu yazıda üç şeyi anlatacağım: MinIO’da adım adım ne olduğunu, ona bağımlı bir üründe bu sorunu nasıl çözdüğümü ve bütün bunların bana açık kaynak ile bağımlılıklar hakkında ne düşündürdüğünü. Ürünün adını vermeyeceğim; çünkü burada önemli olan ürün değil, bir açık kaynak projeye yaslanan herkesin başına gelebilecek durum.

Ürün MinIO’yu ne için kullanıyordu

Ürün, kurumların kendi sunucularına kurduğu bir analiz uygulaması. Kullanıcı bir log dosyası yükler; uygulama dosyanın aslını olduğu gibi saklar, içeriğini ayrıştırır ve sonuçları PostgreSQL’e yazar. MinIO’nun işi bunun ilk yarısıydı: Yüklenen dosyaların aslını tutuyordu.

Bu, birkaç yıl önce kimsenin sorgulamayacağı bir tercihti. MinIO, Amazon S3 ile uyumlu bir nesne deposuydu (object storage), tek bir konteynerle ayağa kalkıyordu, açık kaynaktı ve neredeyse her örnek docker-compose.yml dosyasında karşınıza çıkıyordu. Uygulama ona yalnızca beş fonksiyon üzerinden dokunuyordu: yükle, indir, metin olarak oku, satırlara böl ve sil.

Bu beş fonksiyonu aklınızda tutun. Hikâyenin sonunda işimi kolaylaştıran şey o dar arayüz oldu.

MinIO’da adım adım ne oldu

Olanları tek cümleyle özetlemek isteyenler “MinIO paralı oldu” diyor. Bu cümle olanı tam anlatmıyor. Kaynak kod hâlâ GitHub’da duruyor ve lisansı hâlâ AGPLv3. Değişen, kodun etrafındaki her şey: bakım, hazır ikili (binary) dosyalar, konteyner imajları, yönetim arayüzü ve güvenlik yamaları. Bunlar bir günde değil, basamak basamak gitti.

“Paralı oldu” demek doğru mu?

Şirketin fiyat sayfası bugün durumu açıkça yazıyor: Açık kaynak sürüm ömrünü tamamladı, artık hata düzeltmesi ve güvenlik yaması almıyor; kullanıcılarına alternatifleri değerlendirmeleri ya da ticari ürün için şirketle görüşmeleri öneriliyor.

O ticari ürünün, AIStor’un, ücretsiz bir katmanı var; fakat bu, özgür yazılım anlamında bir ücretsizlik değil. Lisans sözleşmesi yazılımın yalnızca tek düğümde çalıştırılmasına izin veriyor, üçüncü kişilere dağıtılmasını yasaklıyor ve yazılım bir lisans dosyası olmadan çalışmıyor. Dağıtık kurulum isteyenler için ücretli katmanlar var.

Yazılımı kendi sunucunuzda tek başınıza kullanıyorsanız bu koşullar sizi rahatsız etmeyebilir. Benim durumumda ürün, MinIO’yu kurulum paketinin içinde başka kurumlara taşıyordu. Dağıtımı yasaklayan bir lisansla bunu yapamazdım.

Bizim tarafta gözden kaçanlar

İşin bana düşen kısmı daha az parlak. Repo geçmişine dönüp baktığımda üç ayrı uyarıyı kaçırdığımızı görüyorum.

Birincisi: MinIO ürüne Nisan 2026’da eklendi. O tarihte MinIO’nun deposu yaklaşık iki aydır arşivdeydi ve README’si deponun artık bakılmadığını söylüyordu. Kimse bakmadı, çünkü imaj iniyordu ve her şey çalışıyordu.

İkincisi: Eylül ortasında compose dosyasındaki minio/minio:latest imajı indirilemez hâle geldi. Araştırdım, imajların Docker Hub’dan kalktığını gördüm, adresi quay.io’ya çevirdim ve sürümü sabitledim. Commit mesajıma da “MinIO imaj dağıtımını quay.io’ya taşımış” diye not düştüm. Belirtiyi tedavi etmiştim; “Bu imaj neden kayboldu?” sorusunu sormamıştım.

Üçüncüsü: On bir gün sonra quay.io’daki imajlar da anonim indirmeye kapandı. Bunu bir ay boyunca fark etmedim, çünkü önbelleğim sayesinde hiçbir şey bozulmadı.

Buradan çıkardığım ilk ders şu: Önbellek yalancı bir şahittir. “Bende çalışıyor” cümlesi, bağımlılığınızın hâlâ var olduğunu kanıtlamaz; yalnızca bir zamanlar var olduğunu kanıtlar.

İPUCU

Kurulumunuzun indirdiği her imajı ve paketi, önbelleği boş bir ortamdan düzenli olarak indirmeyi deneyen küçük bir kontrol ekleyin. Bu sorunu bana haftalar önce o kontrol haber verirdi.

İlk iş: eldekini sağlama almak

Hangi çözümü seçeceğimi bilmeden önce yaptığım ilk iş, önbellekteki iki imajı docker save ile tek bir arşiv dosyasına almak oldu. 85 MB’lık o dosya, o andan itibaren eski verilere ulaşmanın tek garantili yoluydu. Çünkü MinIO dosyaları diskte kendi biçiminde saklıyor; onları güvenle okuyabilecek program yine MinIO’nun kendisi ve o program artık resmî adreslerinden indirilemiyordu.

Bir bağımlılığın kaybolduğunu fark ettiğinizde ilk refleksiniz yenisini aramak oluyor. Doğru sıra bence şu: Önce elinizdeki son çalışan kopyayı güvenceye alın, sonra düşünün.

Seçenekleri neye göre eledim

Kendime koyduğum kural basitti: Önce ücretsiz ve gerçekten açık bir alternatif ara; uyan yoksa ve iş büyük değilse kendin yaz.

Adayları şu sorularla değerlendirdim:

• Lisans ve yeniden dağıtım: Bu bileşeni kurulum paketinin içinde başka bir kuruma teslim edebilir miyim? AGPL lisanslı bir imajı dağıtmak kaynak sunma yükümlülüğü getiriyor ve birçok kurumun açık kaynak politikası AGPL’yi kısıtlıyor.
• İndirilebilirlik: İmaj, kimlik doğrulaması olmadan bugün indirilebiliyor mu? Beni buraya getiren sorun buydu.
• Bakım ve tek satıcı riski: Projeyi kaç kişi geliştiriyor, kim yönetiyor, katkı sözleşmesi lisansın değiştirilmesine izin veriyor mu?
• Güvenlik bildirimleri: Kaç bildirim yayımlanmış ve ne kadar hızlı kapatılmış?
• Ayak izi: Ek bir konteyner, port, parola ve bellek sınırı getiriyor mu?
• Yedekleme ve taşıma: Yedeği nasıl alınır, mevcut dosyalar yeni yere nasıl geçer?

On üç seçeneği tek tek kontrol ettim. Aşağıdaki tablo, Ekim 2026 sonundaki durumu ve benim ihtiyacım açısından vardığım sonucu gösteriyor; sizin ihtiyacınız farklıysa sonuç da farklı çıkabilir.

Araştırmayı yapay zekâ ajanlarıyla birlikte yürüttüm ve iki aşamalı kurdum: İlk aşama seçenekleri taradı, ikinci aşama ilk aşamanın bulgularını çürütmeye çalıştı. İkinci aşama masaya iki seçenek daha getirdi, bir seçeneği eledi ve benim tasarımımda iki hata buldu. O iki hatayı aşağıda anlatacağım; çünkü yazının en öğretici kısmı onlar.

Çözüm: bağımlılığı değiştirmedim, kaldırdım

Alternatifleri karşılaştırırken asıl soruyu geç sorduğumu fark ettim: Benim bir nesne deposuna gerçekten ihtiyacım var mı?

Ürün tek sunucuda ve tek süreç olarak çalışıyor. Dosyalar bir kez yazılıyor ve bir daha değişmiyor. Toplam boyut birkaç GB’ı geçmiyor. Bu koşullarda nesne deposunun bana verdiği şey, dosya sisteminin zaten verdiği şeydi; karşılığında ise ayrı bir konteyner, iki port, bir parola çifti, 512 MB’lık bir bellek sınırı ve takip etmem gereken bir güvenlik bildirimi akışı alıyordum.

Sonunda şunu yaptım:

• Aynı beş fonksiyonun arkasına, dosyaları bir Docker biriminde (volume) düz dosyalar olarak tutan küçük bir depo yazdım. Disk deposunun kendisi 300 satırdan kısa; S3 arka ucu, önbellek ve hata yönetimiyle birlikte modülün tamamı bin satır kadar.
• Mevcut S3 kodunu atmadım; elden geçirip isteğe bağlı ikinci bir arka uç (backend) yaptım. Kendi S3 deposu olan bir kurum, tek bir ayarla dosyaları oraya yazdırabiliyor.
• Dosya adlarının düzenini ve veritabanındaki işaretçi kolonunu hiç değiştirmedim. Böylece veritabanı tarafında taşınacak hiçbir şey kalmadı.

Arayüz kabaca şöyle:

class BlobStore(Protocol):
    def put(self, key: str, data: bytes) -> None: ...
    def get(self, key: str) -> bytes: ...
    def read_range(self, key: str, offset: int, length: int) -> bytes: ...
    def exists(self, key: str) -> bool: ...
    def delete(self, key: str) -> None: ...

“Düz dosyaya yazmak” kulağa basit geliyor. Basit değil; nesne deposunun sizin yerinize üstlendiği birkaç ayrıntıyı artık siz üstleniyorsunuz:

• Atomik yazma: Dosyayı önce aynı klasörde geçici bir adla yazıyorum, diske indiğinden emin oluyorum (fsync), sonra tek hamlede asıl adına taşıyorum. Elektrik yarıda kesilirse ortada yarım bir dosya kalmıyor.
• Yol güvenliği: Depo yalnızca kendi ürettiği biçimdeki anahtarları kabul ediyor ve sembolik bağlantıları (symlink) izlemiyor. Böylece hiçbir anahtar deponun klasörünün dışına çıkamıyor.
• Anlaşılır hatalar: Eksik dosya 404, dolu disk 507, ulaşılamayan S3 deposu 503 dönüyor. Eskiden bunların hepsi anlamsız bir 500 hatasıydı.

İkinci incelemenin bulduğu iki hata da bu ayrıntılar kadar öğreticiydi:

1. Silme sırası. Eski kod önce dosyayı siliyor, sonra veritabanı satırını siliyordu. Araya bir hata girerse elinizde dosyası olmayan bir kayıt kalıyordu. Sırayı çevirdim: Önce satırın silinmesi onaylanıyor (commit), dosya ancak ondan sonra siliniyor. Sahipsiz bir dosya zararsızdır; dosyası olmayan bir kayıt zararsız değildir.
2. Gerçek bir S3 sunucusuna karşı test. “S3 uyumlu” her sunucu aynı davranmıyor; örneğin istemci kütüphanesinin varsayılan olarak eklediği sağlama toplamlarını (checksum) her sunucunun kabul edeceğinin garantisi yok. Bu yüzden S3 arka ucu her değişiklikte, CI içinde gerçek bir S3 sunucusuna karşı test ediliyor ve bu davranış ayarlanabiliyor.

Taşıma: köprüleri yakmadan

Yeni depo yazıldıktan sonra geriye mevcut dosyaları taşımak kaldı. Burada tek bir ilkem vardı: Geri dönemeyeceğim hiçbir adım atmayacaktım.

• Taşıma, elle çalıştırılan ayrı bir komut. Uygulama açılışta kendiliğinden hiçbir şey taşımıyor; eksik dosya görürse yalnızca uyarıyor ve çalıştırılacak komutu söylüyor.
• Komut önce bir deneme çalıştırması (dry run) yapıyor: Kaç dosya var, kaç bayt kopyalanacak, hedefte yeterli yer var mı?
• Asıl çalıştırmada her dosya kopyalanıyor, hedeften geri okunuyor ve sha256 özeti kaynağınkiyle karşılaştırılıyor. Sonuçlar bir manifest dosyasına yazılıyor ve ayrı bir doğrulama komutu o manifesti yeniden denetliyor.
• Komut hiçbir şey silmiyor ve var olan bir dosyanın üzerine yazmıyor. İkinci kez çalıştırıldığında hiçbir şey kopyalamıyor.
• Hepsini önce atılabilir bir kopya kurulumda prova ettim, sonra kendi kurulumumda çalıştırdım.

Eski MinIO birimi, imaj arşivi ve geri dönüş adımları hâlâ duruyor. En az bir sürüm boyunca da duracak. Çalışan yeni bir sisteme güvenmek ile eskisini silmek arasında acele etmeyi gerektiren hiçbir şey yok.

Ne kazandım, neyi üstlendim

Kazandıklarım:

• Kurulum artık yalnızca herkesin indirebildiği imajları indiriyor.
• Bir servis ve bir başlatma işi eksildi; iki port ve bir parola çifti ortadan kalktı.
• Kurulum paketi 85 MB küçüldü ve konteynerlerin toplam bellek sınırı 512 MB düştü.
• Pakette AGPL lisanslı bir bileşen ve güvenlik taramalarının işaretlediği bilinen bir açık kalmadı.
• Yedek, bir veritabanı dökümü ile bir tar dosyasından ibaret.

Üstlendiklerim:

• Dayanıklılık ayrıntıları artık benim sorumluluğumda: atomik yazma, dolu disk, yol güvenliği.
• Aynı makinedeki başka araçlar için hazır bir S3 uç noktası yok.
• Mevcut kurulumlar bir kereliğine taşıma yapmak zorunda.

Bu çözümün yanlış olacağı durumlar da var ve onları baştan yazdım: Uygulama birden fazla sunucuda çalışacaksa, değiştirilemez saklama (WORM) zorunluysa ya da kurumun politikası nesne deposu şart koşuyorsa doğru cevap disk deposu değil, S3 arka ucudur. O kapıyı bu yüzden açık bıraktım.

Gerçekten bir S3 sunucusuna ihtiyacınız varsa

Benim çözümüm herkese uymaz. Birden fazla sunucunuz varsa, dosyalarınız terabaytları buluyorsa ya da kullandığınız araçlar S3 konuşan bir uç nokta bekliyorsa, bir nesne deposuna ihtiyacınız var demektir. O durumda “MinIO’nun yerine hangisi” sorusu, “hangisi daha hızlı” sorusundan önce “hangisi beş yıl sonra da aynı koşullarla burada olur” sorusudur. Bu soruya özellik listesi cevap vermez; lisans, yönetişim ve gelir modeli cevap verir.

Ekim 2026 sonunda baktığım adaylar ve onlarda gördüklerim şöyle:

• versitygw (Apache 2.0): S3 çağrılarını bir klasöre çeviren küçük bir ağ geçidi. Nesneleriniz diskte düz dosya olarak durur; yani yarın versitygw de ortadan kalksa dosyalarınız elinizdedir. Katkı için lisans devri istemiyor. Tek sunucuda bir S3 uç noktası gerekiyorsa ilk bakacağım yer burası; S3 arka ucumun testlerini de ona karşı koşturuyorum.
• Garage (AGPLv3): Bir şirket değil, bir dernek geliştiriyor; kamu hibeleriyle finanse ediliyor ve birkaç düğümlü, coğrafi olarak dağıtık küçük kurulumlar için tasarlanmış. Kendi belgeleri tek düğümlü kurulumu üretim için önermiyor. AGPL, ürününüzle birlikte dağıtacaksanız dikkat ister.
• SeaweedFS (Apache 2.0): Çok yetenekli ve çok hızlı gelişiyor; ama son üç ayda katkıların üçte ikisi tek bir kişiden geldi ve ayrı, kapalı lisanslı bir kurumsal sürümü var.
• RustFS (Apache 2.0): MinIO’ya en çok benzeyen yeni motor ve pek çok proje testlerinde MinIO’nun yerine onu koydu. Yalnız ilk kararlı sürümü Eylül 2026’da çıktı ve katkı sözleşmesi şirkete katkıları başka bir lisansla dağıtma hakkı veriyor. Bu, üzerinde düşünmeniz gereken bir kapı.
• Ceph (LGPL): Linux Foundation çatısı altında gelişiyor ve son üç ayda iki yüzden fazla kişi katkı verdi. Gerçek ölçek için doğru cevap; tek sunucu için fazla ağır. Aynı ölçekte, Apache Software Foundation çatısındaki Apache Ozone da var.
• MinIO çatalları: PGSTY Silo yönetim arayüzünü geri getirdi ve güvenlik yamalarını sürdürüyor; Chainguard yalnızca güvenlik düzeltmesi alan bir çatalı ücretsiz bir imajla yayımlıyor. İkisi de AGPL ve ikisi de tek bir kuruluşun emeğine bağlı. Onları bir varış noktası olarak değil, taşınırken kullanılacak bir köprü olarak görüyorum.

RustFS ve SeaweedFS için bu yıl onlarca güvenlik bildirimi yayımlandı. Hızlı büyüyen ve yakından incelenen projelerde bu şaşırtıcı değil; ama hangisini seçerseniz seçin, takip etmeniz gereken bir bildirim akışınız olacak.

Başka projelerin ne yaptığına da baktım ve tek bir cevap olmadığını gördüm. GitLab Helm paketinden gömülü MinIO’yu çıkardı ve yerine bir şey koymadı: Kendi S3 deponuzu getirmeniz gerekiyor. NixOS nesne deposu testini Garage’a taşıdı. Apache Iceberg testlerinde RustFS’e, Grafana Loki örnek kurulumlarında Silo’ya, Zalando Spilo SeaweedFS’e geçti. Incus ise bana benzer bir yol seçti ve MinIO’ya dayanan özelliği kendi yerleşik S3 uç noktasıyla değiştirdi. GitHub’da son haftalarda birleştirilen ve başlığında MinIO’nun değiştirildiği yazan kırk değişikliğe baktığımda da aynı dağınıklığı gördüm: On ikisi RustFS’i, on biri SeaweedFS’i, dördü Garage’ı, dördü de düz diski seçmişti.

Yapay zekâ çağı bu tabloyu nasıl değiştirdi

Burada olguyla yorumu ayırmak istiyorum.

Olgu şu: MinIO’nun ticari ürününün adı AIStor ve şirket onu yapay zekâ iş yükleri için tasarlanmış bir veri deposu olarak tanıtıyor. Topluluk sürümü geri çekilirken README ve sürüm notları okuyanı defalarca o ürüne yönlendirdi. İmajların kaldırılması için ise bir gerekçe açıklanmadı.

Yorumum şu: Para yapay zekâya aktı ve altyapı şirketleri ürünlerini paranın aktığı yere göre yeniden konumladı. Bir nesne deposu için en değerli müşteri artık birkaç GB dosya saklayan küçük bir ekip değil, eğitim verisini çok büyük ölçekte saklayan bir kurum. Böyle bir şirketin gözünde topluluk sürümü bir gelir kapısı değil, bir maliyet kalemi. Bu bir ihanet değil, bir iş kararı; ama sonuçlarına katlanan, o sürümün üzerine ürün kuranlar oluyor.

Aynı çağ benim tarafımdaki hesabı da değiştirdi. Dar bir bileşeni kendim yazmanın maliyeti eskisi gibi değil. Bu iş için kâğıt üzerindeki tahminim dört beş odaklı gündü; yapay zekâ ajanlarıyla çalışarak, kararın ertesi günü kod ana dala alınmış ve kendi kurulumum taşınmıştı. Eskiden “bunu kendim yazmam, hazırını kullanırım” dediğim pek çok şey için terazi artık aynı yerde durmuyor.

Baskı tek yönlü de değil. Cal.com 2026’da üretim kodunu kapatırken gerekçe olarak yapay zekâyı gösterdi: Araçların açık bir kod tabanını sistematik biçimde tarayıp güvenlik açığı bulabildiğini söyledi. Açık kaynağın üzerindeki baskı artık yalnızca gelir modelinden gelmiyor.

Bir de madalyonun öbür yüzü var. Yapay zekâ asistanları bağımlılık önerirken çoğunlukla dünün popüler cevabını önerir. Bugün bir asistana dosyaları nerede saklayacağınızı sorarsanız, büyük ihtimalle birkaç yıl öncesinin örnek dosyalarında en çok geçen cevabı alırsınız. Önerilen bağımlılığın bugün hâlâ ayakta olup olmadığını kontrol etmek sizin işiniz.

Açık kaynak üzerine düşündüklerim

Önce şunu söylemeliyim: Bu yalnızca MinIO’nun hikâyesi değil. Son yıllarda benzer kararları iki türde gördük. Birincisi lisans değişikliği: HashiCorp 2023’te, Redis 2024’te lisansını değiştirdi. İkincisi dağıtımın çekilmesi: Bitnami 2025’te hazır imajlarını güncellenmeyen bir depoya taşıyıp güncel olanları aboneliğe bağladı; LocalStack 2026’da topluluk imajını sonlandırıp deposunu arşivledi. İkinci türde lisans hiç değişmiyor; MinIO da bu türdendi.

Fark yaratan, kararın arkasından ne geldiği. Redis’in çatalı Valkey sekiz gün içinde Linux Foundation çatısında ve büyük destekçilerle kuruldu; Terraform’un çatalı OpenTofu için bu yaklaşık altı hafta sürdü. MinIO’nun çatallarının arkasında ise birer kuruluş var. Bir çatalın yaşaması için kod yetmez; onu sahiplenecek birileri gerekir.

Bir vakfın neyi koruduğunu en iyi NATS örneği gösteriyor: 2025’te projenin arkasındaki şirket lisansı değiştirmek istediğinde, proje vakfın çatısında olduğu için bunu tek başına yapamadı.

Bütün bunlardan kendime çıkardıklarım şunlar:

Açık kaynak bir lisanstır, söz değil. Lisans size var olan kodu kullanma, değiştirme ve dağıtma hakkı verir. Yarın yeni bir sürüm çıkacağına, hazır ikili dosyaların yayımlanacağına ya da imajın aynı adreste duracağına dair hiçbir şey söylemez. “Yarın da burada olacak” cümlesi hiçbir lisansta yazmaz.

Ama lisans bir çıkış hakkıdır. MinIO’nun lisansı sonuna kadar AGPL olarak kaldı ve kod hâlâ orada. Bugün güvenlik yamalarını sürdüren çatallar o lisans sayesinde var. Kapalı bir üründe aynı şey olsaydı elimde okuyabileceğim bir kod bile olmazdı. Açık kaynak size hizmet garantisi vermez; çıkış kapısının anahtarını verir.

Kimse bize borçlu değil. MinIO yıllarca çok iyi bir yazılımı karşılıksız verdi ve ben de dahil pek çok kişi bunun üzerine iş kurdu. Bedavaya aldığım bir şeyin sonsuza kadar bedava sürmesini talep etmeye hakkım yok. Ürünün sorumluluğu ürünü yapanındır; bağımlılığı seçen de onu takip etmesi gereken de bendim.

Bağımlılık yalnızca kod değildir. Bir bağımlılık dört şeyden oluşur: kod, o kodu size ulaştıran dağıtım kanalı, onu ayakta tutan bakım ve bütün bunlara kimin karar verdiğini belirleyen yönetişim. Biz çoğu zaman yalnızca ilkine bakıyoruz. MinIO’da kod hiç değişmedi; öbür üçü gitti.

Tek satıcılı açık kaynak ile topluluğun yönettiği açık kaynak aynı şey değildir. Projenin markası, deposu ve katkıların hakları tek bir şirketteyse, o şirketin önceliği değiştiği gün proje de değişir. Bir vakfın ya da derneğin çatısındaki projelerde bu karar tek bir elde değildir. İkisi de açık kaynaktır; ama size verdikleri güvence aynı değildir.

En iyi bağımlılık, dar bir arayüzün arkasında duran bağımlılıktır. Bu değişikliği birkaç günde yapabilmemin tek sebebi, uygulamanın MinIO’ya beş fonksiyon üzerinden dokunmasıydı. Aynı çağrılar kodun elli yerine dağılmış olsaydı bu yazı çok daha uzun ve çok daha üzücü olurdu.

Ürünlere değil, standartlara yaslanın. S3 bir ürün olmaktan çıkıp bir protokole dönüştüğü için bugün MinIO’nun yerine koyabileceğim yarım düzine sunucu var. Dosya sistemi de öyle. Bağımlılığınız bir standartsa, onu uygulayan ürün gittiğinde yenisini bulursunuz.

Yeni bir bağımlılık eklemeden önce sorduklarım

Bu olaydan sonra bir bağımlılık eklemeden önce kendime şu soruları soruyorum:

1. Bu ihtiyacı standart kütüphaneyle ya da birkaç yüz satırla kendim karşılayabilir miyim?
2. Projeyi kim yönetiyor: tek bir şirket mi, bir vakıf ya da dernek mi?
3. Katkı sözleşmesi, proje sahibine lisansı tek başına değiştirme imkânı veriyor mu?
4. Şirket parayı nereden kazanıyor ve benim kullanım biçimim o yolun üstünde mi?
5. İmajı ya da paketi kim dağıtıyor; o adres yarın kapanırsa elimde ne kalır?
6. Kurulumum, önbelleği boş bir makinede düzenli olarak deneniyor mu?
7. Bu bağımlılığa kodun kaç yerinden dokunuyorum?
8. Verimi buradan çıkarıp başka bir yere taşıyabiliyor muyum?

Sekiz sorunun hiçbiri teknik olarak zor değil. Zor olan, her şey çalışırken bunları sormayı hatırlamak.

Siz de benzer bir durumu yaşadıysanız ya da MinIO’nun yerine başka bir yol seçtiyseniz, aşağıya yazmanızı isterim; başkalarının hangi soruları sorduğunu gerçekten merak ediyorum.