Improving Open Source Using Software Process Concepts?

icanoop asks: "I'm working on a project to help improve open source development using mature software process concepts. What process issues do open source developers think are most important and/or can be improved? If you are interested in seeing what is being considered read the problem statement at the project site. It's not final so feel free to suggest changes."

Comments

Considerations:

[Ayanami Rei]

I can give you a list of things to avoid:

1) Allowing the developers to dictate the initial design rules. Allow a focus group determine what it is that is required, then let the developers determine how feasible it will be to implement.

2) Fear of COTS product integration. That is, use the right tool for the job. Of course, if everyone's a whiz with CVS and Emacs, then the more power to them. But don't let anyone make a project a "perfect fit" for their tool of choice which no one else is willing to use. That will cause problems later.

3) Not using outside code / help. Often times, portions of what you want to do have already been beaten to death. Look hard.

Of course, you know all of this. It seems your problem statement and proposed solutions on the linked site are quite thorough; I don't see anything that looks like a sticking point.

Maybe you want to restate the question.

Step one:

[CdotZinger]

Save man-years by not saying things like "mature software process concepts" when you mean things like "good plan."

Cathedral or bazaar ?

[PinglePongle]

The fundamental question seems to be :
Do processes make better software
I've been involved with a lot of software projects (though never contributed much to Open Source...), and I have never seen a single project that was succesful because it followed a process. Nevertheless, whenever a project runs into trouble, the first call is usually for "more/better process !!". So let's look at this in more detail.

Succesful projects seem to grow their own process. The process seems to be simple, and often appears to be way less than you would expect, and rely heavily on interpersonal communication rather than documents and frameworks. There's usual a small core of "gatekeepers" who set the technical and philosophical tone for the project. The Linux kernel is a good example.

I am very worried about people using phrases like "mature process", "industry standard" etc. - in my experience, this often refers to the Rational Unified Process or the Software Engineering Institute's Capability Maturity Model. Both are laudable and when I go on holiday, I really want the airplane's control systems to be written using such processes. However, for many projects, the burden of bureaucracy is inappropriate (yes, I know you can tailor the RUP to suit your needs, but it contains over 140 different deliverables, none of which appears to be code). The training required to bring developers up to speed with these processes is significant, and usually expensive.

Instead, I'd look at the Agile methodologies at Agile Alliance website. The "Crystal" methodologies are especially interesting because they encourage you to actively choose the processes your project needs based on a variety of parameters - size, risk etc.

Having said that, I think a lot of the problems addressed are real - I think they get solved by people, not processes though.