How to Manage an Open Source Project?

Open source software (OSS) development, grounded in principles of collaboration and transparency, is a cornerstone of the modern digital landscape. As more companies and individuals adopt this paradigm, it becomes essential for every programmer to have an understanding of how to launch and manage open source projects.

In this article, we provide an overview of OSS best practices and categorization of open source software licenses.

If you are looking for the basic information about the subject, read our earlier post “Is Open Source the Future of Software Development?”

What is open source software?

Open source software, commonly known as OSS, doesn’t have a fixed definition but stands out for its unique licensing and development models. In terms of licensing, OSS is can be described as software that:

• is freely available to the public in source code form via the Internet;
• comes with a license that allows users to freely modify and distribute the software without paying any fees to the licensor.

OSS licenses vary, but they generally fit into two categories: “permissive” or “copyleft” (sometimes termed “viral”). In contrast, most commercial software licenses restrict usage to the executable form and forbid reverse engineering, modification, or distribution, thereby keeping the source code exclusive to the licensor.

From a development perspective, OSS is built collaboratively by a community of volunteer programmers who work without pay. Sometimes companies pay either their employees or external individuals for contributing to open source projects. Developers are organized into a “project,” with each one contributing code to the collective work. Advocates of OSS highlight its role in driving innovation and collaboration, as the collaborative nature allows for extensive review and enhancement of the code by numerous participants.

When should I open source a project?

There’s no perfect time to open source your project. Do it when you’re ready for others to see and help improve it, whether it’s a new idea or an old product.

As your open source project expands, your role will involve more than just coding. Addressing community issues, reviewing code contributions, and promoting the project will become your key responsibilities. The time dedicated to these non-coding tasks varies with the project’s scale, and as a maintainer, you should be ready to manage them or seek assistance.

For company-driven open source projects, it’s essential to secure the necessary internal resources for success. This includes identifying who will maintain the project post-launch and how to collaborate with the community in managing it. Additionally, if the project requires a specific budget or additional staff for promotional activities, operational support, or ongoing maintenance, it’s important to initiate these discussions early on.

Which OSS license do I need?

Sharing your work with others is exciting and rewarding, but it also involves some legal issues. In this section, we provide a brief overview of popular open source licenses that govern how software can be used, modified, and distributed.

There are two main types of licenses for open source software:

• Copyleft license ensures that any code derived from the original open source code carries the same licensing terms.
• Permissive license offers greater flexibility for the reuse, modification, and distribution of code.

Copyleft licenses

The most common copyleft licenses are:

• GNU General Public License (GPL) is a strict copyleft license. It allows users to freely use, modify, and distribute the software, but any derivative work must also be distributed under the same GPL license. This ensures that the freedoms associated with the software remain intact through all iterations.
• The GNU Lesser General Public License (LGPL) is similar to the GPL but less strict. It’s often used for software libraries. The LGPL allows a user to link LGPL-licensed software with proprietary software, provided that the source code for the LGPL software (or any modifications to it) is made available under the same LGPL terms.
• The Affero GPL (AGPL) introduces a vital clause to address a specific loophole. The standard GPL license is triggered by the distribution of software, but this doesn’t cover software exclusively used over a network. The AGPL addresses this by extending the GPL’s terms to software utilized over a network, closing this loophole.
• The Eclipse Public License (EPL) is particularly popular for business software applications. It permits the integration and sub-licensing of EPL-developed software with non-EPL and even proprietary code. The key condition is that any non-EPL elements must remain distinct, either as separate modules or objects. Modifications to the EPL software must adhere to the EPL and be released under the same terms.
• The Mozilla Public License (MPL) is the most flexible copyleft open source license. It allows easy use and modification of its code in proprietary software, provided any MPL-licensed code remains in separate files and is included in the distribution. The MPL also grants patent rights and requires keeping copyright notices.

Permissive licenses

The most popular permissive licenses for open source projects are:

• MIT license is one of the most permissive and simple open source licenses. It allows almost unrestricted freedom with the software, including commercial use, modification, and distribution. The only requirement is to include the original copyright notice in any significant uses of the work.
• Apache license is similar to the MIT License but also provides an express grant of patent rights from contributors to users. It allows for commercial use, modification, and distribution, and also provides an explicit contribution to trademark rights.
• Berkeley Source Distribution (BSD) license permits the distribution of larger or licensed works without the source code and under different licensing terms. The 2-clause BSD License is similar to the MIT open source license, whereas the 3-clause and 4-clause BSD licenses have additional requirements or restrictions regarding reuse and other conditions.
• Unlicense. As the name suggests, this open source license is the least restrictive, essentially placing software in the public domain. There are no conditions attached, allowing for the distribution of these unlicensed works without source code and under varying terms.

For more information on OSS licensing, check out this website.

What are the risks of OSS?

While open source has long played a crucial role in IT business by reducing costs, accelerating development, enhancing code quality, and drawing skilled professionals, security still poses a significant risk and concern. Below, we outline some of the possible risks associated with open source software.

• Known security weaknesses: A version of a component might include code with vulnerabilities, inadvertently added by the developers. Details about these vulnerabilities are often made public, for instance, via a CVE. There may be exploits and patches available, although this is not always the case.
• Legitimate packages breach: Attackers might infiltrate components of the original project or its distribution network to insert malicious code into a component. This could be done even without hijacking the accounts of legitimate project maintainers, simply by exploiting weaknesses in package repositories or code itself.
• Misleading naming: Attackers can create components with names that are similar to well-known open source or system components, using tactics like typo-squatting. They might also impersonate credible authors (brandjacking) or use familiar naming patterns from different programming languages or ecosystems (combosquatting) to deceive users.
• Unmaintained software: A component or its specific version might no longer be under active development. Consequently, updates or patches for both functional and non-functional issues might not be promptly, or ever, provided by the original open source project.
• Overlooked dependencies: Developers of a project might be unaware of a dependency on a particular component. This could be due to various reasons: the component not being listed in an upstream component’s SBOM, failure to run or detect it with SCA tools, or the dependency not being set up through a package manager.
• License issue: A component or project might lack a license entirely, or have one that doesn’t align with its intended use, or comes with requirements that are either not met or unachievable.
• Underdeveloped software: An open-source project might not adhere to development best practices. This includes not following a standard versioning scheme, lacking a regression test suite, missing review guidelines, or having insufficient documentation. Consequently, its components may not function reliably or securely.
• Undetected modifications: Changes in a component can occur without developers noticing, reviewing, or approving them. This can happen if the download link leads to an unversioned resource, a versioned resource has been altered or compromised, or due to insecure data transfer.

How to secure OSS?

The following steps will help you ensure the security and sustainability of open source software:

• Risk management for OSS: Create a risk profile for open source software, including risk identification, assessment, response, mitigation, and ongoing monitoring. Define the organization’s risk appetite and engage in continuous risk management.
• Open source policy: Develop an enforceable open source policy, drawing from frameworks like NIST SP 800-53. Ensure the policy is integrated into the software development lifecycle (SDLC) and that security tools are part of developers’ processes.
• Shift security left: Embed security by default in the SDLC, ensuring it aligns with software and systems procurement. Prioritize security in product requirements and regularly review automated tests for optimized risk.
• Inventory and audit management: Maintain an inventory and databases for asset and configuration management. Regularly audit open source systems, components, and third-party software vendors.
• Security metrics and KPIs: Define specific metrics for OSS security initiatives and monitor them to evaluate risk and security processes. These metrics help assess OSS governance maturity and control improvements, aiding investment decisions.
• Security-focused culture: Encourage collaboration and shared responsibility for security across all levels of contributors, emphasizing the importance of each individual’s role in maintaining security. Incorporate incentives for good security practices and provide engaging, concise, and high-quality security training activities for all participants.

Best practices for hosting and managing open source projects

GitHub is one of the most popular open source platforms. In this section, we’ll walk you through some best practices for hosting and managing open source projects there.

Open source is more than code; it’s a culture. That’s why for the success of an open source project, a vibrant community around it is as important as code itself. The recommendations below will help you grow an active and supportive community.

Documentation

Having clear and thorough documentation is essential, as it makes the project easy for others to use and contribute to. A well-documented project should explain what it does, how to use it, its dependencies, and how the code works. It should also include information on any limitations.

How to create quality OSS documentation

1. Create a welcoming README.md file to introduce the project and guide newcomers.

2. Add a CONTRIBUTING.md file to detail how to contribute.

3. Use a CODEOWNERS file to specify who is responsible for the code.

4. Establish a community-friendly environment with a CODE_OF_CONDUCT.md file.

5. Document the release process and criteria.

6. Make the project’s governance clear in the repository. Use REPOLINTER to find and fix common repository problems.

How to organize support for contributors

To maintain an open source project on GitHub, you also need to provide support to your community. Here are the key practices for that:

1. Provide a SUPPORT.md with help instructions.

2. Create clear, organized documentation including install/use guides, troubleshooting, and use cases.

3. Utilize the issue tracker for bug reports, feature requests, and user support, ensuring timely and detailed responses.

4. Welcome and seek out user feedback to enhance the project.

5. Communicate transparently about updates and developments via blogs or social media.

6. Implement a SECURITY.md file for reporting security issues.

7. GitHub allows automatic application of the community health files to organization-level repos.

8. Engage with the community using GitHub Discussions to foster a support network.

9. Set up a help center for common questions.

10. Archive inactive repos to indicate discontinued support.

11. Include a FUNDING.md to inform users about the assistance you provide.

Enhancing security for an open source project repository

Security is a cornerstone of any project. Here are several suggestions for enhancing the security:

1. Introduce two-factor authentication.

2. Utilize GitHub’s access control to manage repository permissions.

3. Implement Branch Protection Rules and CODEOWNERS files for review oversight.

4. Conduct secure code reviews with security checks like static code analysis.

5. Automate build, test, and deployment with CI/CD tools for quicker issue resolution.

6. Use GitHub Code Scanning for vulnerability detection.

7. Run dependency scanning tools like Dependabot or Snyk for third-party code security.

8. Aim for the OpenSSF Best Practices Badge to show commitment to security practices.

9. Designate a team for security issues, create a SECURITY.md file, and set up a contact for alerts.

10. Employ GitHub Security Advisories to manage and communicate about vulnerabilities.

11. Sign commits with GPG for verified change sources.

12. Use the OpenSSF scorecard to evaluate and improve security practices, giving insight into the project’s security strengths and areas for improvement.

OSS licensing best practices

You should use licenses approved by the Open Source Initiative (OSI) and those considered “free/libre” by the Free Software Foundation. The OSI’s approval process ensures compliance with the Open Source Definition (OSD). Licenses that restrict usage or distribution, often termed “Source Available,” are not compatible with the OSD.

Some recommended practices for licensing open source projects are:

1. Include a LICENSE.md file at the repository’s root with the terms of use.

2. Opt for OSI-approved licenses, which are well-understood and easy to implement.

3. Mention the license in the README.md file with a link to the full license text.

4. Clearly identify and license third-party code within the project.

5. Use license badges in the README.md file for quick visibility of the project’s license.

6. Apply Software Package Data Exchange (SPDX) identifiers in source files for machine-readable license information.

7. Ensure the license is recognized in the GitHub repository summary for clarity.

8. Regularly update licensing information to ensure it remains current.

9. Provide clear contribution guidelines from a licensing standpoint, considering Developer Certificate of Origin (DCO) or Contributor License Agreement (CLA) if used.

DCOs and CLAs to manage contributions

The Developer Certificate of Origin (DCO) and Contributor License Agreement (CLA) are mechanisms used in open source projects on GitHub to manage contributions. The DCO allows developers to certify that they have authored the code or have the rights to submit it by including a “Signed-off-by” statement in their commits. This helps in establishing a chain of responsibility for code licensing and provenance. On the other hand, the CLA is a legal document between contributors and project maintainers outlining the terms for contributions, often used to prevent legal issues from third-party contributors.

Our recommendations:

1. Include the DCO in the CONTRIBUTING.md file.

2. Implement a bot to ensure all commits are signed off.

3. Use The Linux Foundation’s EasyCLA tool for projects under its umbrella to manage CLAs.

4. Consider CLA Assistant for projects not under umbrella foundations, with corporate counsel advice for handling CLAs.

How to handle an open source community?

In the above section, we have explored some formal organizational processes. Here, we share ideas as to how to shape your community so it aligns with your vision.

Simplify initial contributions for developers

To make the initial contribution process more welcoming for developers, consider adopting the following strategies.

• Begin by selecting an easy task and work towards a pull request, critically evaluating each step for intuitiveness.
• Document any aspects that are not straightforward. Once the pull request is merged, prioritize and address the noted issues.
• Finally, observe a new community member during their first contribution, solicit candid feedback, and make further improvements based on their experience.

Be supportive

Create a safe space where all questions are valued and none are considered too small. Respond to each, pointing contributors to the appropriate resources. Ensure your team is well-informed to clarify issues and provide clear guidance. Such an environment will not only cultivate a supportive community but also establish your project as a valuable asset in the broader developer world.

Avoid governance unless absolutely necessary

There’s a common belief that “true” open source projects must have formal governance, with detailed charters and procedures. However, such structures are only needed for a small number of initiatives. An open source project is often most vibrant and productive in its early stages when the focus is on coding, forging connections, and keeping things simple. Prolonging this initial phase is usually advantageous. Governance becomes important as the project expands, drawing in a variety of contributors and investments, especially when multiple competing companies get involved.

Maintain a culture people enjoy

The best open source projects are known for their friendly cultures. Encouraging a mix of practices and appreciation of everyone’s unique experiences and ideas, help avoid stagnation. By cultivating a culture that values innovation and creativity, you not only establish a dynamic and satisfying environment but also enhance your open source project.

How to contribute to an open source project

In this article, we haven’t explored how individual developers can contribute to open source projects and what they should know before getting involved. To learn more about this aspect, check out this video guide:

Conclusion

We have looked at some of the key aspects you should know when open sourcing your software development project. Successful management of such initiatives hinges on establishing clear goals, selecting appropriate licensing, fostering a collaborative and inclusive environment, and maintaining open and transparent communication channels. This will help you embrace the diverse contributions from the global community, while ensuring high standards of quality and security.