Open source has been a huge part of my life since the 1990s. My work in open source has gotten me a job, introduced me to many new friends, made me more productive at work, and made my time spent programming more enjoyable. And I like to think my contributions to and leadership of open source has helped others as well.
Years of working in the open source community has put me in contact with hundreds of other contributors, and I’ve noticed that the great ones seem to share a certain set of traits. Surprisingly, awesome technical skills do not top the list.
If you’re thinking about contributing to an open source project, but you’re intimidated because you don’t think your tech chops are up to snuff, I’ve got good news for you. These eight factors are the things that really matter as a contributor to an open source project. Even better news, many of these abilities are things you can improve over time.
1. Strong writing ability
Almost everything done in open source is done through the written word. Documentation, bug reports, discussion of implementation—everything is written out and your message must be easily understood. Lots of people can code, not as many of them can clearly communicate what they’ve done.
No one contributes only code to a project. Code must be documented, and patches contributed to the project should include a summary description of what’s been done. Without clear explanations of your actions and their intent, the chances of your code being accepted into the project are greatly diminished.
Clear writing also affects how many people are likely to use your project. A website that makes it easy for users to understand your software, and well-written documentation to go with it, means that people are more likely to use and contribute to the project.
2. A bias for action
Great contributors tend to make things happen. They put in the effort to not just identify problems, but also to solve them. Rather than being content with just writing a bug report, or posting to a mailing list about an error in the docs, a great contributor writes a bug report that also includes a fix, or submits a patch to the documentation.
That doesn’t mean if you can’t provide a fix, you shouldn’t submit a bug report. Reporting a bug is one of the most important things that a project’s user can do. Taking action to fix it, however, takes the bug report above and beyond.
The flip side of working to make things happen is patience. Open source is a collaboration between many different people with many different priorities. Just because one person on a team has a crucial need to fix a bug doesn’t mean that others on the team are able to drop what they’re doing to solve the problem.
The other people working on a project likely have very different lives than you do, and their priorities may not match up with yours. Work projects, vacations, and family are some of the most common things that can push back a response to your needs.
An extreme example of an open source project taking a backseat to real-world concerns happened a few months ago in the DoctrineEnumBundle project, hosted on GitHub.Back in January 2014, GitHub user @bendavies submitted a pull request, to which project owner @fre5h replied, “I will take a look later. Much much later. Because I’m Ukrainian and we have revolution right now. Sorry.” Chances are that most people running the projects you contribute to won’t be in the middle of a country in political turmoil, but everyone has different priorities of which you may not be aware.
4. Strong sense of teamwork
Open source is a team sport. Although some projects are run by one person, most projects seem to be run be a core handful of contributors who get most things done, supported by a much larger group of people who watch from the outside and make smaller, less frequent contributions.
The best contributors understand and respect the contributions, questions, and concerns of everyone in the user base, regardless of technical skill or status in the group. The contributions of everyone on the team, whether the core team or the fringe, has value. Even a terrible, broken patch that you would never accept into the codebase still informs you of at least one user’s need.
Conversely, great contributors understand that even if their contribution is not a large one, it is still worth their time and energy to add to the project. They also knows that their wishes for the project may be outweighed by other factors, but that raising those wishes and ideas is still valuable.
5. Kind and empathetic
Participating in an open source project can be an emotionally harrowing experience for newcomers (and for many veterans, too). Putting out your work for consideration on a project puts your ego and self-esteem at risk.
The best contributors understand that the people at the other end of an email thread, or talking in IRC, or discussing a bug in a GitHub issue ticket, are also human beings who may not always have a lot of confidence in their skills and value. Great contributors nurture and bring forth the best work from others by being encouraging and helpful.
When presented with a contribution that doesn’t meet the standards of inclusion in a project, strong contributors won’t simply point out its faults and reject the contribution. Instead, they may work with the author to help them understand what improvements need to be made to bring it up to the level of quality the project requires. They may also choose to simply do the work themselves, show the newbie contributor what had to be improved, and then accept the patch, because they know that initial patch is a golden opportunity to bring a new member into the fold.
Human time and interest are rare commodities in an open source project. They are resources to be carefully guarded, not squandered just because an initial contribution didn’t fully measure up.
6. Guards the codebase carefully against technical debt and ongoing costs
Strong open source contributors work to strike a balance between new features to a project and the costs of maintaining the project. They know that every line of code adds to the cost of maintaining the project and is another place for bugs to show up. They understand that there are no free patches.
7. Knows their limitations
Open source projects rise and fall in importance to the maintainers. What was once a favorite project can gather dust in the corners of GitHub when attention is focused elsewhere. It’s important for project leaders to know when to hand off their projects to someone else.
Over the years, I’ve passed many of my Perl modules off to other authors who had more time and inclination to do the work that needed to be done. Sometimes I did it because I felt like I had no new ideas. Sometimes it was because the work I was doing at my day job no longer used the module. Unfortunately, for some projects I hung on as owner too long, letting them lie neglected for years, stalling innovation and improvements.
Handing off a project isn’t a sign of failure. It’s just an acknowledgement that needs and priorities are fluid and things change over time.
8. Programming skills
Last, and least, on the list of important traits of an open source contributor is programming skill. Every other trait in my list would be filed under “soft skills.” Why’s that?
First, there is plenty of work to be done on open source projects that don’t require coding. For example, documentation needs to be written, user questions need to be answered, websites need to be updated, and test suites need to be run on various platforms. None of these require writing a single line of code, much less doing it with great skill.
Second, for many tasks that do require coding skill, programmers who can write code well are a dime a dozen. It’s much harder to find a programmer who is patient, writes well, and can write well for humans.
Over the years, I’ve talked to many people who have wanted to contribute to open source projects, but think that they don’t have what it takes to make a contribution. If you’re in that situation, I hope this post helps you get out of that mindset and start contributing to the projects that matter to you.