Four ways to organize as an open source community
Four types of open source communities
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 create 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 create 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.
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 from 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 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 created 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 create 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).