Vídeo de la presentación de gisEIEL 3.0 realizada por Miguel R. Luaces en las VII Jornadas Internacionales de gvSIG, Valencia (2011):
Wednesday, March 14, 2012
Tuesday, November 8, 2011
Segunda evolución
Como consecuencia de las modificaciones introducidas en la gestión del proyecto gisEIEL a raíz del acuerdo de colaboración con las Diputaciones de Córdoba y Ourense, la Universidad de A Coruña y el Consell Insular de Mallorca, y dado que este espacio tenía un carácter semi-oficial y que no estaba claro si servía exclusivamente para publicar comentarios y noticias referidos a gisEIEL, hemos decidido crear un blog oficial de la plataforma eielac (que incluye al portal webEIEL, a la BDT-EIEL, el nodo ideAC y gisEIEL), que servirá a partir de ahora como punto oficial de publicación de novedades, y transformar definitivamente "Going Free" en un espacio para la reflexión personal de sus autores acerca de temas relacionados con la información geográfica, los SIG, las IDE, el software y el conocimiento libres, etc
Por tanto, en los próximos días iréis viendo cómo se transforma este blog. Hemos empezado por su sub-título y seguiremos con los contenidos de la barra lateral, liberándolo de su vinculación inicial con el proyecto gisEIEL.
Por tanto, en los próximos días iréis viendo cómo se transforma este blog. Hemos empezado por su sub-título y seguiremos con los contenidos de la barra lateral, liberándolo de su vinculación inicial con el proyecto gisEIEL.
Monday, June 13, 2011
Pherecyde's cloth (II): The eCloth
When I wrote the previous entry on Pherecyde's cloth, I was thinking of a series of articles driving from the myth to a prospective trip on what can be the future of map making or, more precisely, of geographic information computing.
This series of articles would have explained the different stages of mapmaking evolution along time. But both the time passed since my first post, and the evidence that there are several very good web resources on that issue (e.g. BBC's "Maps: Power, Plunder and Possession" and "The Beauty of Maps" series), have made me change my mind in the sense of deciding to close my own series of posts with just this second entry.
So, the important thing about mapmaking history with regards to what I wanted to transmit is that, from the 1970`s, the arising of CAD, automated mapping and GIS technologies have put in our hands the posibility to build up electronic, virtual representations of the territory. These representations, on despite their resolution, are generally stored as 1:1 models of our sorrounding space. And they have been highly improved from the 1990's on by means of the advancements in computer sciences and technologies (regarding both hardware and software) and the launching of digital globes, geographic mash-ups and SDI.
Due to this technological shift, we now are able of building quite complex, high resolution, almost full scaled representations of the world. So, we are closer and closer to being able to weave an ecloth, similar to that of Pherecyde but (in our case) made of bytes of information, that will perfectly reproduce our world in a 1:1 scale, as a virtual cloth lying on it. When this finally happens, we will have made that the myth comes true.
But this is not the end of the story (and not even of map making history). Let's watch a video:
Interesting, isn't it? When I saw it for the first time, about one year ago, I got highly impressed by the implications of Kurzweil's words and predictions regarding digital geographic information computing. And, when I begun relting them to Pherecyde's myth, provoqued my will of writing about this subject. Why?
Ok. Let's suppose that Kurzweil's predictions come true. If so, by the end of XXIst Century we will be inmersed in an universe that will mix real, phisical elements with virtual ones. An universe that will be, in Kurzweil's words, "As real as real life". An universe in which phisical elements (materials) of any kind will be used as information storing and processing units.
Let's go now one step beyond. Materials are information carriers. Ok. So, why not carrying all the data needed to describe/model themselves? This would not be that difficult as, accordingly again to Kurzweil's words: "The energy in a stone weighting one kilogram, equals the computing capacity needed to manage all of the information that humankind has managed this far". At this point, the above mentioned ecloth and the universe would be melted into just one single reality: the cloth will be the universe and the universe will be its own cloth. No more need to represent and model space, as space will be modelling and representing itself.
Hence, in that new mixed universe, we (our descendents, actually) will have the oportunity of both phisically and virtually move around and experiment the space that surrounds us at the time that we are experiencing its virtual representation.
And, would it be too risky to suppose that universe would, by then, become self-conscious? Think on the implications.
"Amazing!", is the least that I can say.
This series of articles would have explained the different stages of mapmaking evolution along time. But both the time passed since my first post, and the evidence that there are several very good web resources on that issue (e.g. BBC's "Maps: Power, Plunder and Possession" and "The Beauty of Maps" series), have made me change my mind in the sense of deciding to close my own series of posts with just this second entry.
So, the important thing about mapmaking history with regards to what I wanted to transmit is that, from the 1970`s, the arising of CAD, automated mapping and GIS technologies have put in our hands the posibility to build up electronic, virtual representations of the territory. These representations, on despite their resolution, are generally stored as 1:1 models of our sorrounding space. And they have been highly improved from the 1990's on by means of the advancements in computer sciences and technologies (regarding both hardware and software) and the launching of digital globes, geographic mash-ups and SDI.
Due to this technological shift, we now are able of building quite complex, high resolution, almost full scaled representations of the world. So, we are closer and closer to being able to weave an ecloth, similar to that of Pherecyde but (in our case) made of bytes of information, that will perfectly reproduce our world in a 1:1 scale, as a virtual cloth lying on it. When this finally happens, we will have made that the myth comes true.
But this is not the end of the story (and not even of map making history). Let's watch a video:
Interesting, isn't it? When I saw it for the first time, about one year ago, I got highly impressed by the implications of Kurzweil's words and predictions regarding digital geographic information computing. And, when I begun relting them to Pherecyde's myth, provoqued my will of writing about this subject. Why?
Ok. Let's suppose that Kurzweil's predictions come true. If so, by the end of XXIst Century we will be inmersed in an universe that will mix real, phisical elements with virtual ones. An universe that will be, in Kurzweil's words, "As real as real life". An universe in which phisical elements (materials) of any kind will be used as information storing and processing units.
Let's go now one step beyond. Materials are information carriers. Ok. So, why not carrying all the data needed to describe/model themselves? This would not be that difficult as, accordingly again to Kurzweil's words: "The energy in a stone weighting one kilogram, equals the computing capacity needed to manage all of the information that humankind has managed this far". At this point, the above mentioned ecloth and the universe would be melted into just one single reality: the cloth will be the universe and the universe will be its own cloth. No more need to represent and model space, as space will be modelling and representing itself.
Hence, in that new mixed universe, we (our descendents, actually) will have the oportunity of both phisically and virtually move around and experiment the space that surrounds us at the time that we are experiencing its virtual representation.
And, would it be too risky to suppose that universe would, by then, become self-conscious? Think on the implications.
"Amazing!", is the least that I can say.
Wednesday, March 23, 2011
Agreement to cooperate in the management of gisEIEL project
After a process that started up during past November, Province Councils of A Coruña, Córdoba and Ourense, Island Council of Mallorca and University of A Coruña have agreed in signing a Memorandum of Understanding to cooperate in the management, monitoring and coordinate development of gisEIEL [1] project.
As explained within the text of the MoU [2], the signing bodies agree in using BDT-EIEL geo-database and gisEIEL software to build and manage the so called EIEL (Spanish acronym for Enquiry on Local Infrastructures and Services) and, in order to rationalize the use of the available resources, have considered that inter-administrative cooperation "is, in general, wishable in order to rationalize the use of resources and guarantee the sustainibility of Public Administration actions. They also consider that, in the particular case of gisEIEL project, this cooperation will take to the optimization of the resources that are advocated to the development, management and maintaining of the project, to its persistence in time, its continuous improvement, its better fitting the interests and needs of its users and, summarizing, to its more rational management."
To reach those goals, the signing bodies set the deal of coordinating efforts and developments, as well as to annually agree about the schedule of actions to undertake, accordingly to the following
BASIC PRINCIPLES OF COOPERATION:
[1] http://giseiel.forge.osor.eu
[2] Complete text of the MoU (in Spanish only):
https://docs.google.com/document/d/1OWuWltpEpQP3FM3_q_-i_uX77FObtv2OrFUGlv-wGyY/edit?hl=en&authkey=CNSpmvgJ
As explained within the text of the MoU [2], the signing bodies agree in using BDT-EIEL geo-database and gisEIEL software to build and manage the so called EIEL (Spanish acronym for Enquiry on Local Infrastructures and Services) and, in order to rationalize the use of the available resources, have considered that inter-administrative cooperation "is, in general, wishable in order to rationalize the use of resources and guarantee the sustainibility of Public Administration actions. They also consider that, in the particular case of gisEIEL project, this cooperation will take to the optimization of the resources that are advocated to the development, management and maintaining of the project, to its persistence in time, its continuous improvement, its better fitting the interests and needs of its users and, summarizing, to its more rational management."
To reach those goals, the signing bodies set the deal of coordinating efforts and developments, as well as to annually agree about the schedule of actions to undertake, accordingly to the following
BASIC PRINCIPLES OF COOPERATION:
- The signing bodies adopt BDT-EIEL data model, from A Coruña Province Council, as basic model to manage geo-referenced EIEL and as the foundational set of data to support a package of GIS solutions for Local Administrations.
- They also adopt gisEIEL software as GIS tool to manage the contents of BDT-EIEL. Meanwhile gvSIG 2.0 is not available, the newest released version of gisEIEL will be used. As soon as an stable version of gvSIG 2.0 is available, the set of moules of gisEIEL 3.0 and later versions will be adopted, as well as any other gvSIG compatible software that may be gvSIG or gisEIEL compatible.
- The signing bodies may also adopt the rest of the aplications within eielAC platform to publish and share the data contained in BDT-EIEL.
- The developments, modifications and improvements to be undertaken from the signing of this MoU on, will be shared between the signing bodies and will be compatible with gvSIG, from its version 2.0 on, given that it constitutes the most adequate technological platform to day. The MoU Monitoring and Technical Committees may, at any moment, decide to maintain also compatibility with any other interesting software.
- Given that the present MoU relates to a project that was started by A Coruña Province Council and University, and in order to reach the goal that all of the rest of the signing parties (including both their developres and users) may quickly and fully get confident with the shared tools, the former institutions guarantee their cooperation regarding learning and technical advisory as weel as providing the most adequate documentation thus building up a frame of knowledge and technology sharing.
[1] http://giseiel.forge.osor.eu
[2] Complete text of the MoU (in Spanish only):
https://docs.google.com/document/d/1OWuWltpEpQP3FM3_q_-i_uX77FObtv2OrFUGlv-wGyY/edit?hl=en&authkey=CNSpmvgJ
Monday, March 21, 2011
Acuerdo de cooperación para la gestión de gisEIEL
Tras un proceso iniciado el pasado mes de noviembre, las Diputaciones de A Coruña, Ourense y Córdoba, el Consell Insular de Mallorca y la Universidad de A Coruña han adoptado el acuerdo de formalizar un convenio de cooperación para la gestión, seguimiento y desarrollo coordinado de la aplicación gisEIEL [1].
Tal como se explica en el propio texto del convenio [2], las entidades firmantes del mismo coinciden en utilizar la base de datos BDT-EIEL y el software gisEIEL para la confección y gestión de la Encuesta sobre Infraestructuras y Equipamientos Locales (EIEL) y, a fin de racionalizar la utilización de los recursos disponibles, han considerado que la cooperación interadministrativa "es, con carácter general, deseable en orden a racionalizar el uso de recursos y a garantizar la sostenibilidad de las actuaciones de la administración pública. Consideran así mismo que en el caso particular del proyecto gisEIEL esta cooperación llevará a la rentabilización de los recursos destinados al desarrollo, gestión y mantenimiento del proyecto, a su persistencia en el tiempo, a su continua mejora, a su mejor adecuación a los intereses y necesidades de sus usuarios y, en suma, a su más racional gestión."
Para ello, se comprometen a coordinar sus esfuerzos y desarrollos, y a acordar anualmente las líneas de actuación a desarrollar, de acuerdo con los siguientes
PRINCIPIOS BÁSICOS DE COLABORACIÓN:
[1] http://giseiel.forge.osor.eu
[2] Texto completo del convenio:
https://docs.google.com/document/d/1OWuWltpEpQP3FM3_q_-i_uX77FObtv2OrFUGlv-wGyY/edit?hl=en&authkey=CNSpmvgJ
Tal como se explica en el propio texto del convenio [2], las entidades firmantes del mismo coinciden en utilizar la base de datos BDT-EIEL y el software gisEIEL para la confección y gestión de la Encuesta sobre Infraestructuras y Equipamientos Locales (EIEL) y, a fin de racionalizar la utilización de los recursos disponibles, han considerado que la cooperación interadministrativa "es, con carácter general, deseable en orden a racionalizar el uso de recursos y a garantizar la sostenibilidad de las actuaciones de la administración pública. Consideran así mismo que en el caso particular del proyecto gisEIEL esta cooperación llevará a la rentabilización de los recursos destinados al desarrollo, gestión y mantenimiento del proyecto, a su persistencia en el tiempo, a su continua mejora, a su mejor adecuación a los intereses y necesidades de sus usuarios y, en suma, a su más racional gestión."
Para ello, se comprometen a coordinar sus esfuerzos y desarrollos, y a acordar anualmente las líneas de actuación a desarrollar, de acuerdo con los siguientes
PRINCIPIOS BÁSICOS DE COLABORACIÓN:
- Las entidades firmantes adoptan el modelo de datos de la BDT-EIEL de la Diputación de A Coruña como modelo básico para la gestión de la EIEL georreferenciada y como base para la construcción de un paquete de soluciones SIG dirigidas a la administración local.
- Igualmente adoptan el software gisEIEL como herramienta SIG de partida para la gestión de los datos contenidos en la BDT-EIEL. En tanto no esté disponible la versión 2.0 de gvSIG, se adoptará la última versión liberada de gisEIEL. En cuanto se publique la primera versión estable de gvSIG 2.0, se adoptarán como base el conjunto de módulos de gisEIEL 3.0 y versiones posteriores, pudiendo complementarlas en cualquier momento con otro software compatible con los anteriores.
- Las citadas entidades firmantes podrán, así mismo, adoptar las restantes aplicaciones de la plataforma eielAC como software de publicación y compartición de los datos almacenados en la BDT-EIEL.
- Los desarrollos, modificaciones y actualizaciones a realizar a partir de la firma del presente convenio, serán compartidos entre los firmantes y serán, en todo momento, compatibles con gvSIG, a partir de su versión 2.0, por constituir la plataforma tecnológica más adecuada en el momento presente. Igualmente, se mantendrá la compatibilidad con cualquier otro software de base o complementario que decidan los órganos técnicos de seguimiento del convenio.
- En la medida en que este Convenio se constituye sobre un proyecto ya iniciado por la Diputación de A Coruña y la Universidad de A Coruña y con el fin de que el resto de las entidades firmantes (refiriéndose tanto a desarrolladores como usuarios finales de la aplicación) se puedan incorporar rápida y plenamente al estado actual del mismo, las dos entidades citadas garantizan su colaboración en materia de formación, asistencias técnicas y redacción de la documentación adecuada que conforme un marco de transferencia de conocimiento y tecnología adecuado.
[1] http://giseiel.forge.osor.eu
[2] Texto completo del convenio:
https://docs.google.com/document/d/1OWuWltpEpQP3FM3_q_-i_uX77FObtv2OrFUGlv-wGyY/edit?hl=en&authkey=CNSpmvgJ
Tuesday, September 28, 2010
Denial
Given the evidence that someone is spreading the "information" that gisEIEL project is dead and that, henceforth, it is to be replaced by Open gisEIEL, we want to make it clear that BOTH STATEMENTS ARE RADICALLY FALSE.
Whoever is from now on the main developers group and what is the type of contract or collaboration of this group, the project is still being directed and led by the A Coruña Province Council, which, through the Technical Monitoring Committee of the project, will continue to have ultimate capacity of decision on the actions carried out on it. No one outside of A Coruña Province Council may therefore decide whether the project continues or not or if it is to be replaced by another one.
In short: gisEIEL currently is and will remain being alive.
Whoever is from now on the main developers group and what is the type of contract or collaboration of this group, the project is still being directed and led by the A Coruña Province Council, which, through the Technical Monitoring Committee of the project, will continue to have ultimate capacity of decision on the actions carried out on it. No one outside of A Coruña Province Council may therefore decide whether the project continues or not or if it is to be replaced by another one.
In short: gisEIEL currently is and will remain being alive.
Desmentido
Ante la evidencia de que se está extendiendo la "información" de que el proyecto gisEIEL está muerto y que, a partir de ahora, pasa a ser sustituído por Open gisEIEL, queremos dejar claro que AMBAS AFIRMACIONES SON RADICALMENTE FALSAS.
Independientemente de quien sea a partir de ahora el grupo principal de desarrollo y cuál sea la modalidad de contratación o colaboración de ese grupo, el proyecto sigue siendo dirigido y liderado por la Diputación de A Coruña, que, a través de la Comisión Técnica de Seguimiento del proyecto, continuará teniendo la capacidad última de decisión sobre las actuaciones que se realicen sobre el mismo. Nadie ajeno a la Diputación de A Coruña puede, por tanto, decidir si el proyecto continúa o no o si es sustituído por otro.
En resumen: gisEIEL está y continuará estando vivo.
Independientemente de quien sea a partir de ahora el grupo principal de desarrollo y cuál sea la modalidad de contratación o colaboración de ese grupo, el proyecto sigue siendo dirigido y liderado por la Diputación de A Coruña, que, a través de la Comisión Técnica de Seguimiento del proyecto, continuará teniendo la capacidad última de decisión sobre las actuaciones que se realicen sobre el mismo. Nadie ajeno a la Diputación de A Coruña puede, por tanto, decidir si el proyecto continúa o no o si es sustituído por otro.
En resumen: gisEIEL está y continuará estando vivo.
Friday, April 16, 2010
Pherecyde's cloth (I): The cloth
Greek pre-socratic philosopher Pherecides of Syros (6th BC) [1] did explain the origin of the World, as we know it, by means of a myth.
Accordingly to him, in the origin there was the chaos inhabitted by two antagonistic "entities" or "forces": Chtonie (the solid materials) and Ogenos (the oceans or, more exactly, the waters) which would exist in a complete separation from one eachother, with no contact between them.
Zas (laterly known as Zeus, the father of Gods) would have put order into this initial chaos by fostering the meeting between these two entities and their later union, which is poetically described by Pherecydes as their "wedding".
As wedding present, Zas would have woven a large, beautiful cloth in which he would have represented, at a natural scale, earth and seas and all what they contain: geographical elements, animals, plants, minerals, atmosphere, as well as the sun, the moon, the stars, etc.
After the wedding between Chtonie and Ogenos, he would have laid the cloth on them, this way transforming Chtonie into Gea, and chaos into order. And, as a consequence, creating the World in which we now live.
By means of the act of covering the chaos with a representation of the "ordered" world, the model of the world would have become the world itself. Or, in other words (now mine, not from Pherecydes): The mapping of the world at a natural scale would have caused its actual creation.
Beautiful, isn it? Mainly if we read the legend from our perspective: the one of those who work with geographic information.
[1] http://en.wikipedia.org/wiki/Pherecydes_of_Syros
Accordingly to him, in the origin there was the chaos inhabitted by two antagonistic "entities" or "forces": Chtonie (the solid materials) and Ogenos (the oceans or, more exactly, the waters) which would exist in a complete separation from one eachother, with no contact between them.
Zas (laterly known as Zeus, the father of Gods) would have put order into this initial chaos by fostering the meeting between these two entities and their later union, which is poetically described by Pherecydes as their "wedding".
As wedding present, Zas would have woven a large, beautiful cloth in which he would have represented, at a natural scale, earth and seas and all what they contain: geographical elements, animals, plants, minerals, atmosphere, as well as the sun, the moon, the stars, etc.
After the wedding between Chtonie and Ogenos, he would have laid the cloth on them, this way transforming Chtonie into Gea, and chaos into order. And, as a consequence, creating the World in which we now live.
By means of the act of covering the chaos with a representation of the "ordered" world, the model of the world would have become the world itself. Or, in other words (now mine, not from Pherecydes): The mapping of the world at a natural scale would have caused its actual creation.
Beautiful, isn it? Mainly if we read the legend from our perspective: the one of those who work with geographic information.
[1] http://en.wikipedia.org/wiki/Pherecydes_of_Syros
Monday, December 14, 2009
Liberación de la versión 2.1 de gisEIEL
En el día de hoy se ha procedido a liberar el código de la última versión de gisEIEL, la 2.1, que incorpora notables mejoras.
El código fuente de la aplicación así como toda la documentación de desarrollo está accesible desde la web de la EIEL en el siguiente enlace:
También podéis acceder a una descripción del proyecto en la página de OSOR:
Los cambios de esta versión con respecto a la anterior incluyen revisiones/mejoras de los módulos existentes así como nuevas funcionalidades para la aplicación.
A continuación incluimos una descripción de las principales novedades de esta versión.
Mejoras de carácter general:
· Se han corregido los errores detectados por los usuarios así como por el equipo de desarrollo, mejorando la estabilidad general de la aplicación.
· Se han reestructurado los menús para que sea más cómodo e intuitivo su uso.
· Se ha mejorado notablemente la organización de los proyectos así como sus dependencias y se han simplificado los ficheros de ‘ant’ necesarios para compilarlos.
Mejoras en los módulos existentes:
· Módulo de autenticación y gestión de usuarios:
1. Se ha incluido una caché de servidores que permite almacenar los datos de conexión a los servidores a los que se ha accedido de forma exitosa.
· Módulo de impresión:
2. Corregidos los problemas de consumo de memoria que impedían imprimir con calidad muy alta
3. Posibilidad de imprimir a 96, 300 y 600 ppp
4. Posibilidad de poder imprimir en horizontal y vertical
5. Nuevos tamaños de impresión, ahora la aplicación soporta A0, A1, A2, A3 y A4.
6. Incluido módulo de gestión de leyendas de impresión que permite configurar el nombre de cada capa EIEL que aparecerá en la leyenda del mapa impreso.
· Módulo de digitalización y edición.
1. Añadida herramienta de edición de polígonos que permite añadir polígonos o huecos a una entidad con geometría de tipo multipolígono.
2. Añadida herramienta de edición que permite cambiar el sentido de geometrías de tipo polilínea.
· Módulo de formularios de entidad:
1. Incluido soporte a subformularios. De esta forma es posible definir formularios desde los que se pueda abrir subformularios para rellenar datos relativos a una entidad. Por ejemplo los formularios de equipamientos nos permitirán abrir subformularios donde podremos gestionar los usos que se le están dando a ese equipamiento.
· Módulo de generación de fichas municipales:
1. Revisadas las fórmulas de índices e indicadores de la ficha.
2. Mejorado el rendimiento del módulo y reducido el tiempo necesario para la generación de las fichas municipales.
Nuevas funcionalidades de la aplicación:
· Asistente para exportar cartografía a SHP y DXF de forma masiva: Permite exportar a SHP y DXF capas de la BDT-EIEL pertenecientes a un conjunto de municipios de forma rápida y cómoda.
· Nuevo módulo de conectividad de redes con las siguientes herramientas:
1. Herramienta para la comprobación de la conectividad de redes de abastecimiento y saneamiento: Permite realizar simulaciones de recorrido de redes sobre las vistas de gvSIG, de forma que facilita la detección de posibles errores en las conexiones de los elementos que forman una red.
2. Herramienta para el cálculo de conectividad para las redes de abastecimiento y saneamiento: permiten calcular de forma automática las asociaciones de servicio entre elementos de las redes de saneamiento y abastecimiento, y los núcleos de población.
· Herramienta para la eliminación de núcleos EIEL: Permite eliminar de forma cómoda núcleos EIEL, reasignando todos los equipamientos e infraestructuras pertenecientes a este núcleo a un nuevo núcleo EIEL indicado por el usuario.
· Módulo de generación de registros temporales que proporciona al usuario herramientas para:
1. Generar en la BDT-EIEL un esquema temporal, un esquema histórico, disparadores y procedimientos almacenados que permitan implementar la gestión temporal de los datos.
2. Guardar registros temporales de las modificaciones de los datos contenidos en la BDT-EIEL, almacenando en el esquema histórico las modificaciones que ha sufrido la BD entre distintos momentos puntuales.
Mejoras en la BDT-EIEL:
· Introducidos datos de fases anteriores de la EIEL, lo que permite análisis históricos de evolución de las infraestructuras y equipamientos.
· Incluido un esquema temporal, un esquema histórico, disparadores y procedimientos almacenados que permitan implementar la gestión temporal de los datos.
Monday, August 10, 2009
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
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
Subscribe to:
Posts (Atom)
Posts
