Slashdot Mirror
What's Wrong With the FOSS Community?
An anonymous reader writes "Patrick McFarland, one of the major Free Software Magazine authors, has completed his second article on whats wrong with the Free/Open Source Software (FOSS) community, and what we face in this world. He touches on ESR's Cathedral and the Bazaar essay briefly, and warns against cherry-picking style software development."
The major difference between FOSS and other communities are that the people in a FOSS community share far fewer specific goals than other communities. Some people want something fixed **now**. Others want it fixed **properly**, no matter how long that takes. Others just piss and moan.
Engineering is the art of compromise.
If we start buying CDs then the terrorists have already won.
I don't think anything in it is wrong, as such, but it really doesn't say all that much. It sort of meanders through a few stories vaguely relating to the idea that "without an organizing vision, direction doesn't happen." But it seems to me that that while that's vaguely interesting, its not really a problem with the OSS community.
While, of course, the OSS community doesn't have a single vision for any piece of OSS software, quite a lot of OSS projects do and, as his story alludes, OSS projects that have a following but languish either for lack of vision or because the project owner has misguided vision—unlike closed-source projects which, while they may not tend to lack vision, are no less likely to have a misdirected vision than their open-source counterparts—can be rescued by forking.
And plenty of OSS projects do have a vision, direction, roadmap, etc. Sure, there's probably a lot of stuff that gets released under an open-source license (or straight into the public domain) because the author is essentially "done" with it and throwing it out to the community to do with what they will, but certainly open-source players like Apache, Mozilla, etc. have a vision for their main projects, and members of the community are attracted to and contribute to projects, no doubt, largely because of how they see the project's vision as compatible with their own. The "solution" McFarland offers is what it seems to me almost every major open-source project is already openly trying to do: allow the community to contribute, but institute a degree of top-down control in terms of timelines, roadmap, and assignments to make sure that the grunt-work necessary to have a polished project gets done.
I probably wouldn't call it "acting like the Cathedral", the openness of many successful projects to community process and innovation, while retaining a kind of top-down vision, is something of a synthesis: the Cathedral harnessing the energy of the Bazaar, the Bazaar borrowing the focus of the Cathedral. And you see something like it in the embrace by some commercial, formerly closed-source vendors of both open-source software and increasing community involvement. If I had to name the model, I'd call it the "Congregation" or "Assembly", a less-propietary Cathedral, a small portion of the Bazaar united by a common purpose and direction to accept, in the context of a project, some degree of authority and leadership (but not the exclusive ownership and control of the Cathedral.)