Perubahan Cara Pengembangan Ladybird

• Menjelang rilis alpha pertama dan persiapan peluncuran browser untuk pengguna nyata, Ladybird akan berhenti menerima pull request publik dan hanya maintainer proyek yang akan memasukkan perubahan kode
• Dengan adanya alat AI yang membuat pekerjaan yang tampak seperti kontribusi serius menjadi lebih cepat dan murah, model kepercayaan lama bahwa patch besar menunjukkan niat baik atau upaya besar menjadi melemah
• Browser menjalankan seluruh input internet yang tidak tepercaya di mesin pengguna, sehingga satu kerentanan yang disamarkan dengan baik saja sudah cukup bagi penyerang
• Semua PR publik yang saat ini terbuka akan ditutup, dan mereka memutuskan untuk tidak membuat prosedur pengajuan patch terpisah melalui issues, komentar, email, atau forks maupun sistem kontribusi bayangan
• Ladybird akan tetap open source, dan partisipasi eksternal akan diarahkan bukan ke pengiriman kode melainkan ke laporan bug yang jelas, reproduksi minimal, pengujian situs web, diskusi standar dan desain, laporan keamanan, serta umpan balik teknis

---

Inti perubahan proses pengembangan

• Mulai sekarang Ladybird tidak akan menerima pull request publik, dan akan beralih ke cara di mana hanya maintainer proyek yang memasukkan perubahan ke codebase
• Pada tahap persiapan rilis alpha pertama, dibutuhkan proses pengembangan yang lebih ketat, model keamanan yang lebih jelas, dan kelompok yang lebih kecil yang bertanggung jawab atas kode yang masuk ke browser
• Di masa lalu, patch yang substansial merupakan sinyal perwakilan yang masuk akal bahwa ada upaya besar dan niat baik, tetapi dengan alat AI anggapan itu tidak lagi berlaku
• Browser menjalankan input internet yang tidak tepercaya di mesin pengguna, dan satu kerentanan yang disamarkan dengan baik sudah menjadi kondisi yang cukup bagi penyerang
• Sudah ada kampanye yang sabar dan memiliki sumber daya untuk memperoleh lalu menyalahgunakan kepercayaan maintainer di open source, dan yang berubah sekarang adalah kemampuan untuk membuat pekerjaan yang tampak seperti kontribusi serius menjadi lebih cepat dan murah
• Semua perubahan yang masuk ke Ladybird harus sesuai dengan arsitektur, tahan terhadap refactor di masa depan, berinteraksi dengan benar dengan bagian lain browser, dan dapat dipahami oleh maintainer
• Apakah kode ditulis dengan tangan bukanlah inti persoalannya; yang penting adalah siapa yang bertanggung jawab setelah kode itu masuk ke browser

Langkah transisi dan bentuk partisipasi yang tetap dimungkinkan

• Semua pull request publik yang saat ini terbuka akan ditutup, karena jika antrean yang ada dipertahankan maka jalur kontribusi publik pada praktiknya tetap terbuka, sehingga transisi diputuskan dilakukan sekarang
• Ke depannya, pull request hanya akan tersedia bagi maintainer proyek
• Tidak akan dibuat prosedur pengajuan patch terpisah melalui issues, komentar, email, atau forks, dan fork maupun patch dump tidak akan diperlakukan sebagai review queue untuk upstream Ladybird
• Kode eksternal tetap dapat ada sesuai ketentuan lisensi
• Ladybird akan tetap open source, dan source code akan terus dipublikasikan sesuai lisensi open source
• Partisipasi eksternal tetap membantu kemajuan proyek melalui laporan bug yang jelas, reductions, pengujian situs web, diskusi standar, diskusi desain, laporan keamanan, dan umpan balik teknis
• Pada tahap persiapan untuk merilis browser kepada pengguna nyata, proses pengembangan juga harus sejalan dengan tanggung jawab tersebut

[GN⁺]

Pendapat Hacker News

• Belakangan ini saya sering melihat PR di proyek open source besar seperti Godot, dan jumlah PR yang kode serta penjelasannya sepenuhnya dibuat AI memang cukup meningkat
  Karena dilarang oleh kebijakan proyek, biasanya pengirim hanya diberi peringatan ringan, dan banyak yang menerimanya dengan baik, tetapi sebagian marah karena merasa maintainer tidak berterima kasih
  Tampaknya bahkan orang-orang yang sepenuhnya sudah naik ke kereta AI pun belum benar-benar menginternalisasi bahwa menghasilkan segumpal kode itu sendiri tidak punya nilai intrinsik
  Walaupun upaya yang mereka keluarkan jauh berkurang, saat mengirim PR besar mereka tetap mengharapkan reaksi atau rasa terima kasih yang sama seperti sebelum era AI

  • Reaksi sebelum AI pun belum tentu pantas. Commit kode manual dalam jumlah besar yang bisa jadi sulit dirawat juga tidak selalu merupakan kontribusi positif, dan engineer yang baik atau bahkan orang biasa seharusnya tidak mengharapkan ucapan terima kasih terlepas dari banyaknya usaha yang dikeluarkan
    Dalam konteks itu, saya tidak berharap orang-orang yang memang sikapnya buruk dan sejak awal sudah terlalu banyak di industri ini akan mengubah perilakunya setelah hadirnya AI
    Sebagai catatan, staf nonteknis di tempat kerja saya mulai mengirim PR buatan AI ke repositori internal yang saya kelola, dan kualitasnya sangat bagus, juga menerima masukan review dengan baik lalu cepat memperbaikinya. Ini bukan masalah karena dia nonteknis, melainkan masalah sikap
  • Di sebagian kalangan vibe coding memang jelas ada semacam rasa berhak. Mungkin bukan istilah yang paling tepat, tapi lebih mirip sikap terobsesi pada hasil akhir dan tidak bisa menerima bahwa sebagian besar pekerjaannya bukan benar-benar miliknya
    Ini terlihat bukan hanya dari cara mereka berkontribusi, tetapi juga dari cara bicara sehari-hari. Ada ungkapan seperti “saya membuat X”, keras kepala bahwa “kurasi” mereka sangat menentukan hasil, sulit mengakui kontribusi LLM, sikap “saya fokus membuat sementara yang lain membuang waktu pada detail”, dan penolakan untuk menghadapi potensi cacat
    Ini sangat berbeda dari developer senior yang selalu curiga bahwa hasil yang mereka buat mungkin penuh cacat dan dikerjakan asal-asalan. Rasanya seperti sindrom impostor yang terbalik
  • Jika suatu proyek punya aturan bahwa mereka tidak menerima PR buatan AI, maka jangan pernah mengirim PR buatan AI ke proyek itu. Itu spam. Bahkan jika aturannya tentang AI lebih bernuansa, tetap harus dihormati
    Dalam kasus PR seperti ini, kesalahannya 100% ada pada pihak pengirim. Jika seseorang punya riwayat tanpa ragu melanggar aturan proyek dan bahkan bersikap arogan, itu seharusnya menjadi sinyal bahaya besar bagi calon pemberi kerja atau calon rekan kolaborasi yang melihat profil orang tersebut
    Saya tidak paham kenapa orang sengaja merusak reputasinya sendiri. Jauh lebih baik profil tanpa aktivitas apa pun daripada meninggalkan rekam jejak perilaku buruk
  • Saya tidak mengerti kenapa harus heran bahwa orang yang mengharapkan hasil tanpa usaha juga merasa pantas mendapat ucapan terima kasih tanpa benar-benar berpikir
  • Dalam kasus seperti ini, rasanya LLM mungkin sedang memberi tahu “kontributor” itu betapa pintarnya dia dan betapa besar kerugian proyek tersebut
    Misalnya seperti, “Ini bukan soal menjaga batas proyek atau menjamin kualitas kode. Ini hanyalah mekanisme penjaga gerbang yang dibuat kaum tradisionalis yang merasa terancam oleh kreator berpandangan masa depan seperti Anda yang benar-benar telah menguasai efisiensi AI”

• “Patch yang substansial berarti upaya yang substansial, dan upaya itu merupakan proxy yang masuk akal dengan itikad baik. Kini asumsi itu tidak lagi berlaku.”
  Kalimat ini adalah inti dari tulisan tersebut, dan menurut saya berlaku untuk sebagian besar proyek

  • Jika digeneralisasi, kita sedang cepat menyadari bahwa AI merusak kontrak sosial antara penulis dan pembaca, entah itu untuk prosa, kode, atau apa pun
  • Setuju. Menurut saya cara yang diambil Ladybird di sini bisa menjadi model sosial umum untuk open source ke depan
    Meski begitu, tetap perlu ada mekanisme untuk menilai apakah seseorang cukup berkomitmen dalam jangka panjang untuk menjadi maintainer. Kontribusi source kini sulit dipercaya sebagai sinyal itu, dan saya tidak tahu sinyal apa yang akan dipakai nantinya. Ini akan menjadi masalah yang cukup sulit
    Namun jika AI benar-benar meningkatkan produktivitas programmer secara drastis, proyek open source yang sukses mungkin tidak lagi membutuhkan tim maintainer yang besar
  • Betul. Ditulis dengan baik dan akurat. Saya belum pernah memikirkan spam PR dari sudut pandang ini, tetapi ternyata cukup meyakinkan

• Di satu sisi, jika Anda tumbuh di bazar, berpindah ke katedral bisa terasa seperti “kematian open source”. Padahal kenyataannya mungkin hanya kembali ke cara kerja yang lebih lama
  Di sisi lain, jika tidak menerima kontribusi kode dari luar, postur keamanan jelas akan membaik, tetapi akan lebih sulit mengetahui siapa yang layak diundang masuk ke kalangan inti

  • Pengembangan open source makin lama makin menjadi dangkal mengikuti karakter jejaring sosial modern. Yang menjadi lebih penting bukan nilai intrinsik kontribusi atau nilai proyek, melainkan bukti reputasi berbasis piksel seperti rekam kontribusi, riwayat commit aktif, atau jumlah bintang
    Sebelum GitHub naik daun, proyek open source lebih mirip taman berpagar tinggi yang kuat. Rasanya seperti klub kecil yang akan menatap Anda saat masuk ke ruangan. GitHub mengkomoditisasi kontak dan menurunkan hambatan usaha atau perhatian yang perlu dikeluarkan sebelum berkontribusi
    Sekarang masa itu sudah berakhir, dan orang harus membangun kepercayaan dulu sebelum berkontribusi pada apa pun
    Ini bukan kematian open source, melainkan kematian desa global tempat semua orang bebas berkeliaran dan mudah berinteraksi. Ini adalah kebangkitan komunitas kecil, sosial, dan berbasis kepercayaan, dan saya berharap arus ini menyebar ke seluruh internet
  • Saya masih belum terbiasa dengan kenyataan bahwa sekarang ada satu generasi coder yang sama sekali belum pernah melihat dunia di mana “segalanya” open source dan dikembangkan dengan model bazar
    Orang-orang sekarang bahkan tahu metafora itu atau buku Raymond? Kita hidup di dunia di mana Microsoft adalah pemasok open source utama dan memegang platform yang memungkinkan sebagian besar pemrograman open source di bumi. Coba jelaskan itu kepada penjelajah waktu dari akhir 90-an
    Juga, seperti disiratkan komentar saudara, bahkan “bazar” yang klasik seperti kernel Linux sekarang terlihat cukup seperti katedral jika dibandingkan dengan model kekacauan tanpa batas ala GitHub
  • Inti yang ingin disampaikan pengumuman ini adalah bahwa karena AI, kontribusi eksternal kini sudah hampir tidak bernilai sebagai sinyal untuk menemukan siapa yang layak diundang ke kalangan inti
  • Jika melihat SQLite dan proyek-proyek saudaranya (Fossil, dll.), ada proyek open source hebat yang berjalan baik dengan model katedral
    Jadi saya tidak menganggap keputusan Ladybird sebagai masalah. Justru saya melihatnya sebagai keputusan yang memperkuat sisi manusiawi dari pengembangan perangkat lunak dan mengerem para penumpang gelap AI
  • Bagaimana jika seseorang mem-fork proyek itu lalu memasukkan patch mereka ke fork tersebut? Jika fork itu berhasil dan benar-benar dipakai aktif oleh pengguna, upstream bisa mengambil patch yang dibutuhkan secara selektif. Maintainer fork itu pada akhirnya juga akan mendapat pengakuan
    Memang bukan solusi ideal, tetapi membangun reputasi pada dasarnya memang butuh waktu

• Melihat hal seperti ini membuatku merasa akan lebih baik kalau AI sama sekali tidak ada
  Sangat mengecewakan melihat proyek open source kehilangan kemampuan untuk mencari dan membimbing maintainer baru

  • Mereka menulis ulang perubahan besar pada proyek mereka dengan LLM
  • Aku tidak yakin ini benar-benar ada hubungannya dengan AI sejauh itu. Masalah open source dan maintainer sudah ada sejak lama sekali

• Katanya “tidak akan ada prosedur untuk mengajukan patch dengan cara apa pun” dan “partisipasi eksternal tetap penting: laporan bug yang jelas”
  Jadi artinya kita boleh menemukan dan memperbaiki bug, tetapi tidak boleh mengatakan secara persis bagaimana kita memperbaikinya?
  Sebagai gantinya tim harus mencari tahu lagi sendiri. Pasti menyenangkan sekali bagi tim untuk mengulang sesuatu yang sudah berhasil dilakukan orang lain berulang kali
  Sebagai pengguna sekaligus pengembang, aku tidak mengerti kenapa harus menghabiskan waktu untuk proyek yang memasang penghalang seperti ini pada perangkat lunak yang bisa memperbaiki hidupku. Jauh lebih mudah rasanya memakai Firefox atau Chromium, tempat perbaikanku benar-benar bisa diterima
  Dulu ketika versi Chromium baru membuat produku crash, aku bisa mengusulkan perbaikan ke V8, dan itu masuk ke rilis Chromium berikutnya sehingga produknya kembali berjalan. Itu pengalaman yang sangat berguna (https://github.com/v8/v8/commit/4f8a70adca01c)
  Kalau jalur seperti itu tidak ada, bisa saja para pengembang Chromium tidak punya cukup waktu untuk mencari penyebabnya dan tidak pernah memperbaikinya
  Katanya “pull request tidak lagi memberi tahu sebanyak dulu tentang pengirimnya”, tetapi tidak seharusnya siapa pun perlu tahu apa pun tentang orang yang mengajukan pull request
  Aku ingin kode yang masuk ke Firefox atau Chromium diputuskan berdasarkan ketepatan kode yang sudah diverifikasi dalam review, bukan berdasarkan “usaha” atau “niat baik” si pengirim
  Review terhadap perbaikan kode jelas lebih mudah daripada harus memikirkan solusinya sendiri. Kalau tidak begitu, ya tinggal tulis saja kodenya sendiri
  Dari sudut pandang proyek, mereka kapan saja bisa mengabaikan atau menutup PR yang tidak diinginkan. Tetapi menutup opsi untuk meninjau kontribusi eksternal, atau memakainya sebagai masukan untuk penulisan ulang mereka sendiri, rasanya tidak bijak

  • Menunjukkan titik masalah secara tepat jauh lebih berharga daripada kodenya. Jika kamu sudah menulis kode perbaikannya, berarti kamu sudah menganalisis bug itu. Nilainya ada pada analisisnya, bukan pada kode perbaikannya
    Berbagi analisis yang matang itulah cara memaksimalkan kontribusi. Kode paling jauh hanya semacam bonus opsional
  • Review kode PR bukan tindakan yang nyaris tanpa usaha. Kalau ada 3 orang yang mengerjakan proyek dan ribuan orang mengajukan PR perbaikan bug, maka meskipun perbaikannya sangat berguna, 3 orang itu tetap akan kewalahan hanya oleh jumlah PR-nya
    Perbaikan bug darimu mungkin memang punya nilai, tetapi nilai itu belum tentu lebih besar daripada biaya untuk meninjau dan menerimanya
    Pernyataan bahwa “review perbaikan kode jelas lebih mudah daripada membuatnya sendiri” sepenuhnya salah untuk proyek yang cukup kompleks. Perbaikannya mungkin cuma satu baris, tetapi dampaknya bisa menjalar jauh
    Sebagai pengguna sekaligus pengembang, kalau kamu tidak mau menghabiskan waktu pada proyek dengan aturan seperti itu, ya jangan. Kamu tidak berutang apa pun pada proyek itu, dan proyek itu juga tidak berutang apa pun padamu. Sesederhana itu
    Firefox dan Chromium dijalankan oleh tim yang jauh lebih besar, belum lagi kernel Linux. Mungkin mereka memang punya kapasitas untuk menerima kontribusimu
  • Kamu menyatakan seolah-olah “tidak perlu tahu apa pun tentang pengirim, cukup lihat ketepatan kode dalam review, dan review perbaikan kode lebih mudah daripada membuatnya sendiri” itu adalah fakta, padahal itu sepenuhnya bertentangan dengan pengalaman nyata para maintainer open source
    Bukan cuma pengalamanku dan contoh di tulisan aslinya, tetapi juga pengalaman banyak maintainer lain yang membagikan tulisan serupa
    Bisakah kamu membagikan tautan proyek open source yang sudah kamu maintain selama bertahun-tahun dan tempat kamu meninjau kontribusi, sebagai dasar keahlianmu soal masalah ini?
  • Kamu tetap bisa menjelaskan bagaimana caranya. Hanya saja bukan dalam bentuk kode atau patch
    Cukup tulis dalam penjelasan bahasa alami agar maintainer bisa memahami pendekatan penyelesaiannya
  • Kalimat “itu sangat berguna bagiku” adalah intinya. Kamu ingin orang lain berubah demi memenuhi kebutuhanmu
    Prioritas dan kebutuhan mereka berbeda. Dalam kasus ini, mereka sudah mengevaluasinya dan memutuskan itu tidak berguna. Artinya biayanya lebih besar daripada manfaatnya

• Menarik bahwa setidaknya dalam satu aspek penting, Chromium/Gecko/WebKit sekarang tampak seperti mesin browser yang lebih “terbuka” daripada Ladybird
  Servo bisa dibilang berada di tengah, karena masih menerima kontribusi eksternal selama tidak memakai AI
  Bisa dipahami kalau tim yang dananya tidak besar harus menutup kontribusi demi menghemat biaya tenaga kerja. Tetapi rasanya juga orang-orang belum cukup menghargai sumber daya ekonomi yang dikeluarkan Google/Mozilla/Apple untuk memungkinkan keterbukaan itu
  Sebagai pengungkapan bias dan pengalaman pribadi, sekarang aku sudah pensiun, tetapi dulu aku membuat Chrome di Google. Aku melihat banyak rekan membina kontributor eksternal, dan aku juga pernah melakukannya sebagian, baik secara informal maupun lewat program seperti magang

  • Perusahaan-perusahaan itu tidak melakukannya karena niat baik. Mereka melakukannya untuk memperoleh kendali demi melindungi nilai bisnis mereka sendiri. Kalau alasan ekonominya hilang, mereka akan berhenti besok juga
    Menurutku kita tidak perlu selamanya berterima kasih atas pembangunan monopoli
  • Chrome adalah produk loss leader bagi Google

• Saya bisa memahami mengapa keputusan seperti itu diambil. Jika sebagian besar pull request adalah kode yang ditulis AI, para maintainer juga bisa langsung memasukkan prompt ke Claude Code
  Menurut saya, keseluruhan permainan rekayasa perangkat lunak, baik open source maupun bukan, sudah berubah total. Tumpukan kode tidak lagi berarti atau menyiratkan hal yang sama seperti dua tahun lalu

  • Menurut saya, inilah inti masalahnya
    Beberapa tahun lalu, jika saya mengirim PR yang rumit, bisa dikompilasi, dan lolos pengujian, itu berarti saya telah menginvestasikan waktu dan upaya kognitif sebanyak itu. Jika saya tidak memahami codebase, fitur, atau bug tersebut, kemungkinan besar saya tidak akan melakukan investasi itu
    Sekarang, biaya untuk memperoleh pemahaman itu secara umum masih kurang lebih sama seperti dulu, tetapi AI telah sangat menurunkan biaya untuk menghasilkan kode yang bisa dikompilasi dan lolos pengujian
    Anggota komunitas yang kemungkinan besar berniat baik dengan senang hati menyumbangkan hal yang murah, yaitu token Claude Code, tetapi karena itu sudah menjadi terlalu murah, itu tidak lagi menjadi indikator yang baik bahwa mereka juga menyumbangkan hal yang mahal, yaitu pemahaman manusia
  • Saya sering melihat sikap seperti “kode yang dihasilkan AI tidak punya nilai.” Memang benar bahwa sangat mudah membuat kode yang nilainya nol, tetapi saya tidak setuju bahwa semua kode buatan AI bernilai nol
    Saya mengerjakan side project dengan OpenCode, dan saya menghabiskan cukup banyak waktu untuk menulis prompt, menyiapkan file yang tepat, serta menjelaskan produk dan roadmap yang ingin saya buat
    Saya lalu mengulang proses itu dengan menyiapkan loop verifikasi yang rapat, sehingga bisa menjalankan banyak pemeriksaan otomatis setelah perubahan, dan menguji secara manual banyak edge case yang bisa dirusak oleh fitur yang dihasilkan. Ini jenis pekerjaan yang berbeda, tetapi saya bisa maju lebih cepat daripada saat menulis kode dengan tangan. Komponen kuncinya adalah loop verifikasi
    Dari pengalaman beberapa bulan terakhir, coding dengan AI juga merupakan keterampilan; sambil mencoba, kita mempelajari teknik baru dan menjadi lebih baik. Itu juga berarti bahwa jika dilakukan dengan baik, kita bisa menghasilkan sesuatu yang bernilai
    Jadi saya tidak setuju dengan kalimat pertama, tetapi sepenuhnya setuju dengan kalimat kedua. Yang kita hilangkan adalah kemampuan untuk dengan mudah membedakan hasil yang dipikirkan secara mendalam dari hasil yang dihasilkan tanpa berpikir. Di sini, fokus pada verifikasi murah akan sangat membantu
  • Kode sekarang bukan lagi upaya utama dalam pekerjaan. Karena siapa pun bisa menghasilkan implementasi, semakin masuk akal daripada sebelumnya untuk lebih serius membahas apa, mengapa, dan bagaimana yang mendasari suatu perubahan kode
    Sepertinya semua proyek akan bergerak ke arah ini. Lebih masuk akal untuk bersama-sama menyempurnakan rencana
  • Seperti yang dikatakan, malah akan lebih berguna kalau orang langsung mengirimkan prompt

• Saat AI pertama kali muncul, saya takut suatu hari akan kehilangan pekerjaan. Saya cukup beruntung, tetapi banyak orang benar-benar kehilangannya, dan itu sangat menyakitkan
  Ketika seseorang kehilangan sesuatu karena otomatisasi, terlepas dari logika ekonomi, kita jadi ingin berpihak pada manusia, atau setidaknya berharap masyarakat tetap adil bagi mereka yang paling terdampak
  Sekarang saya melihat komunitas yang terkena dampaknya. Jika PR dimatikan, yang terguncang besar bukan hanya kontribusi kode, tetapi juga kontribusi tak kasatmata seperti ide dan lebih banyak mata yang meninjau kode. Itu terasa jauh lebih buruk
  Saya merasa bimbang, bingung, dan takut. Namun saya tetap memakai Claude dan DeepSeek, berbagai teknologi, harness yang rumit, MCP, dan sebagainya. Tetapi sekarang semuanya tampak seperti masa transisi. Saya hanya tidak tahu transisi menuju apa
  Banyak pertanyaan tidak bisa dijawab tanpa memberi makna pada hidup. Sentuhan manusia? Apakah sudah terlambat? Selain itu, saya pernah menyukai sebuah lagu, lalu ternyata itu buatan Suno. Setelah tahu, saya membatalkan like-nya. Saya terlalu sering merasa diri sendiri bodoh
  Maaf kalau ini jadi curhat yang melantur. Saya suka Ladybird, bahkan ada stikernya di laptop saya. Semoga proyek ini berhasil

  • Saya juga merasa relate dengan kalimat, “Semuanya tampak seperti masa transisi. Transisi menuju apa sebenarnya?”
    Rasanya seperti berada tepat di tengah tornado. Namun tetap ada gunanya mematikan layar, duduk di meja, mengingat prinsip pertama, lalu berpikir pelan-pelan dengan tenang
    Meminjam ucapan Obama, “realitas pada akhirnya akan menyusul”
    Orang memang banyak bicara, tetapi iOS tidak merilis fitur dan perbaikan setara 10 tahun kerja setiap tahunnya. Secara harfiah tidak ada yang bisa melakukan itu, dan yang justru muncul adalah keluhan bahwa fitur lama malah rusak. Jadi tidak mungkin benar bahwa kita sudah mencapai produktivitas 10x, dan fakta ini pada akhirnya akan menyusul kita
    Kita harus berpikir secara manusiawi. Kita juga harus ingat bahwa banyak orang punya investasi emosional di dalamnya. Para junior ingin ini menjadi kesempatan untuk bersinar di pasar yang telah menolak mereka. Para CEO sudah bertaruh pada AI dan tidak ingin mundur. Para senior ingin memberi sinyal bahwa mereka belum menjadi tidak berguna. Perusahaan AI akan mencemari diskursus. Namun asap ini pada akhirnya akan menghilang
  • Kontribusi seperti ini memang ada dalam jumlah kecil, tetapi sebagian besar pada kenyataannya berbeda dari yang dikatakan orang
    Biasanya itu bermuara pada opini yang tidak diminta, upaya pengambilalihan yang bermusuhan, ekstraksi nilai, drama pada umumnya, dan beban operasional keseluruhan yang menempel begitu saja pada pekerjaan membuat kode
    Memang tidak selalu begitu, tetapi model pengembangan open source bebas ala GitHub dan penghapusan semua gesekan jelas telah menciptakan default baru
    Model itu sejak awal sebenarnya tidak berkelanjutan, tetapi laju burnout-nya cukup rendah sehingga masih bisa dipertahankan dengan mengganti orang-orang yang kelelahan dengan lebih banyak manusia
    AI telah membuat laju burnout melampaui laju penggantian. Karena itu, kemungkinan besar lebih banyak proyek akan mengambil posisi seperti ini atau posisi yang mirip
  • Sangat normal untuk memiliki perasaan yang saling bertentangan tentang sesuatu, dan itu tidak langsung berarti ada masalah. Itu sangat manusiawi, dan saya juga merasakan hal serupa
    Saya seorang kreator sekaligus programmer; saya tidak suka melihat apa yang terjadi di beberapa komunitas, tetapi saya tetap menggunakan agen dalam pengembangan. Seperti sulitnya menghindari Google dan Stack Overflow saat keduanya pertama kali muncul, tampaknya juga ada momen sebelum dan sesudah yang jelas untuk LLM
    Saya tidak punya hal yang benar-benar berguna untuk ditambahkan, tetapi saya ingin mengatakan bahwa Anda tidak sendirian dalam merasakan konflik seperti ini. Hal-hal baru biasanya memang seperti itu. Di beberapa bidang, mereka memberi keuntungan besar, tetapi di bidang lain seakan mengupas sisi kemanusiaan; sebagian orang memakainya untuk membuat omong kosong dan sampah, sementara yang lain memperoleh kemampuan baru dan membuat sesuatu yang lebih baik. Sayangnya, tampaknya tidak ada kebenaran universal
  • Anda bisa berhenti kapan saja. Realitas yang menyedihkan adalah banyak orang tidak terlalu peduli ketika yang dirugikan adalah orang lain, tetapi jika sekarang ini mulai menghancurkan sesuatu yang Anda hargai secara pribadi, mengapa Anda harus terus mendukungnya, baik secara moral maupun finansial?
  • Fakta bahwa memakai dan mendukung LLM proprietari pada akhirnya hanya membuat OpenAI/Anthropic/Google dan lainnya semakin kaya juga tidak membuat saya merasa lebih tenang. Saya tidak bisa membenarkan penggunaannya

• Setelah membaca tulisan ini, ada semacam rasa yang aneh tertinggal. Soalnya penulisnya memang cenderung membuat PR besar yang tidak sepele, kadang lebih dari 1.000 baris, bahkan terkadang beberapa dalam sehari, lalu di-merge pada hari yang sama tanpa review
  Bahkan kalau aspek LLM dikesampingkan pun tetap begitu. Saya tidak tahu berapa persen di antaranya yang dibantu, tapi sekalipun 0%, itu tetap bukan kecepatan pengembangan yang terasa nyaman bagi saya

  • Ini sepenuhnya konsisten dengan yang dikatakan di sini
    “Apakah kodenya diketik dengan tangan bukanlah hal yang utama. Yang penting adalah siapa yang bertanggung jawab setelah kode itu masuk ke browser. Ladybird sedang menjadi browser untuk pengguna nyata. Orang yang memasukkan perubahan haruslah orang yang memutuskan bahwa perubahan itu layak menjadi bagian dari proyek, dan orang itu juga harus siap mempertanggungjawabkan hasilnya.”
  • Saya jadi kehilangan kepercayaan pada sebagian maintainer proyek open source yang bekerja seperti ini
    Ada platform open source yang sudah kami gunakan selama bertahun-tahun di perusahaan, dan kami memakai versi Enterprise berbayarnya. Masuk sebuah celah keamanan yang cukup ganjil ke platform itu, dan setelah ditelusuri, terlihat jelas bahwa AI sudah mengambil alih proyek tersebut
    Entah itu dinyatakan secara eksplisit atau tidak, cukup lihat log commit-nya saja, jumlah dan frekuensinya sudah sangat jelas. Sangat mengecewakan
  • Hal ini juga agak cocok dengan halaman GitHub-nya [1]. Commit 83%, PR 14%, review 2%, issue 1%. Jelas sudah di luar kendali
    [1] https://github.com/awesomekling

• LLM mungkin salah satu alasan yang mendorong keputusan Ladybird ini, tetapi bukan satu-satunya alasan yang mungkin. Misalnya, SQLite sudah hampir sejak awal dikembangkan dengan cara seperti ini
  Sepertinya tiap proyek memang punya caranya masing-masing

  • Kalau ingatan saya benar, Lua juga mirip. Open source, tetapi bukan pengembangan terbuka
    Lisensinya MIT dan para maintainer selalu berterima kasih atas laporan bug, tetapi seluruh kode proyek itu hanya ditulis oleh 3 orang
  • Saya tidak mengerti apa yang begitu besar di sini. Sebagian perangkat lunak terbaik dibuat dan dipelihara oleh kelompok yang sangat kecil namun berdedikasi
    Ini langkah yang sepenuhnya masuk akal untuk melindungi waktu dan proyek mereka

[GN⁺]

Komentar Lobste.rs

• Belakangan ini, melakukan review kontribusi di clang terasa sangat menyedihkan. PR sampah yang tak ada habisnya terus berdatangan, dan orang-orang makin pandai menyembunyikan jejak yang kentara, tapi biasanya tetap bisa dikenali, dan menyaringnya memakan waktu
  Bahkan untuk orang yang mengakui penggunaan AI dan menuliskan bagaimana mereka memakainya, kita tetap harus memeriksa lagi apakah itu benar atau mereka sekadar mengecilkan tingkat penggunaannya agar PR buruk bisa lolos
  Sampai sekarang saya sudah melihat sangat banyak PR seperti ini, tapi rasanya belum pernah melihat satu pun PR vibe coding yang benar-benar bagus. Sebagian ada yang sekadar “lumayan”, dan penulisnya kadang benar-benar memulai pekerjaannya sendiri, tetapi kebanyakan menghilang, dan sisanya jelas-jelas salah total bahkan soal konsep coding dasar, meski tanpa pengetahuan internal clang pun itu terlihat
  Yang lebih buruk adalah skrip yang mengotomatisasi pipeline fuzzer→bug→LLM→PR, yang secara serius salah memahami bug yang sebenarnya, “memperbaikinya” dengan cara yang rusak, lalu menambahkan tes buruk atau bahkan tidak memasukkan kasus gagal aslinya
  Akhirnya ini juga mengurangi keinginan untuk meluangkan waktu membina kemampuan kontributor baru. Saat nama yang belum pernah saya lihat mengirim PR perbaikan crash, saya jadi curiga dulu apakah ini buang-buang waktu atau orang yang benar-benar bisa jadi kontributor
  Orang yang cuma melempar sampah ke proyek jelas tidak tertarik pada kontribusi atau pembelajaran, dan kebanyakan tampaknya hanya ingin menambahkan hal seperti “berkontribusi ke clang” ke resume mereka

  • Situs web D punya daftar kontributor yang dibuat otomatis dari PR yang di-merge, dan pernah ada seorang pemula masuk ke chat lalu bertanya bagaimana daftar itu diperbarui, kemudian mengirim PR sepele dan mendesak agar di-merge
    Setelah itu dia terus datang dan bertanya, “kenapa daftarnya belum diperbarui? kenapa nama saya masih belum ada?”, lalu setelah situs webnya diperbarui dia menghilang
    Tapi dulu saat masih muda saya juga sama bodohnya. Saya pernah mengirim email karena diberi tahu bahwa saya bisa membuat mirror situs web tokoh open source terkenal, lalu meminta agar mirror itu dimasukkan ke daftar, dan saya juga pernah berlangganan mailing list pengembangan nmap karena ingin jadi 1337 hax0r, meski tidak pernah mengirim patch apa pun

• Definisi masalahnya jelas bagi semua orang. Selama puluhan tahun, proyek open source belajar siapa yang bisa dipercaya melalui kontribusi kode; orang-orang mengerjakan sesuatu, bertanggung jawab atas perubahan yang mereka buat, lalu tetap terlibat, dan kepercayaan lahir dari pekerjaan itu sendiri
  Namun menurut saya solusi ini adalah versi yang jelas lebih buruk dan lebih ketat daripada larangan kontribusi LLM yang dipilih proyek Zig
  Karena alat AI dengan cepat mengubah hitungan ekonominya, sekarang PR tidak lagi banyak berbicara tentang pengirimnya seperti dulu. Patch besar dulu berarti upaya besar dan menjadi indikator pengganti niat baik, tetapi asumsi itu kini tidak lagi berlaku
  Yang mengkhawatirkan adalah, open source sudah merupakan bisnis yang sulit dan seharusnya memaksimalkan keunggulan berharganya; para kontributor pada dasarnya membawa nilai yang luar biasa secara gratis (contributor poker), dan juga sangat penting sebagai jalur rekrutmen. Tetapi menolak semua itu tampak seperti pilihan yang gila
  Orang bisa saja berargumen bahwa LLM dapat mengisi kekosongan itu, tetapi pertama, penggunaan LLM sebenarnya bisa dilarang hanya untuk PR dari kontributor yang belum tepercaya; dan kedua, bahkan LLM terbaik pun berbiaya, harga token naik, kode tetap harus direview, dan pada akhirnya LLM tidak bisa menjadi kontributor inti tepercaya yang bertanggung jawab atas sebagian codebase
  Jika arus masuk kode dari PR dihapus, seiring waktu segelintir kontributor akan memiliki seluruh kode, dan proyek menjadi lebih mudah melakukan license rugpull. Jika kepemilikan hak cipta terdistribusi dengan baik, hal seperti ini lebih sulit dilakukan
  Secara keseluruhan ini buruk. Ini membuat open source menjadi model bisnis yang lebih bermasalah tanpa perlu, mempersulit perekrutan kontributor inti, dan memusatkan kepemilikan kode ke segelintir orang. Ini resep bencana yang sangat jelas, sampai-sampai membuat saya curiga apakah ini sekadar kesalahan atau ada beberapa sponsor Ladybird yang sedang memainkan permainan aneh

  • Kalau mau adil, open source tidak otomatis berarti kontribusi publik atau tata kelola komunitas. SQLite adalah contoh bagus proyek yang sama sekali tidak menerima kontribusi pihak ketiga, dan tampaknya baik-baik saja
  • Melihat daftar sponsor, saya tidak benar-benar melihat kelompok yang akan diuntungkan dari rugpull di browser. Beberapa tampak bermasalah dengan cara lain, tetapi motif seperti itu tidak terlihat
    Saya benar-benar penasaran dengan latar belakang perubahan ini. Proyek yang setiap bulan di bagian depan laporan status membanggakan jumlah beragam kontributor baru tiba-tiba mengubah arah seperti ini; ini perubahan yang sangat drastis. Penjelasan yang diberikan sekarang setidaknya tampak belum lengkap
  • Saya bekerja di SUSE, perusahaan distribusi komersial, pada hal-hal yang berdekatan dengan open source, dan pekerjaan saya lebih ke memelihara versi turunan daripada langsung memakai browser, compiler, atau database itu sendiri. Anggap saja sudut pandang dan keterbatasan saya berasal dari sana
    Baik Zig maupun Ladybird sama-sama sedang mencoba mencari jalan maju dari masa depan yang tidak kita inginkan. Selama beberapa tahun kita tidak paham apa-apa, dan sejujurnya saya tidak menyangka masa depan seperti ini akan datang. Sekarang sudah sama sekali tidak jelas apa itu “hal yang benar”
    Pertanyaan saya untuk Zig adalah, PR LLM dan PR yang benar-benar dibuat manusia tidak bisa dibedakan. Sampah berupaya rendah bisa disaring, tetapi untuk menegakkan “larangan AI” orang harus lulus semacam uji Turing, dan dengan saya plus lisensi Claude Pro, itu sangat mungkin dilewati
    Yang sebenarnya dilakukan “larangan AI” adalah memberi ruang untuk menyerang seseorang dan reputasinya ketika seseorang mengirim kode LLM, mengklaim itu kerja manual, lalu ketahuan. Apakah benar ingin menghabiskan waktu untuk ini? Jadinya akan ada sosok seperti Karl Jobst yang bertugas memburu orang yang memakai LLM sambil berpura-pura menulis kode dengan tangan
    Ini tidak akan menghentikan PR LLM; hanya mengubah permainannya menjadi “coba tangkap kalau bisa”. Saat melihat Andreas di Ladybird mengambil keputusan yang nyaris seperti rugpull, awalnya saya merinding, lalu berpikir setidaknya ini berani. Bantuan LLM dan soal kepercayaan memang masalah besar, jadi saya ingin melihat Zig dan Ladybird sama-sama berpikir di luar kebiasaan
  • Setelah melihat anggaran dasar organisasi Ladybird (https://ladybird.org/assets/documents/…), saya kecewa mengetahui bahwa Christopher Wanstrath adalah co-BDFL. Sebelumnya saya kira dia hanya menyumbang 1 juta dolar dan membantu mendirikan organisasi
    Kenyataannya dia adalah Designator, dan dari yang saya baca, posisinya dijamin seumur hidup kecuali mengundurkan diri atau tidak cakap. Para Designator mengambil keputusan dengan suara mayoritas, tetapi jika hanya ada 2 orang maka keduanya harus setuju; mereka menunjuk dan memberhentikan Directors, dan perubahan anggaran dasar juga memerlukan persetujuan mereka
    Artinya dia pada praktiknya memiliki hak veto tanpa pengawasan atas organisasi nirlaba itu. Andreas juga demikian, tetapi Andreas adalah orang yang membangun bagian besar dari pekerjaannya, terlibat dalam proyek, dan bukan miliarder. Wanstrath adalah miliarder, berjanji menyumbangkan bagian yang sangat kecil dari kekayaannya, tidak terlibat dalam operasional, tetapi memiliki kekuasaan yang sama
    Kecuali ada alasan hukum bagus yang saya lewatkan, ini tidak terdengar seperti struktur tata kelola yang baik untuk proyek open source

• Saya khawatir bagaimana nasib jangka panjang proyek-proyek yang baru-baru ini menutup kontribusi. Pada suatu titik, sebagian personel inti tepercaya akan pergi, dan tanpa kontributor jangka panjang yang sudah terbukti, mungkin tidak ada penerus yang jelas
  Jalur default-nya bisa berujung pada burnout dan proyek yang terbengkalai, jadi saya harap mereka menemukan cara untuk mengatasinya

  • Saya berharap demam LLM akan stabil atau mereda, atau proyek lain menemukan cara untuk menangani banjir “kontribusi” secara berkelanjutan. Jadi saya menganggap ini akan bersifat sementara. Tulisan itu juga memberi nuansa bahwa keadaan ini tidak akan dibiarkan seperti ini terus setelah rilis stabil

• Saya tidak melihat ini sebagai bentuk kepemimpinan apa pun. Ini bukan satu langkah pun ke arah yang benar, juga bukan gagasan tentang bagaimana kita bisa hidup bersama
  Saya paham tekanannya nyata, tetapi responsnya terasa sinis dan kalah sebelum bertanding, bukannya energik dan penuh harapan, dan itu mengecewakan

  • Saya penasaran kenapa Anda melihat ini bukan sebagai arah yang benar

• Bagian “sebagai bagian dari perubahan ini kami akan menutup semua pull request publik yang saat ini terbuka” itu mengejutkan
  Beberapa tahun lalu, sebuah proyek memutuskan tidak punya sumber daya untuk mereview PR, lalu menutup PR saya; rasanya cukup menyakitkan dan tidak adil bagi kontributor yang sudah menghabiskan tenaga untuk PR tersebut

  • Itu memang bisa menyakitkan, tetapi kalau maintainer sebenarnya tidak pernah meminta PR itu dibuat, saya rasa sulit menyebutnya tidak adil
  • Tidak adil kalau mengharapkan seseorang mereview pekerjaan yang tidak diminta

• Alasan yang diajukan bisa dipahami, tetapi keputusannya mengkhawatirkan. Bukan berarti pasti buruk, dan mungkin masih oke jika ini hanya sementara lalu nanti ditemukan titik kompromi lain, tetapi tetap membuat khawatir
  Ini juga bukan tanda bahaya pertama. Penulisan ulang Rust dengan bantuan LLM juga terasa serupa. Memang, tidak seperti Bun, pendekatannya relatif lebih hati-hati: komponen berukuran cukup kecil untuk ditinjau, dengan input-output yang jelas, dan dijalankan paralel dengan komponen lama untuk menangkap ketidaksesuaian. Meski begitu, ini tetap bukan pendekatan yang ingin saya lihat pada mesin peramban
  Saya berharap Ladybird berhasil. Saya ingin ada mesin peramban baru yang menantang struktur oligopoli. Tetapi jika membayangkan Ladybird melenceng, cukup melegakan bahwa Servo yang sempat stagnan selama beberapa tahun juga sedang mengalami kemajuan yang baik

  • Saya mendukung Servo. Kalau mengingat siapa yang memimpin Ladybird dan pandangan yang dia miliki, bahkan jika proyek ini berhasil, saya tidak ingin orang-orang seperti itu berada di balik salah satu aplikasi terpenting di mesin saya. Setidaknya untuk saat ini ada kebijakan seperti ini

• Memakai kode sampah AI untuk implementasi Rust, lalu berpihak pada DHH, yang tampak condong ke supremasi kulit putih dan anti-LGBT, juga terlihat cukup agresif. Rasanya proyek ini tidak akan melangkah jauh

• Jika tidak ada jalur masuk bagi kontributor dari luar, rasanya banyak hal akan terlewat. Bahkan jika yang dibutuhkan adalah komitmen yang lebih serius daripada sekadar lewat lalu melempar PR
  Dengan begitu, saat ingin menambah pengembang, akan ada kumpulan orang yang sudah mengenal codebase, dan organisasi luar juga bisa menangani kebutuhan yang tidak dijadikan prioritas oleh tim inti. Ini juga membantu adopsi dan mengurangi beban kerja

• Rasanya tidak tepat memberi tag vibecoding pada tulisan ini. Mengelompokkan korban dari praktik itu dengan tag yang sama seperti orang-orang yang mempromosikan perilaku tersebut terasa aneh secara mendasar

  • Dari tulisan ini saja konteksnya memang belum lengkap, tetapi jika membaca tulisan lain dan latar belakang terbarunya, alasan PR ditutup juga karena maraknya PR hasil vibe coding, sekaligus karena mereka sendiri kini sebagian besar beralih ke vibe coding. Porting vibe coding terbaru dari C++ ke Rust juga patut dilihat