Những cách "ngớ ngẩn" khiến một dự án mã nguồn mở qua đời

Bài viết nổi tiếng mang tên "Weekend at Bernie’s" đã từng chỉ ra một thực tế đáng báo động: một phần lớn các gói thư viện mã nguồn mở được phụ thuộc nhiều nhất hiện nay thực tế đã "chết". Tuy nhiên, chúng vẫn được sử dụng rộng rãi như thể vẫn còn sống. Có rất nhiều cách để một dự án phần mềm rơi vào trạng thái tồi tệ này, và dưới đây là những nguyên nhân phổ biến nhất.

Người duy trì rời đi

Đây là nhóm nguyên nhân phổ biến nhất, nơi dự án mất đi người chăm sóc chính của nó.

• Người duy trì ma (Ghost maintainer): Đây là trường hợp đơn giản và phổ biến nhất. Lần commit cuối cùng của con người diễn ra vài năm trước, các issue (vấn đề) tích tụ không được giải đáp, và kho chứa (repo) không được lưu trữ (archive) nên không xuất hiện trong bất kỳ bộ lọc cảnh báo nào. Thông thường, người duy trì chỉ đơn giản chuyển sang việc khác và dự án không đủ quan trọng để họ bàn giao chính thức hoặc đóng cửa. Sự im lặng này che phủ mọi khả năng, bao gồm cả việc người duy trì đã qua đời.
• Mồ côi doanh nghiệp (Corporate orphan): Một công ty xây dựng và mã nguồn hóa dự án với một đội ngũ vận hành, nhưng sau đó việc thay đổi chiến lược hoặc sa thải khiến đội nhóm này tan rã mà không ai cập nhật README. Tổ chức GitHub vẫn tồn tại với logo công ty, nhưng những người có quyền quản trị đã rời đi. Ngay cả Google cũng có những "nghĩa trang" như vậy, chứ chưa nói đến các công ty lớn khác.
• Mồ côi luận văn (Thesis orphan): Dự án được xây dựng bởi sinh viên tốt nghiệp cho thạc sĩ hoặc tiến sĩ, và sau đó họ đã tốt nghiệp và rời đi. Phòng thí nghiệm sở hữu kho chứa nhưng không ai có đủ bối cảnh để tiếp tục, vì học thuật không khuyến khích duy trì phần mềm của người khác.
• Vách đá tài trợ (Funding cliff): Dự án vận hành nhờ một khoản tài trợ, và khi tiền cạn kiệt, người duy trì phải quay lại làm công việc khác để kiếm sống. Một dự án cần công suất toàn thời gian giờ chỉ được chăm chút vào buổi tối và cuối tuần, thực chất là không có gì.

Người duy trì vẫn ở đó

Đôi khi, dự án vẫn có hoạt động nhưng thực chất đã ngừng phát triển theo cách khác.

• Đỉnh kiệt sức (Burnout plateau): Vẫn tích cực theo mọi chỉ số, các sửa lỗi chính tả và cập nhật phụ thuộc vẫn được merge, nhưng bất kỳ quyết định thiết kế hay phiên debug thực sự nào đều nằm open mãi mãi. Người duy trì không còn đủ năng lượng cho dự án từ lâu nhưng vẫn duy trì hoạt động ở mức tối thiểu.
• Zombie nhân từ (Benevolent zombie): Biểu đồ đóng góp (contribution graph) đẹp đẽ màu xanh nhờ các bot như Dependabot. Mọi điểm số dựa trên tính mới đều đánh giá dự án này là khỏe mạnh, và đó chính là vấn đề của các điểm số này: không có con người nào thực sự đọc code.
• Kiến thức bộ lạc đã mất (Tribal knowledge gone): Code vẫn chạy và test vẫn pass, nhưng người hiểu tại sao lại như vậy đã rời đi. Không ai còn lại đủ tự tin để chạm vào các phần cốt lõi. Dự án trở thành read-only (chỉ đọc) trong thực tế.

Phá hoại và chiếm đoạt

Đây là những trường hợp nguy hiểm nhất đối với bảo mật và tính ổn định của hệ sinh thái.

• Người duy trì bị chiếm đoạt (Captured maintainer): Quyền commit hoặc publish rơi vào tay người có ác ý. Vụ xz là một ví dụ điển hình: một chiến dịch kỹ thuật xã hội kéo dài hai năm nhằm cài cắm người duy trì mới để chèn backdoor. Vụ event-stream năm 2018 cũng tương tự, khi tác giả trao gói cho một tình nguyện viên, người sau đó đã thêm mã đánh cắp ví tiền.
• Phần mềm phản kháng (Protestware): Người duy trì chính thống cố tình phá hỏng gói của mình. Các trường hợp như colors và faker bị phá hoại năm 2022, hay left-pad bị gỡ bỏ hoàn toàn năm 2016 là những ví dụ điển hình. Hiệu quả đối với下游 (người dùng cuối) là như nhau: code trong registry không còn là những gì họ nghĩ họ đang chạy.

Đường dẫn phát hành bị hỏng

Đôi khi code vẫn tốt nhưng quy trình đưa nó đến người dùng đã gặp sự cố.

• Duy trì nhưng không phát hành (Maintained-not-shipping): Phát triển vẫn diễn ra và sửa lỗi được đẩy vào git, nhưng không ai có thể cắt một bản release (phát hành). Tài khoản có quyền phát hành đã mất, hoặc mất thiết bị 2FA. Người dùng bị kẹt ở phiên bản cũ trong khi bản sửa lỗi họ cần nằm trước mắt nhưng không thể cài đặt.
• Khảo cổ học xây dựng (Build archaeology): Các bản build công khai hoạt động nhưng không ai tái tạo được nó. Quy trình build phụ thuộc vào dịch vụ CI đã bị xóa hoặc image cơ sở đã bị xóa. Để phát hành bản mới, người ta phải tái tạo lại môi trường build, một nhiệm vụ gần như bất khả thi.

Thế giới thay đổi và Bất khả kháng

• Bị mắc kẹt trên nền tảng (Platform-stranded): Dự án bị xích vào một runtime đã hết vòng đời (ví dụ: chỉ chạy Python 2) hoặc phụ thuộc vào trình biên dịch đã bị loại bỏ. Việc chuyển đổi sang phiên bản mới tốn quá nhiều công sức so với lợi ích nhận được.
• API bị rút ruột (API rug-pull): Dự án bao bọc một thứ gì đó bên ngoài mà chủ sở hữu đã thu hồi. Ví dụ điển hình là các thư viện client cho API của Twitter hay Reddit sau khi họ thay đổi chính sách năm 2023. Nhà phát triển thư viện không thể làm gì từ phía của họ.
• Bị thay thế (Superseded): Tính năng mà dự án thực hiện không còn cần thiết nữa vì ngôn ngữ lập trình đã hỗ trợ sẵn. Ví dụ các thư viện polyfill hay object-assign sau khi ES2015 ra đời. Người duy trì dừng lại một cách hợp lý, nhưng hàng trăm nghìn tệp lockfile vẫn cài đặt nó vì việc loại bỏ một dependency vẫn hoạt động không được ưu tiên.

Dự án bị chia tách

• Vùng ngoại lõi của Fork (Fork limbo): Một sự bất đồng hoặc sự ra đi của người duy trì khiến dự án bị chia cắt sang nhiều fork. Không fork nào thắng thế hoàn toàn, nên người dùng vẫn giữ phiên bản tiền chia tách trong khi sự phát triển diễn ra ở nơi khác dưới những tên gọi khác.
• Hậu quả của việc rút giấy phép (Licence rug-pull aftermath): Dự án đổi giấy phép sang loại không phải mã nguồn mở, và một fork cộng đồng tồn tại nhưng sự chấp nhận chưa hợp nhất. Ví dụ như Terraform/OpenTofu hay Redis/Valkey. Hầu hết các lockfile vẫn trỏ đến phiên bản gốc cấp phép mở cuối cùng, hiện đang trở thành một điểm cố định không ai bảo trì.

Campagin an toàn của Melbourne Metro mà tiêu đề bài viết này lấy cảm hứng kết thúc bằng lời khuyên "hãy an toàn quanh các đoàn tàu". Điều này khả thi hơn bất kỳ lời khuyên nào tôi có thể đưa ra. Dù trường hợp nào ở trên xảy ra, gói thư viện vẫn được giải quyết (resolve) như nhau, và tệp lockfile của bạn sẽ tiếp tục kéo nó qua bữa tiệc với kính râm trong suốt chừng nào chưa ai kiểm tra quá kỹ.