Các rủi ro

Có một số rủi ro và khó khăn đáng lưu ý khi áp dụng PMNM:

Gánh nặng bảo trì phần mềm có thể gia tăng. Một xem xét thận trọng về cơ sở mã nguồn của các gói cụ thể nào đó và cộng đồng có thể làm giảm nhẹ rủi ro này, khi có thể chỉ áp dụng các sản phẩm PMNM với sự hỗ trợ của nhà cung cấp tận tâm. Tư duy về một phần của các cán bộ kỹ thuật nội bộ cũng cần thay đổi – việc bảo trì không cần thiết phải giới hạn trong việc lập hồ sơ một báo cáo lỗi với một nhà cung cấp, mà đòi hỏi sự điều tra nghiên cứu và giải quyết vấn đề tích cực hơn. Tính có thể đúng và tốc độ giải quyết vấn đề sẽ còn được cải thiện nhiều hơn vì sự phụ thuộc theo lối cũ vào các tài nguyên kỹ thuật nội bộ của chỉ một nhà cung cấp sẽ không còn trở thành một sức ép nữa.

Không phải lúc nào cũng rõ ràng cách xác định và có đưọc PMNM. Tất nhiên, không phải lúc nào cũng rõ ràng cách xác định các giải pháp thay thế của phần mềm sở hữu độc quyền cái nào dễ dàng hơn cái nào, nhưng ít nhất qui trình RFI và các tài nguyên mở rộng dành cho việc marketing bởi trợ giúp của các nhà cung cấp phần mềm sở hữu độc quyền. Google và Sourceforge là các công cụ tuyệt hảo, nhưng dễ dàng bị mỏi mắt để tìm kiếm dự án ứng cử viên tốt trong khi nhồi nhét qua hàng tá các dự án không phù hợp.

Một số dự án PMNM bắt đầu như việc đào mỏ và không rõ ràng về kiến trúc. Không có đầu tư chút thời gian, nó khó có được sự hợp lý của một dự án được đưa ra. Kích cỡ của đội phát triển lõi không phải là một chỉ số tin cậy, rất tiếc là như vậy.

Các dự án PMNM có thể đánh mất xung lượng/sự quan tâm của các nhà lập trình phát triển, hoặc đâm đầu vào các bức tường kiến trúc (ban đầu từ chỗ thiếu một thiết kế thực thụ trong các phiên bản đầu). Các hệ thống ghép lỏng lẻo có thể bao gồm các dịch vụ mà chúng có tưong lai mù mịt hoặc đơn giản là sẽ biến mất, ảnh hưởng tới toàn bộ hệ thống.

Các tiêu chuẩn công nghiệp có thể là không mở (như các định dạng của Microsoft Word) nên có những rủi ro ngược lại về mặt kỹ thuật với mọi PMNM phụ thuộc vào các tiêu chuẩn đó. Ưu tiên của Bộ Tư pháp đối với các tiêu chuẩn mở (như định dạng tài liệu mở ODF, mà nó hiện nay được hỗ trợ bởi ngay cả Microsoft) làm giảm rủi ro này.

Tổng kết các lợi ích

The benefits of OSS can be summarised as follows:

Lợi ích của PMNM có thể được tổng kết như sau:

1. Tiết kiệm chi phí (khi xem xét tới toàn bộ chi phí, không chỉ chi phí mua)

2. Chất lượng được cải thiện – không cần trả tiền cho những lần thử nghiệm và các quyết định về chức năng có thể được đưa ra cho tới cuối qui trình phát triển mà không cần xem xét những hậu quả về giấy phép.

3. Tránh việc khoá trói vào nhà cung cấp (việc mua, tuỳ biến, các sản phẩm phụ thuộc bổ sung, các sản phẩm bị bỏ rơi) – SOA là một phần thiết yếu của sự tự do này, PMNM là một phần khác.

4. Sửa lỗi nhanh hơn, không triển khai theo một lịch trình của nhà cung cấp

5. Việc đưa ra nhánh chính (việc tích hợp đối nghịch với việc xây dựng đối với các tính năng tuỳ biến) là khả thi, vì thế sẽ có ít rủi ro hơn đối với việc bị đơn côi với một phiên bản tuỳ biến mà nó không thể được hỗ trợ một cách thích hợp.

6. Những thay đổi về phát triển một cách nhanh lẹ không cần đàm phán lại với nhà cung cấp và cho phép các yêu cầu mới đáp ứng được nhanh hơn (như việc tạo ra một phiên toà mới).

7. Giảm rủi ro việc bị bỏ rơi bởi các hệ thống sở hữu độc quyền (vì sự tan rã của công ty hoặc không tiếp tục của sản phẩm).

8. Không còn 'sự tù mù về an ninh' – mà là an ninh thông qua sự xem xét của cộng đồng

9. Phân nhỏ của N-1 hành động (mã nguồn được chuyển đi khi đã xong hơn là khi các bản vá sẽ được tung ra).

10. Sử dụng lại các mã nguồn – vừa giảm được mã nguồn đặt trước của Bộ (Tư pháp) và sự thúc đẩy mã nguồn của PMNM đang tồn tại.

PMNM từng là một cách khác thường về suy nghĩ, bị hạn chế trong các dự án hàn lầm và du kích nhỏ trong cộng đồng các hackers. Tuy nhiên, dần dần, nó là tiêu chuẩn.

Dịch tài liệu: Lê Trung Nghĩa