- Menentang keputusan kepemimpinan teknologi NHS England untuk menjadikan source code repositori tertutup, sambil menegaskan kembali prinsip bahwa kode yang dibuat dengan dana publik harus dibuka kepada publik
- NHS England diminta mencabut SDLC-8 red line dan menegaskan kembali komitmennya pada NHS Service Standard Principle 12 “Make new source code open”
- Membuka kode sebagai open source memang membutuhkan lebih banyak kerja dibanding mempertahankannya tetap tertutup, tetapi hal itu menuntut standar kualitas yang lebih tinggi, penemuan dan perbaikan kerentanan lebih dini, serta penyiapan pembatas untuk membatasi dampak
- Source code tertutup dapat membuat pekerjaan keamanan yang diperlukan terlewati, bergantung pada ketidakjelasan alih-alih defense in depth, dan keuntungan yang diberikannya kepada penyerang yang cukup termotivasi tampak sangat kecil
- Sejak 1 Mei 2026, 402 orang telah menandatangani, dan penandatangan dapat mengirimkan nama, email, serta apakah mereka pernah berkontribusi pada perangkat lunak sektor publik Inggris; untuk tanda tangan anonim, data pribadi akan dihapus dalam 24 jam setelah verifikasi
Tuntutan utama surat terbuka
- Menentang keputusan kepemimpinan teknologi NHS England untuk menyembunyikan source code semua repositori, sambil menegaskan kembali prinsip bahwa kode yang dibuat dengan dana publik harus dibuka kepada publik
- Prinsip ini termuat dalam UK Government Design Principles dan NHS Service Standard, dan dipandang sedang mengalami kemunduran
- NHS England diminta mencabut SDLC-8 red line dan menegaskan kembali komitmennya pada NHS Service Standard Principle 12 “Make new source code open”
- Sejak 1 Mei 2026, 402 orang telah menandatangani, dan tanda tangan ditampilkan di halaman setelah ditinjau secara manual
Logika bahwa open source menciptakan standar kualitas yang lebih ketat
- Membuka kode sebagai open source membutuhkan lebih banyak kerja dibanding mempertahankannya tetap tertutup
- Pekerjaan sulit itu sendiri dianggap sebagai inti persoalan
- Membuka kode sebagai open source menuntut standar kualitas yang lebih tinggi serta prosedur untuk menemukan, memperbaiki, dan memantau kerentanan lebih dini
- Risiko harus diidentifikasi, dan pembatas perlu disiapkan untuk membatasi dampak ketika masalah terjadi
- Hal ini diibaratkan dengan sistem kekebalan tubuh manusia, di mana paparan terhadap ancaman membuat permukaan serangan menjadi lebih tangguh
Kritik terhadap source code tertutup
- Source code tertutup memungkinkan pekerjaan keamanan yang diperlukan dilewati
- Pendekatan tertutup dianggap bergantung pada ketidakjelasan alih-alih defense in depth
- Ketika ada penyerang yang cukup termotivasi, keuntungan yang diberikan oleh ketidakjelasan tampak sangat kecil
Cara penandatanganan dan pemrosesan data pribadi
- Penandatangan dapat mengirimkan nama, alamat email, apakah pernah berkontribusi pada perangkat lunak sektor publik Inggris, serta peran dan organisasi sebagai informasi opsional
- Kontribusi pada perangkat lunak sektor publik Inggris dapat mencakup kontribusi teknis maupun nonteknis, baik terbuka maupun tertutup
- Jika ada kontribusi, cukup menyertakan commit atau tautan profil, dan informasi tersebut tidak akan dipublikasikan
- Jika memilih tanda tangan anonim, tanda tangan akan ditampilkan sebagai “Anonymous”, dan bila peran serta organisasi diberikan, keduanya dapat ditampilkan bersama
- Untuk tanda tangan anonim, data pribadi akan dihapus dalam 24 jam setelah verifikasi
- Alamat email hanya digunakan bila perlu menghubungi terkait tanda tangan dan tidak akan dipublikasikan
- Dasar hukum pemrosesan data pribadi adalah persetujuan, dan persetujuan dapat ditarik kembali
- Untuk kontak terkait data, dapat menghubungi signatures@keepthingsopen.com
- Keluhan terkait pemrosesan data pribadi dapat diajukan ke Information Commissioner’s Office
Materi referensi dan tautan dukungan
1 komentar
Komentar Hacker News
Respons terhadap ancaman Mythos ini semuanya terlihat seperti langkah simbolis semata, dan begitu transparansi serta keterbukaan mulai muncul, tampak jelas ada upaya untuk memutarnya kembali dengan dalih serapuh apa pun
Ini lebih mirip keputusan dari orang nonteknis yang berpikir, “meski cuma ada kemungkinan 0,1% kita disalahkan karena tidak beralih ke closed source dan tidak berbuat cukup saat kerentanan ditemukan”
Keserakahan dan egoisme ekstrem pada 2026 membuat keputusan seperti itu mudah diambil meski harus mengorbankan kepentingan publik, dan perlu selalu diingat bahwa sektor swasta juga tidak jauh lebih baik dalam hal ini
Secara internal, dengan memakai model bahasa besar untuk menemukan bug secara privat tanpa membuka source code, kita bisa selangkah lebih cepat daripada penyerang
Kita juga baru melihat kasus seperti bencana publikasi Copy.fail baru-baru ini, ketika kerentanan yang ditemukan seseorang dengan model bahasa besar dipublikasikan sebagai zero-day tanpa perbaikan yang jelas, sehingga komunitas jatuh ke dalam kebingungan dan kepanikan
Dalam situasi saat model bahasa besar yang kuat tersedia baik sebagai bobot terbuka maupun bobot tertutup, terutama untuk software yang digunakan di rumah sakit, menjadikan semuanya open source tanpa syarat terasa makin kurang masuk akal, dan dibutuhkan keseimbangan
Jika Anda mengikuti thread ini karena khawatir dengan kualitas layanan digital NHS, mohon pertimbangkan juga untuk menandatangani petisi agar penyedia NHS tidak membeli accessibility overlay yang benar-benar merusak pengalaman pengguna difabel dan membuang uang yang seharusnya bisa dipakai untuk memperbaiki layanan inti: https://petition.parliament.uk/petitions/765480/
Verifikator Cloudflare menganggap saya bukan manusia, jadi saya tidak bisa menandatangani
Ada video yang menjelaskan situasi ini dengan mudah: https://youtu.be/XNLUfqtgBUk
Jika ini memang bidang keahlian Anda, akan sangat baik bila Anda ikut menandatangani surat terbuka tersebut
Kalaupun NHS setuju dan ingin menjalankannya, hanya untuk membuat panduan terkait saja kemungkinan akan butuh setidaknya 1 tahun
Lalu kalau setelah itu tim teknis yang sekarang diminta membereskannya, rasanya bisa makan 10 tahun lagi
Tulisan terkait: NHS Goes to War Against Open Source
https://shkspr.mobi/blog/2026/05/nhs-goes-to-war-against-ope... (https://news.ycombinator.com/item?id=47973710)
Dalam beberapa minggu terakhir saya membicarakan topik ini dengan para CISO, CTO, maintainer, dan kolega, sebagian dari mereka berasal dari perusahaan F50, dan rencana dasar mereka adalah menghentikan kontribusi dan penggunaan open source sampai tim keamanan aplikasi bisa dengan mudah memverifikasi dan memperbaiki masalah dalam sehari
Secara tradisional, waktu respons end-to-end berada di kisaran 8–10 hari, tetapi sekarang kecepatan seperti itu sudah tidak bisa dipertahankan
Saya tidak melihat ini sebagai kematian open source, tetapi sebagai bukti bahwa ekonomi open source telah berubah menjadi tragedi bersama karena maintainer tidak diberi sumber daya operasional yang berkelanjutan
Ini juga merupakan pengakuan bahwa organisasi selama puluhan tahun tidak menempatkan keamanan sebagai prioritas, baik di dalam engineering maupun di tingkat organisasi, tetapi melihat kualitas percakapan di HN soal ini, itu tampaknya perlu dibahas terpisah
Kalau orang-orang yang menyukai open source benar-benar peduli, mereka harus berhenti hanya berbicara idealisme dan mulai mengeluarkan uang, serta memikirkan langkah seperti beralih ke open core atau menyiapkan pendanaan dan sponsor formal
Penting juga untuk mengadopsi lisensi yang jauh lebih ketat sambil tetap mengizinkan komersialisasi oleh pemilik proyek. Sebagian besar proyek bergaya GNU yang bergantung pada niat baik segelintir orang yang punya ideologi serupa kemungkinan sulit bertahan, dan para kontributor juga harus dibayar
Menjawab pertanyaan “bukannya tidak mungkin menghentikan Linux/Kubernetes/Chrome(termasuk Edge)/hampir semua bahasa pemrograman/nginx dan seterusnya?”, maksudnya adalah membekukan semua dependensi dan library yang dipakai ke depan, dan tidak mempublikasikan source code sampai perbaikan kerentanan end-to-end bisa dilakukan dalam 24 jam
Tim juga secara serius mempertimbangkan untuk mem-fork proyek inti dan dependensinya untuk penggunaan internal, lalu tidak berkontribusi ke upstream karena takut kontribusi upstream telah terkontaminasi atau bisa membawa kerentanan tambahan
“Hasil yang menarik adalah library open source menjadi lebih bernilai. Sebab biaya token yang dikeluarkan untuk keamanan bisa dibagikan ke semua pengguna. Ini secara langsung membantah gagasan bahwa library open source akan menjadi kurang menarik karena kini lebih murah membuat penggantinya dengan vibe coding”
Saya paham reaksi spontan untuk mem-fork kode dan membawanya ke internal, tetapi ketika itu berarti tim engineering harus mengelola dan memitigasi lebih banyak kode yang rentan, saya ragu seberapa berkelanjutannya pendekatan itu
[0] https://simonwillison.net/2026/Apr/14/cybersecurity-proof-of...
Rasanya tidak mungkin mereka benar-benar bisa menghentikan Linux/Kubernetes/Chrome(termasuk Edge)/hampir semua bahasa pemrograman/nginx dan sebagainya, jadi saya penasaran