Nguồn cộng đồng vs nguồn mở

Community source vs open source

By Gabriel Hanganu, Published: 25 August 2008, Reviewed: 13 March 2012

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

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ở 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 đượ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ở 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 f-rom 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 f-rom 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 whe-reby 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.

Confused terminology

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 al-ternative 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 f-rom 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.

A cultural model for education?

One claimed feature of the community source model concerns its suitability for the Higher and Further Education market. F-rom 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 f-rom 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 f-rom day one. Seen in this context, the open source model could be a better choice for academic development activities.

Mitigating institutional risk

Another claimed advantage of community source arises f-rom 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 cre-ate 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.

Early contractual consortium

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 f-rom 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 f-rom 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.

Conclusion

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 cre-ate 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 f-rom 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

letrungnghia.foss@gmail.com