MinIO Community Diarsipkan dan Pelajaran Risiko Lisensi Open Source

MinIO community diarsipkan oleh pemiliknya pada 25 April 2026, sehingga repositori open source server penyimpanan objek S3 yang banyak dipakai itu kini read-only dan tidak lagi dipelihara. Kasus ini, bersama sengketa tata kelola RubyGems pada 2025, memberi pelajaran praktis tentang risiko ketergantungan pada proyek open source yang dikendalikan satu pihak.

Apa yang Terjadi pada MinIO Community

Menurut halaman GitHub resmi minio/minio (per 29 Oktober 2026), repositori ini diarsipkan pemiliknya pada 25 April 2026 dan berstatus read-only. README-nya menyatakan bahwa repositori tidak lagi dipelihara dan mengarahkan pengguna ke produk komersial AIStor, yaitu AIStor Free (edisi tunggal untuk komunitas) dan AIStor Enterprise (edisi terdistribusi dengan dukungan komersial). Riwayat commit README menunjukkan proyek dinyatakan masuk mode pemeliharaan pada 3 Desember 2025. Sejak Oktober 2025, edisi komunitas juga hanya didistribusikan sebagai kode sumber: binary siap pakai yang lama masih bisa diunduh, tetapi tidak lagi dipelihara.

Dua hal perlu dibedakan agar tidak salah paham. Pertama, kode sumber MinIO yang sudah dirilis tetap berlisensi GNU AGPLv3, sehingga siapa pun boleh memakai dan membuat fork sesuai syarat lisensi tersebut. Kedua, lisensi terbuka tidak sama dengan pemeliharaan aktif. README MinIO sendiri menegaskan bahwa AGPLv3 tidak mewajibkan pihak mana pun untuk mendukung atau memelihara karya tersebut. Tanpa maintainer yang merilis patch, pengguna menanggung sendiri risiko kerentanan baru.

Fork dan Alternatif untuk Pengguna MinIO Community

Komunitas bergerak cepat. Pigsty memelihara fork yang kini bernama PGSTY Silo (repositori pgsty/silo, berganti nama dari pgsty/minio pada 6 Agustus 2026). Menurut README-nya, fork ini menyediakan build, paket, image multi-arsitektur, perbaikan keamanan, dan konsol web lengkap, serta menjaga kompatibilitas S3 dan format penyimpanan. Klien yang didukung adalah fork mc milik Pigsty (dikemas sebagai mcli); kompatibilitas dengan MinIO dan mc upstream yang tidak dimodifikasi bersifat best effort. Pigsty menyatakan fork ini tidak berafiliasi dengan MinIO, Inc. Proyek penyimpanan objek kompatibel S3 lain yang masih aktif antara lain Garage (AGPLv3), SeaweedFS, dan RustFS (keduanya Apache 2.0). Setiap pilihan punya kematangan, model lisensi, dan jaminan patch yang berbeda, jadi evaluasi sebelum memutuskan:

• Siapa maintainer-nya dan berapa banyak?
• Seberapa cepat patch keamanan sebelumnya dirilis?
• Apakah fitur yang Anda pakai (versioning, replikasi, enkripsi, IAM) didukung?
• Apakah ada jalur migrasi data yang teruji?

Kasus Kedua: Sengketa Tata Kelola RubyGems

Risiko open source tidak hanya soal lisensi. Pada September 2025, akses GitHub sejumlah maintainer lama RubyGems dan Bundler dicabut oleh Ruby Central, nonprofit yang menaungi operasional RubyGems.org, dengan alasan pengamanan rantai pasok. Berikut garis waktu menurut laporan LWN (20 Oktober 2025):

• 9 September 2025: menurut dokumen dari maintainer Ellen Dash, organisasi GitHub "RubyGems" diubah namanya menjadi "Ruby Central", Marty Haught dari Ruby Central ditambahkan, dan maintainer lain dihapus.
• 18 September 2025: setelah akses sempat dipulihkan, keanggotaan seluruh admin dicabut kembali, termasuk akses ke gem bundler dan rubygems-update.
• Awal Oktober 2025: Martin Emde mengumumkan gem.coop, alternatif berbasis koperasi yang dibangun sejumlah mantan maintainer.
• 17 Oktober 2025: pencipta Ruby, Yukihiro Matsumoto, mengumumkan bahwa tim inti Ruby akan mengambil alih pengelolaan repositori RubyGems dan Bundler.

Klaim kedua pihak saling bertentangan. Ruby Central menyangkal bahwa yang terjadi adalah pengambilalihan dan menyatakan dukungan sponsor tidak disyaratkan pada langkah tersebut; para maintainer yang dicabut menyebutnya pengambilalihan paksa. LWN menyebut tulisannya hanya ringkasan dari peristiwa yang masih berkembang, dan mencatat bahwa menurut Marty Haught pada Juni 2025, anggaran RubyGems.org tahun 2025 sebesar 1,4 juta dolar AS belum sepenuhnya terkumpul. Pelajaran utamanya netral: infrastruktur registri paket yang dipakai jutaan pengembang bergantung pada tata kelola yang jelas dan pendanaan yang transparan. Isu pendanaan dibahas di Pendanaan Keamanan Open Source 2026.

Pelajaran Risiko Lisensi dan Ketergantungan Open Source

1. Petakan ketergantungan kritis. Buat inventaris komponen infrastruktur (penyimpanan, registri paket, ingress, database) dan catat siapa pemiliknya. SBOM membantu; lihat SBOM, SLSA, dan Sigstore.
2. Nilai kesehatan proyek, bukan hanya fitur. Perhatikan jumlah maintainer, frekuensi rilis, pendanaan, dan model bisnis di balik proyek.
3. Pahami lisensi. AGPLv3 memberi hak fork, tetapi juga kewajiban tertentu pada layanan jaringan. Libatkan tim legal untuk pemakaian komersial.
4. Siapkan rencana keluar. Gunakan antarmuka standar (S3 API, misalnya) agar migrasi tidak menulis ulang aplikasi, dan uji restore dari cadangan secara berkala.
5. Pantau advisori sendiri. Jika Anda tetap memakai versi yang sudah tidak dipelihara, tambahkan kontrol kompensasi: isolasi jaringan, otentikasi kuat, dan pemantauan akses. Prinsip dasarnya mirip pencegahan supply chain attack.

Relevansi bagi Organisasi di Indonesia

Startup dan tim internal yang memakai MinIO untuk penyimpanan objek self-hosted, apalagi untuk data yang tunduk pada kewajiban pelindungan data pribadi, sebaiknya segera mengecek versi yang berjalan, apakah ia sudah berada di rilis yang tidak lagi menerima patch, dan siapa yang bertanggung jawab atas rencana migrasinya.

Rencana Praktis 30-60-90 Hari bagi Pengguna MinIO

Agar keputusan tidak berhenti di diskusi, pecah pekerjaan menjadi tahap-tahap kecil:

• 30 hari pertama: inventaris. Daftar semua instance MinIO, versi, bucket kritis, ukuran data, dan aplikasi yang bergantung pada S3 API. Pastikan akses jaringan ke instance dibatasi dan kredensial dirotasi.
• Hari 30 sampai 60: evaluasi. Pilih dua atau tiga kandidat (fork Pigsty Silo, Garage, SeaweedFS, RustFS, atau produk komersial) dan uji dengan beban yang menyerupai produksi, termasuk replikasi, kebijakan akses, dan enkripsi.
• Hari 60 sampai 90: migrasi bertahap. Mulai dari data non-kritis, bandingkan checksum objek, jalankan kedua sistem paralel untuk sementara, lalu alihkan aplikasi satu per satu.

Selama masa transisi, perlakukan instance lama sebagai aset berisiko lebih tinggi: jangan membukanya ke internet, aktifkan log akses, dan pantau anomali. Keputusan akhir, termasuk anggaran dan lisensi, sebaiknya dikonsultasikan dengan pemilik sistem dan tim hukum.

Baca juga: OpenSSL 4.0: Perubahan Penting dan Persiapan Migrasi.

Pertanyaan yang Sering Diajukan

Apakah MinIO masih bebas dipakai?

Kode sumbernya tetap berlisensi AGPLv3 sehingga boleh dipakai dan di-fork, tetapi versi komunitas tidak lagi dipelihara oleh MinIO.

Apakah saya harus langsung berpindah?

Tidak harus terburu-buru, tetapi buat rencana: pilih fork atau alternatif dengan maintainer yang jelas dan uji migrasi di staging.

Apa pelajaran dari kasus RubyGems?

Bahwa tata kelola dan pendanaan proyek sama pentingnya dengan kodenya. Klaim kedua pihak saling bertentangan, jadi baca sumber primer sebelum menarik kesimpulan.

Kesimpulan

Arsip MinIO community mengingatkan bahwa open source tidak otomatis berarti dipelihara selamanya. Inventaris ketergantungan, nilai kesehatan proyek, dan siapkan rencana keluar. Untuk membangun kemampuan tim dalam keamanan rantai pasok dan infrastruktur, lihat training Linuxhackingid.