Open source tidak berarti komunitas terbuka
(blog.feld.me)- Perangkat lunak open source bahkan sebelum era (D)VCS sudah bisa didistribusikan hanya dengan halaman HTML, file txt, tarball di FTP, dan kontak email, serta tetap merupakan open source meski tanpa komunitas publik
- Jika ada mailing list atau kanal IRC itu sudah termasuk beruntung, tetapi pull request, issue, wiki, core team, dan Code of Conduct bukanlah syarat wajib open source
- Sourceforge menyediakan CVS/SVN dan mailing list hampir secara gratis sehingga memudahkan pengembangan terbuka, lalu git memenangkan persaingan DVCS dan dunia pun berkonsolidasi ke GitHub
- Setelah GitHub, pemeliharaan open source berubah seperti pekerjaan tanpa bayaran yang juga harus menanggung issue, pull request di luar cakupan, keluhan dan tuntutan, hingga pengelolaan grup chat, yang dapat berujung pada burnout dan hilangnya kendali
- Sebuah proyek tidak harus dikembangkan secara publik; Anda bisa mematikan issue tracker dan pull request, atau memakai bare git server, lalu mengelola open source bersama kelompok kecil tepercaya atau sendirian
Beban pemeliharaan setelah GitHub
- GitHub membuat open source terasa seperti pekerjaan tanpa bayaran bagi para maintainer
- Setelah seharian di kantor menangani tiket, rapat dengan stakeholder, roadmap, politik internal, distraksi, tenggat, metrik, KPI, perubahan kebutuhan, standup, one-on-one, Agile, dan Waterfall, setibanya di rumah notifikasi open source sudah menumpuk
- Issue terus bertambah, pull request masuk untuk mendesain ulang perangkat lunak ke arah yang keluar dari cakupan proyek, serta keluhan dan tuntutan makin banyak
- Saat grup chat dan “komunitas” terbentuk, maintainer juga akhirnya menanggung tanggung jawab untuk mengelola orang-orang yang tidak sabaran dan melayani mereka satu per satu
- Akibatnya, open source berubah seperti pekerjaan kedua, dan maintainer bisa mengalami burnout serta kehilangan kendali dan arah atas proyeknya sendiri
Menjalankannya sederhana lagi
- Beberapa proyek memang terlalu besar dan kompleks sehingga membutuhkan pengelolaan tim, tetapi itu pengecualian dan bukan kasus umum
- Jika Anda marah karena perhatian terus tersedot oleh orang-orang baru dan bot AI, Anda bisa kembali ke cara lama
- Anda bisa mematikan issue tracker dan pull request, atau menjalankan bare git server untuk memublikasikan kode
- Anda bisa bekerja bersama kelompok kecil yang benar-benar dikenal dan dipercaya, atau menjalankan proyek sepenuhnya sendirian
- Tidak perlu membiarkan orang asing memasuki ruang Anda, dan Code of Conduct seremonial atau kebijakan LLM juga bukan keharusan
- Agar menjadi “open source”, open source tidak harus dikembangkan secara publik
- Gunakan alat yang Anda inginkan, buat hal yang Anda sukai, bahkan lakukan code drop pada pukul 2 pagi saat Natal, tanpa harus terseret ke pola operasi yang terasa seperti campuran inkubator teknologi dan fasilitas pengasuhan
2 komentar
Opini di Lobste.rs
Karena pemikiran seperti inilah saya membuat https://casuallymaintained.tech/, dan saya sangat menyukainya
Contoh yang paling terkenal adalah SQLite, yang menolak kontribusi dari luar
Mengingat ini juga dipakai di aplikasi mission-critical seperti pesawat Airbus, kebijakan itu masuk akal
SQLite adalah open source, jadi bisa disalin sesuka hati dan digunakan tanpa batasan, tetapi bukan proyek dengan kontribusi terbuka (
open-contribution)Untuk menjaga SQLite tetap berada di domain publik dan mencegah tercampurnya kode berpemilik atau berlisensi, mereka tidak menerima patch dari orang yang belum mengajukan pernyataan bahwa kontribusinya didedikasikan ke domain publik
Ini sudut pandang yang cukup segar
Mungkin penulisnya benar, dan mungkin kita menuntut terlalu banyak dari para maintainer
Mungkin yang rusak bukan open source secara keseluruhan, melainkan inflasi ekspektasi tentang apa yang seharusnya disediakan open source
Unsur sosial GitHub juga bisa berperan. Semakin banyak bintang dan pengguna biasa, semakin besar tekanan untuk memuaskan orang-orang baru yang datang melihat proyek itu
Ini jadi berbahaya terutama ketika perhatian dan tuntutan komunitas tidak selaras dengan visi awal pembuatnya
Tulisan terkait: Git without a Forge: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/
Ini pendekatan yang solid, dan saya berharap lebih banyak orang menjadikannya sebagai default
Membangun komunitas atau memikul tanggung jawab tertentu seharusnya menjadi tindakan yang sengaja dipilih dan bersifat pengecualian
Bagian yang menyebut code of conduct dan kebijakan LLM sebagai sekadar performatif memang terasa agak meleset, tetapi topiknya sensitif jadi bisa dimaklumi
Tetapi jika ditempelkan pada repositori satu orang yang tidak punya pengguna, tidak punya komunitas, dan juga tidak berniat membangunnya, itu memang jadi performatif
Tidak perlu code of conduct untuk diri sendiri di repositori yang saya pakai sendirian
Akan sangat bagus jika diskusi ini mendapat momentum dan benar-benar menghasilkan kesepahaman yang bisa diterapkan
Ada banyak cara untuk membuat software dan berkontribusi secara sehat
Hanya saja, cara-cara itu bisa saja saling tidak cocok, tidak memenuhi standar tinggi open source, menuntut biaya dari visibilitas dan popularitas, atau memakai mekanisme yang berbeda seperti lisensi, self-hosting, atau tidak menerima kontribusi kode
Saya berharap kita bisa bersama-sama menemukan jalan yang baik dengan menempatkan kesenangan dan keadilan di depan dalam software komunitas
Kondisi yang dijelaskan tulisan itu adalah keadaan alami dari hampir semua proyek open source pribadi yang baru dibuat oleh orang yang bukan figur terkenal
Kita semua punya cukup banyak proyek yang berjalan seperti itu
Masalahnya ada pada orang-orang yang tidak tahu apa yang mereka inginkan dari sebuah proyek, atau mengira mengelola proyek populer akan terlihat keren tanpa benar-benar mempertimbangkan biayanya
Dari situlah dimulai pengejaran perhatian, entah disadari atau tidak
Ucapan bahwa “GitHub telah mengubah seluruh open source menjadi pekerjaan tanpa bayaran bagi maintainer” hanya benar kalau dibiarkan terjadi
Jika janji samar soal ketenaran dikesampingkan, dalam kebanyakan situasi GitHub sebenarnya tidak punya banyak daya ungkit untuk memaksa orang melakukan hal yang sejak awal tidak ingin mereka lakukan
Benar sekali
Dulu saya pernah punya proyek yang agak populer, dan saya stres karena harus menangani laporan bug serta pull request untuk fitur-fitur yang tidak saya inginkan
Rasanya akan sangat membantu jika saat itu saya bisa membaca tulisan seperti ini
Tambahan lagi, https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 juga layak dibaca
Untuk proyek kecil, saya sangat setuju dengan tulisan ini
Bahkan untuk proyek yang lebih besar pun, banyak yang paling sukses justru tidak dimulai sebagai komunitas terbuka sejak awal
Banyak proyek yang saya sukai memulai pengembangannya di organisasi besar, dan yang penting adalah software itu benar-benar dipakai secara aktif di internal
Jadi para maintainer-nya memang sudah dibayar
Baik proyek pribadi maupun tim internal, software yang dibuat untuk menyelesaikan masalah sehari-hari pengembangnya sendiri tampak lebih sukses dan kurang eksploitatif dibanding software yang dibuat demi ketenaran atau komersialisasi
Komentar Hacker News
Bahkan di komunitas yang paling tertutup pun, sering kali kontribusi tetap diterima kalau kita mengirim email dengan sopan
Ada seorang pengembang open source yang pernah mematikan pull request dan berbagai fitur di repositorinya karena lelah menghadapi pelecehan, dan pada masa itu ia sampai mendapat reputasi sebagai orang yang sangat sulit diajak berurusan
Tanpa mengetahui situasinya, saya hanya mengira proyek itu memang dari awal bekerja seperti itu, jadi setelah sedikit mencari alamat emailnya, saya mengirim patch tidak resmi lewat email yang ringan dan sopan, sambil menegaskan bahwa ia bebas memakainya atau mengabaikannya
Pengembang itu membalas dengan ucapan terima kasih, menjelaskan situasinya, bahkan meminta maaf karena membuatnya tidak nyaman, lalu mengatakan bahwa mengunci semuanya adalah satu-satunya cara yang ia tahu untuk merespons, dan tentu saja perbaikannya juga ia terapkan
Saya kira tulisan ini akan membahas masalah yang sudah sangat umum, yaitu proyek perangkat lunak bebas yang memaksa diskusi atau pelaporan bug lewat Discord
Selama sekitar satu dua minggu sempat terlihat ada minat untuk pindah ke alat lain, tetapi tampaknya sudah mereda, dan akhirnya semua orang menyerah lalu kembali ke Discord
Discord memang tidak sepenuhnya mengerikan, tetapi serba sementara dan menuntut aplikasi web besar yang gemuk
Dari sudut pandang seorang greybeard, saya suka sikap penulisnya
Saya sudah cukup tua sampai ingat masa duduk di depan para sesepuh ARPANET, ketika yang ada cuma angka 1, jadi sekitar setengahnya harus diasah dengan tangan menjadi 0
Dalam cara lama pengembangan perangkat lunak, proyek biasanya ditulis atau dipelihara oleh satu atau dua orang, dan seluruh internet tahu alamat email mereka lalu mengirim laporan bug langsung kepada mereka
Beberapa proyek dibahas di IRC atau mailing list, orang-orang umumnya bersikap profesional, dan kalau tidak, mereka biasanya dihapus dari mailing list atau dimasukkan ke file blokir iirc dan pine
Intinya, pada titik mana pun kelompok pengembang aktif itu sangat kecil
Yang saya maksud terutama utilitas kecil seperti make, Sendmail, sed, awk, dan bahkan Perl pun sebelum 1990 tampaknya pada dasarnya hanya Larry Wall dan tchrist
gcc adalah pengecualian gila, di mana ribuan orang mengirim patch dan kalau ingin masuk ke upstream juga harus pandai berkoordinasi dengan RMS
Alat-alat baru mendukung tim yang lebih besar untuk terus berinteraksi, dan memang ada banyak keuntungan besar dibanding tim kecil yang tidak akan peduli pada siapa pun di internet kecuali orang itu rela mempertaruhkan ginjal demi mengirim patch
Hanya saja cara seperti itu bukan keunggulan untuk menarik orang masuk ke pekerjaan itu, jadi Anda boleh saja kembali ke cara lama, tetapi timnya akan lebih kecil dan mungkin lebih sulit menarik pengguna
Meski begitu, pengguna bukan urusan saya, saya memakai perangkat lunak untuk mendukung kebutuhan saya sendiri, dan saya merilisnya sebagai open source hanya karena barangkali berguna juga bagi orang lain
Lebih spesifik lagi, open source hanya menjanjikan empat kebebasan dasar(https://en.wikipedia.org/wiki/The_Free_Software_Definition)
Di luar itu, secara harfiah tidak menjanjikan apa pun, dan itu termasuk bukan berarti gratis
Perangkat lunak bebas/open source boleh dipungut biaya dan memang seharusnya begitu, karena “free” di sini bukan soal uang
Saya cukup memandang positif berbagai serangan “rantai pasok” open source yang terjadi belakangan di banyak komunitas, karena secara optimistis saya berharap itu membuat orang sadar bahwa open source bukanlah rantai pasok
Penjelasan lebih rinci ada di https://lobste.rs/s/cxwidw/no_one_owes_you_supply_chain_secu...
Kalau Anda tidak membayar vendor, atau tidak punya kontrak yang berisi jaminan jadwal, maka Anda tidak punya rantai pasok
Hampir semua lisensi FOSS memiliki klausul “perangkat lunak ini disediakan tanpa jaminan”, sedangkan rantai pasok mengandaikan adanya jaminan, jadi FOSS bukan rantai pasok
Saya muak melihat orang datang ke sini dan memperlakukan “open source” seolah punya “nilai moral”, lalu mencampurkan konsep yang dicuri dari perangkat lunak bebas seakan keduanya sama
Open source hanya berarti perusahaan perangkat lunak besar mengambil dari banyak sukarelawan
Orang-orang kubu code of conduct itu memang cuma ada untuk bikin masalah
Lihat saja perdebatan tombol merah/tombol biru; racun kata-kata sekeras itu hanya masuk akal kalau tombolnya benar-benar ada atau orang memang suka bersikap kejam
Pendukung code of conduct yang beritikad baik berbicara soal kebebasan berserikat dan kebebasan berekspresi
Pertanyaannya adalah apakah platform boleh memblokir lawan hanya karena tidak suka, atau apakah ini seharusnya cukup ditangani dengan kebiasaan praktis mailing list seperti “ayo bersikap baik”
Tentu saja semuanya bergantung pada siapa yang memegang kuasa, tetapi itu berlaku untuk proyek apa pun
Anda tidak bisa sekaligus menuntut hak untuk berpartisipasi dalam proyek orang lain sambil mengajukan syarat yang bertentangan dengan kehendak kepemimpinan proyek, lalu tetap mengklaim kebebasan berserikat
Dugaan saya, maksud penulis saat mengatakan “tidak perlu Code of Conduct yang demonstratif” mungkin adalah bahwa bila proyek masih kecil, hanya dibagikan ke dunia, dan Anda cuma ingin membuka opsi menerima kontribusi dari luar nanti, maka Anda belum perlu menyiapkan code of conduct sebelum benar-benar menghadapi situasi nyata
Tidak perlu pusing memikirkan masalah yang sepenuhnya masih hipotesis
Alasan code of conduct ada adalah karena alternatifnya ialah hukuman sewenang-wenang untuk pelanggaran yang juga sewenang-wenang, atau anarki spam total
Saya tidak paham kenapa orang-orang yang dulu berkhotbah soal netiket sekarang sangat menentang kejelasan dan komunitas yang sehat
Kalau dipikir lagi, mungkin ini Goomba fallacy, dan orang-orang yang menghina code of conduct barangkali memang orang yang pada 1990-an terus menebar flame war dan spam di Usenet
Open source bukan sekadar pilihan lisensi
Ia adalah pembingkaian ulang perangkat lunak bebas agar tampak lebih menarik bagi perusahaan, dan inti open source adalah keyakinan bahwa bagi perusahaan lebih efektif mengembangkan perangkat lunak dengan berkolaborasi dengan publik daripada melakukannya secara tertutup
Jadi, open source mengandaikan adanya komunitas terbuka
Jika Anda ingin melempar kode ke publik dengan lisensi permisif tetapi tidak ingin pengembangan kolaboratif, tentu Anda boleh melakukannya, dan kode itu tetap open source
Membuka kode adalah hal baik dan Anda tidak wajib melakukan lebih dari itu, tetapi itu bukan menjalankan open source sesuai tujuan rancangnya, dan berarti mengabaikan sebagian intinya
Orang yang melihat kode open source lalu berasumsi bahwa pengembangannya kolaboratif bukanlah orang yang tidak masuk akal
Itulah tujuan gerakan open source
Boleh saja asumsi itu tidak berlaku untuk perangkat lunak Anda, tetapi pihak yang melanggar norma sosial bukan mereka, melainkan Anda
Saya memikirkan Stallman, driver printer, dan soal pengguna memiliki kendali atas pekerjaannya sendiri, jadi pernyataan tegas tentang tujuan open source seperti itu terasa tidak tepat bagi saya
https://en.wikipedia.org/wiki/The_Open_Source_Definition
Di sana tidak ada satu kata pun tentang pengembangan kolaboratif
Orang sering menjadi emosional, lalu merasa harus melayani pengguna baru atau pengguna yang tidak mau mempelajari dasar-dasarnya
Lebih baik menjaga hubungan yang terpisah dari forum dukungan, tetapi tegas, merespons tepat waktu, namun tetap berjarak
coreboot dan MrChromebox adalah contoh yang bagus; dia menjawab hanya saat perlu
Saya setuju, dan mau menambahkan satu hal lagi: tidak perlu membuat halaman pemasaran untuk membujuk orang memakai perangkat lunak Anda
Sebagai gantinya, atau bersamaan dengan itu, bagus juga kalau Anda menjelaskan semua alasan mengapa orang justru tidak seharusnya memakai perangkat lunak ini
Semakin banyak pengguna, semakin banyak pula masalahnya
Aplikasi FOSS tidak harus didistribusikan secara publik, itu hanya ekspektasi sosial yang umum
Menjadi FOSS juga tidak berarti kode harus disediakan kepada orang yang bukan pelanggan, dan siapa yang dianggap pelanggan ditentukan oleh pengembang
FOSS justru mendorong perangkat lunak dijual berbayar, dan Anda bahkan boleh menjual perangkat lunak orang lain yang tadinya gratis (lihat https://www.gnu.org/philosophy/selling.en.html)
Open source dengan lisensi nonbebas tetaplah open source, tetapi bukan FOSS, dan pengembang tidak perlu merasa malu memilih lisensi open source nonbebas jika ingin menghasilkan lebih banyak uang dari perangkat lunaknya atau menambahkan pembatasan ekstra yang menguntungkan dirinya
Itu pun bisa saja berbentuk copyleft
Singkatnya, kita membuat LICENSE.md dan sangat bergantung padanya, tetapi tidak ada yang pernah berpikir membuat SOCIAL.md
Saat seseorang mengatakan “open source”, banyak orang berasumsi “penulis membuat ini demi orang lain, demi masyarakat, demi lingkungan sekitarnya; ia tertarik pada pengembangan proyek, penambahan fitur baru, terutama fitur yang saya butuhkan, serta perbaikan demi kepentingan semua pengguna. Kalau tidak begitu, untuk apa dipublikasikan?”
Padahal ini hanyalah ekspektasi sosial yang paling umum terhadap FOSS, jauh dari satu-satunya kemungkinan
Tidak adanya pembedaan antara open source teknis dan open source sosial adalah penyebab utama ketidakcocokan, perdebatan, dan akhirnya burnout yang lahir dari ekspektasi sosial yang meleset
Dulu saya harus menjelaskan masalah ini dan perbedaannya kepada massa yang marah, tetapi belakangan saya melihat tulisan Jeffrey Paul https://sneak.berlin/20250720/the-agpl-is-nonfree/ yang mengibaratkan kode open source sebagai hadiah
Penjelasan saya pada akhirnya menjadi: “kalau Anda tidak suka hadiahnya dan itu tidak cocok untuk Anda, buang saja dan lupakan”
Lisensi yang disetujui OSI tetapi tidak dianggap perangkat lunak bebas oleh FSF hanya ada beberapa
Lihat saja daftar panjang lisensi perangkat lunak bebas yang tidak kompatibel dengan GPL di https://www.gnu.org/licenses/license-list.html
Lagi pula, “open source non-FOSS” juga tidak masuk akal, karena FOSS secara harfiah berarti Free and Open Source Software
Sekarang hampir langsung muncul di GitHub lengkap dengan executable yang bisa dipakai siapa saja, tanpa harus melewati situs web mencurigakan atau pipeline build yang aneh
Tidak ada “komunitas”, tidak ada politik, tidak ada code of conduct, tidak ada pull request atau issue, tidak ada wiki, tidak ada tim inti; terdengar seperti surga
Saya merasa sekarang terlalu banyak komunitas yang justru merugikan proyek itu sendiri
Bahkan lebih jauh lagi, saya tidak bisa mengingat satu pun contoh di mana komunitas benar-benar membantu proyek open source dengan cara apa pun
Kalau tujuannya memaksimalkan kendali dengan mengorbankan kualitas, ya silakan
Hanya saja dalam kasus seperti itu, saya jadi ragu apakah yang Anda cari benar-benar FLOSS