4 dạng các cộng đồng nguồn mở

Four types of open source communities

Posted 10 Jun 2013 by Matthias Stürmer

Theo: http://opensource.com/business/13/6/four-types-organizational-structures-within-open-source-communities

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

Lời người dịch: Bổ sung cho các bài nói về cộng đồng nguồn mở của OSS Watch trên blog, bài viết này phân ra 4 loại cộng đồng nguồn mở thường thấy hiện nay trên thế giới và những đặc thù của nó. Một trong những đặc thù của một dạng cộng đồng mà có lẽ hiện nay ở Việt Nam nhiều người sẽ thấy rất xa lạ với mô hình phát triển phần mềm nguồn đóng, xin được trích ra ở đây khi nói về cộng đồng những người sử dụng: “Các cộng đồng người sử dụng là tương tự với các cộng đồng các lập trình viên theo cách là sự kiểm soát được phân tán giữa những người tham gia đóng góp khác nhau. Tuy nhiên, trong các cộng đồng người sử dụng và các tổ chức của người sử dụng đầu cuối sản phẩm phần mềm đó sở hữu bản quyền của phần mềm. Phần mềm hoặc từng được phát triển nội bộ ở một người sử dụng phần mềm và sau đó nó đã được phát hành như là phần mềm nguồn mở. Hoặc phần mềm đó đã được tạo ra dưới một giấy phép nguồn mở như là công việc theo hợp đồng của một nhà cung cấp bên ngoài. Trong cả 2 trường hợp thì những người sử dụng phần mềm đó là những người chủ sở hữu sản phẩm phần mềm đó, nhà cung cấp đưa ra các dịch vụ cho sản phẩm phần mềm đó nhưng không sở hữu mã nguồn. Việc sở hữu bản quyền mã đó cho phép những người sử dụng định nghĩa dạng giấy phép nguồn mở”.

Phần mềm nguồn mở (PMNM) không chỉ là về lập trình viết mã nguồn. Tồn tại một lượng lớn các cấu trúc tổ chức khác nhau tạo thuận lợi cho sự phát triển và thăng hoa của PMNM. Trong bài báo này, tôi giải thích các dạng tổ chức chính bên trong cộng đồng nguồn mở.

Tôi phân biệt giữa:

• Các dự án nguồn mở một nhà cung cấp duy nhất

• Các cộng đồng phát triển

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

• Các trung tâm năng lực nguồn mở

4 dạng đó của các tổ chức đại diện cho các mẫu tổ chức cơ bản, và những biến thể và quá độ giữa chúng là rất phổ biến.

Các dự án nguồn mở một nhà cung cấp duy nhất

Các công ty thường phát triển phần mềm trong nội bộ và cuối cùng, vì bất kỳ lý do gì, phát hành sản phẩm dưới một giấy phép nguồn mở. Họ sở hữu bản quyền đầy đủ của phần mềm vì thế kéo theo mô hình cấp phép đôi. Điều này bao gồm việc xuất bản phần mềm theo một giấy phép và cùng với việc bán sản phẩm thông qua các giấy phép sở hữu độc quyền cổ điển. Công ty chắc chắn để lại chỉ là người nắm giữ bản quyền bằng việc để cho những người đóng góp bên ngoài ký các thỏa thuận giấy phép của người đệ trình (committer) hoặc người đóng góp (contributor). Các hợp đồng đó chuyển giao bản quyền của mã nguồn được đóng góp và các tài sản bổ sung cho hãng phần mềm dẫn dắt dự án nguồn mở đó.

Mục tiêu ban đầu của các dự án nguồn mở đó là bán các giấy phép sở hữu độc quyền ở phạm vi toàn cầu. Giành được những người đóng góp từ bên ngoài là thách thức vì việc bỏ các quyền sở hữu trí tuệ cho hãng dẫn dắt đưa ra ít động lực cho các lập trình viên phần mềm bên ngoài. Dù thực tế đã chứng minh rằng thậm chí các dự án nguồn mở một nhà cung cấp duy nhất có khả năng xây dựng một cộng đồng nguồn mở. Tôi xem xét các dự án như MySQL của Oracle, Openbravo ERP của Openbravo ..S.L., Magnolia CMS của Magnolia Inc., hoặc Alfresco DMS của Alfresco Inc. như các dự ansn nguồn mở một nhà cung cấp duy nhất thành công về sự áp dụng trong thị trường tương ứng của chúng. Thông qua các hội nghị các lập trình viên được công ty dẫn dắt, các chương trình đối tác, và các hoạt động xây dựng cộng đồng khác, các công ty đó đã xoay xở để tạo ra một lượng đáng kể thị phần.

Một số người chỉ trích nói rằng các dự án nguồn mở một nhà cung cấp duy nhất đó không thực sự là các dự án nguồn mở vì có một công ty duy nhất đứng đằng sau chúng kiểm soát toàn bộ cộng đồng. Như trong phần mềm sở hữu độc quyền thi điều này có thể dẫn tới sự khóa trói vào nhà cung cấp và vì thế vào một sản phẩm không bền vững. Tôi đồng ý rằng những người sử dụng tạo ra những phụ thuộc với công ty dẫn dắt thậm chí nếu họ không quyết định mua phiên bản chuyên nghiệp.

Tuy nhiên, vì mã nguồn y hệt được làm cho sẵn sàng bên dưới một giấy phép nguồn mở nên luôn có sự tồn tại khả năng đối với những người sử dụng hoặc các lập trình viên không hạnh phúc lấy mã đó, tạo lại thương hiệu cho nó và bắt đầu một dự án nguồn mở mới. Cái gọi là việc rẽ nhánh này của các dự án nguồn mở đã xảy ra nhiều lần trong quá khứ. Như hiện nay đang tồn tại vài rẽ nhánh của MySQL được gọi là MariaDB, OurDelta, hoặc XtraDB. Cũng vậy với hệ thống ERP nguồn mở Compiere do Compiere Inc. dẫn dắt từng bị rẽ nhánh vào năm 2006 thành dự án nguồn mở mới ADempiere. Điều này chứng minh rằng thậm chí các dự án nguồn mở bị kiểm soát từ một nhà cung cấp duy nhất như vậy là bền vững nếu một phần đáng kể của cộng đồng các lập trình viên tích cực quyết định đi tiếp với một dự án nguồn mở mới.

Các cộng đồng các lập trình viên

Các dự án nguồn mở được các cộng đồng các lập trình viên quản lý đại diện cho dự án nguồn mở điển hình. Chúng hoặc được một cá nhân hoặc một tổ chức như một công ty phần mềm, một cơ quan nhà nước hoặc một trường đại học khởi xướng. Thông qua những đóng góp từ các nguồn khác nhau mã nguồn của dự án nguồn mở đó được nhiều người tham gia đóng góp sở hữu. Những người đóng góp tham gia vào qui trình phát triển vì những động lực đa dạng và đi theo các mục tiêu khác nhau. Một số lập trình viên đã tham gia vì các động lực về lý tưởng hoặc khác của bản thân. Một số lập trình viên đóng góp vì họ cần phần mềm cho bản thân họ hoặc vì họ muốn học thứ gì đó. Hoặc họ tham gia trong cộng đồng vì họ được thuê trong một công ty nguồn mở hoặc vì họ sở hữu một doanh nghiệp CNTT đang phục vụ các khách hàng.

Dự án nguồn mở đó có thể được tổ chức như một cộng đồng đơn nhất như LibreOffice bên trong Quỹ Tài liệu (The Document Foundation) hoặc hệ thống quản trị nội dung TYPO3 trong Hội TYPO3. Hoặc dự án đó có thể là một phần của một hội nguồn mở lớn hơn với các dự án nguồn mở khác nhau khác được một quỹ hoặc cơ quan pháp lý khác điều hành. Các ví dụ là Quỹ Linux (Linux Foundation), Apache Foundation, Mozilla Foundation, hoặc cộng đồng Debian. Các cộng đồng các lập trình viên đó được tổ chức theo các cách thức rất khác nhau đi theo các chuẩn mực và qui tắc riêng rẽ. Chúng có điểm chung là sự kiểm soát dự án thường được phân tán trong những người đóng góp chính (được gọi là chế độ người tài lãnh đạo) và rằng bản quyền của phần mềm được chia sẻ trong những người tham gia đóng góp khác nhau. Vì thế sự kiểm soát được chia sẻ. Không có thực thể thương mại duy nhất nào có thể quyết định, như về qui trình phát hành, lộ trình của các tính năng, hoặc dạng giấy pép nguồn mở.

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

Các cộng đồng người sử dụng là tương tự với các cộng đồng các lập trình viên theo cách là sự kiểm soát được phân tán giữa những người tham gia đóng góp khác nhau. Tuy nhiên, trong các cộng đồng người sử dụng và các tổ chức của người sử dụng đầu cuối sản phẩm phần mềm đó sở hữu bản quyền của phần mềm. Phần mềm hoặc từng được phát triển nội bộ ở một người sử dụng phần mềm và sau đó nó đã được phát hành như là phần mềm nguồn mở. Hoặc phần mềm đó đã được tạo ra dưới một giấy phép nguồn mở như là công việc theo hợp đồng của một nhà cung cấp bên ngoài. Trong cả 2 trường hợp thì những người sử dụng phần mềm đó là những người chủ sở hữu sản phẩm phần mềm đó, nhà cung cấp đưa ra các dịch vụ cho sản phẩm phần mềm đó nhưng không sở hữu mã nguồn. Việc sở hữu bản quyền mã đó cho phép những người sử dụng định nghĩa dạng giấy phép nguồn mở.

Người sử dụng các sản phẩm nguồn mở tạo nên các cộng đồng người sử dụng vì họ muốn nắm giữ sự kiểm soát chiến lược của các hệ thống cốt lõi của họ và vì họ muốn chia sẻ các chi phí phát triển và duy trì với những người khác. Có một kho người sử dụng rộng lớn của một sản phẩm phần mềm nguồn mở cũng có thể dẫn tới những đóng góp từ bên ngoài như làm tài liệu, các bản dịch, sửa các lỗi, các trình mở rộng và cuối cùng sự phát triển của các thành phần cốt lõi. Trong vai trò của họ như là những người sử dụng phần mềm thì hoạt động chính của cộng đồng đó là xác định các yêu cầu chung và triển khai chúng hoặc bằng sự phát triển trong nội bộ, hoặc bằng việc hợp đồng với các công ty bên ngoài. Một ví dụ về một cộng đồng như vậy là Liên minh GENIVI, một nhóm các nhà sản xuất ô tô (BMW, Renault, GM, Honda, Jaguar …) và các nhà cung cấp (Continental, Bosch, Pioneer, …) đang phát triển một sự giải trí bằng tin học nguồn mở trong các xe cộ. Hoặc hãng tái bảo hiểm MunichRe và Allianz ART Insurance đang xây dựng bộ Quản lý Rủi ro Chuyên nghiệp (ERM) PillarOne.

Một ví dụ khác là Quỹ Kuali tại Mỹ. Có khoảng 70 thành viên cộng đồng người sử dụng này, chủ yếu là các trường đại học lớn của Mỹ đang sử dụng các giải pháp nguồn mở để quản lý các khu học đường của họ. Tại Thụy Sỹ đang tồn tại nền tảng OpenJustitia được Tòa án Tối cao Liên bang Thụy Sỹ thành lập để làm tài liệu và nghiên cứu các quyết định trước đó của tòa án, các luật và các cơ sở dữ liệu pháp lý khác.

Các trung tâm năng lực nguồn mở

Dạng thứ 4 các tổ chức nguồn mở đang tồn tại với nhiều dạng khác nhau các trung tâm năng lực nguồn mở. Chúng hành động như là các nền tảng trung lập về sản phẩm và nhà cung cấp với mục tiêu tạo thuận lợi cho sử dụng phần mềm nguồn mở trong các cơ quan nhà nước, các công ty tư nhân, các tổ chức phi chính phủ NGO, … Các trung tâm năng lực nguồn mở lấp khoảng trống giữa những người sử dụng phần mềm, các nhà cung cấp CNTT và các thành viên cộng đồng nguồn mở độc lập.

Vì các hoạt động mà một trung tâm năng lực nguồn mở thường tổ chức các hội nghị và hội thảo, cung cấp các dịch vụ tư vấn cho các cơ quan hành chính và các doanh nghiệp, và phát tiển các xuất bản phẩm và tài liệu nghiên cứu về nguồn mở. Hơn nữa các trung tâm năng lực nguồn mở thường tạo ra các danh mục các công ty và các ủy nhiệm nguồn mở, xây dựng và quản lý các nền tảng thông tin về tri thức và kinh nghiệm nguồn mở, và bảo vệ sử dụng và phát hành nguồn mở trong các tổ chức và quan điểm chính trị nguồn mở.

Trung tâm năng lực nguồn mở cũng có thể giải quyết thách thức về các vấn đề hành động tập thể trong các cộng đồng nguồn mở: thường tồn tại các nhu cầu chung ở một dải rộng lớn những người sử dụng nguồn mở vì sự tiến bộ của phần mềm đó. Tuy nhiên, vì không có thực thể thương mại duy nhất nào mà thu thập ít nhưng vô số sự cấp vốn của những người sử dụng, không có gì thay đổi. Một trung tâm năng lực nguồn mở có thể phối hợp các hoạt động phát triển của các nhu cầu nhất định của người sử dụng bằng việc xác định các yêu cầu chung, lôi kéo các tài nguyên và mua sắm giải pháp của một nhà cung cấp cho vấn đề đó.

Các trung tâm năng lực nguồn mở được quản lý thành công tồn tại khắp thế giới. Tổ chức khởi xướng, cấu trúc thành viên, các hoạt động, kích cỡ và việc cấp vốn … có thể khác nhau. Tuy nhiên, chúng tất cả đều làm việc với mục tiêu chung để cải thiện môi trường và các điều kiện chung để sử dụng và phát triển các phần mềm nguồn mở. Các trung tâm năng lực nguồn mở như vậy có thể thấy được, ví dụ, ở Thụy Sỹ (Nhóm người sử dụng các Hệ thống Nguồn Mở - Swiss Open Systems User Group /ch/open), tại Đức (Liên minh Doanh nghiệp Nguồn Mở - Open Source Business Alliance), tại Tây Ban Nha (CENATIC), tại Pháp (Adullact), tại Anh (OSS Watch), tại Nauy (Friprog), và tại châu Âu nói chung (Diễn đàn Mở châu Âu - Open Forum Europe).

Open source software is not only about programming code. There exist a vast amount of different organizational structures that facilitate the development and diffusion of open source software. In this article, I explain the main types of organizations within the open source community.

I distinguish between:

• single vendor open source projects

• development communities

• user communities

• open source competence centers

These four types of organizations represent basic organizational patterns, and variations and transitions between them are very common.

Single vendor open source projects

Often companies develop software in-house and eventually, for whatever reason, release the product below an open source license. They own the full copyright of the software thus are entitled to follow e.g. a dual-licensing model. This includes publishing the software under an open source license on the one side and selling the product through classical proprietary licenses on the other side. The company makes sure to remain the only copyright holder by letting external contributors sign committer or contributor license agreements. These contracts transfer the copyright of the contributed source code and additional assets to the software firm leading the open source project.

The primary goal of these open source projects are the sales of proprietary software licenses on a global scale. Gaining external contributors is challenging since giving up intellectual property rights to the leading firm provides little incentive to external software developers. Nevertheless reality has proven that even single vendor open source projects are able to build an open source community. I consider projects such as MySQL by Oracle, Openbravo ERP by Openbravo S.L., Magnolia CMS by Magnolia Inc., or Alfresco DMS by Alfresco Inc. as successful single vendor open source projects in terms of adoption within their respective market. Through company-lead developer conferences, partner programs, and other community building activities these companies managed to cre-ate a substantial amount of market share.

Sometimes critical people state that these single vendor open source projects are not real open source projects since there is a single company behind them controlling the entire community. As in proprietary software this may lead to vendor lock-in and thus an unsustainable product. I agree that users cre-ate dependencies with the leading company even if they don't decide to buy the enterprise version.

However, since the identical source code is made available below an open source license there always exists the ability for unhappy users or developers to take the code, rebrand it and start a new open source project. This so called forking of open source projects has happened many times in the past. E.g. currently there exist several forks of MySQL called MariaDB, OurDelta, or XtraDB. Also the open source ERP system Compiere lead by Compiere Inc. was forked in 2006 into the new open source project ADempiere. This proves that even such single vendor controlled open source projects are sustainable if a substantial part of the active developer community decides to move on with a new open source project.

Developer communities

Open source projects managed by developer communities represent the typical open source project. They were either initiated by an individual or by an organization such as a software company, a public administration, or a university. Through contributions f-rom various sources the source code of the open source project is owned by multiple stakeholders. The contributors participate in the development process because of diverse motivations and follow different goals. Some programmers are involved because of ideological or other intrinsic motives. Some developers contribute because they need the software for themselves or because they want to learn something. Or they participate in the community because they are employed at an open source company or because they own an IT enterprise serving clients.

The open source project may be organized as a single community such as LibreOffice within The Document Foundation or the content management system TYPO3 within the TYPO3 Association. Or the project may be part of a greater open source association with various other open source projects governed by a foundation or other legal institution. Examples are the Linux Foundation, the Apache Foundation, the Mozilla Foundation, or the Debian community. Such developer communities are organized in very different ways following individual rules and norms. They have in common that the control of the project is usually distributed among the main contributors (called meritocracy) and that the copyright of the software is shared among various stakeholders. Thus control is shared. There is no single commercial entity that may decide e.g. about the release process, feature road map, or the type of open source license.

User communities

User communities are similar to developer communities in the way that control is distributed among various stakeholders. However, in user communities the end user organizations of the software product own its copyright. The software was either developed internally at a software user and then it was released as open source software. Or the software was cre-ated below an open source license as contract work by an external vendor. In either case the software users are the owners of the software product, the vendor provides services for the open source product but does not own the source code. Owning the copyright of the code allows users to define the software's type of open source license.

Users of open source products form user communities because they want to keep strategic control of their core systems and because they want to share the development and maintenance costs with others. Having a broad user basis of an open open source software product also may lead to external contributions such as documentation, translations, bug fixes, extensions, and eventually development of core components. In their role as software users the main activity of the community is to define common requirements and implement them either by in-house development or by contracting external companies. An example of such a user community is the GENIVI Alliance, a group of car manufacturers (BMW, Renault, GM, Honda, Jaguar etc.) and suppliers (Continental, Bosch, Pioneer etc.) developing an open source in-vehicle infotainment. Or the re-insurance MunichRe and Allianz ART Insurance building the Enterprise Risk Management (ERM) suite PillarOne.

Another example is the Kuali Foundation in the U.S. There are around 70 members of this user community, mostly large U.S. universities using the open source solutions for their campus management. In Switzerland there exists the OpenJustitia platform founded by the Federal Supreme Court of Switzerland to document and research previous court decisions, laws, and other legal databases.

Open source competence centers

As a fourth type of open source organizations there exist various forms of open source competence centers. They act as vendor- and product-neutral platforms with the goal to facilitate the use of open source software in public institutions, private companies, NGOs, etc. Open source competence centers close the gap between software users, IT providers, and independent open source community members.

As activities an open source competence center typically organizes conferences and workshops, provides consulting services for administrations and businesses, and develops research studies and publications about open source. Furthermore open source competence centers often cre-ate directories of open source firms and credentials, build up and manage information platforms about open source knowledge and experience, and the advocate the use and release of open source in government organizations and politics.

Open source competence center may also solve the challenge of collective action problems within open source communities: Often there exist common needs at a broad range of open source users for improvement of the software. However, since there is no single commercial entity that collects the little but numerous funding of the users, nothing changes. An open source competence center may coordinate development activities of certain user needs by defining the common requirements, pooling the resources, and procuring a vendor solution to the problem.

Successfully managed open source competence centers exist all over world. The initiating organization, the membership structure, the activities, size and funding etc. may vary. However, they all work with the common goal of improving the environment and general conditions to use and develop open source software. Such open source competence centers can be found for example in Switzerland (Swiss Open Systems User Group /ch/open) , in Germany (Open Source Business Alliance), in Spain (CENATIC), in France (Adullact), in UK (OSS Watch), in Norway (Friprog), and in Europe in general (Open Forum Europe).

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com