Why open source governance is key for security

What is open source governance?

Open source governance is the recognized rules and customs that guide an open source project. According to OpenSource.com, in order to outline governance directives, the following questions need to be answered: 

• What roles can contributors play in the project?

• What qualifications, duties, privileges, and authority are associated with each role?

• How do people get assigned to (and removed from) roles?

• How can role definitions be changed?

• What are the project's collective policies and procedures?

As the roles within the project are defined, usually based on each developer’s activities, governance of open source projects can be applied.

6 Different governance models

Defining the rules of an open source project and assigning the roles is known as the governance model. There are six governance models, according to Red Hat.

1. Do-ocracy: This governance model follows the idea that the developers doing the work should be the ones making the decisions, and in this case, peer review plays a large role in governance. It can also be a hard governance for those developers who need more guidance.

2. Founder-leader: This open source governance model is used most often on new projects or those with just a few contributors. There is a clear line of governance in this software model, usually the initial person or development team. Unfortunately, this type of model can lead to an open source dictatorship, where the founder-leader can dictate governance across the software’s lifecycle.

3. Self-appointing council or board: This open source software governance model creates a leadership committee to oversee the project development steps. The downside to this model is the leadership committee could shut out the voices and participation of the rest of the team.

4. Electoral: This model lets the community choose its governance via the election process. It is a popular model for projects with large community input from a number of developers with similar skills and roles. While it is the most equitable type of model when it comes to the decision-making process, it can also add more layers of responsibilities and distractions, as well as infighting as members in the community jockey for leadership roles.

5. Corporate-backed: Under this software governance model, businesses or industries take over the distribution of the software under open source licensing agreements. While this offers control of the software development, it also limits outside contributions typical for open source projects.

6. Foundation-backed: This model is managed by a non-profit organization and governance is often strictly controlled by a single structure. This is because of the requirements surrounding the status of these organizations.

How to formalize leadership roles

Open source software projects are designed to be collaborative, but governance offers direction. Leaders guide the project, ensure deadlines are met and that policies and guidelines are followed.

Each governance model has its own processes for choosing leadership. They are:

• Do-ocracy: Leadership is built by doing. The more the developer’s contributions to a project are accepted, the more influence they gain within the project’s community.

• Founder-Leader: Leadership most often comes naturally from those who began the project.

• Self-appointing: With more mature and long-term open source projects, there is often documentation already available outlining governance processes. It’s up to the developer to take the initiative to learn how their contributions lead to leadership roles.

• Electoral: With an election process, there are well-defined procedures in place to determine how/when elections are held and for what roles. Election results are readily available in the online literature about the project. Candidates usually have built a reputation within the community before putting their name up for a leadership position.

• Corporate-backed: Governance comes from the originating company, so leadership has a relationship with that company.

• Foundation-backed: Governance either comes directly from the foundation or from a self-appointed council.

All project contributors should have an opportunity for a governance role if they so choose, but first, the developer needs to join the project. To do so, interested developers should subscribe to a project’s mailing list, which can be found on GitHub and official project sites.

Once they get started contributing to a project, they’ll need to track their contributions. This is done with tools such as the Open Source Contributions Log. Tracking contributions provides proof of work for anyone who wants to move into leadership roles within open source governance.

Roles within open source governance

There are formal roles project contributors hold within open source software governance. Among the most recognized are:

Maintainer: This could be someone who has written a lot of code for the open source project or it could be someone who has produced documentation about the project or even an evangelist for the project. This contributor feels a sense of responsibility for the overall direction of the project and does what’s necessary to make it better.

Contributor: Anyone who contributes to the project, whether it is commenting on problems or writing code. If they bring in something of value to the project, they play the role of contributor.

Committer: Someone with special commit access who has demonstrated deep and continuing commitment to the project.

4 Ways to protect your open source project

The appeal of open source software is the accessibility to anyone who wants to be involved. At the same time, the greatest risk in open source projects is that anyone can contribute. Open source governance includes taking action to protect the project from threats. Steps that can be done to prevent risk include:

1. Create policies within the project designed around security, including oversight of users and contributors or project documentation. Someone with a leadership role should have authority to enforce those policies. Maintainers are a good choice in this role.

2. Test, track and fix vulnerabilities. Software composition analysis (SCA) tools let developers analyze and manage open source components within software. SCA tools do tasks like verifying licensing and evaluating vulnerability risks. 

3. Limit who can create pull requests and evaluate them before action is taken. These pull requests can also be scanned using an SCA or static application security testing (SAST) tools to detect vulnerabilities.

4. Vet contributors before they join a project and offer access only to trusted users.

When to implement governance

Governance should be implemented as soon as possible in any open source project. The earlier documentation is drawn up, the easier it is to define the expectations and goals. Early governance also allows roles to be clearly outlined. If the project is corporate or foundation backed, discussions should occur internally before launching the project so the processes are clear and there is a known path as the project moves forward.

Contributions from companies and governance models

Open source software is used by many different users. Because different companies will have their own need for the software, their contributions may change the scope. Companies may also have paid developers who are designated to join as project contributors to some projects.

These contributions should be treated as any other contribution. Governance continues to be based on the value of contributions and involvement.

Getting started with open source governance

More than 90% of proprietary software uses open source components, which means open source governance should be a priority for IT departments and C-suite executives in every company where code is released as open source. Policies for open source governance, project contributors and leadership should be well defined and well communicated and everyone involved with open source software development should know their roles in project engagement.

The open source governance policy offers solutions for problems that can occur, ranging from security risks to operational risks. A lack of governance can slow down the software development cycle, delaying releases or requiring remediation after the product goes live.

Adding governance models addresses potential legal issues. For example, the organization’s governance policy should include an SCA tool to understand potential vulnerabilities and license issues within dependencies. Snyk Open Source provides visibility into the open source packages you’re using, as well as license compliance and dependency management.