- Gần đây, đã xuất hiện chỉ trích về việc sử dụng phần mềm mã nguồn mở do một lập trình viên người Nga tạo ra
- Trên thực tế, phần lớn tuyệt đại đa số các dự án mã nguồn mở đều đang được vận hành bởi chỉ một cá nhân bảo trì duy nhất
- Không chỉ NPM mà cả nhiều hệ sinh thái khác cũng có rất nhiều trường hợp các gói phổ biến được quản lý bởi một người bảo trì duy nhất
- Vấn đề của cấu trúc này là gánh nặng quá mức đặt lên một người bảo trì và rủi ro chuỗi cung ứng
- Bản chất của vấn đề không nằm ở quốc tịch, mà ở sự thiếu hụt tài nguyên và hỗ trợ trong thực tế
Mở đầu: mã nguồn mở và tranh cãi gần đây
- The Register đã đăng một bài viết đặt vấn đề về sự phụ thuộc của Bộ Quốc phòng Mỹ vào một tiện ích mã nguồn mở do một lập trình viên người Nga tạo ra
- Nhà phát triển mã nguồn mở đó đang ở trong tình huống bị chỉ trích một cách oan uổng
- Nội dung bài viết đã hiểu sai thực tế của mã nguồn mở, và chỉ ra giới hạn của cách tiếp cận như vậy
Thực tế của mã nguồn mở: cấu trúc 'một người'
- Theo dữ liệu, gần như hầu hết các dự án mã nguồn mở đều do một người quản lý
- Dự án ecosyste.ms hiện đang thống kê dữ liệu của khoảng 11,8 triệu dự án mã nguồn mở
- Trong số đó, khoảng 7 triệu dự án có một người bảo trì duy nhất
- Khoảng 4 triệu dự án còn lại không rõ số lượng người bảo trì, nhưng nhiều khả năng phần lớn cũng chỉ có một người
- Chỉ một số rất ít dự án mới có hàng trăm người bảo trì
Ngay cả dự án phổ biến cũng không ngoại lệ
- Nhiều người nghĩ rằng "mã nguồn mở quan trọng hoặc dự án phổ biến sẽ do nhiều người cùng quản lý", nhưng trên thực tế các hệ sinh thái lớn như NPM cũng không khác
- Trong hệ sinh thái NPM có hơn 4 triệu dự án do một người bảo trì duy nhất
- Ngay cả trong số các gói NPM được tải xuống hơn 1 triệu lần mỗi tháng, khoảng một nửa vẫn do một người bảo trì vận hành
- Nếu nâng số lượt tải lên 1 tỷ thì có một số khác biệt, nhưng vẫn còn các gói chỉ có 1 người bảo trì
- Số người thực sự đang vận hành 4 triệu dự án một người bảo trì trong NPM là khoảng 900.000 người (tức là một người chịu trách nhiệm cho nhiều dự án)
Bản chất của vấn đề: không phải quốc gia mà là thiếu tài nguyên
- Quy mô kinh tế của mã nguồn mở là một nền tảng trị giá hàng nghìn tỷ đô la (theo nghiên cứu của Harvard, 8,8 nghìn tỷ đô la)
- Phần lớn các dự án một người bảo trì thiếu tài nguyên, và tồn tại rủi ro chuỗi cung ứng
- Rủi ro lớn nhất không phải là quốc gia, mà là 'một người bảo trì' đang làm việc quá sức và không được đền bù xứng đáng
- Việc truyền thông hay các bên khác nhắm mục tiêu vào người bảo trì cá nhân không phải là giải pháp
Kết luận và các điểm hành động
- Nguyên nhân của vấn đề hiện nay nằm ở cấu trúc một người bảo trì, còn việc tập trung vào quốc gia là vô nghĩa
- Việc biến người bảo trì cá nhân thành quỷ dữ hoặc tìm cách truy lùng họ không phải là giải pháp
- Đây là một vấn đề phức tạp nên chưa có lời giải ngay lập tức
- Thay vì chỉ đích danh và chỉ trích người bảo trì đơn lẻ, cần suy nghĩ về vấn đề mang tính cấu trúc và các phương án hỗ trợ
1 bình luận
Ý kiến trên Hacker News
Có cảm giác trong cộng đồng phần mềm có khá nhiều hiểu lầm về vấn đề này; thực ra rủi ro chuỗi cung ứng theo tôi không hẳn là vấn đề phần mềm hay kỹ thuật mà là vấn đề quản trị.
Ngay cả khi không ai có ác ý, một dự án vẫn có thể phát sinh rủi ro chuỗi cung ứng, và mỗi người đánh giá rủi ro chuỗi cung ứng lại có góc nhìn và tiêu chí bảo mật khác nhau.
DoD (Bộ Quốc phòng Mỹ) nhìn rủi ro theo một góc độ hoàn toàn khác với lập trình viên thông thường, và nhiều dự án một người trở thành rủi ro chỉ đơn giản vì chỉ có một người phụ trách.
Khi “bus factor” là 1 thì bản thân điều đó đã là rủi ro chuỗi cung ứng.
Đa số mọi người khi chọn package không nghĩ xa đến tình huống chiến tranh, nhưng quân đội thì có thể phải tính đến điều đó.
Khi chiến tranh nổ ra, ngay cả các dự án mã nguồn mở vốn thường được vận hành tự chủ cũng có thể đột ngột thay đổi tình hình.
Trên thực tế, nhiều quốc gia trong thời chiến có thể yêu cầu doanh nghiệp tư nhân hoặc dự án cá nhân hợp tác theo luật, nên có những nơi (như DoD) tính luôn cả những chuyện này vào rủi ro bảo mật.
Họ sẽ không vận hành theo kiểu “giá mà có thêm một người nữa mà chúng ta cũng chẳng hề tin tưởng” trong bối cảnh chiến tranh.
Có dữ liệu nói rằng NPM có 4 triệu dự án một người và khoảng 900.000 người đang quản lý các dự án đó; tôi tự hỏi đó có thực sự là điểm quan trọng không.
Tức là phần lớn giá trị kinh tế của mã nguồn mở (Harvard ước tính là 8,8 nghìn tỷ USD) được tạo ra bởi các “dự án một người”, và không ai trong số họ thực sự nhận được nguồn lực hỗ trợ đúng mức.
Trong câu chuyện rủi ro chuỗi cung ứng, thứ thực sự nguy hiểm là những maintainer đơn lẻ bị trả công thấp và làm việc quá tải.
Người đó đến từ quốc gia nào thật ra tôi thấy không quan trọng lắm.
Tôi tò mò không biết có thống kê nào về việc chuyện gì xảy ra khi một maintainer đơn lẻ đột ngột gặp tai nạn hoặc bỏ dự án không.
Với từng ấy dữ liệu thì có vẻ rất đáng để nghiên cứu.
Tôi muốn biết liệu có lập trình viên mới tiếp quản dự án, nó được thay thế bằng dự án khác tương tự, hay biến mất hoàn toàn.
Trên thực tế, chuyện xảy ra còn thường là “người quản lý mất hứng hoặc không còn thời gian nên buông tay” hơn là bị xe buýt tông.
Những kịch bản hay gặp lúc đó là
Điểm mạnh của mã nguồn mở là kể cả khi người tạo ra biến mất, trở nên kỳ quặc hoặc đổi license, vẫn có ai đó fork để duy trì tiếp.
Ngược lại, với phần mềm thương mại thì dù người tạo là công ty hay cá nhân, một khi họ biến mất hoặc thay đổi nội dung thì coi như hết.
Cùng lắm là phải đi tìm sản phẩm thay thế.
Cũng là lý do tôi không điều hành Netflix.
Cuối cùng vẫn là vấn đề phụ thuộc vào số lượng người dùng, độ phức tạp của codebase và việc có hay không có giải pháp thay thế.
Đó là một câu chuyện còn kỳ lạ hơn nhiều so với việc chỉ đơn giản là “bị xe buýt tông”, và cuối cùng dự án đó biến mất.
Ngay cả với các dự án có từ hai người quản lý trở lên, trong thực tế phần lớn commit rốt cuộc vẫn do một người đảm nhận.
Link liên quan: https://github.com/11ty/eleventy/graphs/contributors
Chỉ cần kiểm tra mức độ hoạt động thôi cũng đã thấy ngay một nửa số dự án hoàn toàn không có maintainer nào, thật đáng tiếc.
Nghĩa là cứ để đó cũng được, không cần dọn dẹp, tinh chỉnh hay hiệu chỉnh gì thêm.
Nhiều khi vấn đề lại nằm ở update, chứ không phải ở bản thân dự án.
Việc DoD dùng node còn khiến tôi lo hơn.
Tôi có cảm giác bất an rằng nền tảng như npm có bề mặt tấn công quá lớn.
DoD là một trong những tổ chức lớn nhất thế giới, nên họ cũng có nhiều công việc kiểu gửi newsletter hay trang web đặt lịch tham quan doanh trại Hướng đạo sinh.
Với những thứ như vậy thì dùng node cũng chẳng sao.
Những hệ thống đó vận hành tách biệt với các hệ thống quan trọng kiểu phóng tên lửa, và kể cả trang đăng ký sự kiện có bị phá thì cũng không thành vấn đề lớn.
Tôi nghĩ rất nhiều dự án GitHub một người thực ra chỉ là thử nghiệm cá nhân hoặc trò đùa kiểu “hello world”.
Tôi không biết npm thế nào, nhưng trên PyPI cũng đầy ví dụ tương tự.
Tôi vừa tự bấm vào ‘browse projects’ thì ra cái này: https://pypi.org/project/helloworld-eduardo/
Thật lòng mà nói thì dù có say cỡ nào cũng chẳng ai nghĩ đến việc dùng thứ này trong sản phẩm đâu.
DoD cực kỳ giỏi trong việc nếu thấy có thể lấy thứ gì đó miễn phí thì sẽ thuyết phục mọi người rằng “ai cũng được lợi”, rồi cuối cùng lại giao việc cho nhà thầu bên ngoài có trả tiền.
Có đoạn nói về “package có hơn 1 tỷ lượt tải xuống nhưng chỉ có một người quản lý”, tôi tự hỏi điều đó thực sự muốn nói lên điều gì.
Tôi đã nghe khá nhiều điều hay ho về những gì một người tên Linus tạo ra, và chắc là cũng đã dùng rất nhiều.
Ông ấy đến từ một nước giáp biên giới với Nga, nên tôi cũng tự hỏi liệu mình có nên để tâm đến kiểu chuyện đó không.
Tôi đã phát triển mã nguồn mở hàng chục năm, hầu như toàn làm một mình hoặc thỉnh thoảng lập một nhóm tình nguyện.
Ai từng làm việc với đội tình nguyện sẽ hiểu chuyện đó thực sự không hề dễ.
Tất nhiên không phải là bất khả thi, nhưng nó không trơn tru và phổ biến như chúng ta tưởng.
Khi nó vận hành tốt thì thường là có một “BDFL (nhà độc tài nhân từ)” hoặc mọi người cùng di chuyển theo một mục tiêu chung.
Trường hợp của tôi hầu như luôn là dạng thứ hai.
Bố ông ấy cũng từng sống ở Moscow vài năm.