The Business Obligations of Open Source Software

This article is a part of a series on using open source in business:

The previous two articles in this series covered the technical and business benefits OSS offers. However, this only paints half the picture. While OSS might be free to use, modify, and distribute, it doesn’t come without effort and risk; if a company isn’t prepared to handle them, they can cause significant headaches down the road. This article will provide an overview of the obligations and risks a company that uses OSS in their products or services must be aware of.

Licensing and Compliance

While OSS has no initial licensing costs, this doesn’t always mean you’re free to use OSS however you want. Open source licenses can impose a range of obligations that must be satisfied whenever code that includes OSS is distributed in a product or service. This can include things like disclosure requirements, specific notifications, and licensing modifications under the same open source license.

At the very least, all businesses need to maintain an accurate inventory of all OSS that’s used in their products or services, and must have adequate processes to ensure compliance with all licenses both during and after product distribution. Typically, a single person is assigned the responsibility of being the open source compliance manager to oversee the execution of this, and it requires coordination between legal, engineering, human resources, and the compliance officer; larger companies often need to establish an Open Source Review Board to facilitate this coordination.

The most critical coordination is between product, engineering, and management teams: they must identify all OSS used in product code and to assist with any licensing or compliance questions. This often means employee roles need to be expanded to cover the various elements of OSS compliance that directly relate to each position. This coordination must also expand outside the company to include software providers as well because any OSS that’s included in the software they provide must also be properly accounted for and complied with. While establishing a framework for this coordination, it’s common to come across areas that need better tooling which creates more need for deployment and training.

Open source licensing can create substantial obligations, especially in larger organizations, and these obligations require more coordination between various teams. This article only briefly touches on the subject of open source compliance, and if you’re interested in this subject more there is a lot of detailed information on the web.

Training and Development

Training is a critical component of open source engineering because you’ll need to train developers, legal, software procurement, quality assurance, systems administrators, and others on the obligations of open source compliance. Additionally, you might need training for developers that have little to no experience working with an open source community on how open source development works.

Maintenance and Support

Proprietary software typically includes some level of paid support from the vendor company, which may include an SLA, pre-disclosure of vulnerabilities, or implementation support.  This is generally contractually enforceable, and it’s reasonable to demand responsiveness from the vendor in line with your support contract.  Similar support for OSS projects may be offered by companies participating in the ecosystem, but it is rare to find unpaid guaranteed support from the development community itself.  As most of the participants are either working on their own time or on behalf of an employer, it is neither reasonable nor fair to expect the same level of service as provided by a paid vendor.  As such, it may be the case where businesses that incorporate unpaid OSS into their products are responsible for installing updates and implementing security fixes and new modules themselves.  These tasks are easy to push aside in favor of more pressing issues, but they must be addressed nonetheless because a lack of maintenance can rapidly overcome the benefits of incorporating externally developed code.

To reiterate, OSS does not include any sort of support contract unless it is specifically negotiated with a third-party company that offers these services.  The most common OSS licenses specifically include a disclaimer of warranty.  If a business requires 24/7 support for services that use OSS, this will either need to be negotiated with an appropriate third-party company or the team will need to be hired in-house. Support services are a critical, but often overlooked, investment when using OSS.

Application Dependence

OSS can be a great avenue to avoid proprietary software dependence, but that doesn’t mean it’s a simple process to migrate away from OSS that no longer meets the requirements of a company. Whenever OSS is used for business-critical applications, the business becomes dependent on the community and project.  Changes that go against the interests of the business could result in the company needing to migrate to an alternative. The effort required to make this switch can vary widely depending on the availability of expertise and the maturity of the projects being migrated between. OSS community support can mitigate this problem, but this also varies substantially from project to project.  In general, it is considered a best practice to be actively engaged with and support select OSS communities to reduce the risk of unexpected changes to critical components.

Strategic Dependence

Open source leadership can bring substantial benefits to companies that properly leverage it, but the independent nature of open source communities can complicate strategic decisions. For starters, open source community choices may preclude downstream requirements, particularly if a company does a poor job of communicating with the upstream community.  This can introduce added effort to maintain downstream products. Additionally, if the community doesn’t have a formal technical roadmap, planning can become much more complicated. Finally, all software whether open or proprietary fits onto a spectrum of maturity, and this can often reflect the needs of a community.  For example, software developed for home use or for academic research may require some level of investment to meet product security requirements.

Do the Benefits of Open Source Outweigh the Obligations?

This article should have provided you with a general understanding of what obligations and risks are associated with the use of OSS in a product or service. There is no one-size-fits-all solution for whether a company should use OSS or simply buy software from a proprietary vendor, so it’s always important for any business that’s considering the use of OSS to consider their own specific requirements.  However, the overwhelming trend in the industry has been in favor of OSS components wherever possible, particularly in consumer electronics.

Here are some questions all businesses should ask themselves when considering the use of OSS in products.

  • How do the platform costs of OSS compare to similar offerings?
  • What commercial support offerings are available?
  • What license obligations does the code have? Does our company have the resources to fill them?
  • Who are the key individuals and organizations in the open source community? How long have they been around?
  • Do the open source community goals and roadmap meet our risk profile?
  • Does our company have adequate resources to support the use of OSS in our products?

 

The Business Value of Open Source Software

This article is a part of a series on using open source in business:

 

This article will explore how OSS can benefit a business from a non-technical perspective.

Open Source Development Reduces Costs

One of the major reasons more companies are adopting OSS is because it is a very effective way to reduce development costs. The two primary ways open source reduces development costs is by simplifying software licensing and increasing development speed.

Simplifies Licensing

Initially, the most obvious place OSS reduces costs is through the complete lack of licensing costs. Proprietary software typically includes initial licensing costs and ongoing maintenance contracts that can be a significant portion of the initial costs; these are often unavoidable. OSS licenses grant free use, modification, and distribution rights to everyone, meaning there is no initial costs to licensing the software, and maintenance can be customized to the needs of the specific business.

OSS also has a lower cost associated with the software procurement process since the OSS can simply be downloaded for experimentation or research, with no requirement to negotiate procurement with a proprietary vendor. Finally, OSS licenses allow a much broader range of use and customization, sometimes unlimited, this usually needs to be negotiated in a contract with a vendor in the case of proprietary software.

Increases Development Speed

In an OSS project, code functionality can be modified whenever necessary, with no need to negotiate custom contracts or statements of work with third-parties; this alone can result in significant improvements to development speed and reduce the amount of time to deploy products or services.

Any contributions that are successfully committed upstream will ultimately reduce the amount of effort required for ongoing maintenance. Once a maintainer has deemed code worthy of being included upstream, they usually do so with the implicit understanding they will maintain its functionality in the project unless something else is specifically agreed upon. Of course, there are limits to this, and the maintainer may eventually decided the functionality doesn’t comply with project requirements in the future; this may result in the code being dropped if no contributors step up to maintain its place in the source code.

Additionally, open source communities typically produce a faster evolution of upstream software that’s based on the features the community needs rather than financial motivations. The release early, release often strategy of most open source communities results in regular updates that allow anyone to take advantage of new features as soon as they’re available while also monitoring changes to experimental versions to be prepare downstream software to accommodate upcoming changes to stable versions.

The Strategic Value of Open Source

OSS has value that goes beyond the company’s bottom line; it can also be an effective route for creating strategic value. The two major ways it accomplishes this is through an avoidance of vendor lock-in and the ability to influence the direction of vital software through technical and political leadership.

Avoid Vendor Lock-in

A proprietary vendor might limit their software’s compatibility with competing services to elevate their prices. This can lead to any companies who rely on this software to face extremely high costs to migrate away from proprietary software which puts them at a disadvantage in contract negotiations.

OSS development encourages compatibility with more formats and software because it improves the functionality of the software: the primary goal of the developer community. Additionally, the ease of adaptability to niche use cases tends to make OSS compatible with a much wider range of complimentary software.

The primary benefit of this is that it mitigates the risk of upstream software discontinuation. Proprietary software vendors might discontinue a product, get purchased by another company with different business motivations, or go entirely out of business. Any of these scenarios can result in a sudden and expensive switch to new software.

On the other hand, OSS code is not generally owned by any single organization or individual, and anyone can pick up the reins to keep the project going. While this sudden changes in leadership for an OSS community still have costs for companies that rely on the code, adopters will have more options and flexibility for dealing with these changes. For example, an affected company could decide to adapt to the new direction of the project, or fork the project if the new direction conflicts with the company’s requirements.

Create Technical and Political Leadership

Open source community leadership provides an avenue to ensure important software remains viable to a company, while also ensuring the they have a voice in community decisions.

Open source leadership must be earned through an ongoing participation in the community, and is something that can be lost due to a lack of participation. Achieving OSS leadership takes persistent effort over an extended period of time, but the benefits often outweigh the costs.  Typical reasons to go through this process include a desire for improved visibility in external developer and user groups, and gaining technical influence over the direction of important projects.

A major benefit of open source leadership is that it can be leveraged to grow internal open source competence by promoting open source best practices and transferring knowledge of open source components to internal teams. Finally, engineers who dedicate time to upstream contributions improve the ability of product teams to use open source, making it easier for them to directly maintain and improve the OSS components they rely on.

The Rosy View of Open Source

The Business Value of Open Source Software - OSS-Business-Value

After reading the last two articles in this series, you might think OSS is nothing but sunshine and flowers with all the benefits it offers. These benefits might be pretty big, but they also come with significant risks and obligations any company that uses OSS needs to be aware of.  The next article in this series will cover these risks and obligations.

The Technical Value of Open Source Software

This article is a part of a series on using open source in business:

Technical value is one of the most important traits of software development and engineering. A mature open source community will often have multiple companies, organizations, and individuals who contribute to and depend on the code base. Any groups that depend on the code are invested in the future of the code, making it much less likely for the code to disappear while simultaneously encouraging participants to play an active role in ensuring proper bug and security fixing processes. This article will explore the ways open source software can benefit a business from a technical perspective by offering improved code stability and greater control over the software stack.

Open Source Improves Code Stability

Software built by a proprietary component provider can typically only be fixed by employees of the vendor company. In an open source community, anyone can test or fix bugs, regardless of association, and contribute to the reporting and tracking of bug fixes; as a result, there are many more avenues for errors in open source code to be discovered. This concept forms the core of Linus’s Law: “given enough eyeballs, all bugs are shallow.” Essentially, this states that when there are more tester’s and developers working together, bugs should be identified more quickly with more people who are capable of addressing them.

Anyone who identifies a bug with open source software can either fix it themselves, or inform the community of the problem in hopes that it will be fixed by someone who has a common interest. Proprietary vendors make commercial and financial evaluations before they implement security or bug fixes; there might not be enough financial incentive for them to make the specific fixes you require and creating this incentive can be extremely costly. Bugs in proprietary code can typically only be found through indirect methods, such as by encountering them while using the code in another product or service. On the other hand, OSS can be evaluated directly which makes it possible to find bugs before the software is even used.

The benefits of OSS for security are much more challenging to completely evaluate because open source vulnerabilities are often highly publicized, whereas proprietary software vendors can rely on security through obscurity since they distribute object code rather than source code. Because of this, bugs and security issues tend to be addressed much more quickly in open source communities with one major caveat: it hinges on the community having adequate bug and security vulnerability reporting and patching practices. There have been multiple high profile security vulnerabilities in OSS, including Heartbleed, which went unnoticed for years as it was deployed in numerous systems all over the world. In recent years, the security practices of OSS have come under much more scrutiny, resulting in the formation of groups like the Core Infrastructure Initiative, which seeks to identify critical open source components and ensure security is given adequate attention.

Ultimately, proper bug fixing and security practices come down to human ability and processes. Proper bug fixing and security auditing processes in an open source community can create code that is exceptionally secure and the high level of transparency open source offers makes it possible to evaluate the community directly. Many communities have formally defined processes for identify bug fixes or security flaws and patching them, all of this can be verified externally which isn’t possible with proprietary software. Finally, all OSS can be built from source code which improves security in cases where object code distribution is a concern.

Open Source Improves Control of the Software Stack

Another major technical benefit of OSS is having improved control of the software stack by means of a relatively unlimited potential for customization, and better knowledge-base of resources and information. Proprietary vendors can restrict the customization of their software and require expensive contracts for customization services. On the other hand, integrators can adapt OSS to meet the needs of anyone.

Mature open source communities often have numerous experts who can be relied upon for customization, whether it be through volunteered effort as a result of a shared interest, or by being hired directly to make the customizations. Since anyone can acquire OSS for learning purposes, there tends to be a much more broad and diverse ecosystem of developers and engineers. Additionally, since open source code is typically built in a modular fashion and governed through a maintainership system, it’s often much easier to find the items that need to be tweaked in the code and to make the required modifications.

One specific example where OSS is much more customizable than proprietary software is in language translations. Since all code is open to the public, anyone who is capable of translating between two languages can adapt the software for their specific language. This allows OSS to be translated to niche languages that might not be cost effective for a proprietary software vendor.

One final way that OSS improves control of the software stack is in the availability of a detailed knowledge-base of information. Proprietary vendors can restrict learning resources for their software however they want, but OSS tends to have a much more robust selection of supporting knowledge material that can be used to build in-house expertise. These resources can include things like wikis, project websites, and forums that provide general information for users and developers, as well as resources that allow individuals to get into direct contact with project experts like mailing lists, chat rooms, and question boards.

The Technical Value of Open Source Software - OSB3-tools-v2-1.png

Leveraging the Technical Benefits of Open Source

This article should have explained some common technical justifications for why OSS often provides better flexibility than proprietary software. In summary, it provides product creators:

  • The freedom to fix any bugs or security flaws that are identified,
  • A transparent process for identifying and fixing bugs and security flaws that can be verified externally,
  • More options for customization, with a more diverse ecosystem of developers and users, and
  • An improved knowledge-base that is publicly accessible.

The next article in this series will explore the ways OSS can benefit a business by simplifying licensing, increasing development speed, and reducing vendor lock-in.

Common Tools Used in Open Source Development

This article is a part of a series on using open source in business:

Up to this point, this guide has focused on the fundamental characteristics of open source communities and how these communities are organized. One of the major reasons these communities have organized around a relatively standard set of practices is because of the tools that are available to get work done in a distributed community. These tools must support individuals from diverse backgrounds who each have their own unique needs.

This article will describe the tools that are commonly used in an open source community and will explain the roles they play in an open source community. Additionally, it will provide some insight into how to get the most out of them.

Communication and Problem Solving

Development in an open source community includes people from numerous timezones and cultures around the world. The tools used for communication in these communities must be designed in a way that allows for these differences and makes it easier for them to be bridged. There are two types of classifications for these tools: asynchronous and synchronous communications.

Asynchronous Communication

Mailing Lists

Example: Mailman

Email mailing lists are one of the most widely used tools in an open source community because they create a good environment for in-depth, technical discussions. Most people already use email in their day-to-day work, and a mailing list makes it easy for large, distributed groups of people, who have a shared interest, to come together in a singular effort. In many communities, the mailing list serves as the official documentation of community decisions.

The asynchronous nature of mailing lists have an added benefit of making it easier for people of different ethnic backgrounds to participate because they give individuals more time to evaluate the statements of others and construct their own questions and replies. This is particularly beneficial to individuals that speak a native language that’s different from the language used in the open source community because they can avoid disrupting the flow of the conversation as they take the time necessary to understand everything.

 

Forums

Examples: phpBB, Discourse, mybb

Forums serve a very similar role as email mailing lists; the choice between the two comes down mostly to personal or community choice, and it’s common for communities to use both. With that said, there are a few key differences in how these tools are best used.

Forums are much easier to organize into structured content based on specific areas of information. It’s often easier for users to navigate and search forums, making it much easier for visitors to learn if someone else has had the same problem before them and if that problem has been resolved. Finally, forums also make it much easier to embed supplementary assets like images and videos.

On the other hand, it is much harder to branch off conversations in a forum. When the topic changes in a mailing list discussion, creating a new conversation branch is as simple as changing the email subject line. On a forum, someone must create an entirely new discussion in the forum that includes the information which led to the branch or they risk diluting the original conversation. Additionally, since most people use email daily, it’s more likely for them to make quick replies to other people on a mailing list, which can result in a more organic discussion. A forum requires users to login to a specific site and this increased barrier to participation can reduce user involvement.

Common Tools Used in Open Source Development - 7-tips-mailinglist

Real-time Communication

Real-time Chat

Example: Freenode

The most common real-time communication method used in open source communities is IRC. Most open source communities have IRC rooms dedicated to the project or specific subsystems of the project; there are even web services that offer free IRC rooms for open source communities.

Chat rooms can be valuable to an open source community in a number of ways. For starters, it is often a great method for someone to get quick responses to simpler questions that don’t need to be sent out to the entire community in an email. For example, new users or developers can use it to get quick help from the community if they are having trouble finding specific project resources, or they can also be used to solve minor technical problems.

Chat rooms also help build a sense of community by providing an informal location for participants to meet and have discussions. They can be a good environment for people from various organizations, companies, and backgrounds to come together in a single place. Lastly, chat rooms provide a good venue for scheduled and ad-hoc online meetings.

One final important consideration for chat rooms is that the conversations are typically not documented as well as forums or mailing lists. Mailing lists often serve a second purpose as documentation of project decisions because they are easier to review after the fact. For this reason, in-depth conversations that take place in chat rooms related to design and development decisions should be summarized and communicated to the entire community via asynchronous channels.

Code Development and Distribution

After discussions have taken place, the community needs to coordinate their efforts towards writing code. Fortunately, there are a plethora of tools designed to facilitate code development in distributed environments. No open source community can be successful without an established system for sharing source code, collaborating on improving the existing code base, and contributing new code.

Code Repositories

Example: Git

A code repository is a public system for storing and downloading source code; the primary purpose of which is to make sure that all developers are working on the same code base. Anyone that plans to submit code to an open source project absolutely must make sure they are working with the latest code found in the project’s repository. Git has become the de-facto standard for code repositories in the open source industry as the greater majority of open source communities rely on it for sharing code.

Anyone is free to download code from the repository or to submit recommended changes to the source code, otherwise known as a pull request. Typically, the ability to accept pull requests and commit code the the upstream project is limited to a select group of trusted individuals.

Bug & Feature Development Tracking

Example: Bugzilla, JIRA Mantis, Redmine, Trac

Bugs and feature requests go hand-in-hand with any software development project, open source is no different in this regard. However, bug and feature tracking in an open source community differ from proprietary development in one key way. In an open source community, all users and developersare free to browse the project’s issue tracker and to contribute information via testing or suggesting new features. This empowers users to get more involved in the development process because they can track it through each step of the process and contribute information related to their specific use.

Knowledge Sharing

Once project decisions have been made and development work has occurred, it is vital for a members of the community to document all important materials. Everything including events, developer reference documentation, technical demonstrations, governance decisions, and so on must be documented in some way because this is the only way for large groups of individuals to coordinate their efforts.

Wiki

Examples: Foswiki, dokuwiki, MediaWiki, TWiki

In many open source communities, the wiki excels at providing information in a form that’s easy to read and manipulate making them the primary resource for individuals to learn about the inner workings of an open source project. In many communities all participants can edit the wiki; this allows both users and developers to get involved in updating and maintaining the project documentation. The wiki is often considered the de-facto standard for a project. There is a large variety of wiki software designed to fit a range of use cases, and communities pick wiki software based on how well they fit the community’s specific needs.

Collaborative Editing Platform

Examples: Etherpad, ownCloud

In recent years, collaborative editing applications that allow multiple individuals to work on the same document at the same time have become much more common, especially in distributed communities. These make it easy for groups of people to share information in real-time and can be a great supplement to a chat room by allowing participants to quickly share smaller amounts of information. These are best used for ad-hoc collaborations and are not typically suitable for official documentation.

Public Website

Examples: WordPress, Drupal

A public website ties everything together by serving as a centralized location that makes it easy for people to find important project resources. Additionally, a website can be a great resource for informing newcomers about the project and explaining why they might want to use or contribute to it.

Common Tools Used in Open Source Development - OSB3-tools-v2-1

Coming Up Next: The Value of Open Source

This article concludes the first section of this guide: A Definition of the Open Source Development Model. The purpose of this section is to provide context for the rest of the guide by defining what an open source community is and how it operates.

The next section will explain how open source exceeds proprietary development in a number of ways including development efficiency, security, quality, and more. It will then go on to outline the business reasons for open source in an effort to demonstrate why it can be valuable for a business to use and contribute to an open source project.

An Introduction to the Open Source Development Model

This article is a part of a series on using open source in business:

If you are someone who is accustomed to working in a traditional, proprietary software development, the open source development model might challenge many of your perceptions about how code is produced in large scale software development projects. This is a result of a fundamental requirement of transparency and communication which results in a development process that is distributed, extremely fast, and modular.

This article will explore how development occurs in an open source community. It will also explain how a typical open source community operates in order to provide context for how the actual development of code is carried out.

General Community Practices

Open source development is a highly collaborative process, and the only way for this to be successful is for all participants to make their technical motivations, intentions, and plans related to their participation visible to the rest of the community. This encourages greater collaboration and cooperative planning, which improves overall productivity of all parties and helps dependencies get resolved more quickly. It also results in greatly enhanced documentation because discussions themselves can be used as documentation and discussion archives provide important historical context for project decisions.

Public discussion is a prerequisite to all development in an open source community because it makes maintainers aware of the needs and problems community members have, and allows others to provide feedback and join the effort if their motivations are aligned with it. This helps keep various stakeholders on the same page to maintain the overall project direction. The decentralized decision making process that results from this has an added benefit of drastically improving the quality of the code.

Transparent Peer Review to Enforce Strict Quality Standards

Peer review is at the center of the decision making process in an open source community; this involves public discussions where anyone can comment on potential changes. Then feedback is offered primarily from the individuals who the change most impacts. Peer review helps maintainers process larger amounts of code faster by relying on trusted members of the community to enforce the strict quality standards the community has adopted. Feedback from the community can include commentary on code quality or formatting, the number of changes being made in a single submission, the degree of change the patch introduces, compliance with the overall strategy of the project or subsystem, or many other things.

Full Stack Involvement, From User to Developer

In a traditional corporate development environment, the development team is the only group that has access to resources like source code, requirements lists, documentation, and bug lists; users often have very little involvement in development before release.

In an open source project, development resources are made available to everyone, even those who are outside the development team. This means that source code and project requirements are published publicly, and bug tracking is openly searchable by anyone. Users and beta testers are also encouraged to submit bug reports. This tighter integration of users and developers results in better informed requirements before release, and it empowers users to find, report, and help fix bugs and other issues that are outside official test cases.

Decentralized Decision Making

Open source project leaders appoint delegates to make decisions for the community; these delegates build trust by being good participants in the community and by making good decisions on related issues. Transparency is vital because it is only possible to build trust by participating in public discussions, and often the discussions, themselves, are the documented record of the project direction. Anyone who wants to influence community decisions absolutely must participate on public discussion platforms like mailing lists, IRC, issue trackers, and project forums. With that said, not all decisions need multiple levels of review, and often trivial fixes are passed directly to the project maintainer.

How Open Source Compares to Proprietary Software Development

Proprietary development typically involves very little interaction between the developer team and the client that receives the software. If the client is commissioning the software development, their interactions are often limited to submitting a list of requirements to the developers, who then build the software behind closed doors. The client doesn’t see what is happening in the development process until the vendor is ready to deliver the next incremental version. If the client is simply a user of the proprietary software, their interactions are often more limited to communication channels such as support lines and premium consultation services.

An Introduction to the Open Source Development Model - OSB2-prop-dev

In an open source community, users play an active role in proposing new ideas for the project and they can follow the entire development process from start to finish through public channels of communication. Anyone can submit patches, including users, and both developers and users are involved in the testing process. The roles of developers and users are much more closely integrated in open source development; this allows users to have a more direct path to influencing project development. This model also makes it much easier to integrate new features, and allows developers to respond to fringe test cases much more quickly.

An Introduction to the Open Source Development Model - OSB2-OSS-devOne important consideration here is that while a vendor might be contractually required to fulfill their client’s requirements in the proprietary model, developers have no obligation to build user-requested features in an open source project. This can be remedied by hiring developers to add the features to the open source project or by finding active developers who share similar motivations.

The Development Process

Release Early, Release Often, and Test Continuously

One of the fundamental concepts of open source development is to release early, release often. Releasing early allows others to participate in development and provide feedback, making it easier for new ideas to be worked in while the code is still new and malleable, and allowing potential problems to be identified early.

Releasing often results in smaller changes that are easier to understand, debug, and mature, and it helps maintain the rapid development and innovation pace that is commonplace in open source development by giving all contributors the latest code on a regular basis. However, quick releases  may lead to release fatigue in users that are forced to constantly update their system as the project progresses. To combat this, many projects release multiple versions of their code:

  • Long Term Stable (LTS) – This is for users that value stability above all else; LTS releases are typically supported for multiple years and typically only receive essential security updates.
  • Stable – This is for users and developers that want newer features, but only after developers users have tested them.
  • Experimental – This is the absolute newest code and has a high likelihood of containing bugs. This is typically only for developers who are looking to contribute to the upstream project, or who are building products that need to use features which are still under development.

An Introduction to the Open Source Development Model - OSB2-release-cycles

Continuous testing allows open source communities to discover and triage problems more quickly, resulting in faster fixes. Since changes are typically smaller (release often), it makes troubleshooting much easier, and results in regressions being noticed earlier. This makes the work of maintainers to determine which code should be accepted easier. Open source communities often have multiple build cycles that overlap each other and align with release schedules and feature freezes. Automated build tools are often used for this process.

Modular Development

Staffing in an open source community is much more fluid than traditional software development communities. In a traditional software development model, developers are assigned to specific projects and typically don’t have much incentive to contribute to other areas. In an open source community projects will have clear owners, however developers are often encouraged to contribute to other projects or subsystems. They often have incentives to do so because the requirements of multiple projects can often align. Developers might have a primary project they work on, but it is likely they will contribute to a broad range or projects and subsystems.

As a result, open source code is often designed in an extensible, modular fashion to make it easier for individuals to contribute across subsystems. Where extensibility is often considered a feature in traditional software development it is a requirement in open source because it helps make incremental changes, follow an early and often release cycle, improve code maturity, and reduce overhead. A smaller core with features implemented as plugins reduces collisions and creates a natural separation of tasks and scope. This allows features to be made available to developers more quickly since the number of interdependencies is reduced and features can be released as they are completed.

Coming Up Next: The Tools of an Open Source Community

The most important points to take from this article is that transparent collaboration is an absolute requirement in any open source community, and one must interact with the community based on their established processes for doing so. As a result of this requirement, open source communities have coalesced around a relatively standardized set of tools that are used to facilitate transparent collaboration. The next article in this series will discuss the tools that are typically used in open source communities and what their roles are in the development process.

Common Characteristics of an Open Source Community

This article is a part of a series on using open source in business:

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.

Common Characteristics of an Open Source Community - hierarchy

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.