Community
source vs open source
By Gabriel Hanganu,
Published: 25 August 2008, Reviewed: 13 March 2012
Bài được đưa lên
Internet ngày: 13/03/2012
Lời
người dịch: Bài viết về thực tế của nước Anh, dù
nó có thể để tham khảo rất tốt cho Việt Nam. Bài viết
phân biệt mô hình phát triển
nguồn mở và mô
hình phát triển nguồn cộng đồng.
“Nguồn cộng đồng và nguồn
mở chia sẻ các động lực tương tự nhau, nhưng tiếp
cận của chúng đối với sự phát triển là hoàn toàn
khác nhau. Trong khi các dự án
nguồn mở tin tưởng là tốt hơn để phát
hành sớm và phát hành thường xuyên,
thì các dự án nguồn cộng đồng có ý định tạo
ra các sản phẩm phần lớn là hoàn chỉnh trước khi mở
ra sự truy cập cho qui trình phát triển.
Một số ưu thế được cho của nguồn cộng đồng, như
khả năng tích hợp gia tăng với các hệ thống khác, hoặc
chi phí thấp hơn về tư vấn và hỗ trợ, trong thực
tế là những tính năng của phát triển nguồn mở.
Những tính năng khác, như sự thích đáng đối với văn
hóa của khu vực giáo dục trong việc chia sẻ, hoặc khả
năng làm giảm nhẹ các rủi ro có liên quan tới những
lợi ích phân kỳ của những người đóng góp, dường
như là khó bền vững khi phân tích cùng với phát triển
nguồn mở. Việc quản lý các
dự án nguồn cộng đồng xuyên khắp nhóm [cơ quan] tập
trung vào giáo dục có thể rất lôi cuốn cho các mục
đích hành chính nhưng thiếu
tính mở trong các giai đoạn phát triển ban đầu có thể
làm xói mòn nghiêm trọng tiềm năng về tính bền vững
của chúng. Các bài học học
được từ các dự án nguồn cộng đồng là cực kỳ hữu
dụng, và chúng sẽ được sử dụng để phản ánh trong
bản chất tự nhiên sâu hơn của phát
triển nguồn mở (bản
dịch tiếng Việt) và tác động
tiềm tàng của nó lên Giáo dục Trung học và Giáo dục
cao hơn của nước Anh”.
Trong phát triển nguồn
mở truyền thống, mã phần mềm được làm cho sẵn sàng
để kiểm soát và sửa đổi từ đầu của một dự án.
Sự đóng góp của các đối tác độc lập hoặc cơ quan
có thể là tự nguyện hoặc có thể liên quan tới những
thỏa thuận ràng buộc pháp lý, nhưng về cơ bản mỗi
người có sự truy cập ngang bằng nhau tới mã từ ngày
đầu tiên. Ngược lại với sự phát triển nguồn mở,
trong các cái gọi là các dự án 'cộng đồng', như Sakai
và Kuali, một nhóm (consortium) của các cơ quan hoặc các
công ty thương mại ký một thỏa thuận theo đó họ quyết
định đóng góp một số lượng nhất định các tài
nguyên tài chính và/hoặc nhân lực, và đổi lại, có
toàn quyền trong việc gây ảnh hưởng tới sự phát triển
của dự án trong giai đoạn đóng ban đầu. Sau giai đoạn
đóng này, mã có thể được làm cho sẵn sàng cho bất kỳ
ai, và sự phát triển bước sang một mô hình nguồn mở
truyền thống hơn. Nguồn
cộng đồng (bản
dịch tiếng Việt) được mô tả trong một lưu ý ngắn
gọn khác của OSS Watch. Tài liệu này so sánh các mô hình
phát triển nguồn cộng đồng và nguồn mở, và thảo
luận về tính bền vững của chúng đối với nhóm các
cơ quan Giáo dục Trung học. (Higher Education institutions).
Thuật ngữ gây lẫn
lộn
Sự khác biệt giữa
nguồn mở và nguồn cộng đồng là không dễ làm, chủ
yếu vì 2 khái niệm đó thường được sử dụng một
cách không phù hợp. Trong kiểm soát sát sao hơn, nhiều ưu
thế được cho là của cái gọi là mô hình nguồn cộng
đồng thực tế tham chiếu tới các tính năng chung của
phát triển nguồn mở. Những tính riêng biệt như khả
năng gia tăng cho sự tích hợp với các hệ thống khác,
chi phí thấp hơn về tư vấn và hỗ trợ, và sự phát
triển nhân sự và các kỹ năng chia sẻ tri thứ được
cải thiện, là những hệ quả của việc mở ra sự truy
cập tới mã và sự phát triển của phần mềm. Cả 2 mô
hình đều cung cấp các giải pháp tạo doanh thu theo các
lựa chọn khác nhau, chúng thách thức các thực tiễn
thương mại truyền thống dựa vào việc bán các giấy
phép để sử dụng phần mềm.
Có khả năng tìm thấy
các mô hình tương tự cho nguồn cộng đồng trong môi
trường nguồn mở. Ví dụ, một số dự án lựa chọn
tung ra trong cái gọi là 'chế độ giấu giếm', đó là,
họ vận hành như một sự phát triển nguồn mở thực sự
từ kiểm soát, nhưng hạn chế thông tin marketing về dự
án trong các giai đoạn sớm. Điều này có tác động đối
với việc cho phép truy cập tới bấy kỳ ai mà quan tâm
đủ để phát hiện ra dự án, trong khi cùng lúc cho phép
những thành viên khởi xướng duy trì sự tập trung vào
các mục tiêu chiến lược sớm, hơn là sự phát triển
của cộng đồng.
Một mô hình văn
hóa cho giáo dục?
Một tính năng được
nói của mô hình nguồn cộng đồng có liên quan tới sự
thích hợp của nó cho thị trường Giáo dục Trung học và
Cao hơn. từ một viễn cảnh văn hóa, nguồn cộng đồng
thường được mô tả như sự vừa khít tuyệt vời với
các đặc tính và giá trị của giáo dục và nghiên cứu,
theo truyền thống có liên quan tới đổi mới trí tuệ và
việc chia sẻ tri thức giữa các học giả. Như trong các
cộng đồng truyền thống của các học giả, sự phát
triển nguồn cộng đồng được cho là xây dựng trên một
hệ thống cốt lõi được chia sẻ, không áp đặt bất
kỳ hạn chế nào lên sự sản xuất của các mở rộng
cục bộ.
Tuy nhiên, nếu các dự
án nguồn cộng đồng bắt đầu với một giai đoạn ban
đầu đóng, sẽ có những hạn chế được đặt ra trong
sự phát triển của các trình bổ sung (add-ons) cục bộ,
ảnh hưởng tới những người bên ngoài cộng đồng khởi
xướng. Trong giai đoạn đóng đó, chỉ các đối tác có
ràng buộc theo hợp đồng có thể thấy và sửa được
mã, hoặc đóng góp cho các thảo luận về các yêu cầu
và thiết kế. Tính năng chia sẻ có hạn chế này là cực
kỳ quan trọng, đặc biệt nếu một người đã quen với
ý tưởng rằng nguồn mở bền vững về cơ bản là về
sự phát triển của cộng đồng. Để phát triển một
cộng đồng, một người cần giúp mọi người tập hợp
xung quanh một 'cốt lõi được chia sẻ', và bằng việc
hạn chế những đóng góp sớm, nguồn cộng đồng dường
như sẽ ép các thành viên không ký hợp đồng vào 'việc
rẽ nhánh' mã (tại thời điểm mà cốt lõi chung không
còn là sẵn sàng cho việc chia sẻ nữa).
Các
cộng đồng nguồn cộng đồng có thể được so sánh với
các cộng đồng các học giả chỉ theo ý nghĩa rằng các
đối tác khởi xướng chia sẻ một hệ thống cốt lõi
giữa họ với nhau, không có sẵn sàng cho phần còn lại
của thế giới, đặc biệt khi sự tham gia rộng lớn
hơn vượt ra khỏi các ranh giới học tập đang trở nên
ngày một quan trọng ngày nay? Không giống như nguồn cộng
đồng, sự phát triển của nguồn mở là mở cho bất kỳ
ai từ ngày đầu tiên. Được xem theo ngữ cảnh này, mô
hình nguồn mở có thể là lựa chọn tốt hơn cho các
hoạt động phát triển của giới hàn lâm.
Giảm thiểu rủi
ro của các cơ quan
Ưu thế khác được
nói của nguồn cộng đồng nảy sinh từ bản chất rất
tự nhiên của nó, khi các dự án nguồn cộng đồng cơ
bản có nghĩa để điều hành các cơ quan hơn là các cá
nhân. Giai đoạn sớm các nhóm theo hợp đồng dường như
sẽ là giải pháp tài chính ít rủi ro hơn đối với các
đối tác có liên quan, khi việc chia sẻ mã được hạn
chế dường như 'an toàn hơn' so với việc mở nó cho bất
kỳ ai. Trong nhiều cơ quan, nguồn cộng đồng được ưu
tiên hơn nguồn mở vì sợ rằng nguồn mở có thể gây
ra sự thay đổi bước ngoặt không đoán trước được
của dự án hướng tới các lợi ích của những người
đóng góp không quen biết.
Tuy nhiên, mối lo này
bộc lộ một sự hiểu sai chung về nguồn mở. Các dự
án nguồn mở thực sự không mang theo một rủi ro được
gia tăng của 'việc bị cướp' bởi những người đóng
góp không quen biết. Trong các dự án nguồn mở, sự truy
cập 'đọc' đối với mã được cung cấp, cùng với
quyền để sửa đổi nó cho sử dụng cá nhân, nhưng điều
này không tạo ra sự đảm bảo rằng những thay đổi đó
sẽ được đưa vào trong nguồn của dự án. Một dự án
tư duy theo cộng đồng (community – minded) sẽ khuyến
khích những người đóng góp cung cấp những sửa đổi,
nhưng dự án không chịu trách nhiệm để đưa chúng lên
ban lãnh đạo. Một sự dịch chuyển sang nguồn mở không
nhất thiết làm giảm sự kiểm soát, trừ phi quản trị
dự án muốn nó thế. Ví dụ, Linus Torvalds vẫn là người
có thể đưa mã vào nhánh phát triển hiện hành của nhân
Linux. Đúng để viện lý rằng ông phải nghe cộng đồng,
nếu không họ sẽ tạo ra một dự án riêng rẽ, mà họ
có quyền, nhưng cộng đồng không thể ép ông nắm lấy
một đường hướng mà ông tin tưởng sẽ là không phù
hợp.
Trong thực tế, có
thể còn tranh cãi rằng có (tiềm năng) một rủi ro gia
tăng trong việc sử dụng một mô hình nguồn cộng đồng.
Hợp đồng ban đầu giữa những người cộng tác có thể
là hữu dụng để làm rõ các bổn phận của các đối
tác, nhưng các ưu tiên chiến lược của một đối tác
có thể thay đổi qua thời gian, hoặc có thể có tranh
chấp nội bộ về cách thức tốt nhất để đạt được
các mục tiêu của dự án. Dù vậy, các đối tác của dự
án sẽ tiếp tục có bổn phần theo hợp đồng để bơm
tiền vào những gì có thể hóa ra là một giải pháp ít
tối ưu hơn đối với các nhu cầu riêng rẽ của họ.
Hợp đồng ban đầu giữ cho mọi người có ràng buộc,
thậm chí trong trường hợp dự án thất bại. Trong các
dự án nguồn mở, không có bổn phận như vậy, chỉ có
sức ép của cộng đồng.
Các mô hình nguồn mở
không khóa mọi người vào các dự án. Nếu dự án là
thành công, thì kết quả là y hệt như trong kết quả dựa
vào hợp đồng, nhưng nếu thất bại, nó thất bại sẽ
nhanh, khi các đối tác nhanh chóng rút ra hoặc rẽ nhánh
các dự án một cách phù hợp. Điều này đặt ra sức ép
xã hội lên dự án phải 'làm điều đúng' cho cộng đồng
như là tổng thể hơn là cho một số lượng nhỏ các đối
tác có ảnh hưởng.
Nhóm theo hợp đồng
sớm
Vì các đối tác cơ
quan đã đóng góp các tài nguyên có nhiều hơn sức mạnh
ra quyết định, có thể tranh luận rằng những người
tham gia trong một dự án nguồn cộng đồng là không bình
đẳng. Những người bảo vệ nguồn cộng đồng bảo vệ
rằng điều này chỉ đúng cho giai đoạn ban đầu của dự
án, trong thời gian đó sự không bình đẳng như vậy
không thể tránh được. Vì nguồn cộng đồng chỉ có
thể bắt đầu với việc tổng hợp các nguồn lực lớn
của các cơ quan và sự bơm cấp vốn từ bên ngoài, điều
này là bình thường, họ nói, rằng các đối tác trong
nhóm được trao địa vị cao trước và một ưu thế gây
ảnh hưởng cho quỹ đạo ban đầu của dự án.
Tuy niên, giai đoạn
sớm này thường quan trọng hơn nhiều so với các giai
đoạn tiếp sau, và nó có thể được tranh luận rằng
bằng việc hạn chế mã và sự truy cập khi phát triển
đối với nhóm, các thành viên có tiềm năng gắn bó rộng
lớn hơn bị giới hạn và sự phát triển tự nhiên của
cộng đồng bị cản trở. Trong nguồn mở, các đối tác
có thể là ban quản lý dự án ban đầu, và những người
đó thậm chí có thể có bổn phận theo hợp đồng đối
với nhau. Sự khác biệt là trong nguồn mở, sự truy cập
tới mã và sự phát triển là mở từ ngày đầu tiên, và
nhiều đối tác hơn có thể làm việc theo cách của họ
trong dự án bằng việc bổ sung những tài nguyên mới ở
mức phù hợp cho nhu cầu của họ. Trong thực tế, càng
nhiều tài nguyên họ bổ sung vào, thì ảnh hưởng mà họ
có càng nhiều lên, khi họ chuyển từ người sử dụng
sang người đóng góp, sang người đề xuất, tới quản
lý dự án. Sức mạnh ra quyết định và tình trạng đối
tác được đo đếm theo công việc thực sự được phân
phối, là ngược lại với đầu tư tài chính.
Các dự án nguồn
cộng đồng mà đối xử với các thành viên nhóm ban đầu
như 'bình đẳng hơn' so với những người khác có thể
trong thực tế sẽ làm nản lòng những đóng góp của
những người tình nguyện. Bổ sung thêm, thỏa thuận hợp
đồng ban đầu có thể thúc đẩy những cảm nghĩ tồi
giữa các thành viên mà đã đóng góp tài chính và những
người tới sau để tham gia, khi mà nó là, 'vì tự do'.
Thậm chí các đối tác được cho là bình đẳng, thì
những thành viên của nhóm có thể cảm thấy nản lòng,
vì đã thực hiện những đóng góp đáng kể cho một dự
án trong những giai đoạn sớm, họ tiếp tục được nhìn
nhận như là có sự kiểm soát nhiều hơn từ những thành
viên mới hơn của cộng đồng. Quỹ Eclipse, ví dụ, vẫn
còn đang đấu tranh với vấn đề này, dù có số lượng
ngày một gia tăng các thành viên của các dự án của Quỹ
Eclipse mà không phải là một phần của nhóm ban đầu.
Kết luận
Nguồn cộng đồng và
nguồn mở chia sẻ các động lực tương tự nhau, nhưng
tiếp cận của chúng đối với sự phát triển là hoàn
toàn khác nhau. Trong khi các dự án nguồn mở tin tưởng
là tốt hơn để phát hành sớm và phát
hành thường xuyên, thì các dự án nguồn cộng đồng
có ý định tạo ra các sản phẩm phần
lớn là hoàn chỉnh trước khi mở ra sự truy cập cho qui
trình phát triển.
Một
số ưu thế được cho của nguồn cộng đồng, như khả
năng tích hợp gia tăng với các hệ thống khác, hoặc chi
phí thấp hơn về tư vấn và hỗ trợ, trong thực tế là
những tính năng của phát triển nguồn mở. Những tính
năng khác, như sự thích đáng đối với văn hóa của khu
vực giáo dục trong việc chia sẻ, hoặc khả năng làm
giảm nhẹ các rủi ro có liên quan tới những lợi ích
phân kỳ của những người đóng góp, dường như là khó
bền vững khi phân tích cùng với phát triển nguồn mở.
Việc
quản lý các dự án nguồn cộng đồng xuyên khắp nhóm
[cơ quan] tập trung vào giáo dục có thể rất lôi cuốn
cho các mục đích hành chính nhưng thiếu tính mở trong
các giai đoạn phát triển ban đầu có thể làm xói mòn
nghiêm trọng tiềm năng về tính bền vững của chúng.
Các bài học học được từ các dự án nguồn cộng đồng
là cực kỳ hữu dụng, và chúng sẽ được sử dụng để
phản ánh trong bản chất tự nhiên sâu hơn của phát
triển nguồn mở (bản
dịch tiếng Việt) và tác động
tiềm tàng của nó lên Giáo dục Trung học và Giáo dục
cao hơn của nước Anh.
In
traditional open source development, the software code is made
available for inspection and modification from the beginning of a
project. The contribution of independent or institutional partners
may be voluntary or may involve legally binding agreements, but
essentially everyone has equal access to the code from day one. In
contrast to open source development, in so-called ‘community
source’ projects, such as Sakai and Kuali, a consortium of
institutions or commercial companies sign an agreement whereby they
decide to contribute a certain amount of financial and/or human
resources, and get, in exchange, exclusivity in influencing the
development of the project during an initial closed stage. After this
closed period, the code can be made available to everyone, and the
development moves towards a more traditional open source model.
Community
source
is described in another OSS Watch briefing note. This document
compares the community source and open source development models, and
discusses their suitability for consortia of Higher Education
institutions.
The
distinction between open source and community source is not easy to
make, mainly because the two terms are often used inappropriately. On
closer inspection, many of the claimed advantages of the so-called
community source model actually refer to general features of open
source development. Particularities such as the increased capacity
for integration with other systems, the lower cost of consultancy and
support, and the improved staff development and knowledge sharing
skills, are ultimately consequences of opening up access to the
software code and development. Both models provide alternative
revenue generating solutions that challenge traditional commercial
practices based on selling licences for the use of software.
It
is possible to find models similar to community source within the
open source environment. For example, some projects opt to launch in
a so-called ‘stealth mode’, that is, they operate as a truly open
source development from inception, but restrict marketing information
about the project during the early stages. This has the effect of
permitting access to anyone who cares enough to discover the project,
whilst at the same time allowing the initiating members to maintain a
focus on early strategic objectives, rather than community
development.
One
claimed feature of the community source model concerns its
suitability for the Higher and Further Education market. From a
cultural perspective, community source is often described as a
perfect fit with the ethos and values of education and research,
traditionally associated with intellectual innovation and the sharing
of knowledge among scholars. As in traditional scholarly communities,
community source development allegedly builds on a shared core
system, without imposing any restrictions on the production of local
extensions.
However,
if community source projects begin with an initial closed period,
there are restrictions placed on the development of local add-ons
affecting those outside the initial community. During the closed
period, only the contractually bound partners can see and modify the
code, or contribute to discussions about requirements and design.
This restricted sharing feature is extremely important, especially if
one is familiar with the idea that sustainable open source is
essentially about community development. In order to develop a
community, one needs to help people congregate around a ‘shared
core’, and by restricting early contributions, community source
appears to force non-contractual members into ‘forking’ the code
(at which point no common core is available for sharing anymore).
Community
source communities can be compared with scholarly communities only in
the sense that the initial partners share a core system among
themselves, unavailable to the rest of the world. The claim that
community source is the most suitable development model for the
education sector is based on the assumption that collaboration in
education comprises sharing information among specialist circles of
academics. But can academic collaboration be perceived in isolation
from the rest of the world, especially as wider engagement beyond
scholarly confines becomes increasingly important today? Unlike
community source, open source development is open to everyone from
day one. Seen in this context, the open source model could be a
better choice for academic development activities.
Another
claimed advantage of community source arises from its very nature, as
community source projects are essentially meant to coordinate
institutions rather than individuals. The early-stage contractual
consortium appears to be a less risky financial solution for the
partners involved, as the restricted sharing of the code seems
‘safer’ than opening it to everyone. In many situations,
community source is preferred over open source for fear that the
latter may result in unpredictable veering of the project towards the
interests of unknown contributors.
However,
this anxiety reveals a common misconception about open source. Open
source projects do not actually carry an increased risk of being
‘hijacked’ by unknown contributors. In open source projects,
‘read’ access to the code is provided, along with a right to
modify it for personal use, but this does not result in a guarantee
that these changes will be included in the project source. A
community-minded project will encourage contributors to supply
modifications, but the project is under no obligation to take them on
board. A move to open source does not necessarily reduce the control,
unless the project management wants it to. For instance, Linus
Torvalds is still the only person who can put code into the current
development branch of the Linux kernel. It is true to argue that he
has to listen to the community, otherwise they will create a separate
project, as is their right, but the community cannot force him to
take a direction he believes to be inappropriate.
In
fact, it can be argued that there is (potentially) an increased risk
in using a community source model. The initial contract between
collaborators may be useful for clarifying the partners’
obligations, but the strategic priorities of a partner may change
over time, or there may be internal dispute over the best way to
achieve the project objectives. Nevertheless, the project partners
will continue to be contractually obliged to pump money into what may
turn out to be a less than optimal solution for their individual
needs. The initial contract keeps people tied, even in the case of a
failing project. In open source projects, there is no such
obligation, only community pressure. Open source models do not lock
people into projects. If the project is successful, the outcome is
the same as in a contract-based one, but if it fails, it fails fast,
as partners can quickly pull out or fork the projects as appropriate.
This puts social pressure on the project to ‘do the right thing’
for the community as a whole rather than for a small number of
influential partners.
Since
institutional partners that have contributed resources have more
decision making power, it can be argued that the participants in a
community source project are not equal. Community source advocates
maintain that this is only true for the initial stage of the project,
during which time such inequality cannot be avoided. Since community
source can only start off with large institutional pooling of
resources and the injection of external funds, it is normal, they
say, that the consortium partners are given pre-eminence and an
opportunity to influence the initial trajectory of the project.
However,
this early stage is often far more important than the subsequent
ones, and it can be argued that by restricting code and development
access to the consortium, members the potential for wider buy-in is
limited and the natural development of the community is hampered. In
open source, the partners would be the initial project management
committee, and these people may even be contractually obligated to
one another. The difference is that in open source, access to the
code and development is open from day one, and more partners can work
their way into the project by adding new resources at a level
appropriate to their need. In practice, the more resources they add,
the more influence they get, as they move from user to contributor,
to committer, to project management. Partner status and decision
making power are measured in terms of actual work delivered, as
opposed to financial investment.
Community
source projects that treat early consortium members as ‘more equal’
than others may in reality be discouraging volunteer contributions.
Additionally, the initial contractual agreement may foster bad
feelings between the members who have contributed financially and
those who have come on board late in order to participate, as it
were, ‘for free’. Even when the partners are considered equal,
the consortium members may feel frustrated, as having made
significant contributions to a project in the early stages, they
continue to be perceived as having more control by the newer members
of the community. The Eclipse Foundation, for instance, is still
struggling with this issue, although there is an increasing number of
members on Eclipse Foundation projects who were not part of the
original consortium.
Community
source and open source share similar motivations, but their approach
to development is quite different. While open source projects believe
it is better to release early and release often, community source
projects attempt to create largely complete products before opening
up access to the development process.
Some
of the claimed advantages of community source, such as increased
capacity for integration with other systems, or lower cost of
consultancy and support, are in fact general features of open source
development. Other features, such as appropriateness to the education
sector’s culture of sharing, or the ability to mitigate risks
associated with divergent interests of contributors, appear difficult
to sustain when analyzed alongside open source development.
Running
community source projects across education focused consortia can be
very appealing for the purposes of administration, but the lack of
openness during the initial stages of development can seriously
undermine their sustainability potential. The lessons learned from
community source projects are extremely useful, and they should be
used to reflect on the deeper nature of open
source development and its potential impact upon UK Higher and
Further Education.
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.