Getting Started as an OSS Contributor/Maintainer

What are some important concepts to understand for open source software?

InnerSource is the use of open source software development best practices and the establishment of an open source-like culture within organizations. The organization may still develop proprietary software, but internally opens up its development. The benefits of innersource includes network effect and increased visibility to your work and skills within and potentially outside the organization. If you have something in the organization that is security critical, there’s a higher chance that bigger mistakes will be spotted.

Now why should you care about InnerSource?

1. Software supply chain attacks are on the rise with no end in sight.
2. Corporate stewardship is needed to increase the security posture of the OSS community at large.
3. Part of your journey should be to spread the word at your job/company you are founding.
4. We are in this together.

Now, moving onto OSS contributors, a contributor is a person who helps improve (writes code and/or document and tests the software) the project, but does not have (or want) the authority to review pull requests. If you’re an OSS maintainer, you’d also:

1. Be a contributor who also reviews pull requests
2. Tend to think about the longer term vision/goals of the project more than the average contributor.
3. Evangelize the project
4. Organize, run, and manage the meeting calendar, mailing list, instant messaging platform, and more.

How do you become an OSS contributor?

Becoming a contributor implies you’ll propose change to the open source project, and that change will go through the entire lifecycle until it actually gets merged, which is when you can start celebrating. Here’s the list of a pull request:

• A need arises, you try to fill it with OSS
• Discover that your selected OSS has a missing feature
• Verify that contribution would be feasible, e.g. verify you can:
  • Compile the project
  • Run the tests
  • Understand the code
  • Figure out roughly where your change would be placed and how it would work
  • Maintainers seem like people you can work with
• Get confirmation from maintainers that your feature is welcomed
• Fork the upstream repository
• Work on your pull request then submit it
• Reach out to maintainers on alternative channels to ensure visibility
• Accommodate changes according to feedback, if any
• Also be prepared to defend your solution in a neutral, dispassionate, and humble way.

The traits of a good pull request include:

• Pre-approved by the maintainers if the change is significant
• Abides by the contributor guidelines (if there are any)
• Clear, but short commit message(s)
  • Pay attention to the project requiring a specific formatting of the pull requests such as conventional changelog
• No breaking changes, unless there was no other way and it was agreed in advance
• Tests updated/new tests added
• Documentation updated/added
• Even if there was no documentation before, it’s always good to add some
• Uses the provided templates/questionnaires of the maintainers for issue and pull request opening (if there are any)

A few tips on how to become a better and more efficient OSS contributor are to read large amounts of code on the projects you feel is high quality, avoid rabbit holes via timeboxing, proactivity, and checking if it compiles first.

How do you become an OSS maintainer?

Running your own project can be a very rewarding experience. It will be challenging because you have to learn a lot on the go, so you want to be ready for that, especially when it comes to communication. Before you start your project, think about your definition of success, why you’re doing this, what you want to achieve and whatnot. Do not rely on stars on GitHub, number of commits, because all those metrics can be spoofed easily just like on social media. Instead, what you want is high quality code and commits, which will increase your brand recognition among engineering minded folks and attract talented and passionate people to help with the project.

The other thing is to have a product mindset. Treat the software you’re building as a product, it just happens to be free. The target audience is people like yourself because whoever uses your software will likely be in a similar situation and have similar use cases as yourself. You want to go for quality, and not quality, and think about the first time contributor experience as a marketing funnel. So treat your project ReadMe like a product landing page, when other developers try to figure out what the software does, how it works, and how difficult it would be for them to use the software. Depending on how well you check the boxes, people will consider contributing to your open source project.

The last thing is to allow yourself to be vulnerable. Being able to receive criticism is important, even when the criticisms aren’t constructive. Always admit when you realize you’ve made a mistake or have misspoken. And lastly, never take things personally, but stay professional no matter what.