Twitter github

The Open Source Developer’s Dilemma

Over a couple frosty beverages yesterday, I had a lively discussion with a colleague about open source contributions from a developer’s perspective. In my opinion, open source developer’s have to walk a fine line when it comes to working with new contributors and not killing all of your time while doing it…

What do I mean here? Well, when you get a contribution it’s pretty rare that the contribution is just perfect and ready to be submitted to the main line. The reality is that you get contributions that generally need some form of tweaking before they are ready for the world. It’s the tweaking where things get interested. There’s two attitudes you can generally take.

The first position is you can simply be happy that you got a contribution in the first place and just make the necessary tweaks your self and push it to the mainline. The upside to this is that the contribution actually gets contributed quickly. The downside is that this consumes a bit of your time to polish the contribution and that you may also miss out on the opportunity on cultivating a contributor. The second position is that you can do a thorough review of the patch and force a contributor to polish the contribution to meet your standards. The upside is that your this may result in higher quality patches from contributors in the future. Heck, if contributors become really good, they may even make the jump to a full blown committer on your project. The downside is that patches may go stale because you may discourage contributors if you ask too much from them.

I’ve seen both approaches in a variety of open source communities. I’m generally happy just to get a contribution from anyone. I don’t think there’s a silver bullet approach in the way you treat contributors, you probably have to do things on a case-by-case basis. In the end, I felt like I needed to do a brain dump of the discussion I had yesterday. On top of that, I find the question of how to attract contributors without killing all of your time while keeping quality high… just fascinating.

What do you think about this problem… from either a developer’s or a contributors perspective?

  • Laurent Goubet

    I usually try and take the third option : be happy that I've had a contribution, make the necessary tweaks … and send comments to the contributor as to what was necessary to do, provide her/him the tweaked patch, and hope s/he takes it into account for the next patch.

    I admit this is even more time consuming that your first option … yet I hope this time I take for all patches will be rewarded by 1) not scaring the contributor away and 2) have the contributor provide patches more aligned to the code style next time.

  • I think we can learn something from the Git community here. Have a look at their mailing list:

    http://news.gmane.org/gmane.comp.version-contro
    news://news.gmane.org:119/gmane.comp.version-control.git

    It's amazing at which rate patches are flying through the mailing list and how fast the contributors get back high-quality feedback. It's also amazing that there are a lot of patches for smaller things, like fixing a documentation bug or adding cmdline options etc.

    I'm pretty sure this is a lot more motivating for contributors than the Eclipse-Bugzilla-Patch-Queue situation. I was thinking recently what contributes to this:

    – getting feedback quickly is motivating contributors a lot, this probably has a snowball-effect
    – making the flow of patches visible convinces others to also write patches, esp. as a lot can be learned from looking at a patch (patch says more than 1000 words)
    – patches via mailing list seems to be easier to handle for C hackers than Bugzilla/Mylyn for Java Hackers, esp. as you can have a completely automated Git command line workflow to try/accept/reject patches

  • Hi Chris,

    Good Question!!!

    Laurent Goubet gave a good answered about “third option”.

    In my humble opinion, when a contributor receive a feedback(i.e positive/negative) you encourage him/her.

    I love Eclipse, Open-Source community because always help us.

    I agreed with Ralf Ebert because when I received feedback in the eclipse patch I felt very good, and I learned more.

    Performance improvement: Feedback is essential to learning.
    Motivation: They want to contribute to solutions, not be the cause of problems.

    I read in interesting book called: The Art Of Community (http://www.artofcommunityonline.org/) written by Jono Bacon.
    Bacon takes you through the different stages of community.

    Cheers

  • Hi Chris,

    Good Question!!!

    Laurent Goubet gave a good answered about “third option”.

    In my humble opinion, when a contributor receive a feedback(i.e positive/negative) you encourage him/her.

    I love Eclipse, Open-Source community because always help us.

    I agreed with Ralf Ebert because when I received feedback in the eclipse patch I felt very good, and I learned more.

    Performance improvement: Feedback is essential to learning.
    Motivation: They want to contribute to solutions, not be the cause of problems.

    I read in interesting book called: The Art Of Community (http://www.artofcommunityonline.org/) written by Jono Bacon.
    Bacon takes you through the different stages of community.

    Cheers

  • Perhaps there is a 4th approach, which is for those who don't have the time to be committers, but do have the time to do code reviews (in my case, I've started following the eGit gerrit, and it looks a great tool for community based polishing and feedback).

    Naturally, the downside is that beer and exercise time should be kept in balance with desk time, something I've found frustrating reading your blog Chris, as I'm currently sat on the sofa wrapped in a duvet feeling like crap, and I'd really like to get to Russ's inaugral Cambridge Java User Group meetup (http://www.meetup.com/Cambridge-Java-Group/cale…) tomorrow (and be able to drink beer).

  • I like Gerrit a lot too Neale. One of my goals at Eclipse is to get a global Gerrit instance for all of Eclipse Git repositories. It's working really well for the Android project and I think we can reap similar benefits.

    In terms of beer… I'm sorry you find my blog frustrating sometimes 🙂

    I find that working in open source has improved my both desire and taste for quality beer. You should totally hit up the JUG meeting for a tasty frosty beverage!

  • Perhaps there is a 4th approach, which is for those who don't have the time to be committers, but do have the time to do code reviews (in my case, I've started following the eGit gerrit, and it looks a great tool for community based polishing and feedback).

    Naturally, the downside is that beer and exercise time should be kept in balance with desk time, something I've found frustrating reading your blog Chris, as I'm currently sat on the sofa wrapped in a duvet feeling like crap, and I'd really like to get to Russ's inaugral Cambridge Java User Group meetup (http://www.meetup.com/Cambridge-Java-Group/cale…) tomorrow (and be able to drink beer).

  • I like Gerrit a lot too Neale. One of my goals at Eclipse is to get a global Gerrit instance for all of Eclipse Git repositories. It's working really well for the Android project and I think we can reap similar benefits.

    In terms of beer… I'm sorry you find my blog frustrating sometimes 🙂

    I find that working in open source has improved my both desire and taste for quality beer. You should totally hit up the JUG meeting for a tasty frosty beverage!