How To Best Manage Open Source Projects?

This member, from the voiciferous Clan Anonymous Coward asks: "I work for a fairly large company, and I'm trying to convice the senior management to open source a piece of internally developed software that we rely upon, but that we don't directly profit from. This software enables our business model, but the software itself doesn't offer any particular competitive advantage. (Actually, to be a little more accurate, we would like to develop a system that replaces a commercial off-the-shelf solution that we're less than happy with, and open source that, so if you have anecdotal evidence or other ammunition for that particular argument, I'd be glad to hear it)." And this is something that I think more businesses should look into doing. If you use a piece of software that your business doesn't depend on, commercially, why not free it? (Read more...)

"What I'm really looking for is advice on how to make the project successful as an open source intiative. Specific issues include, but aren't limited to:

• Where/how should we host the project? Something internal? Something like SourceForge?
• What management structures/tools are helpful? At minimum we'll need a source-code repository and a mailinglist/newsgroup, right? Anything else considered critical?
• What are some effective control stuctures? Who should determine what makes it into an official release? By what procedure? Who should be able to add code to the tree? What kinds of resources do we need to commit to this project to make it effective?

In short, what advice do you have on the mechanics and management of open source projects?

I'm familiar with the standard technical and business arguments for open source software (including:

• various ESR documents from opensource.org
• Tim O'Reilly's "Open Source Revolution" article from Release 1.0 www.edventure.com/release1/1198.html
• Frank Hecker's "Setting Up Shop: The Business of Open-Source Software" from www.hecker.org/writings/setting-up-shop.html

and others), and feel I can articulate them pretty clearly, but that's not really what my question is about."

Comments

Suggestions

[jd]

• Appoint a "Benevolent Dictator" for the project. They, and they alone, have final say on what goes in. If the project has multiple applications, it may be better to appoint a BD for each.
• You ABSOLUTELY need a repository from which you can access any version of the software.
• It is STRONGLY recommended that you have some kind of bug-tracking system, so that bug-fixes don't clash more than they absolutely have to.
• Release Early, Release Often. RERO is the only way people will know your project is alive and well. Too many projects die from their maintainers trying to get the release "just that little bit better". Forget it, throw it out, and let people find the bugs. Driving yourself mad earns you nothing.
• Set Deadlines and be firm about them! If people want to add unstable/untested stuff, fine. Just make sure it's possible for users to not have to contend with it. Then IT DOESN'T MATTER!
• Announce on Freshmeat, for the project AND the code.
• Pick a SUITABLE licence, but don't invent your own. GPL, LGPL and BSD will cover 99.999% of all cases.
• Keep It Simple, Stupid! Feature-creep, bloat, complex code, etc, are all ways to create slow, unmaintainable, unusable, buggy code. If that's what you want, fine, but if you want something you can use, keep things simple.
• Loose-Coupling is Good. The more tightly coupled two routines are, the more fragile they are. Any slight change in one can wreck the other, without warning. Not only that, but you can't do anything new with the code. Loose coupling allows you to move into distributed code, parallel processing, etc.
• A bird in the hand is worth two in the bush. If a routine works, can be compiled as a library and has a well-defined interface it, FREEZE IT! Get everything that stable, before doing anything further. The fewer unknowns you have, the better.

If this goes against what anyone else has written, pick who's advice seems to be the most sound and go with that.

If the above is not what you wanted to know, then take what you like and leave the rest. (Hmmm. Open Source is programming's own 12-step group!)

You are asking the wrong question

[Golias]

If you are trying to persuade management to open source something that they spent money on developing, the question they will expect you to be able to answer is not "how" but "why".

They really won't care what your model is for managing the long-term growth of the project. Instead of reading about how the GNU team runs things, start thinking about these questions:

"Does doing this add value to our company?"

"If so, what are the specific benifits?"

"How can the value of these benifits be measured?"

"How much is this likely to cost?"

"Are the potential benifits likely to justify the trouble?"

If you go into a meeting with the PHB's, and don't have specific details of the reasons for doing the project, the goals of the project, how the goals can be evaluated, and the costs... they will pretend to listen to your presentation, and then move on to something else.

Knowing this kind of stuff is supposed to be management's job, but they didn't get where they are today by doing their own research. If you want the project to happen, it is up to you to do the thinking for them.