Helping Companies contribute to Open Source

6 min readJan 24, 2023

Key points:

What is the company’s aim? Why do you want to take part?
Getting started is the hardest thing — we want to help people Make The First Change
As a contributor, improving small projects is good for getting started and “when you find something missing” — improving medium projects is good for long-term sustainability
To allow contributions, minimize time to first commit for contributors; to make the code useful, minimize time to first value for users

Understand your goals

Once a tech company gets big enough, it may wish to get involved with Open Source projects. “That’s what big companies do” sometimes comes as a reason, but it usually masks a deeper reason, the ‘why’ of those bigger companies.

Understanding your aim as a company will allow you to better focus your resources on achievable goals.

“We want to help the Open Source community that’s given us so much”

This is a laudable goal, but if you want to maximize cost-effectiveness as a company, my advice would be to donate money to Open Source projects you use. It is generally more efficient for people already developing those projects to continue doing so, unless you already have a team that deals extensively in something specific.

“Big companies have big OSS projects to their name, we want in”

This is very rarely an achievable goal by itself, it can only come as a side effect of having something useful to contribute and working on it very hard, which comes as a result of the final goal.

In this article we will be focusing on the following two goals:

“Having our developers work on Open Source will make them better developers” -> improving existing repositories“We have developed something unique that we can contribute to the community” -> being an owner

Maybe you do! But Open Source projects have to be useful to many people to actually be, well, useful — this too

“Digging into source code” is more a psychological standpoint than a technical one; The biggest roadblock to contributing to Open Source is the very first PR.

Once someone has done it once and they know the process, adding a second, third, etc becomes a simple matter.

What this means is that to promote Open Source contributions, both for owners/maintainers and contributors, the goal should be to minimize Time To First Commit

This has different practical implications if you’re planning on being Owners or Contributors.

Contributing to Open Source as a company can be done in two ways:

A. Improving existing repositories

The general rule of thumb is, due to Pareto, “the more important it is, the more work has already been put into it, and the harder it is to improve”.

Open source projects usually fall into 1 of 3 categories:

Big projects (over 10,000 stars)

What first comes to mind for many people. Think Linux, OpenGL, MongoDB, React, Android, Python. These things are already in major use and thus already heavily optimized, usually with a big company behind it, which means it will be very hard to get up to the required level to work on these!

Anything above 10,000 stars on Github falls into this category.

Projects that have little use (less than 100 stars)

These probably have a lot of room for improvement and thus can be easily improved. This is a good training ground for people who want to start contributing to open source, but chances are that the build instructions are lacking, there are little to no tests, or other such blockers. Also, the bigger your company is, the less chance you’ll rely on these, since you want something that’s actively maintained and used.

Medium sized projects

This, in my eyes, is the “sweet spot” of company open source contribution. These are projects that are maintained and used, and probably most of your 3rd party libraries fall into this category. These do require some time to set up and figure out how they work and how you can contribute, but you can be relatively sure that you’ll be able to help there

My recommendation is:

Avoid big projects unless you want to dedicate a team to working on it — you’ll need to invest too much time and effort
Help small projects wherever you can — mostly so your developers can experience small wins in helping out, and grow comfortable with the act of cloning a repo to make a small PR contribution 🙂
Medium sized projects are where you, as a company, can really make a difference. These are where you should be aiming to produce long term contributions, and these are the names you’ll put on your “we have helped these projects” list 😉

SO, if minimize Time To First Commit is the goal, what can you do to help?

Have people in your company tell about how they contributed to projects, so others can see that Open Source isn’t reserved for people like Linus Torvalds — people like them can help out too!
Drive home that the contribution doesn’t need to be perfect, it just needs to be better than what is! Even fixing a typo in documentation is a contribution, and it’s better to start small! (My first contribution was adding a single missing field in what amounts to a type documentation)

This one is mostly speculative, as in “what would I do to get people to contribute”:

Designate a “Helping Open Source Week”, during which anyone can mail you which Open Source project they contributed to to get something small and permanent — like a keychain with the words “Open Source Contributor” or whatever.
At the end of the week, hang up a big poster with the names of everyone who contributed and what they contributed to.

The important things are:

Seeing that lots of people did it shows that it’s possible for anyone
Seeing your own name on that board is cool, and “feeling cool” is a big part of what makes people keep working 🙂
The small, permanent thing (keychain or equivalent) stays with them as a reminder that They Did It. Since it’s mostly a mindset thing, we want to reinforce their self-image as People Who Can Contribute To Open Source, and that’s what the small thing does every time they notice it

B. Being an owner

This means taking code that you already have and making it public. This isn’t my choice A since this is often a cop-out! Since chances are that the library/framework that you’re using is tailor-made for your use, and therefore won’t be really useful to other people and companies. So you’ll put your code up on Github, but no one else will use it — not really “contributing to the community”.

Signs that your code won’t help anyone else:

Uses 4 or more libraries/frameworks together (suited to your architectural decisions), OR
Very domain specific (suited to your specific business logic)

On the other hand, signs that your code will help other people:

Very self contained and solves a problem with a popular framework, OR
Makes 2 popular existing libraries/frameworks work well together

If you have one of the latter, then you can be an owner!

Owners have 2 responsibilities:

minimize Time To First Value, to make the project easy to use and thus useful
minimize Time To First Commit, as previously mentioned, to make the project easy to contribute to

To minimize Time To First Value you’ll want:

Super simple usage instructions (npm install X, import Y from X code snippet example)
Sensible defaults (minimum time configuring initial setup)
Good usage documentation to show what it can do