Cathedrals or bazaars?

Even I don´t fully agree with Reynold's proposal about Libre Software projects cathegorization [1], as I don't think that cathedrals were completely built by hierarchical organizations, whilst  bazaars are not actually "that" collaborative, there is no doubdt that it has been widely adopted by the LS community. Thus thinking about projects as bazaar-like managed is what prevails. And, well, maybe that, in general, this is the case with must LS projects. But, what happens with Public Administration led ones? Do they properly fit bazaar paradigma?

I begun thinking about this issue when we were preparing gisEIEL project releasing, last year. Being the "bible" of LS projects managing, I was then trying to follow Karl Fogel's reccomendations at his well known book "Producing Open Source software" [2]. But as we progressed in gisEIEL releasing tasks, I begun being more and more aware about that our project COULDN'T follow all of those reccomendations. As a consequence, I tried to figure out wether this happened to every PA led project.

To help myself in that task, I launched PA FOSS, a web based enquiry (not currently available) that contained a series of questions regarding all of the main points that Fogel mentions in his book. Even announced at several fora, it was completed just by four project managers (including myself), what can not be considered as statitically representative at all. Anyway, the contents of those four answers are homogeneous enough as to suspect that, when dealing with projects from Public Administration bodies, my thoughts about the existence of constrains to follow bazaar model are something more than just an intuition.

Why do I think so? Well, let's have a look at some of the results of the enquiry:

i. Developing

 In all of the four cases, developing is being made by teams from the own leading PA body, its associated institutions or contrated companies. In no case it was made by a free and self organized community.

Developing decissions are, thus, taken by project managing teams.

ii. Project releasing
All of the four projects were firstly released only when they had achieved all of the decided functionality. No alfa, beta or candidate releases. No code sharing until the applications were fully developed and functional enough. And, by the time when the enquiry was held, this applied as well to former versions.

iii. Funding
 Again, in no case funding came, not even partially, from the community or from private sources. Developing costs were totally paid with Public Administration funds.

iv. Community
So, is there any "community" around those projects? Well! Yes, it is! But not a self organized one. In general, what exists is a more or less wide series of tools to support the use of the applications and the intercommunication between their users and the project managing team, regarding mainly issues such as news announcement, applications testing, improvement proposals, bug tracking and so on. In some cases (i.e. gisEIEL [3]), there is also a Community Code of Conduct that rules that community's activity.

As said, this pattern does perfectly fit both four projects. Only in the case of gvSIG [4], given its wide success and the fact that its use has spreaded all over the world, the Public Administration body that launched the project (Generalitat Valenciana, in Spain) has begun to feel "over charged" by managing tasks and has been preparing project's total independence and self managing by means of the constitution of an Association that will take care of gvSIG from some time in this year on. From that moment, the project will no more depend on GV decissions and funding and, in the close future, these will only regard the developing of given components that the mentioned institution may be interested in.

But, why does this happen? Why PA lead projects seam to be that tightly dependent on PA bodies decissions and that poorly built on communities activity? Well, PA activities are tightly controled by a broad series of legislative rules that try to assure that they rely, between other principles, on that of the save and care use of public funds and on that PA bodies have always to preserve their prestige and public trusting. This implies that wells, services and products paid with public funds can not be distributed if they do not pass quality and completeness controls. The responsibility (and liability) of PA bodies on those products are clearly higher than in the case of those produced by private institutions. So, regarding PA Libre software projects, "control" is, more than a convenience, an absolute need. If not a legal imposition.

And this makes that a new question arises: are them actually "Libre" projects? In my opinion, must of them are. Freedom does not depend on how much community driven are the projects, but on what are the conditions under which the software is released. As far as they are distributed under an approved "Libre" license, with no added use constrains, for me they are "Libre" themselves. Tighter or looser managed, more or less community driven, but "Libre" anyway.

So, cathedrals or bazaars?


PS: As you probably noticed, I do always use the expresion "Libre Software" instead of "Free Software". That's because I understand that "Free" is quite a more ambiguous word (remember that of "Free as in freedom, not free as in free beer", what becomes useless if you simply use "Libre" instead). And, moreover this, "Libre" is independent from any given definition of what can be considered as "free" or "non free" software [5] [6], what IMHO becomes a valuable added value. :-)

[1]: http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
[2]: http://producingoss.com/
[3]: http://www.dicoruna.es/webeiel/giseiel/soportecomunidad.do
[4]: http://www.gvsig.org
[5]: http://www.gnu.org/philosophy/free-sw.html
[6]: http://www.opensource.org/docs/osd