How
to evaluate the sustainability of an open source project
by Scott Wilson
on 11 December 2013
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,
from the viewpoint of selection 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.
Elsewhere
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 where 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 Selecting Open Source Software and Decision
Factors for Open Source Software Procurement.
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:
From
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 from 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.
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 creates 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 from 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
create a new release in 8 out of the last 9 quarters:
Similarly,
the SQLite project has made frequent releases from 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 from web pages, or obtain the dates when source code was
“tagged” with a particular version in the source control system.
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 from users?
Note
that even if there are lots of complaints
from 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 where 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 from 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 from one tool to another –
for example there may be a legacy mailing list from 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.
Projects
sometimes follow a natural cycle of being created, 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 where there seems to
be steady migration from 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.
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 from 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 where 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?
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 from OSS Watch:
Dịch: Lê Trung Nghĩa
Không có nhận xét nào:
Đăng nhận xét
Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.