Geeks With Blogs
No Fun Intended Shoo! You are debugging the crap outta me!

I was chatting with former NTeam-er Jonas Antonsson a few weeks ago and the topic of why finding developers for open source projects is so difficult. I guess finding those interested is relatively simple but actually getting contributions is the difficult part. Of the 50 that signed up for NTeam, only eight that I can count have contributed. This struck me as very strange and I mentioned it to Jonas and his response was that most developers are intimidated by the complexities of open source projects. Their work, after all, is on display for the whole world to see. We do this at work all the time but we all screw up and our co-workers are just as error-prone as we are. The very nature of open source projects are complex. For the most part, these projects are commercial software with high quality levels and even higher visibility but our development methods are not commercial quality. Maintaining even a small level of control over a disparate project team is extremely difficult. This is one reason we are building NTeam with VSTSb3. It is ideal for this kind of work. Later on, we will replace VSTS with NTeam. Anyway, I am quickly moving off topic.

Jonas is of the opinion that because these projects are complex and developers are either scared of them or just shy away from them and there are only two approaches to maintaining control. First, you can only recruit and accept developers advanced enough to handle them. The problem with this approach is obvious: There are only so many developers out there that A) Want to contribute to an open source project. B) Are legally capable to contribute (employment contracts). C) Are of an advanced enough level to safely and effectively contribute. Second, you can segment the project into different sections of complexity. The advanced developer(s) work on the advanced sections and the not so advanced work on the simpler stuff. When integration occurs, you can have a meeting of the minds so to speak so that everything comes out okay and most can wrap their minds around the sections. Understanding the code in a software project is much easier than playing the roles of architect, quality assurance, and compliance.

I think I stand with Jonas. There are many smart people out there that want to contribute but can't find the time or just do not have the experience for a bird's eye view of the project architecture. The problem is integration. We all know that daily builds and continuous integration are an important part of software quality management and if you do not have these things your project is probably in a lot of danger. I think the fact that open source projects move a little slower than the commerical stuff we write at our day jobs and other quality controls can offset this danger. I do a weekly build for NTeam and all code must have unit tests that I check nightly and fix before writing any new code. I am interested in knowing how other project leaders are handling this type of problem in their projects.

Posted on Wednesday, October 19, 2005 6:08 PM Open Source , Methods & Madness , Patterns, Practices, Architecture | Back to top

Comments on this post: Open Source Intimidation

# Managing Open Source projects
Requesting Gravatar...
NTeam founder Jason Bentley quotes me in his post: "Open Source Intimidation". In the post he refers to a chat we had a few weeks ago about the difficulties of staffing and managing Open Source projects. He accurately describes my views where I am of the opinion that most developers are afraid and intimidated by the complexities of most Open Source projects. I've thought a lot about this and I've come realize that time, or lack of it, is also a factor.
Left by Jónas Antonsson on Oct 21, 2005 3:10 PM

Your comment:
 (will show your gravatar)

Copyright © Jason Bentley | Powered by: