Refleksi kasus Left-Pad 8 tahun kemudian (2024)
(azerkoculu.com)- kasus left-pad tetap menjadi contoh utama tentang dependensi open source dan otoritas pengelolaan paket bahkan setelah 8 tahun, dan Azer Koçulu menjelaskan kembali keputusannya saat itu
- Keputusan untuk menjadikannya privat bukan didorong kemarahan atau keserakahan, melainkan pilihan yang lahir dari perenungan diri, dan latar belakang utamanya adalah situasi ketika NPM melanggar aturan yang dibuatnya sendiri
- Di bawah tekanan Kik Messenger, ia memandang NPM memprioritaskan nilai lain dibanding komunitas open source, dan penilaian ini berujung pada penghapusan semua paket
- Target penghapusan mencakup lebih dari 350 paket, tetapi cakupan dampak sebenarnya sulit diketahui hanya dari statistik penggunaan dan aktivitas GitHub
- Sekitar 10 menit setelah menjalankan skrip NPM, berbagai proyek termasuk React rusak, lalu dalam beberapa jam modul dipulihkan dan situasi kembali normal
Penilaian saat kasus left-pad terjadi
- Sudah 8 tahun sejak kasus left-pad terjadi, dan Azer Koçulu merasa selama ini lebih baik menghindari topik tersebut agar bisa fokus pada pekerjaan yang benar-benar ia lakukan
- Pada 2016, ia mengambil keputusan untuk menjadikannya privat saat menghabiskan sebagian besar akhir pekan dengan berkemah di tempat terpencil tanpa sinyal
- Ia menjelaskan bahwa itu bukan keputusan yang lahir dari logika, kemarahan, atau keserakahan, melainkan pilihan yang datang dari perenungan diri di alam dan dari hati
- Prinsip penilaiannya sederhana
- Jika NPM melanggar aturannya sendiri dan menghapus salah satu paket miliknya, maka dengan standar yang sama semua paket miliknya juga harus dihapus
- Ia memandang semangat di balik aturan lebih penting daripada aturan itu sendiri
- Dalam konteks lain, ia mengakui bisa saja ada alasan yang baik untuk meminta penghapusan paket tanpa izin pemilik
- Namun dalam kasus ini, ia menilai Kik Messenger menggunakan ancaman seperti “we’ll bang on your door”, “take down your accounts” untuk menjalankan kekuasaan atas komunitas open source berbasis NPM
- Jika peristiwa ini hanya dilihat sebagai “orang yang marah memprotes kepentingan perusahaan”, maka itu akan melewatkan tanggal email dan linimasa, situasi bertahan di bawah tekanan, serta cara keputusan bergerak dalam kondisi kesadaran yang berbeda
Proses penghapusan dan dampaknya
- Dari sudut pandang NPM, ia menilai penghapusan itu bukan sesuatu yang mendadak atau tak terduga
- Ia lebih dulu meminta NPM untuk menghapus modul-modulnya dan menunggu jawaban
- Karena tidak menetapkan tenggat waktu, ia menilai NPM punya kesempatan untuk menyesuaikan API dan alat agar transisinya berjalan mulus
- Sebaliknya, NPM menyediakan skrip untuk menghapus semua paket sekaligus
- Sebagian besar karya open source miliknya adalah paket-paket kecil yang melakukan satu hal pada satu waktu, seperti filosofi Unix
- Jumlah paketnya lebih dari 350, dan semuanya telah dioptimalkan serta diuji
- Dari luar paket-paket itu tampak tidak populer, NPM tidak menampilkan statistik penggunaan, dan 90% di antaranya hampir tidak memiliki aktivitas GitHub
- Dari sudut pandang pengguna biasa, sulit mengetahui dampak seperti apa yang akan ditimbulkan jika dijadikan privat
- Setelah menjalankan skrip yang diberikan NPM, ia meninggalkan tempat itu selama beberapa menit, lalu dalam sekitar 10 menit seorang teman memberi tahu bahwa hal itu menjadi topik hangat di Twitter
- Satu dari lebih dari 350 paket tersebut merusak React dan berbagai proyek lain
- Setelah itu ia menulis posting blog singkat, menyerahkan pekerjaan open source miliknya, dan memindahkan kepemilikan repositori GitHub kepada para sukarelawan
- Dalam beberapa jam modul dipulihkan dan keadaan kembali normal
- Beberapa bulan kemudian ia berhenti dari pekerjaannya dan meninggalkan Amerika Serikat secara permanen, lalu menghabiskan satu tahun di Morocco, Jordan, Türkiye, dan Indonesia
- left-pad adalah momen seperti kematian dan kelahiran kembali, ketika sebagian dari dirinya yang menaruh hati begitu dalam pada open source menghilang dan sesuatu yang baru mengambil tempatnya, dan kini ia memiliki gairah terhadap membangun dan menjalankan perusahaan sebesar gairahnya pada pemrograman
2 komentar
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.
Komentar Hacker News
Saya merasa tidak benar-benar memahami separuh isi posting blog itu karena terasa melewatkan konteks, tetapi bagus bahwa pihak yang terkait langsung dengan left-pad menulis analisis pascakejadian
Namun klaim bahwa “NPM seharusnya memeriksa apakah modul saya digunakan secara luas, lalu mempertimbangkan cara untuk membatalkan publikasinya tanpa merusak apa pun” terdengar aneh. Memang benar desain fitur pembatalan publikasi NPM keliru, tetapi jika maksudnya ia berharap setiap kali seseorang membatalkan publikasi, staf perusahaan meninjaunya satu per satu secara manual, itu tampaknya tidak masuk akal. NPM sebagai perusahaan lebih dekat ke layanan yang meng-hosting registry seperti layanan publik, bukan mengurasi registry tersebut
Meski begitu, sulit juga menyalahkan penulisnya terlalu keras. Bahkan jika ia tidak memicu insiden left-pad, tak lama kemudian orang lain kemungkinan akan melakukannya, dan NPM memperbaiki masalah itu dengan kebijakan pembatalan publikasi yang lebih baik: https://docs.npmjs.com/policies/unpublish#packages-published...
Koçulu hanya menjalankan perintah itu pada 22 Maret 2016 dan menghapus semua paket yang pernah ia distribusikan; belakangan NPM menyalahkan kegagalan mereka sendiri kepada penulisnya
Sebagai orang yang menghindari JavaScript dan ekosistemnya seperti wabah Visual Basic abad ke-21, bagian paling menarik dari cerita ini adalah bahwa Koçulu sempat menjaga jarak dari dunia teknologi dan melakukan hiking, camping, serta menjelajahi trail yang keren, tetapi 8 tahun kemudian ia masih merasa perlu menjelaskan dirinya
Teknologi itu seperti muse yang berubah-ubah. Kita para nerd terobsesi pada teknologi dan mengikis diri sendiri dalam pelayanannya, tetapi teknologi selalu memanggil kita kembali ke cahaya
Sebagai seseorang yang ada di lapangan saat Morris worm terjadi dan menghabiskan beberapa minggu mengurangi dampaknya, saya melihat ada masalah mendasar pada kemampuan kita membuat teknologi yang mengubah dunia dengan alat yang ada saat ini. Semakin sedikit upaya kita memahami kegagalan teknis yang bersifat organisasional dan etis, semakin sulit teknologi menciptakan perubahan produktif di ranah tempat ia diterapkan
Saya sendiri mungkin sekitar sebulan lagi, dan ratusan kegagalan kompilasi lagi, akan mengambil sabbatical, dan saya jadi memikirkan seperti apa ruang teknologi yang telah saya bangun dalam skala dan konteks berbeda sesuai kebutuhan saya ketika saya kembali beberapa tahun kemudian
Mungkin para teknolog perlu lebih sering dan lebih serius mengambil sabbatical, sampai taraf tertentu menjadi hal yang standar. Dengan begitu kita bisa memperoleh konteks untuk memahami dilema etis yang membebani kapasitas teknis kita
Ini hal kecil, tetapi kalimat “sebagian besar pekerjaan open source mengikuti filosofi Unix, dan paket melakukan satu hal dalam satu waktu” agak ambigu
Contoh yang paling obvious, biasanya tidak ada yang menganggap libc bertentangan dengan filosofi Unix. Perdebatan biasanya muncul soal apakah suatu command atau daemon melakukan terlalu banyak hal, atau apakah ia tidak composable. Contoh terbaru yang representatif adalah systemd
libc modern cukup bertentangan dengan filosofi Unix. libc Unix tradisional jauh lebih sederhana, dan banyak fungsinya hanyalah system call. Sebagian libc hari ini dulu dipisahkan menjadi library terpisah seperti libm, dan hal seperti NSS atau framework resolusi DNS yang rumit sama sekali tidak ada
Eclipse juga bisa dibilang melakukan “satu hal, yaitu menjadi platform IDE”, tetapi saya rasa bukan itu maksud para pengembang Unix. Demikian pula, saya rasa mereka juga tidak bermaksud menyuruh orang membuat library yang hanya berisi satu fungsi 11 baris
Nasihat yang sebenarnya seharusnya kira-kira “program atau library tidak boleh mencoba melakukan terlalu banyak maupun terlalu sedikit.” Menentukan seberapa banyak itu terlalu banyak atau terlalu sedikit pada akhirnya, seperti banyak pedoman pemrograman lain, membutuhkan intuisi dan pengalaman
Setelah membaca Lions book atau APUE di satu sisi, lalu manual pthreads atau spesifikasi
setlocale()ANSI C di sisi lain, rasanya tidak mungkin menyimpulkan bahwa keduanya merepresentasikan filosofi yang sama. Itu setara dengan menganggap Ayn Rand sebagai wakil filosofi yang sama dengan Epicurus, yang berarti tidak pernah terlibat serius dengan salah satu dari keduanyaHal yang paling kuat tertinggal dari insiden ini adalah bahwa komunitas JavaScript terlalu bergantung pada dependency
Saya tidak mengerti mengapa begitu banyak kecaman diarahkan hanya karena sebuah paket kode 11 baris https://en.wikipedia.org/wiki/Npm_left-pad_incident#Backgrou... di-unpublish. Tulisan itu juga mengatakan bahwa ia tidak sepenuhnya memahami seberapa besar frustrasi yang akan ditimbulkannya
NPM tidak memiliki statistik penggunaan dan aktivitas GitHub-nya juga hampir tidak ada, jadi dari sisi pengguna dampak unpublish paket itu tidak bisa diketahui. Menurut saya akar masalahnya bukan pada akoculu yang menurunkan paketnya, melainkan lebih pada ketergantungan dependency yang berlebihan, kebijakan npm, dan sistem build yang tidak melakukan caching atau vendoring kode
Azer Koçulu tidak pernah menjadi bencana bagi ekosistem NPM. Tidak ada yang memaksa siapa pun memakai left-pad, dan alasan ia masuk ke begitu banyak proyek adalah dependency transitif yang berantakan
Sebaliknya, Jon Schlinkert sengaja membuat micro-library seperti ini dan memasukkannya ke handlebars-helpers, proyek normal yang banyak dipakai, tetapi tampaknya sama sekali tidak berniat mengintegrasikannya ke proyek yang benar-benar menggunakannya. Kalau mau terpancing, pakailah handlebars-helpers; kalau tidak, berhentilah memakai library itu
Masalahnya adalah NPM mengambil alih paksa paketnya dan menyediakan skrip yang jelas berbahaya jika dijalankan. Fakta bahwa Azer Koçulu sampai disalahkan itu sendiri konyol
Jon Schlinkert terlihat seperti sosok pengganggu bergaya marketing yang tipikal, dan secara pribadi menurut saya ia seharusnya dilarang dari NPM dan Github
Riwayat versi paket kik terasa aneh. Paket itu diganti 9 tahun lalu menjadi paket pendudukan untuk keamanan: https://www.npmjs.com/package/kik?activeTab=versions
Kik terbukti sebagai perusahaan yang ceroboh dan cukup menjijikkan. Ada juga kontroversi terkait kripto, tetapi hal utama yang saya ingat adalah maraknya pornografi di Kik, khususnya materi eksploitasi seksual anak, dan hal ini juga dibahas di episode Darknet Diaries ini: https://darknetdiaries.com/episode/93/
Dari sudut pandang itu, cukup memuaskan melihat Azer Koçulu menyuruh mereka pergi
Fakta bahwa left-pad adalah sebuah paket itu sendiri cukup lucu. Saya jadi membayangkan berapa banyak byte yang lewat melalui CDN, proxy, pipeline build, dan sebagainya hanya untuk memakai fungsi utilitas yang sangat kecil
Memanfaatkan solusi yang sudah ada itu baik, tetapi ketika perlu padding string, sulit bagi saya memahami pikiran “pasti ada paket untuk ini”
Ada juga budaya merilis paket demi mendapatkan popularitas dan GitHub stars, serta developer yang bersikeras bahwa mengimplementasikan sendiri sesuatu yang bisa diinstal lewat NPM adalah “menciptakan ulang roda”. Sampai sekarang saya masih sering bekerja dengan developer yang lebih memilih micro-package bahkan untuk fungsi sederhana, karena bagi mereka itu berarti “mengurangi maintenance”
Keduanya tentu tidak sama, tetapi jika ada tooling yang cukup matang, jaraknya tampaknya tidak begitu jauh sampai-sampai kita tidak bisa memahami keinginan untuk memperlakukan keduanya secara mirip
Ini hanya copy-paste dengan satu langkah tambahan
Ada bagian yang mengatakan, “Di pihak NPM, saya melihat sikap umum yang meremehkan developer, dan itu melahirkan serangkaian keputusan tidak rasional yang pada akhirnya membuat semua biayanya dibebankan kepada saya,” tetapi tampaknya NPM tidak banyak belajar bahkan setelah insiden ini
Insiden ini bagus karena memang terjadi. Pencadangan nama adalah masalah nyata, dan ketika situasinya ambigu, harus dipilih opsi yang paling tidak mengejutkan pengguna
Tidak adanya statistik penggunaan juga masalah besar, dan kemampuan untuk begitu saja melakukan unpublish juga masalah besar. Infrastruktur yang bergantung pada kode remeh 10 baris buatan individu yang keras pendirian juga merupakan masalah nyata, baik saat itu maupun sekarang. Dalam situasi ini sulit untuk benar-benar mengatakan ada seseorang yang bertanggung jawab; tidak ada yang berutang apa pun kepada siapa pun, tetapi semua orang bisa belajar darinya
Dari sudut pandang seseorang yang memelihara beberapa paket npm top-10, tulisan ini sepenuhnya masuk akal
Pada titik tertentu, NPM berhenti bekerja sama dengan komunitas. Akuisisi oleh Microsoft membuatnya semakin mengeras, tetapi itu sudah jelas jauh sebelum itu
Ada banyak retakan dalam cara npm dijalankan, mereka juga tidak bekerja sama dengan baik dengan komunitas maupun tim utama Node, dan dorongan menuju keberlanjutan komersial terasa sangat mengganggu dan memaksa. Beberapa anggota timnya juga punya reputasi yang agak keras
Saya pernah mengunjungi kantor Oakland mereka, dan ada beberapa interaksi yang cukup menarik; tidak terlalu positif, tetapi detailnya saya lewatkan saja
Saat itu, celah unpublish sudah dikenal luas. Semua orang menyalahkan left-pad karena merusak internet, tetapi hampir tidak ada yang mempertanyakan tanggung jawab npm yang mengelola seluruh kejadian itu dengan sangat buruk
Jika ingatan saya benar, npm memaksa memulihkan paket tersebut bertentangan dengan kehendak maintainer-nya; paling baik itu menunjukkan keterputusan dari orang-orang yang mereka klaim layani, dan paling buruk secara hukum pun meragukan. Segera setelah itu, mereka juga tampak tidak terlalu peduli pada penyalahgunaan platform, ada hal-hal seperti spam iklan core.js, dan mereka juga tidak bekerja sama dengan baik dengan komunitas dalam hal standar, kompatibilitas, dan sebagainya
Rilis npm@5 adalah bencana. Pengenalan file lock paket nyaris tidak mungkin lebih buruk lagi, dan seingat saya ada tekanan untuk merilisnya agar cocok dengan rilis mayor Node.js berikutnya. Rasanya tim Node tidak menunggu sampai npm siap, tetapi mengingat npm adalah perusahaan komersial, atau setidaknya bertindak seperti itu, menurut saya itu justru hal yang baik
Respons komunitas selama periode bug fatal yang tak ada habisnya, sikap mempermalukan komunitas yang memberi tekanan, dan sikap sok saleh itu adalah bukti bahwa npm tidak lagi menjadi perwakilan perangkat lunak bebas dan open-source. Saya tidak ingat apakah left-pad terjadi sebelum atau sesudahnya, tetapi di kepala saya semua itu tersimpan sebagai satu alur panjang kemunduran ekosistem
Sekarang paket npm sudah menjadi meme tentang paket-paket kecil yang melakukan pekerjaan sepele, dan semua orang mengejeknya. Kalau melihat ke belakang, itu mungkin bukan yang terbaik. Namun konteks itu penting. npm adalah package manager pertama yang sangat mudah diakses untuk teknologi populer yang sedang naik daun, hampir sepenuhnya dikelola oleh komunitas, punya sistem pencarian yang bagus, dan terintegrasi erat dengan semangat “social coding” GitHub
Ia hadir pada masa awal Node, bahkan sebelum ES5 ada, ketika orang masih memakai
vardanprototype. Belum ada praktik terbaik JavaScript yang benar-benar mapan, itu sebelum Joyent menyerahkan Node.js kepada komunitas, dan juga sebelum keluar dari fork Io.js serta stagnasi panjang Node 0.10/0.12Tidak ada yang tahu cara terbaiknya
Saya sepenuhnya memahami penulisnya. Dari sudut pandang keamanan, saya benar-benar bersyukur left-pad terjadi. Meski bukan itu niat penulisnya, kejadian itu memperlihatkan dengan sangat jelas kepada orang-orang risiko apa yang muncul ketika bergantung pada kepentingan korporat yang terpisah dari komunitas yang mereka klaim layani. Ia memulai banyak percakapan tentang keamanan rantai pasok, redundansi, dan sebagainya, dan dalam jangka panjang membuat industri sedikit lebih baik
npm, dan JavaScript secara umum, terutama adalah korban tren