Make Something Great: Become an Open Source Contributor

My first contribution to Bootstrap was a tiny line of CSS. It was a no-brainer to merge, but the feeling of seeing that bit of code in the project’s codebase was unreal and addictive.

You may think that open source is not for you. After all, it has always been a developer-dominant ecosystem. But code is by no means the only thing a piece of software is made of. Open source is first and foremost about community. Whether you’re a designer, developer, writer, doctor, or lawyer, there are many paths to the open source world.

Learn what you need to know to set out on your journey, from first steps to becoming a core contributor. It might change your career.

It’s OK if you don’t code#section2

Developers think about their work logically. They break problems down into solvable pieces to make things work. They will devote themselves to crafting an API or a data structure, and optimize those solutions for performance and reusability. Unfortunately, this deconstruction often results in a Swiss Army knife of an interface, with a design that reflects the underlying data structures and APIs available.

This is why the open source community needs you. Not only diversity in perspective, but also diversity of gender, location, cultures, and social backgrounds. Together these become greater than the sum of their parts.

Designers#section3

Most people who contribute to an open source project are also users of the software. But designers look at the project from a different perspective. Their job is to defend the user, especially those that are not able to contribute to the project but still need the software. They make sure that everyone working on the project understands users’ needs and stays focused on them as the community makes decisions.

Writers#section4

Let’s face it: writing is really hard! Designers and developers are usually bad at it. But it’s so valuable to an open source community, where members have to collaborate and communicate remotely, asynchronously, and, more often than not, in a non-native language.

Documentation, especially on open source projects, is rarely up-to-date. It’s worse when it involves the documentation meant for contributors. Information for getting started with a project frequently has gaps, with important information missing.

Also, like developers who dedicate themselves to different pieces of a software project, different types of writers can contribute to different pieces of a project’s messaging. They can team up with designers and subject matter experts to write copy for user interfaces, landing pages, or help documentation.

Geertjan Wielenga was a technical writer in the NetBeans community. Through his documentation, articles, and getting-started guides, he helped thousands of Java developers navigate their way around the project. His contributions had a profound impact, and he became the most acclaimed person in the community.

Without communication, you have no community. What you write may be the reason why someone decides to get involved. It can make the difference between someone feeling welcome or feeling lost. Your contribution as a writer is invaluable.

Developers that don’t want to code#section5

Coding is optional; even software developers don’t always code. There’s administrative work too! Replying to issues, reviewing contributions, and helping users on forums, chats, Reddit, or Stack Overflow is as important to the success of the project as writing code.

Subject matter experts#section6

Participation in open source projects is by no means limited to software engineers, designers, and writers. Lawyers, other engineers, and even medical doctors and other specialists can find a place to apply their knowledge too.

So if you thought open source projects were just for developers, think again. There is a place for you and every single contribution is important.

Why bother?#section7

In 2013, Jay Balunas, the cofounder of AeroGear, a small open source project, saw that more than 85% of its Android code was written by a single developer: Daniel Passos. Jay had received some funding, so he reached out, offering him a job on the spot. But Daniel turned it down.

Why would someone turn down a paid position and want to continue working for free? Passos lived thousands of miles away, in Rio de Janeiro. He also didn’t speak any English.

Not about to lose a great developer that had already proven his worth, Jay solved the problem. He made the position remote, and sent an English teacher to Daniel’s house every week.

This story may sound too good to be true. But this may describe the careers of more people than you think—people who did not start out contributing to open source ever expecting anything in return. They would probably describe their experience starting out as a labor of love.

Getting a job offer shouldn’t be your only motivation to contribute to an open source project. If it is, you’ll likely be frustrated with the results.

Working for free#section8

You may have a problem with working for free, especially when there seems to be plenty of well-paid work to go around. Why should you work in a vulnerable environment with total strangers, without ever receiving compensation?

On a professional level, among the biggest assets you have are your connections. But not everyone lives in a major tech industry area. Not everyone can attend industry conferences or participate in hackathons. The open source community opens a network of passionate and talented people from around the world. To become part of it, you don’t have to worry about whiteboarding exercises, interviews, or whether you have a degree from the right university.

But you may be disappointed if you contribute to an open source project just to get a job. Open source is volunteer work, just like helping other not-for-profit and community organizations that need people in order to stay open and reach as many people as possible. It should be approached from a place of wanting to give back to your community and contributing to a worthy cause.

Still, good employees are hard to find, and it’s often not a question of a person’s technical skills. Many companies today require applicants to participate in a months-long interview process, and complete hours of coding and design challenges that are unpaid, are unrecognized, and become the company’s property. In the case of Daniel Passos, by contributing to a project over time, he was able to demonstrate what he was capable of building, how he collaborated with others, and how passionate he was. This let him get past job requirements that aren’t related to the work but that are used to deny qualified job applicants all the time. This results in people who pay it forward: Daniel has since mentored many people in the community, including me.

As a contributor, you will be able to experiment and play with bleeding-edge techniques at a scale that you would hardly find on a personal project or in a hackathon scenario. It’s also an opportunity to continue working with technologies that you might not get to use anymore in other work. And if you have been away from making things for a long time, an open source project is a great way to get back on track.

Last but not least, it’s hard to explain with words the feeling you get when your name appears on a project. The positive feedback loop of being part of something larger than yourself is what makes open source addictive. Just ask what happened when a couple of people took over the blogging tool b2 when it was abandoned by its creator.

Finding your community#section9

If all of this sounds good to you, it’s time to find your people. Start by taking a look at what you like and use. Ask yourself what problems you would like to solve. If you are passionate about something, there is probably a community around it.

If you enjoy working with a particular technology, you have options spanning the entire programming realm. For example, if you are like me and enjoy working with CSS, you can contribute to projects like Bulma, Bootstrap, Tachyons, Tailwind CSS, or Foundation, or design systems like Primer, PatternFly, or Lightning, among many others. GitHub has a great open source explorer you can use to find a group.

If you would like to work on use cases that you don’t get to in your day job, like healthcare software, for example, you can find lists of active projects by area and see what kind of contributions they need. OpenMRS is a great example of a project that benefits people outside the industry and that would never be successful with millions of developers but no designers, writers, or subject matter experts.

Respect#section10

Brian Leathem, a notable open source developer, describes working on an open source project as being like working behind a glass wall. Every single action you take will be visible, transparent, and recorded. This makes you vulnerable, but a healthy community will make you feel welcome and comfortable. Check your project’s code of conduct before you contribute. Never tolerate harassment, bullying of any kind, or unkindness. If it happens and the members don’t act swiftly to enforce their code of conduct, they don’t deserve you.

Communication#section11

Having said that, it’s essential to have a thick skin. Frame any criticism you will receive as a learning opportunity. When interacting with others, commit to setting aside ego for something bigger. Be humble, stay positive, have good arguments, and remain open-minded.

Being able to connect with people who are very different from you will be critical. You may collaborate with someone from a part of the world where communication styles and customs are different. For example, some cultures expect you to be very assertive if you care deeply about something. This is very different than cultures where it’s impolite to disagree in an open forum.

Trust#section12

As you take your first steps, you might notice that thriving open source communities are supported by people who trust each other. Learn to trust and to be trusted by showing what you are able to do, admitting when you are wrong or don’t know something, and letting people do their work. Approach your first contributions from a place of humility. Once you gain an understanding of how people like to work with one another, you will be able to make a bigger dent with bolder contributions.

My very first contribution was to AeroGear, a small open source project. I downloaded the codebase to my computer, made my design changes, zipped the files, and sent an email to the community mailing list.

To say that the community had trouble understanding the improvements I had made to the user experience would be an understatement. I felt terribly lost, and a little rejected. I really wanted to become a part of this open source project, but I didn’t know where to begin. So I asked for help, and the community had endless patience with me, even when I destroyed the repository a few times.

The toolbox#section13

To participate in an open source project, you will need to shed any fears you may have of using the command line and working with version control. However, many open source projects are hosted on Github, where you might be able to avoid some of this if you do not code and are posting sketches, making changes to copy, or writing documentation.

The command line#section14

Level Up Tutorials has a great video series about the command line if you are a visual learner. Their Command Line Basics #1 video is a good place to start. If you prefer to read, Remy Sharp’s Working the Command Line is excellent.

Git#section15

For getting started with version control, GitHub has a great step-by-step guide to Git. There are many Git desktop apps like Sourcetree, GitHub Desktop, or GitKraken that will help you visualize what Git does. I still highly recommend becoming familiar with the Git command-line tool. It’s a steeper learning curve, but you’ll get a return on your investment.

Communication channels#section16

Every community has its communication channels. There is almost always a mailing list where the most important decisions are made. GitHub’s Issues feature is used for contribution issue tracking. Forums are common for user discussions.

Chat among contributors has traditionally been on IRC, but Slack, Rocket.Chat, and Gitter have become more popular, including for user discussions. Find out where your community hangs out, and get to know its members.

Making your first contribution#section17

The harder part of getting started with open source is finding a community and becoming familiar with how it operates and communicates. If you have cleared that hurdle, you are more than ready to begin contributing. Start small, and be nice.

Look at the issues for a small task you feel comfortable doing. On some projects they are tagged as “help wanted” or “good first issue.” Documentation is also a great place to start. Go through the “getting started” guides and see if they make sense to a newcomer, like you. Can you improve them, make them more clear? Look for a typo or a grammar mistake. Contributions like these are easy to merge and are a perfect starting point.

If you want to contribute to a project in ways other than working on the code, these issues are good ways to introduce yourself and what you can do. For example, if you are a designer, a project will sometimes, but not always, be looking for UI designs. But in most cases, even on projects with very little UI, like a utility or a service, there will be usability problems that need solutions. By starting with pointing out unclear information and offering lots of quick solutions to a problem, you can start to demonstrate both your expertise and your passion.

Sometimes, changes or further explanation will be requested. Other times you’ll break things, and that’s OK. I once sent a pull request that messed up the border radius of Bootstrap buttons. I hadn’t tested the result. Mark Otto, the leader of the project, took the time to write a comment explaining where I made a mistake and how I might fix it. He didn’t have to do that; I should have known better. The gesture and the respect for my time as a contributor made me want to help the project even more.

Leveling up#section18

Here is a secret: you don’t need to make a ton of commits to become a top contributor. React is probably the most active open source project today, and to become a Top 100 React contributor, you only need to merge five commits. They can even be five typos that you’ve fixed in the docs! And you can make an even greater impact in smaller communities with that level of contribution.

Commit to contribute#section19

If you value the idea of open source, you are worthy of contributing to a project, earning recognition, and being a respected member of a community. If you have different expertise, experience, or points of view about a project, we need you even more. At the end of the day, without people contributing to the community, the web will not remain open and free.

Rachel Andrew goes on to write about how she’s seen people of her generation taking a step back, as she started to feel the pressure of the finite amount of time she has. Pioneers of the modern web like her paid it forward. Can you?