- Sự cố GitHub lặp đi lặp lại đã đạt đế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·Actions mà chỉ riêng kho Git phân tán không thể giải quyết
- Trong một tháng qua, gần như ngày nào vấn đề GitHub cũng ảnh hưởng đến công việc, và ngay trong ngày viết bài, sự cố GitHub Actions đã 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; dự án đang xem xét nhiều dịch vụ thương mại và nhà cung cấp FOSS, đồng thời có kế hoạch giảm dần sự phụ thuộc vào GitHub
- URL hiện tại sẽ vẫn để lại bản mirror chỉ đọc, và thay đổi này trước mắt chỉ áp dụng cho Ghostty; các dự án cá nhân khác vẫn sẽ tiếp tục ở lại GitHub trong thời gian tới
- Quyết định này không phải được đưa ra vội vàng để phản ứng với sự cố diện rộng ngày 27 tháng 4 năm 2026, mà đã được thảo luận từ nhiều tháng trước; việc quay lại 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 di chuyển
- Ghostty đã quyết định rời GitHub và cho rằng các sự cố lặp lại gần đây đã đạt đến mức cản trở công việc thực tế
- Trong một tháng qua, tác giả đã ghi lại riêng những ngày sự cố GitHub ảnh hưởng đến công việc và cho biết gần như ngày nào cũng có vấn đề
- Ngay trong ngày viết bài, do sự cố GitHub Actions, tác giả đã không thể tiến hành review PR trong khoảng 2 giờ
- Các hạ tầng xung quanh như issues, PRs, Actions mới là trọng 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 chuyện này
- Khi tình trạng công việc bị đình trệ nhiều giờ mỗi ngày tiếp diễn, tác giả đi đến kết luận rằng GitHub không còn phù hợp để được xem là một không gian làm việc nghiêm túc
Kế hoạch và phạm vi
- Điểm đến tiếp theo của Ghostty vẫn chưa được chốt; dự án đ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à loại bỏ dần sự phụ thuộc vào GitHub thay vì cắt đứt ngay một lần
- Tại URL hiện tại, dự án dự định vẫn để lại bản mirror chỉ đọc trên GitHub
- Thay đổi 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ó ảnh hưở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 được đặt vào đây
Ngữ cảnh bổ sung
- Dù thời điểm trùng với sự cố diện rộng ngày 27 tháng 4 năm 2026, kế hoạch rời GitHub đã được thảo luận 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 viết 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, tác giả có thể quay lại vào một lúc nào đó, nhưng điều kiện để quay lại phải là kết quả và cải thiện thực chất, chứ không phải lời nói hay cam kế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
Khi viết bài này tôi đã thật sự bật khóc, không hề nói quá
GitHub với tôi không chỉ là một SaaS, mà còn mang ý nghĩa lớn hơn nhiều, nên mối quan hệ đó đã trở nên sâu đậm đến mức có phần không lành mạnh
Sau vài tháng trò chuyện ngắt quãng, vài tuần gần đây chúng tôi mới bàn bạc nghiêm túc, vài ngày trước đã chốt quyết định cuối cùng, nhưng đến lúc tự tay đăng bài thì nó mới thật sự trở nên quá đỗi hiện thực
Có thể sẽ có người cười nhạo, nhưng tôi thật sự rất trân trọng GitHub và mong nó tìm lại được con đường của mình
Tôi là GitHub User 22723, nghĩ đến chuyện bây giờ số tài khoản chắc vào khoảng 180 triệu thì có thể xem như đã đi cùng nó gần từ thuở đầu
Theo cách tôi nghĩ thì GitHub chỉ có thể tốt lên nếu những người còn quan tâm vẫn ở lại và làm cho nó tốt hơn
Khi rời Heroku khoảng 6 năm trước, sau gần 10 năm dùng rất hài lòng, tôi đã không bao giờ mở lại dashboard nữa, và cuối cùng cảm thấy Salesforce thực sự đã phá hỏng nó
Nhưng với GitHub thì tôi không thể rời đi như vậy
Nó có những mặt trở nên lộn xộn khi cùng lúc trải qua agentic coding và tăng trưởng bùng nổ, nhưng chuyện này có vẻ không giống kiểu thảm họa Heroku/Salesforce
Thay vì giải thích mọi thứ bằng việc có thêm AI coding hay một Microsoft tà ác, có lẽ hợp lý hơn là quy mô và chính nền đất dưới chân các developer đã thay đổi
Tôi hy vọng nó làm đủ tốt để 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 developer hoàn toàn không hề ngốc nghếch
Cái cảm giác muốn làm việc mà cứ bị cản trở, muốn deploy phần mềm mà dịch vụ lại như thể không muốn cho làm, đặc biệt rất dễ đồng cảm
Cảm xúc này không chỉ là chuyện của GitHub, mà dường như cả web ngày nay đang trở nên cẩu thả và chất lượng thấp hơn
Quá nhiều sự cố liên miên, bug, gai góc UI, và tính năng dở dang đến mức tôi không hiểu rốt cuộc chuyện gì đang xảy ra
Cảm ơn vì đã tạo ra ergonomic software cho con người
Với người ngoài thì nó có thể trông tầm thường, nhưng với người trong cuộc lại là một món đồ chứa đựng tình cảm và ký ức tích lũy lâu năm
https://knowyourmeme.com/memes/spool-of-wire-guy
Trong đời sẽ có những thứ mình thích và yêu quý, và khi phe mà mình ủng hộ trở nên tệ đi thì buồn là điều tự nhiên
Tôi cũng sẽ không cười nhạo vì lý do đó, và còn thấy tức với những ai cười nhạo chuyện ấy
Chỉ là nói thật thì tôi không lạc quan lắm về việc GitHub sẽ tìm lại được đường đi
Việc chứng kiến GitHub sa sút ở cấp độ tổ chức thực sự khá đáng kinh ngạc
Người ta đưa ra đủ kiểu lý do như việc sáp nhập vào Microsoft, dồn nguồn lực sang Copilot, cấu trúc tổ chức, vibe coding, nhưng dù nguyên nhân là gì thì cũng khó phủ nhận đ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 được nghe góc nhìn từ bên trong, nhưng hiện giờ nó giống như một con tàu đắm vẫn trôi nhờ quán tính, và vào lúc cả ngành phần mềm đang chao đảo thì quán tính thôi có lẽ không đủ để trụ nổi
Nó đang được vận hành theo kiểu mà các dịch vụ bị công ty lớn thâu tóm thường gặp
Ban đầu vẫn ổn, rồi từ từ tệ đi, cuối cùng sụp đổ, và mọi thứ biến thành trò chơi con số
Microsoft, Oracle, VMware, CA, Salesforce đều có những ví dụ tương tự, còn những đội thực sự xử lý M&A tốt thì rất 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 xấu hơn nữa
Ngay cả trước khi bị mua lại, đã có thời GitHub giống như tung đồng xu xem hôm nay site có chạy ổn hay không
Nó thành công vì xuất hiện đúng thời điểm đúng chỗ, nhưng về bản chất vốn là một hệ thống vá víu khá lỏng lẻo từ đầu đến cuối
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 ngờ và phi đạo đức, thì có lẽ đã bớt tổn thương 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à rốt cuộc đượ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 không còn lựa chọn nào khác, nhưng chưa bao giờ gắn bó tình cảm với nó
Nó được xây trên git là free-software, nhưng việc về mặt cấu trúc luôn cố trói người dùng vào nền tảng của nó vẫn 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à đồng ý điều khoản sử dụng, lại còn không hoạt động ở Iran do luật trừng phạt của Mỹ
Vì vậy việc ghostty rời GitHub làm tôi vui mừng mà không chút lấn cấn
Ở KDE, chúng tôi hầu như chưa bao giờ nghiêm túc cân nhắc GitHub; ban đầu tự vận hành git infra của riêng 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 từ Enterprise Edition sang Community edition
Trong 16 năm qua, tôi nghĩ chỉ có đúng một lần gặp sự cố git kéo dài nhiều giờ
Chỉ cần nhìn xem nó có đáng để bỏ thời gian và tiền bạc của mình hay không
Nó có thể hao tổn cảm xúc như chuyện Netflix tăng giá hay game nọ game kia, nhưng nếu không còn giá trị thì cứ rời đi thôi
Dĩ nhiên tôi hiểu việc hình thành kết nối cảm xúc, giống như với ký ức về thời kỳ đầu của máy tính
Càng ngày tôi càng thấy việc nhúng những thứ như issue tracker vào trong git repo là hợp lý hơn
Tôi nghĩ nỗi đau kiểu này đến từ việc không nhìn thấu vấn đề của closed source software đến cùng
Từ sau khi bán Hashicorp, sự tôn trọng tôi dành cho ông ấy đã giảm đi nhiều
Trước đây tôi từng thấy trong một thread trên X nơi Mitchell chỉ trích GitHub, có nhiều reply nói GitHub nên mời anh ấy làm CEO, và tôi thấy điều đó khá có lý
Kiểu lãnh đạo có thể xoay chuyển một con tàu như thế này không thể chỉ là người quản lý đơn thuần, mà phải là người vừa có niềm tin mạnh mẽ, vừa có năng lực thực thi, vừa có sức hút nhân tài
Tôi tin cuối cùng 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 đời đầu từng làm trong thời SVN và SourceForge, nó có thể tăng trưởng rất nhanh
Có vẻ cũng đã có nhiều nỗ lực nhắm vào khoảng trống đó
Nhưng ngay cả xét theo tiêu chí dịch vụ cốt lõi, tôi vẫn thấy chưa có UI tốt nào, đặc biệt cho các dự án phức tạp
Còn jujutsu thì hướng đi cơ bản có vẻ khá tốt, nhưng vẫn chưa có forge ra hồn
Code, wiki, issue đều được quản lý phân tán gần như trong cùng một công cụ
Nếu AI thật sự thay thế việc phát triển phần mềm theo cách mà giới điều hành Big Tech mong muốn thì có lẽ hai bên sẽ lại khớp nhau, nhưng hiện tại người ta muốn một git remote ổn định, còn thực tế lại là một host chập chờn kèm thêm những 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ì nó cho phép cộng tác issue và PR dễ dàng ngay cả khi từng self-hosted forge không cần mở đăng ký tài khoản, và đ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 xuống cấp
Có lẽ khó thành hiện thực, nhưng nếu làm được thì thậ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 gần như không mở web GitHub mà dùng github cli rất nhiều
Chỉ với gh là đã làm được hầu hết việc cần làm, còn Actions thì chạy trên GitHub, agent lấy kết quả, xem issue, sửa code, nên toàn bộ workflow thực tế đã thay đổi rồi
Nếu thật sự có nhiều người đồng cảm với cảm giác GitHub không còn là nơi dễ chịu nữa, và còn cản trở họ làm việc lẫn deploy, thì Redmond phải phản ứng mạnh
Nếu cảm giác này lan rộng đáng kể, đó có thể là đòn chí mạng với Microsoft
8 năm trước họ đã bỏ gần 8 tỷ USD để đặt developer vào vị trí trụ cột, rồi chi thêm 2 tỷ USD cho Minecraft để gắn kết cả lớp developer trẻ tuổi
Họ đã mất OS và server, nếu giờ còn mất cả developer thì có thể đi theo con đường na ná Xerox của thế kỷ 21
Microsoft có thể không áp đảo, thậm chí dễ thua ở game, mobile hay 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 là đủ
Có quá nhiều người không quan tâm đến công nghệ nhưng bị Office trói chặt
Việc một trong những kỹ năng thực dụng đầu tiên Claude học rất tốt là viết file .docx cũng cho thấy điều đó
Vấn đề không nằm ở bản thân Git, mà ở lớp hạ tầng như issue, PR, Actions xây bên trên nó
Nếu được đề xuất, tôi nghĩ ngay cả khi chuyển sang forge khác thì vẫn nên dùng kèm git-bug
Nó lưu issue, PR và những thứ tương tự vào chính git dưới dạng special ref thay vì branch, đồng thời hỗ trợ đồng bộ hai chiều với nhiều nhà cung cấp khác nhau
Các VCS khác như fossil cũng lưu issue cùng với repo, và tôi nghĩ cách đó hợp lý vì issue cũng là một phần giống tài liệu, giúp đem ý nghĩa đến cho code
Khi mọi thứ đều ở trong repo thì đúng là tiện hơn
Chỉ có điều bây giờ gần như tất cả những thứ đó lại được một LLM coding agent gần như không bị ràng buộc cùng thao tác, nên khóa phạm vi truy cập trở nên khó hơn nhiều
Tôi biết phần 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 gửi được issue, cuối cùng vẫn cần hạ tầng công khai
Trong dự án của tôi, tôi dùng nó với https://github.com/stryan/materia, và nó khá tốt để tập trung hóa repo với issue
Nhưng với đầu vào ngẫu nhiên từ người dùng thì tôi vẫn dùng GitHub Discussions như một bug tracker bán chính thức
Nếu là bug thì tôi thêm vào git-bug rồi đồng bộ với GitHub issues để hiển thị công khai, nhưng cách này không thật sự phù hợp với các báo cáo bug quy mô lớn 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 bug trước qua discussion, rồi chỉ tạo issue có gắn nhãn khi nó thật sự có thể hành động đượ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 nhiều nhất cho việc chất lượng GitHub giảm mạnh
Có người giải thích là code do AI tạo ra đã làm giảm chất lượng codebase, cũng có người nói sau khi Microsoft thâu tóm thì văn hóa kỹ thuật tệ lan rộng
Có thể cả hai đều đúng ở một 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ả pha trộn giữa văn hóa và hạ tầng của Microsoft, và giờ chất lượng của nó cho cảm giác giống các dịch vụ Microsoft khác
Nói thêm thì binary dotnet CLI được host quá bất ổn, CI của tôi vỡ thường xuyên đến mức tôi phải tự re-host
Những sự cố kiểu trang Pull Request hiển thị kết quả không đầy đủ, hay dữ liệu không mất nhưng danh sách không hiện đúng cho tới khi Elasticsearch index được nạp lại xong, vẫn đang xảy ra nguyên xi
Anh ấy nói trong vài tháng tới sẽ chia sẻ cụ thể hơn nơi Ghostty sẽ chuyển sang, nhưng như vậy cũng có thể bị hiểu là để phản ứng với chuyện GitHub Issues hay PR đôi lúc không truy cập được trong ngày, lại tự tạo ra một tình trạng không truy cập được trong vài 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 thật sự thấy nó chắc chắn có lợi cho bản thân anh ấy, cho Ghostty hay cho cộng đồng
Ít nhất tôi mong anh ấy chuẩn bị sẵn đường dự phòng rồi hãy chuyển