Cracking the open-source community code for drive-by developers

Jack Repenning, CTO of Collabnet, takes issue with my complaint that contributing code to open-source projects is hard. Jack's suggestion that "while community membership requires more than 'casual contribution,' you shouldn't have to 'become a key member'" in order to play a part is fair and spot-on. Unfortunately, it doesn't really tackle the big issue.

Most would-be open-source contributors don't have time to become anything more than casual contributors. This means that the vast majority of potential open-source contributions remain in their silos and never make it back into the common code pool.

Think about Red Hat CEO Jim Whitehurst's suggestion that enterprises need to start participating in open-source development. I'm going to be speaking at the New York CTO Club in November on this very topic: how do we encourage "drive-by developers" to become full-fledged members of open-source communities?

It's a non-trivial question with much at stake. The organization that cracks this code would likely immediately take center stage in open-source development. It must become easier to contribute to open-source communities if we hope to make open source more than simply an interesting facet of the software industry, and turn it into the central, driving force behind the industry.

[royrusso]

There's no magic here. A system that supports bi-directional dialog leads to just this sort of one-off contribution. Apache, Hibernate, and JBoss are great examples of this, allowing community members to submit code patches either via forums or issue-tracking software (JIRA). As an another example, SugarCRM's forge and exchange lend themselves to more active involvement with regards to extending the base platform - benefiting everyone inside the community. So to answer your question, you encourage active involvement by being inclusive in your community efforts, and sometimes that does mean ceding a bit of control.

[The_Decider]

If I didn't already know it, I would suspect you don't have the first clue about software development or writing code.

Contributing to a non-trivial project is not a casual exercise. It takes time to understand the code, and that must be done before writing code to patch(or even find the buggy code) or add to it. They have to keep on top of what already was done and what is being worked on.

If a person wants to contribute to a project but can't do so very regularly, they shouldn't be writing code. They should be bug testing, writing documentation, stuff like that.

If you start letting casual contributors submit patches and new functionality, anarchy will erupt and your project will spiral down into a total mess.

[Matt Asay]

And yet you graciously keep reading. You're a trooper, The_Decider. :-)

You absolutely do need more than just hard-core project developers involved in a project for it to thrive. Your exclusion above would have 99.999999999% of the planet not contributing code. I doubt that's what you want.

[Mike Dartt]

@The_Decider: Matt's original post focuses less on the technical aspects and more on the "cultural/management" ones such as development priorities. I don't think there's any controversy about needing to understand the code and do development that's consistent with the existing codebase.

While a "Not Invented Here" attitude is one thing (and particularly silly in an OSS project), I understand how the core team would rather do other things than spend their time double-checking code submissions. A few things come to mind for addressing these sorts of issues:
* Published code standards (variable naming, when to make new routines/objects/etc., commenting, etc.), or ones that are clear and quickly grasped from the code
* Requirements for documenting testing prior to submission, whether via existing unit/automated tests, or through some other means
* Requirements for documenting the changes made at a high level

These sorts of practices could make it much easier for the core team to quickly evaluate contributions and encourages better design on the part of the contributors. The testing documentation could also be used by future contributors as models or starting points for their own tests, while the high level documentation is a starting point for end-user documentation.

[The_Decider]

My point is important, even if he is ignoring it. Casual developers should not contribute code.

Following code standards is all well and good but doesn't address the problem of people writing code for a system they don't understand.

Documenting testing is not the same as proving that you tested and that your tests are even relevant.

What good is it to document the changes when the changes just broke a good chunk of your program?

The fact remains, if you only have time to contribute once in a while, you likely didn't have the time to learn the software. => You should not be writing code for it.

[The_Decider]

I do agree with: ""Not Invented Here" attitude is one thing (and particularly silly in an OSS project)"

But there needs to be true standards on who can submit changes and your 3 bullets, while important do not address the issue to the point where opening up development to more people is a sane idea.

This is one reason I like Rails. The plug in system is great for casual developers because it doesn't really effect anything else, and those plugins that are worthwhile will get used and become part of rails, perhaps not officially, but at least an unofficial part of rails.

[odubtaig]

Really though, whether someone can contribute frequently or not doesn't necessarily have any bearing on how much time they've spent understanding the project. Could be they've spent 99% of their time understanding the project and 1% making a minor change while someone else with more time on their hands has spent 5% of their time understanding and 95% making more substantial changes (maybe it's a change their employer wanted and they're getting paid for their time).

Just because someone is a 'causal' developer, doesn't mean they don't understand the project. It only means they don't have as much time as others to spend on it.

[The_Decider]

@odub,

Your assertions goes beyond any credulity. If someone only has time to contribute 2-3 times a year, they simply don't have time to learn the system.

[odubtaig]

OK, won't be asking you for any tips on time management then.

[Matt Asay]

Most developers are, by definition, "casual developers." You want to restrict projects only to those that are fanatical about the project. This is a recipe for blinder-based development. It's unhealthy and unproductive. Most developers work for the GEs of the world and can't make it their life's mission to contribute to Alfresco or whatever project.

[russ danner]

Open source communities need to make contribution a priority. As Mike points out, they need to lower the barrier to getting code in but putting a process in place and letting folks know what is expected. They need to make it someones job or a hierarchy of jobs (if the project is significant in size) for reviewing code. It's a core job IMO just like a community manager is a core, and extremely important job.

Companies engaging in open source need to give developers the time to participate. This is tough one. When you are working on a relevant project it is easier to justify. When you are not it's much harder to allow your developers to burn daylight working on something that doesn't contribute to a deadline. However, you need to remember that, as a development manager you have other priorities than just deadlines. One such example is professional development.

I'm not saying you should let your developers contribute to just any project. But I think you should let them contribute to some project. When they work only with the members of your project they can begin to think inwardly. Participation with outside people invites fresh thinking, insight and mentoring. It develops their ability to work remotely, forcing them develop strong written communication skills. Help your developers pick the communities they join and the projects they contribute to. Make sure they are hanging out in the best possible neighborhoods. Projects like Linux, Alfresco, Hadoop and many, many others have world class developers and management teams behind them. Expose your developers to these people and they will blossom.