This article is part of The Comprehensive Guide to Open Source for Business., and was originally posted on the Samsung Open Source Group blog.
Open source communities are as complex as the diverse individuals that contribute to them, and there is no one-size-fits-all definition of how they operate. With that said, there are a lot of common fundamental practices and organizational strategies that many communities migrate towards. This article will provide a general definition of how open source communities are organized and operate in order to provide greater context for the rest of the guide.
New definitions
- Open Source – Denotes software for which the original source code is made freely available and may be modified and redistributed.
- Upstream (noun) – The originating open source software project upon which a derivative is built.
- Maintainer (Committer) – An individual who is responsible for organizing code into source repositories, committing patches, and building the source code into binary packages for distribution.
Community Organization
Open source communities are generally inclusive by default, and are exclusively transparent because the strength of an open source community depends heavily on attracting the right contributors. Newcomers are welcome to participate in public discussions, development, and testing, and community leadership is granted to those that are the most valuable.
Distributed Contributors with Differing Motivations
Open source communities often include contributors from many cultures, distributed across the globe, who speak many languages. Because of this, communication channels are designed to reduce the impact of language barriers and to be used across disparate timezones. Some of these people are volunteers, while others are making contributions on behalf of their employer. Everyone will have their own set of motivations for their contributions and will align themselves with people who share them; this will bring individuals from various companies together to collaborate and even has the potential to result in competitors working together towards a common goal.
Self-Organizing Meritocracy
Open source communities are almost entirely meritocratic. Reputation in an open source community is gained by making valuable contributions to the project, and leadership in these communities must be earned through experience. Reputation in one project does not necessarily translate to reputation in another, and internal reputation with a company doesn’t translate to open source communities. Individuals of any skill level can have their code rejected based on a multitude of reasons.
In an open source community, responsibilities are given to the individuals or teams that have the best capacity to deliver. These individuals are guided by their own internal motivations in a self-organizing development process. If individuals cease to participate, there are often others to step in and take their place, but only if they have similar motivations. Code can live forever, even after a maintainer departs; this helps make open source communities more resilient to organizational change.
Scalable Hierarchy
Typically, open source communities are structured in a tight, vertical hierarchy with individual maintainers that manage a single body of code, or the entire project. As the project grows, it is common for it to be divided into subsystems and for the releases to become more organized and standardized. The largest projects often establish sub-maintainers and have multiple contributors that work with them on reviews. This design allows open source communities to be exceptionally scalable because hierarchy levels can be added and removed as needed, based on the size of the community. Ultimately, from an organizational perspective the open source software development model is not very different from traditional, large-scale software development.
After contributor-submitted code goes through the review process, it must then be accepted by a subsystem maintainer. If accepted, it will be passed on to the next level of maintainers who will go through their own review process. Code that is accepted into a major release of a large open source project will ultimately filter through several layers of maintainers, and each line of code that is accepted has a clear audit trail.
Foundations, Advisory Boards, and Working Groups
Some code is too important to be tied to a single host, this is where foundations, advisory boards, and community groups come in to provide the expertise, guidance, and facilitation that is needed to execute a large-scale open source software development projects. Smaller communities are not likely to have formalized organizations like these, but as projects grow and gain more diverse stakeholders, foundations, advisory boards, and working groups become much more critical to ensuring the community remains vibrant.
The Neutral Role of Foundations
The fundamental purpose of a foundation is to be a neutral facilitator that brings experience and credibility to a project. They are typically 501(c)3 or 501(c)6 non-profit organizations that are supported by membership dues and/or donations. A foundation can serve as a neutral host of software projects and help preserve important software that needs to remain neutral, like de-facto standards and core infrastructure. A good foundation will provide knowledge and expertise through staff in addition to services that are tailored to the project, like IT infrastructure, marketing, developer and user resources, and more.
Recent history has shown that the industry values neutrality, and a foundation can help with multi-party arrangements by serving as a single place to manage legal agreements and foster trust. Foundations foster trust by appointing unbiased decision makers, ensuring the project remains around despite industry changes, making the code valuable enough to justify investing R&D budget, and by making the intentions of all participants visible. This trust allows participants to make long-term, strategic commitments and form development alliances. It also encourages participants to contribute features that make the project more valuable than its competitors.
Guiding the Project with Advisory Boards and Working Groups
The self-organizing nature of open source communities results in leadership coming from a wide range of individuals. Community groups like advisory boards and working groups provide guidance on certain areas and can be arranged in a very formal manner with clear policies, rules, and guidelines, or they can be ad-hoc, temporary efforts.
Advisory boards commonly guide a project on technical, social, and political matters, and they help identify and resolve issues before they become problems. Members are typically established through elections, and advisory boards consist of some of the most well-respected community members who have a long history of project contributions and good connections within the community. These connections are vital because they allow board members to find the people needed to solve problems.
Working groups are established to solve specific problems with legal, technical development, community policy, and more. They can be formed with a defined endpoint if their purpose is to implement specific functionality or to prepare something for a specific event like a version release or community event. In formal scenarios, working groups typically receive tasks from the advisory board, and their job is to make sure the tasks are completed.
Coming Up Next: Understanding the Open Source Development Model
An open source community can seem quite hectic based on the diversity of a typical community. However, the distributed, self-organizing, meritocratic community model that is commonly formed around successful open source projects has proven itself to be very resilient and capable of producing great code at a massive scale. The first step in understanding what it takes to contribute to an open source project is understanding how the community that powers it operates, and this article should have provided you with a clear starting point for this understanding.
Now that we have established a general definition of an open source community, the next article in this guide will focus on the open source development model. It will introduce the open source development process and explain how it differs from traditional software development models. Additionally, it will provide an overview of how code is submitted, reviewed, tested, implemented, and released in most open source projects, and how the community makes decisions about which code to accept.
