Left-Pad (2024)

• insiden left-pad adalah contoh representatif yang menunjukkan benturan aturan dan nilai antara komunitas open source, NPM, dan perusahaan
• Keputusan untuk menghapus paket lahir dari ketulusan dan prinsip internal, bukan karena logika, kemarahan, atau keserakahan
• Dalam situasi ketika NPM melanggar aturan mereka sendiri dengan tunduk pada tuntutan Kik Messenger, penulis memilih untuk menghapus semua paketnya
• Setelah insiden itu, gairah terhadap open source berubah, dan minat bergeser ke bidang baru seperti bisnis, pemasaran, serta pengelolaan tim
• insiden left-pad menjadi momentum yang mendorong developer dan industri startup untuk kembali memikirkan hakikat open source dan kompleksitas pengambilan keputusan

---

Latar belakang insiden dan keputusan

• Delapan tahun setelah insiden left-pad terjadi, penulis membagikan pengalaman dan pemikiran pribadinya
• Pada saat insiden, ia menghabiskan sebagian besar waktunya di alam tanpa sinyal, melakukan refleksi diri, dan keputusan untuk menghapus paket juga lahir dari proses ini
• Keputusan ini berangkat dari keyakinan atas prinsip batinnya, bukan dari penilaian logis, kemarahan, atau keserakahan, yaitu: "Jika NPM melanggar aturan mereka sendiri, maka semua paket saya juga harus dihapus"
• Ini bukan semata sikap seorang "penganut aturan yang kaku", melainkan pendekatan yang lebih menekankan semangat dari aturan itu sendiri
• Dalam situasi di mana perusahaan seperti Kik Messenger memberi ancaman dan menggunakan kekuatan terhadap komunitas open source, NPM mengabaikan aturan yang mereka tetapkan sendiri dan memprioritaskan kepentingan perusahaan

Struktur konflik antara NPM dan komunitas

• Penulis tidak takut terhadap ancaman dari Kik, tetapi NPM takut kehilangan Kik
• Menafsirkan insiden ini hanya sebagai "seorang pria marah yang melawan perusahaan besar" adalah penyederhanaan yang mengabaikan konteks insiden, alur waktunya, dan bobot keputusan tersebut
• Pihak NPM, meski ini bukan sesuatu yang mendadak atau tak terduga, secara umum menunjukkan sikap yang arogan terhadap developer, dan melalui serangkaian keputusan yang tidak konsisten, melemparkan seluruh tanggung jawab kepada penulis

Struktur paket dan dampaknya

• Sebagian besar karya open source penulis dibagi menjadi peran-peran kecil sesuai filosofi Unix, sehingga terdiri dari lebih dari 350 paket
• Di permukaan nyaris tidak ada jejak penggunaan, tetapi karena NPM tidak membuka statistik penggunaan, mustahil mengetahui cakupan dampaknya
• Pengguna tidak punya cara untuk mengetahui dampak nyata dari penghapusan paket, dan NPM juga tidak berupaya menyelidiki dampaknya atau mencegah masalah akibat penghapusan yang serampangan

Perubahan dan pertumbuhan setelah 8 tahun

• Beberapa bulan setelah insiden left-pad, penulis berhenti dari pekerjaan utamanya dan meninggalkan Amerika Serikat, lalu mencari jalannya sendiri di lingkungan baru seperti Maroko, Yordania, Turki, dan Indonesia
• Ia mengalami momen seperti kematian ketika gairah terhadap open source terputus, lalu momen terlahir kembali melalui minat-minat baru
• Saat ini ia menekuni berbagai bidang seperti bisnis, pemasaran, pengelolaan perusahaan dan tim dengan gairah yang sama seperti saat memrogram
• Sambil menyampaikan pesan bahwa hidup terus berjalan, insiden left-pad tetap menjadi kesempatan untuk meninjau kembali kebebasan dalam mengambil keputusan, nilai komunitas, dan kompleksitas proses pengambilan keputusan

[ndrgrd]

Ini memang kejadian yang berdampak besar, tetapi bahkan tanpa membaca tulisan dari pembuat paket tersebut, saya merasa kesalahan yang lebih besar ada pada perusahaan-perusahaan dan sistem yang terlibat daripada pada dirinya.

[GN⁺]

Opini Hacker News

• Sejujurnya saya merasa seperti tidak benar-benar paham setengah dari isi tulisan blog ini, seolah ada konteks yang saya lewatkan, tetapi saya suka bahwa "left pad guy" merangkum kejadian ini
  Namun, klaim berikut terasa agak aneh

  Tapi saya tetap tidak mengerti kenapa NPM tidak meneliti seberapa banyak modul-modul saya dipakai, dan tidak memikirkan cara menangani unpublishing agar tidak ada yang rusak
  Tentu saja cara unpublish NPM memang dirancang dengan buruk, tetapi yang dikatakan penulis terasa seperti ia berharap ada pemeriksaan manual setiap kali seseorang melakukan unpublish. Ekspektasi seperti itu tidak tampak masuk akal. Saya melihat NPM bukan sebagai organisasi yang mengkurasi registry, melainkan sebagai pihak yang menyediakan layanan publik
  Meski begitu, saya juga sulit menyalahkan penulis; kalau bukan penulis yang memicu "left-pad incident", saya rasa tak lama lagi orang lain pun akan melakukannya. NPM sudah memperbaiki masalah tersebut, dan juga menetapkan kebijakan unpublish yang lebih baik
  Sebagai referensi, lihat kebijakan unpublish baru NPM

  • Anda bilang tidak mengerti setengah dari tulisan blog ini
    Penyebabnya mungkin karena Anda belum membaca al-Ghazali.
    (Ini bagian yang paling pongah dan egosentris dalam tulisan itu)

  • Konteks tambahan bisa dilihat di Wikipedia insiden Npm left-pad

  • Pada 18 Maret 2016, CEO npm Isaac Z. Schlueter mengirim email ke Kik Interactive dan Koçulu untuk memberi tahu bahwa kepemilikan paket kik akan dipindahkan secara manual ke Kik Interactive
    Setelah Koçulu menyatakan kekecewaannya atas keputusan npm dan mengatakan ia tidak lagi ingin berpartisipasi di platform itu, Schlueter memberinya perintah untuk menghapus seluruh 273 modul yang telah ia daftarkan
    Koçulu menjalankan perintah itu pada 22 Maret dan menghapus semua paket yang ia unggah
    Penulis hanya menjalankan perintah yang diberitahukan langsung oleh pihak NPM, tetapi setelah itu NPM melemparkan seluruh tanggung jawab kepadanya

  • Perusahaan bernama NPM tidak mengkurasi registry NPM
    Pada praktiknya mereka memang mengkurasi, misalnya menerima laporan kerentanan keamanan dan memberi tahu pengguna, atau menghapus paket berbahaya

  • Dulu saat saya menggunakan Sourceforge, ada kebijakan yang mewajibkan meminta izin sebelum menghapus proyek
    Setelah left-pad, saya jadi benar-benar paham alasannya

• Hal kecil saja

  Sebagian besar proyek open source saya dirancang mengikuti filosofi Unix, agar paket-paket hanya melakukan satu hal pada satu waktu
  Tidak ada yang berpendapat bahwa libc melanggar filosofi Unix. Perdebatan biasanya muncul soal apakah sebuah command atau daemon punya terlalu banyak fungsi (systemd adalah contoh khas), atau apakah komposabilitasnya buruk

  • Saya rasa insiden left-pad menunjukkan bahwa granularitas paket NPM menjadi terlalu kecil, sehingga overhead-nya jauh lebih besar daripada manfaat dari penyederhanaan paket

  • Tidak ada yang bilang libc melanggar filosofi Unix
    Justru banyak orang pernah mengusulkannya, dan saya sendiri juga merasa itu benar
    libc modern sama sekali berbeda dari filosofi Unix tradisional
    libc lama lebih sederhana, banyak fungsi dipisahkan ke library lain seperti libm, dan hal-hal rumit seperti DNS belum ada

  • Hal yang berlawanan dengan 'do one thing' adalah, 'lakukan satu hal itu secara utuh'
  • Filosofi Unix adalah pedoman untuk membangun lingkungan pemrograman interaktif yang kuat di minikomputer 16-bit
    libc yang saya pakai di ponsel sekarang berukuran 1MiB, 16 kali lebih besar daripada Unix tradisional
    Kesimpulannya, setidaknya 90% dari libc bertentangan dengan filosofi Unix
    Jika membaca Lions Book atau APUE lalu melihat manual pthreads atau spesifikasi ANSI C setlocale(), akan jelas bahwa itu filosofi yang sepenuhnya berbeda
    Jika menganggap keduanya sama, itu justru bukti bahwa Anda tidak benar-benar bersimpati serius pada salah satu dari dua filosofi tersebut
  • "Filosofi Unix" adalah filosofi yang tidak berguna, bahkan bisa berbahaya
    Karena makna 'one thing' tidak jelas, pada praktiknya ia tidak membantu apa-apa dan hanya memicu perdebatan
    Eclipse juga bisa dianggap hanya melakukan 'satu hal', yaitu menjadi IDE, tetapi jelas itu bukan maksud para pengembang Unix
    Itu juga bukan berarti kita harus membuat library yang hanya berisi fungsi 11 baris
    Nasihat yang sebenarnya mestinya lebih seperti "jangan biarkan program atau library melakukan terlalu banyak, tapi juga jangan terlalu sedikit"
    Menentukan mana yang terlalu banyak dan mana yang terlalu sedikit pada akhirnya adalah soal pengalaman dan intuisi

• Terima kasih kepada akoculu yang sudah menulis ini
  Saya rasa ini contoh yang sangat jelas dari komunitas JavaScript, yaitu ekosistem yang terlalu bergantung pada dependency
  Saya tidak paham kenapa begitu banyak orang menyalahkanmu sebesar itu
  Kamu hanya melakukan unpublish pada sebuah paket dengan kode 11 baris, dan mungkin tidak sepenuhnya bisa memprediksi efek sampingnya
  Penulis sendiri menyebutkan dalam tulisannya

  NPM juga tidak menampilkan statistik penggunaan dengan baik, dan hampir tidak ada aktivitas di Github
  Dari sudut pandang pengguna, sulit mengetahui dampak dari melakukan unpublish pada paket
  Saya rasa akar masalahnya bukan pada unpublish yang dilakukan akoculu, melainkan pada ketergantungan yang berlebihan, kebijakan npm, serta kurangnya caching/vendoring pada build system
  Lihat wiki latar belakang insiden

• Riwayat versi paket kik terasa aneh
  Sembilan tahun lalu itu digantikan oleh security holding package
  riwayat versi paket kik

  Ironi terbesar dari semua ini justru adalah paket kik
  Paket kik yang begitu ingin direbut oleh kik pada akhirnya sama sekali tidak berguna
  Dan perusahaan bernama Kik ternyata adalah tempat yang ceroboh dan bermasalah
  Ada kontroversi terkait kripto, dan juga reputasi sebagai platform yang diam-diam disebut-sebut terkait distribusi pornografi anak dan semacamnya
  Lihat Darknet Diaries episode 93
  Karena itu, saya justru merasa puas melihat Azer Koçulu bersikap tegas menolak Kik

  Jadi semua ini pada akhirnya... ternyata sama sekali tidak berarti?

• Fakta bahwa left-pad ada sebagai sebuah paket itu sendiri cukup lucu
  Hanya demi satu fungsi padding string, sejumlah byte yang sangat besar berpindah melalui CDN, proxy, build pipeline, dan sebagainya
  Saya setuju soal memanfaatkan solusi yang sudah ada dengan baik, tetapi sulit memahami situasi di mana orang berpikir "mungkin ada paket untuk itu" hanya untuk fungsi sederhana yang menambahkan padding di depan string

  Sebagian dari perdebatan saat itu menjadi pengingat tentang obsesi buta para web developer terhadap micro-package
  Ada juga budaya merilis paket demi popularitas atau Github star
  Di sisi lain, ada budaya yang begitu kuat untuk tidak mengimplementasikan fungsi apa pun sendiri selama itu bisa di-install lewat npm
  Banyak developer yang bekerja dengan saya sekarang pun masih sering lebih memilih paket sederhana seperti itu
  Bagi mereka, logikanya adalah "beban maintenance jadi berkurang"
  Kenyataan yang sangat ironis

  Implementasi asli paket itu sendiri tampaknya juga menimbulkan operasi tidak efisien O(n^2), bukan O(n)
  lihat Wikipedia

  Apakah ada perbedaan kualitas yang besar antara mengambil referensi fungsi utilitas dari proyek orang lain, dan memakai paket yang sudah tersebar di seluruh ekosistem?
  Memang tidak sama, tetapi dalam lingkungan dengan tooling yang cukup matang, menurut saya kedua pendekatan itu secara praktis tidak terlalu jauh berbeda

  Fenomena mengejar reuse kode semaksimal mungkin, seolah copy-paste adalah cara yang sudah ketinggalan zaman

  Jangan-jangan ini mirip dengan AI?
  Realitas di mana orang kembali bertanya ke AI dengan tak terhitung banyaknya prompt untuk masalah yang sebenarnya bisa diselesaikan dengan pencarian sederhana
  Struktur yang hanya menambahkan satu langkah tak perlu di atas C&P

• Filosofi Unix adalah "lakukan satu hal dengan baik"
  left-pad gagal pada syarat kedua (dengan baik)
  Saya terkejut bahwa begitu banyak proyek memakai implementasi naif itu apa adanya
  Implementasi yang lebih optimal bisa jadi lebih cepat sekaligus lebih kecil

  Saya tidak terlalu paham budaya JavaScript, tetapi saya ingat pernah ada kecenderungan berlomba menaikkan angka download npm
  left-pad punya 1,4 juta download per minggu, is-even 160 ribu download
  Sebagian orang melakukannya sebagai lelucon, sebagian lagi untuk menaikkan metrik popularitas library mereka dengan menambahkan micro-package ke dependency
  Bahkan ada suara penolakan terhadap penggunaan paket seperti is-even di dalam library terkenal berbasis react
  Karena ada prinsip kaku semacam "kalau bisa diambil, ambil saja, meski kodenya bisa ditulis sendiri"
  Cerita terkait: mengapa paket is-odd terpasang hampir 3 juta kali dalam seminggu

  Saya penasaran contoh 'implementasi nonnaif'

• Saya maintainer paket npm yang populer
  Saya sangat bisa memahami ini
  Sejak titik tertentu, npm mulai menjauh dari kolaborasi komunitas
  Akuisisi oleh Microsoft membuatnya makin kokoh, tetapi tanda-tandanya sudah banyak bahkan sebelumnya
  Banyak hal tentang cara npm beroperasi, sikapnya yang tidak kooperatif dengan komunitas/tim Node, fokus berlebihan pada komersialisasi, reputasi beberapa anggotanya, dan berbagai hal lain terasa mengganggu
  Saya ingat pernah berkunjung ke kantor mereka di Oakland, tetapi interaksi hari itu tidak terlalu positif jadi saya tidak akan membahas detailnya
  Celah unpublish saat itu adalah masalah yang semua orang sudah tahu
  Semua orang menyalahkan penulis seolah-olah 'left-pad merusak internet', tetapi saya rasa masalah yang lebih besar justru adalah buruknya pengelolaan npm
  Kalau ingatan saya benar, mereka memulihkan paket itu secara paksa meski bertentangan dengan keinginan maintainer-nya sendiri, dan itu adalah tindakan yang sepenuhnya terpisah dari level komunitas yang mereka klaim wakili (setidaknya secara hukum juga terasa janggal)
  Setelah itu npm nyaris tidak menunjukkan minat untuk mengelola abuse, spam, dan semacamnya (seperti spam iklan core.js), dan juga hampir tidak terlibat dalam diskusi standar maupun kompatibilitas dengan komunitas
  Rilis npm@5 juga kegagalan besar, dan pengenalan package lockfile juga kacau
  (Fakta bahwa tim Node merilis tanpa menunggu kesiapan npm malah menurut saya keputusan yang bagus)
  Pada saat itu komunikasi dengan komunitas benar-benar buruk, penuh bug besar, menyalahkan komunitas, dan sikap yang arogan
  Itu menjadi bukti bahwa npm tidak lagi menjadi representasi semangat open source
  Saya agak lupa apakah left-pad terjadi sebelum atau sesudah itu, tetapi seluruh ekosistem saat itu memang sedang berada dalam periode stagnasi dan kekacauan jangka panjang
  Paket npm sering dianggap seperti paket terpisah untuk fungsi-fungsi sepele, hampir seperti meme, tetapi jika melihat konteksnya, npm adalah package manager pertama yang benar-benar mudah diakses untuk emergent popular technology, dikelola oleh komunitas, dan terintegrasi erat dengan Github
  Itu terjadi pada masa awal Node (bahkan sebelum ada ES5, saat orang masih memakai var dan prototype), sebelum Joyent menyerahkan Node.js ke komunitas, dan sebelum fork Io.js serta masa stagnasi panjang Node 0.10/0.12
  Itu masa ketika belum ada yang benar-benar tahu apa best practice-nya
  Saya sangat bersimpati pada posisi penulis
  Dari sudut pandang keamanan, insiden left-pad menjadi momen besar yang secara tak sengaja menyadarkan banyak pihak tentang keterpisahan antara perusahaan/komunitas di dalam ekosistem dan juga tentang keamanan supply chain
  Itu memicu diskusi penting tentang redundansi dan keamanan
  Saya rasa pada akhirnya industri justru menjadi lebih baik karenanya
  Menarik membacanya lagi setelah sekian lama

  npm bukan package manager pertama untuk bahasa apa pun, dan sudah banyak orang memperingatkan soal begitu banyaknya paket sekecil ini
  Saya rasa npm dan ekosistem JS secara umum menjadi korban dari tren

• Diskusi terkait saat left-pad terjadi
  diskusi Hacker News

• Mengapa Java punya utility library tepercaya seperti Apache Commons dan Google Guava, sedangkan JS tidak?

  JavaScript juga punya utility library tepercaya seperti Lodash. Dibanding masa lalu, sebagian besar fungsinya sekarang sudah masuk ke standard library
  Bahkan, Lodash sudah menyediakan fungsi pad/padStart/padEnd sejak tiga bulan sebelum insiden left-pad
  dokumentasi Lodash pad

  Menurut saya penyebab terpentingnya adalah budaya, lalu standard library yang tertata baik, lalu ada atau tidaknya alat yang mencegah orang menyisipkan lebih dari 300 paket tak berguna ke dependency

  Maven adalah tool yang benar-benar dirancang dengan baik (ironisnya selalu dicaci), dan itu salah satu faktor rahasia kesuksesan Java
  Alasan Java tidak mengalami kompromi komersial seperti npm adalah karena Java punya Apache Foundation, organisasi nirlaba berbasis komunitas yang didukung dengan baik (struktur seperti ini sangat langka, dan merupakan hasil keberuntungan dari sejarah hukum Java yang rumit)
  (JS juga punya banyak library hebat. Masalahnya adalah manajemen paket yang terlalu tersentralisasi dan pengelolaannya buruk)

  Google Guava lebih mirip lodash, bukan left-pad

  Dulu library seperti Jquery dan Underscore juga memainkan peran itu

• Saya heran sekali ada perusahaan yang tidak melakukan mirroring internal untuk semua dependency yang dibutuhkan build
  Seluruh proses build seharusnya bisa clean build secara offline, dan bergantung hanya pada cache download pada dasarnya seperti menyerahkan semuanya pada keberuntungan

  Dalam proyek saya, dependencies selalu saya vendor secara internal
  Lebih bisa diprediksi, bisa di-build secara offline, dan biaya penyimpanan juga murah