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."
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
- 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.
Of course some of those "process" things can be valuable, and when a project meets a problem, they can use a solution. For some projects it even makes sense to talk of focus groups (KDE comes to mind), and regression testing is used in some (GnuGo).
I think it is fine to make some of these techniques available to those who see the need of them. Good introduction material about such would be welcome. But do accept that most OS projects are better off without a pointy-haired boss and his bureaucracy.
In Murphy We Turst
Well, if it's on your own time, then might I suggest you just back away from the project?
If it is on your own time after all, I don't see how anyone can force you to write according to what the focus groups say, not like you're getting paid for it or anything.
If I decided to start my own project, I sure as hell wouldn't want somebody to start commiting code to said project when the code benefits no one, apart from possibly its author.
If you want to do something with my code, fine, fork the project, just don't get your knickers in a knot when I decide your code doesn't belong in my project.
It is after all MY project that _I_ started and _I_ control.
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.
Good job at not getting his point.
If you start a project "for fun" then focus groups are overkill. Now if someone uses your program and finds a missing feature and submit the patch then you have the "focus group" and coder in one person. That's the basic idea with OSS.
You as a maintainer don't have to include it, but most project maintainers have too little time already so I recon they'd appreciate some help.