Its hard to imagine a world without open source software, the most significant force multiplier for the software industry. Open source software is so prevelant that we often take it for granted that critical software should be open source and free to use. This includes anything from databases to cryptocurrencies to programming languages.

Open collaboration and free use of projects isn't the norm across industries. Imagine trying to explain how open source to someone outside the software industry. If you say "the world depends on this software that engineers write in their free time, without compensation", you'd be right and your friend would be puzzled. Open source is confusing and I rarely see explinations around why and how it works and why one should contribute to open source. In this post I'll discuss what open source is, why it works, and how you can start contributing to open source.

What is Open Source?

At its core open source is about finding solutions for problems and sharing those solutions with others.

David Heinemeier Hansson, the creator of Ruby on Rails, summarizes this well:

My core philosophy about open source is that we should all be working on the things that we personally use and care about. ... if we work on the things we care about and then share those solutions between us, the world gets richer much faster.

Why open source works

A commonly misunderstood aspect of open source is its incentive structure, a critical component of successful open source communities. I'll start by making an argument that might run contrary to your intuition: it's in the best interest of individuals and organizations to open source certain projects. For companies, this usually means open sourcing projects their product depends on, not the product itself. It's quite common for a company's competitor to depend on software it has open sourced. The counterintuitive idea of competing companies collaborating on software baffles many who are new to open source, but to insiders, it makes perfect sense.

Open source is a Nash equilibrium between competing companies, meaning organizations with opposing interests can collaborate in such a way that each organization better off than it would be working independently. Microsoft and Amazon, fierce competitors in cloud computing, make frequent contributions to the Rust programming language and its surrounding ecosystem. Each contribution made by one organization benefits itself and all other organizations that depend on the project. It's in the best interest of existing contributors to the project to onboard new contributors, which implies more contributions. Concisely, open source projects thrive off of network effects. Similarly, increasing a number of users of a project also benefits the project since frequent users are likely to eventually become contributors.

Benefits to contributors

The benefits of open source to software communities and ecosystems are quite hard to ignore. However, what's rarely discussed are the direct benefits to individual open source contributors.

"Why would anyone work for free?"

This is a good place to start. Contributors don't see open source as work; instead, they see it as an outlet for creative expression and experimentation, an opportunity to dabble in new domains of software engineering, and a way to be part of a community. Additionally, contributors have the flexibility to switch between projects, choose what and when they contribute, and even choose if they want to contribute at all.

Forms of open source projects

Open source projects largely fall into four categories:

Category Characteristics Examples
single owner, single contributor unmaintained, few users
single owner, multiple contributor frequently maintained, many users three.js
single organization owner, multiple contributors frequently maintained, many users typescript, react
distributed ownership, multiple contributors frequently maintained, many users git, rust

Open Source in 5 Steps

1. Open source your projects

One of the easiest ways to try something new is to try the easiest version of that thing. One way of making something easier to do is lowering the barrier to trying that thing. The easiest way to get started is to open source projects you already have, whether or not you want to contribute to them later on. I recommend this for two reasons: (1) it showcases what you've worked on and (2) it helps you practice open sourcing projects and showcasing them well. If you want to bring attention to certain projects, use GitHub's pinned repositories feature to highlight them. Don't worry about your projects being new or ground breaking, since your first goal should be to showcase your interests. Consider open sourcing notes or other kinds of organized information that could be of value to others. These projects tend to be some of the most popular while also being the easiest to bootstrap and contribute to.

Below are some examples of popular lists and notes:

A common pitfall I see is lack of communication around projects. It's common to see projects with profound technical accomplishments that are very poorly understood. These projects usually lack READMEs and channels for discussion such as Slack, Discord, or the new GitHub discussions feature. I've outlined a set of high level tips for project communication that you might find useful.

2. Pick a project

After adding your projects to your GitHub profile, decide on a project you want to contribute to.

There are two ways you could go about finding a project you want to contribute to:

(1). Pick a project you depend on that you want to improve. That project, for example, may be lacking certain features you require, difficult to use, or suboptimal in performance. If you're actively working on a project and you find a dependency lacking certain features you depend on, contribute these features.

(2). Find the problem spaces you are interested in and pick an actively maintained project in the problem space you find most interesting. If the project has been inactive for over a year I recommend considering another project. Be careful to not pick a large project as the first project you contribute to since they tend to be harder to ramp up on.

Most existing contributors tend to favor option (1) since it adds immediate value to themselves and the community. It also has a much clearer end goal compared to (2). Option (2) is ideal if you are already a software engineer who's dabbled in open source and your primary goal is to ramp up in new problem spaces. Most who are new to open source try to start with option (2) but the immediate and practical benefits of option (1) make it a better option for most.

3. Start contributing

Once you've picked a project, decide what you want to contribute. Contributions can include anything from helping answer questions in the community to helping resolve open GitHub issue tickets to adding or improving documentation. Again, lower the barrier to contributing by finding the easiest way to contribute. Contributing these small improvements can be seen as ramp up tasks which will eventually familiarize yourself enough with the project to contribute more technical changes later on.

After you're familiar enough with the project, try addressing more technical aspects of the project. This includes bug fixes or implementing small features. For larger changes, ask the project's maintainers if they will welcome the change you have in mind. Don't hesitate to ask the maintainers for some guidance around what you want to contribute.

Maintainers vs contributors

When you think it's appropriate, reflect on whether you want to be a contributor or a maintainer.

I often see open source beginners think of making one time contributions to open source projects as a learning experience. This makes sense but it’s often a much better learning experience to be a long term contributor to a project.

Long term contributors learn to take ownership for changes they make to a project. This is comparable to the experience of a full time employee. They have the opportunity to see a project to completion and observe how it evolves over time. One-off contributions are analogous to contract work. Depending on the project, long term contributors can also be much more aware of customer demands in the problem space. This can give them an edge in understanding new challenges and seed ideas for new projects.

Becoming a Maintainer

So you've now found a project and you've made a number of contributions to it. You're excited about its trajectory and you're fascinated by its technical capabilities. You've familiarized yourself with the project and you've made a number of ramp up contributions. What then?

One option is to expand your role and influence in the project. If you disagree with the roadmap, start a discussion with the maintainers and share your suggestions. This is about as far you can go as a contributor. To have greater influence on the project, you'll need to join the core team of the project or, in open source jargon, become a maintainer.

4. Join a Community

Listen to the conversation

Twitter is the platform of choice for open source maintainers and the tech community in large.

Twitter is a tool -- use it with intention and browsing your feed will be analogous to listening in on a conversation amongst the greatest minds in the field.

You’re the average of the five people you spend the most time with.

Use twitter to surround yourself with great engineers and you will learn so much. You can listen to their opinions, see them clash, see their predictions in the problem space, and see what they identify as key problems.

Join the conversation

Actively participate in conversations that you find interesting. If you have questions, tweet about what you're working on.

Once you build something new, tweet and blog about it.

5. Stay in the loop

Stay on top of recent news and trends. Paying attention to new ideas can hint at some suggestions for new project ideas. I recommend subscribing to the domain specific and generalist newsletters.

Generalist

Domain/language specific newsletters

Appendix

Recommended Readings

I hope you now have a bit more insight on where to get started in open source. If you feel like I have missed certain topics or if you have questions please feel free to comment or reach out.