Nhìn lại kỷ nguyên trước GitHub và tương lai của mã nguồn mở

GitHub không phải là ngôi nhà đầu tiên của các dự án mã nguồn mở của tôi. SourceForge mới là nơi đầu tiên.

Trước khi GitHub xuất hiện, tôi có bản cài đặt Trac riêng. Tôi có các kho chứa Subversion, hệ thống theo dõi vé (tickets), các gói tarball và tài liệu nằm trên hạ tầng mà tôi tự kiểm soát. Sau đó, tôi chuyển các dự án sang Bitbucket, vào thời điểm mà Bitbucket vẫn cảm thấy là một sự thay thế nghiêm túc cho các dự án mã nguồn mở, đặc biệt là với những người chưa hoàn toàn "chuyển đổi" sang Git.

V rồi, cuối cùng, GitHub trở thành nơi tụ hội, và tôi chuyển tất cả mọi thứ sang đó. Rất khó để có thể nói quá tầm quan trọng của GitHub đối với cuộc đời tôi. Một phần lớn danh tính mã nguồn mở của tôi được hình thành tại đó. Các dự án tôi làm việc đã tìm thấy người dùng tại đó. Mọi người tìm thấy tôi ở đó, và tôi cũng tìm thấy những người khác ở đó. Nhiều mối quan hệ chuyên môn và nhiều tình bạn đã bắt đầu chỉ vì một kho chứa nào đó, một vấn đề (issue), một pull request hay một luồng bình luận đã khiến hai người nhận ra sự tồn tại của nhau.

Đó là lý do tại sao tôi thấy những gì đang diễn ra với GitHub ngày nay thật buồn và thật thất vọng. Tôi không nhìn nhận nó chỉ là những người tại Microsoft đưa ra các quyết định sản phẩm mà tôi không thích. GitHub đã là một phần của hạ tầng xã hội của mã nguồn mở trong một thời gian rất dài. Đối với nhiều người trong chúng ta, đó không chỉ là nơi mã nguồn sống; đó là nơi một phần lớn cộng đồng sinh sống.

Vì vậy, khi tôi nghĩ về sự suy thoái của GitHub, tôi cũng nghĩ về những gì đã tồn tại trước nó, và những gì có thể sẽ đến sau nó. Tôi đã viết vài lần trong những năm qua về các phần phụ thuộc (dependencies), và đặc biệt là vấn đề của các vi phụ thuộc (micro dependencies). Trong tâm trí tôi, GitHub đã sinh ra hiện tượng này. Đó là điều mà tôi chắc chắn không hoàn toàn ủng hộ, nhưng nó cũng làm cho mã nguồn mở bao trùm hơn. GitHub đã thay đổi cảm giác của mã nguồn mở, và sau đó npm cùng các hệ thống khác đã thay đổi cảm giác về sự phụ thuộc. Kết hợp chúng lại, bạn có được một thế giới nơi việc xuất bản mã nguồn gần như không có ma sát, tiêu thụ mã nguồn gần như không có ma sát, và số lượng dự án trên thế giới bùng nổ.

Điều này có nhiều mặt tích cực. Nhưng đáng nhớ rằng mã nguồn mở không luôn hoạt động theo cách này.

Trước GitHub, thế giới mã nguồn mở nhỏ hơn nhiều. Không hẳn là về số lượng người quan tâm đến nó, mà là về số lượng dự án mà hầu hết chúng ta có thể thực sự phụ thuộc vào.

Có những dự án nổi tiếng, được duy trì trong thời gian dài bởi một số lượng người tương đối nhỏ. Bạn biết tên họ. Bạn biết các danh sách thư (mailing lists). Bạn biết ai đã ở đó từ nhiều năm và ai đã giành được sự tin tưởng. Sự tin tưởng đó không hoàn hảo, và thế giới cũ có rất nhiều sự "giữ cửa" (gatekeeping), nhưng uy tín lại quan trọng theo một cách rất trực tiếp. Chúng tôi lấy làm tự hào (và cũng bực bội) khi nhóm Debian đến và nói rằng các vấn đề về cấp phép của chúng tôi mơ hồ hoặc các tiêu đề bản quyền không đạt chuẩn, bởi vì họ đóng gói những thứ đó.

Một phần phụ thuộc không chỉ là một tên gói. Nó là một dự án với một lịch sử, một trang web, một người bảo trì, một quy trình phát hành, rất nhiều trở ngại, và thường là một vị trí trong một cộng đồng lớn hơn. Bạn không thêm các phần phụ thuộc một cách tùy tiện, bởi vì hành động phụ thuộc vào một cái gì đó thường có nghĩa là bạn phải hiểu nó đến từ đâu. Không phải tất cả những điều này là cố ý, nhưng vì các dự án này tương đối lớn, chúng cũng cần mang theo hạ tầng của riêng mình. Các dự án nhỏ có thể chạy trên máy chủ đại học, và nhiều trong số chúng nằm trên SourceForge, nhưng những cái lớn hơn tự điều hành. Chúng nhóm lại thành các tập thể lớn hơn để làm cho nó hoạt động.

Các dự án mã nguồn mở đầu tiên của tôi sống trên hạ tầng mà tôi tự chạy. Có một bản cài đặt Trac, các kho chứa Subversion, các gói tarball, tài liệu và tệp phát hành được phục vụ từ các máy tính của riêng tôi hoặc từ các máy chủ dưới sự kiểm soát của tôi. Điều đó là bình thường. Nếu bạn muốn xuất bản phần mềm, bạn thường cũng trở thành một quản trị viên hệ thống quy mô nhỏ. Georg và tôi đã chạy tập thể của riêng mình cho các dự án mã nguồn mở của chúng tôi: Pocoo. Chúng tôi chia sẻ chi phí máy chủ và gánh nặng duy trì Subversion và Trac, danh sách thư và hơn thế nữa.

Subversion đặc biệt làm cho việc "chạy kho lưu trữ riêng" trở nên tự nhiên. Nó tập trung: bạn cần một máy chủ, và ai đó phải vận hành nó.

Dự án có một ngôi nhà, và ngôi nhà đó thường khá theo nghĩa đen: một tên máy chủ, một thư mục, một phiên bản Trac, một kho lưu trữ danh sách thư.

Khi Mercurial và Git xuất hiện, chúng về mặt triết học là đối lập. Cả hai đều phân tán. Mọi người đều có thể có toàn bộ kho chứa. Mọi người đều có thể có bản sao riêng, nhánh riêng và lịch sử riêng. Về nguyên tắc, các hệ thống kiểm soát phiên bản phân tán đó nên đã giảm nhu cầu về một trung tâm duy nhất. Nhưng mặc dù tất cả những điều đó, GitHub đã trở thành trung tâm.

Đó là một trong những sự mỉa mai lớn của mã nguồn mở hiện đại. Hệ thống kiểm soát phiên bản phân tán đã chiến thắng, và sau đó thế giới chuẩn hóa trên một dịch vụ tập trung khổng lồ để lưu trữ nó.

Bây giờ rất dễ để chỉ nói về những thất bại của GitHub, trong đó hiện nay có rất nhiều, nhưng điều đó sẽ không công bằng: GitHub đã là, và tiếp tục là một món quà tuyệt vời cho mã nguồn mở.

Nó đã làm cho việc tạo một dự án trở nên dễ dàng và làm cho việc khám phá các dự án trở nên dễ dàng. Nó đã làm cho việc đóng góp trở nên dễ hiểu với những người chưa bao giờ đăng ký một danh sách thư phát triển trong đời họ. Nó đã cung cấp cho các dự án trình theo dõi vấn đề, pull requests, trang phát hành, wiki, trang tổ chức, quyền truy cập API, webhook và sau này là CI.

Nó đã chuẩn hóa ý tưởng rằng mã nguồn mở diễn ra công khai, với lịch sử hiển thị và sự hợp tác hiển thị. Và nó là một lựa chọn mặc định tuyệt vời và hợp lý trong một thập kỷ.

Nhưng có lẽ điều bị đánh giá thấp nhất mà GitHub đã làm là công việc lưu trữ: GitHub đã trở thành một thư viện. Nó đã trở thành một chỉ mục của một phần lớn commons phần mềm vì ngay cả các dự án bị bỏ rơi vẫn có thể tìm thấy. Bạn có thể tìm thấy các nhánh (fork), và các vấn đề cũ và thảo luận vẫn giữ trực tuyến. Đối với tất cả các phàn nàn có thể đưa ra về sự tập trung, sự tập trung đó cũng đã tạo ra một bộ nhớ có thể khám phá được.

Các nhà lãnh đạo ở đó từng quan tâm rất nhiều đến việc giữ cho GitHub khả dụng ngay cả ở các quốc gia bị Mỹ trừng phạt.

Tôi biết sự thay thế trông như thế nào, vì tôi đã sống trong nó. Một số dự án mã nguồn mở sớm nhất của tôi về mặt kỹ thuật vẫn còn trên PyPI, nhưng các gói thực tế đã biến mất.

Metadata trỏ đến máy chủ cũ của tôi, và máy chủ đó đã ngừng phục vụ các tệp đó từ lâu.

Điều đó là bình thường trước các nền tảng lớn. Một tên miền cá nhân hết hạn, một VPS bị tắt, một nhà phát triển qua đời, và cùng với họ là các dịch vụ họ trả tiền. Web từng đầy những ngôi nhà phần mềm nhỏ, và nhiều trong số chúng đã biến mất.

Vấn đề vi phụ thuộc không chỉ là mọi người xuất bản các gói rất nhỏ. Hạ tầng được lưu trữ của GitHub và npm đã làm cho nó cảm thấy như thể không có chi phí để tạo, xuất bản, khám phá, cài đặt và phụ thuộc vào chúng.

Trong thế giới tiền-GitHub, uy tín và tuổi thọ là một phần của quá trình lựa chọn phụ thuộc gần như là cần thiết, và nó thường yêu cầu vendor (nhúng mã nguồn). Nhiều phần phụ thuộc sớm của chúng tôi chỉ được vendor vào các cây Subversion của chính chúng tôi theo mặc định, một phần vì chúng tôi không thể dựa vào các dịch vụ khác hoạt động khi chúng tôi cần và vì việc duy trì các tập lệnh để tìm nạp chúng, trong thời kỳ tiền-API, rất đau đớn. Sự ma sát ngầm đã buộc một số sự phản ánh, và nó dẫn đến hành vi của nhà phát triển khác. Với các hệ sinh thái kiểu npm, đồ thị gói có thể phát triển nhanh hơn khả năng lý luận của bất kỳ ai.

Vấn đề mà kiểu tư duy này tạo ra cũng có nghĩa là các giải pháp phải được tìm thấy trên đường đi. GitHub đã giúp bù đắp cho vấn đề trách nhiệm giải trình và nó đã giúp với việc cấp phép. Tại một thời điểm, sự gia nhập đột ngột của các nhà phát triển và các pull request được hợp nhất đã để lại nhiều câu hỏi mở về trạng thái thực tế của giấy phép là gì. GitHub thậm chí đã cố gắng sửa chữa điều này với các điều khoản dịch vụ của họ.

Suy nghĩ trong nhiều năm là nếu tôi sẽ phụ thuộc vào một số gói nhỏ, ít nhất tôi muốn xem kho chứa của nó. Tôi muốn xem liệu người bảo trì có tồn tại không, có vấn đề nào không, có thay đổi gần đây không, các dự án khác có sử dụng nó không, mã có phải là những gì gói tuyên bố không. GitHub đã trở thành một phần của hệ thống cung cấp sự tin tưởng, và gần đây nó thậm chí đã trở thành một trong số ít hệ thống có thể xuất bản gói lên npm và các sổ đăng ký khác với việc xuất bản đáng tin cậy.

Điều đó có nghĩa là khi sự tin tưởng vào GitHub bị xói mòn, vấn đề không bị cô lập trong việc lưu trữ mã nguồn. Nó ảnh hưởng đến toàn bộ văn hóa chuỗi cung ứng đã hình thành xung quanh nó.

GitHub hiện đang mất đi một số điều khiến nó cảm thấy không thể tránh khỏi. Có lẽ đó chỉ là sự sống và cái chết của các nền tảng tập trung lớn: chúng luôn thất vọng cuối cùng. Ngay bây giờ mọi người đang mệt mỏi vì sự bất ổn, sự thay đổi sản phẩm liên tục, tiếng ồn AI Copilot, sự lãnh đạo không rõ ràng và cảm giác rằng nền tảng không còn được thiết kế chủ yếu cho cộng đồng đã làm cho nó có giá trị.

Rõ ràng, GitHub cũng thấy mình ở giữa cuộc cách mạng lập trình tác nhân (agentic coding) và điều đó gây ra áp lực khổng lồ cho những người ở đó. Nhưng trang web không có lãnh đạo! Đó là một điều kỳ diệu mà mọi thứ đang diễn ra tốt đẹp như vậy.

Trong một thời gian, việc rời GitHub cảm thấy như một bước đi mang tính biểu tượng chủ yếu được thực hiện bởi các dự án nhỏ hơn hoặc những người có quan điểm mạnh mẽ về tự do phần mềm. Chắc chắn tôi đã "rùng mình" khi Zig chuyển sang Codeberg! Nhưng bây giờ tôi thấy những người có trọng lượng và tín hiệu thực sự đang nói về việc rời GitHub. Người rõ ràng nhất là Mitchell Hashimoto, người đã thông báo rằng Ghostty sẽ chuyển. Nó sẽ chuyển đi đâu thì chưa rõ, nhưng đó là một tín hiệu mạnh. Nhưng cũng có những người khác.

Strudel đã chuyển sang Codeberg và Tenacity cũng vậy. Chúng sẽ gây ra sự thay đổi đủ lớn không? Có lẽ không, nhưng tôi thấy mình thường xuyên hơn trên các thuộc tính không phải của GitHub so với chỉ một năm trước.

Người có thể lập luận rằng điều này là tốt: nó lành mạnh cho mã nguồn mở để ngừng giả vờ rằng một công ty nên là ngôi nhà mặc định của mọi thứ. Bản thân Git được thiết kế cho một thế giới với nhiều ngôi nhà.

Quay trở lại nhiều kho lưu trữ, nhiều máy chủ, nhiều ngôi nhà nhỏ và nhiều cộng đồng độc lập sẽ tăng sự phi tập trung hóa, và theo nhiều cách, nó sẽ buộc các hệ thống phải thích ứng. Điều này có thể khôi phục quyền tự chủ và làm cho các dự án ít phụ thuộc vào ý muốn của lãnh đạo Microsoft hơn. Nó cũng có thể cho phép các cộng đồng khác nhau chọn các quy trình làm việc khác nhau. Những gì đang xảy ra trong trình theo dõi vấn đề của Pi hiện nay phần lớn là kết quả của các lựa chọn sản phẩm của GitHub không hoạt động trong thế giới mã nguồn mở hiện nay. Nó được xây dựng để tương tác, không phải cho sự tỉnh táo của người bảo trì.

Nó cũng có thể làm cho web quên lại. Tôi khá thích phần mềm quên vì nó có một yếu tố thanh lọc.

Có lẽ rủi ro mất mát thực sự sẽ khiến chúng ta phản ánh nhiều hơn về việc thực sự tận dụng hệ thống kiểm soát phiên bản phân tán.

Nhưng nếu các dự án chuyển sang một cái gì đó giống như các kho lưu trữ tự lưu trữ (self-hosted), đến các máy chủ Mercurial hoặc cgit tự lưu trữ của riêng họ, chúng ta chạy rủi ro mất những thứ chúng ta không muốn mất. Mã nguồn có thể được phân tán trong lý thuyết, nhưng bối cảnh xã hội thường thì không. Các vấn đề, bài đánh giá, thảo luận thiết kế, ghi chú phát hành, tư vấn bảo mật và các gói tarball cũ là mong manh. Chúng biến mất dễ dàng hơn nhiều so với những gì chúng ta thừa nhận. Các danh sách thư, vốn mang lại nhiều điều này trong những năm trước, đã không bắt kịp với nhu cầu của ngày nay, và chủ yếu là một thảm họa về trải nghiệm người dùng.

Bất chấp tôi thích ý tưởng những thứ phai dần khỏi sự tồn tại, chúng ta tuyệt đối cần các thư viện và kho lưu trữ.

Bất kể GitHub có ở đây để ở hay các dự án tìm thấy những ngôi nhà mới, những gì tôi muốn thấy là một kho lưu trữ công cộng, nhàm chán, được tài trợ tốt cho phần mềm mã nguồn mở. Một cái gì đó có sức mạnh của một quỹ từ thiện hoặc tài trợ công để giữ nó nổi. Một cái gì đó mà công việc của nó không phải là giành thị trường năng suất của nhà phát triển mà chỉ để đảm bảo rằng những điều quan trọng nhất chúng ta tạo ra không biến mất.

Những cái chuông và còi (tính năng thừa thãi) có thể là vấn đề của người khác, nhưng các kho lưu trữ mã nguồn, các tạo tác phát hành, metadata và đủ bối cảnh dự án để hiểu những gì đã xảy ra nên được bảo quản ở một nơi không bị ràng buộc với mô hình kinh doanh hoặc tâm trạng lãnh đạo của một công ty duy nhất.

GitHub đã vô tình trở thành kho lưu trữ đó vì nó trở thành trung tâm của hoạt động mã nguồn mở. Một khi điều đó không còn giữ đúng, chúng ta không nên giả định rằng một chức năng lưu trữ ma thuật nào đó sẽ xuất hiện hoặc rằng GitHub sẽ tiếp tục hoạt động như vậy.

Chúng ta đã thấy điều gì sẽ xảy ra khi các ngôi nhà dự án chỉ là máy chủ cá nhân và ý định tốt, và chúng ta đã thấy điều gì đã xảy ra với Google Code và Bitbucket.

Tôi hy vọng GitHub phục hồi, tôi thực sự như vậy, một phần vì rất nhiều lịch sử sống ở đó và vì những người vẫn làm việc trên đó đã kế thừa một cái gì đó thực sự quan trọng. Nhưng tôi không còn nghĩ rằng có trách nhiệm để để bộ nhớ liên tục của mã nguồn mở phụ thuộc vào việc GitHub vẫn là một sản phẩm lành mạnh.

Thế giới trước GitHub có nhiều quyền tự chủ và nhiều mất mát hơn, và theo một số cách, chúng ta có thể sẽ quay trở lại đó, ít nhất là trong một thời gian. Bất cứ điều gì mọi người muốn bắt đầu xây dựng tiếp theo nên cố gắng giữ bộ nhớ và mất sự phụ thuộc.

Nó nên dễ dàng hơn để chuyển các dự án, dễ dàng hơn để sao gương bối cảnh xã hội của chúng, dễ dàng hơn để bảo quản các bản phát hành và khó hơn để sự trôi dạt của một công ty trở thành một cuộc khủng hoảng văn hóa cho tất cả những người khác.

Tôi không muốn quay lại web cũ của các liên kết tarball bị hỏng và các phiên bản Trac bị bỏ rơi. Tôi cũng không muốn mã nguồn mở giả vờ rằng hai mươi năm qua là bình thường hoặc vĩnh viễn. GitHub đã viết một chương đáng chú ý của mã nguồn mở, và nếu chương đó đang kết thúc, chương tiếp theo nên học hỏi từ nó và cũng từ những gì đã đến trước đây.

Đây cũng là một lời nhắc nhở tốt rằng chúng ta phụ thuộc rất nhiều vào Internet Archive cho nhiều dự án của thời điểm đó.