- Phụ thuộc mã nguồn mở không chỉ là chọn một package, mà còn là việc xem xét cả uy tín và tính bền vững của dự án cùng cách nó được bảo trì
- Dù hệ thống quản lý phiên bản phân tán đã trở nên phổ biến, trung tâm cộng tác thực tế lại tập trung trở lại vào GitHub, và điều này trở thành một nghịch lý lớn của mã nguồn mở hiện đại
- Với các tính năng như issue tracker, pull request và trang phát hành, GitHub đã thay đổi mặc định của cộng tác công khai, đồng thời giúp việc khám phá dự án và luồng đóng góp trở nên dễ dàng hơn rất nhiều
- Đồng thời, GitHub còn đóng vai trò như một kho lưu trữ, giữ lại cả những repository bị bỏ hoang lẫn lịch sử thảo luận, qua đó níu giữ ký ức về các tài sản phần mềm dùng chung vốn rất dễ biến mất
- Trong bối cảnh gần đây xuất hiện dấu hiệu cho thấy tính trung tâm của GitHub đang suy yếu, mã nguồn mở ngày càng cần một kho lưu trữ công cộng có thể bảo tồn ký ức và giảm phụ thuộc bất kể mô hình kinh doanh của một công ty nào
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 bị giới hạn, và uy tín 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à tên package, mà còn đi kèm 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ì có khi được đặt trên máy chủ đại học hoặc SourceForge
- Có những ma sát như trong quy trình đóng gói Debian, nơi cả giấy phép lẫn header bản quyền đều được xem xét, và chính những ma sát đó cũng vận hành như một phần của quá trình đánh giá độ tin cậy
Vận hành hạ tầng riêng và nghịch lý của 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 những máy chủ tự vận hành Trac, Subversion, tarball và tài liệu
- Cũng có những mô hình 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 và mailing list
- Vì Subversion là kho lưu trữ tập trung, việc vận hành máy chủ đi kèm gần như tự nhiên, và “ngôi nhà” của dự án hiện diện rất rõ về mặt vật lý qua hostname, thư mục, instance Trac hay kho lưu trữ mailing list
- Mercurial và Git là hệ thống phân tán nơi ai cũng có thể giữ toàn bộ repository, branch và lịch sử, nhưng trung tâm thực tế cuối cùng lại tụ về GitHub
- Sau khi hệ thống quản lý phiên bản phân tán giành thắng lợi, cả thế giới lại được chuẩn hóa quanh một dịch vụ tập trung khổng lồ, và đó vẫn là một nghịch lý lớn của mã nguồn mở hiện đại
Những thay đổi do GitHub tạo ra
- GitHub giúp việc tạo và khám phá dự án trở nên dễ dàng hơn, đồng thời khiến luồng đóng góp dễ hiểu hơn ngay cả với những người chưa từng có trải nghiệm với mailing list dành cho phát triển
- Bằng việc cung cấp issue tracker, pull request, trang phát hành, 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ở dần trở nên phổ biến theo cách diễn ra trên nề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 hoạt động như lựa chọn mặc định rất hợp lý để đưa dự án mã nguồn mở lên
- Những chính sách như nỗ lực duy trì khả năng truy cập GitHub tại các quốc gia bị Hoa Kỳ trừng phạt cho thấy sự tập trung hóa này không chỉ là hosting, mà còn đóng vai trò như một nền tảng công cộng có thể tiếp cận đượ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ỏ mặc vẫn còn có thể được tìm thấy, khiến GitHub hoạt động như một chỉ mục của các tài sản phần mềm dùng chung
- Việc các fork, issue cũ và lịch sử thảo luận tiếp tục được giữ lại đồng nghĩa với việc 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 các nền tảng lớn, chuyện 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 dừng hoạt động hay lập trình viên rời đi là điều rất phổ biến
- Với những trường hợp như các dự án thời kỳ đầu trên PyPI chỉ còn metadata nhưng package thực tế đã biến mất, địa chỉ repository thường trỏ đến máy chủ cá nhân cũ rồi cuối cùng bị đứt
- Nhiều dự án trong quá khứ rốt cuộc phải phụ thuộc lớn vào những phương tiện bảo tồn 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ó quá nhiều package nhỏ, mà còn trầm trọng 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 có vẻ như gần bằng không
- 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 vào độ 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 repository cũng rất phổ biến
- Trước thời API, việc duy trì các script để kéo mã từ bên ngoài cũng phiền phức, và chính những ma sát như vậy buộc người ta phải cân nhắc thêm một lần trước khi thêm dependency
- Trong hệ sinh thái kiểu npm, đồ thị package có thể phình ra nhanh hơn nhiều so với tốc độ con người có thể suy luận
- Để ứng phó với vấn đề tình trạng giấy phép ngày càng mơ hồ, 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ỏ, một văn hóa kiểm tra trên GitHub vẫn hình thành: repository có tồn tại không, có người bảo trì không, issue ra sao, thay đổi gần đây thế nào, dự án khác có dùng không, và mã có khớp với mô tả package hay không
- GitHub cũng trở thành một trong số rất ít hệ thống đảm nhận cả trusted publishing cho các registry như npm, nên sự suy giảm niềm tin vào GitHub sẽ ảnh hưởng không chỉ đến nơi host mã nguồn mà còn đến toàn bộ văn hóa chuỗi cung ứng
Dấu hiệu GitHub suy yếu và dịch chuyển
- Gần đây GitHub đang mất đi một phần tính tất yếu trước kia vì sự bất ổn, thay đổi sản phẩm liên tục, tiếng ồn từ Copilot AI và vai trò lãnh đạo thiếu rõ ràng
- Khi bị đặt vào chính 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 lãnh đạo đặc biệ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 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ực sự rõ ràng
- Strudel moved to Codeberg
- Tenacity moved to Codeberg
- Có thể điều này vẫn chưa đủ để tạo ra một cú xoay chuyển xu thế, nhưng đã xuất hiện một dòng chảy khiến người ta lại thường xuyên nhìn thấy nhiều không gian hosting ngoài GitHub hơn
- Vì bản thân Git ngay từ đầu đã được thiết kế với giả định có nhiều ngôi nhà, nên việc chấm dứt tình trạng 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ở
Chi phí của việc quay lại phân tán
- Nếu quay về nhiều forge, nhiều máy chủ và nhiều cộng đồng nhỏ hơn, phi tập trung và quyền tự chủ sẽ tăng lên, đồng thời giảm phụ thuộc vào thay đổi lãnh đạo từ Microsoft
- Một lợi điểm khác là mỗi cộng đồng có thể chọn workflow riêng của mình
- 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 có thể dẫn tới kết quả không phù hợp với thực tế bảo trì mã nguồn mở ngày nay
- GitHub cho thấy những khía cạnh được thiết kế thiên về engagement hơn là sức khỏe tinh thần của người bảo trì
- Mặt khác, 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 phân tán, bối cảnh xã hội lại rất dễ bị phân mảnh
- Issue, review, thảo luận thiết kế, ghi chú phát hành, 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 tưởng tượng
- Các mailing list từng lưu giữ bối cảnh kiểu này trong quá khứ nay không còn theo kịp nhu cầu hiện tại, và trải nghiệm người dùng cũng không tốt
- Bản chất dễ bị lãng quên của phần mềm có thể có tác dụng thanh lọc, nhưng nếu rủi ro mất mát tăng quá cao thì cũng cần suy nghĩ lại về cách thực sự sử dụng các 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, nhàm chán nhưng ổn định
- Điều cần thiết không phải là một dịch vụ để thắng trong thị trường năng suất dành cho lập trình viên, mà là một cấu trúc bảo đảm phần mềm quan trọng không biến mất
- Nó phải vận hành trên một nền tảng có thể duy trì dài hạn, như endowment hoặc nguồn tài trợ công
- Kho lưu trữ mã nguồn, artifact phát hành, metadata và bối cảnh dự án phải được bảo tồn ở nơi không bị ràng buộc bởi mô hình kinh doanh hay tâm trạng lãnh đạo của một công ty
- GitHub vô tình kiêm luôn vai trò lưu trữ đó khi trở thành trung tâm 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ỉ máy chủ cá nhân và thiện chí thôi đã từng không đủ cho việc bảo tồn, và khoảng trống sau khi Google Code cùng Bitbucket đóng nền tảng đã cho thấy rõ điều đó
- Hệ thống trong tương lai cần đi theo hướng bảo tồn ký ức và giảm phụ thuộc, để việc di chuyển dự án, mirror bối cảnh xã hội và lưu giữ bản phát hành trở nên dễ dàng hơn, đồng thời khiến sự chao đảo của một công ty khó 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 những liên kết tarball hỏng và các instance Trac bị bỏ hoang, và bên kia là cũng không thể chấp nhận cấu trúc xoay quanh GitHub của 20 năm qua như một trạng thái bình thường vĩnh viễn
1 bình luận
Ý 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 đó