- Trước khi GitHub trở thành hạ tầng xã hội của mã nguồn mở, các lập trình viên quản lý dự án trên hạ tầng tự vận hành như Trac riêng, kho Subversion, mailing list, v.v.; ngay cả việc thêm dependency cũng đi kèm khá nhiều ma sát và sự cân nhắc thận trọng
- GitHub đã khiến việc tạo dự án, khám phá dự án và đóng góp trở nên dễ dàng hơn một cách đột phá, đồng thời chuẩn hóa issue tracker, pull request, CI và thậm chí còn đảm nhiệm cả vai trò lưu trữ cho mã nguồn mở
- Khi kết hợp với các hệ sinh thái gói như npm, điều này đã gây ra sự bùng nổ micro dependency; GitHub trở thành trụ cột cốt lõi của hệ thống niềm tin, nhưng hiện nay niềm tin đang bị xói mòn bởi sự bất ổn, định hướng sản phẩm rối rắm và nhiễu từ AI
- Ghostty cũng rời đi, và đã xuất hiện các động thái chuyển sang Codeberg như Strudel, Tenacity, v.v.; phân tán hóa giúp tăng tính tự chủ nhưng cũng có nguy cơ làm mất đi bối cảnh xã hội như issue, review, security advisory
- Trong bối cảnh gần đây xuất hiện dấu hiệu tính trung tâm của GitHub đang suy yếu, một kho lưu trữ công cộng có thể giữ lại ký ức nhưng giảm bớt phụ thuộc trở nên quan trọng hơn. Mã nguồn mở của thời đại tiếp theo cần đi theo hướng giữ lại ký ức nhưng giảm bớt sự phụ thuộc
Môi trường mã nguồn mở trước GitHub
- Trước GitHub, số lượng dự án có thể tin cậy để phụ thuộc vào là có hạn, và danh tiếng cùng tính bền vững của từng dự án gắn trực tiếp với việc lựa chọn dependency
- Dependency không chỉ là một tên package đơn thuần mà còn kéo theo cả lịch sử dự án, website, người bảo trì, quy trình phát hành và bối cảnh cộng đồng
- Các dự án lớn thường tự vận hành hạ tầng riêng, còn dự án nhỏ thì đôi khi được đặt trên máy chủ của trường đại học hoặc trên SourceForge
- Có những ma sát như trong quy trình đóng gói Debian, nơi cả license và header bản quyền cũng được rà soát; chính những ma sát đó cũng hoạt động như một phần của việc đánh giá độ tin cậy
Nghịch lý của hạ tầng tự vận hành và hệ thống quản lý phiên bản phân tán
- Các dự án mã nguồn mở thời kỳ đầu thường chạy trên máy chủ tự vận hành Trac, Subversion, tarball, tài liệu
- Cũng có những cấu trúc như Pocoo, nơi nhiều dự án cùng chia sẻ chi phí máy chủ và gánh nặng vận hành Subversion, Trac, mailing list
- Subversion là kho lưu trữ tập trung, nên việc vận hành máy chủ gần như đi kèm một cách tự nhiên; “ngôi nhà” của dự án cũng hiện diện rất rõ ràng về mặt vật lý qua hostname, thư mục, instance Trac, kho lưu trữ mailing list
- Mercurial và Git là các hệ thống phân tán nơi ai cũng có thể sở hữu toàn bộ kho lưu trữ, branch và history, nhưng trên thực tế trọng tâm lại một lần nữa dồn về GitHub
- Sau khi hệ thống quản lý phiên bản phân tán chiến thắng, cả thế giới lại được chuẩn hóa lên một dịch vụ tập trung khổng lồ; đây vẫn là một nghịch lý lớn của mã nguồn mở hiện đại
Những thay đổi mà GitHub tạo ra
- GitHub giúp việc tạo và khám phá dự án trở nên dễ dàng, đồng thời khiến cả những người không có kinh nghiệm với mailing list phát triển cũng dễ hiểu hơn về luồng đóng góp
- Bằng việc cung cấp issue tracker, pull request, trang release, wiki, trang organization, API, webhook và sau này là cả CI, GitHub đã thay đổi mặc định của cộng tác công khai
- Cộng tác mã nguồn mở đã trở nên phổ biến theo cách diễn ra trên lịch sử hiển thị công khai và các cuộc thảo luận hiển thị công khai
- Trong một thời gian dài, GitHub đóng vai trò là lựa chọn mặc định rất hợp lý để đưa dự án mã nguồn mở lên mạng
- Cũng như chính sách cố duy trì khả năng truy cập GitHub tại các quốc gia nằm trong diện trừng phạt của Mỹ, tính tập trung hóa không chỉ vượt ra ngoài việc hosting đơn thuần mà còn đóng vai trò như một nền tảng công cộng có thể truy cập được
GitHub như một kho lưu trữ
- Một chức năng ít được chú ý hơn của GitHub là vai trò lưu trữ; ngay cả các dự án bị bỏ quên cũng vẫn có thể được tìm thấy, khiến nó hoạt động như một chỉ mục cho tài sản công cộng phần mềm
- Fork, issue cũ và lịch sử thảo luận vẫn tiếp tục tồn tại, nhờ đó sự tập trung hóa đã tạo ra ký ức có thể được khám phá
- Ngược lại, trước thời kỳ các nền tảng lớn, việc file dự án và dịch vụ biến mất cùng với việc domain cá nhân hết hạn, VPS bị ngừng hoặc lập trình viên vắng bóng là chuyện thường gặp
- Cũng có những trường hợp như các dự án đời đầu chỉ còn metadata trên PyPI nhưng package thực tế đã biến mất, nơi địa chỉ kho lưu trữ trỏ tới máy chủ cá nhân cũ rồi bị đứt gãy
- Cuối cùng, nhiều dự án trong quá khứ đã phải phụ thuộc rất lớn vào các phương tiện lưu trữ bên ngoài như Internet Archive
npm và sự bùng nổ dependency
- Vấn đề micro dependency không chỉ dừng lại ở việc có nhiều package nhỏ hơn, mà còn trở nên lớn hơn vì GitHub và npm khiến chi phí tạo, phát hành, tìm kiếm, cài đặt và phụ thuộc gần như biến mất trong cảm nhận
- Trước GitHub, độ tin cậy và tính bền vững là yếu tố bắt buộc khi chọn dependency, và vì khó tin tưởng vào tính sẵn sàng của các dịch vụ khác nên việc vendoring bằng cách đưa mã trực tiếp vào kho lưu trữ cũng khá phổ biến
- Trước thời API, việc duy trì script để lấy mã bên ngoài cũng phiền phức, và chính những ma sát đó khiến người ta phải suy nghĩ thêm một lần trước khi thêm dependency
- Trong hệ sinh thái kiểu npm, đồ thị package có thể tăng trưởng nhanh hơn tốc độ con người có thể suy luận
- Để phản ứng trước vấn đề tình trạng license trở nên không rõ ràng, GitHub cũng từng thử sửa đổi điều khoản dịch vụ
- Ngay cả khi phụ thuộc vào package nhỏ, văn hóa kiểm tra trên GitHub xem kho lưu trữ có tồn tại không, có người bảo trì không, có issue không, có thay đổi gần đây không, có dự án khác đang dùng không, mã nguồn có khớp với mô tả package không cũng đã hình thành
- GitHub trở thành một trong số rất ít hệ thống còn đảm nhận cả trusted publishing cho các registry như npm; vì thế sự suy giảm niềm tin vào GitHub tác động không chỉ đến hosting mã nguồn mà còn đến toàn bộ văn hóa chuỗi cung ứng
Sự suy yếu của GitHub và dấu hiệu dịch chuyển
- Gần đây GitHub đang dần đánh mất một phần tính tất yếu trước đây vì sự bất ổn, thay đổi sản phẩm lặp đi lặp lại, tiếng ồn AI từ Copilot và sự thiếu rõ ràng trong lãnh đạo
- Khi bị đặt giữa làn sóng agentic coding, áp lực nội bộ cũng tăng lên, nhưng hiện trạng được mô tả là cảm giác thiếu vắng vai trò lãnh đạo đang rất rõ rệt
- Trong một thời gian, việc rời GitHub gần như chỉ mang tính biểu tượng, nhưng giờ đây ngay cả các dự án có tầm ảnh hưởng lớn cũng đang công khai cân nhắc hoặc thực hiện việc chuyển đi
- Thông báo Ghostty rời GitHub được xem là một tín hiệu mạnh dù đích đến vẫn chưa thật sự rõ ràng
- Strudel moved to Codeberg
- Tenacity moved to Codeberg
- Có thể vẫn chưa đủ để tạo ra một cuộc đảo chiều xu thế, nhưng đã xuất hiện dòng chảy khiến chúng ta lại thường xuyên nhìn thấy không gian hosting bên ngoài GitHub hơn
- Vì bản thân Git vốn dĩ được thiết kế với tiền đề nhiều ngôi nhà, nên việc chấm dứt trạng thái một công ty trở thành ngôi nhà mặc định của mọi thứ có thể là điều lành mạnh cho mã nguồn mở
Cái giá của việc quay lại phân tán
- Nếu quay lại nhiều forge, nhiều máy chủ và nhiều cộng đồng nhỏ, phi tập trung hóa và tính tự chủ sẽ tăng lên, đồng thời giảm sự phụ thuộc vào thay đổi lãnh đạo từ Microsoft
- Việc mỗi cộng đồng có thể tự chọn workflow khác nhau cũng là một ưu điểm
- Vấn đề issue tracker hiện tại của Pi cho thấy các lựa chọn sản phẩm của GitHub đã dẫn tới kết quả không phù hợp với thực tế duy trì mã nguồn mở ngày nay
- GitHub bộc lộ khía cạnh được thiết kế xoay quanh engagement hơn là sức khỏe tinh thần của maintainer
- Ngược lại, nếu chuyển sang self-hosted forge, máy chủ Mercurial riêng hay máy chủ cgit, thì dù bản thân mã nguồn có được phân tán đi, bối cảnh xã hội vẫn có thể rất dễ bị phân mảnh
- Issue, review, thảo luận thiết kế, release note, thông báo bảo mật và các tarball cũ biến mất dễ hơn nhiều so với ta tưởng
- Các mailing list từng chứa đựng bối cảnh đó trong quá khứ nay không còn theo kịp yêu cầu hiện tại và trải nghiệm người dùng cũng không tốt
- Việc phần mềm bị lãng quên có thể có tác dụng thanh lọc, nhưng nếu rủi ro mất mát tăng lên thì cũng cần suy nghĩ lại về cách thực sự tận dụng hệ thống quản lý phiên bản phân tán
Điều cần thiết là một kho lưu trữ công cộng
- Dù GitHub còn ở lại hay các dự án chuyển đi nơi khác, mã nguồn mở vẫn cần một kho lưu trữ công cộng, tẻ nhạt nhưng ổn định
- Điều cần thiết không phải là một dịch vụ nhằm chiến thắng trên thị trường năng suất dành cho lập trình viên, mà là một cấu trúc giúp phần mềm quan trọng không biến mất
- Nó phải vận hành trên nền tảng có thể duy trì dài hạn, như endowment hoặc nguồn vốn công
- Kho lưu trữ mã nguồn, release artifact, metadata và bối cảnh dự án phải được bảo tồn ở nơi không bị trói buộc vào mô hình kinh doanh hay tâm trạng lãnh đạo của một công ty
- GitHub đã vô tình đảm nhiệm cả vai trò kho lưu trữ đó khi trở thành trung tâm của hoạt động mã nguồn mở, nhưng nếu tính trung tâm suy yếu thì không thể mặc định cho rằng chức năng ấy sẽ tự động được duy trì
- Chỉ dựa vào máy chủ cá nhân và thiện chí thì việc bảo tồn chưa bao giờ là đủ, và khoảng trống sau khi các nền tảng như Google Code và Bitbucket đóng cửa đã cho thấy điều đó
- Hệ thống trong tương lai cần đi theo hướng giữ lại ký ức nhưng giảm bớt phụ thuộc; việc di chuyển dự án, mirror bối cảnh xã hội và bảo tồn release phải trở nên dễ dàng hơn, để sự trôi dạt của một công ty không dễ biến thành khủng hoảng văn hóa của tất cả mọi người
- Vẫn còn đó sự căng thẳng giữa một bên là không ai muốn quay lại thời các liên kết tarball hỏng và các instance Trac bị bỏ hoang, còn bên kia là cũng không thể chấp nhận cấu trúc GitHub-trung tâm của 20 năm qua như một trạng thái bình thường vĩnh viễn
3 bình luận
Đúng là GitHub đã đóng nhiều vai trò cho đến tận bây giờ, nhưng theo ký ức của tôi thì trước đó, các dự án mã nguồn mở chủ yếu chỉ do những người thực sự làm trong lĩnh vực này tham gia, và trường hợp cá nhân tự công khai dự án của mình thì không nhiều. Thậm chí ngay trong công ty cũng có khi chỉ chia sẻ với nhau trong cùng một nhóm. Và với mã nguồn mở, việc được xem là người đóng góp cho một dự án lớn là một vinh dự rất lớn, còn những dự án nhỏ mang tính cá nhân thì hầu như chẳng mấy ai quan tâm.
Tôi nhớ rằng khởi đầu là khi bầu không khí trong cộng đồng phát triển thay đổi, phần mềm công khai được dùng như một cách để được công nhận năng lực của bản thân, rồi cuối cùng git cũng được sử dụng rộng rãi hơn so với một vài DVCS khác — nhiều yếu tố may mắn đã cùng lúc xuất hiện. Các đối thủ cạnh tranh khi đó cũng cung cấp những dịch vụ tương tự, nên theo tôi không phải vì riêng GitHub làm quá xuất sắc mà thành công như vậy.
Thực ra vấn đề là phần thảo luận issue và PR, chứ bản thân git thì lúc nào cũng có thể chuyển sang dịch vụ khác. Tôi thấy cũng có dự án đưa cả ba thứ này vào git, nên nếu dùng kiểu đó thì có lẽ có thể chuyển đi bất cứ lúc nào.
Ý kiến trên Hacker News
Việc có thể gắn ngay một kho lưu trữ vào tên của mình và tạo thật nhanh đem lại cảm giác giải phóng hơn rất nhiều so với quy trình nặng nề thời SourceForge, khi phải đặt tên dự án, giữ chỗ, rồi dựng cả kho CVS hay SVN, website, mailing list và issue tracker
Nó làm giảm rất nhiều gánh nặng tâm lý kiểu "cái này chỉ là thứ làm tạm thôi"
Cũng không phải GitHub ngay từ đầu đã cung cấp cùng lúc issue tracker, PR, trang phát hành, wiki, trang tổ chức, API, webhook và CI
Ngày xưa còn chưa có chức năng tổ chức nên đôi khi người ta tạo hẳn tài khoản người dùng mới để giả làm tổ chức, rồi vừa nghĩ "chắc GitHub vài tháng nữa sẽ ra thôi" vừa trì hoãn việc đưa vào một bug tracker riêng, để rồi cuối cùng quản lý bằng file văn bản trong kho
Với những codebase siêu lớn như Linux kernel thì Git có thể có lợi thế về hiệu năng, nhưng phần lớn dự án gần như không bao giờ chạm đến giới hạn hiệu năng của VCS
Fossil thật sự rất hữu ích ở chỗ các công cụ tích hợp như wiki, forum, ticket đều được quản lý phiên bản cùng mã nguồn trong một tệp duy nhất
Trong công việc freelance, Fossil giúp việc nắm lại ngữ cảnh dự án, chi tiết và các thỏa thuận với khách hàng trở nên rất dễ dàng
Không cần làm bừa bộn codebase, cũng không phải lục tung email và công cụ ghi chú khắp nơi để phục hồi ngữ cảnh
Tôi cũng không thích kiểu nghĩ rằng chỉ vì Git đã ăn quá sâu vào văn hóa nên không thể thay đổi
Fossil cũng dễ chuyển sang, và kể cả từ Git chuyển qua thì workflow còn đơn giản hơn
Chỉ là đa số không muốn như vậy nên chúng không có lực đẩy
Cũng có khá nhiều trường hợp việc lưu issue cùng với dự án là bất tiện
Nếu khách hàng gửi nhiều ảnh chụp màn hình hoặc video để tái hiện lỗi thì kho sẽ phình ra rất nhanh, mà nếu gắn chặt với mã nguồn thì ai cũng phải tải một kho cồng kềnh về máy chỉ để xem ticket, rất phiền
Cuối cùng rất dễ trôi sang kiểu "đừng dùng cái này, phức tạp quá và chỉ làm kho lưu trữ phình to"
Phần lớn chức năng của Fossil có vẻ vẫn có thể triển khai trên backend Git, còn wiki hay issue thì có thể để ở một lớp nhánh song song riêng
Nếu tôi nhớ không nhầm thì đến lúc Git đã ổn định và dùng hằng ngày được rồi, Fossil vẫn có lúc buộc phải tạo lại toàn bộ kho lưu trữ khi cập nhật phiên bản
UX của Git tệ hơn, và có thể bây giờ vẫn thế, nhưng dù sao nó vẫn chạy được và cho cảm giác sẵn sàng đưa vào thực chiến hơn
Thêm nữa, một trong những dự án mã nguồn mở lớn nhất thế giới đang dùng nó, nên về mặt nhận thức thì khác biệt đó là quyết định
Dù vậy, tôi nhớ là trong một thời gian dài lợi thế đó không bộc lộ rõ khi xử lý blob lớn
Khi có một dịch vụ tập trung tiện lợi trong 99% thời gian, năng lực bảo tồn của cả cộng đồng sẽ bị thoái hóa
Nếu muốn thứ gì đó tiếp tục sống thì phải có ai đó tự tay seed nó, khi ấy mọi người hẳn sẽ giữ các bản sao của những gì họ thật sự coi là quan trọng tốt hơn
Việc quá dễ dàng mặc định rằng "để sau checkout lại là được" mới là vấn đề
Không nên có chỉ một nơi duy nhất để tải thứ gì đó xuống
Nếu một dự án GitHub bị DMCA thì cả các fork cũng biến mất theo
Khi Nintendo gỡ trình giả lập Switch nổi tiếng vào năm 2024, cách duy nhất để bảo tồn và tiếp tục phát triển là đi tìm người nào còn checkout revision mới nhất rồi phục hồi từ đó
Mà chuyện đó còn chỉ khả thi vì đây là dự án cực kỳ nổi tiếng: https://news.ycombinator.com/item?id=40254602
Nhân tiện thì tôi rất thích animation header/footer mang cảm giác Splatoon của trang này
Nó không gây khó chịu, vẫn tạo được không khí, mà khi cuộn trang thì lập tức tránh ra, đến mức tôi cũng muốn bê nguyên xi về dùng
Có quá nhiều lập trình viên dường như thậm chí không biết rằng mã nguồn có thể được lưu ở nơi khác
Nếu giảm bớt các rào cản khiến thông tin khó tiếp cận thì sự tập trung quyền lực cũng sẽ giảm đi
Một trong những lý do GitHub xây dựng được niềm tin suốt nhiều năm là vì cho đến giờ họ vẫn chưa trực tiếp kiếm tiền từ vai trò lưu trữ lâu dài đó
Dĩ nhiên nhìn vào các tính năng mới liên quan đến Copilot thì tương lai thế nào còn chưa biết
Nếu phương án thay thế là chia nhỏ ra thành nhiều website thì rốt cuộc cũng chỉ là mỗi nơi một bộ quy tắc DMCA khác nhau
Điều đó khiến tôi phải hỏi lại rằng lựa chọn tốt hơn thực sự là gì
Phần lớn công việc mã nguồn mở của tôi diễn ra trên hạ tầng self-hosted, và ví dụ tiêu biểu là Xfce
Khi tôi tham gia lần đầu vào năm 2004, tôi nhớ là có một máy chủ SVN và có lẽ thêm giao diện web hỗ trợ SVN mới của CVSweb
Sau khi vào core team, hình như tôi là người thiết lập Bugzilla, dù cũng có thể là người khác
Khi Git bắt đầu trở thành xu thế, tôi dẫn dắt việc chuyển một kho SVN lớn thành nhiều kho Git và gắn thêm giao diện web cgit
Đến lúc đó vẫn còn dùng Bugzilla
Khoảng 2009~2010 tôi vào một startup nhỏ nên không còn nhiều thời gian cho OSS và rời dự án, rồi quay lại vào năm 2022 thì trong lúc đó họ đã dựng một instance GitLab cùng CI runner và cũng chuyển Bugzilla sang GitLab issue
Số người hoạt động vẫn chỉ đếm trên đầu ngón tay và việc quản trị hạ tầng gần như do một người gánh, nhưng với đội nhỏ thì vẫn hoàn toàn vận hành được
Việc hạ tầng được tài trợ là một may mắn lớn, và có lẽ chỉ với tài trợ định kỳ thôi thì khi cần họ cũng tự chi trả được
Quan trọng nhất là không phải phụ thuộc vào GitHub/Microsoft
Nếu 20 năm trước ai nói rằng Microsoft sẽ sở hữu code forge OSS lớn nhất thế giới thì chắc tôi đã muốn nôn, và giờ chuyện đó vẫn khiến tôi khó chịu
Rust dùng công cụ tên là
craterđể chạy kiểm thử trên toàn bộ các dự án Rust, và luồng làm việc ít ma sát đã giúp rất nhiều khi phải đăng thủ công hàng trăm issue để tìm các dự án phụ thuộc vào chi tiết triển khai nội bộ của CargoNếu đã có sẵn thông tin xác thực của website và còn cho phép template trống, thì việc đăng 200 issue sẽ dễ hơn rất nhiều
Ngược lại, cứ gặp instance self-hosted là thường tôi dừng lại ở đó
Khi bắt đầu một dự án mã nguồn mở mới, việc thiết lập Trac ngay từ bước đầu có mức ma sát khó tin, nhưng tôi vẫn thích nó
Django đến giờ vẫn chạy trên Trac sau hơn 20 năm: https://code.djangoproject.com/timeline
Tôi không phải người thiết lập cái đó, nhưng có thể tôi đã từng giúp dựng một Trac riêng tư còn sớm hơn thế
Dù vậy issue tracker đầu tiên của tôi là Bugzilla, thứ khá đau khổ để cài đặt và cũng không tích hợp tốt với các công cụ khác
Nhưng niềm vui khi nhìn thấy
Zarro Boogsthì khá đặc biệtHệ thống plugin của nó thật sự xuất sắc
Nó làm tốt vai trò của mình, với tôi chẳng có gì hỏng hóc đáng kể, và tôi cũng thích phía Mercurial hơn
Tôi chuyển sang vì các công ty đều dùng GitHub, nhưng đến giờ vẫn chỉ dùng GitHub như một endpoint Git hơi ì, còn build/deploy thì xử lý bằng Docker và shell script nên chi phí chuyển đi là rất thấp
Trong công việc, nếu không có quyền quyết định thì tôi nghĩ cứ dùng công cụ trả phí như thời SVN là được, miễn là được trả tiền để dùng
Khi ấy tôi cảm thấy nó cố làm quá nhiều thứ mà chẳng thứ nào thật sự xuất sắc
Có lẽ bây giờ danh hiệu đó thuộc về GitLab, và sau này chắc tôi cũng sẽ nhớ về nó một cách đẹp đẽ
Có cả chương trình của chính GitHub: https://archiveprogram.github.com/
Cũng có Software Heritage, một tổ chức phi lợi nhuận được UNESCO hỗ trợ: https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/
Tuy vậy phía này chủ yếu gần với việc bảo tồn mã nguồn và lịch sử commit, chứ chưa xử lý tốt phần metadata xung quanh như issue, PR, thảo luận hay wiki
Tôi học Python để tận dụng AppEngine, một nền tảng hosting hiện đại vừa miễn phí vừa dễ dùng, và nhờ vậy tôi ở đúng vị trí khi Flask xuất hiện
Tôi đã ngưỡng mộ Armin từ lâu, nên còn chưa bấm vào link mà chỉ nhìn domain là nhận ra ngay
Tôi cũng đồng cảm với nhận xét của anh ấy rằng thời đó lựa chọn mặc định không phải là GitHub
Cũng ấn tượng ở chỗ bài này là phản hồi cho bài của Mitchell chỉ vài giờ trước, và thật đáng ngạc nhiên khi anh ấy viết được một bài dài, chất lượng cao và mạch lạc nhanh đến vậy
Tôi vẫn chưa thể tin là Google lại đánh rơi cơ hội lớn đến thế
Trước khi dịch vụ đó đóng cửa, tôi từng ở trong đội đó