Tài liệu tranh luận về nguồn mở của Bộ Tư pháp New Zealand (Phần 4)

Ministry of Justice Open Source Discussion Paper

Bài được đưa lên Internet ngày: 11/12/2007

Barry Polley, MoJ A&S, barry.polley@justice.govt.nz

Lời người dịch: Tài liệu này cho chúng ta một cách nhìn thực dụng hơn trong vấn đề ứng dụng và khai thác các phần mềm nguồn mở trong chính phủ. Bên cạnh đó, nó cũng sẽ giúp những người ra các quyết định, chính sách có liên quan tới phần mềm nguồn mở những tiếp cận mà các nước phát triển đi trước đã tổng kết. Điều này là rất cần thiết đối với việc ứng dụng và phát triển phần mềm nguồn mở tại Việt Nam hiện nay.

Risks

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.

There are a number of risks and obstacles worth noting when adopting OSS:

Software maintenance burden may increase. A thoughtful review of particular packages' codebase and community can mitigate this risk, as can adopting only OSS products with dedicated vendor support. The mindset on the part of internal technical staff needs to change too - maintenance is not necessarily limited to filing a bug report with one vendor, but entails more active investigation and problem resolution. The likelihood and speed of problem resolution will still be much improved because the old dependency on a single vendor's in-house engineering resources will no longer be a constraint.

It's not always obvious how to identify and obtain OSS. Of course, it's not always obvious how to identify proprietary software al-ternatives easily either, but at least the RFI process and extensive resources devoted to marketing by proprietary software vendors help. Google and Sourceforge are wonderful tools, but it's easy to overlook a good candidate project whilst wading through dozens of unsuitable ones.

Some OSS projects started as hacks and are architecturally unsound. Without some time investment, it's hard to gauge the soundness of a given project. Size of the core development team is not a reliable indicator, unfortunately.

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.

OSS projects can lose momentum/developer interest, or hit architectural brick walls (primarily f-rom lack of an actual design in early versions). Loosely-coupled systems might include services that have poor uptimes or simply disappear, affecting the whole system.

Industry standards may not be open (e.g., Microsoft Word file formats) so there are reverse-engineering risks with any OSS dependent upon those standards. The MoJ preference for open standards (e.g., Open Document Format, which is now supported even by Microsoft) lessens this risk.

Summary of Benefits

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.

1) Cost savings (when considering full costing, not just acquisition costs)

2) Improved QA - no need to pay for suitable test instances, and functionality decisions can be deferred until late in the development process without need to consider licence consequences

3) Avoiding vendor lock-in (purchase, customisation, ancillary products, orphaning) - SOA is an essential part of this freedom, OSS is another

4) Quicker fixes, not implemented on a vendor's schedule

5) Main branch backporting (integration as opposed to building for custom features) is feasible, therefore there is less risk of being orphaned with a custom version that can't be supported properly

6) Agile deployment changes do not need renegotiation with vendors and allow new demands to be met more quickly (e.g., creation of a new tribunal)

7) Decreasing the risk of being stranded by proprietary systems (via company dissolution or product discontinuation)

8) No more 'security through obscurity' - rather, security through community review

9) Breakdown of N-1 practice (code ships when ready rather than when patchsets are issued)

10) Code reuse - both reduction of Ministry bespoke code and leverage of existing OSS code

OSS was once an extraordinary way of thinking, limited to academia and small guerilla projects in a community of hackers. Increasingly, however, it's the norm.

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