- Sebelum GitHub menjadi infrastruktur sosial bagi open source, para pengembang mengelola proyek di atas infrastruktur yang mereka operasikan sendiri seperti Trac, repositori Subversion, dan mailing list, dan bahkan penambahan dependensi pun disertai gesekan yang besar serta kehati-hatian tinggi
- GitHub membuat pembuatan, penemuan, dan kontribusi ke proyek menjadi jauh lebih mudah, menstandarkan issue tracker, pull request, CI, dan bahkan berperan sebagai arsip bagi open source
- Ketika berpadu dengan ekosistem paket seperti npm, terjadilah ledakan mikro-dependensi, dan GitHub menjadi poros utama sistem kepercayaan, tetapi kini kepercayaan itu terkikis oleh ketidakstabilan, kebingungan arah produk, noise AI, dan lain-lain
- Ghostty juga pergi, dan mulai muncul pergerakan seperti Strudel dan Tenacity yang berpindah ke Codeberg; desentralisasi meningkatkan otonomi, tetapi juga berisiko menghilangkan konteks sosial seperti issue, review, dan advisori keamanan
- Di tengah tanda-tanda melemahnya sentralitas GitHub belakangan ini, arsip publik yang menjaga ingatan namun mengurangi ketergantungan menjadi semakin penting. Open source di era berikutnya harus mempertahankan ingatan sambil mengurangi ketergantungan
Lingkungan open source sebelum GitHub
- Sebelum GitHub, jumlah proyek yang layak diandalkan terbatas, dan reputasi serta keberlanjutan tiap proyek terhubung langsung dengan pemilihan dependensi
- Dependensi bukan sekadar nama paket; ia datang bersama sejarah proyek, situs web, maintainer, proses rilis, hingga konteks komunitas
- Proyek besar sering mengoperasikan infrastruktur sendiri, sementara proyek kecil kadang diunggah ke server universitas atau SourceForge
- Ada gesekan seperti proses packaging Debian yang sampai meninjau lisensi dan header hak cipta, dan gesekan semacam ini juga berfungsi sebagai bagian dari penilaian kepercayaan
Paradoks menjalankan infrastruktur sendiri dan version control terdistribusi
- Proyek open source awal sering berjalan di server yang mengoperasikan sendiri Trac, Subversion, tarball, dan dokumentasi
- Ada juga struktur seperti Pocoo, di mana beberapa proyek berbagi beban biaya server serta operasional Subversion, Trac, dan mailing list
- Karena Subversion adalah repositori terpusat, menjalankan server menjadi konsekuensi yang alami, dan rumah sebuah proyek tampak jelas secara fisik lewat hostname, direktori, instance Trac, atau arsip mailing list
- Mercurial dan Git adalah sistem terdistribusi di mana siapa pun bisa memiliki repositori penuh, branch, dan histori, tetapi pusat gravitasi pada akhirnya tetap berkumpul lagi di GitHub
- Setelah distributed version control system menang, fakta bahwa seluruh dunia kemudian distandarkan pada satu layanan terpusat raksasa tetap menjadi ironi besar dalam 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 CI di kemudian hari, GitHub mengubah default kolaborasi publik
- Kolaborasi open source menjadi umum dilakukan di atas histori yang terlihat dan diskusi yang terlihat
- Untuk waktu yang lama, GitHub berfungsi sebagai pilihan default yang sangat masuk akal untuk menaruh proyek open source
- Sentralisasi juga berfungsi lebih dari sekadar hosting, menjadi fondasi publik yang bisa diakses, seperti terlihat dalam kebijakan yang berupaya menjaga akses GitHub di negara yang terkena sanksi AS
GitHub sebagai arsip
- Fungsi GitHub yang kurang mendapat sorotan adalah perannya sebagai arsip; bahkan proyek yang ditelantarkan tetap bisa dicari dan berfungsi seperti indeks aset bersama perangkat lunak
- Dengan fork, issue lama, dan catatan diskusi yang tetap tersimpan, sentralisasi menciptakan ingatan yang bisa ditemukan
- Sebaliknya, sebelum era platform besar, proyek sering lenyap bersama kedaluwarsanya domain pribadi, matinya VPS, atau tidak hadirnya pengembang
- Seperti proyek awal yang hanya menyisakan metadata di PyPI sementara paket aslinya hilang, ada situasi di mana alamat repositori menunjuk ke server pribadi lama yang sudah terputus
- Pada akhirnya banyak proyek lama sangat bergantung pada sarana pelestarian eksternal seperti Internet Archive
npm dan ledakan dependensi
- Masalah micro dependency tidak berhenti pada bertambahnya jumlah paket kecil; ia membesar karena GitHub dan npm membuat biaya penciptaan, distribusi, pencarian, instalasi, dan dependensi tampak nyaris tidak ada
- Sebelum GitHub, kepercayaan dan keberlanjutan adalah unsur wajib dalam memilih dependensi, dan karena sulit mempercayai ketersediaan layanan lain, vendoring dengan memasukkan kode langsung ke repositori juga umum dilakukan
- Sebelum era API, mempertahankan skrip untuk mengambil kode eksternal juga merepotkan, dan gesekan ini membuat orang berpikir sekali lagi sebelum menambah dependensi
- Dalam ekosistem ala npm, graf paket bisa tumbuh lebih cepat daripada kecepatan manusia untuk menalarinya
- Untuk menanggapi masalah status lisensi yang menjadi tidak jelas, GitHub bahkan mencoba merevisi ketentuan layanannya
- Budaya pun terbentuk untuk memeriksa di GitHub hal-hal seperti repositori, apakah maintainer benar-benar ada, issue, perubahan terbaru, apakah dipakai proyek lain, dan apakah kode selaras dengan deskripsi paket, bahkan ketika hanya bergantung pada paket kecil
- GitHub juga menjadi salah satu dari sedikit sistem yang bahkan menangani trusted publishing untuk registry seperti npm, sehingga melemahnya kepercayaan pada GitHub berdampak bukan hanya pada source hosting, tetapi juga pada seluruh budaya supply chain
Melemahnya GitHub dan tanda-tanda perpindahan
- Belakangan GitHub mulai kehilangan sebagian dari keniscayaan yang dulu dimilikinya karena ketidakstabilan, perubahan produk yang berulang, kebisingan AI Copilot, dan kepemimpinan yang tidak jelas
- Karena berada tepat di tengah arus agentic coding, tekanan internal juga meningkat, tetapi saat ini situasinya digambarkan sebagai sangat terasa kekosongan kepemimpinannya
- Selama beberapa waktu, meninggalkan GitHub lebih mirip gerakan simbolis, tetapi kini proyek-proyek berpengaruh juga mulai secara terbuka mempertimbangkan atau melaksanakan perpindahan
- Pengumuman Ghostty meninggalkan GitHub diperlakukan sebagai sinyal kuat meskipun tujuannya belum sepenuhnya jelas
- Strudel moved to Codeberg
- Tenacity moved to Codeberg
- Mungkin belum sampai tingkat yang membalikkan arus utama, tetapi mulai tampak tren untuk lebih sering melihat ruang hosting di luar GitHub lagi
- Karena Git sendiri pada dasarnya dirancang dengan asumsi adanya banyak rumah, mengakhiri keadaan di mana satu perusahaan menjadi rumah default untuk segalanya bisa jadi 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 menghasilkan konsekuensi yang tidak selaras dengan realitas pemeliharaan open source saat ini
- GitHub memperlihatkan sisi yang lebih dirancang berpusat pada engagement daripada kesehatan mental maintainer
- Di sisi lain, jika pindah ke forge self-hosted, server Mercurial sendiri, atau server cgit, kode memang tersebar, tetapi konteks sosial bisa dengan mudah ikut tercerai-berai
- Issue, review, diskusi desain, catatan rilis, pengumuman keamanan, dan tarball lama bisa hilang jauh lebih mudah daripada yang dibayangkan
- Mailing list yang dulu memuat konteks semacam ini tidak lagi mampu memenuhi kebutuhan saat ini, dan pengalaman penggunanya juga tidak baik
- Sifat perangkat lunak yang bisa dilupakan mungkin punya efek pemurnian, tetapi jika risiko kehilangan membesar, kita juga perlu kembali memikirkan cara benar-benar memanfaatkan distributed version control system
Yang dibutuhkan adalah arsip publik
- Entah GitHub tetap ada atau proyek-proyek pindah ke tempat lain, open source membutuhkan arsip publik yang membosankan tetapi stabil
- Yang dibutuhkan bukan layanan yang menang di pasar produktivitas pengembang, melainkan struktur yang memastikan perangkat lunak penting tidak menghilang
- Ia harus berjalan di atas fondasi yang bisa 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 hati kepemimpinan satu perusahaan
- GitHub secara kebetulan ikut memegang peran arsip itu ketika menjadi pusat aktivitas open source, tetapi ketika sentralitasnya melemah, kita tidak bisa menganggap fungsi tersebut akan otomatis tetap terjaga
- Server pribadi dan niat baik saja tidak cukup untuk pelestarian, dan kekosongan setelah penutupan platform seperti Google Code dan Bitbucket sudah menunjukkan hal itu
- Sistem ke depan harus bergerak ke arah menjaga ingatan sambil mengurangi ketergantungan, sehingga perpindahan proyek, mirroring konteks sosial, dan pelestarian rilis menjadi mudah, dan keterombang-ambingan satu perusahaan tidak mudah berubah menjadi krisis kultural bagi semua orang
- Ketegangan itu tetap ada: kita tidak ingin kembali ke tautan tarball rusak dan instance Trac yang terbengkalai, tetapi kita juga tidak bisa menerima struktur 20 tahun terakhir yang berpusat pada GitHub sebagai keadaan normal yang permanen
3 komentar
Memang benar GitHub telah banyak berperan sampai sekarang, tetapi menurut ingatan saya, sebelum itu proyek open source hanya dikerjakan oleh orang-orang yang memang menekuninya, dan tidak banyak kasus individu yang merilisnya secara terbuka. Bahkan di dalam perusahaan pun kadang hanya dibagikan antar tim yang sama. Dan open source dianggap sebagai sesuatu yang sangat membanggakan bila Anda diterima sebagai kontributor pada proyek besar; sementara proyek pribadi yang kecil-kecilan nyaris tidak ada yang peduli.
Saya ingat awal mulanya juga didukung oleh berbagai keberuntungan: suasana di komunitas pengembang berubah, perangkat lunak yang dibuka ke publik dipakai sebagai sarana untuk mendapatkan pengakuan atas kemampuan diri, dan pada akhirnya git menjadi lebih luas dipakai dibanding beberapa DVCS lain. Para pesaingnya juga menyediakan layanan yang mirip, jadi menurut saya bukan karena GitHub secara khusus melakukan sesuatu jauh lebih baik.
Sebenarnya yang jadi masalah itu isu, PR, dan diskusinya;
gitsendiri bisa dipindahkan ke layanan lain kapan saja. Sepertinya ada juga proyek yang memasukkan ketiganya ke dalamgit, jadi kalau pakai yang begitu, sepertinya bisa pindah kapan saja.Opini Hacker News
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
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
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
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
Tapi saya ingat, untuk sementara waktu keunggulan itu tidak terlalu terlihat saat menangani blob besar
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
Rasanya terlalu banyak developer yang bahkan tidak tahu bahwa kode bisa disimpan di tempat lain
Kalau hambatan untuk membuat informasi bisa diakses dikurangi, konsentrasi kekuasaan juga akan berkurang
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?
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
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 membantuJika 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
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
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 BoogsSistem plugin-nya benar-benar luar biasa
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
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
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
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
Saya masih tidak percaya Google bisa meleset sebesar itu
Saya ada di tim itu sebelum layanannya ditutup