How to become an amazing contributor (to an open source project)

No readers like this yet.
Participation text on a field

It's a busy morning here in New York City. My email inbox is full of pleasant surprises. The first is a patch for one of my open source projects. A second will appear this afternoon. A third should come late at night—or maybe tomorrow–from a new contributor.

Alongside my day job, I contribute and manage open source projects. The number of projects I work on has grown from a couple of small tools to well over a dozen in the last three years. Open source has become a great way to learn new technology, experiment with modern software development practices, and, of course, meet other like-minded engineers. I find that seeing great contributors send working and tested code provides a unique feeling of accomplishment, as powerful as having many satisfied users of my own applications or strong revenues posted by the employer that pays my bills.

I asked the three engineers who sent patches in the past few months to tell me more about their story. First, I wanted to know what motivated them to contribute.


Nicolas Guillaumin works on the R&D team of Funnelback, a search engine technology and services company located in Dickston, Australia. My first connection with Nicolas began as a comment for WAFFLE workitem #8559:

"Please find attached a patch. I've done a basic implementation of … [this thing that everybody wanted and nobody cared to implement].

I asked Nicolas to explain what pushed him to become a contributor:

"We were investigating porting our web application from Perl to Java and we needed a way to replace some features provided by IIS like SSO and impersonation. We came across various possible solutions for authentication such as Spring Security and JAAS but WAFFLE seemed the simplest and cleanest one. Moreover it's the only one that had impersonation support, at least on the low level APIs, and extending it to implement impersonation in a Servlet filter seemed easy enough. Contributing was also straightforward: the framework is small, simple to understand and well documented."

Rami Abughazaleh works for NovaStor, a backup software and data protection company with an office in Agoura Hills, California. Today, he commits to several related open source projects in the Windows deployment space, including dotNetInstaller, a popular bootstrapper for Windows.

"We use dotNetInstaller in production and needed a few bug fixes and a couple more features. At first I felt grateful to find an open source solution that met all the requirements for my employer, which in turn made me look good at my job. Then, I wanted to contribute some of my time to thank the people and the community that started and continue to improve the project. I also had a personal quest to learn and gain more experience with various new tools."

Neil Sleightholm runs X2 Systems Ltd., which provides IT consultancy in Southwest England. He has notably implemented install-time permissions elevation in dotNetInstaller (#7968).

"The project did 95% of what I needed; commercial applications either fell short or were too expensive for the small part of them I wanted. It seemed cost-effective to spend my time adding the features I required. The quality of the code impressed me, so I knew that it was worth investing effort to get a reliable system. In particular, I don't think I have ever come across a project (open source or commercially developed) that had such a sophisticated unit test program. This meant I felt confident to add features without breaking existing code. Plus, the project co-ordinator was willing to assist with programming issues."


These are good stories! But what made Nicolas, Rami, and Neil great contributors? I thought about this a while, and considered what they had said, what I think when I'm contributing, and what I've seen happen in communities like these.

I came up with a list of the things that I value most in contributing engineers. Displaying these qualities will make you an excellent—and likely well-received--open source developer.

  1. Have a real problem to solve, business need, or some type of commercially-driven motivation.
  2. Understand the goals of the project and make sure your contribution is in line with them.
  3. Submit complete patches that implement full features. Include any test information and documentation.
  4. Play by the rules of the project that you're contributing to.
  5. Be humble. Never add your name to the list of contributors yourself—the project leader should do so, if she or he values your work.
  6. Have low expectations. Learn to accept rejection.
  7. Persevere. Improve upon comments and keep sending updates.
  8. Be honest and vocal about your available time and skills.
  9. Be a doer, not a talker or a troll.
  10. Finish what you started, don't give up.

This is my list of core values that I encourage my contributors to cultivate. If you're an open source project leader, what do you value most in your contributors? If you're an open source developer, what are the rules that you follow? Does my list fit your worldview? I'd love to hear from you in the comments.

User profile image.
Head of Engineering @artsy. Follow me @dblockdotorg.


Great article. My only comment is on item 6 in your list of core values. In this case I think maybe it needs to have a 6a an 6b.

6. Expectations.
a. Have high expectations for yourself and the work your provide.
If you expect yourself to consistently provide quality work, you will.
b. Have low expectations for how often your work will be accepted
without comment. Learn to accept rejection.

Again great article.

Very good point, thank you.

Enlightening article, especially for me, an aspiring contributor.
I'm willing to share this <a href="">link</a> to a great article titled "Diaries of a Core Maintainer: A tale of two developers" from Drupal Core contributor Angie Byron. It shows how a newbie contributor can gain acceptance among other "dinosaur" contributors just by being humble, honest and armed with enthusiasm and perseverance, the article shows also how a good developer could be unaccepted in the community if he dives into solo-work and isolate himself from the community scratches.

this was a really honest and useful list. Thanks for sharing!

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.