Saat Proyek Open Source Kehilangan Pemimpinnya

Ketika Ryan Dahl mundur dari Node.js, proyeknya tetap bertahan, tapi butuh bertahun-tahun restrukturisasi tata kelola, sebuah fork (io.js), dan rekonsiliasi sebelum akhirnya stabil. Ketika Guido van Rossum mengundurkan diri sebagai BDFL Python ('Benevolent Dictator For Life'), komunitas menghabiskan berbulan-bulan memperdebatkan model tata kelola sebelum akhirnya memilih steering council. Ketika proyek Deno menghadapi pertanyaan kepemimpinannya sendiri, dampaknya merambat ke setiap developer yang sudah bertaruh pada runtime tersebut.

Ini bukan insiden yang berdiri sendiri. Ini adalah ciri struktural dari pengembangan open source. Sebagian besar proyek open source penting bergantung pada segelintir orang, sering kali hanya satu orang, jauh lebih besar dari yang disadari penggunanya. Ketika orang itu pergi, kelelahan, berganti prioritas, atau membuat keputusan kontroversial, proyek menghadapi krisis eksistensial yang tidak bisa dicegah oleh jumlah bintang GitHub sebanyak apa pun.

Masalah Bus Factor

'Bus factor', yaitu berapa banyak orang yang harus tertabrak bus sebelum sebuah proyek runtuh, angkanya sangat rendah untuk sebagian besar proyek open source. Sebuah studi tahun 2015 menemukan bahwa lebih dari 60% paket npm hanya punya satu maintainer. Analisis yang lebih baru terhadap infrastruktur open source kritis menemukan bahwa banyak proyek dengan jutaan dependent hilir dikelola oleh satu atau dua orang, sering kali sebagai pekerjaan hobi tanpa bayaran.

Ini bukan masalah hipotetis. OpenSSL, library yang mengamankan sebagian besar lalu lintas terenkripsi internet, dikelola terutama oleh dua orang yang mengerjakannya di waktu luang saat Heartbleed ditemukan. Left-pad, paket npm sepele berisi 11 baris, merusak ribuan build ketika penulisnya menghapusnya. Core-js, yang diunduh lebih dari 25 juta kali per minggu, dikelola oleh satu developer yang secara terbuka mengaku nyaris tidak mampu membeli makanan.

Polanya konsisten: proyek kritis dimulai oleh individu yang bersemangat, mendapat adopsi, menjadi infrastruktur yang bergantung pada jutaan orang, tetapi beban pemeliharaannya tetap ada di pundak satu atau dua orang yang sama. Kepentingan proyek tumbuh secara eksponensial. Dukungannya tidak.

Model Tata Kelola dan Trade-off-nya

Proyek open source menangani tata kelola dengan beberapa cara yang berbeda, masing-masing dengan kekuatan dan titik kegagalan yang bisa diprediksi.

Model BDFL

Satu orang membuat keputusan akhir. Python (Guido van Rossum), Linux (Linus Torvalds), Ruby (Matz): proyek paling sukses sering punya pemimpin teknis yang kuat, yang selera dan penilaiannya membentuk arah proyek. Keunggulannya jelas: arah yang terang, visi yang konsisten, dan pengambilan keputusan yang cepat. BDFL bisa bilang 'tidak' pada fitur yang tidak cocok, dan proyek tetap fokus.

Titik kegagalannya sama jelasnya: BDFL pergi dan tidak ada rencana suksesi. Transisi Python setelah pengunduran diri Guido berjalan tersendat, padahal ia sudah membangun komunitas selama puluhan tahun. Proyek dengan komunitas yang kurang terlibat sering kali benar-benar mati begitu BDFL-nya melangkah pergi.

Model Yayasan

Proyek seperti Apache, Eclipse, dan Linux Foundation berada di bawah yayasan nonprofit dengan struktur tata kelola formal: komite teknis pengarah, pemilihan committer, dan proses pengambilan keputusan. Ini memberi kesinambungan kelembagaan. Proyek bisa bertahan dari kepergian individu karena strukturnya tetap ada.

Trade-off-nya adalah birokrasi dan dinamika politik. Tata kelola yayasan bisa lambat, penuh perselisihan, dan bisa dikuasai kepentingan korporasi. Sebagian developer merasa proses komite membosankan dibandingkan kelincahan proyek yang dipimpin BDFL. Kasus terburuknya: yayasan yang tata kelolanya lebih mengurusi politik organisasi ketimbang kualitas teknis.

Model Sponsor Korporasi

React (Meta), Go (Google), Rust (awalnya Mozilla, sekarang punya yayasan sendiri), TypeScript (Microsoft). Banyak proyek besar disponsori oleh perusahaan yang mempekerjakan maintainer intinya. Ini menyelesaikan masalah pendanaan: maintainer dibayar, bisa bekerja penuh waktu, dan proyek mendapat manfaat dari sumber daya engineering perusahaan.

Risikonya adalah keselarasan. Prioritas perusahaan bisa berubah. Mozilla pernah mem-PHK tim Rust. Google pernah menurunkan prioritas dan mengurangi pendanaan proyek open source ketika fokus bisnisnya bergeser. Ketika kepentingan strategis perusahaan berbeda dengan kepentingan komunitas, gesekan tidak terhindarkan. Tren belakangan ini, di mana lisensi proyek open source diubah oleh sponsor korporasi (Redis, Terraform, Elastic), menunjukkan betapa rapuhnya model ini.

Kapan Fork Itu Sehat

Fork, yaitu membuat salinan kompetitif dari sebuah proyek, sering dianggap tanda kegagalan. Tapi dalam open source, fork justru katup pengaman paling pamungkas. Ketika kepemimpinan gagal, fork memungkinkan komunitas tetap berjalan tanpa bergantung pada maintainer asli.

Fork io.js dari Node.js mendorong Node ke model tata kelola yang lebih terbuka dan siklus rilis yang lebih cepat. Ketika kedua proyek akhirnya digabung kembali, Node justru jadi lebih baik. LibreOffice yang di-fork dari OpenOffice.org menyelamatkan proyek dari menurunnya minat Sun/Oracle. MariaDB, yang di-fork dari MySQL setelah akuisisi Oracle, terus berkembang sebagai alternatif yang digerakkan komunitas.

Belakangan ini, perubahan lisensi juga memicu fork yang produktif. Ketika Elastic mengubah lisensi Elasticsearch, Amazon membuat fork bernama OpenSearch. Ketika HashiCorp mengubah lisensi Terraform, komunitas membuat fork bernama OpenTofu di bawah Linux Foundation. Fork-fork ini ada karena hak untuk melakukan fork adalah kontrol terakhir komunitas terhadap kepemimpinan proyek.

Kuncinya, fork paling berhasil ketika komunitasnya, bukan hanya kodenya, terbelah dengan rapi. Fork dengan maintainer aktif dan dukungan komunitas akan berkembang. Fork oleh satu developer yang frustrasi dan tidak diikuti siapa pun hanya menciptakan kebingungan.

Spiral Burnout

Sebagian besar krisis kepemimpinan di open source tidak dimulai dengan kepergian yang dramatis. Mereka dimulai dengan burnout, yaitu terkikisnya kapasitas dan antusiasme maintainer secara perlahan di bawah beban issue, pull request, permintaan fitur, dan pengguna yang merasa berhak.

Dinamikanya bisa ditebak. Seorang maintainer membuat sesuatu yang berguna. Pengguna berdatangan. Bersama pengguna datang laporan bug, permintaan fitur, pertanyaan dukungan, dan tuntutan. Maintainer, merasa bertanggung jawab, mencoba menjawab semuanya. Volumenya melampaui kapasitasnya. Ia mulai takut melihat notifikasinya. Balasannya makin lambat, lalu makin ketus, lalu tidak ada sama sekali. Akhirnya ia menghilang, dan proyek masuk ke fase pemeliharaan zombie: secara teknis masih hidup, tapi praktis ditinggalkan.

Burnout maintainer open source bukan kegagalan pribadi. Ini masalah struktural: proyek menghasilkan permintaan tanpa batas terhadap waktu dan perhatian sejumlah orang yang terbatas, tanpa mekanisme bawaan untuk mengelola permintaan tersebut.

Beberapa maintainer sudah menemukan cara untuk bertahan: membatasi waktu respons dengan tegas, mendelegasikan triase ke anggota komunitas, pemeliharaan berbayar lewat GitHub Sponsors atau Open Collective, atau sekadar nyaman dengan waktu respons yang lebih lambat. Tapi semua ini menuntut perlawanan sadar terhadap tekanan untuk selalu tersedia, yang bertentangan dengan budaya banyak komunitas open source.

Seperti Apa Suksesi yang Sehat

Beberapa proyek sudah menangani transisi kepemimpinan dengan baik, dan mereka punya pola yang serupa.

• Pengetahuan yang terdistribusi, bukan hanya kodenya. 'Pengetahuan tribal' proyek, yaitu mengapa keputusan tertentu diambil, alternatif apa yang dipertimbangkan, dan apa prinsip desainnya, didokumentasikan dan tidak hanya ada di kepala satu orang. Architecture Decision Records (ADR) dan RFC yang detail berfungsi untuk tujuan ini.
• Banyak orang dengan akses commit dan wewenang rilis. Jika hanya satu orang yang bisa merilis, orang itu adalah titik kegagalan tunggal. Proyek yang sehat punya setidaknya 3-5 orang yang bisa merilis versi baru secara mandiri.
• Dokumen tata kelola yang eksplisit. Bagaimana keputusan dibuat? Siapa punya wewenang atas apa? Bagaimana maintainer baru ditambahkan? Proyek yang menjawab pertanyaan ini sebelum krisis akan menangani suksesi lebih baik daripada yang berimprovisasi.
• Transisi bertahap, bukan kepergian mendadak. Transisi kepemimpinan terbaik terjadi ketika pemimpin yang lengser secara sengaja mengurangi keterlibatannya selama berbulan-bulan, membimbing penerus, dan secara eksplisit menyerahkan wewenang. Kepergian mendadak, meski dengan niat baik, menciptakan kekosongan.
• Keberlanjutan finansial. Proyek dengan pendanaan yang andal (lewat yayasan, sponsor korporasi, atau pendanaan komunitas) lebih mampu melewati transisi karena maintainer baru bisa dibayar atas waktunya. Meminta seseorang mewarisi pekerjaan penuh waktu yang tidak dibayar adalah tawaran yang sulit diterima.

Apa yang Harus Dilakukan Pengguna dan Perusahaan

Jika bisnis Anda bergantung pada perangkat lunak open source, dan memang begitu, Anda punya kepentingan terhadap kesehatan proyek yang Anda andalkan. Beberapa langkah praktisnya:

1. Audit bus factor dependensi Anda. Lihat proyek open source kritis di stack Anda. Berapa maintainer aktif yang mereka punya? Kapan rilis terakhirnya? Seberapa cepat masalah keamanan ditangani? Proyek dengan satu maintainer dan kerentanan keamanan yang sudah berumur enam bulan adalah risiko yang seharusnya Anda ketahui.
2. Danai apa yang Anda pakai. Jika sebuah proyek krusial bagi bisnis Anda, berkontribusilah pada pendanaannya. GitHub Sponsors, Open Collective, dan Tidelift menyediakan mekanisme untuk ini. Biaya mendanai seorang maintainer sangat kecil dibandingkan biaya dependensi kritis yang tidak lagi dipelihara.
3. Berkontribusi ke upstream. Perbaikan bug, peningkatan dokumentasi, dan triase issue semuanya mengurangi beban maintainer dan membuat tim Anda familiar dengan codebase-nya. Jika proyek suatu saat butuh maintainer baru, Anda sudah siap untuk mengambil alih.
4. Punya rencana cadangan. Untuk dependensi kritis, ketahui apa yang akan Anda lakukan jika proyek itu ditinggalkan. Bisakah Anda melakukan fork dan memeliharanya sendiri? Adakah alternatif yang bisa Anda migrasikan? Waktu untuk menjawab pertanyaan ini adalah sebelum Anda membutuhkannya.

Tata kelola open source memang bukan pekerjaan yang glamor. Tidak menghasilkan berita utama atau bintang GitHub. Tapi perbedaan antara proyek yang bertahan setelah kepergian pendirinya dan yang tidak hampir selalu terletak pada tata kelola, yaitu pekerjaan membosankan dan struktural berupa mendokumentasikan keputusan, mendistribusikan wewenang, dan merencanakan suksesi. Proyek yang awet adalah yang membangun institusi, bukan sekadar perangkat lunak.