- Các sự cố GitHub lặp đi lặp lại đã đến mức thực sự cản trở việc review PR và công việc hằng ngày, làm lộ rõ sự phụ thuộc vào issues, PR và Actions mà chỉ một kho Git phân tán là không thể giải quyết
- Trong một tháng qua, gần như ngày nào vấn đề của GitHub cũng ảnh hưởng đến công việc, và ngay trong ngày viết bài, sự cố GitHub Actions cũng đã chặn việc review PR trong khoảng 2 giờ
- Điểm đến tiếp theo vẫn chưa được quyết định; nhóm dự định sẽ dần giảm phụ thuộc vào GitHub trong khi xem xét nhiều dịch vụ thương mại và nhà cung cấp FOSS
- Một mirror chỉ đọc sẽ vẫn được giữ ở URL hiện tại, và thay đổi lần này trước mắt chỉ áp dụng cho Ghostty; các dự án cá nhân khác vẫn sẽ ở lại GitHub trong thời gian tới
- Quyết định này không phải phản ứng vội vàng trước sự cố diện rộng ngày 27/4/2026, mà đã được thảo luận từ nhiều tháng trước; việc quay lại không phải là lời hứa mà chỉ có thể xảy ra khi có cải thiện thực chất được xác nhận
Bối cảnh chuyển đi
- Ghostty đã quyết định rời GitHub và cho rằng các sự cố lặp lại gần đây đã đến mức cản trở công việc thực tế
- Tác giả cho biết đã ghi lại riêng những ngày mà sự cố GitHub ảnh hưởng đến công việc trong một tháng qua, và gần như ngày nào cũng có vấn đề
- Ngay trong ngày viết bài, tác giả cũng không thể tiến hành review PR trong khoảng 2 giờ vì sự cố GitHub Actions
- Các hạ tầng xung quanh như issues, PRs và Actions mới là trung tâm của vấn đề; chỉ riêng việc Git là hệ thống phân tán không thể giải quyết được điều này
- Khi tình trạng công việc bị chặn nhiều giờ mỗi ngày tiếp diễn, tác giả cho rằng GitHub không còn có thể được xem là một không gian làm việc nghiêm túc nữa
Kế hoạch và phạm vi
- Điểm đến tiếp theo của Ghostty vẫn chưa được chốt, và hiện nhóm đang tiếp tục trao đổi với nhiều dịch vụ thương mại và nhà cung cấp FOSS
- Kế hoạch là không cắt hoàn toàn sự phụ thuộc vào GitHub trong một lần, mà sẽ loại bỏ dần từng bước
- Nhóm dự định để lại một mirror chỉ đọc trên GitHub tại URL hiện tại
- Thay đổi lần này trước mắt chỉ áp dụng cho Ghostty; các dự án cá nhân và công việc khác vẫn sẽ ở lại GitHub trong thời gian tới
- Vì Ghostty là dự án có tác động lớn nhất đến bản thân tác giả, các maintainer và cộng đồng mã nguồn mở, nên trọng tâm của thay đổi lần này cũng đặt vào đó
Bối cảnh bổ sung
- Dù thời điểm trùng với sự cố diện rộng ngày 27/4/2026, kế hoạch rời GitHub đã được bàn thảo từ nhiều tháng trước, và quyết định cuối cùng chỉ được đưa ra trong tuần này
- Nội dung bài viết được soạn trước sự cố Elasticsearch diện rộng, và sự cố trong ngày được nhắc đến trong bài là một sự cố riêng biệt
- Nếu GitHub thực sự cải thiện, họ có thể quay lại vào một ngày nào đó; nhưng điều kiện để quay lại không phải là lời nói hay cam kết, mà phải là kết quả và cải thiện thực chất
3 bình luận
Những ai đã chuyển sang nơi khác (như Codeberg) từ trước có lẽ khi nhìn vụ việc lần này sẽ càng thêm chắc chắn rằng mình đã chuyển đi là đúng.
Mitchell Hashimoto còn viết trong bình luận trên HN rằng anh thực sự đã rơi nước mắt, nên tôi thử xem
https://x.com/mitchellh/status/2049213597419774026
Hóa ra anh ấy là người dùng GitHub số 1299, đăng ký từ tháng 2 năm 2008.
Có vẻ dạo này GitHub thật sự gặp khá nhiều vấn đề. Vài giờ trước cũng đã có bài GitHub hiện đang gặp sự cố được đăng lên.
Ý kiến trên Hacker News
mitchellh: Tôi đã thật sự khóc khi viết bài này, hoàn toàn không hề cường điệu
GitHub với tôi không chỉ đơn thuần là một SaaS, mà còn mang ý nghĩa lớn hơn nhiều, nên mối quan hệ ấy đã trở nên khá sâu đậm đến mức không còn lành mạnh nữa
Chúng tôi đã nói chuyện ngắt quãng trong vài tháng, rồi vài tuần gần đây mới thảo luận nghiêm túc, vài ngày trước mới chốt quyết định cuối cùng, nhưng đến khi chính tay công bố bài viết này thì nó mới thật sự trở nên quá đỗi thực tế
Có thể sẽ có người cười nhạo, nhưng tôi thật sự rất quý GitHub và mong nó tìm lại được con đường của mình
Tôi là GitHub User 22723, mà giờ số tài khoản đã khoảng 180 triệu, nên thực tế là tôi đã đồng hành cùng nó gần như từ những ngày đầu
Nói theo cách của tôi thì GitHub chỉ có thể tốt lên nếu những người còn quan tâm ở lại và làm cho nó tốt hơn
Khi rời Heroku khoảng 6 năm trước, dù đã dùng rất hài lòng gần 10 năm, tôi cũng không mở lại dashboard nữa, và cuối cùng cảm thấy Salesforce đã thật sự phá hỏng nó
Nhưng với GitHub thì tôi không thể rời đi như thế
Nó đúng là có phần rối loạn khi cùng lúc phải trải qua agentic coding và tăng trưởng bùng nổ, nhưng tôi thấy chuyện này khác với kiểu sụp đổ Heroku/Salesforce
Thay vì giải thích bằng việc có thêm AI coding hay chỉ do Microsoft xấu xa, có lẽ hợp lý hơn khi cho rằng quy mô và chính nền tảng dưới chân các developer đã thay đổi
Tôi hy vọng họ làm tốt đến mức khiến người ta muốn quay lại, và việc có cảm xúc mạnh với thứ nằm ở trung tâm đời sống của developer hoàn toàn không hề ngớ ngẩn
Cảm giác muốn làm việc mà cứ bị cản trở, muốn triển khai phần mềm mà lại thấy như dịch vụ không hề muốn điều đó, là điều tôi đặc biệt đồng cảm
Cảm xúc này không chỉ riêng GitHub, mà có vẻ như web nói chung dạo này cũng đang ngày càng cẩu thả và chất lượng thấp đi
Quá nhiều sự cố liên tục, bug, những vướng víu nhỏ trong UI, và các tính năng chưa hoàn thiện đến mức tôi không hiểu chuyện gì đang diễn ra nữa
Cảm ơn vì đã làm ra ergonomic software cho con người
Nó là phép so sánh rằng thứ có vẻ tầm thường trong mắt người khác lại có thể là món đồ chứa đựng tình cảm và ký ức tích lũy từ rất lâu với chính người trong cuộc
https://knowyourmeme.com/memes/spool-of-wire-guy
Trong đời luôn có những thứ ta thích và yêu quý, nên khi phía mà ta từng ủng hộ trở nên tệ đi thì buồn là chuyện đương nhiên
Tôi cũng sẽ không cười nhạo vì lý do này, và còn thấy bực với những người chế giễu chuyện đó
Chỉ là thành thật mà nói, tôi không lạc quan rằng GitHub sẽ tìm lại được hướng đi
Chứng kiến GitHub suy sụp ở cấp độ tổ chức quả thật khá đáng kinh ngạc
Có nhiều cách giải thích như việc sáp nhập vào Microsoft, chuyển nguồn lực sang Copilot, cấu trúc tổ chức, vibe coding, nhưng dù lý do là gì thì cũng khó phủ nhận là đang có vấn đề nghiêm trọng
Lịch sử mà trang trạng thái không chính thức cho thấy cũng khá kinh khủng
Tôi muốn nghe góc nhìn từ bên trong, nhưng hiện giờ nó giống như một con tàu đang chìm vẫn còn trôi nhờ quán tính, mà trong lúc cả ngành phần mềm đang rung chuyển thì chỉ dựa vào quán tính có lẽ sẽ không trụ nổi
Nó đang được vận hành theo đúng kiểu mà nhiều dịch vụ thường gặp sau khi bị công ty lớn thâu tóm
Ban đầu vẫn ổn, rồi từ từ đi xuống, cuối cùng sụp đổ, và mọi thứ trở thành trò chơi số liệu
Microsoft, Oracle, VMware, CA, Salesforce đều có những ví dụ tương tự, và đội ngũ thật sự xử lý M&A tốt thì cực kỳ hiếm
https://onlineornot.com/uptime-calculator/87.25
Khi phình to quá mức mà không có lãnh đạo đủ tốt thì sớm muộn gì cũng sụp
Cảm nhận thực tế cho thấy con số còn tệ hơn
Ngay cả trước khi bị thâu tóm, cũng đã có thời GitHub hoạt động kiểu tung đồng xu xem hôm nay site có chạy ổn không
Nó thành công vì xuất hiện đúng nơi đúng lúc, chứ về bản chất vốn là một hệ thống chắp vá khá lỏng lẻo
Tôi hiểu tình cảm chân thành mà Hashimoto dành cho GitHub và thế giới mã nguồn mở
Nhưng tôi nghĩ nếu có thêm một chút thái độ kiểu Richard Stallman rằng phần mềm không tự do về bản chất là đáng nghi và phi đạo đức, thì có lẽ nỗi tổn thương này đã nhẹ hơn
GitHub năm 2008 cũng như bây giờ đều là phần mềm không tự do, chạy trên máy chủ của người khác theo luật của người khác, và cuối cùng vẫn được vận hành vì lợi ích của chủ sở hữu
Tôi cũng dùng nó rất lâu, và nhiều lúc vì công việc nên buộc phải dùng, nhưng chưa từng gắn bó về mặt cảm xúc
Việc nó được xây trên free-software là git nhưng lại có cấu trúc cố trói người dùng vào nền tảng luôn khiến tôi khó chịu
Tôi không thể yêu một phần mềm đòi hỏi tài khoản email và phải đồng ý điều khoản sử dụng, lại còn không hoạt động ở Iran vì luật trừng phạt của Mỹ
Vì vậy, việc ghostty rời GitHub khiến tôi vui mừng mà không chút lấn cấn
Ở KDE, gần như chưa bao giờ chúng tôi nghiêm túc cân nhắc GitHub, mà tự vận hành git infra của mình, rồi sau đó cùng Gnome hợp tác với GitLab để đưa những tính năng thực sự cần trong Enterprise Edition sang Community edition
Trong 16 năm qua, tôi nghĩ chỉ đúng một lần có sự cố git kéo dài nhiều giờ
Chỉ cần nhìn xem nó có đáng để tôi bỏ thời gian và tiền bạc hay không
Nó có thể gây tiêu hao cảm xúc như chuyện Netflix tăng giá hay game, nhưng nếu không còn giá trị thì cứ rời đi thôi
Dĩ nhiên tôi vẫn hiểu việc có sự gắn bó cảm xúc, như với những ký ức từ thời kỳ đầu của máy tính
Tôi ngày càng thấy việc nhúng sẵn những thứ như issue tracker vào ngay trong git repo là hướng rất hợp lý
Tôi nghĩ kiểu đau đớn này sinh ra vì không nhìn đến cùng vấn đề của closed source software
Từ sau vụ bán Hashicorp, tôi đã mất đi rất nhiều sự tôn trọng
Trước đây trong một thread Mitchell chỉ trích GitHub trên X, tôi thấy có những reply nói GitHub nên mời anh ấy làm CEO, và tôi thấy điều đó khá có lý
Người có thể xoay chuyển con tàu này không thể chỉ là nhà quản lý đơn thuần, mà phải là người vừa có niềm tin mạnh mẽ, năng lực thực thi, vừa có khả năng thu hút nhân tài
Tôi tin rằng rồi sẽ có một GitHub mới xuất hiện, và nếu mọi thứ khớp đúng thời điểm như OpenClaw hay GitHub ngày xưa từng làm trong thời SVN·SourceForge, nó có thể tăng trưởng rất nhanh
Có vẻ cũng đã có khá nhiều nỗ lực nhắm đến vị trí đó
Dù vậy, nếu xét theo tiêu chí dịch vụ cốt lõi thì tôi vẫn thấy chưa có UI tốt, đặc biệt với các dự án phức tạp
Trong khi đó, jujutsu có vẻ có định hướng nền tảng khá tốt, nhưng vẫn chưa có forge tử tế
Code, wiki và issue về cơ bản đều được quản lý phân tán trong một công cụ duy nhất
Nếu AI thật sự thay thế được phát triển phần mềm theo đúng cách giới lãnh đạo Big Tech mong muốn thì có thể hai phía sẽ lại khớp nhau, nhưng hiện giờ mọi người cần một git remote ổn định, còn thứ họ nhận được lại là một host chập chờn trộn cùng các tính năng vibe coding nửa vời
Lý do lớn nhất khiến mọi người đổ về GitHub là vì có thể dễ dàng cộng tác qua issue và PR ngay cả khi từng self-hosted forge không mở đăng ký thành viên, mà điều đó hoàn toàn có thể giải quyết mà không cần dồn toàn bộ code vào một hạ tầng đang đi xuống
Có lẽ khó thành hiện thực, nhưng nếu làm được thì sẽ rất tuyệt
Tôi khá tò mò 5 năm nữa hệ sinh thái developer sẽ thay đổi thế nào, và GitHub 5 năm nữa sẽ trông ra sao
Tôi hầu như không mở web GitHub mà dùng github cli rất nhiều
Chỉ với gh đã làm được hầu hết việc cần làm, Actions thì chạy trên GitHub, agent lấy kết quả rồi đọc issue và sửa code, nên toàn bộ workflow thật ra đã thay đổi rồi
Nếu có nhiều người đồng cảm với nhận định rằng GitHub không còn là nơi vui vẻ nữa, và cứ như đang ngăn cản việc làm việc lẫn triển khai, thì Redmond cần phản ứng thật mạnh
Nếu cảm giác này thật sự lan rộng, đó có thể là đòn chí mạng với Microsoft
8 năm trước họ chi gần 8 tỷ USD để lấy developer làm trụ cột chiến lược, rồi còn bỏ ra 2 tỷ USD cho Minecraft để kéo luôn cả lớp developer trẻ
Họ đã mất vị thế ở mảng OS và server, nếu còn mất cả developer thì có thể sẽ đi theo con đường giống Xerox của thế kỷ 21
Microsoft có thể không quá áp đảo hoặc còn có nguy cơ thua ở game, mobile, AI, nhưng họ vẫn giữ được một lượng khổng lồ nhân viên văn phòng phổ thông chỉ cần Word và Excel
Có quá nhiều người không quan tâm công nghệ nhưng bị trói chặt vào Office
Việc một trong những kỹ năng thực dụng mà Claude học rất sớm là tạo file .docx cũng cho thấy điều đó
Vấn đề không nằm ở git tự thân, mà nằm ở lớp hạ tầng đặt phía trên như issue, PR, Actions
Nếu phải đề xuất thì kể cả khi chuyển sang forge khác, vẫn nên dùng thêm git-bug
Nó lưu issue, PR và những thứ tương tự ngay trong git bằng special ref chứ không phải branch, đồng thời hỗ trợ đồng bộ hai chiều với nhiều nhà cung cấp khác nhau
Những VCS khác như fossil cũng lưu issue cùng với repo, và tôi thấy điều đó hợp lý vì issue cũng là một phần tạo ý nghĩa cho code giống như tài liệu
Khi mọi thứ đều nằm trong repo thì đúng là thuận tiện hơn
Chỉ là giờ gần như mọi thứ còn bị một LLM coding agent hầu như không giới hạn cùng xử lý, nên khóa phạm vi truy cập lại càng khó hơn
Tôi biết vế sau đang được làm theo hướng như web UI, nhưng trước lúc đó thì nếu muốn người dùng phổ thông vẫn có thể gửi issue, rốt cuộc vẫn cần hạ tầng công khai
Trong dự án của tôi, tôi dùng nó ở https://github.com/stryan/materia, và nó rất tốt cho việc tập trung hóa repo lẫn issue
Nhưng với đầu vào ngẫu nhiên từ người dùng, tôi vẫn dùng GitHub Discussions như một pseudo bug tracker
Nếu là bug thì tôi thêm vào git-bug và đồng bộ với GitHub issues để hiện công khai, nhưng cách này không thực sự hợp với lượng lớn báo lỗi từ người dùng
Trớ trêu là tôi lại lấy ý tưởng workflow này từ ghostty và mise, cả hai đều nhận báo lỗi trước qua discussion rồi chỉ tạo issue có gắn nhãn khi thật sự tái hiện được
Một mẹo rất đáng giá
Tôi tò mò đâu là nguyên nhân phải chịu trách nhiệm lớn nhất cho việc chất lượng GitHub giảm mạnh
Có lời giải thích rằng mã do AI tạo đã làm chất lượng codebase đi xuống, cũng có giải thích rằng sau khi Microsoft thâu tóm thì văn hóa kỹ thuật tệ lan rộng
Có thể cả hai yếu tố đều trộn lẫn ở mức nào đó
https://news.ycombinator.com/item?id=45517173
https://github.blog/news-insights/company-news/an-update-on-github-availability/
Có vẻ là kết quả của việc trộn văn hóa và hạ tầng Microsoft vào, và giờ chất lượng của nó bắt đầu giống các dịch vụ Microsoft khác
Nói thêm thì binary của dotnet CLI được host quá thiếu ổn định đến mức CI của tôi hay gãy, nên tôi phải tự host lại
Trên trang Pull Request, kết quả vẫn hiển thị thiếu sót, và vẫn xảy ra những sự cố kiểu dữ liệu không mất nhưng danh sách không hiện đúng cho đến khi reindex xong vì đang nạp lại Elasticsearch index
Anh ấy nói sẽ chia sẻ chi tiết hơn trong vài tháng tới về nơi chuyển Ghostty sang, nhưng như vậy cũng có thể bị hiểu là để phản ứng chuyện GitHub Issues hay PR đôi lúc không truy cập được trong ngày, lại tự tạo ra trạng thái không truy cập được trong nhiều tháng
Quyết định này có vẻ hơi cảm tính và vội vàng, và tôi không chắc nó thật sự tốt cho bản thân anh ấy, cho Ghostty hay cho cộng đồng
Ít nhất thì tôi mong anh ấy đã chuẩn bị đường lui dự phòng rồi mới hành động