Open source tidak berarti komunitas terbuka

 (blog.feld.me)
1 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • 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

Bacaan terkait

1 komentar

 
GN⁺ 1 jam lalu
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 tidak menolak kontribusi eksternal. Hal ini juga tertulis jelas di halaman hak cipta mereka
      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

    • Itu bukan berarti semua code of conduct atau kebijakan LLM itu sekadar performatif
      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