Kho phần mềm mã nguồn mở khổng lồ và gần như thứ gì cũng có sẵn miễn phí. Nhưng phần lớn dự án chết yểu — bị bỏ rơi sau vài tháng hào hứng ban đầu. Đưa một công cụ vào quy trình làm việc là một cam kết dài hạn, nên trước khi cài, hãy dành mười phút trả lời năm câu sau. Chúng rẻ để hỏi và đắt để bỏ qua.
1. Lần cập nhật gần nhất cách đây bao lâu
Một dự án im lặng hai năm không hẳn đã chết — có thể nó đã hoàn thiện và không cần sửa gì thêm, điều hoàn toàn hợp lý với một công cụ nhỏ làm đúng một việc. Nhưng nếu kho vẫn còn hàng trăm báo lỗi mở và không ai trả lời, im lặng đó nghĩa là bị bỏ rơi. Phân biệt hai trường hợp bằng cách nhìn phản hồi, không chỉ nhìn ngày commit.
2. Có bao nhiêu người thực sự đóng góp
Dự án một người viết là rủi ro lớn nhất trong mã nguồn mở. Người đó đổi việc, mất hứng, có con nhỏ, hoặc đơn giản là bận — và dự án dừng lại đúng lúc bạn phụ thuộc vào nó nhất. Nhìn danh sách người đóng góp: nếu 95% thay đổi đến từ một tài khoản duy nhất, hãy chuẩn bị tinh thần rằng một ngày nào đó bạn sẽ phải tự bảo trì hoặc tự tìm đường thoát.
3. Giấy phép có hợp với mục đích của bạn không
- MIT, BSD, Apache — thoải mái, dùng được cả trong sản phẩm đóng, gần như không ràng buộc.
- GPL — nếu bạn phân phối một sản phẩm có chứa nó, sản phẩm của bạn cũng phải mở mã.
- AGPL — chặt hơn nữa: chạy nó trên máy chủ phục vụ người khác qua mạng cũng bị tính như phân phối, nên phần mềm dịch vụ của bạn cũng phải mở.
Dùng cho cá nhân thì hầu như không có khác biệt. Dùng trong công ty thì đây là câu hỏi bắt buộc, và trả lời sai có thể thành rắc rối pháp lý đắt đỏ về sau.
4. Dữ liệu của bạn có lấy ra được không
Đây là câu hỏi quan trọng nhất mà ít người hỏi nhất. Phần mềm lưu dữ liệu ở định dạng mở hay trong một cơ sở dữ liệu độc quyền chỉ nó đọc được? Có chức năng xuất đầy đủ không, hay chỉ xuất được bản rút gọn? Nếu ngày mai bạn muốn rời đi — vì dự án chết, vì nhu cầu đổi — bạn mang theo được gì? Mã nguồn mở bảo vệ bạn khỏi việc nhà cung cấp biến mất, nhưng không tự động bảo vệ bạn khỏi việc dữ liệu bị nhốt trong một định dạng khó đọc.
5. Cộng đồng phản ứng thế nào với lỗ hổng bảo mật
Tìm thử lịch sử các bản vá bảo mật của dự án. Một dự án nghiêm túc có quy trình báo lỗi riêng, kín đáo, và vá trong vài ngày. Một dự án lỏng lẻo thì lỗ hổng nằm phơi trong báo lỗi công khai hàng tháng trời trước khi ai đó để ý — nghĩa là suốt thời gian đó, ai đọc cũng biết cách tấn công bạn.
Quy tắc thực dụng
Không phải dự án nào cũng cần vượt qua cả năm câu. Cân mức khắt khe theo mức độ quan trọng: một tiện ích dòng lệnh nhỏ chạy trên máy bạn thì lỏng tay được. Nhưng càng đưa dữ liệu quan trọng vào, hoặc càng đặt nó ở vị trí mà cả hệ thống phụ thuộc, thì bốn câu đầu càng phải trả lời rõ ràng trước khi cài, chứ không phải sau khi đã lún sâu.
Thảo luận