Các mẹo hàng đầu cho việc lựa chọn phần mềm nguồn mở

Top tips for selecting open source software

By Randy Metcalfe, Published: 01 February 2004, Reviewed: 09 July 2012

Theo: http://www.oss-watch.ac.uk/resources/tips

Bài được đưa lên Internet ngày: 09/07/2012

Lời người dịch: Khi lựa chọn một phần mềm nguồn mở (PMNM) để sử dụng, bạn cần trước hết lựa chọn các mô hình đánh giá PMNM như mô hình độ chín bền vững của phần mềm (SSMM) hay mô hình độ chín của PMNM (OSMM), chúng đề cập tới các vấn đề của phần mềm cần chọn như: (1) Uy tín của phần mềm; (2) Nỗ lực liên tục; (3) Các tiêu chuẩn và tính tương hợp; (4) Sự hỗ trợ của cộng đồng; (5) Sự hỗ trợ thương mại; (6) Phiên bản; (7) Phiên bản1.0; (8) Tài liệu; (9) Tập hợp các kỹ năng; (10) Mô hình phát triển của dự án; (11) Giấy phép. Và còn một tiêu chí quan trọng nữa, là tổng chi phí sở hữu (TCO). Bạn hãy đọc hết bài để có được chi tiết về các tiêu chí này.

Các mẹo hàng đầu

Hiệu năng và độ tin cậy là các tiêu chí rất quan trọng cho việc lựa chọn phần mềm. Tuy nhiên, trong hầu hết sự thực hành mua sắm, thì giá cũng là một yếu tố quyết định khi so sánh các định giá từ nhiều nhà cung cấp. Các so sánh về giá có một vai trò, nhưng thường không phải là so sánh duy nhất của các giá mua. Thay vào đó, các vấn đề về giá có xun hướng nảy sinh khi so sánh tổng chi phí sở hữu (TCO), nó bao gồm cả giá mua và các chí phí liên tục cho sự hỗ trợ (và làm mới lại giấy phép) qua toàn bộ vòng đời của sản phẩm.

Một số khung công việc đã được phát triển để giúp mọi người trong mua sắm CNTT đánh giá phần mềm nguồn mở (PMNM). Chúng có thể giúp xác định tính phù hợp của các ứng dụng nhất định trong các tình huống nhất định, hoặc để đánh giá các sản phẩm nguồn mở khác nhau đối với nhau. Chúng không thật phù hợp cho việc so sánh PMNM đối với các lựa chọn thay thế sở hữu độc quyền. Các ví dụ của các khung như vậy bao gồm Mô hình độ chín bền vững của phần mềm – SSMM (Software Sustainability Maturity Model) (bản dịch tiếng Việt) và Mô hình độ chính của phần mềm nguồn mở – OSMM (Open Source Maturity Model).

Các lĩnh vực chủ đề sau đây là quan trọng khi cân nhắc các PMNM:

Uy tín

Phần mềm có một uy tín tốt về hiệu năng và độ tin cậy không? Ở đây, các báo cáo nói mồm từ những người mà ý kiến của họ bạn tin cậy được thường là chìa khóa. Một số PMNM có một uy tín rất tốt trong giới công nghiệp, như máy chủ web Apache, Trình biên dịch GNU(GCC), Linux, Samba ... Bạn nên so sánh các PMNM giống tốt nhất so với các phần mềm tương tự sở hữu độc quyền. Việc thảo luận các kế hoạch của bạn với ai đó có kinh nghiệm sử dụng PMNM, và một nhận thức về các gói mà bạn đang đề xuất sử dụng, là sống còn.

Nỗ lực liên tục

Có bằng chứng rõ ràng về những nỗ lực liên tục để phát triển PMNM mà bạn đang cân nhắc hay không? Liệu có công việc gần đây để sửa các lỗi và đáp ứng các nhu cầu của người sử dụng hay không? Các dự án tích cực thường cập nhật thường xuyên các trang web và các danh sách thư điện tử phát triển bận rộn. Chúng thường khuyến khích sự tham gia của những người sử dụng phần mềm trong sự phát triển tiếp của nó. Nếu mọi thứ là im lìm ở mặt trận phát triển, thì có thể là công việc đã bị treo hoặc thậm chí dừng rồi.

Các tiêu chuẩn và tính tương hợp

Hãy chọn phần mềm mà triển khai các tiêu chuẩn mở. Tính tương hợp với các phần mềm khác là một cách thức quan trọng để có được từ sự đầu tư của bạn. Phần mềm tốt không nhất thiết phải làm lại cái bánh xe, hoặc ép bạn phải học các ngôn ngữ mới hoặc các định dạng dữ liệu phức tạp.

Sự hỗ trợ (Cộng đồng)

Dự án có một cộng đồng hỗ trợ tích cực sẵn sàng trả lời các câu hỏi của bạn về sự phát triển hay không? Hãy nhìn vào lưu trữ của danh sách thư của dự án, nếu có sẵn. Nếu bạn gửi một thông điệp vào danh sách và nhận được nhắc nhở và trả lời hữu dụng hợp lý, thì điều này có thể là dấu hiệu rằng có một cộng đồng những người sử dụng tích cực ở đó sẵn sàng để giúp đỡ. Thực tiễn tốt (bản dịch tiếng Việt) gợi ý rằng nếu bạn muốn tận dụng bản thân các hỗ trợ như vậy, thì bạn cũng nên có thiện chí để cung cấp sự hỗ trợ cho những thành viên khác của cộng đồng khi bạn có khả năng.

Hỗ trợ (thương mại)

Sự hỗ trợ thương mại của bên thứ 3 là sẵn sàng từ một sự đa dạng các công ty, trải từ các tập đoàn lớn như IBM và Sun Microsystems, tới các tổ chức nguồn mở chuyên gia như Red Hat và MySQL, tới các hãng địa phương và các nhà thầu độc lập.

Phiên bản

Khi nào phiên bản ổn định mới nhất của phần mềm được phát hành? Hầu hết không phần mềm nào, cả sở hữu độc quyền hoặc nguồn mở, là hoàn toàn không có lỗi. Nếu có một cộng đồng phát triển tích cực, thì những lỗi mới được phát hiện sẽ được sửa và các bản vá cho phần mềm hoặc phiên bản mới sẽ được phát hành; đối với sử dụng chuyên nghiệp, bạn cần phiên bản phần mềm ổn định gần nhất. Tất nhiên, luôn có lựa chọn bạn tự sửa lỗi, vì mã nguồn phần mềm sẽ là sẵn sàng cho bạn. Nhưng điều đó phụ thuộc vào tập hợp các kỹ năng và cam kết về thời gian của bạn (hoặc đội của bạn).

Phiên bản 1.0

Trong nguồn mở, không có qui ước đối với tầm quan trọng của số phiên bản 1.0. Một chương trình với một số phiên bản thấp hơn 1.0 có thể là phù hợp cho sử dụng sản xuất. Ngược lại, một sản phẩm với số phiên bản 1.0 hoặc lớn hơn thì không. Các tiêu chí khác với số phiên bản phải chỉ dẫn ở đây.

Tài liệu

Các dự án PMNM có thể tụt hậu phía sau trong tài liệu đối với người sử dụng đầu cuối, nhưng chúng thường tốt hơn với tài liệu phát triển của chúng. Bạn nên có khả năng theo dõi lịch sử rõ ràng của các sửa lổi, cac sthay đổi tính năng, …

Tập hợp các kỹ năng

Hãy xem xét tập hợp kỹ năng của bản thân bạn và các đồng nghiệp của bạn. Bạn có được các kỹ năng phù hợp để triển khai và duy trì phần mềm này không? Nếu không, bạn sẽ sử dụng các nhà thầu là bên thứ 3 hay bạn sẽ triển khai một kế hoạch huấn luyện để khớp các kỹ năng của bạn với nhiệm vụ đó? Hãy lưu ý, điều này không đơn giản đúng cho PMNM, mà còn cho các phần mềm sở hữu độc quyền nữa. Các chi phí huấn luyện đó nên được đưa vào khi so sánh TCO cho các sản phẩm khác nhau.

Mô hình phát triển của dự án

Sự phát triển của nguồn mở nên không là loạn xạ, dù nó đối lúc có thể thấy như vậy. Một dự án nguồn mở nên có một qui trình phát triển rất rõ ràng mô tả cách mà những đóng góp được thực hiện và cách mà chúng được đánh giá để đưa vào. Nó cũng nên mô tả cách mà những người đóng góp đầu tư tài nguyên đáng kể trong những tùy biến có thể trở thành một phần của, hoặc ảnh hưởng, tới sự quản lý của dự án. Điều này là để tái khẳng định cho những người đóng góp rằng những đóng góp của họ sẽ vẫn có giá trị cho họ trong tương lai. Trong một số dự án có một cấu trúc chính thức điều hành dạng phát triển này, trong những dự án khác thì cấu trúc đó được để lỏng, trong cả 2 trường hợp các qui tắc tham gia nên là rõ ràng.

Giấy phép

Còn tranh cãi, PMNM phần nhiều là về giấy phép khi hay là nó là về phương pháp luận phát triển. Hãy đọc giấy phép. Các giấy phép nguồn mở được thừa nhận có các điều kiện được định nghĩa tốt cho sự đóng góp mã nguồn của bạn cho sự phát triển đang diễn ra của phần mềm hoặc sự kết hợp của mã vào các gói khác. Nếu bạn không quen với các giấy phép đó hoặc với một giấy phép được phần mềm sử dụng mà bạn đang cân nhắc, hãy bỏ thời gian để làm rõ các điều kiện sử dụng (bản dịch tiếng Việt).

Tài liệu Các yếu tố quyết định cho mua sắm PMNM (bản dịch tiếng Việt) cung cấp chỉ dẫn chi tiết hơn trong việc lựa chọn và triển khai nguồn mở trong các môi trường doanh nghiệp hoặc viện trường như các trường cao đẳng và đại học.

Top Tips

Performance and reliability are very important criteria for selecting software. In most procurement exercises however, price is also a determining factor when comparing quotes from multiple vendors. Price comparisons do have a role, but usually not in terms of a simple comparison of purchase prices. Rather, price issues tend to arise when comparing total cost of ownership (TCO), which includes both the purchase price and ongoing costs for support (and licence renewal) over the real life span of the product.

Some frameworks have been developed to help those in IT procurement assess open source software. These can help determine the appropriateness of particular applications in specific situations, or to evaluate different open source products against one another. They are not so well suited for comparing open source software against proprietary alternatives. Examples of such frameworks include the Software Sustainability Maturity Model and the Open Source Maturity Model (OSMM).

The following topic areas are important when considering open source software:

Reputation

Does the software have a good reputation for performance and reliability? Here, word of mouth reports from people whose opinion you trust is often key. Some open source software has a very good reputation in the industry, e.g. Apache web server, GNU Compiler Collection (GCC), Linux, Samba etc. You should be comparing best of breed open source software against its proprietary peers. Discussing your plans with someone with experience of using open source software, and an awareness of the packages you are proposing to use, is vital.

Ongoing effort

Is there clear evidence of ongoing effort to develop the open source software you are considering? Has there been recent work to fix bugs and meet user needs? Active projects usually have regularly updated web pages and busy development email lists. They usually encourage the participation of those who use the software in its further development. If everything is quiet on the development front, it might be that work has been suspended or even stopped.

Standards and interoperability

Choose software which implements open standards. Interoperability with other software is an important way of getting more from your investment. Good software does not unnecessarily reinvent the wheel, or force you to learn new languages or complex data formats.

Support (Community)

Does the project have an active support community ready to answer your questions concerning deployment? Look at the project’s mailing list archive, if available. If you post a message to the list and receive a reasonably prompt and helpful reply, this may be a sign that there is an active community of users out there ready to help. Good practice suggests that if you wish to avail yourself of such support, you should also be willing to provide support for other members of the community when you are able.

Support (Commercial)

Third party commercial support is available from a diversity of companies, ranging from large corporations such as IBM and Sun Microsystems, to specialist open source organizations such as Red Hat and MySQL, to local firms and independent contractors.

Version

When was the last stable version of the software released? Virtually no software, proprietary or open source, is completely bug free. If there is an active development community, newly discovered bugs will be fixed and patches to the software or a new version will be released; for enterprise use, you need the most recent stable release of the software. There is, of course, always the option of fixing bugs yourself, since the source code of the software will be available to you. But that rather depends on your (or your team’s) skill set and time commitments.

Version 1.0.

In open source, there is no convention as to the significance of a 1.0 version number. A program with a version number below 1.0 may be suitable for production use. Conversely, a product with version number of 1.0 or above may not be. Criteria other than version number must be the guide here.

Documentation

Open source software projects may lag behind in their documentation for end users, but they are often better with their development documentation. You should be able to trace a clear history of bug fixes, feature changes, etc.

Skill set

Consider the skill set of yourself and your colleagues. Do you have the appropriate skills to deploy and maintain this software? If not, will you employ third party contractors or will you implement a training plan to match your skills to the task? Remember, this is not simply true for open source software, but also for proprietary software. These training costs should be included when comparing TCOs for different products.

Project Development Model

Open source development should not be chaotic, although it can sometimes look that way. An open source project should have a very clear development process that describes how contributions are made and how they are evaluated for inclusion. It should also describe how contributors investing considerable resource in customisations can become a part of, or influence, the project management. This is to reassure significant contributors that their contributions will remain valuable to them in the future. In some projects there is a formal structure governing this kind of development, in others the structure is fluid, in both cases the rules of engagement need to be clear.

Licence

Arguably, open source software is as much about the licence as it is about the development methodology. Read the licence. Recognised open source licences have well defined conditions for your contribution of code to the ongoing development of the software or the incorporation of the code into other packages. If you are not familiar with these licences or with the one used by the software you are considering, take the time to clarify conditions of use.

The document Decision factors for open source software procurement provides more detailed guidance in selecting and deploying open source in institutional or enterprise environments such as colleges and universities.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com