Slashdot Mirror
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."
It chases off professionals interested in real projects. 'Oh I don't want to get involved with that, there are 30 projects like it on Sourceforge.....'
Maybe my gripe it with how the opensource projects are handled.
Vaporware that sits for 2 years is not a project.
Sorry about the writing. Robot fingers, you know? Cliff Steele in DOOM PATROL #23
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.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Save man-years by not saying things like "mature software process concepts" when you mean things like "good plan."
Your mouth is like Columbus Day.
Focus Group? If I'm writing code for FUN in my OWN TIME then I think that I should be able to determine what I write, not some focus group. I don't tell others how to spend their free time, why should they be able to tell me. If the focus group want feature X then they can code it themselves....
- Lack of a plan.
- Lack of peer reviewing.
- Lack of predictability (both feature and time wise).
There are many points here, but one of the most important is the lack of a plan. It would greatly benefit most OSS projects if there was a plan of features to be implemented. This would not only tell users and project members where the project is heading, but also prevents eyecandy and other code bloating problems to enter the project too early. It would be good if a feature had to be on the TO-DO list to be included into the project source tree. This way each feature has to be discussed, specified and granted before being implemented. This helps building more consistent software.The second problem, peer reviewing, could be solved by including it in the code versioning system (hense the subject of this reply...). All code must be tested and reviewed by an independen peer before included in the source tree. By introducing automatic testing, such as a small test bench application showing that the submission works, modularity is encouraged. By introducing good modularity, new patches are more easily tested and included in the source tree.
The last point is mainly a project management issue. Someone has to say that these features will be available at this date in this release. This problem is simply the addition of time to the first problem (a plan). This is the thoughest challenge when working with spare-time programmers. Not many will be happy about commiting to a project, then being forced to keep a time plan. Anyway, this can be enforced in the big, with partially paid work-time, projects.
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.
It's all very well in practice, but it will never work in theory.