Transcript
00:00:00GitHub sedang berada dalam situasi yang sangat gawat, sangat buruk.
00:00:04Ada banyak sekali masalah, banyak di antaranya terkait dengan AI,
00:00:08tapi mungkin bukan karena alasan yang Anda pikirkan,
00:00:10nanti saya akan kembali membahas hal itu.
00:00:11Dan tentu saja itu penting.
00:00:13Itu penting karena GitHub adalah tulang punggung
00:00:16dari pekerjaan pengembangan modern.
00:00:17Tidak peduli apakah Anda melakukan pengembangan sumber terbuka,
00:00:20jika Anda mengelola beberapa proyek sumber terbuka,
00:00:22jika Anda hanya mengerjakan proyek Anda sendiri,
00:00:24proyek pribadi Anda, proyek sampingan Anda,
00:00:26jika Anda menjalankan bisnis kecil, perusahaan kecil,
00:00:29atau mungkin jika Anda berada di perusahaan yang lebih besar,
00:00:32ini digunakan untuk segala macam hal sebagai arsip kode
00:00:35untuk alur kerja CI/CD, untuk kolaborasi,
00:00:38untuk mengerjakan proyek bersama, melalui issue,
00:00:42untuk pull request dan banyak hal serta kasus penggunaan lainnya.
00:00:47Jadi itu penting, tapi seperti yang disebutkan,
00:00:49ada banyak sekali masalah.
00:00:51Dan mari kita mulai dengan apa yang salah
00:00:53sebelum kita melihat alasannya
00:00:54dan apa artinya bagi masa depan.
00:00:57Dan mari kita mulai dengan satu masalah besar.
00:00:59Ada sebuah kerentanan keamanan yang besar, sangat besar,
00:01:02luar biasa yang dilaporkan kemarin
00:01:07saat saya merekam ini.
00:01:09Eksekusi kode jarak jauh di github.com.
00:01:12Maksud saya, membaca hal itu saja sudah gila.
00:01:16Itu ditemukan oleh Viz, sebuah perusahaan keamanan,
00:01:19dan itu belum dieksploitasi.
00:01:21Jadi itu ditemukan, dilaporkan, dan diperbaiki.
00:01:25Tidak ada kerusakan yang terjadi.
00:01:28Menurut GitHub,
00:01:31mereka juga mempublikasikan jawaban atas laporan ini.
00:01:33Sekarang, saya tidak akan membahas detailnya
00:01:36tentang bagaimana kerentanan itu bekerja.
00:01:39Namun, saya akan menautkan artikelnya di bawah ini.
00:01:42Tapi pada akhirnya, semuanya bekerja melalui git push.
00:01:44Jadi tidak ada phishing yang terlibat,
00:01:46tidak ada pengambilalihan akun karyawan mana pun,
00:01:49tidak ada serangan rantai pasokan.
00:01:51Kita telah melihat banyak hal seperti itu selama beberapa minggu terakhir,
00:01:54tapi tidak, tidak ada hal seperti itu yang terlibat.
00:01:56Sebaliknya, itu hanya git push,
00:01:58dan kemudian secara spesifik fitur standar push option
00:02:03yang dapat Anda tambahkan ke perintah git push
00:02:05untuk melampirkan opsi tambahan ke perintah push tersebut.
00:02:10Dan melalui fitur opsi tersebut serta kerentanannya
00:02:13dan cara GitHub menangani push,
00:02:17para peneliti keamanan di sini dapat melampirkan kode
00:02:22yang akan langsung dieksekusi di server GitHub.
00:02:27Sekali lagi, detail tepatnya ada dalam laporan ini,
00:02:31tapi pada akhirnya, mereka menyalahgunakan fakta
00:02:34bahwa Anda bisa menambahkan metadata tambahan ke header xstat
00:02:39yang akan diisi dengan bantuan flag push options tersebut.
00:02:44Dan metadata tersebut, informasi yang bisa Anda teruskan
00:02:49bersama permintaan push melalui header tersebut pada akhirnya
00:02:52tidak disanitasi oleh GitHub.
00:02:54Mereka hanya mengautentikasi permintaan push pada akhirnya,
00:02:58perintah push tersebut.
00:02:59Mereka memeriksa apakah Anda diizinkan untuk melakukan push
00:03:01ke repositori yang ingin Anda tuju,
00:03:03tapi kemudian mereka mengambil data opsi tersebut
00:03:07dan membangun header xstat tanpa menyanitasi data tersebut.
00:03:12Dan hal itu memungkinkan para peneliti keamanan
00:03:15untuk mengeksekusi perintah yang kemudian tidak dibatasi
00:03:18pada repositori tempat mereka melakukan push,
00:03:21melainkan berjalan bebas di server GitHub
00:03:24dan dapat mengakses repositori lain juga,
00:03:27termasuk repositori privat.
00:03:29Sekali lagi, kerentanan ini telah dilaporkan dan diperbaiki
00:03:33dan sudah tidak ada lagi,
00:03:35tapi ini jelas merupakan masalah besar.
00:03:39Maksud saya, ini masalah yang sangat besar karena kerentanan ini
00:03:43memungkinkan eksekusi kode jarak jauh di github.com.
00:03:45Ini benar-benar luar biasa besar.
00:03:47Jadi ya, itu masalah besar,
00:03:48tapi tentu saja itu bukan satu-satunya masalah.
00:03:51Pada tanggal 23 April, jadi hanya beberapa hari sebelumnya,
00:03:56terjadi insiden besar terkait dengan GitHub merge queue.
00:04:01Sekarang, GitHub merge queue, jika Anda belum tahu,
00:04:04adalah fitur GitHub yang dimaksudkan untuk digunakan pada repositori
00:04:07di mana Anda memiliki banyak aktivitas, banyak pekerjaan aktif,
00:04:11banyak pull request yang masuk.
00:04:13Dan untuk memastikan bahwa Anda tidak perlu menggabungkan
00:04:16setiap pull request sebelum pull request baru dapat dikirim,
00:04:19karena tentu saja Anda ingin memiliki pull request
00:04:21terhadap status terbaru dari repositori tersebut,
00:04:24dari cabang utama, misalnya,
00:04:26untuk memastikan bahwa Anda tidak perlu menggabungkan
00:04:28setiap pull request sebelum yang baru dapat dibuka.
00:04:30Pada akhirnya, fitur merge queue ini ada,
00:04:34yang memiliki tujuan sederhana untuk secara efektif membuat
00:04:38seperti penggabungan perantara
00:04:42untuk menciptakan status baru dari repositori cabang tersebut
00:04:46yang ingin Anda gabungkan untuk setiap pull request.
00:04:49Dan jika ada pull request baru yang ditambahkan
00:04:51ke dalam rangkaian pull request tersebut,
00:04:53itu juga sudah digabungkan dikombinasikan dengan pull request
00:04:57sebelumnya ke dalam cabang utama
00:04:58sehingga pull request baru dibuka
00:05:01seolah-olah pull request sebelumnya sudah digabungkan.
00:05:05Dan hal itu memungkinkan tim untuk bekerja lebih cepat
00:05:08karena Anda dapat membuka lebih banyak pull request
00:05:10tanpa harus menunggu yang sebelumnya selesai terlebih dahulu.
00:05:13Pada suatu titik, tentu saja semuanya akan digabungkan,
00:05:15tapi ini memungkinkan Anda untuk terus bekerja,
00:05:17yang tentu saja penting bagi tim besar, misalnya.
00:05:19Sekarang hal yang juga penting terkait fitur itu
00:05:22tentu saja adalah fitur tersebut bekerja dengan benar.
00:05:24Dan apa yang terjadi pada tanggal 23 April adalah
00:05:28adanya sebuah kesalahan, kesalahan logika internal
00:05:32tentang bagaimana GitHub menyelesaikan berbagai pull request ini
00:05:37sehingga pada akhirnya hal itu menciptakan penggabungan
00:05:41yang akan menghilangkan beberapa informasi yang akan menyebabkan
00:05:45commit yang tidak valid dan menghapus bagian-bagian
00:05:49dari riwayat Git di sana.
00:05:50Sebenarnya datanya tidak benar-benar hilang,
00:05:53tapi fitur ini bekerja secara tidak benar
00:05:55dan menghasilkan commit yang salah tersebut.
00:05:57Itulah versi singkatnya, inti dari masalahnya.
00:06:00Dan tentu saja, hal ini juga sama sekali tidak dapat diterima
00:06:03jika Anda adalah perusahaan besar atau perusahaan mana pun yang bergantung
00:06:06pada fitur tersebut dan tiba-tiba proyek Anda berakhir
00:06:09dalam keadaan rusak tanpa ada penjelasan yang jelas
00:06:13mengenainya, hal itu tentu saja tidak dapat diterima.
00:06:16Dan pikiran pertama Anda tentu saja mungkin bukan
00:06:19bahwa ada beberapa bug internal dalam fitur merge queue itu.
00:06:23Mungkin Anda mengira Anda melakukan sesuatu yang salah.
00:06:26Jadi Anda menghabiskan banyak waktu mencari kesalahannya
00:06:28sampai Anda menemukan, oh tidak, ini kesalahan GitHub.
00:06:30Dan hal itu tentu saja muncul sebagai tambahan
00:06:33dari masalah uptime-downtime berkelanjutan yang dimiliki GitHub.
00:06:38Sekarang halaman status resmi memang terlihat buruk,
00:06:42tapi mungkin lumayan, tapi kita tidak memiliki angka uptime
00:06:46tiga sembilan (99,9%) di sini, setidaknya untuk sebagian besar sistem.
00:06:49Mereka memang melaporkan uptime secara terpisah untuk sistem yang berbeda.
00:06:53Tapi segalanya terlihat sedikit berbeda jika kita melihat
00:06:55halaman status GitHub yang hilang (missing GitHub status page),
00:06:57yang melacak uptime dengan cara yang berbeda
00:07:00dan menghitung setiap insiden kecil sebagai masalah,
00:07:04sebagai downtime pada akhirnya.
00:07:05Di sini kita melihat uptime yang mengerikan untuk sistem yang begitu krusial
00:07:10seperti GitHub, tentu saja sama sekali tidak dapat diterima.
00:07:14Jadi kita mengalami masalah uptime selama beberapa bulan terakhir
00:07:18dan bahkan sudah sejak tahun lalu.
00:07:20Dan juga ada bug-bug kecil di sana-sini,
00:07:23hanya saja tidak sebesar yang satu ini atau sepenting
00:07:26kerentanan keamanan ini.
00:07:28Tapi ya, ada banyak masalah
00:07:31dan GitHub jelas telah menjadi platform yang tidak dapat diandalkan
00:07:36saat ini, sayangnya,
00:07:38yang merupakan bencana mengingat peran dan pentingnya
00:07:43dalam pengembangan modern, seperti yang saya katakan di awal,
00:07:47tidak peduli jenis pekerjaan pengembangan apa yang Anda lakukan.
00:07:50Masalah lainnya adalah komunikasi dari pihak GitHub
00:07:54bisa dibilang tidak banyak.
00:07:59Belum banyak komunikasi yang dilakukan,
00:08:01tetapi ada sebuah postingan blog yang dibagikan pada tanggal 28 April
00:08:06sebelum kerentanan keamanan tersebut muncul,
00:08:10di mana mereka semacam menjelaskan apa yang terjadi,
00:08:14dari mana masalah-masalah tersebut berasal,
00:08:16bahwa mereka memahami bahwa strategi komunikasi mereka
00:08:19selama ini belum ideal dan segalanya akan menjadi lebih baik.
00:08:23Itulah bagian selanjutnya.
00:08:25Dari mana masalah-masalah tersebut berasal?
00:08:28Pernyataan resmi di sini menyebutkan AI sebagai alasannya,
00:08:32tapi bukan dalam artian para insinyur GitHub
00:08:36di Microsoft menggunakan AI dan merilis perangkat lunak yang rusak,
00:08:40pembaruan yang rusak ke GitHub.
00:08:43Hal itu mungkin saja terjadi, tapi kita tidak punya buktinya.
00:08:47Namun sebaliknya, alasan utama yang disebutkan di sini adalah, tentu saja,
00:08:51bahwa karena AI, ada jauh lebih banyak proyek
00:08:57yang dibuat, jauh lebih banyak kode yang dihasilkan,
00:09:00dan pada akhirnya semua proyek dan semua kode itu
00:09:03didorong (pushed) ke GitHub.
00:09:04Dan mereka membagikan beberapa, yah, ya, tidak terlalu membantu,
00:09:09tapi mereka membagikan beberapa grafik di sini.
00:09:12Grafik itu tidak terlalu membantu karena kita tidak memiliki sumbu y.
00:09:14Kita tidak melihat angka absolutnya,
00:09:17tapi tentu saja kita bisa melihat hubungannya di sini.
00:09:20Dan kita bisa melihat, tentu saja, bahwa sepanjang tahun 2025,
00:09:23terjadi peningkatan tajam dalam pull request yang digabungkan,
00:09:28commit yang didorong, dan tentu saja repo baru yang dibuka.
00:09:32Itu semua adalah proyek sampingan yang sekarang sedang kita buat
00:09:34dan tidak diselesaikan dengan bantuan AI.
00:09:36Dan kemudian pada tahun 2026, jelas untuk semua metrik ini,
00:09:41grafiknya melonjak sangat tinggi, saya rasa.
00:09:46Jadi ya, itu tentu saja tren yang cukup jelas.
00:09:49Dan lalu lintas ini, jenis peningkatan lalu lintas ini
00:09:54tentu saja akan membuat sistem apa pun berada di bawah tekanan.
00:09:58Ini sangat bermasalah bagi GitHub
00:10:01karena mereka sedang berada di tengah proses migrasi
00:10:05dari struktur monolitik dan dari pusat data khusus
00:10:09atau sistem mereka sendiri ke dalam cloud Azure
00:10:13dan ke dalam sistem yang lebih terpecah-pecah, sistem microservices,
00:10:17bisa dibilang begitu, alih-alih struktur monolitik tersebut.
00:10:21Itu adalah proses yang berkelanjutan bahkan sebelum kita memasuki tahun 2026.
00:10:26Tapi tentu saja itu berarti bahwa sekarang proses migrasi ini
00:10:31dihantam oleh lonjakan permintaan tersebut,
00:10:34yang berarti meskipun Anda sedang bermigrasi,
00:10:36Anda harus menstabilkan sistem saat ini
00:10:39sambil melanjutkan migrasi,
00:10:40yang kemudian diharapkan akan membantu lonjakan
00:10:44lalu lintas di masa depan.
00:10:46Itu harapannya, tentu saja, tidak ada jaminan.
00:10:50Tapi tentu saja itu adalah sesuatu yang harus dihadapi GitHub.
00:10:52Sekarang mereka menyatakan di sini bahwa mereka mulai menjalankan rencana
00:10:56untuk meningkatkan kapasitas GitHub sebesar 10 kali lipat pada Oktober 2025.
00:11:01Jadi bisa dikatakan di sekitar sini mereka melihat,
00:11:04yah, ini semua meningkat.
00:11:06Maksud saya, mereka sudah bisa melihatnya dari sebelumnya,
00:11:09tetapi di sinilah mereka memutuskan kita perlu meningkatkan kapasitas 10 kali lipat.
00:11:13Dan kemudian pada Februari 2026, mereka melihat,
00:11:16oke, kita butuh 30 kali lipat, bukan 10 kali lipat karena,
00:11:20karena perkembangan di sini, kan?
00:11:22Hal itu tentu saja harus dilakukan sebagai tambahan dari migrasi tersebut.
00:11:28Dan itu adalah tugas yang sangat besar, tentu saja.
00:11:33Sekarang ini adalah bagian dari Microsoft, jadi ini bukan startup kecil,
00:11:37namun tetap saja, ini adalah tugas yang menakutkan.
00:11:39Dan ini adalah salah satu aspek dari seluruh masalah GitHub ini
00:11:44di mana saya merasa simpati karena menurut saya mudah
00:11:47untuk membenci GitHub, untuk mengejek GitHub.
00:11:51Dan Anda pasti bisa melakukannya.
00:11:52Dan saya akan kembali ke lebih banyak masalah, yang sangat buruk.
00:11:56Tetapi lonjakan lalu lintas semacam ini akan menjadi masalah besar
00:11:59bagi sistem apa pun, bagi perusahaan apa pun di luar sana.
00:12:03Dan sulit untuk percaya bahwa pesaing GitHub mana pun
00:12:07akan melakukan lebih baik dalam situasi ini.
00:12:09Tetap saja, tentu saja, itu bukan alasan.
00:12:10Ini adalah bagian dari Microsoft.
00:12:12Oleh karena itu, mereka tentu saja memiliki sumber daya
00:12:16untuk melewati transisi itu dan menyesuaikan sistem mereka
00:12:20dengan dunia baru ini dan dengan jumlah lalu lintas yang baru ini.
00:12:24Tetapi ada masalah penting lainnya di sini dengan GitHub.
00:12:28Yaitu GitHub tidak lagi memiliki CEO.
00:12:32CEO sebelumnya, Thomas, Thomas Domke,
00:12:37pensiun atau mengundurkan diri atau mengumumkan akan mundur
00:12:41pada bulan Agustus 2025.
00:12:43Dan Microsoft tidak menunjuk CEO baru.
00:12:48Sebaliknya, GitHub menjadi bagian dari Core AI,
00:12:51sebuah divisi internal di Microsoft yang, seperti namanya,
00:12:56adalah tentang AI dan membangun alat serta platform AI.
00:13:01Dan GitHub adalah bagian dari itu.
00:13:03Jadi jelas misi GitHub dari sudut pandang Microsoft
00:13:07adalah menjadi bagian dari rantai alat AI tersebut,
00:13:11dari revolusi AI tersebut.
00:13:13Dan jelas Microsoft mendorong Co-Pilot
00:13:15ke dalam semua produk mereka.
00:13:16Dan memang di GitHub Universe 2023,
00:13:20mereka sudah mengatakan akan mengubah GitHub
00:13:24menjadi platform pengembang bertenaga AI
00:13:28dengan GitHub di mana-mana.
00:13:30Itu mencakup hal-hal seperti fitur baru
00:13:32yang membantu pembuatan issue dengan GitHub Co-Pilot,
00:13:36yang merupakan masalah besar bagi pemelihara open source,
00:13:39tetapi juga sekadar kehadiran GitHub Co-Pilot
00:13:43di mana-mana di GitHub.
00:13:44Ada hal Agent HQ ini di GitHub,
00:13:48[github.com/copilot](https://github.com/copilot),
00:13:49di mana Anda dapat berinteraksi dengan GitHub Co-Pilot
00:13:52dan mengerjakan kode Anda langsung dari dalam GitHub Co-Pilot
00:13:55tanpa perlu membuka IDE lokal atau alat agen pengkodean
00:14:00dan masih banyak bagian lainnya.
00:14:02GitHub Co-Pilot ada di mana-mana di GitHub,
00:14:05sama seperti Co-Pilot ada di mana-mana
00:14:07di semua produk Microsoft, saya rasa.
00:14:10Dan itu tentu saja merupakan keputusan strategis yang jelas
00:14:14yang agak bertentangan dengan misi sebenarnya dari GitHub,
00:14:19setidaknya misi yang dimiliki GitHub di masa lalu.
00:14:23Karena seperti yang saya sebutkan di awal,
00:14:25GitHub penting bagi berbagai jenis pengembang
00:14:29untuk segala macam kasus penggunaan.
00:14:31Pemelihara open source menggunakannya untuk menyimpan kode sumber
00:14:36di sana dan berkolaborasi dengan pemelihara lain
00:14:39dan kontributor lainnya dari komunitas.
00:14:41Issue sangat penting untuk mendeteksi, yah, masalah
00:14:45dan mengerjakannya.
00:14:46Pull request penting agar orang lain
00:14:50dapat berkontribusi ke basis kode.
00:14:52Diskusi bisa sangat berguna untuk membahas fitur baru
00:14:55atau arah dari suatu repositori atau pustaka dan sebagainya.
00:15:01Ada banyak fitur terkait di sini
00:15:03yang membantu pemelihara open source
00:15:04atau setidaknya membantu di masa lalu.
00:15:07Orang lain menggunakan GitHub hanya sebagai sumber daya
00:15:11untuk menghosting tautan atau dokumen
00:15:13seperti semua repositori luar biasa ini, awesome Go, awesome Rust
00:15:17dan seterusnya, yang dapat Anda gunakan untuk mencari sumber daya dengan mudah
00:15:20jika Anda ingin bekerja dengan Go atau Rust.
00:15:22Saya juga menggunakan GitHub untuk menghosting sumber daya kursus saya
00:15:26seperti di sini untuk kursus Codex saya, misalnya,
00:15:29dan untuk banyak kursus lainnya juga.
00:15:31Jadi Anda bahkan bisa menyalahgunakan GitHub
00:15:33sebagai semacam penyimpanan dokumen saja.
00:15:36Dan kemudian tentu saja Anda juga bisa menggunakan GitHub untuk pekerjaan CI/CD.
00:15:40Di sebuah perusahaan, Anda mungkin menggunakan GitHub
00:15:43untuk menaruh kode sumber Anda di sana, tentu saja,
00:15:46agar anggota tim Anda berkolaborasi pada kode sumber tersebut
00:15:50dengan pull request dan sebagainya.
00:15:52Dan kemudian tentu saja, GitHub sangat sering
00:15:54juga menjadi bagian dari alur kerja CI/CD
00:15:57di mana push baru ke branch utama, misalnya,
00:15:59memicu alur kerja CI/CD.
00:16:02Itu bisa dilakukan dengan bantuan GitHub action,
00:16:05meskipun produk tersebut memiliki masalahnya sendiri.
00:16:08Tapi tentu saja itu juga bisa untuk memicu alur kerja CI/CD
00:16:12pada penyedia CI/CD lainnya, bukan hanya GitHub action.
00:16:16Jadi GitHub tentu saja memiliki peran yang sangat penting
00:16:20untuk pekerjaan pengembangan tradisional klasik.
00:16:24Tapi tentu saja, Microsoft memutuskan bahwa tidak,
00:16:27itu harus menjadi platform pengembang bertenaga AI,
00:16:31bukan sekadar platform pengembang.
00:16:33Dan itu tentu saja merupakan semacam ketidakcocokan di sini.
00:16:37Pengembang tidak selalu menginginkan Co-Pilot
00:16:41di setiap aspek GitHub.
00:16:43Saya rasa pengguna produk Microsoft secara umum
00:16:46tidak menginginkan GitHub di semua produk mereka,
00:16:48tapi itu cerita yang berbeda.
00:16:49Dan GitHub telah mengabaikan fitur-fitur inti
00:16:53yang penting bagi pengembang.
00:16:56Maksud saya, lihat saja pekerjaan pengembangan open source.
00:17:00Pemelihara proyek open source kewalahan
00:17:03dengan issue dan pull request yang dihasilkan AI.
00:17:07Masalah di sini tentu saja adalah asimetri.
00:17:10Mudah menggunakan AI untuk menghasilkan kode atau issue.
00:17:14Jauh lebih sulit untuk meninjau semua hal itu.
00:17:19Yaitu meninjau kode dan issue yang dihasilkan tersebut.
00:17:24Dan maksud saya, itu adalah sesuatu yang diketahui setiap pengembang
00:17:26yang pernah bekerja dengan AI.
00:17:27Anda dapat dengan mudah menjalankan tiga agen AI atau lebih
00:17:30dan membiarkan mereka mengerjakan proyek Anda,
00:17:32benar-benar di luar GitHub.
00:17:33Anda dapat melakukannya di mesin Anda dengan Codex,
00:17:35Claude Code, dan sebagainya.
00:17:36Tetapi jika Anda tidak menempuh jalur pengkodean tanpa henti,
00:17:39yang menurut saya tidak seharusnya Anda lakukan,
00:17:41Anda harus meninjau kode tersebut pada suatu saat.
00:17:44Dan itu membutuhkan waktu.
00:17:45Dan itu tidak terlalu menyenangkan, setidaknya bagi saya.
00:17:48Sekarang, jika Anda menjalankan tiga agen,
00:17:51Anda harus meninjau output dari tiga agen tersebut.
00:17:54Anda dapat mengurangi jumlah agen jika itu terlalu banyak
00:17:57bagi Anda dan Anda merasa tidak benar-benar produktif
00:17:59dengan cara itu.
00:18:00Nah, saat Anda menjadi pemelihara open source di GitHub,
00:18:03Anda kewalahan dengan issue dan pull request buatan AI
00:18:07dan Anda hanya punya dua pilihan utama.
00:18:09Anda bisa mengabaikannya dan itu tentu saja menggagalkan tujuannya,
00:18:13tapi itu jelas merupakan strategi yang valid.
00:18:16Atau Anda mencoba untuk memeriksanya satu per satu
00:18:18dan Anda mengalami burnout karena itu terlalu banyak
00:18:21karena tidak seperti pekerjaan pengembangan pribadi Anda,
00:18:25Anda tidak bisa begitu saja mengurangi jumlah issue
00:18:29dan pull request yang masuk.
00:18:30Anda dapat menggunakan lebih sedikit agen sendirian
00:18:33jika Anda merasa tidak efektif atau tidak produktif
00:18:36dengan semua agen yang Anda coba jalankan.
00:18:38Anda tidak bisa melakukan itu dengan repositori publik.
00:18:41Anda tidak dapat mengontrol berapa banyak orang yang akan memposting
00:18:45issue buatan AI atau mengirimkan pull request kepada Anda.
00:18:49Jadi itu adalah masalah besar bagi pemelihara open source
00:18:53dan mengapa seluruh skena open source
00:18:56dan filosofi di balik open source
00:18:59sedang dalam masalah besar saat ini karena AI.
00:19:04Dan GitHub tidak membantu dalam hal itu.
00:19:06Sebaliknya, mereka melakukan hal yang berlawanan.
00:19:08Mereka secara aktif mempermudah issue sampah AI
00:19:13untuk dibagikan dan sebagainya.
00:19:15Apa yang dibutuhkan pemelihara dan pengembang
00:19:18adalah alat yang lebih efektif untuk menangani
00:19:22semua issue dan pull request buatan AI ini.
00:19:25Tetapi GitHub tidak mengerjakan hal itu.
00:19:27Sepertinya itu bukan bagian dari strategi mereka.
00:19:29Nah, mungkin itu akan berubah.
00:19:30Postingan resmi dari GitHub yang saya sebutkan tadi
00:19:35terutama berbicara tentang masalah reliabilitas dan uptime
00:19:39dan bahwa mereka ingin lebih transparan dan sebagainya.
00:19:41Tetapi mereka juga menyebutkan memiliki komitmen
00:19:44untuk mendukung pengembang.
00:19:46Kita lihat saja nanti, saya tidak terlalu optimis
00:19:49karena pada akhirnya ini adalah bagian dari Microsoft
00:19:52dan mereka memiliki strategi mereka sendiri di sini.
00:19:55Tapi apa artinya ini bagi GitHub?
00:19:59Apakah sudah waktunya untuk bermigrasi?
00:20:02Saya telah mendengar beberapa suara di sana-sini di X
00:20:05bahwa sekaranglah saatnya untuk alternatif GitHub.
00:20:08Saya tahu bahwa beberapa proyek telah bermigrasi.
00:20:12SIG mungkin adalah yang paling menonjol.
00:20:15Mereka bermigrasi dari GitHub ke Codeberg pada November 2025.
00:20:20Tapi mari kita realistis di sini.
00:20:22Pertama, seperti yang saya sebutkan sebelumnya,
00:20:24jumlah lalu lintas yang menghantam GitHub
00:20:28juga akan membebani pesaing mana pun.
00:20:31Bahkan mungkin lebih dari GitHub
00:20:32karena mereka bukan bagian dari Microsoft.
00:20:35Jadi kita pasti tidak akan melihat GitHub digantikan.
00:20:40Dan meskipun beberapa proyek individu,
00:20:42terutama proyek open source mungkin keluar dari GitHub
00:20:45karena alasan yang sangat saya pahami,
00:20:48semua perusahaan itu, semua pengembang individu itu
00:20:52kemungkinan besar tidak akan bermigrasi.
00:20:54GitHub memiliki, terlepas dari semua masalahnya,
00:20:57platform yang kaya fitur dengan fitur-fitur yang tidak terpisahkan
00:21:02dari banyak alur kerja pengembang dan pekerjaan sehari-hari.
00:21:06Khususnya bagi perusahaan, tentu saja,
00:21:08tidak mudah bagi mereka untuk mengganti GitHub begitu saja
00:21:11dengan penyedia lain.
00:21:13Meskipun semua masalah reliabilitas
00:21:15jelas merupakan masalah besar bagi perusahaan juga,
00:21:18mereka akan mampu dan mau menahan lebih banyak rasa sakit
00:21:23sebelum mereka mempertimbangkan untuk pindah.
00:21:25Saya yakin akan hal itu.
00:21:26GitHub adalah platform yang terlalu penting.
00:21:30Ini adalah platform untuk menaruh kode yang dikelola Git Anda
00:21:35ke cloud dan mengerjakannya serta berkolaborasi di sana.
00:21:39Jadi saya yakin GitHub tidak akan pergi ke mana-mana,
00:21:43bahkan jika situasinya memburuk.
00:21:45Tentu saja, pada akhirnya orang akan pergi
00:21:47jika GitHub tidak melakukan apa-apa,
00:21:49tapi jelas mereka melakukan sesuatu,
00:21:50setidaknya terkait masalah uptime dan reliabilitas.
00:21:55Mengenai pekerjaan open source dan masalah di sana
00:21:58serta masalah sampah AI, kita lihat saja nanti.
00:22:01Bahkan di sana, saya yakin GitHub terlalu penting
00:22:07dan memiliki terlalu banyak keuntungan bagi pemelihara open source
00:22:10untuk sekadar pergi, setidaknya tidak semuanya.
00:22:14Tetapi saya sangat mengerti jika proyek-proyek individu
00:22:17pindah dari GitHub, jadi itu mungkin saja terjadi.
00:22:20Tapi ya, bagi perusahaan dan GitHub secara umum,
00:22:23ia akan tetap ada.
00:22:24Meskipun demikian, kita hanya bisa berharap bahwa situasi ini
00:22:28mungkin menjadi semacam peringatan bagi Microsoft.
00:22:33Mungkin mereka akan menempatkan CEO kembali memimpin GitHub.
00:22:38Mereka mungkin memahami pentingnya GitHub.
00:22:41Mereka mungkin memahami bahwa ini adalah platform
00:22:45bagi pengembang, bukan platform AI sebagai utamanya.
00:22:49Tapi ya, kita hanya bisa berharap.
00:22:52Saya tidak tahu apakah dan kapan hal itu akan terjadi.
00:22:55Tapi ya, itulah situasi GitHub saat ini.
00:23:00Buruk, sangat buruk.
00:23:03Dan akan tetap buruk untuk masa depan dekat,
00:23:06tetapi setidaknya reliabilitasnya semoga akan membaik
00:23:11akhir tahun ini.
00:23:13Kita lihat saja nanti.