Sebelum GitHub

• Dependensi open source bukan sekadar memilih paket, tetapi juga menilai reputasi dan keberlanjutan proyek, termasuk cara pemeliharaannya
• Sistem kontrol versi terdistribusi memang sudah menjadi umum, tetapi pusat kolaborasi nyata justru kembali terkonsentrasi di GitHub, dan ini menjadi ironi besar dalam open source modern
• Dengan fitur seperti issue tracker, pull request, dan halaman rilis, GitHub mengubah default kolaborasi publik, sekaligus sangat mempermudah penemuan proyek dan alur kontribusi
• Pada saat yang sama, GitHub juga berperan sebagai arsip yang menyimpan repositori terbengkalai dan catatan diskusi, sehingga membantu menjaga ingatan atas aset bersama perangkat lunak yang mudah hilang
• Di tengah tanda-tanda melemahnya sentralitas GitHub belakangan ini, open source makin membutuhkan arsip publik yang menjaga ingatan tetapi mengurangi ketergantungan, terlepas dari model bisnis satu perusahaan

---

Lanskap open source sebelum GitHub

• Sebelum GitHub, jumlah proyek yang layak diandalkan terbatas, dan reputasi serta keberlanjutan tiap proyek berhubungan langsung dengan pemilihan dependensi
• Dependensi bukan hanya nama paket, tetapi juga membawa sejarah proyek, situs web, maintainer, proses rilis, dan konteks komunitasnya
• Proyek besar sering menjalankan infrastrukturnya sendiri, sementara proyek kecil kadang diunggah ke server universitas atau SourceForge
• Ada friksi seperti proses packaging Debian yang bahkan meninjau lisensi dan header hak cipta, dan friksi semacam itu juga berfungsi sebagai bagian dari penilaian kepercayaan

Menjalankan infrastruktur sendiri dan paradoks kontrol versi terdistribusi

• Pada masa awal, proyek open source sering berjalan di server yang mengelola sendiri Trac, Subversion, tarball, dan dokumentasi
• Ada juga struktur seperti Pocoo yang membagi bersama biaya server serta beban menjalankan Subversion, Trac, dan mailing list untuk beberapa proyek
• Karena Subversion adalah repositori tersentralisasi, pengelolaan server menjadi konsekuensi yang wajar, dan rumah sebuah proyek terlihat jelas secara fisik lewat hostname, direktori, instance Trac, dan arsip mailing list
• Mercurial dan Git adalah sistem terdistribusi di mana siapa pun bisa memiliki seluruh repositori, branch, dan riwayat, tetapi pusat praktik nyatanya kembali berkumpul di GitHub
• Setelah sistem kontrol versi terdistribusi menang, dunia justru terstandarisasi pada satu layanan pusat raksasa, dan ini tetap menjadi ironi besar open source modern

Perubahan yang dibawa GitHub

• GitHub mempermudah pembuatan dan penemuan proyek, serta membuat alur kontribusi lebih mudah dipahami bahkan oleh orang yang tidak punya pengalaman dengan mailing list pengembangan
• Dengan menyediakan issue tracker, pull request, halaman rilis, wiki, halaman organization, API, webhook, hingga kemudian CI, GitHub mengubah default kolaborasi publik
• Kolaborasi open source lalu menjadi hal yang umum dilakukan di atas riwayat yang terlihat dan diskusi yang terlihat
• Untuk waktu yang cukup lama, GitHub berfungsi sebagai pilihan default yang sangat masuk akal untuk menaruh proyek open source
• Seperti kebijakan yang mencoba mempertahankan akses GitHub bahkan di negara yang terkena sanksi AS, sentralisasi ini berperan bukan hanya sebagai hosting, tetapi juga sebagai fondasi publik yang dapat diakses

GitHub sebagai arsip

• Fungsi GitHub yang kurang mendapat perhatian adalah perannya sebagai arsip; bahkan proyek yang terbengkalai tetap bisa dicari dan bertindak seperti indeks aset bersama perangkat lunak
• Fork, issue lama, dan catatan diskusi tetap tersedia, sehingga sentralisasi menciptakan ingatan yang dapat ditemukan
• Sebaliknya, sebelum platform besar mendominasi, file proyek dan layanannya sering hilang bersama domain pribadi yang kedaluwarsa, VPS yang dimatikan, atau absennya pengembang
• Seperti proyek awal di PyPI yang hanya menyisakan metadata sementara paket aslinya hilang, ada situasi ketika alamat repositori menunjuk ke server pribadi lama yang kemudian terputus
• Banyak proyek lama pada akhirnya sangat bergantung pada sarana pelestarian eksternal seperti Internet Archive

npm dan ledakan dependensi

• Masalah micro dependency tidak berhenti pada bertambahnya paket kecil, tetapi membesar karena GitHub dan npm membuat biaya pembuatan, distribusi, pencarian, instalasi, dan penggunaan dependensi tampak nyaris nol
• Sebelum GitHub, kepercayaan dan keberlanjutan adalah elemen wajib dalam memilih dependensi, dan karena sulit mempercayai ketersediaan layanan lain, praktik vendoring dengan menyertakan kode langsung ke repositori juga umum dilakukan
• Sebelum era API, memelihara skrip untuk mengambil kode eksternal juga merepotkan, dan friksi semacam itu membuat orang berpikir sekali lagi sebelum menambah dependensi
• Dalam ekosistem ala npm, grafik paket bisa tumbuh lebih cepat daripada kemampuan manusia untuk menalarinya
• Untuk merespons masalah status lisensi yang menjadi tidak jelas, GitHub bahkan mencoba merevisi ketentuan layanannya
• Meski bergantung pada paket kecil, budaya untuk memeriksa di GitHub apakah repositorinya ada, apakah maintainer-nya masih aktif, bagaimana issue-nya, perubahan terbaru, apakah dipakai proyek lain, dan apakah kode sesuai dengan deskripsi paket pun terbentuk
• GitHub juga menjadi salah satu dari sedikit sistem yang menangani trusted publishing untuk registry seperti npm, sehingga melemahnya kepercayaan pada GitHub berdampak bukan hanya pada hosting source, tetapi juga pada seluruh budaya supply chain

Melemahnya GitHub dan tanda-tanda perpindahan

• Belakangan ini GitHub mulai kehilangan sebagian aura keniscayaannya karena ketidakstabilan, perubahan produk yang berulang, kebisingan Copilot AI, dan kepemimpinan yang tidak jelas
• Karena berada di tengah arus agentic coding, tekanan internalnya juga makin besar, tetapi saat ini situasinya digambarkan sangat terasa sebagai ketiadaan kepemimpinan
• Selama beberapa waktu, meninggalkan GitHub lebih dekat ke langkah simbolis, tetapi kini proyek-proyek berpengaruh juga mulai secara terbuka mempertimbangkan atau melaksanakan perpindahan
• Pengumuman Ghostty meninggalkan GitHub diperlakukan sebagai sinyal kuat meskipun tujuan akhirnya belum jelas
• Strudel moved to Codeberg
• Tenacity moved to Codeberg
• Mungkin ini belum cukup untuk menciptakan pembalikan arus utama, tetapi mulai terlihat tren di mana orang lebih sering kembali melihat ruang hosting di luar GitHub
• Karena Git sendiri sejak awal dirancang dengan asumsi banyak rumah, mengakhiri keadaan di mana satu perusahaan menjadi rumah default bagi segalanya bisa menjadi hal yang sehat bagi open source

Biaya kembali ke distribusi

• Jika kembali ke banyak forge, banyak server, dan banyak komunitas kecil, desentralisasi dan otonomi bisa meningkat dan ketergantungan pada perubahan kepemimpinan Microsoft bisa berkurang
• Ada juga keuntungan bahwa tiap komunitas bisa memilih workflow yang berbeda-beda
• Masalah issue tracker saat ini di Pi menunjukkan bagaimana pilihan produk GitHub dapat menghasilkan konsekuensi yang tidak cocok dengan realitas pemeliharaan open source saat ini
• GitHub memperlihatkan sisi yang dirancang lebih berpusat pada engagement daripada kesehatan mental maintainer
• Di sisi lain, jika berpindah ke forge self-hosted, server Mercurial sendiri, atau server cgit, kodenya memang tersebar tetapi konteks sosialnya bisa dengan mudah ikut tercerai-berai
• Issue, review, diskusi desain, catatan rilis, pengumuman keamanan, dan tarball lama jauh lebih mudah hilang daripada yang dibayangkan
• Mailing list yang dulu memuat konteks semacam ini sudah tidak lagi mampu memenuhi kebutuhan masa kini, dan pengalaman penggunanya juga tidak baik
• Sifat perangkat lunak yang bisa dilupakan mungkin punya efek pemurnian, tetapi jika risiko kehilangan membesar, cara benar-benar memanfaatkan sistem kontrol versi terdistribusi juga perlu dipikirkan ulang

Yang dibutuhkan adalah arsip publik

• Entah GitHub tetap bertahan atau proyek berpindah ke tempat lain, open source membutuhkan arsip publik yang membosankan tetapi stabil
• Yang dibutuhkan bukan layanan untuk menang di pasar produktivitas pengembang, melainkan struktur yang memastikan perangkat lunak penting tidak menghilang
• Ini harus berjalan di atas fondasi yang dapat dipertahankan dalam jangka panjang, seperti endowment atau pendanaan publik
• Arsip source, artefak rilis, metadata, dan konteks proyek harus disimpan di tempat yang tidak terikat pada model bisnis atau suasana kepemimpinan satu perusahaan
• GitHub secara kebetulan mengambil peran arsip itu ketika menjadi pusat aktivitas open source, tetapi ketika sentralitasnya melemah, kita tidak bisa menganggap fungsi itu akan otomatis terus terjaga
• Server pribadi dan niat baik saja tidak cukup untuk pelestarian, dan celah setelah penutupan platform seperti Google Code dan Bitbucket sudah menunjukkan hal itu
• Sistem ke depan perlu bergerak ke arah menjaga ingatan dan mengurangi ketergantungan, sehingga perpindahan proyek, mirroring konteks sosial, dan pelestarian rilis menjadi mudah, serta hanyutnya satu perusahaan tidak mudah berubah menjadi krisis budaya bagi semua orang
• Ketegangan tetap ada antara tidak ingin kembali ke tarball link yang rusak dan instance Trac yang ditinggalkan, namun juga tidak bisa menerima struktur yang berpusat pada GitHub selama 20 tahun terakhir sebagai keadaan normal yang permanen

[GN⁺]

Opini Hacker News

• Salah satu perubahan terbesar yang dibawa GitHub menurut saya adalah strukturnya yang berpusat pada orang, bukan berpusat pada proyek
  Fakta bahwa saya bisa langsung menempelkan repositori ke nama saya sendiri dan membuat sesuatu dengan cepat terasa jauh lebih membebaskan dibanding prosedur berat di SourceForge, di mana kita harus menentukan dan memesan nama proyek lalu menyiapkan repositori CVS atau SVN, situs web, mailing list, sampai pelacak isu
  Ini sangat mengurangi beban mental bahwa "ini cuma sesuatu yang dibuat sebentar"
  GitHub juga tidak langsung memberi issue tracker, PR, halaman rilis, wiki, halaman organisasi, API, webhook, dan CI sekaligus sejak awal
  Dulu bahkan belum ada fitur organisasi, jadi orang membuat akun pengguna baru untuk meniru organisasi, dan sambil berpikir, "GitHub pasti akan merilisnya dalam beberapa bulan," saya pernah menunda mengadopsi bug tracker terpisah lalu akhirnya mengelolanya lewat file teks di repositori
• Saya masih agak menyesal bahwa di banyak proyek Git mengalahkan Fossil
  Untuk codebase super besar seperti kernel Linux, mungkin ada keunggulan performa Git, tapi untuk sebagian besar proyek hampir tidak pernah menyentuh batas performa VCS
  Fossil sangat berguna karena alat internal seperti wiki, forum, dan tiket ikut dikelola versinya bersama kode dalam satu file
  Dalam pekerjaan freelance, Fossil membuat saya sangat mudah memahami kembali konteks proyek, detail-detailnya, dan kesepakatan dengan klien
  Tidak perlu mengotori codebase, atau membongkar email dan alat catatan di berbagai tempat untuk memulihkan konteks
  Saya juga tidak suka anggapan bahwa karena Git sudah terlalu dalam tertanam secara budaya, maka kita tidak bisa mengubahnya
  Beralih ke Fossil juga mudah, dan workflow-nya malah lebih sederhana dibanding pindah dari Git
  • Alat serupa sebenarnya bisa dibuat juga di atas protokol dan repositori Git, dan memang pernah ada hal seperti distributed code review
    Hanya saja kebanyakan orang tidak menginginkannya, jadi tidak pernah benar-benar mendapat momentum
    Ada cukup banyak kasus di mana menyimpan isu bersama proyek justru merepotkan
    Kalau klien mengirim banyak screenshot atau file video untuk reproduksi bug, repositori akan cepat membesar, dan kalau semuanya dibundel bersama kode maka semua orang harus mengunduh repositori yang membengkak hanya untuk melihat tiket secara lokal, yang sangat merepotkan
    Akhirnya mudah bergeser menjadi, "jangan pakai ini, terlalu rumit dan cuma membesarkan repositori"
    Sebagian besar fitur Fossil tampaknya bisa diimplementasikan juga di atas backend Git, dan wiki atau isu bisa ditempatkan dalam lapisan branch paralel terpisah
  • Sepertinya faktor timing juga berpengaruh
    Kalau saya ingat benar, bahkan ketika Git sudah stabil dan layak dipakai sehari-hari, Fossil kadang masih mengharuskan kita membangun ulang seluruh repositori saat update versi
    UX Git memang lebih buruk, dan mungkin sampai sekarang pun masih begitu, tapi setidaknya ia berjalan dan terasa siap dipakai di medan nyata
    Lagi pula, salah satu proyek open source terbesar di dunia memakainya, dan dari sisi persepsi itu membuat perbedaan yang menentukan
  • Menurut saya sekarang justru saat yang tepat bagi seseorang untuk membeli fossilhub.com dan membangun komunitas baru
  • Saya penasaran kenapa Git lebih cepat pada repositori besar
    Tapi saya ingat, untuk sementara waktu keunggulan itu tidak terlalu terlihat saat menangani blob besar
• Menurut saya justru buruk bahwa GitHub berperan sebagai arsip
  Jika selama 99% waktu ada layanan terpusat yang nyaman, kemampuan pelestarian komunitas secara keseluruhan akan menurun
  Kalau agar sesuatu tetap hidup orang harus benar-benar menyemai sendiri, maka mereka akan lebih baik mempertahankan salinan dari hal-hal yang benar-benar mereka anggap penting
  Fakta bahwa kini orang mudah berasumsi "nanti tinggal checkout lagi" justru menjadi masalah
  Tidak boleh ada satu tempat tunggal tempat sesuatu bisa diturunkan
  Jika sebuah proyek GitHub terkena DMCA, bahkan fork-nya pun bisa ikut hilang
  Saat Nintendo menurunkan emulator Switch yang populer pada 2024, pelestarian dan pekerjaan lanjutan hanya mungkin dilakukan dengan mencari siapa yang masih sempat checkout revisi terbaru lalu meneruskannya dari sana
  Itu pun hanya mungkin karena proyeknya memang sangat populer: https://news.ycombinator.com/item?id=40254602
  Tambahan lagi, animasi header/footer bergaya Splatoon di situs ini benar-benar bagus
  Tidak mengganggu, tetap membangun suasana, dan langsung menyingkir saat kita scroll, sampai saya jadi ingin mencurinya mentah-mentah
  • Akibatnya muncul juga suasana bahwa kalau tidak ada di GitHub, seolah-olah itu tidak ada
    Rasanya terlalu banyak developer yang bahkan tidak tahu bahwa kode bisa disimpan di tempat lain
  • Pengarsipan itu sendiri mudah, tapi hak cipta dan hukum kekayaan intelektual yang menghambat
    Kalau hambatan untuk membuat informasi bisa diakses dikurangi, konsentrasi kekuasaan juga akan berkurang
  • Saya tidak setuju dengan ini
    Salah satu alasan GitHub mendapat kepercayaan selama bertahun-tahun adalah karena sejauh ini mereka belum langsung memonetisasi peran arsip itu
    Tentu saja, melihat fitur-fitur baru terkait Copilot, ke depannya saya tidak yakin
    Kalau alternatifnya adalah terpecah ke banyak situs, hasilnya cuma tiap tempat punya aturan DMCA yang berbeda-beda
    Itu membuat saya bertanya lagi: apa tepatnya alternatif yang lebih baik?
• Membaca tulisan seperti ini membuat saya menoleh kembali ke perjalanan proyek-proyek yang pernah saya ikuti
  Sebagian besar pekerjaan open source saya dilakukan di atas infrastruktur self-hosted, dan contoh utamanya adalah Xfce
  Saat pertama ikut pada 2004, kalau tidak salah yang ada hanya server SVN dan mungkin antarmuka web CVSweb dengan dukungan SVN yang masih baru
  Setelah saya masuk tim inti, saya rasa saya yang memasang Bugzilla, meski mungkin juga orang lain
  Ketika Git mulai menjadi arus utama, saya memimpin migrasi repositori SVN besar ke beberapa repositori Git, lalu menambahkan antarmuka web cgit
  Sampai saat itu kami masih memakai Bugzilla
  Sekitar 2009~2010 saya masuk startup kecil dan waktu untuk OSS berkurang, jadi saya meninggalkan proyek itu, lalu kembali pada 2022, dan di sela waktu itu ternyata mereka sudah menyiapkan instance GitLab serta runner CI, dan Bugzilla juga sudah dipindahkan ke GitLab Issues
  Jumlah orang yang aktif masih segelintir dan pengelolaan infrastruktur hampir ditangani satu orang, tetapi bahkan untuk tim kecil pun ini cukup layak dijalankan
  Fakta bahwa infrastrukturnya disediakan lewat sponsor adalah keberuntungan besar, dan tampaknya bahkan hanya dengan donasi rutin pun kami bisa membiayainya sendiri jika perlu
  Yang paling penting, saya sangat suka bahwa kami tidak bergantung pada GitHub/Microsoft
  Jika 20 tahun lalu ada yang bilang Microsoft akan memiliki code forge OSS terbesar di dunia, saya mungkin akan muntah, dan sampai sekarang pun itu tetap terasa tidak nyaman
• Sering terlewat, tapi shared login juga sangat penting
  Rust menjalankan pengujian seluruh proyek Rust yang dikenal dengan alat bernama crater, dan saat harus mengajukan ratusan isu secara manual untuk mencari proyek yang bergantung pada implementasi internal Cargo, alur dengan gesekan rendah sangat membantu
  Jika kita sudah punya kredensial situs dan template kosong juga diperbolehkan, mengajukan 200 isu jadi jauh lebih mudah
  Sebaliknya, kalau bertemu instance self-hosted, biasanya saya berhenti di situ
• Saya sudah memposting di Planet Source Code bahkan sebelum SourceForge ada
• Saya benar-benar menyukai Trac
  Memulai proyek open source baru dan menjadikan setup Trac sebagai langkah pertama punya gesekan yang nyaris tak masuk akal, tetapi saya tetap menyukainya
  Django bahkan sampai sekarang masih berjalan di atas Trac setelah lebih dari 20 tahun: https://code.djangoproject.com/timeline
  Saya bukan yang menyiapkannya, tetapi mungkin saya pernah membantu menjalankan Trac privat yang lebih awal dari itu
  • Trac memang sangat bagus
    Hanya saja issue tracker pertama saya adalah Bugzilla, dan setup-nya cukup menyakitkan serta integrasinya dengan alat lain juga kurang baik
    Meski begitu, ada kenikmatan tersendiri melihat Zarro Boogs
  • Dalam banyak hal, Trac adalah alasan saya akhirnya membuat aplikasi deployment dengan Python alih-alih PHP
    Sistem plugin-nya benar-benar luar biasa
  • Saya suka Bitbucket
    Ia menjalankan fungsinya dengan baik, buat saya hampir tidak pernah bermasalah, dan saya memang lebih menyukai sisi Mercurial
    Saya pindah karena perusahaan-perusahaan memakai GitHub, tapi sampai sekarang pun saya hanya memakai GitHub seperti endpoint Git yang tumpul, sementara build/deploy saya tangani dengan Docker dan shell script, jadi biaya pindah sangat rendah
    Dalam pekerjaan, kalau saya tidak punya wewenang menentukan, saya pikir ya sudah pakai saja alat berbayar seperti zaman SVN dulu
  • Anehnya, dulu saya sangat membenci Trac, tapi sekarang yang tertinggal justru kenangan yang baik
    Dulu saya merasa ia mencoba melakukan terlalu banyak hal sekaligus tanpa benar-benar unggul di salah satunya
    Sekarang mahkota itu mungkin dipegang GitLab, dan nanti mungkin itu pun akan saya kenang dengan baik
• Saya mencari layanan arsip kode karena penasaran dan menemukan beberapa
  Ada program GitHub sendiri juga: https://archiveprogram.github.com/
  Ada juga Software Heritage, organisasi nirlaba yang didukung UNESCO: https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/
  Hanya saja yang ini lebih fokus pada pelestarian kode dan riwayat commit, dan tidak banyak menangani metadata pendukung seperti isu, PR, diskusi, atau wiki
• Rasanya saya termasuk salah satu orang yang memakai Flask hampir sejak awal
  Saya belajar Python untuk memanfaatkan AppEngine, yang gratis, mudah, dan modern sebagai hosting, dan berkat itu saya berada di posisi yang tepat saat Flask muncul
  Saya sudah lama mengagumi Armin, dan bahkan sebelum mengklik tautannya saya langsung mengenali domain itu
  Saya juga setuju dengan ucapannya bahwa pada masa itu GitHub bukan pilihan default
  Menarik juga bahwa tulisan ini adalah respons terhadap tulisan Mitchell beberapa jam sebelumnya, dan saya terkesan ia bisa menulis artikel panjang, rapi, dan berkualitas tinggi secepat itu
• Ini mengingatkan saya pada code.google.com
  Saya masih tidak percaya Google bisa meleset sebesar itu
  • Benar-benar bikin nostalgia
    Saya ada di tim itu sebelum layanannya ditutup