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

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.

Appendix: Open Source Policies for MoJ

Phụ lục: Chính sách về PMNM của Bộ Tư pháp

Policy 1: Open standards

Chính sách 1: Các tiêu chuẩn mở

Hãy chọn các phần mềm mà chúng triển khai các tiêu chuẩn mở ở bất kỳ nơi nào có thể. PMNM có lẽ là đúng hơn để triển khai các tiêu chuẩn mở hơn các phần mềm sở hữu độc quyền, tạo thuận lợi cho tính tương hợp và truyền dữ liệu bên trong và bên ngoài các kho dữ liệu của ứng dụng. Nhưng việc đánh giá phải được làm trên cơ sở từng trường hợp một, vì một số phần mềm sở hữu độc quyền hỗ trợ tuyệt vời cho các tiêu chuẩn mở và có thể đáp ứng được các nhu cầu của Bộ (Tư pháp) tốt hơn là một sản phẩm PMNM tương ứng.

Choose software that implements open standards whe-rever possible. OSS is more likely to implement open standards than proprietary software, facilitating interoperability and data transfer in and out of application data stores. But evaluation must be on a case-by-case basis, as some proprietary software has excellent support of open standards and might meet Ministry needs better than a comparable OSS product.

Policy 2: Prefer OSS

Chính sách 2: Ưu tiên PMNM hơn

Khi đánh giá các phần mềm như một phần của một giải pháp kỹ thuật, việc ưu tiên hơn sẽ được đưa ra cho các giải pháp thay thế của PMNM so với các giải pháp sở hữu độc quyền tương ứng. PMNM nâng cao được tính mềm dẻo trong triển khai, cung cấp mã nguồn nhiều hơn, cho phép thay đổi nhanh hơn, và cho phép tính mềm dẻo trong dàn xếp hỗ trợ. Nói chung, PMNM tránh được các rủi ro có liên quan tới sự khoá trói vào nhà cung cấp, và làm giảm một cách to lớn giá thành áp dụng. Chính sách này KHÔNG chèn lấn lên chính sách của Bộ (Tư pháp) về việc sử dụng lại trước khi mua/xây dựng; các ứng dụng hiện hành phải không bị hạn chế đơn giản vì chúng không có các thành phần PMNM. (Việc bỏ qua các giải pháp PMNM là một dạng không hợp lý, nhưng việc thay thế các hệ thống đang làm việc vì chúng không được xây dựng với PMNM cũng là không hợp lý).

When evaluating software as part of a technical solution, preference is to be given to OSS al-ternatives over comparable proprietary solutions. OSS increases deployment flexibility, provides for more robust code, allows faster changes, and permits flexibility of support arrangements. Put generally, OSS avoids the risks associated with vendor lock-in, and greatly lowers the cost of adoption (though not to zero; see below). This policy does NOT override the Ministry's policy of reuse before buy/build; existing applications should not be eliminated simply because they do not include OSS components. (Ignoring OSS al-ternatives is a form of irrationality, but replacing working systems because they aren't built with OSS is equally irrational.)

Policy 3: Review licences

Chính sách 3: Xem xét các giấy phép

Khi xem xét một sản phẩm PMNM, các điều khoản của giấy phép phải được xác định và xem xét một cách rõ ràng. Các thoả thuận về giấy phép với các nhà cung cấp phần mềm sở hữu độc quyền và tất cả các hợp đồng dịch vụ đều là đối tượng để xem xét và thông qua. Gánh nặng này là ít hơn nhiều với PMNM (vì việc tải về ban đầu và đánh giá xảy ra không có việc chi tiền cho bất kỳ ai) nhưng chúng ta cần thu thập và quản lý các yêu cầu về giấy phép một cách cụ thể cho từng sản phẩm PMNM trước khi triển khai sản phẩm sao cho mọi sức ép về việc cấp phép để sử dụng và phân phối là được biết trước. Một cách đơn giản để tuân thủ với chính sách này và giảm thiểu các rủi ro có liên quan với các điều khoản của giấy phép là yêu cầu Bộ Tư pháp áp dụng chỉ các PMNM nào sử dụng một trong các giấy phép đã được tin cậy một cách rộng rãi: http://www.opensource.org/licenses/alphabetical

When considering an OSS product, the licence terms should be identified and reviewed explicitly. Licence agreements with proprietary software vendors and all service contracts are already subject to review and approval. This burden is much less with OSS (as initial download and evaluation incur no payment to anyone) but we need to collect and manage specific licence requirements for every OSS product before production deployment so any licencing constraints on use and distribution are known upfront. A simple way to comply with this policy and reduce risks associated with licence terms is to require that MoJ adopt only OSS using one of the widely-trusted licences: http://www.opensource.org/licenses/alphabetical

Policy 4: Formal OSS evaluation

Chính sách 4: Đánh giá PMNM một cách chính thức

Khi đánh giá một sản phẩm PMNM, hãy cam kết các phương sách cho việc đánh giá một cách chính thức. Vì PMNM có giá thành là không có gì để đánh giá và áp dụng, sẽ không có dòng đầu tư sẵn sàng nào để trả tiền cho các trình bày demo của các kỹ sư bán hàng, các đánh giá của các phòng thí nghiệm độc lập, hoặc tạo ra những câu trả lời RFP. Vì thế việc áp dụng PMNM sinh ra một chi phí nhỏ trước đó, không phải trong chi phí giấy phép mà trong các cam kết về thời gian của bộ phận cán bộ kỹ thuật để quyết định trong những khả năng có thể của PMNM dựa trên các giá trị kỹ thuật. Giá thành này phải được hiểu và được quản lý. Việc đánh giá phải xảy ra trong 2 pha: một danh sách ngắn gọn các tiêu chí không thể đàm phán được có thể làm giảm số lượng các lựa chọn để xem xét, sau đó một qui trình của quyết định chính thức có thể xếp thứ tự các thứ còn lại. Qui trình chính thức này có thể là một ma trận so sánh đơn giản dựa trên một nửa trong hàng tá các yêu cầu mang tính sống còn; không cần thiết đưa vào mọi tiêu chí thích hợp. Nếu không có PMNM nào được đưa ra là phù hợp, thì việc mua các phần mềm sở hữu độc quyền theo truyền thống có thể được kêu gọi, việc sử dụng giải pháp PMNM tốt nhất như một điểm chuẩn.

When evaluating an OSS product, commit resources to formal evaluation. Because OSS costs nothing to evaluate and adopt, there is no funding stream available to pay for sales engineers' demos, independent laboratory evaluations, or generating RFP responses. Therefore adoption of OSS incurs a small upfront cost, not in licence fees but in time commitments by technical staff to deciding amongt OSS possibilities based on technical merits. This cost must be acknowledged and managed. Evaluation should occur in two phases: a short list of non-negotiatible criteria can reduce the number of options to consider, then a following formal decision process can rank the remainder. The formal process can be a simple comparison matrix based on half a dozen critical requirements; it does not need to include every relevant criterion. If no OSS offering is found to be adequate, traditional proprietary software procurement may be called for, using the best OSS solution as a benchmark.

Policy 5: Version

Chính sách 5: Phiên bản

Áp dụng hầu hết các phiên bản hiện hành của bất kỳ sản phẩm PMNM nào, và chỉ áp dụng một phiên bản nhỏ hơn 1.0 nếu thực tế hiển nhiên về tính ổn định có tồn tại. Các phiên bản PMNM có xu hướng một cách thường xuyên, được dẫn dắt bởi các nhu cầu cảm nhận được trong cộng đồng người sử dụng hơn là một lịch trình ra phiên bản tuỳ tiện. Các giai đoạn cho phiên bản beta thường là dài và được tuân theo một cách rộng rãi, nên các phiên bản hiện hành hầu hết là ổn định và đầy đủ tính năng; mã nguồn không được kiểm tra hoặc không đáng tin cậy thường xuất hiện trong 'không chính thức' của riêng nó, mà nó dễ dàng tránh xa được. Chính sách N-1 thông thường (như không đưa ra một phiên bản chính thức của phần mềm cho tới khi phiên bản chính tiếp theo sẽ có) là một sự giả tạo của phần mềm sở hữu độc quyền trong một thị trường cạnh tranh về tính năng mà nó đặt giá trị ít lên tính ổn định và không áp dụng được cho PMNM.

Adopt most current versions of any OSS product, and adopt a release lesser than 1.0 only if substantial evidence of stability exists. OSS releases tend to be frequent, driven by perceived needs in the user community rather than an arbitrary release calendar. Beta periods are typically long and widely followed, so current versions are the most stable and feature-complete; untested or untrustworthy code usually appears in its own 'edge' version, which is easily avoided. The typical N-1 policy (i.e., don't roll out a major release of software until the subsequent major release happens) is an artifact of proprietary software in a feature- competitive marketplace that placed little value on stability, and does not apply to OSS.

Policy 6: Active development

Chính sách 6: Phát triển tích cực

Từ chối áp dụng bất kỳ sản phẩm PMNM nào mà nó không có bằng cớ rõ ràng về CẢ công việc phát triển hiện hành VÀ hỗ trợ của cộng đồng. Một ưu điểm đáng kể của PMNM là tránh sự khoá trói bởi các nhà cung cấp và khả năng bị bỏ rơi, nhưng ưu thế này bị giảm bớt rất nhiều khi mà các khách hàng bị khoá trói vào PMNM mà nó thực sự đã chết, không có cộng đồng để cải tiến nó và giữ cho nó tương thích với những thay đổi trong các hệ điều hành, an ninh, .v.v.

Reject adoption of any OSS product that does not have clear evidence of BOTH current development work AND community support. One substantial advantage of OSS is avoiding lock-in by vendors and possible orphaning, but this advantage is greatly diminished when customers are locked in to OSS that is essentially dead, without a community to enhance it and keep it compatible with changes in operating systems, security, etc.

Policy 7: Commercial support

Chính sách 7: Hỗ trợ thương mại

Áp dụng các sản phẩm PMNM mà chúng có các lựa chọn hỗ trợ thương mại có sẵn. Hỗ trợ tuyệt vời có thể sẵn sàng từ các công ty nội địa hoặc từ các công ty chuyên biệt vận hành xuyên biên giới quốc tế. Các công ty tư vấn như EDS, KPMG, .v.v. có thể đem lại các kinh nghiệm triển khai và đào tạo trao tay khi cần. Kinh nghiệm quốc tế nâng cao trong việc hỗ trợ và cải tiến từng sản phẩm PMNM được áp dụng bởi Bộ (Tư pháp) có lẽ sẽ không thực thi, và có thể là ít quan trọng hơn việc nâng cao tri thức về nghiệp vụ mà nó hỗ trợ.

Adopt OSS products that have commercial support options available. Excellent support may be available f-rom local firms or f-rom specialised firms operating across international borders. Consulting firms such as EDS, KPMG, et al. may bring implementation expertise and hands-on training as needed. Growing internal expertise in the support and enhancement of every OSS product adopted by the Ministry is not likely to be feasible, and would be less important that improving knowledge of the business it supports.

Policy 8: Enterprise architecture

Chính sách 8: Kiến trúc nghiệp vụ

Sử dụng kiến trúc nghiệp vụ để hướng dẫn qui trình lựa chọn một sản phẩm PMNM. Kiến trúc nghiệp vụ ép các giải pháp mà chúng được xem xét cho các ứng dụng mang tính chiến lược, và cũng hướng dẫn các giải pháp mang tính chiến thuật. Các sản phẩm PMNM phải được đánh giá về tính tuân thủ kiến trúc nghiệp vụ chính xách hệt như GIÁ THÀNH hoặc các giải pháp được đặt hàng. Việc lựa chọn sản phẩm phải đưa ra ưu tiên đối với các công nghệ xuất hiện trong nền tảng Ứng dụng Nghiệp vụ vì các lý do hỗ trợ và phát triển (như POJO theo Tomcat khi đối nghịch với các công nghệ thuần tuý của perl), hay như các công nghệ sẽ là dễ dàng hơn trong việc hỗ trợ nội bộ ngày nay và trong tương lai. PMNM mà ít tuân thủ hơn với kiến trúc nghiệp vụ có thể cũng sẽ còn được áp dụng, nhưng chỉ được áp dụng nếu giải pháp đó đưa ra những ưu tiên thuyết phục hơn các giải pháp khác, và nếu nó có thể được duy trì như một dự án hộp đen bởi một nhà cung cấp bên ngoài.

Use the EA to guide the process of se-lecting an OSS product. The EA does constrain the solutions that are considered for strategic applications, and guides tactical solutions as well. OSS products should be evaluated for EA conformance exactly the same as COTS or bespoke solutions are. Product se-lection should give preference to technologies appearing in the Business Applications platform for support and deployment reasons (e.g., POJO under Tomcat as opposed to pure perl technologies), as such technologies will be easier to support in-house today and moving forward. OSS that is less compliant with the EA can still be adopted, but only if the solution offers compelling advantages over al-ternatives, and if it can be maintained as a black- box project by an external vendor.

Policy 9: Release Code Changes (Integrate, Don't Build)

Chính sách 9: Các thay đổi mã nguồn của phiên bản (Tích hợp, Không Xây dựng)

Cho phép cả các nhà lập trình phát triển nội bộ và bên thứ 3 triển khai và đưa ra những thay đổi mã nguồn cho cộng đồng. Các nhà lập trình phát triển được trả tiền để phân phối chức năng sử dụng cho Bộ (Tư pháp), không phải để cung cấp các cải tiến ngẫu nhiên vì lợi ích của cộng đồng theo nghĩa rộng. Tuy nhiên, không có lý do để giữ bí mật những thay đổi về mã nguồn, khi mà mã nguồn là những tư liệu không bí mật. (Dữ liệu, tất nhiên, cần được đảm bảo an ninh phù hợp với thực tế vận hành tốt, các luật về tính riêng tư, .v.v. và không thể bị lộ). Ngoài việc sử dụng đơn giản các PMNM cho việc đóng góp mã nguồn ngược trở lại cho dự án sẽ làm giảm rủi ro của các thay đổi đang được cách ly với phiên bản trụ cột. Nó cũng hoàn toàn bỏ qua những vấn đề có thể với việc tuân thủ GPL. Thẳng thắn mà nói: sẽ dễ dàng hơn khi hỏi và nhận trợ giúp TỪ cộng đồng khi bạn cũng tặng ngược lại CHO cộng đồng.

Allow both internal and third-party developers to implement and release code changes back to the community. Developers are paid to deliver functionality of use to the Ministry, not to provide random enhancements for the benefit of the community at large. However, there is no reason to keep code changes secret, as the code is not confidential material. (Data, of course, need to be secured in accord with good operational practices, privacy laws, etc. and cannot be disclosed.) Going beyond simple use of OSS to contributing code back to the project decreases the risk of changes being isolated f-rom the trunk release. It also completely bypasses possible issues with GPL compliance. And put bluntly: it's easier to ask for and receive help F-ROM the community when you also donate back TO the community.

Policy 10: Documentation

Chính sách 10: Tài liệu

Chỉ áp dụng PMNM mà có nỗ lực về tài liệu kỹ thuật đang lưu hành có liên quan tới chúng. Nhiều lợi ích của PMNM được phác thảo trong tài liệu này tích luỹ từ việc có được truy cập đơn giản tới nguồn, nhưng nếu nguồn đó là không khó hiểu, những lợi ích đó được giảm thiểu nhiều. Các tài liệu kỹ thuật chất lượng kém hoặc quá hạn làm cho việc sửa lỗi và cải tiến bị khó khăn. Rất ít các thành viên của cộng đồng PMNM có cảm hứng viết tài liệu kỹ thuật một cách tuyệt hảo, vì thế sự hiện diện của nó cũng là một dấu hiệu của một cộng đồng phát triển mạnh mẽ. Tài liệu cho người sử dụng thì ít tính sống còn hơn, đặc biệt đối với các sản phẩm hạ tầng; các nhà công nghệ quá quen thuộc với các tài liệu không thoả đáng từ những kinh nghiệm của họ với các phần mềm sở hữu độc quyền (nơi mà tài liệu thường là một ý nghĩ nảy ra muộn màng và không tạo ra doanh số).

Adopt only OSS that have an ongoing technical documentation effort associated with them. Many of the OSS benefits outlined in this paper accrue f-rom simply having access to source, but if that source is incomprehensible, those benefits are much reduced. Poor or out-of-date technical documentation makes fixes and enhancements difficult. Very few OSS community members are inspired by writing excellent technical documentation, so its presence is also a sign of a vibrant developer community. User documentation is less critical, especially for infrastructure products; technologists are quite used to inadequate documentation f-rom their experiences with proprietary software (whe-re documentation is typically an afterthought and does not generate revenue).

Open issues not addressed by these Policies

Các vấn đề mở không được đề cập tới trong các chính sách nêu trên

Issues not addressed explicitly above but critically important to MoJ success are:

Các vấn đề không được đề cập tới một cách rõ ràng ở trên nhưng lại là quan trọng sống còn đối với sự thành công của Bộ Tư pháp là:

1. Những cải tiến trong thực tiễn phát triển giải pháp và phần mềm

2. Những ảnh hưởng của sự vận hành như các qui trình của các phiên bản và những thay đổi đối với các quan hệ Gen-i

3. Việc đánh phiên bản nội bộ và quản lý cấu hình

4. Các yêu cầu và đòi hỏi về nghiên cứu phát triển về phòng thí nghiệm A&S

5. Đánh giá ảnh hưởng rộng rãi của chính phủ về vấn đề sở hữu trí tuệ của vụ Novell/Microsoft và những thoả thuận bán lẻ

6. Các vấn đề về sở hữu trí tuệ rộng hơn bên trong chính phủ New Zealand có liên quan tới phần mềm nguồn mở, quản lý quyền hạn số và bản quyền

7. Các vấn đề rộng lớn hơn bên trong chính phủ New Zealand liên quan tới phát triển kinh tế. Việc áp dụng rộng rãi hơn PMNM là một dạng 'Mua Kiwi' bằng các phương tiện khuyến khích phát triển của các nhà cung cấp dịch vụ và phần mềm của New Zealand.

(1) Improvements in software and solutions development practices,

(2) Operations impacts such as release processes and changes to the Gen-i relationship,

(3) Internal versioning and configuration management,

(4) R&D requirements and demands on the A&S lab,

(5) Government-wide impact assessment of Novell/Microsoft IP and reseller agreements,

(6) Broader IP issues within NZ government related to open source software, whiteboarding, digital rights

management, and copyright; and

(7) Broader issues within NZ government related to economic development. More widespread adoption of OSS is a form of 'Buying Kiwi' by means of encouraging growth of NZ-based software and service providers.

Disclaimer

Không thừa nhận

Tài liệu này phản ánh nhiều tháng tranh luận bên trong Bộ Tư pháp và với các đối tác của nó. Nó được xem xét lại để phản ánh ý kiến đóng góp từ nhiều độc giả, và được tin tưởng là sẽ phù hợp với các chính sách hiện hành của Bộ Tư pháp. Nhưng tài liệu này không biểu lộ bất kỳ dạng cam kết thương mại hay pháp lý nào của Bộ Tư pháp.

This document reflects months of discussions within MoJ and with its partners. It has been revised to reflect feedback f-rom dozens of readers, and is believed to be consistent with existing MoJ policies. But this document is not the expression of any sort of legal or commercial commitment by MoJ.

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

ltnghia@yahoo.com