Resistansi Open Source: Mari menjaga open source di jam kerja

 (ossresistance.com)
6 poin oleh GN⁺ 2026-05-15 | 2 komentar | Bagikan ke WhatsApp
  • Open Source Resistance adalah manifesto aksi langsung yang mengajak orang untuk secara diam-diam dan profesional melakukan pemeliharaan perangkat lunak open source yang diandalkan perusahaan dalam jam kerja
  • Menolak struktur yang membuat maintainer harus memohon izin terpisah, tombol donasi, atau waktu Jumat sore, padahal semua perusahaan tidak bisa menjalankan bisnis tanpa open source
  • Sebelumnya sudah ada alternatif seperti Open Source Pledge (meminta pembayaran US$2.000 per tahun per developer) dan Open Source Friday (berkontribusi minimal 2 jam setiap Jumat), tetapi manifesto ini menekankan eksekusi yang lebih langsung
  • Untuk sanggahan bahwa ini adalah “pencurian waktu”, jawabannya adalah bahwa perusahaan selama ini sudah menerima subsidi OSS gratis, dan pemeliharaan OSS yang menjadi dependensi adalah pekerjaan infrastruktur bersama
  • Wajib memeriksa klausul pengalihan IP dalam kontrak kerja, dan menegosiasikan carve-out open source secara tertulis

Manifesto: jangan meminta izin untuk memperbaiki pekerjaan yang memang sudah perlu dilakukan

  • Open Source Resistance adalah usulan aksi langsung untuk tidak mendorong pemeliharaan perangkat lunak open source (OSS) yang diandalkan perusahaan menjadi hobi malam atau akhir pekan, melainkan melakukannya secara tenang dan profesional di jam kerja
  • Perangkat lunak open source bukan “hobi” di waktu luang, dan perusahaan mengekstrak nilai dari open source setiap saat sambil hanya memberi maintainer satu Jumat sore, satu tombol donasi, atau ucapan terima kasih di rapat umum
  • Maintainer harus mengerjakan kode OSS yang sudah diandalkan perusahaan dari dalam organisasi tanpa dokumen, program internal, atau persetujuan manajer pada jam kerja
  • Ini bukan gagasan baru, melainkan mengatakan secara terbuka bagaimana kebanyakan open source memang selalu dikerjakan
  • Para maintainer telah menjaga internet tetap berjalan tanpa menunggu izin rapat, sprint, atau product manager

Prinsip tindakan utama

  • Lindungi diri sendiri

    • Periksa kontrak kerja, simpan informasi rahasia tetap di dalam perusahaan, dan pastikan Anda memiliki hak atas IP open source yang Anda rilis

  • Lakukan pekerjaannya

    • Kerjakan review PR, pembaruan dependensi, dan perbaikan bug pada bagian yang memang sudah berupa OSS

  • Jangan gegabah

    • Jangan menghabiskan 100% jam kerja untuk OSS lalu menyalahkan orang lain setelah dipecat; keseimbangan adalah kuncinya

Alternatif yang sudah ada

  • Open Source Pledge: meminta perusahaan membayar maintainer (US$2.000 per tahun per developer)
  • Open Source Friday: meminta perusahaan menyumbangkan waktu (minimal 2 jam setiap Jumat)
  • Ada juga jalur yang sopan, yaitu meyakinkan pemberi kerja terlebih dahulu; semuanya positif dan layak didukung
  • Open Source Resistance adalah langkah berikutnya dalam arus ini, yang menyatakan bahwa pemeliharaan rantai dependensi sudah merupakan bagian dari pekerjaan, meskipun tidak dinamai demikian oleh manajer
  • Alokasi anggaran perusahaan mungkin di luar kendali kita, tetapi cara menggunakan jam kerja sendiri masih bisa dikendalikan

Sanggahan yang diperkirakan dan jawabannya

  • “Ini pencurian waktu / pencurian terhadap pemegang saham”

    • Perusahaan sudah mengekstrak nilai dari maintainer open source setiap hari, dan para pemegang saham selama puluhan tahun telah menerima subsidi open source gratis
    • Jika pemberi kerja bergantung pada OSS, maka merawatnya adalah pekerjaan infrastruktur untuk barang publik, bukan pencurian

  • “Harus minta izin”

    • Meminta izin adalah tindakan yang mempertahankan ketimpangan kuasa
    • Tidak perlu restu manajer untuk merawat infrastruktur yang sudah diandalkan pemberi kerja

  • “Ini seperti quiet quitting”

    • Quiet quitting mengurangi beban kerja, sedangkan ini adalah tindakan memproduksi infrastruktur OSS yang membangun internet
    • Masalahnya bukan pada pekerjaannya, melainkan pada penolakan perusahaan untuk mengklasifikasikannya sebagai pekerjaan

  • “Pemberi kerja yang baik juga dirugikan”

    • Pemberi kerja yang baik bisa menghindari masalah ini dengan mengizinkan pemeliharaan open source di jam kerja, mendanai maintainer, atau berpartisipasi dalam Open Source Pledge

Pengalaman Mike McQuaid

  • Salah satu pendiri Open Source Friday dan GitHub Sponsors, serta pemimpin proyek Homebrew (maintainer sejak 2009)
  • Di tidak satu pun tempat kerja, pekerjaan pada proyek open source seperti Homebrew pernah dibayar sebagai tugas utama
  • Meski begitu, ia tetap melakukannya di semua pemberi kerja, menegosiasikan kontrak IP agar legal, dan tetap memenuhi komitmen pekerjaannya
  • Setelah memiliki anak, lebih dari 90% pekerjaan open source dilakukan pada jam kerja
  • Seperti yang ia tulis dalam Open Source Maintainers Owe You Nothing, tidak ada siapa pun yang berhak menuntut waktu malam, akhir pekan, atau waktu keluarga yang tidak dibayar dari seorang maintainer hanya karena model bisnis sebuah perusahaan bergantung pada kodenya

Hal yang perlu diperhatikan dan pemberitahuan hukum

  • Bukan nasihat hukum

    • Isi ini secara tegas menyatakan bahwa ini bukan nasihat hukum, dan bukan saran terkait kontrak, pemberi kerja, status imigrasi, kewajiban lisensi, atau situasi individual
    • Jika risikonya besar, konsultasikan dengan pihak yang kompeten sebelum bertindak
    • Seperti kebanyakan lisensi open source, tidak ada jaminan apa pun dan semuanya diberikan “apa adanya”

  • Kontrak, kebijakan, dan kepemilikan

    • Kontrak kerja, kebijakan handbook, dan klausul pengalihan invensi dapat mengklaim hak atas karya yang dibuat selama masa kerja, dengan perangkat pemberi kerja, atau dalam lingkup tanggung jawab pekerjaan
    • Di beberapa negara bagian, klaim hak seperti ini dibatasi untuk karya yang dibuat pada waktu pribadi dan dengan perangkat pribadi, tetapi detailnya sangat penting
    • Sebelum menjalankannya, Anda harus membaca kontrak kerja dan memastikan pemberi kerja tidak memiliki IP open source yang ingin Anda publikasikan
    • Jika perangkat, jaringan, atau akun mengubah risiko kepemilikan, gunakan milik Anda sendiri

  • Negosiasi kontrak IP

    • Pengalihan IP sering kali bisa dinegosiasikan, dan dianjurkan untuk meminta klausul pengecualian open source secara tertulis saat menerima tawaran kerja, sebelum menandatangani
    • Baca dulu employee IP agreement untuk memahami bagian mana yang perlu ditolak
    • Mike McQuaid mengatakan ia telah menegosiasikan perubahan dari kontrak standar dengan hampir semua pemberi kerjanya, dan sebagian besar menolak jauh lebih sedikit dari yang diperkirakan
    • Anda dapat menunjukkan Balanced Employee IP Agreement milik GitHub kepada calon pemberi kerja
    • Perjanjian ini di-open-source-kan dengan CC0, telah benar-benar digunakan oleh perusahaan publik besar, dan dirancang agar pemberi kerja memiliki apa yang mereka bayar, sementara karyawan tetap memiliki pekerjaan open source yang tidak bersaing dengan bisnis

  • Kerahasiaan dan keamanan

    • Jangan pernah mengungkap repositori privat, kredensial, insiden, data pelanggan, roadmap, kerentanan yang belum diungkap, atau diskusi internal
    • Jangan melewati kontrol keamanan atau menggunakan hak akses yang tidak diizinkan
    • Aksi langsung bukan alasan untuk membocorkan informasi rahasia perusahaan, melainkan menjaga pekerjaan publik tetap publik dan memisahkannya dengan jelas dari rahasia dagang

  • Diam bukan berarti ceroboh

    • Saat kebijakan, kontrak, kewajiban pada pelanggan, atau aturan keselamatan mengubah risiko, diperlukan pertimbangan sendiri
    • Anda mungkin perlu bekerja dengan perangkat, akun, dan jaringan Anda sendiri
    • Ini bukan “mencuri” dari perusahaan, tetapi menyeimbangkan apa yang perusahaan ambil dari open source dan apa yang bisa Anda berikan
    • Anda mungkin mendapat penilaian kinerja yang lebih rendah daripada rekan kerja, tetapi B yang berkelanjutan lebih sehat daripada menghabiskan hidup demi A di perusahaan yang besok pun bisa memecat Anda

  • Batas penerapan

    • Argumen ini paling lemah ketika waktu ditagihkan ke pelanggan tertentu, hibah, lembaga pemerintah, proyek pertahanan, atau lingkungan yang teregulasi
    • Juga paling lemah bagi engineer junior atau engineer tidak stabil yang tidak punya pengaruh untuk menanggung konsekuensinya
    • Paling kuat bagi maintainer senior yang memperbaiki dependensi publik yang memang sudah digunakan pemberi kerjanya
    • Bentuk yang paling rapi bukanlah “lakukan apa pun yang Anda mau di jam kerja”, melainkan memperlakukan pemeliharaan open source sebagai bagian dari pekerjaan engineering
    • Pertahankan proyek yang memang sudah Anda rawat, tingkatkan alat bersama yang bersentuhan dengan pekerjaan Anda, dan hindari hal yang tidak terkait, kode proprietari, atau sesuatu yang membuat komitmen nyata terabaikan

Sumber dan proyek

Bacaan terkait

2 komentar

 
roxie 2026-05-22

Secara keseluruhan,,, sepertinya ungkapan "resistance" memang yang paling tepat.
 
GN⁺ 2026-05-15
Komentar Hacker News

  • Cukup sering perusahaan memberi izin menyeluruh untuk berkontribusi ke proyek open source tertentu
    Cara menyampaikannya penting. Bukan, “bolehkah saya melakukan sedikit amal supaya merasa senang?”, melainkan, “bolehkah saya mendapatkan review ketat gratis dari para ahli di bidang ini, lalu memasukkan perbaikan ke proyek open source upstream agar biaya maintenance perusahaan di masa depan hilang?”
    Itulah inti sebenarnya, dan ketika disampaikan seperti itu, belum pernah ada pemberi kerja yang menolak. Ini sepenuhnya sejalan dengan kepentingan perusahaan, jadi kita hanya perlu membantu mereka melihatnya

    • Salah satu alasan besar saya masih menyesal diberhentikan dari pekerjaan lama adalah karena saat itu kami sedang membahas apakah perubahan besar yang saya buat pada library Kafka Streams akan dirilis sebagai open source
      Sebagian besar API tetap kompatibel, tetapi banyak bagian ditulis ulang, dengan penekanan pada I/O non-blocking yang memungkinkan penggunaan semantik backpressure bila diperlukan. Ini membuka hal-hal menarik karena state store bisa dipakai bersama I/O blocking/non-blocking sambil tetap mempertahankan performa yang cukup baik, dan saya sangat bangga karena proyek ini berhasil mengangkat performa di banyak titik yang tidak terlalu terlihat
      Saya sempat mendorong agar ini dipublikasikan di GitHub atau dikirim sebagai PR ke proyek upstream Kafka Streams, tetapi sebelum itu terjadi ada PHK, dan setelahnya tidak ada lagi champion yang bisa mendorongnya, jadi akhirnya terkunci sebagai kode proprietary
      Saya masih kadang berpikir untuk membuatnya ulang dari nol dan merilisnya sebagai open source bebas. Sudah cukup lama berlalu, jadi sepertinya tidak masalah kalau saya tulis ulang dan rilis, tidak ada hal seperti paten juga, dan ada beberapa hal yang ingin saya ubah, seperti menghapus dependensi Vert.x. Mungkin suatu hari kalau saya punya waktu libur sekitar seminggu, saya akan mencobanya
    • Saya kangen masa bekerja di tempat yang mengizinkan hal seperti ini
      Ada perusahaan yang bahkan hanya dengan proses review legal saja sudah jadi berbelit
      Suatu kali saya minta izin apakah boleh mengirim patch ke sebuah proyek, dan muncullah rangkaian email yang menarik. Pada akhirnya pertanyaannya cuma satu: jika ini adalah patch yang ditulis untuk memperbaiki bug pada produk yang kami kirim, dikerjakan pada waktu yang ditagihkan ke pelanggan, library yang sudah dipatch harus dikompilasi ulang dan dikirim bersama source code, dan kontraknya menyatakan semua hasil kerja serta hak kekayaan intelektual terkait produk dialihkan ke pelanggan, apakah kami punya hak untuk merilis patch itu ke domain publik?
      Tim legal tidak ingin menjawab
    • Ini umumnya pendekatan yang baik dan contoh bagus bagaimana membingkai pekerjaan secara profesional. Hanya saja, ini tidak menyelesaikan inti masalah. Terutama pada kepemimpinan perusahaan yang berorientasi engineering, mereka seharusnya langsung memahami manfaat ini; kalau tidak, itu sendiri sudah masalah
      Seberapa jauh pendekatan ini bisa berhasil juga sangat ditentukan oleh keberuntungan soal pemberi kerja
    • “Baik, nanti saya teruskan ini ke tim compliance dulu. Hanya untuk memastikan tidak ada pelanggaran hak kekayaan intelektual. Tepatnya repository dan issue yang mana?”

  • Soal pernyataan “dan pastikan Anda benar-benar memiliki hak atas kekayaan intelektual open source yang Anda rilis”, di yurisdiksi tempat saya pernah bekerja, kode yang ditulis dan dirilis pada jam kerja adalah milik pemberi kerja, bukan milik saya
    Saya tidak bisa memutuskan sendiri untuk berkontribusi pada jam kerja, dan kalau ingin mengerjakan kode open source harus ada persetujuan resmi. Setiap kali meminta, prosesnya melewati bagian legal selama berbulan-bulan, sampai akhirnya saya menyerah, atau selama itu kontributor lain sudah lebih dulu mengirim PR sehingga saya tidak jadi meminta lagi

    • Mungkin maksudnya adalah “jangan sembarangan menyumbangkan hasil kerja yang bukan milik Anda.” Ada bagian terpisah di bawah yang membahas ini, tetapi kalau hanya melihat bullet point di atas, memang membingungkan
      Bagi developer berpengalaman ini mungkin sudah jelas, tetapi untuk beberapa developer junior di sejumlah perusahaan, ini benar-benar jadi masalah. Ketika perusahaan sedang mengerjakan sesuatu yang keren di proyek internal, mereka bisa berpikir akan bagus jika hal itu disumbangkan ke proyek open source tertentu, tanpa mempertimbangkan bahwa mereka lalu memakai pengetahuan dari kode privat untuk mengirim kode yang secara substansial mirip, atau kadang malah copy-paste langsung
    • Saya belum meneliti langsung, tetapi setahu saya di Jerman secara default semua source code yang dibuat pada jam kerja dimiliki oleh pemberi kerja
      Sebagian besar pemberi kerja yang tidak berfokus pada IT mungkin bahkan tidak memahami apa itu open source atau bagaimana cara kerjanya. Jadi mendapatkan izin dari banyak orang bisa terasa putus asa
      Menurut saya situs yang ditautkan sebaiknya lebih fokus menjelaskan manfaat open source kepada pemberi kerja terlebih dahulu, serta mendorong adanya panduan hukum untuk pemberi kerja
    • Kalau sebuah perusahaan tidak mengizinkan kode dirilis dengan lisensi permisif, kecuali untuk bagian yang masuk ke production mereka, saya rasa saya tidak akan bekerja di sana. Bagi saya itu sangat mematikan motivasi dan bisa mendorong saya ke batas mental. Saya lebih memilih miskin daripada begitu

  • Ini ide yang bagus, bahkan ide yang sangat bagus, tetapi saya tidak yakin memosisikannya sebagai resistance itu tepat
    Tujuan pekerjaan biasanya adalah mencapai sasaran tertentu. Bagaimana cara mencapainya seharusnya bisa diputuskan oleh developer sebagai profesional. Jika keputusan itu mencakup software open source, maka merawatnya juga seharusnya menjadi bagian dari keputusan tersebut
    Ini bukan tindakan radikal, hanya melakukan pekerjaan sambil menjaga stabilitas masa depan dan kemudahan maintenance dari hal-hal yang menjadi sandaran pekerjaan itu

    • Ini juga sekadar naluri bisnis yang baik. Perusahaan yang mendorong kolaborasi lewat open source pada dasarnya sedang memelihara ekosistem yang menopang bisnis mereka sendiri
    • Saya setuju dengan semua yang Anda katakan, tetapi realitas kebanyakan perusahaan teknologi sekarang, setidaknya dari pengalaman saya, berbeda. Mereka bahkan tidak mau meluangkan waktu untuk maintenance infrastruktur dan library mereka sendiri kecuali dipaksa, apalagi open source
      Fitur tidak berguna demi permainan metrik, enshittification, dark pattern, dan integrasi tren yang nyaris seperti malware lebih diprioritaskan daripada investasi pada infrastruktur dasar atau library
    • Setuju. Penggambaran seperti ini membuatnya terlihat seperti seseorang hanya ingin menarik lebih banyak perhatian di media sosial. Sedih rasanya kita sudah sampai di titik di mana semuanya harus dibesar-besarkan

  • Secara umum saya sepenuhnya setuju, tetapi menurut saya pelaksanaannya memang rumit. Saya bukan pengacara, tetapi secara umum saya paham bahwa pemberi kerja memiliki hak kekayaan intelektualnya, jadi merilis sesuatu sebagai open source memerlukan izin eksplisit
    Dan proses mendapatkan izin itu sering kali sulit, melewati prosedur tanpa akhir dan bagian legal
    “Di Amerika Serikat, Inggris, dan berbagai yurisdiksi lain, jika seorang karyawan membuat sebuah karya sebagai bagian dari pekerjaannya, pemberi kerja dianggap sebagai penulis sah atau pemegang hak cipta pertama”
    https://en.wikipedia.org/wiki/Work_for_hire
    Meski begitu, saya tetap berpikir pekerjaan open source—yakni maintenance dan development—harus dilakukan oleh profesional bergaji, bukan relawan yang mengemis donasi. Pertanyaan kuncinya adalah bagaimana mewujudkannya, dan bagaimana membuat perusahaan menerima kontribusi open source sebagai praktik standar, bukan pengecualian yang perlu dinegosiasikan satu per satu

    • Masalah-masalah yang dijelaskan itu lebih dekat ke “masalah teoretis” daripada “masalah praktis”
      Dalam praktiknya, ya tinggal dilakukan saja. Tidak ada subrutin di komputer yang mencegah git push. Pada praktiknya, pemberi kerja menaruh macam-macam hal di kontrak kerja. Mereka menulis sebanyak mungkin untuk menghindari tanggung jawab dari segala arah. Kalau mereka bisa seenaknya menulis begitu, kenapa kita tidak bisa begitu saja melakukannya? Tidak ada yang penting
      Pada kenyataannya, hampir nol proyek open source yang benar-benar ditantang soal hak kekayaan intelektual karena alasan teknis seperti ini
    • Benar bahwa jika pekerjaan itu terkait dengan tugas Anda, maka pemberi kerja memegang hak kekayaan intelektualnya
      Jika tidak terkait dengan tugas Anda, aturannya berbeda-beda tergantung negara bagian. Banyak negara bagian membatasi sejauh mana pemberi kerja bisa mengklaim sesuatu sebagai hak kekayaan intelektual mereka. Kontrak standar sering memakai bahasa yang sangat luas untuk mengklaim semuanya, tetapi hukum sering mengatakan perusahaan tidak bisa mengambil pekerjaan waktu luang yang tidak terkait dengan bisnis pemberi kerja
      Jika dilakukan pada jam kerja atau memakai laptop kantor, itu memberi perusahaan ruang untuk mengklaim hak. Kebanyakan perusahaan mungkin tidak peduli, tetapi kalau ingin tetap bersih jika nanti ada sengketa, jangan lengah
      Kerjakan di waktu pribadi, dengan perangkat pribadi, dan pastikan tidak tumpang tindih dengan pekerjaan yang Anda dibayar untuk lakukan atau hal-hal yang Anda ketahui dari perusahaan
    • Saya bukan pengacara, tetapi kalau Anda memberi salinan ke rekan kerja agar mereka bisa menjalankannya, bukankah itu sendiri sudah berarti memakai lisensi open source? Rekan kerja itu lalu memperoleh hak hukum yang diberikan lisensi tersebut, dan bukankah itu juga memberi mereka hak untuk mendistribusikan ulang perubahan?
      Mengirim perubahan ke upstream adalah cara terbaik untuk memastikan maintenance, jadi semua ini terasa sangat konyol. Hal yang sama juga berlaku untuk ketidakpastian hukum dalam memelihara fork proprietary internal
    • Tulisan itu tampaknya menyarankan untuk mengambil jalur dengan resistensi paling kecil. Kerjakan di waktu perusahaan, jangan bikin gelombang besar. Kalau ketahuan, tinggal minta maaf. Dari sudut pandang perusahaan, memaafkan adalah jalan termudah. Kalau melibatkan pengacara, biayanya jadi sangat besar dan bisa berubah jadi mimpi buruk PR
    • Jika ada satu hal yang ditunjukkan oleh keadaan pemrograman saat ini, itu adalah bahwa hukum hak kekayaan intelektual dan hak cipta pada dasarnya sudah tidak ada lagi

  • Saya bekerja di perusahaan yang cukup besar. Kebijakan open source perusahaan kami kira-kira bisa diringkas menjadi “tanya manajer dulu, jangan pakai nama perusahaan, dan jangan membocorkan informasi rahasia”
    Tidak pernah jadi masalah, dan secara garis besar rasanya sepenuhnya masuk akal

  • Saya rasa berkontribusi seperti perbaikan bug ke proyek open source pihak ketiga pada jam kerja tidak masalah, tetapi saya tidak tahu bagaimana seharusnya menangani open source milik sendiri
    Misalnya saya punya library kecil yang saya buat secara pribadi, lalu dipakai di kantor, dan saya menemukan bug pada jam kerja. Kalau saya berkontribusi pada jam kerja, itu terasa seperti area abu-abu
    Adakah yang pernah menegosiasikan hal seperti ini saat wawancara? Penasaran bagaimana caranya

    • Saya belum pernah bekerja di perusahaan yang benar-benar peduli soal ini. Saya hanya mengerjakan apa yang perlu dikerjakan. Bahkan ketika saya bertanya bagaimana cara melakukannya “dengan benar”, saya tidak pernah mendapat jawaban

  • Saat bekerja di perusahaan besar, umumnya setiap permintaan untuk mengerjakan sesuatu selain menulis kode langsung ke codebase perusahaan akan dijawab manajer langsung dengan “kerjakan di waktu luang” meskipun alasannya jelas
    Dalam lingkungan yang berorientasi laba, yang dianggap layak dikejar hanyalah nilai yang langsung terlihat. Sikap ini cukup parasitik, dan dorongan efisiensi lebih tinggi serta perlombaan metrik dari atas membuatnya begitu

  • Saya jelas pernah mem-fork sesuatu untuk memperbaikinya demi menyelesaikan masalah pekerjaan, lalu mengirim hasilnya ke upstream sebagai PR
    Itu salah satu hal baik dari memakai dan memiliki akses ke open source. Ini juga alasan git nyaris menjadi opsi kelas satu di package.json dan cargo.toml: Anda bisa langsung menunjuk ke fork sampai perubahan itu masuk ke upstream

  • Ketika Anda sudah senior, pada tahap wawancara saat mereka bertanya, “ada pertanyaan untuk kami?”, saya akan bertanya, “bagaimana sikap perusahaan ini terhadap saya menggunakan sebagian waktu saya untuk berkontribusi pada proyek open source yang menjadi ketergantungan perusahaan?”
    Lalu Anda bisa memutuskan dari jawabannya apakah ingin lanjut atau tidak