Day 3 - Contributing to Open Source

By: Jennifer Davis (@sigje)
Edited By: Dan Maher (@phrawzty)

Developers are often encouraged to contribute to open source. If you don’t consider yourself a developer, it can feel daunting to start on the journey to contributing. In the last year, meeting with people in infrastructure, ops, and SRE communities, I’ve found that the number of folks participating in open source is minimal. In this article, I will share a little about why you should contribute, and provide some information about where to contribute, including some additional resources to get you started.

Why should you contribute to an open source project?

Participating in open source is a gift that keeps on giving. Everyone has their motivations, but some of the benefits of connecting with the community in an active role include:

• Promotes learning and development of skills. You can practice collaboration skills in roles that aren’t tied directly to performance reviews. You can develop other skills driven by your interests that are not part of your day job.
• Builds and promotes visibility. Your employer benefits from your participation in open source communities. You can find new job opportunities and potential co-workers.

What do you need?

First, figure out your employer’s policies for contributing to open source and review your employment agreement. While I think every company using open source software should give their employees time to contribute, often the contribution policies are problematic even if individuals contribute during personal time and on personal equipment. If your company doesn’t have a policy (or has a restrictive policy), sharing A Model IP and Open Source Contribution Policy may be helpful in providing guidance to improving the situation.

Specific software requirements will vary based on the project. Your skills in infrastructure as code or configuring continuous deployment pipelines may be extremely helpful to a project that hasn’t already implemented these practices. Your experience in these areas might drive the direction of software requirements; for example, a specific version of docker or cloud provider CLI.

If you’ve never done a pull request, the first-contributions project has a walkthrough as part of the repository. Every project will have a workflow and may have different recommendations on how to submit a pull request. It’s helpful to learn the fundamentals here rather than learning from scratch on a project of interest.

What kind of contributions?

Operations engineers have a lot to offer to open source projects. Beyond developing features, areas of contribution can include:

• Reporting and replicating issues
• Mentoring
• Documentation
• Architecture diagrams
• CI/CD pipeline
• Infrastructure as code
• Separating secrets from code
• Maintaining tests
• Review pull requests
• Project management
• Supporting other community members

Many large projects have contributor summits that allow individuals to meet and collaborate in-person as well. In these summits, providing an ops perspective can help guide the project to be more robust and resilient.

What project?

Sometimes, the best question to ask is who rather than what. Who do you want to collaborate with? Understanding the who can help guide your focus to specific projects that allow you to work with those folks.

Another question to ask prior to what is: How long do you want to contribute? For example, is this a one-time contribution, or something you are willing to provide on-going support? Being clear with your objectives can help you be successful in your selection of projects and contributions.

💡 Just because something is “public” on GitHub or Gitlab, and even if there are CONTRIBUTING files, it doesn’t mean that the repository owner wants collaborators or contributors. Sometimes folks are coding in the open. Before you invest a lot of work into a contribution, send an initial query through an issue or via a contact address.

It is often helpful to contribute to something that your company already depends on. This may help you fix something for the community at large that also helps you in your day job (and doesn’t require you maintaining a separate fork forever!).

You can also explore things that aren’t related to your company at all! This will help you to learn about other areas that can help you grow your skills and filter future job opportunities.

Strategies for identifying projects

One method to find projects is to look for active projects in your skill sets. I’m going to walk through the process I have gone through to find projects to contribute to with my Chef and infrastructure skills.

💡 Communities may have a specific artifact repository that can help you identify popular projects. Chef Supermarket, Puppet Forge, and RubyGems can help you find chef, puppet, and ruby projects for example.

Search and Organize Community Cookbooks

By searching cookbooks, and then choosing to order by “Recently Updated”, I first find cookbooks that have recent activity. I then click on the project to get more information.

Examine a cookbook

Next, I verify that the project is properly licensed for open source and that the code is available and accessible in a shared version control repository (not just a downloadable artifact).

Here, the lampp_platform project from the University of Alaska has an MIT License, and the source code and issues are linked.

Examine contributing guidelines

I then check whether the project has explicit contributing guidelines defined in a README.md or CONTRIBUTING.md.

Another good thing to check is for open unclaimed issues where I can provide value. I also look at the number of contributors on the project; I will still support a project that only has a few contributors, but it does give me insight into how overloaded they might be (especially if the project is popular).

Overall, when I look at the lampp_platform cookbook a lot is going for it:

• It’s currently active, i.e. has regular contributions.
• The README follows Chef conventions with a purpose, requirements, supported platforms, dependencies, and examples.
• The CONTRIBUTING documentation is present, and while sparse it does include information about testing.
• The project has a kitchen.yml configuration.

From here, I could verify whether the kitchen configuration allows me to spin up the infrastructure as intended. A project might have specific configurations for the organization that aren’t as helpful to others. For example, maybe there are tags in use that wouldn’t make sense for general use or maybe it’s using a specific cloud provider. This is a good example of a project where small contributions can have a big impact.

A different method for identifying projects within a specific skill set is to look at broader community opportunities. These will vary and be specific to that particular project. For example, within the Chef community, the Sous Chefs are individuals that collaborate on cookbooks intended for the wider Chef community. These opportunities can be hard to find unless you are already active in a given community. For example, if you don’t already participate in the Chef Community Slack, or attend the Chef Community Summit, it might not be obvious how to find out about the Sous Chef team.

Another method to find a project to contribute to is to look at aggregating platforms for insight into available projects. Many of these are organized from a developer perspective. For example, CodeTriage provides a list of popular projects on GitHub, sorted by language. Mozilla provides a more nuanced “choose your adventure” process that helps you drill down to a possible project to get involved with.

A final method is to look for community inquiries. Sometimes the request may be general. For example, when Carolyn Van Slyck put out a call for Porter contributors on Twitter in September of 2019. Porter has a welcoming website that states the project values and guidelines upfront and lists the steps to take to get started contributing.

Other times, it might be more specific. For example, when Karthik Gaekwad requested feedback for VirtualBox and its website on Twitter at the end of November 2019. Providing feedback about VirtualBox is contributing to open source. (There are other ways to contribute to VirtualBox as well if this is of interest.)

💡 The most important thing is to be kind in your contributions. If you find that your chosen project has toxic contributors, it’s OK to walk away from the project.

Identify possible contributions

Some projects use labels to mark issues that are good for new contributors. These issues generally focus on documentation or code issues but are good way to learn about the project as a beginner. It’s helpful to lurk and examine both open and closed issues to see how contributors participate and maintainers support contributions.

Sometimes projects will use Trello or GitHub Projects to organize planned issues. Larger projects may have a regular scheduled online community hangout to plan and identify areas of concern.

Here is an example of the DevSec Hardening Framework project and prioritized tasks using a GitHub Project board:

Wrap Up

While many of the resources out there focus on developers, people who identify as system administrators, site reliability engineers, and other operations engineers have a lot to contribute to open source. We don’t have to accept software as-is. We can shape, define, and help move in our desired directions.

If you want to have a greater impact and support open source as a whole, join the Open Source Initiative, a member-driven community non-profit that promotes the use of open source software.

If you want to dig more into how to contribute to open source, read Forge Your Future with Open Source by VM Brasseur.

I’d love to hear about your open source contributions. Share in the comments or with #OSSandTell on Twitter.

Additional Resources:

• A Model IP and Open Source Contribution Policy
• Forge Your Future with Open Source by VM Brasseur
• Open Source Licenses
• Join the Open Source Initiative
• Open Source Licensing in the Real World
• Open Source Guides and the project