Đánh giá tính bền vững của một dự án nguồn mở như thế nào

Thứ ba - 25/02/2014 07:12

P { margin-bottom: 0.21cm; }A:link { }

How to evaluate the sustainability of an open source project

by Scott Wilson on 11 December 2013

Theo: http://oss-watch.ac.uk/resources/evaluatingsustainability

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

Lời người dịch: Có nhiều tiếp cận khác nhau với các dấu hiệu khác nhau để đánh giá tính bền vững của một dự án phần mềm nguồn mở. Nếu bạn muốn xây dựng một dự án nguồn mở bền vững, thì những gợi ý trong bài là điều bạn rất nên nắm bắt.

Các dự án nguồn mở bền vững là các dự án mà có khả năng tự chúng hỗ trợ. Nói đơn giản, chúng có khả năng đáp ứng các chi phí liên tục của chúng.

Tuy nhiên, từ quan điểm lựa chọn và mua sắm, tính bền vững cũng có nghĩa là dự án có khả năng phân phối các cải tiến và sửa các lỗi với các sản phẩm của nó theo một cách đúng lúc, và bản thân dự án có một triển vọng hợp lý tiếp tục trong tương lai.

Đâu đó trên site của chúng tôi bạn có thể tìm thấy các bài viết mô tả một vài trong số nhiều tiếp cận chính thống cho việc đánh giá phần mềm nguồn mở như một phần của Mô hình Độ chín Bền vững của Phần mềm – SSMM (Software Sustainability Maturity Model).

Tuy nhiên, cũng có các phương pháp không chính thống cho việc đánh giá tính bền vững của một dự án nguồn mở mà có thể là hữu dụng nơi mà sự đầu tư trong một phương pháp luận chính thống không được biện minh, ví dụ nếu số lượng các đánh giá phần mềm mà tổ chức của bạn tiến hành là khác nhỏ và không thường xuyên.

Trong tài liệu này chúng tôi xem xét một số chỉ số chính của tính bền vững mà bạn có thể đánh giá bằng việc sử dụng các kỹ thuật nghiên cứu web và thông tin truy cập được công khai:

hoạt động của mã
các phát hành
cộng đồng người sử dụng
tính vĩnh cửu
hệ sinh thái

Lưu ý rằng chúng không có cách nào là những yếu tố duy nhất để xem xét khi đánh giá phần mềm; xem thêm bài của chúng tôi về Các mẹo hàng đầu cho việc lựa chọn phần mềm nguồn mở và Các yếu tố quyết định cho mua sắm phần mềm nguồn mở.

Hoạt động của mã: các đóng góp và những người đóng góp

Đối với một dự án sẽ là bền vững thì nó phải có những người đóng góp, và kho mã của nó cần phải có tiến hóa. Bạn có thể theo dõi điều này bằng việc xem xét hệ thống kiểm soát sửa đổi của dự án và xem xét mẫu của các đóng góp. Một nhúm các công cụ cho việc thực hiện điều này là website Ohloh của Black Duck Software.

Đây là lịch sử đóng góp cho CKAN, ví dụ:

Các dự án phần mềm có xu hướng đi qua các chu kỳ hoạt động khác biệt nhau; thường có một cơn gió mạnh của sự phát triển ở lúc đầu của một dự án khi khung công việc và các chức năng chính được bày ra, sau đó bước đi có xu hướng chậm lại khi dự án chín muồi và nỗ lực chuyển sang việc sửa các lỗi và cải thiện hiệu năng. Sau đó có thể có cơn gió mạnh khác của hoạt động khi có một sự bổ sung chức năng chính, hoặc một sự chuyển sang một khung công việc mới.

Vì thế hoàn toàn bình thường để thấy các biến động trong số lượng các đóng góp cho kho mã của một dự án, và đối với một số dự án một số lượng giảm dần các đóng góp thực sự là một dấu hiệu tốt nếu nó chỉ thị tính bền vững và độ chín.

Một lần nữa, nhìn vào CKAN chúng ta có thể so sánh đồ thị ở trên với sự đo đếm số lượng những người đóng góp cho dự án:

Vì thế ảnh ở đây là toàn bộ số lượng các lập trình viên đóng góp cho dự án đang gia tăng rồi, nhưng bước phát triển đang chậm lại sau một đỉnh chóp. Đây là một dấu hiệu tốt khi nó chỉ ra rằng dự án đạt đỉnh chóp các lập trình viên thậm chí khi nó chuyển động vào một pha ổn định hơn.

Tuy nhiên, một ví dụ khác ở đây, HtmlCleaner.

Đây là một dự án mà đã từng “được khởi động lại” sau khi rơi vào sự không hoạt động khoảng 1 năm. Bản thân dự án là hoàn toàn chín muồi. Tuy nhiên, bất kỳ ai đang đánh giá dự án đó trong năm 20 12cũng có thể đúng khi lo lắng về tính bền vững của nó.

Cuối cùng, đây là một ví dụ tốt về những giới hạn của tiếp cận này:

Từ hình này nó trông như là dự án đã chết từ năm 2008 và đã không thấy hoạt động từ đó. Tuy nhiên, dự án đó (OpenSAML trong trường hợp này) trên thực tế không chết! Dự án đơn giản đã thay đổi địa điểm kho mã nguồn của nó và điều này đã không được phản ánh tong hồ sơ của nó trên website Ohloh.

Nếu bạn xem trên website của riêng dự án thì bạn có thể đi theo một liên kết tới kho của nó và thấy các đóng góp mã từ sau ngày này. Vì thế điều quan trọng không chỉ lấy các dạng đồ thị ở giá trị bề mặt, mà còn phải kiểm tra liệu nó có phản ánh những gì đang diễn ra trong bản thân hệ thống kiểm soát sửa đổi hay không.

Lịch sử phát hành

Các dự án có các tiếp cận rất khác nhau khi tiến hành các phát hành, nên là khó để tổng quát hóa giữa các dự án. Một số có thể đệ trình để có các phát hành thường xuyên, và nếu có các vấn đề về tính bền vững thì điều này sẽ là bằng chứng trong sự đứt quãng chu kỳ đó. Tuy nhiên, nhiều dự án tiến hành các phát hành khi họ cảm thấy sẵn sàng, và vì thế các phát hành sẽ không tuân theo bất kỳ mẫu đặc biệt nào.

Vì điều này mà lịch sử phát hành có thể nói được ít hơn về lịch sử hữu ích so với việc nhìn vào cộng đồng các lập trình viên mà tạo ra các phát hành đó.

Một ngoại lệ là nếu từng không có các phát hành đôi lúc nào đó bất chấp một mức độ tốt hoạt động của các lập trình viên; điều này có thể chỉ ra rằng có các vấn đề về điều hành bên trong dự án mà đang cản trở nó tiến hành các phát hành; cách duy nhất để tìm ra là đi tới các cộng đồng dự án và xem liệu có một vấn đề hay không.

Bên dưới là lịch sử phát hành cho HtmlCleaner từ 2006 tới 2013. Điều này phần lớn phản ánh mẫu hoạt động trong dự án, nhưng cũng chỉ ra rằng các phát hành từng được thực hiện thường xuyên hơn trong các năm trong quá khứ.

Đây là lịch sử phát hành của CKAN cho các năm 2011-2013, chỉ ra dự án tạo một phát hành mới trong 8 từ 9 quý vừa qua:

Tương tự, dự án SQLite đã thực hiện các phát hành thường xuyên từ 2006-2013:

Lưu ý rằng, không giống như các dữ liệu về sự hoạt động, các lịch sử phát hành thường không sẵn sàng theo cách làm cho chúng dễ dàng phân tích. Bạn có thể cần các danh sách đầu vào từ các trang web, hoặc có được các ngày tháng khi mã nguồn từng được “gắn thẻ” với một phiên bản đặc biệt trong hệ thống kiểm soát mã nguồn.

Cộng đồng người sử dụng

Phần mềm không bền vững nếu không có những người sử dụng. Những người sử dụng định hướng chức năng, nhận diện các lỗi, và hình thành đường hướng của một dự án để đáp ứng các nhu cầu của họ. Thường không rõ ràng cách xác định kích cỡ và sự đầu tư của cộng đồng người sử dụng trong một dự án phần mềm, khi mà sự tham gia có xu hướng khác nhau, phụ thuộc vào dạng dự án.

Một điểm khởi đầu tốt là hãy sử dụng máy tìm kiếm để có được một ý tưởng xem ai đang nói về dự án. Một công cụ hữu dụng là Google Trends, nó cho phép bạn nhìn thấy có bao nhiêu người đang tìm kiếm thông tin về một chủ đề. Ví dụ, chúng ta có thể so sánh các tìm kiếm cho “CloudStack” vs. “OpenStack”:

Bạn cũng có thể sử dụng các máy tìm kiếm để biết về các bài viết trên các blog và các bài báo thảo luận về dự án. Tương tự, bạn có thể theo cá thẻ băm (hashtag) của dự án trên Twitter hoặc hoạt động có liên quan trên LinkedIn, Facebook và Google+. Liệu dự án có nhiều “fan hâm mộ” hay không? Hoặc liệu nó có tạo ra nhiều bài trên Twitter từ những người sử dụng hay không?

Lưu ý rằng thậm chí nếu có nhiều khiếu nại từ những người sử dụng trên phương tiện xã hội thì điều này không nhất thiết là một dấu hiệu tiêu cực - nó chỉ ra ít nhất là có đủ những người quan tâm đủ tới sản phẩm đó để sử dụng thậm chí dù họ có một vấn đề với nó!

Một công cụ khác để sử dụng là trình theo dõi các vấn đề của dự án. Một dự án lành mạnh nên có một số lượng tốt các vấn đề với nó - dù điều này nghe có vẻ khá phản trực quan. Về cơ bản, tất cả các phần mềm đều có các lỗi và các lĩnh vực cho sự cải tiến. Một cộng đồng người sử dụng lành mạnh sẽ liên tục phát hiện các lỗi đó và nhận diện các lĩnh vực nơi mà phần mềm có thể cải thiện. Tất nhiên, một số dự án là rất chín muồi và có thể có khá ít hoạt động trong trình theo dõi lỗi.

Tuy nhiên, đối với các dự án mới hơn, nếu không có các báo cáo lỗi nào trong trình theo dõi lỗi thì điều này có thể chỉ ra hoặc một cộng đồng các lập trình viên phản ứng dị thường mà đóng được các vấn đề ngay khi chúng xuất hiện, nhưng điều đó nhiều khả năng hơn chỉ ra một dự án không có đủ những người sử dụng để tìm ra được bất kỳ vấn đề gì với nó.

Một lần nữa, hãy thận trọng về những điểm yếu không đúng: có thể không có các lỗi nhìn thấy vì dự án đã chuyển từ việc sử dụng một hệ thống này sang một hệ thống khác ở một số thời điểm. Ví dụ, ePrints có các vấn đề di sản của nó trong Trac, nhưng các vấn đề mới được báo cáo trên GitHub.

Bạn cũng có thể xem các công cụ của cộng đồng những người sử dụng được dự án cung cấp để có được một ý tưởng về tính bền vững, như các diễn đàn người sử dụng và các danh sách thư. Nhiều thứ đó đưa ra các phân tích được xây dựng sẵn, hoặc bạn có thể sử dụng các site của bên thứ 3 như Markmail.

Ví dụ, nếu chúng ta nhìn vào các thông điệp trong các danh sách thư của Hadoop trên Markmail, bạn có thể thấy sự gia tăng qua thời gian hoạt động của danh sách thư đối với dự án đó:

Một lần nữa, hãy thận trọng khi các cộng đồng có thể dễ dàng chuyển từ công cụ này sang công cụ khác - ví dụ có thể có một danh sách thư di sản khi dự án đã bắt đầu không có các bài đưa lên sau một ngày tháng nhất định nào đó, nhưng những người sử dụng mới có thể thực sự đang tương tác với dự án thông qua trang Facebook hoặc Google+ của nó.

Tóm lại, điều này nên trao cho bạn một ý tưởng hợp lý về sức khỏe của cộng đồng một dự án. Bạn có thể lấy một tiếp cận chính thống thực sự xuất phát từ các con số dựa vào ccs công cụ khác nhau đó, nhưng đưa ra được sự đa dạng các nguồn mà một tiếp cận định tính dường như thực tế hơn.

Tính vĩnh cửu

Các dự án đôi khi đi theo một chu kỳ tự nhiên của việc được tạo ra, có một cơn gió mạnh hoạt động cao, trước khi chuyển sang một pha sản xuất ổn định, trước khi cuối cùng chìm khi nó được thay thế bằng các dự án mới trong vùng y hệt với một nền công nghệ mạnh mẽ hơn.

Tuy nhiên, một số dự án nguồn mở cũng sống lâu một cách khó tin, như máy chủ web Apache.

Khi điều này xảy ra, hiệu ứng đó có xu hướng sẽ là thứ gì đó tự bền vững như nhiều tổ chức bảo thủ hơn áp dụng phần mềm đó, và vẫn giữ sử dụng nó dài lâu hơn, gây ra sự đầu tư lâu dài hơn trong tính bền vững của nó.

Nếu một dự án đã sống sót đủ lâu qua việc liệu có vài chu kỳ thay thế công nghệ hay không, thì điều này là chỉ số tốt rằng nó sẽ tiếp tục được trong những năm sắp tới. Các dấu hiệu cảnh báo ở đâu có thể có sự chuyển đổi rồi từ cộng đồng dựa án sang dự án khác; thậm chí cuối cùng một dự án lớn, chín muồi sẽ bắt đầu chịu đựng nếu điều này xảy ra.

Đối với các dự án mới hơn mà khó để phán xét; nếu chúng đang ở trong pha phát triển nhanh lúc khởi đầu dự án thường không có chỉ số thực sự về việc liệu dự án có không thành công và bị thay thế bằng điều lớn lao nào tiếp sau hay không, hay dịu dần trong một cuộc sống dài và năng suất.

Ví dụ, đã có một số tranh luận khi Node.js lần đầu xuất hiện về việc liệu sự khởi đầu rất sống động “rất kêu” về dự án có đi tới chết yểu hay không. Tuy nhiên, dự án bây giờ đã 3 tuổi và chỉ ra các dấu hiệu đang dịch chuyển vào một pha ổn định hơn.

Đối với số ít hơn các dự án, tiến trình hành động tốt nhất có thể sẽ là giảm nhẹ đi các rủi ro hơn là tránh chúng; ví dụ, việc phát triển một chiến lược thoát ra tốt, việc đầu tư trong tính tương hợp và các tiêu chuẩn mở được dự án hỗ trợ, và việc tiến hành các rà soát lại thường xuyên cách mà dự án đang tiến hóa so với các đối thủ của nó.

Hệ sinh thái

Cũng như việc xem xét các lập trình viên và những người sử dụng xung quanh một dự án, cũng quan trọng để xem xét các công ty mà tham gia vào với nó. Điều này bao gồm các nhà cung cấp đặt chỗ hosting và hỗ trợ, các dịch vụ tư vấn và tùy biến, và các công ty mà đánh đống các phần mềm với các sản phẩm như một phần các giải pháp.

Hệ sinh thái xung quanh một dự án là một chỉ số quan trọng rõ ràng về các công ty như vậy có một mối quan tâm mạnh trong tính bền vững của bản thân các phần mềm đó.

Phép ẩn dự đôi khi được sử dụng đối với một “vết rạn san hô” - một dự án bền vững tích tụ các đối tác và các nhà cung cấp ngày một chuyên môn hóa. Giống tương tự, neus có các dấu hiệu các công ty dịch vụ chuyển từ việc hỗ trợ dự án thì điều này có thể là một chỉ số của các vấn đề nằm bên dưới.

Không phải tất cả các dự án phần mềm theo bản chất tự nhiên của nó đưa bản thân nó tới dạng hệ sinh thái này, mà ở những nơi có các công ty cung cấp các dịch vụ hữu dụng để xem xét sự đa dạng của chúng. Ví dụ, liệu chúng có chỉ vận hành trong 1 hoặc 2 quốc gia hay không? Liệu chúng có là một sự pha trộn giữa các công ty nhỏ hơn và lớn hơn hay không? Liệu chúng tất cả nhắm đích vào một lĩnh vực công nghiệp duy nhất hay không?

Đặt nó tất cả cùng nhau

Không có cách nào chỉ các yếu tố đó khi xem xét tính bền vững của phần mềm, và nếu bạn đang tiến hành một số lượng lớn các đánh giá thì việc áp dụng một phương pháp luận chính thống và tập hợp các công cụ có thể là một sự đầu tư đáng giá. Tuy nhiên, đối với sự tiến hóa đặc biệt thì lưu ý tóm tắt này sẽ đưa ra một điểm khởi đầu tốt.

Các liên kết:

Thông tin có liên quan từ OSS Watch:

Sustainable open source projects are those that are capable of supporting themselves. Simply put, they are able to meet their ongoing costs.

However, f-rom the viewpoint of se-lection and procurement, sustainability also means that the project is capable of delivering improvements and fixing problems with its products in a timely manner, and that the project itself has a reasonable prospect of continuing into the future.

Elsewhe-re on our site you can find articles describing some of the many formal approaches to evaluating open source software as part of the Software Sustainability Maturity Model.

However, there are also informal methods for evaluating the sustainability of an open source project that may be useful whe-re investment in a formal methodology is not justified, for example if the number of software evaluations your organisation undertakes is fairly small and infrequent.

In this document we’ll take a look at some of the key indicators of sustainability you can evaluate using basic web research techniques and publicly accessible information:

code activity
releases
user community
longevity
ecosystem

Note that these are by no means the only factors to look at when evaluating software; see also our Top Tips for Se-lecting Open Source Software and Decision Factors for Open Source Software Procurement.

Code activity: contributions and contributors

For a project to be sustainable it must have contributors, and its codebase needs to be evolving. You can track this by looking at the project’s revision control system and looking at the pattern of contributions. One handy tool for doing this is the Ohloh website by Black Duck Software.

Here’s the contribution history for CKAN, for example:

Software projects tend to go through distinct cycles of activity; there is often a flurry of development at the start of a project as the framework and main features are put in place, then the pace tends to slow down as the project matures and effort shifts onto fixing bugs and improving performance. Later on there may be another flurry of activity as there is a major feature addition, or a move onto a new framework.

So its quite normal to see fluctuations in the number of contributions to the codebase of a project, and for some projects a declining number of contributions is actually a good sign if it indicates stability and maturity.

Again, looking at CKAN we can compare the graph above with the measure of the number of contributors to the project:

So the picture here is that the overall number of developers contributing to the project is steadily increasing, but the pace of development is slowing down after a peak. This is a good sign as it indicates that the project is picking up developers even as it moves into a more stable phase.

However, here’s another example, HtmlCleaner.

This is a project that has been “rebooted” after lapsing into inactivity for about a year. The project itself is quite mature. However, anyone evaluating the project in 2012 would have been correct to be concerned for its sustainability.

Finally, here is a good example of the limitations of this approach:

F-rom this it looks as if the project pretty much died towards the end of 2008 and has seen no activity since. However, the project (OpenSAML in this case) is not in fact dead! The project simply changed the location of its source code repository and this hadn’t yet been reflected in its profile on the Ohloh website.

If you take a look at the project’s own website you can follow a link to its repository and see code contributions f-rom well after this date. So it’s important to not just take these kinds of graphs at face value, but to check whether it reflects what is happening in the revision control system itself.

Release History

Projects take very different approaches to making releases, so it’s hard to generalise between projects. Some may commit to make regular releases, and if there are sustainability issues this will be evident in disruptions to the cycle. However, many projects make releases as and when they feel ready, and so releases will not follow any particular pattern.

Because of this the release history can tell a less useful story than looking at the developer community that cre-ates the releases.

One exception is if there have been no releases for some time despite a good level of developer activity; this may indicate that there are governance issues within the project that are preventing it making releases; the only way to find out is to go into the project communications and see if there is an issue.

Below is the release history for HtmlCleaner f-rom 2006 to 2013. This largely mirrors the activity pattern in the project, but does also indicate that releases have been made on a more regular basis over the past year.

Here is the release history for CKAN for 2011-2013, showing the project cre-ate a new release in 8 out of the last 9 quarters:

Similarly, the SQLite project has made frequent releases f-rom 2006-2013:

Note that, unlike activity data, release histories often aren’t available in a way that makes them easy to analyze. You may need to input lists f-rom web pages, or obtain the dates when source code was “tagged” with a particular version in the source control system.

User Community

Software isn’t sustainable without users. Users drive the functionality, identify the bugs, and shape the direction of a project to meet their needs. It’s often not obvious how to determine the size and investment of the user community in a software project, as the engagement tends to vary depending on the kind of project.

A good starting point is to use a search engine to get an idea of who is talking about the project. A useful tool is Google Trends, which lets you see how many people are searching for information about a topic. For example, we can compare searches for “CloudStack” vs. “OpenStack”:

You can also use search engines to uncover blog posts and articles discussing the project. Similarly, you can follow the project’s hashtag on Twitter or related activity on LinkedIn, Facebook and Google+. Does the project have plenty of “fans”? Or does it generate plenty of tweets f-rom users?

Note that even if there are lots of complaints f-rom users on social media this isn’t necessarily a negative sign – it indicates at the very least there are enough people who care enough about the product to use it even though they have a problem with it!

Another tool to use is the project’s issue tracker. A healthy project should have a good number of issues with it – though this may sound a bit counter-intuitive. Basically, all software has bugs and areas for improvement. A healthy user community will continually uncover those bugs and identify the areas whe-re the software can improve. Of course, some projects are very mature and may have relatively little activity on bug trackers.

For newer projects, however, if there are no bug reports in the tracker this can indicate either a fantastically responsive developer community that closes the issues as soon as they appear, but it more likely indicates a project without enough users around to find any problems with it.

Again, be careful about false negatives: there may be no bugs visible because the project has moved f-rom using one system to another at some point. For example, ePrints has its legacy issues in Trac, but new issues are reported on Github.

You can also look at user community tools provided by the project to get an idea of sustainability, such as user forums and mailing lists. Many of these provide built-in analytics, or you can use third-party sites such as Markmail.

For example, if we look at messages on the Hadoop mailing lists on Markmail, you can see the increase over time of mailing list activity for the project:

Again, be careful as communities can easily move f-rom one tool to another – for example there may be a legacy mailing list f-rom when the project started with no posts after a certain date, but new users may actually be interacting with the project via its Facebook or Google+ page.

Taken together, this should give you a reasonable idea of the health of a user community. You can take a formal approach of actually deriving numbers based on these various tools, but given the diversity of sources a qualitative approach seems more realistic.

Longevity

Projects sometimes follow a natural cycle of being cre-ated, having a flurry of high activity, before moving into a steady productive phase, before eventually dying as its replaced by new projects in the same space with a more powerful technology base.

However, some open source projects are also fantastically long lived, such as the Apache web server.

When this happens, the effect tends to be somewhat self-sustaining as more conservative organisations adopt the software, and retain use of it for longer, resulting in longer-term investment in its sustainability.

If a project has survived long enough to weather several technology replacement cycles, this is a good indication it’s going to be around for years to come. The warning signs are whe-re there seems to be steady migration f-rom the project community to another; eventually even a large, mature project will start to suffer if this happens.

For newer projects it’s harder to judge; if they are in the phase of rapid development at the onset of the project there is often no real indication of whether the project will fizzle out and be replaced by the next big thing, or settle into a long and productive life.

For example, there was some debate when Node.js first appeared as to whether the very lively initial “buzz” around the project was going to be short-lived. However, the project is now three years old and shows signs of moving into a more stable phase.

For newer projects, the best course of action may be to mitigate the risks rather than avoid them; for example, developing a good exit strategy, investing in interoperability and open standards supported by the project, and conducting regular reviews of how the project is evolving compared to its competitors.

Ecosystem

As well as looking at the developers and users around a project, it’s also important to consider the companies that engage with it. This includes hosting and support providers, consultancy and customisation services, and companies that bundle the software with other products as part of solutions.

The ecosystem around a project is an important indicator as clearly such companies have a strong interest in the sustainability of the software themselves.

The metaphor sometimes used is that of a “coral reef” – a sustainable project accumulates partners and providers of increasing specialisation. Likewise, if there are signs of service companies moving away f-rom supporting the project this may be an indicator of underlying problems.

Not all software projects by their nature lend themselves to this kind of ecosystem, but whe-re there are companies providing services it’s useful to look at their diversity. For example, are they only operating in one or two countries? Are they a mix of smaller and larger companies? Are they all targeting a single industry sector?

Putting it all together

These are by no means the only factors when considering software sustainability, and if you are conducting a large number of evaluations then adopting a formal methodology and set of tools may be a worthwhile investment. However, for ad-hoc evaluation this briefing note should provide a good starting point.

Links:

Related information f-rom OSS Watch: