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

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.

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ý).

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

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.

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.

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.

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ợ.

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.

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.

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ố).

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

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.

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.

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