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

It would be nice

[infonography]

To have a more coordinated setup. I have lots of misgivings about just putting alpha code up on the web and claiming some victory.

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.

Code auditing system

[Twylite]

I've made this suggestion several times before; what we really need in OpenSource development is a reliable and powerful code auditing controller.

While direction and design are problems experienced by a lot of OpenSource software, it is quality and security issues which are of more concern to mature projects, which have the highest visibility and widest use.

A code audit system would allow a project to be viewed as a graph of procedures/methods, and force every procedure to be marked as audited by a number (variable threshold) of auditers of a predetermined "skill level". i.e. the designers and core audit team together decide that certain procedures and modules are sensitive, and require an audit by three senior/trusted auditors; other less sensitive code requires only to junior auditors.

The system could track the auditing in conjunction with source code control, and use the software call graph to invalidate audits on procedures when dependancies are modified (and automatically marked as unaudited).

e.g. Procedure A calls procedures B and C. They are all marked as completely audited. Any change to Procedure C will necessarily invalidate the audit on C, and by relationship invalidate the audit on A. Once C is re-audited, the audit of A will still have to be performed again (unless, say, a special "interface not changed" flag is used on the re-audit of C).

In this way everyone can be happy that a project release is secure and reliable, based on the extent of the audited code.

Re:Code auditing system

[Twylite]

I agree completely, although there should be no harm in having auditing available to new projects (project leaders just wouldn't consider it for the purposes of when to stablise and release).

Although I would like to contribute more to OSS development, I have very little time or opportunity. In a project of any maturity which has a well designed and documented code structure and is employing DBC (design by contract), it is very easy to audit a single function now and then. Coding the function is somewhat more time consuming - even with strict modularity it takes some time to understand the requirements and implement them.

I'm betting that there are many eyes out there willing to find the bugs, but not sufficient tools to track where the eyes are (and should be) looking.

Re:In short: More bureaucracy

[e8johan]

"most OS projects are better off without a pointy-haired boss and his bureaucracy"

I'd say that most projects would benefit from a general plan stating which features that are wanted and for whom the project is intended. As soon as a project grows from 5-10 developers a more controlled development process will be needed if to avoid bloat and general confusion about what the project is supposed to do.

One of the main problems when bringing GNU/Linux to the desktop is actually the huge number of options. If projects were better narrowed down, and more structured, most of these options could be hidden, or atleast bundled. Open source does need far better project management than is common today!

Re:Cathedral or bazaar ?

[PaddyM]

Are you sure people followed or understood the process? Right now I'm involved with a project where we aren't following the process because we don't understand the process and things are being unsuccessful.

And what about Extreme Programming? I don't know too much about it, but I hear it's starting to gain popularity.

Although a friend of mine suggests that the reason process doesn't work is because in the end, you have to meld the software with the hardware. Usually since your processes don't address the quirks of hardware, you end up having to rewrite a lot of code to get it to work.

Re:Code auditing system - false sense of security

[rlowe69]

I believe the saying goes "with enough eyes, all bugs become shallow", not "with an arbitrary number of eyes ..."

If an auditing process like this is used, people might take a function for granted as "working" just because it's been checked by three different people, two of which are "experts". Even experts make mistakes.

A far more reliable solution is to have unit tests (like with JUnit or xUnit). An expert at writing good unit tests is far more useful to a team than someone that just scans code.

The unit tests also become important regression tests, so bugs introduced indirectly are found immediately. For more info, googlize yourself on "test driven design".