- Sejak diakuisisi Microsoft, ketersediaan (uptime) GitHub memburuk secara mencolok, dan bahkan halaman status resminya menunjukkan angka yang mengkhawatirkan, sementara halaman status tidak resmi menggambarkan situasi yang lebih serius
- Akibat penggunaan Copilot yang berlebihan dan banjir kode berkualitas rendah hasil AI (slop), GitHub seperti melakukan DDoS terhadap dirinya sendiri, sementara bot dan ekonomi bintang palsu merusak kepercayaan pada platform
- Git adalah sistem kontrol versi terdistribusi open source dan tetap dapat berjalan tanpa GitHub, jadi kita perlu lepas dari anggapan yang menyamakan GitHub dengan Git itu sendiri
- Ada berbagai forge Git alternatif seperti Codeberg, Tangled, Gitea, GitLab, dan Forgejo yang di-self-host, dan migrasi harus segera dimulai
- Sejumlah pengembang ternama terus menerbitkan tulisan yang menyatakan keluar dari GitHub, sehingga melepaskan diri dari ketergantungan pada GitHub muncul sebagai tugas bagi seluruh ekosistem
Alasan harus meninggalkan GitHub
- GitHub dikritik karena tingkat ketersediaan dan pengalaman pengguna memburuk setelah diakuisisi Microsoft, dan halaman status yang hilang dianggap menunjukkan tren yang lebih buruk daripada uptime resmi
- Grafik GitHub’s Historic Uptime digunakan sebagai bahan yang menunjukkan bahwa rata-rata uptime bulanan menjadi tidak stabil setelah akuisisi Microsoft
- Setelah mengakuisisi GitHub, Microsoft memperbanyak keluarga produk terkait Copilot, dan GitHub sendiri sampai merilis pembaruan masalah ketersediaan karena terus diganggu oleh “slop”
- Belakangan ini terus bermunculan tulisan tentang meninggalkan GitHub atau menengok kembali cara pengembangan sebelum era GitHub
Git ≠ GitHub
- GitHub telah menjadi sinonim dengan "manajemen source code", tetapi terlalu banyak pengguna yang tidak tahu bahwa Git bukanlah GitHub
- Git dan GitHub bukan hal yang sama, dan teknologi inti Git bersifat open source serta terdistribusi, sehingga semua repositori setara dan dapat berfungsi tanpa layanan terpusat
- Layanan terpusat adalah hasil dari kenyamanan sosial; GitHub awalnya hanyalah alat tambahan yang berguna, tetapi Microsoft mengubahnya menjadi beban mahal
- Efek jaringan memang kuat, tetapi ekonomi bintang palsu GitHub tidak punya nilai, dan platform itu dipenuhi bot serta slop
- GitHub Actions adalah bagian dari pipeline CI yang terlalu rumit. Mencari solusi lain memang merepotkan, tetapi kita perlu bertanya apakah stabilitas GitHub benar-benar bisa dipercaya
- Kapalnya sedang tenggelam, jadi meskipun tidak memindahkan semuanya sekaligus, proses migrasi harus segera dimulai
Alternatif dan cara berpindah
- Jalur keluar terdekat adalah pindah ke forge Git terpusat lain, lalu setelah mendaftar cukup push repositori ke upstream baru
- Beberapa layanan mungkin mengotomatisasi migrasi dan mendukung impor issue, tetapi tetap mungkin memilih membiarkan issue di GitHub apa adanya
- Semua alternatif di bawah ini bukan pilihan yang sempurna; kesamaan mereka hanya satu: mereka bukan GitHub
-
Alternatif forge Git terpusat
- Codeberg — proyek nirlaba yang digerakkan komunitas, serta alternatif aman dengan rekam jejak yang terbukti. Ini adalah instans utama dari Forgejo
- Tangled — startup tahap alfa, dengan integrasi AT protocol yang menarik sebagai opsi. Layak dipertimbangkan untuk proyek pribadi kecil
- Gitea — menyediakan hosting Git terkelola di cloud, dan merupakan proyek open source asli tempat Codeberg/Forgejo bercabang
- GitLab — kelas enterprise sehingga terasa berat dan membingungkan, tetapi bisa menjadi opsi yang cocok untuk pengambilan keputusan dalam organisasi
- Bitbucket — tidak direkomendasikan, tetapi tetap masuk kategori “bukan GitHub”
- Game of Trees, Radicle, Sourcehut — alternatif tambahan yang perlu diteliti sendiri
-
Self-hosting
- Cara berkolaborasi adalah persoalan terpisah, tetapi jika Linux bisa dipelihara dengan bertukar patch lewat mailing list email, sulit untuk langsung menyimpulkan bahwa itu mustahil hanya karena masalah skala
- Forge Git terpusat mungkin merupakan kompromi yang realistis, tetapi dengan mengingat bahwa ia juga bisa runtuh seperti GitHub, kita harus selalu memiliki rencana keluar
2 komentar
Kalau melihat fitur yang ditawarkan, cukup mengejutkan bahwa mereka berhasil memenuhi lebih dari 99% kebutuhan.
Komentar Hacker News
Semua orang ingin menyalahkan ini pada akuisisi Microsoft atau ketidakbecusan, tetapi jika melihat data yang dipublikasikan GitHub, tampak cukup jelas bahwa jumlah kode yang di-commit ke GitHub meningkat 10x karena AI, dan dampaknya menyebar ke CI, Actions, pengumpulan kode, dan seluruh sistem
Penulisnya menunjuk hal-hal aneh seperti MS Copilot sebagai penyebab, tetapi rasanya lebih seperti daftar hal yang dia benci daripada hubungan sebab-akibat
Sementara itu, ledakan kode akibat AI, si gajah di dalam ruangan, justru diabaikan
OpenAI merilis GPT-3.5 pada November 2022, atau praktis Desember, dan coding dengan model bahasa besar/agen seperti yang dijelaskan baru benar-benar meluas pada 2024, bahkan terasa lebih dekat ke 2025
Jadi bagaimana menjelaskan buruknya ketersediaan selama sekitar 4 tahun setelah akuisisi, sebelum pembicaraan soal AI dimulai?
Tidak masalah ikut mengkritik Microsoft, tetapi jangan sampai melewatkan gajah di dalam ruangan
Bahkan jika besok muncul pengganti GitHub yang sempurna, apa yang bisa mencegah kode hasil AI berjuta-juta baris merusak infrastruktur di sana?
Hosting kode terpusat tampaknya hampir akan mati karena AI. Mirip dengan apa yang terjadi di media sosial
10 tahun itu waktu yang panjang, dan hasilnya mulai terlihat
GitHub Actions, Copilot, pencarian AI jelek yang bahkan tidak bisa dimatikan. Sampai migrasi ke Azure
Microsoft berhasil merusak efek jaringan, dan gangguan ini adalah sedotan terakhir yang mematahkan punggung unta
Mereka punya codebase internal yang sangat besar dan sekitar 200 ribu karyawan
Terutama karena mereka secara sadar membuat keputusan seperti menggratiskan private repository, ini sulit dijadikan alasan
Setiap kali GitHub down, aku berpikir, “Pasti ada yang meng-update Windows Server tempat GH berjalan lalu harus me-reboot semuanya”
Aku yakin 99% itu tidak benar, tetapi memikirkannya begitu bikin hati lebih tenang dan sedikit lucu setiap kali ada outage
Hari ini aku mencoba melihat repository di GitHub
Aku menekan tautan “xxx commits” untuk melihat riwayat commit, lalu muncul pesan bahwa aku kena secondary rate limit dan harus menunggu
Aku satu-satunya orang di jaringan ini yang membuka GitHub, dan koneksinya juga IP khusus, bukan CGN
Setelah itu halamannya akan termuat dengan normal
Kenyataannya selama bertahun-tahun ini lebih mirip penolakan default daripada rate limit, tetapi mereka menolak mengubah teksnya agar sesuai kenyataan
“GitLab - enterprise-grade artinya besar, membingungkan, tetapi terlihat mengesankan bagi atasan. Kalau butuh beberapa rapat hanya untuk memilihnya, maka pilih ini.”
Lucu
Untuk melakukan hal paling sederhana pun UI-nya terlalu rumit. Misalnya, untuk menyetujui MR, praktis harus menekan tombol yang sebenarnya seperti menu, diff sulit dibaca, dan ‘To-do list’ bahkan berisi MR yang sudah di-merge. Bagaimana itu bisa dianggap tugas yang bisa ditindaklanjuti?
Masalah MR yang sudah di-merge tetap muncul di ‘To-do list’ sudah dilaporkan sejak beberapa tahun lalu, tetapi perbaikannya tampaknya lambat
Sebaliknya, reaksi negatif terhadap Bitbucket agak mengejutkan. UI-nya sangat sederhana dan jelas, dan orang-orang yang baru bergabung juga merasa begitu. Jika memakai Script Runner, banyak hal yang cukup luar biasa bisa dilakukan, dan ia juga menangani repository besar dengan baik
GitLab tidak secara khusus lebih besar atau lebih membingungkan daripada GitHub
Bahkan sulit dibilang sebagai software enterprise-grade yang sesungguhnya. Kalau mau yang seperti itu, lihat saja Jira atau apa pun buatan Microsoft
Kami memakai GitLab self-hosted, dan aku yang memilihnya karena ada git dan container registry
Kalau tidak sering memakai web UI, antarmukanya memang bisa terasa membingungkan
Dengan 5 dolar per bulan, Anda bisa meng-host satu server dan menaruh beberapa proyek di sana
Repository-nya mungkin tidak akan mendapat sejuta bintang, tetapi itu cukup untuk kebutuhanku dan aku juga bisa memberi akses kepada siapa pun yang kuinginkan
Aku tidak begitu tahu harus membaca grafik itu bagaimana
Di satu sisi, bisa saja ketersediaan memang memburuk karena akuisisi GitHub
Di sisi lain, agak mencurigakan bahwa sebelum akuisisi ketersediaannya tampil 100.00%, jadi mungkin saja yang berubah hanya status page mulai diperbarui dengan lebih baik
Aku tahu ada masalah ketersediaan GitHub belakangan ini, tetapi di grafik masalahnya terlihat mulai pada 2020 dan tidak tampak memburuk secara drastis
Rasanya repository open source besar pada akhirnya memang mustahil dibiarkan tetap tenang
Aku ingat bagaimana SourceForge memburuk, dan sungguh menyedihkan melihat hal yang sama terjadi di GitHub
Tambahan lagi, aku sempat membaca URL itu sebagai “dBus hell”. Semua orang pernah mengalami itu setidaknya sekali
Aku sering memikirkan apa yang akan kulakukan kalau menjalankan perusahaan
Aku benar-benar ingin melihat seperti apa jika semua code review dilakukan lewat email
Repository cukup berupa server ala VPS sederhana yang hanya memberi akses SSH khusus git, ada namespace branch
for-review/untuk kode yang ditinjau, dan CI bisa dibuat sebagai bot yang menunggu branch muncul lalu memberi komentar atau tag pada ref untuk menandai lulus atau tidak. Hasilnya juga bisa dibalas ke thread emailMailing list tentu bisa diberi web archive viewer agar review lama bisa dilihat. Solusi seperti ini sudah banyak ada, dan pada dasarnya cuma HTML
Untuk chat cukup pakai IRC dan bot menyimpan arsip kanal. Sangat mudah
Seluruh sistem bisa dijalankan di server yang sangat murah, kecuali runner CI yang butuh hardware lebih kuat
GitHub terasa jauh terlalu overengineered dibanding yang benar-benar dibutuhkan untuk menjalankan proyek perangkat lunak. Lihat kernel Linux, yang memakai mailing list sederhana, dan sulit membantah bahwa itu salah satu proyek perangkat lunak tersukses sepanjang masa
Hanya saja issue/bug tracking terasa agak lebih menakutkan. Soalnya aku bisa saja terlalu tenggelam membangun solusi sendiri sampai malah lebih sibuk dengan itu daripada bisnis utama perusahaan. Mungkin sekalian jadi perusahaan software pelacak bug?
Maksudnya, aku ingin bisa melihat komentar itu tepatnya menempel pada baris yang mana, kapan baris itu berubah, lalu berpindah melihat konteks sebelum dan sesudahnya
Email mungkin cukup sebagai protokol untuk bertukar data ini, tetapi menurutku klien email bukan cara yang enak untuk menampilkannya
Mungkin kita juga butuh sistem code review terdistribusi
Tinggal di Eropa Timur juga ada keuntungannya
Karena zona waktu, aku hampir tidak pernah menyadari outage GitHub besar
Aku juga puas dengan gratisan hosting dan Actions yang mereka berikan cukup murah hati
Sejak memasang Forgejo di server rumah, aku tidak pernah menoleh lagi
Satu-satunya masalah adalah saat meng-host aplikasi di DigitalOcean App Platform atau Vercel, karena mereka hanya terhubung ke GitHub
DigitalOcean App Platformmendukung deployment bukan hanya dari GitHub tetapi juga dari GitLabHanya saja harus memakai instance yang di-host di gitlab.com, bukan instance GitLab self-hosted
Kalau Anda sudah memasang forge self-hosted, Anda bisa memakai gitlab.com sebagai jembatan untuk terhubung ke DigitalOcean App Platform. Cukup buat akun gitlab.com sekali, lalu biarkan forge self-hosted mengirim mirror ke gitlab.com. Praktis Anda tidak perlu benar-benar memakai GitLab
Meski begitu, tetap tidak masuk akal bahwa DigitalOcean, perusahaan yang menjual IaaS/PaaS, tidak membiarkan Anda terhubung ke Forgejo self-hosted atau yang sejenis yang berjalan di infrastruktur mereka sendiri
Sebenarnya banyak orang ingin meng-host forge sendiri, tetapi tidak banyak yang ingin men-setup dan mengoperasikannya sendiri. Jadi aneh juga bahwa DigitalOcean tidak mengambil Forgejo atau alternatifnya lalu menawarkan opsi deployment one-click semi-managed dengan harga diskon besar seperti 20 dolar per tahun, plus dukungan kelas satu untuk integrasi App Platform
Aku memakai DigitalOcean, tetapi hanya VPS-nya
Jangan terjebak vendor lock-in di lapisan tengah seperti ini; pertahankan kendali dan targetkan lapisan stack yang seumum mungkin
Aku pindah ke Gitea sejak beberapa tahun lalu, bahkan sebelum fork Forgejo, dan tidak menyesal
Saat perlu GitHub, aku bisa membuat repository bermirror ke sana agar tetap bekerja. Hanya saja sinkronisasi kodenya agak merepotkan
GitHub kesulitan karena coding yang diperkuat AI membuat jumlah commit naik 14x selama setahun terakhir, dan lajunya masih terus meningkat
Situsnya kesulitan mengejar
COO GitHub mengonfirmasinya di sini: https://x.com/kdaigle/status/2040164759836778878
Aktivitas platform sedang melonjak. Pada 2025 ada 1 miliar commit, sekarang sudah 275 juta per minggu, jadi bahkan kalau pertumbuhannya tetap linear saja, laju tahun ini sudah setara 14 miliar. Dan tentu saja ini tidak akan berhenti secara linear
GitHub Actions naik dari 500 juta menit per minggu pada 2023 menjadi 1 miliar menit per minggu pada 2025, dan minggu ini sejauh ini sudah mencapai 2,1 miliar menit
Jadi mereka sedang mendorong besar-besaran penambahan CPU, penskalaan layanan, dan penguatan fungsi inti GitHub