Imposing strict and methodic Software Engineering to Open-Source projects

Question

Preface: please don't flame against Software Engineering. This question is about applying software engineering in opensource projects, not about the effectiveness of software engineering in general.

Opensource development is performed in parallel, as it involves large communities of globally distributed developers and a system of independent peer reviews. This obviously implies more entropia when compared to closed-source or small team development.

1. Do you think it is possible to apply systematic and disciplined software engineering/development methodologies to a large opensource project? I'm imaging people involved in the project that are responsible for imposing precise rules, just like software engineers acting as consultants for business realities. They would act on aspects like:
   • Requirements engineering (maybe asking to potential users / people involved in the project)
   • Verification and validation (testing techniques)
   • Quality (in terms of functionality, usability, performance, safety [..])
   • General project management (planning / monitoring of all software life-cycle phases)
2. Do you believe that this would improve the quality of projects? Or do you think that this would kill OSS development?

Update: I know that most large opensource projects make use of some SE methodologies. I'm thinking about roadmaps, release cycles, bugs and features reporting and fixing etc.

What I don't know is if there are projects applying full and stricts methodologies, such those regarding tests and quality verification. Moreover, it would be interesting to know if there are persons that are playing that role in a large OSS project. If there aren't, would it be possible?

Let's keep professional opensource away from my question, and just imagine about a completely free and open project such as a Gnu/Linux distribution, an Office suite, a particular server or whatever

Update 2: turned as Community Wiki as suggested

Answer 1

1.yes
Writing specs, making timelines and having some design beforehand is always recommended 2.depends

It depends on the project. Most open source start off by personnal initiative. "We'd like to have a software like this so lets cram code until it works". It works well until a certain point, a certain size of project where evereything collapses. I will not tell people how to manage their project since well, its their projects.

There are other kinds of open source developpement, in a much bigger scale which absolutely need engineering practices, like Firefox or Red Hat Linux for example.

There is a line between what the developpers will enjoy to do and accept to do freely and their desired scope for the project

Answer 2

I'd like to see what evidence you have that these software engineering practices aren't done in open source software.

I also fail to see how applying these practices would kill OSS.

The larger question is: Can software engineering be practiced by geographically dispersed teams that may never meet face to face without a web cam?

It implies at least one strong personality who has a vision of the objective and how it should be accomplished. It requires an enforcement mechanism to guarantee that practices are followed.

Are you saying that software engineering is the anti-thesis of open source?

Answer 3

Most "non-professional" open source software is developed in a way that clashes frontally with Fred Brooks' "surgical team" approach. According to Brooks, a single individual must lead the team by possessing global, centralised knowledge of the project, and controlling everybody else.

Most trades in engineering have a tradition of working along these lines, so from this perspective I wouldn't be confident that open source and software engineering can be reconciled. However, the fact that it has been always like this doesn't mean that it can't be changed. Whether or not software engineering can take place in a socio-technical context that is totally opposed to Brook's surgical team model, that is something that I can't tell.