- Kể từ sau khi được Microsoft mua lại, độ sẵn sàng hoạt động (uptime) của GitHub đã giảm sút rõ rệt; ngay cả trang trạng thái chính thức cũng cho thấy những con số đáng lo, còn trang trạng thái không chính thức phản ánh tình hình còn nghiêm trọng hơn
- Việc lạm dụng Copilot và làn sóng mã chất lượng thấp do AI tạo ra (slop) đang khiến GitHub tự DDoS chính mình, trong khi bot và nền kinh tế sao giả làm xói mòn niềm tin vào nền tảng
- Git là một hệ thống quản lý phiên bản phân tán mã nguồn mở và vẫn hoạt động không cần GitHub, vì vậy cần thoát khỏi nhận thức đồng nhất GitHub với chính Git
- Có nhiều forge Git thay thế như Codeberg, Tangled, Gitea, GitLab, Forgejo tự host, và cần bắt đầu việc di chuyển ngay lập tức
- Nhiều nhà phát triển tên tuổi liên tiếp đăng bài tuyên bố rời GitHub, khiến việc thoát phụ thuộc vào GitHub trở thành bài toán của toàn bộ hệ sinh thái
Vì sao nên rời GitHub
- GitHub bị chỉ trích là đã suy giảm về tỷ lệ hoạt động và trải nghiệm sử dụng kể từ sau khi được Microsoft mua lại; người viết cho rằng trang trạng thái bị thiếu cho thấy xu hướng còn tệ hơn cả số liệu uptime chính thức
- Biểu đồ GitHub’s Historic Uptime được dùng như tư liệu cho thấy mức uptime trung bình theo tháng đã trở nên bất ổn kể từ sau thương vụ Microsoft mua lại
- Sau khi mua GitHub, Microsoft đã mở rộng dòng sản phẩm liên quan đến Copilot, và GitHub hiện bị “slop” hành hạ đến mức phải tự đăng cập nhật về các vấn đề độ sẵn sàng
- Gần đây liên tiếp xuất hiện các bài viết về việc rời GitHub hoặc nhìn lại cách phát triển phần mềm trước thời GitHub
Git ≠ GitHub
- Dù GitHub đã trở thành từ gần như đồng nghĩa với “quản lý mã nguồn”, quá nhiều người dùng vẫn không biết rằng Git không phải là GitHub
- Git và GitHub không phải là một; công nghệ cốt lõi của Git là mã nguồn mở và có tính phân tán, nên mọi kho đều bình đẳng và có thể hoạt động không cần dịch vụ tập trung
- Dịch vụ tập trung là sản phẩm của sự tiện lợi về mặt xã hội; GitHub ban đầu chỉ là một công cụ bổ sung hữu ích, nhưng Microsoft đã biến nó thành một khoản nợ đắt đỏ
- Hiệu ứng mạng rất mạnh, nhưng nền kinh tế sao giả của GitHub là vô giá trị, và nền tảng này đang tràn ngập bot cùng slop
- GitHub Actions là một phần của các pipeline CI quá mức phức tạp. Tìm giải pháp khác có thể phiền toái, nhưng cần tự hỏi liệu có thể tin vào độ ổn định của GitHub hay không
- Con tàu đang chìm, nên dù không chuyển mọi thứ trong một lần, vẫn phải bắt đầu quá trình di chuyển ngay lập tức
Các lựa chọn thay thế và cách di chuyển
- Lối thoát gần nhất là chuyển sang một forge Git tập trung khác; chỉ cần đăng ký rồi push kho lưu trữ sang upstream mới
- Một số dịch vụ có thể tự động hóa việc migration và hỗ trợ nhập issue, nhưng cũng có thể chọn giữ nguyên issue trên GitHub
- Không lựa chọn thay thế nào dưới đây là hoàn hảo; điểm chung duy nhất của chúng là không phải GitHub
-
Các lựa chọn thay thế cho forge Git tập trung
- Codeberg — dự án phi lợi nhuận do cộng đồng dẫn dắt, là một lựa chọn thay thế an toàn với hồ sơ đã được kiểm chứng. Đây là instance tiêu biểu của Forgejo
- Tangled — startup đang ở giai đoạn alpha; tích hợp với AT protocol là một lựa chọn thú vị. Đáng cân nhắc cho các dự án cá nhân nhỏ
- Gitea — cung cấp dịch vụ hosting Git managed trên cloud, đồng thời là dự án mã nguồn mở gốc mà Codeberg/Forgejo đã tách ra từ đó
- GitLab — cấp độ enterprise nên nặng và khá rối, nhưng có thể phù hợp với việc ra quyết định trong tổ chức
- Bitbucket — không được khuyến nghị, nhưng vẫn thuộc nhóm “không phải GitHub”
- Game of Trees, Radicle, Sourcehut — các lựa chọn bổ sung, cần tự tìm hiểu thêm
-
Tự host
- Cách cộng tác là một vấn đề riêng, nhưng nếu Linux vẫn có thể được duy trì bằng cách trao đổi patch qua mailing list email, thì khó có thể kết luận rằng điều đó là bất khả thi chỉ vì quy mô
- Forge Git tập trung có thể là một sự thỏa hiệp thực tế, nhưng luôn phải có kế hoạch thoát ra vì chúng cũng có thể sụp đổ như GitHub
1 bình luận
Ý kiến trên Hacker News
Mọi người đều muốn đổ lỗi việc này cho thương vụ Microsoft mua lại hoặc sự bất tài, nhưng nếu nhìn vào dữ liệu GitHub công bố thì có vẻ khá rõ là do AI khiến lượng mã được commit lên GitHub tăng gấp 10 lần, và hệ quả của nó lan ra toàn bộ CI, Actions, thu thập mã, v.v.
Tác giả lại xem những yếu tố kỳ quặc như MS Copilot là nguyên nhân, nhưng cảm giác giống đang liệt kê những thứ mình ghét hơn là chỉ ra quan hệ nhân quả
Trong khi đó lại phớt lờ vụ bùng nổ mã do AI tạo ra, tức “con voi trong phòng”
OpenAI ra mắt GPT-3.5 vào tháng 11 năm 2022, thực tế gần như là tháng 12, còn kiểu lập trình bằng mô hình ngôn ngữ lớn/agent như mô tả thì phải tới 2024 mới thực sự tăng mạnh, và thực tế còn gần 2025 hơn
Vậy thì giải thích thế nào về tình trạng khả dụng tệ trong khoảng 4 năm sau khi bị mua lại, trước cả khi người ta bắt đầu nói nhiều về AI?
Chỉ trích Microsoft thì cũng được, nhưng không nên bỏ qua con voi trong phòng
Dù ngày mai có xuất hiện một sản phẩm thay thế GitHub hoàn hảo đi nữa, thì điều gì sẽ ngăn hàng triệu dòng mã do AI tạo ra làm hỏng hạ tầng ở đó?
Có vẻ như dịch vụ lưu trữ mã tập trung sẽ gần như chết vì AI. Khá giống những gì đang xảy ra với mạng xã hội
10 năm là khoảng thời gian dài, và kết quả đang lộ ra
GitHub Actions, Copilot, rồi cả tính năng tìm kiếm AI xấu xí không thể tắt. Cả việc chuyển sang Azure nữa
Microsoft đã thành công trong việc phá hỏng hiệu ứng mạng lưới, và các sự cố chỉ là giọt nước tràn ly
Họ có những codebase khổng lồ của riêng mình và khoảng 200.000 nhân viên
Nhất là khi họ đã cố ý đưa ra các quyết định như miễn phí kho riêng tư, nên khó mà xem đây là lời bào chữa được
Mỗi lần GitHub sập tôi lại nghĩ “chắc ai đó vừa cập nhật Windows Server chạy GH nên phải reboot toàn bộ”
Tôi tin chắc 99% là không phải vậy, nhưng nghĩ như thế thấy dễ chịu hơn và mỗi lần có sự cố cũng buồn cười đôi chút
Hôm nay tôi định xem một repository trên GitHub
Tôi bấm vào liên kết “xxx commits” để xem lịch sử commit thì bị báo dính secondary rate limit nên phải đợi
Trên mạng này chỉ có mình tôi xem GitHub, và kết nối cũng là IP riêng chứ không phải CGN
Sau đó trang sẽ tải bình thường
Thực tế nhiều năm nay nó gần như là chặn mặc định chứ không phải rate limit, nhưng họ từ chối sửa câu chữ cho khớp với thực tế
“GitLab - cấp độ enterprise nghĩa là cồng kềnh và rối rắm nhưng trông ấn tượng với sếp. Nếu cần họp nhiều lần mới chọn được thì hãy chọn cái này.”
Buồn cười thật
Ngay cả việc đơn giản nhất mà UI cũng quá phức tạp. Ví dụ muốn duyệt MR thì về cơ bản phải bấm vào một cái nút kiểu menu, phần diff thì khó đọc, còn ‘To-do list’ lại chứa cả những MR đã merge rồi. Sao cái đó lại được tính là việc cần làm?
Vấn đề MR đã merge vẫn còn nằm trong ‘To-do list’ đã được báo từ nhiều năm trước mà có vẻ cải thiện rất chậm
Ngược lại, phản ứng tiêu cực với Bitbucket làm tôi hơi ngạc nhiên. UI của nó rất đơn giản và rõ ràng, người mới vào cũng thấy vậy. Dùng Script Runner thì làm được khá nhiều thứ ấn tượng, và nó xử lý repository lớn cũng tốt
GitLab không hề cồng kềnh hay rối rắm hơn GitHub một cách đặc biệt
Cũng khó mà xem nó là phần mềm cấp doanh nghiệp thực thụ. Nếu muốn kiểu đó thì cứ nhìn Jira hoặc bất kỳ thứ gì Microsoft làm
Chúng tôi dùng GitLab tự host, và tôi chọn nó vì có git lẫn container registry
Nếu không thường xuyên dùng web UI thì giao diện đúng là có thể gây rối
Với 5 USD một tháng, bạn có thể host một server và đưa lên đó nhiều project
Repository sẽ không có cả triệu sao, nhưng với nhu cầu của tôi thì chạy tốt và cũng có thể cấp quyền truy cập cho ai tôi muốn
Tôi không rõ nên đọc biểu đồ đó thế nào
Một mặt, có thể tính khả dụng đã tệ hơn vì GitHub bị mua lại
Mặt khác, việc trước khi bị mua lại mà khả dụng hiện 100,00% lại khá đáng ngờ, nên có lẽ chỉ là từ lúc đó trang trạng thái bắt đầu được cập nhật tốt hơn mà thôi
Tôi biết gần đây GitHub có vấn đề về khả dụng, nhưng vấn đề trên biểu đồ có vẻ bắt đầu từ 2020 và không giống như đã xấu đi quá mạnh
Cứ có cảm giác các repository mã nguồn mở lớn rồi cuối cùng cũng không thể để yên được
Tôi còn nhớ hồi SourceForge xuống dốc, nên nhìn cảnh tương tự xảy ra với GitHub thật sự rất đáng buồn
Nhân tiện, tôi đọc URL đó thành “dBus hell”. Chắc ai cũng từng trải qua rồi
Tôi hay nghĩ nếu mình điều hành một công ty thì sẽ làm thế nào
Tôi thật sự muốn thử làm toàn bộ code review qua email
Repository chỉ cần là một server VPS đơn giản chỉ cho truy cập git qua SSH, có namespace nhánh
for-review/cho mã cần review, còn CI thì có thể làm bằng bot chờ nhánh xuất hiện rồi gắn nhận xét hoặc tag vào ref để đánh dấu pass/fail. Kết quả cũng có thể trả lời lại trong thread emailVới mailing list thì tất nhiên chỉ cần gắn thêm web archive viewer để xem các review cũ. Loại giải pháp này đã có nhiều rồi, chỉ là HTML thôi
Chat thì dùng IRC và cho bot lưu log kênh là được. Quá dễ
Toàn bộ hệ thống, trừ runner CI cần phần cứng mạnh hơn, đều có thể chạy trên server rất rẻ
GitHub được thiết kế vượt xa những gì cần thiết để vận hành một dự án phần mềm. Nhìn Linux kernel đi, họ dùng mailing list đơn giản mà vẫn là một trong những dự án phần mềm thành công nhất lịch sử, chuyện đó gần như không cần tranh cãi
Chỉ có issue/bug tracking là đáng ngại hơn. Vì tôi sợ nếu tự mày mò làm giải pháp thì sẽ sa đà vào đó hơn cả công việc chính của công ty. Hay là cuối cùng lại biến thành công ty làm phần mềm theo dõi lỗi?
Tức là tôi muốn xem comment đã gắn chính xác vào dòng nào, dòng đó thay đổi khi nào, rồi chuyển qua lại theo ngữ cảnh
Email có thể đủ để làm giao thức trao đổi dữ liệu này, nhưng tôi không nghĩ email client là cách hay để hiển thị nó
Có lẽ ta còn cần cả một hệ thống code review phân tán
Sống ở Đông Âu cũng có lợi thế
Nhờ múi giờ nên tôi hầu như không nhận ra các sự cố GitHub lớn
Tôi cũng hài lòng với việc họ cung cấp hosting miễn phí và Actions khá hào phóng
Từ khi cài Forgejo trên server ở nhà, tôi chưa từng nhìn lại
Vấn đề duy nhất là khi host ứng dụng trên DigitalOcean App Platform hay Vercel, vì chúng chỉ kết nối với GitHub
DigitalOcean App Platformhỗ trợ triển khai không chỉ từ GitHub mà cả GitLabTuy nhiên bạn phải dùng instance GitLab được host trên gitlab.com chứ không phải instance GitLab tự host
Nếu bạn đã triển khai forge tự host rồi, có thể dùng gitlab.com làm cầu nối để kết nối với DigitalOcean App Platform. Chỉ cần tạo tài khoản gitlab.com một lần, rồi để forge tự host đẩy bản sao lên gitlab.com là được. Thực ra gần như không cần dùng GitLab
Dù vậy thì chuyện DigitalOcean là công ty bán IaaS/PaaS mà lại không cho kết nối với thứ như Forgejo tự host chạy ngay trên hạ tầng của họ vẫn rất vô lý
Thực ra nhiều người muốn host forge riêng nhưng ít người muốn tự cấu hình và vận hành, nên cũng lạ là DigitalOcean không mang Forgejo hoặc giải pháp thay thế vào, cung cấp tuỳ chọn triển khai gần như được quản lý dạng one-click với giá ưu đãi lớn kiểu 20 USD/năm, rồi hỗ trợ kết nối App Platform như tính năng hạng nhất
Tôi có dùng DigitalOcean, nhưng chỉ dùng VPS
Đừng bị khóa vào nhà cung cấp ở tầng trung gian như vậy; hãy giữ quyền kiểm soát và nhắm tới các tầng stack càng phổ quát càng tốt
Tôi đã chuyển sang Gitea từ vài năm trước, trước cả đợt fork thành Forgejo, và không hề hối tiếc
Khi cần GitHub, tôi vẫn có thể mirror repository sang đó để mọi thứ hoạt động. Chỉ là việc đồng bộ mã hơi phiền
GitHub đang chật vật vì lập trình được tăng cường bởi AI đã khiến số commit tăng gấp 14 lần trong năm qua, và tốc độ đó vẫn còn đang tăng
Site đang rất khó theo kịp
COO của GitHub xác nhận tại đây: https://x.com/kdaigle/status/2040164759836778878
Hoạt động trên nền tảng đang bùng nổ. Năm 2025 từng có 1 tỷ commit, còn giờ là 275 triệu mỗi tuần, tức nếu tăng trưởng chỉ giữ tuyến tính thôi thì năm nay cũng đang ở nhịp 14 tỷ. Tất nhiên có lẽ sẽ không dừng ở tuyến tính
GitHub Actions đã tăng từ 500 triệu phút mỗi tuần vào năm 2023 lên 1 tỷ phút mỗi tuần vào năm 2025, và riêng tuần này đến giờ đã là 2,1 tỷ phút
Vì thế họ đang dốc toàn lực để có thêm CPU, mở rộng dịch vụ và tăng cường các chức năng cốt lõi của GitHub