Jika Saya Bisa Membuat GitHub Versi Saya Sendiri

• Forge modern seperti GitHub, GitLab, dan Gitea berbagi model ala GitHub, tetapi inti pekerjaan nyata lebih sering terjadi di dalam fitur forge seperti PR, Actions, Issues, dan Releases daripada di git itu sendiri
• Forge baru seharusnya menjalankan pre-commit hook wajib secara remote yang memberi umpan balik sebelum push, bukan setelah commit, sehingga dapat mengurangi commit berulang seperti Feature, fix, actually fix, asdfasdf
• Persetujuan PR seharusnya melampaui dikotomi setuju/tolak dengan mendukung persetujuan lemah dan penanda untuk ditinjau lagi nanti seperti Gerrit, dan perubahan kecil yang penulisnya adalah maintainer serta dinilai berisiko rendah oleh LLM seharusnya bisa lolos dengan lebih fleksibel
• Stacked PR seharusnya menjadi fitur kelas satu di forge dan VCS, dan repositori lokal harus merepresentasikan seluruh keadaan repositori, termasuk persetujuan PR dan issue, bukan hanya kode
• Kombinasi yang diinginkan adalah JJ sebagai VCS, forge baru yang bisa di-host dalam unit kecil, serta Actions yang mendukung tanda tangan, SHA, dan eksekusi offline; namun di era ketika GitHub menjadi default sebagai satu forge raksasa, masih belum ada alternatif yang benar-benar jelas

---

Masalah pada forge modern

• GitHub, GitLab, dan Gitea mengikuti model desain yang nyaris sama meski detailnya berbeda, dan bentuknya lebih mirip pola industri yang dibuat GitHub lalu dipindahkan ke alat lain
• Sebagian besar fitur forge saat ini hampir tidak berhubungan langsung dengan git itu sendiri, dan kliennya terlepas dari cara pakai yang sebenarnya
• git adalah sistem kontrol versi terdistribusi yang cocok untuk lingkungan seperti pengembangan kernel, dengan alur kerja berbasis kepercayaan tinggi di mana patch dikirim lewat email ke maintainer, maintainer mengelola wilayahnya sendiri, dan memutuskan apakah akan menggabungkannya
• Tetapi di kebanyakan tempat kerja, git lebih mirip sarana untuk pull/push kode dari repositori yang disimpan di forge terpusat, sementara pekerjaan penting terjadi di dalam forge
  • Pull Request menjadi sarana untuk memaksakan prinsip four-eyes
  • GitHub Actions menjalankan pengujian dan linting pada Pull Request untuk memeriksa fungsionalitas dan apakah persyaratan organisasi terpenuhi
  • Identitas pengguna di dalam forge menjadi dasar untuk memverifikasi pengguna
  • Issues digunakan untuk melacak masalah kode, dan Releases dipakai untuk membuat rilis yang akan diunduh pengguna
• Karena alur kerja seperti ini lebih banyak bergantung pada fitur forge yang dibangun di atas git daripada pada git itu sendiri, jika membuat forge baru maka alasannya untuk tetap terikat pada batasan git menjadi jauh berkurang

Fitur yang diinginkan dari forge baru

• Umpan balik harus datang sebelum commit, bukan sesudahnya

  • PR yang umum sering berisi rangkaian commit seperti Feature, fix, fix, actually fix, please, asdfasdf
  • Jika loop umpan balik datang setelah commit, pengguna akan menderita karena harus terus memperbaiki sampai larut malam
  • Forge harus menyediakan pre-commit hook wajib yang menjalankan pekerjaan secara remote, agar pengguna bisa menerima umpan balik sebelum melakukan push

• Persetujuan PR terlalu biner

  • PR saat ini dibagi menjadi keadaan disetujui atau tidak disetujui, tetapi dalam code review nyata ada banyak area di antaranya
  • Respons manusia seperti “untuk sekarang oke, nanti kita tangani” juga seharusnya bisa diekspresikan lewat tombol
  • Gerrit menawarkan model yang lebih baik dalam hal ini
  • Jika maintainer memberi persetujuan lemah, harus ada penanda agar bisa dilihat kembali nanti

• Kebijakan PR harus lebih fleksibel

  • Tidak semua perubahan membutuhkan review empat mata, terutama di lingkungan yang sudah memiliki LLM
  • Biaya menunggu engineer senior hanya untuk meninggalkan LGTM pada PR empat baris terlalu besar
  • Jika penulisnya adalah maintainer dan LLM menilai risikonya rendah atau tidak ada, seharusnya ada kontrol yang memudahkan perubahan langsung dilanjutkan

• Stacked PR harus menjadi fitur kelas satu

  • Stacked PR membuat review dan pemahaman menjadi lebih mudah
  • Ini seharusnya diperlakukan sebagai warga kelas satu di forge dan VCS, bukan fitur tambahan lewat alat di luar VCS

• Forge tidak boleh mencoba melakukan segalanya

  • Pelacakan issue memang perlu, tetapi papan Kanban mungkin tidak perlu
  • Kebutuhan akan Wiki juga diragukan
  • Alat yang memasukkan semua fitur pada akhirnya kualitasnya menurun, dan meski menambah fitur itu mudah, biaya pemeliharaannya terus muncul terlepas dari tingkat adopsi
  • Begitu seseorang mulai memakainya di suatu tempat, orang lain akan terikat pada fitur itu

• Unit hosting terlalu besar

  • Menjalankan GitHub Enterprise adalah pekerjaan besar, dan mengoperasikan GitLab juga beban yang cukup besar
  • Produk-produk ini adalah sistem kompleks dengan banyak komponen bergerak
  • Harus dimungkinkan membuat unit hosting individual yang lebih kecil lalu menghubungkannya untuk membentuk satu organisasi
  • Tidak harus federation global, dan tidak masalah jika perlu membuat akun per organisasi, tetapi sebuah organisasi seharusnya cukup fleksibel untuk mengatakan, “12 Raspberry Pi ini adalah organisasi saya”

• Repositori lokal harus merepresentasikan seluruh repositori, bukan hanya kode

  • Salinan lokal seharusnya merepresentasikan keseluruhan repositori, termasuk persetujuan PR dan issue, bukan hanya kode
  • Persetujuan PR harus bisa dilakukan dari VCS yang sama tempat kode di-check in
  • Issue harus bisa ditinjau seperti menelusuri file lokal

• Tidak perlu selalu menanggung biaya penyimpanan seluruh histori

  • Untuk bekerja dengan baik dalam tim, koneksi online memang diperlukan, jadi tidak perlu memaksa semua orang selalu menanggung biaya penyimpanan penuh
  • VCS dan forge harus bekerja bersama
  • Saat melakukan clone repositori, cukup ambil histori terbatas, lalu ketika perlu kembali ke masa lalu, jalankan worker untuk mengambil yang dibutuhkan dari VCS
  • Tidak perlu terus-menerus mengirim permintaan clone raksasa ke forge hanya karena ada asumsi bahwa suatu hari pengguna mungkin ingin membangun ulang forge dari seluruh histori proyek

• Actions harus ditandatangani, memiliki SHA, dan bisa dipakai secara offline

  • Actions itu penting, jadi harus mendukung tanda tangan, SHA, dan penggunaan offline
  • Jika diinginkan, seharusnya bisa mengunduh tarball semua action dan menaruhnya di repositori, lalu memberi tahu sistem agar tidak mengambil checkout action dari luar, melainkan memakai yang ada di repositori lokal
  • Jika menentukan latest, mekanismenya seharusnya bekerja dengan membuka PR yang memasukkan tarball terbaru ke repositori, seperti Dependabot saat ini
  • Actions juga seharusnya bisa dijalankan di mesin lokal melalui VCS yang sama jika diinginkan

Sudah ada alat yang melakukan sebagian, tetapi perlu dikombinasikan

• Sudah ada banyak alat yang menangani sebagian dari kebutuhan ini
• Yang dibutuhkan adalah mengambil alat-alat ini, menyatukannya, dan membuatnya benar-benar pas satu sama lain
• Kombinasi yang diinginkan adalah JJ sebagai VCS, sistem baru sebagai forge, dan harapan bahwa pengguna bisa puas memakai satu Raspberry Pi sebagai forge untuk waktu lama
• Forge baru harus dirancang dengan konsep modern seperti object storage, shallow clone, dan permintaan berkelanjutan dari bot LLM sebagai pusat desainnya

Retakan di era GitHub sebagai default

• Jika GitHub benar-benar bekerja dengan baik, mungkin tidak perlu menulis gagasan seperti ini
• GitHub adalah default, dan mencoba meyakinkan orang untuk melampaui default biasanya hampir seperti membuang waktu
• Sampai 2026, jika seseorang memakai forge, mereka membutuhkan alasan yang sangat kuat untuk tidak memilih alat yang dipakai semua orang
• Sampai belum lama ini, forge lain sebenarnya lebih dianggap sebagai pengganti daripada pilihan yang benar-benar diinginkan
• Tetapi forge raksasa tunggal sedang runtuh, dan penggantinya masih belum dibuat
• Orang-orang yang punya uang sibuk dengan roket, orang-orang yang punya selera sibuk dengan pekerjaan utama mereka, dan sisanya membuka PR bernama asdfasdf pada tengah malam, menunggu pemeriksaan robot, lalu bertanya kapan tepatnya alat yang mereka pakai sepanjang hari berhenti dibuat untuk penggunanya

[GN⁺]

Komentar Hacker News

• Kritik bahwa persetujuan PR terlalu biner terdengar kontradiktif. Persetujuan PR adalah pemberian wewenang, jadi pada akhirnya memang harus berupa boolean: kode bisa di-merge atau tidak, hanya itu pilihannya
  Yang dimaksud di sini lebih mirip mekanisme untuk sedikit menenangkan hati saat menyetujui kode yang sebenarnya tidak disukai, dengan komentar seperti “harus ditinjau lagi nanti...”. Tinggal buka tiket baru saja

  • Gerrit punya rentang dari -2 sampai +2
    -2: ide buruk, jangan dilakukan
    -1: ide bagus, tapi perlu perbaikan
    +1: terlihat bagus, tapi saya tidak punya pengetahuan atau wewenang untuk menyetujui
    +2: disetujui
  • Saya berharap ada tombol yang bisa mengatakan, “3 commit ini disetujui dan di-merge sekarang, 2 yang ini perlu dikerjakan ulang”
  • Ada juga kasus ketika kode sudah disetujui tetapi tidak di-merge. Dalam situasi seperti ini, maintainer bisa menambahkan perubahan lalu menerapkannya secara manual, dan menambahkan penulis PR sebagai co-author pada commit perubahan tersebut
  • Masalah yang lebih besar tampaknya adalah GitHub terlalu terpisah dari sistem pelacakan isu. Beban sinkronisasi manual terus-menerus terlalu besar, dan meskipun Linear membantu sampai tingkat tertentu, itu tetap tidak ideal
  • “Kode bisa di-merge atau tidak, hanya dua pilihan” — sepertinya bukan seorang intuitionist

• Memang benar kalau “Y melakukan sebagian dari itu”, tetapi tangled.org sebenarnya melakukan hampir semuanya

  1. Menggunakan JJ sebagai sistem kontrol versi: tangled mendukung stacked PR lewat jj change-id. https://blog.tangled.org/stacking tangled sendiri juga banyak dibangun dengan cara ini: https://tangled.org/tangled.org/core/pulls
  2. Forge yang bisa berjalan lama di Raspberry Pi: ini juga memungkinkan. shim server git sangat ringan, hanya lapisan XRPC di atas repositori git dan database sqlite3. Bahkan ada yang menjalankannya di board RISC-V dengan RAM 512MB
  3. Actions itu penting dan harus bisa dijalankan di mesin lokal: menurut saya tuntutan ini agak meleset. Menyediakan lingkungan terisolasi, bisa dijalankan di mana saja, dan menangani cross-build pada umumnya adalah tugas build system. Akan sangat bagus kalau hasil build seperti itu bisa “dipromosikan” ke forge itu sendiri
  • Agak mengejutkan melihat Raspberry Pi disebut untuk meng-host data yang penting bagi workflow. Dulu saya terlalu sering kena kerusakan kartu SD, jadi penasaran apakah sekarang orang memakai drive NVME
  • Betul, itu memang tugas build system. Hanya saja, masalah yang ingin dipecahkan orang dengan Actions yang bisa dijalankan secara lokal kebanyakan bukan kegagalan build itu sendiri, melainkan integrasi keseluruhan
    Hal-hal seperti definisi YAML, secret, perintah persis apa yang dijalankan, bagaimana tool dan cache dipulihkan. Build system bisa menangani sebagian, tetapi primitive yang disediakan GHA sangat minim. Pada akhirnya ini kembali ke masalah menjalankan seluruh sistem di tempat lain, jadi sistem seperti ini biasanya berakhir dengan pola trial-and-error
  • Betul, dan lebih jauh lagi maksudnya adalah akan bagus jika konsep build terisolasi diperluas agar bisa dengan mudah dijalankan secara lokal atau di mana pun ada sumber daya komputasi
    Masalah mendasar yang dimaksud di sini adalah betapa menyakitkannya mengulang siklus perubahan, commit, dan pemanggilan jaringan sampai CI akhirnya hijau. Cara terbaik menghindari iterasi itu tentu saja dengan tidak pernah menulis bug! Bercanda
  • Radicle dan Tangled sama-sama melewatkan inti persoalan. Mereka ditujukan untuk kerja kolaborasi publik, tapi bagaimana dengan repositori privat? Banyak pengguna punya side project dan memakai GitHub private untuk itu
    Kalau orang belajar GitHub, proyek publik mereka juga akan dimulai di GitHub. Selama belum memungkinkan membuat repositori privat untuk side project, akan sulit dipakai luas. Yang diinginkan orang adalah bisa membuat repositori privat, pergi beberapa bulan, lalu kembali dan semuanya masih menunggu di sana
  • Wah, dukungan jujutsu di Tangled persis yang saya cari. Akhir pekan ini sepertinya habis untuk setup self-hosting

• Jika ingin meng-clone hanya riwayat terbatas dan mengambil data lama saat diperlukan, gunakan blobless clone
  git clone --filter=blob:none
  Riwayat diambil, sedangkan blob hanya diambil saat dibutuhkan. Ada tulisan bagus dari GitHub: https://github.blog/open-source/git/get-up-to-speed-with-par...

• Ketika solusi menjadi masalah, terbuka peluang untuk inovasi disruptif. Belakangan ini pembahasan soal ini cukup banyak, dan saya penasaran apakah sebelum GitHub membetulkan arahnya, setidaknya satu dari banyak alternatif baru ini akan mendapat momentum

  • Saya rasa masalahnya adalah Microsoft sepenuhnya all-in pada AI. Tidak ada jalan kembali, dan GitHub pasti ikut terkena dampaknya
    Humas Microsoft akan bilang AI adalah solusi untuk segalanya, tetapi di dunia nyata masalah yang sama akan terus berulang. Gangguan layanan GitHub mungkin tidak terkait langsung dengan AI, tetapi strategi Microsoft sudah berubah, jadi sebagian besar keputusan akan diselaraskan dengan kontrol top-down yang berpusat pada AI. Apakah workflow para pengguna GitHub rusak atau tidak, bagi Microsoft itu paling-paling hanya perhatian sekunder, dan masalah itu akan terus muncul lagi. Mungkin akan tenang selama sekitar tiga bulan, tetapi tak lama lagi saya yakin 100% akan muncul drama baru soal GitHub sedang menurun. Ghostty bukan yang terakhir. Menarik apakah akan muncul alternatif, tetapi alternatif itu tidak boleh jelek, sementara banyak situs web memang cukup buruk
  • Saya sedang membuat alat saya sendiri. Menurut saya orang juga harus membuat alat mereka sendiri
    Mungkin di masa depan, alih-alih perangkat lunak berbayar atau open source, orang akan menerima sekumpulan dokumen kebutuhan untuk code forge, semacam resep. Masing-masing tinggal memanggang sendiri, lalu menyesuaikannya dengan kebutuhan dan selera masing-masing

• Menurut saya ada celah pasar untuk layanan git yang jauh lebih sederhana. Yang dibutuhkan hanyalah host remote untuk push proyek agar bisa dilihat orang lain; saya tidak benar-benar menginginkan PR atau Actions
  Mungkin akan bagus kalau ada fitur “release” untuk mengunggah aset biner yang dibangun secara lokal. Fork bisa ditangani dengan orang meng-clone repositori lalu mengunggahnya sebagai proyek baru

  • Bukankah banyak dari ini bisa diselesaikan dengan mematikan fitur yang tidak dibutuhkan? Saya baru saja melihat instance Forgejo saya, dan ada opsi per repositori untuk mematikan Code, Projects, Releases, Packages, Actions, Issues, PRs, dan Wikis
  • https://sr.ht/
  • Jadi kita kembali ke cgit lagi?

• Gagasan bahwa data review juga bisa dimasukkan ke repositori git seperti source code terdengar cukup meyakinkan
  Ini bisa diimplementasikan dengan sangat mudah dengan memberi prefiks yang dikenal lalu membuat satu branch per review, tetapi namespace branch default akan cepat berantakan. Bisa dipisahkan dari namespace utama dengan git namespaces, atau punya branch khusus seperti .reviews yang hanya berisi ID commit ujung dari tiap branch review. Jika ada yang cukup peduli untuk membuat spesifikasi dan implementasi yang benar-benar bisa dipakai, mungkin orang akan mulai mengadopsinya. Alasan GitHub dan berbagai forge tidak memilih pendekatan ini kemungkinan karena mengunci metadata review di dalam ekosistem mereka sendiri adalah bagian dari nilai platform. Jika siapa pun bisa mereview kode orang lain dengan alat lokal pilihan mereka, vendor lock-in akan berkurang. Meski begitu, mungkin juga ada alasan lain untuk ingin menaruh metadata review di repositori lain, seperti kontrol akses atau review lintas repositori

  • Dulu ada beberapa upaya seperti ini. Pada masa ketika orang masih peduli pada cara kerja offline dan store-and-forward[1], ada Bugs Everywhere[3], git-appraise[4] yang menyimpan data di namespace “notes” Git yang kurang dikenal[5], dan git-bug[6] yang belakangan muncul jauh lebih sering di thread seperti ini dibanding yang lain
    Jika hanya bicara akses baca-saja, data review Gerrit sebenarnya juga bisa diakses lewat Git[7]. Jika review-nya ABCDE, alih-alih ref nomor biasa di bawah prefiks itu, cukup pull refs/changes/DE/ABCDE/meta. Ada juga seseorang yang membuatnya bisa diakses lewat Git notes[8]. Fossil SCM yang terkenal dengan SQLite juga melakukan hal seperti ini dengan pelacak bug bawaannya[9]. Hanya saja ini kurang dikenal karena kombinasi kebetulan sejarah bahwa Git menang, dan sifatnya yang sangat memusuhi penulisan ulang riwayat yang dulu umum dilakukan di Git. Kembali ke topik bekerja di atas Git, saat mencoba membuat tipe data yang keren, yang sebenarnya dibutuhkan adalah strategi merge kustom, dan dukungan Git memerlukan banyak pembungkus agar terasa mulus. Contoh sukses yang saya tahu hanyalah pelacakan lokasi milik git-annex[10], dan itu pun merupakan proyek Haskell yang cukup besar. porcelain yang ada sekarang terlalu kaku
    [1] Tidak bisakah kita punya pengganti PGP yang cocok untuk kegunaan itu? Tolong berhenti bilang pada saya bahwa itu tidak ada atau suruh saya diam[2]
    [2] https://news.ycombinator.com/item?id=44239804
    [3] https://github.com/aaiyer/bugseverywhere
    [4] https://github.com/google/git-appraise
    [5] https://tylercipriani.com/blog/2022/11/19/git-notes-gits-coo..., https://news.ycombinator.com/item?id=44345334 (579 points, 146 comments)
    [6] https://github.com/git-bug/git-bug
    [7] https://gerrit-review.googlesource.com/Documentation/note-db...
    [8] https://gerrit.googlesource.com/plugins/reviewnotes/+/refs/h...
    [9] https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki
    [10] https://git-annex.branchable.com/

• Saya sangat menyukai workflow Gerrit yang mereview perbedaan, bukan PR. Tetapi dibandingkan sesuatu seperti gitea, rasanya sulit meyakinkan banyak orang karena kurangnya fitur lain yang kini diharapkan orang dari hosting git, seperti issue dan perencanaan proyek
  Sayang sekali tidak ada platform review diff yang bagus seperti Phabricator

  • Tapi kenapa Gitea tidak menambahkan itu? Semuanya yang lain sudah ada, jadi saya tidak mengerti kenapa forge seperti ini selalu berhenti sebagai tiruan GitHub dan tidak melangkah lebih jauh

• Menurut saya RFC2822 seharusnya dipakai sebagai format dasar untuk menyimpan semua pesan seperti PR, komentar review, dan issue, lalu CommonMark dipakai untuk memformat saat pesan ditampilkan
  Semua metadata bisa dimasukkan ke header, dan bisa saling ditautkan dengan header Message-ID/In-Reply-To/References. Dengan format yang terdefinisi baik seperti ini, kita bisa memilih bagaimana semua pesan disimpan dan ditransmisikan. Bisa dimasukkan ke repositori git, dikirim lewat email, atau memakai cara lain yang cocok. Untuk code review, secara pribadi saya merasa Gerrit jauh lebih baik daripada GitHub dan lainnya. Untuk CI, sebisa mungkin saya ingin menaruhnya di luar, dan hanya punya hook untuk memulai pipeline, menampilkan hasil, dan memutuskan apakah merge diizinkan

  • Saya rasa salah satu daya tarik GitHub adalah ia mengintegrasikan code review, penelusuran source, pelacakan tiket, dan CI
    Ia tidak luar biasa hebat dalam keempatnya, tetapi bagus dalam menyatukannya. Saya setuju Gerrit adalah model code review yang lebih baik, tetapi tanpa tiga bagian lainnya, itu bukan produk. Bahkan ketika saya dulu memakai Gerrit setiap hari di Google, saya tetap frustrasi dengan lemahnya integrasi antara pencarian kode, code review, dan CI. Alat internal Google seperti Google3/Critique/Forge menghubungkan semua itu jauh lebih baik

• Saya jadi teringat satu kelebihan workflow berbasis email. Kalau kita mulai melihat email, biasanya itu berarti kita sedang dalam mood untuk itu, dan dalam kondisi seperti itu kita berharap tidak ada gangguan lain, jadi bisa lebih fokus
  Masalah notifikasi adalah ada dorongan untuk langsung membereskannya saat muncul. Tetapi tidak ada jaminan kita punya energi untuk menanganinya pada saat itu. Kebanyakan sistem notifikasi web tampak seperti tiruan canggung dari sesuatu yang sudah dicapai klien email puluhan tahun lalu. Mungkin memang orang zaman dulu benar memakai email

  • Email juga notifikasi, jadi bisa dijelaskan lebih jelas bagaimana seseorang bisa sedang dalam mood untuk menerimanya tepat saat email datang?

• Saat Microsoft mengakuisisi GitHub, sudah banyak orang yang kesal. Hanya saja, secara realistis alternatif-alternatifnya sering kali juga buruk. Sourceforge membuat pembuatan issue terasa menyebalkan tanpa akhir, GitLab lebih baik daripada Sourceforge tetapi saya tetap tidak suka membuat issue di sana. Codeberg tampaknya baru-baru ini mengubah UI, tetapi tetap terasa cukup tidak nyaman
  Hal yang awalnya GitHub lakukan dengan baik adalah UI dan fokus pada orang-orang yang memakai GitHub, membuat pekerjaan menjadi mudah atau lebih mudah. Tetapi tidak semuanya dilakukan dengan baik; dukungan wiki menurut saya buruk sekali. Saking buruknya, saya hampir tidak pernah memakai wiki. Masalah yang benar-benar besar menurut saya adalah kepentingan komersial, atau lebih tepatnya kepentingan privat. Microsoft hanyalah satu contoh, dan ini masalah yang ada hampir di semua situs serupa. Saya pernah menyinggung diskusi issue terkait utilitas backdoor xz, dan saya juga ikut dalam diskusi itu, tetapi keesokan harinya Microsoft menurunkan semuanya. Apakah itu Microsoft atau pemilik repositori sebenarnya tidak penting. Masalahnya adalah satu pihak bisa terlalu mudah menyensor informasi yang berpotensi berguna. Diskusi issue itu berguna, dan disensor. Kalau saya ingat benar, saat itu tidak semua informasi dipulihkan. Mungkin ada yang membuat mirror, tetapi saya tidak pernah melihat tautannya. Ini menunjukkan bahwa kontrol top-down benar-benar bisa merusak. Sejujurnya, seberapa jauh kita bisa mempercayai Microsoft? Kita butuh sesuatu yang terdesentralisasi, berjalan stabil dengan baik, UI bawaan yang bagus, dan workflow yang sederhana atau setidaknya bagus. Kita juga harus menghindari situasi ketika aktor privat menyandera semua orang. Saya sama sekali tidak tahu bagaimana menyelesaikannya, dan mungkin dibutuhkan beberapa pendekatan sekaligus. Web sudah berubah, dan terutama kepentingan privat perusahaan raksasa selama 10–15 tahun terakhir terasa membuat keadaan jauh lebih buruk. Ini harus berubah

  • Masalahnya adalah mengoperasikan produk SaaS memang mahal
    Perusahaan besar bisa membayar biaya itu, tetapi sekumpulan developer dengan anggaran kecil tetap tidak punya uang untuk melakukan hal yang sama. Karena itu, proyek komersial apa pun pada akhirnya akan cenderung lebih mendukung kepentingan perusahaan besar daripada kepentingan orang biasa