Procedimiento De Liberación De Software De La Xunta De Galicia

Transcripción

1 Procedimiento De Liberación De Software De La Xunta De Galicia

2 Procedimiento De Liberación De Software De La Xunta De Galicia Agencia para la Modernización Tecnológica de Galicia AMTEGA Esta obra está sujeta a una licencia Atribución - CompartirIgual 3.0 España de Creative Commons. Para ver una copia de la licencia, visite: Este documento está disponible en el portal web Mancomún de la Xunta de Galicia XUNTA DE GALICIA Presidencia Agencia de Modernización Tecnológica de Galicia Santiago de Compostela 2012

3 ÍNDICE CAPÍTULO 1.- INTRODUCCIÓN...3 CAPÍTULO 2.- FASE DE IDENTIFICACIÓN FICHA DE IDENTIFICACIÓN DEL PROYECTO ELIGIENDO MOMENTO Y ESTRATEGIA DE LIBERACIÓN...7 Desarrollo en abierto desde el comienzo del proyecto...7 Liberación del proyecto en fase de producción PERSPECTIVAS DE ACTIVIDAD E IMPLICACIÓN FUTURAS...10 CAPÍTULO 3.- FASE DE PREPARACIÓN LICENCIAMIENTO DEL PROYECTO...13 Informe de recomendación de licencia ELEGIR UNA LICENCIA PARA EL SOFTWARE ELEGIR UNA LICENCIA PARA LA DOCUMENTACIÓN LICENCIAMIENTO DUAL ELABORACIÓN DEL DOCUMENTO DE GESTIÓN DE COMUNIDAD CAPÍTULO 4.- FASE DE PUBLICACIÓN EN EL REPOSITORIO DE SOFTWARE LIBRE DE LA XUNTA DE GALICIA CREACIÓN DEL PROYECTO EN EL REPOSITORIO DE SOFTWARE LIBRE DE LA XUNTA DE GALICIA ALTA DE USUARIOS DESARROLLADORES EN EL PROYECTO Y ASIGNACIÓN DE PERMISOS PUBLICACIÓN DEL CÓDIGO EN EL SISTEMA DE CONTROL DE VERSIONES ESCOGIDO PUBLICACIÓN DE DOCUMENTACIÓN ELABORACIÓN Y PUBLICACIÓN DE PAQUETES DE INSTALACIÓN (OPCIONAL RECOMENDABLE)...30 CAPÍTULO 5.- FASE DE LIBERACIÓN GESTIÓN DE LA COMUNIDAD

4 CAPÍTULO 1.- INTRODUCCIÓN Desde la concepción de la industria del software, usuarios y clientes han tenido que aceptar alguna vez las restricciones y condiciones impuestas por aquellos que venden licencias de uso de sus programas. El software privativo no puede (por regla general) ser redistribuido, mejorado, adaptado a las necesidades particulares o siquiera ser reparado por quien lo está usando cuando no funciona bien. Únicamente el dueño de los derechos de autor (copyright) está capacitado legalmente para ejercer dichas acciones. Esta situación es especialmente delicada cuando el cliente que busca una solución software es una entidad pública. Al no poder redistribuir el software que ha adquirido, no puede ponerlo a disposición de sus ciudadanos en un momento determinado, no puede mejorarlo y adaptarlo para dar un mejor servicio y, al no poder estudiar sus mecanismos internos, podría incluso estar sufriendo una gestión indebida de datos sin ni siquiera ser consciente de la posibilidad. Llamamos software libre a aquellos programas informáticos que, a través de un modelo de gestión de la propiedad intelectual alternativo, aseguran para sus usuarios las siguientes cuatro libertades 1 : Libertad de uso del programa para cualquier fin Libertad para estudiar y modificar el programa según sus necesidades Libertad para hacer copias del programa y redistribuirlas Libertad para redistribuir versiones modificadas del programa Cuando un organismo público produce o adquiere una solución de software, existen varios motivos para recomendar que se trate de software libre los cuales repercuten en beneficio de la ciudadanía 2 : El software libre ahorra costes de licencias, cumple las directivas legales como la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos, favorece la transparencia y la interoperabilidad entre sistemas y facilita la adaptación en materia lingüística, legislativa o de accesibilidad, entre otros motivos. La industria y la economía también se benefician de que las entidades públicas liberen el software que han creado o adquirido. El tejido empresarial local se ve reforzado por la apertura de mercado que supone la independencia a la hora de buscar proveedores de servicios de software. También se ponen a disposición de empresas conocimiento y tecnologías nuevos y se fomenta la cooperación entre universidades, empresas y centros de I+D. 1 Adaptado de 2 Más información en 3

5 Por todo esto, el presente documento conforma una guía para el procedimiento estandarizado de liberación de software para la Xunta de Galicia y en los siguientes apartados se abordarán los métodos de actuación para las siguientes fases de dicho proceso: Fase de Identificación, durante la cual habrá de recogerse información correspondiente al proyecto, que ayude en las sucesivas tomas de decisiones relativas al mismo. Fase de Preparación, en la que deberán tomarse la mayoría de las decisiones relativas a licenciamiento, modelo de gestión de comunidad y objetivos y motivaciones del proyecto. Fase de Publicación, durante la cual se llevará a cabo gran parte del trabajo técnico de puesta del software a disposición pública en repositorios de código fuente, la creación de documentación, el empaquetado y en resumen lo que podríamos llamar la publicación de un producto software. Fase de Liberación, donde se perseguirá la autonomía del proyecto de software libre, sustentado en su propia comunidad con sus propios mecanismos. 4

6 CAPÍTULO 2.- FASE DE IDENTIFICACIÓN Para llevar a cabo una transición a proyecto libre de un desarrollo existente o para crear una comunidad a partir de un proyecto que da comienzo prácticamente desde cero, habrá que pasar por varias fases y tomar numerosas decisiones. Esta fase de identificación tiene por objeto recoger toda la información precisa sobre el proyecto, que ayude tanto en la toma de decisiones durante el proceso de preparación de la liberación como en la propia liberación. La recogida de información deberá ser lo más completa y contrastada que podamos, para poder facilitar el resto del proceso. Para llevar a cabo dicha tarea se proporciona la siguiente ficha de identificación del proyecto. Una herramienta que servirá para categorizar el proyecto y adecuar el resto de las acciones hasta la liberación al caso particular que nos ocupe Ficha de identificación del proyecto Nombre del proyecto Nombre en clave Fecha de comienzo Descripción Estado Contacto Organismo ejecutante Ficha de identificación de proyecto Nombre completo del proyecto Si existe un acrónimo, abreviatura o identificador interno Si el proyecto está ya en marcha, indicar fecha de comienzo Breve descripción de la finalidad y objetivos del proyecto Mencionando estado del arte de la tecnología Identificando áreas de aplicación Incluyendo resultados perseguidos Contratación, Diseño, Desarrollo, Producción Datos de contacto incluyendo al menos: Nombre, afiliación, teléfono y correo electrónico de personas relevantes Responsable funcional del proyecto Responsable técnico del proyecto Consejería, Subdirección, Departamento o entidad responsable del proyecto Nombre completo Dirección de su sitio web Persona de contacto 5

7 Colaboradores Funcionalidad Sitio web del proyecto Información y datos de contacto de organismos, entidades, o empresas colaboradoras en el proyecto Nombre completo Dirección de su sitio web Persona de contacto Rol que desempeñan en el proyecto Descripción lo más detallada posible de las funcionalidades del proyecto Describiendo problemas que soluciona Comentando acciones que posibilita Identificando áreas de aplicación Direcciones en Internet del proyecto (incluir varias, si existen o si son diferentes según su función) Sitio web del proyecto Sitio web donde el desarrollo se lleva a cabo Foros o wikis Listas de correo Descripción técnica Descripción técnica lo más detallada posible Lenguajes de programación Sistemas operativos Estándares empleados Requisitos Software Lenguajes de programación y plataformas de desarrollo empleadas en el desarrollo del proyecto. Indicando cuando sea posible: Número de versión y sistema operativo Dependencias de librerías APIs o servicios web utilizados Sistemas operativos en los que es posible desplegar la solución. Indicando cuando sea posible: Arquitecturas Números de versión Enumeración de los estándares empleados por la solución. Indicando cuando sea posible: Si se trata de estándares abiertos o cerrados Organismo que define el estándar Dirección donde se encuentra la especificación Especificar requisitos software específicos para el despliegue de la solución. Indicando cuando sea posible: Números de versión de sistemas operativos Números de versiones de librerías y APIs Dependencias con otros paquetes de software 6

8 Requisitos Hardware Interno Desarrollo interno propio de la Xunta? Especificar requisitos hardware específicos para el despliegue de la solución. Indicando cuando sea posible: Requisitos mínimos Requisitos recomendados Tipología del desarrollo Externo Desarrollo de terceros (contratación externa)? A la medida Desarrollo a medida desde cero? Adaptación Adaptaciones sobre un proyecto existente? Además de la información facilitada en esta ficha de identificación será preciso definir otra serie de aspectos importantes en el proceso de liberación, de manera menos esquemática. Las secciones siguientes pretenden dar diferentes orientaciones para la toma de decisiones temprana en dicho proceso Eligiendo momento y estrategia de liberación En esta sección nos detenemos para elegir un momento y una estrategia de liberación adecuadas a nuestros objetivos y al proyecto en particular que estemos tratando. Si dicho proyecto se encuentra ya en fase de producción se puede pasar al siguiente punto: 2.3. Perspectivas de desarrollo futuro del proyecto. Resulta de mucha ayuda para la posterior toma de decisiones saber en este punto temprano del proceso cuál será nuestra estrategia de liberación. Tal vez la más importante de las cuestiones a decidir es el momento de la liberación del proyecto. Para lo cual se presentan principalmente dos opciones: A. Desarrollo del proyecto en abierto desde el inicio. Que consistiría en realizar una liberación temprana del proyecto, buscando la máxima implicación de la comunidad a costa, tal vez, de cierta perdida de control sobre el proyecto. B. Liberación del proyecto ya en fase de producción. Que conllevaría más trabajo interno para la entidad que lidera el proyecto, especialmente en las fases de publicación. Pero a cambio permite un mayor control sobre el proyecto. Desarrollo en abierto desde el comienzo del proyecto Esta opción resulta una opción tal vez más afín a la filosofía clásica del software 7

9 libre y el desarrollo en comunidades. El lema release early release often 3 (libera pronto, libera a menudo), ha sido desde hace tiempo directiva principal para muchos proyectos libres exitosos. Entre las ventajas de liberar temprano cabe reseñar: Crear comunidad más fácilmente y asegurarse de que será más madura cuando el proyecto llegue a producción, puesto que habrá crecido junto a él. Recabar más fácilmente una buena base de testers para el proyecto, que sienten que entran en la comunidad en una fase en la que todavía es excitante y novedoso. Se estimula y agradece a los potenciales contribuidores de la comunidad a través de una rápida y temprana aplicación de sus aportaciones. Se minimiza la proliferación de bugs (errores en el código) mediante el sometimiento temprano y continuo del código a escrutinio público. El proyecto se beneficia de la innovación abierta y la aportación de ideas provenientes de la comunidad, que podrían no haber surgido de un grupo pequeño y dedicado. El desarrollo en abierto desde el principio puede no resultar tan adecuado si necesitamos tener un control estricto sobre el proyecto. Dado que la principal desventaja de este curso de acción es la cesión de protagonismo a una comunidad de agentes externos, que aunque podría ser muy fuerte, sana y bienintencionada no tiene por qué perseguir nuestros mismos objetivos. Una situación así podría causar cierta pérdida de control sobre el proyecto. Si queremos llevar a cabo una liberación temprana y desarrollo en abierto habrá que tener en cuenta las siguientes cuestiones y definir políticas al respecto, tan pronto como sea posible: Establecer unas normas para la creación de usuarios en los sistemas de desarrollo colaborativo que se utilicen (preferentemente el Repositorio de Software Libre de la Xunta de Galicia). Tanto para forjas, como para repositorios de código. También habrá que definir políticas de usuarios para wikis de documentación, listas de correo y otros canales de comunicación. Definir una política de aceptación de cambios en la rama principal del código en el sistema de control de versiones, que podrá incluir o no un proceso de revisión por parte de la Xunta o la entidad responsable del área técnica correspondiente. Habrá que decidir si los colaboradores externos, como por ejemplo 3 Popularizado por Eric S. Raymond en 8

10 empresas contratadas por la Xunta, tendrán permisos para modificar el código a discreción según tengan nuevas aportaciones o si enviarán sus cambios por lotes. Resultará especialmente sensible en este modelo de liberación temprana la correcta y atenta gestión de la comunidad. Asuntos que podrán estudiarse en mayor profundidad en las secciones 3.2. Elaboración del Documento de Gestión de Comunidad y 5.1. Gestión de la comunidad. Liberación del proyecto en fase de producción Podría darse que las circunstancias aconsejen una liberación del proyecto ya en fase de producción. Bien porque se quiere mantener un control estricto del desarrollo o bien porque tratemos de liberar un proyecto que originalmente fuera software privativo. Las ventajas de este modelo son las siguientes: Se evita un posible fork del proyecto en fase de desarrollo. Un fork es una división de opiniones técnicas o personales que genera la creación de una versión alternativa del proyecto. A menudo los fork son considerados dañinos para los proyectos. Resulta mucho más fácil controlar la consecución de objetivos del proyecto y mantener el foco sobre los intereses principales. Al eliminar el elemento de deriva que introduce la innovación abierta. Resulta más fácil controlar los tiempos del proyecto al no ser necesario invertir tiempo y recursos en la gestión de la comunidad, aunque como contrapartida el desarrollo dependerá exclusivamente de los recursos internos. La imagen del proyecto y su percepción externa es controlable a través de métodos tradicionales de marketing y recae principalmente en los actores internos. Existe una ventaja competitiva de explotación comercial a través de consultoría o servicios de formación o adaptación, para los participantes internos sobre aquellos que adoptarán el proyecto más tarde, en su liberación. Esta última ventaja podría convertirse en una potencial merma de imparcialidad en el caso de que se espere que sean varias las empresas que exploten el proyecto y algunas de ellas no hubieran participado en el desarrollo desde el comienzo. Sin duda tendrían ventaja, en forma de un mayor conocimiento, aquellas que hubieran estado en él desde el principio. Otra desventaja de este modelo de liberación reside en la mayor disposición de recursos que se requiere por parte de los ejecutantes, al no haber aportación de la comunidad durante el desarrollo. Esto nos lleva a la mayor desventa- 9

11 ja; la creación de una comunidad a posteriori, cuando el proyecto ya está maduro, será mucho más difícil. La percepción que tengan del proyecto los potenciales contribuidores será menos motivadora y excitante que la de aquellos proyectos en los que haya más cosas por hacer y decidir. Si se opta por una liberación en la fase de producción habremos de tener en cuenta los siguientes puntos en nuestro curso de acción: Elegir una licencia atractiva para la comunidad. Crear comunidad será el reto más complejo de un proyecto liberado en fase de producción y elegir una licencia oscura, poco conocida o con mala reputación podría ser un lastre importante para este objetivo. Definir con especial cuidado la documentación tanto de usuario como para desarrolladores. Habrá que facilitar la entrada de agentes externos a un proyecto que ya está maduro. Si no van a poder hacer las cosas a su manera, al menos habrá de estar claro cuál es la manera adecuada de hacerlas. Hacer buena publicidad del proyecto y mantener canales de comunicación abiertos y claros. Establecer un buen canal de noticias, anunciar los bugs y los avances con regularidad y mantenerse atento para responder adecuadamente a sugerencias y ofertas de colaboración Perspectivas de actividad e implicación futuras Con el objeto de decidir el nivel de implicación y recursos que habrán de dedicarse al proyecto en el futuro, tendremos que tener claros algunos puntos durante la fase de identificación. Principalmente deberíamos sopesar aquellas circunstancias que nos indiquen la importancia del proyecto para nuestros intereses, tales como si resulta una dependencia importante para otros proyectos interesantes, si es un proyecto que proporciona una buena imagen o si se espera que la comunidad crezca rápido. El siguiente cuestionario comentado sitúa el foco en algunas de los principales aspectos a tener en cuenta a la hora de decidir la dedicación e implicación según nuestros intereses: Tenemos recursos humanos y económicos que dedicar al proyecto? A veces la escasez de recursos o incapacidad de actuación en un determinado momento puede hacer que descuidemos el proyecto. Pero hay muchas cosas que se pueden hacer por un proyecto que no cuestan mucho dinero y que no llevan demasiado tiempo, como por ejemplo hacer difusión del mismo en páginas web que ya existan y estén bajo nuestro control. Tenemos un especial interés en participar activamente en el proyec- 10

12 to una vez esté liberado o preferimos ser usuarios u observadores? Puede resultar que todo lo que necesitamos de un proyecto sea cubierto por su comunidad. En ese caso podríamos decidir no implicarnos más allá de ser usuarios. Queremos ofrecer servicios de informe de fallos, canales de comunicación, página web y otras infraestructuras? A menudo las infraestructuras están presentes para otros proyectos. Deberíamos decidir si vamos a querer mantenerlas, si vamos a solucionar los errores que se reporten y si vamos a frecuentar los canales de chat, por ejemplo. Queremos participar activamente en el desarrollo? Habrá que decidir si vamos a invertir tiempo de desarrolladores en el proyecto, si merece la pena y si necesitamos ese tipo de control. Necesitamos establecer un control sobre los objetivos y la evolución del proyecto? Si es así, habremos de considerar el pertenecer a su comunidad de manera activa y mantener una buena comunicación con el resto de participantes. Según el tipo de respuestas que queramos dar a este conjunto de preguntas, podremos situarnos principalmente en cuatro posturas respecto del proyecto una vez liberado, de menor a mayor implicación, serían: Desvincularse y no participar en la comunidad, de manera que una vez liberado el proyecto, si no nos interesa o no podemos permitirnos el esfuerzo que conlleva, lo abandonemos independientemente de que otros actores intervengan o no. En este caso sería suficiente con publicar el proyecto siguiendo los pasos descritos en el apartado 4.Fase de publicación en el Repositorio de Software Libre de la Xunta de Galicia. Participar en la comunidad de manera pasiva. Consistiría en un modo de colaboración de baja actividad, pero presencia notable. Una buena posibilidad es mantener vigilancia en los foros del proyecto, ofreciendo respuestas a las dudas de los agentes externos que se interesen en el proyecto o publicando nueva documentación que se vaya elaborando durante el uso del proyecto, Esta actividad no supone una dedicación excesiva mientras que el valor añadido y la visibilidad que ofrece el ser el encargado de las infraestructuras de un proyecto son muy grandes. Participar activamente en la comunidad. Por supuesto, además de todo lo anterior, participar activamente en la comunidad aunque sea sin aportar mucho código, es una manera de elevar el grado de implicación. Existen muchas tareas accesorias al desarrollo que son muy valiosas para el proyecto y que pueden dar mucha visibilidad y otorgar méritos a nuestra organización, como son la preparación de documentación técnica, llevar a cabo pruebas y el hacer reportes de fallos, la organización de 11

13 eventos, la promoción del proyecto y la productización en general. Participar activamente en el desarrollo. Idealmente, siempre que case con nuestros intereses y los recursos disponibles lo permitan, la relación perfecta con un proyecto es participar de manera sustancial en el desarrollo del código. Esto nos dará máxima visibilidad y control tanto en aspectos técnicos como en la dirección del proyecto y sus objetivos. Otro aspecto importante que conviene definir en esta fase (sobre el que se ampliará información en el capítulo 3.2. Elaboración del Documento de Gestión de Comunidad) es el modelo de comunidad que queremos implantar. Porque aunque no existe una categorización comúnmente extendida para clasificar las diferentes comunidades, sí se puede hacer una diferenciación importante ajustando roles y características de la comunidad, tales como el control que se ejerce sobre el proyecto, las barreras de entrada que se establecen, los procesos internos o las infraestructuras y herramientas. Una vez hemos concluido la identificación del proyecto y tenemos clara la estrategia de liberación y el tipo de implicación que planeamos tener a lo largo del la vida del proyecto, pasaremos a la Fase de Preparación. 12

14 CAPÍTULO 3.- FASE DE PREPARACIÓN Licenciamiento del proyecto La diferencia fundamental entre el software libre y el resto del software es la licencia, que en el caso del software libre permite una gestión alternativa de la propiedad intelectual. Una de las principales decisiones que habremos de tomar a la hora de liberar un proyecto de software libre es sin duda la licencia que le queremos dar al código, dado que las diferencias entre las licencias implican condiciones de uso y redistribución totalmente diferentes. En términos sencillos se puede pensar en la licencia como un contrato unilateral entre el autor (más correctamente el dueño de los derechos) y los usuarios, que establece qué se puede hacer con el software y bajo qué condiciones. Es decir, las condiciones y restricciones impuestas por las licencias sólo pueden ser definidas por los propietarios de los derechos del software. Un aspecto importante a destacar es que la propiedad intelectual seguirá siendo suya puesto que la licencia no conlleva la trasmisión de los derechos. Tan solo se garantizan derechos de uso y en algunos casos de distribución. También conviene recordar que cada nueva versión de un programa es considerada una nueva obra. Esto significa que el dueño de los derechos puede elegir distribuir cada nueva versión de su programa bajo una licencia diferente cada vez, si así lo desea. Una licencia de software es una licencia libre si cumple con las cuatro libertades del software libre que se detallaron en el capítulo 1. Introducción. Según la Free Software Foundation y la Open Source Initiative, no son licencias libres aquellas que pretenden evitar usos determinados del software (por ejemplo, impidiendo su uso militar o comercial o restringiendo su uso exclusivamente para entornos educativos) ni las que impiden la creación de obras derivadas. Informe de recomendación de licencia Antes de proceder a realizar el licenciamiento del proyecto deberá realizarse una consulta técnico-legal a la Oficina de Coordinación de Software Libre de la Xunta de Galicia para que pueda analizar las posibles dependencias software del proyecto y sus correspondientes licencias para detectar posibles incompatibilidades de cara a elaborar un informe de recomendación de licencia particular. La Oficina de Coordinación de Software Libre contará para esta tarea con el 13

15 asesoramiento de CENATIC. Para elaborar este informe será preciso proporcionar los siguientes elementos: Documentación contractual involucrada en el desarrollo del proyecto (contratos, pliegos, ofertas técnicas, ) En caso de no ser posible disponer de esta documentación completa la Oficina proporcionará un Documento de cesión de derechos que deberán firmar todas las empresas o terceras partes involucradas en el desarrollo para garantizar que la Xunta de Galicia es la propietaria de los derechos del software. Acceso al código fuente y documentación asociada al proyecto. En los siguientes apartados hacemos una distinción entre licencias para el software y licencias para la documentación que lo acompaña, ya que tanto la licencia como la manera de incluirla difiere en ambos casos. También hablaremos de cómo elegirlas y repasaremos algunos conceptos generales, como el licenciamiento dual Elegir una licencia para el software Aunque la Comisión Europea recomienda emplear la licencia EUPL 4 para los desarrollos de las administraciones públicas, será preciso evaluar cada caso particular para analizar la conveniencia o necesidad de escoger esta u otra licencia o incluso realizar un licenciamiento dual. En cualquier caso debemos evitar siempre la creación de una nueva licencia por dos razones fundamentales: Familiaridad. Si usamos una licencia bastante popular, los potenciales contribuidores al proyecto sentirán que conocen las bases del trato que se les propone. Calidad. Resulta muy complicado elaborar una licencia nueva que sea sólida aun incluso con un buen grupo de abogados a disposición. Existe un gran número de buenas licencias de software libre entre las que escoger. La mayoría no tendremos por qué considerarlas ya que fueron elaboradas para satisfacer necesidades legales particulares de proyectos concretos. De manera que lo ideal sería escoger entre las licencias más utilizadas puesto que es muy probable que alguna se ajuste a nuestras necesidades. Para tener en cuenta todos los factores que entran en juego al escoger una licencia, hemos de hacernos las siguientes preguntas:

16 Queremos que la gente sea capaz de hacer sus modificaciones privadas? Si queremos que los cambios que otros hagan al código sean hechos públicos al redistribuirlo, habremos de escoger una licencia que así lo ordene. Como por ejemplo la GPL o la LGPL. Si no nos importa, podríamos usar una licencia que no lo requiera, como la Apache 2.0. Queremos que nuestro programa se pueda mezclar con software propietario? Si es así, podríamos querer usar la LGPL que permite explícitamente mezclar el software privativo con el software LGPL si este último no se modifica. También podríamos usar las licencias estilo BSD como la Apache 2.0 que permiten que las modificaciones que hagamos a proyectos bajo ellas pasen a ser software privativo. Queremos que algunas personas puedan comprar versiones con licencias propietarias del software? Entonces lo ideal sería establecer un licenciamiento dual, por ejemplo usando la GPL como licencia libre y además una licencia privativa que se aplicará a una versión diferente del software. Es importante para nosotros el modelo de negocio para la explotación del proyecto? Esta pregunta también puede influir en nuestra decisión a la hora de escoger una licencia puesto que diferentes modelos de negocio pueden requerir o recomendar diferentes licencias. Planeamos integrar software de diferentes fuentes? Si la respuesta es sí, habremos de prestar mucha atención a las compatibilidades e incompatibilidades entre licencias. Especialmente respecto de la GPL, debido a su importancia y difusión. La siguiente tabla presenta algunas de las licencias de software libre más populares y algunas de sus características: Licencia Berkeley Software Distribution License (BSD) Apache License 2.0 Mozilla Public License (MPL) Licencias populares de software libre Enlazado con software propietario Distribución del trabajo original Redistribución del código modificado Compatible con la GPL Permitido. Permitido. Permitido. Sí. Permitido. Permitido. Permitido. Permitido. Permitido. Solo bajo la MPL de nuevo. Solo con la GPLv3. No. 15

17 Lesser GNU Public License (LGPL) Affero GPL License GNU Public License (GPL) Licencias populares de software libre Permitido. Permitido con algunas restricciones. Solo bajo LGPL o GPL. No permitido. Permitido. Permitido. No permitido. No permitido con software cuya licencia no es compatible con GPL. Solo bajo la GPL. Sí. Con la GPLv3. Sí. Una vez escogida la licencia idónea, el procedimiento a seguir para su correcta aplicación al proyecto puede variar según la licencia y el tipo de proyecto, pero en líneas generales es el siguiente: 1. Conviene publicar en la página web del proyecto cuál es la licencia que hemos escogido y enlazar al texto completo de la licencia en cuestión. 2. Para que tenga efectos legales, se ha de distribuir la licencia junto con el código fuente del programa. Esto se hace adjuntando una copia de texto íntegro de la licencia en un fichero junto con la distribución. Generalmente en un fichero llamado COPYING. 3. También debemos incluir en cada fichero de código fuente una nota del copyright y una autorización de copia, estableciendo que el programa se distribuye bajo la licencia correspondiente. La nota de copyright se incluirá, como decimos, en cada uno de los ficheros fuentes. Deberá indicar el año y el dueño del copyright. Algo con este formato resulta adecuado: Copyright 2012 Xunta de Galicia. Se utiliza la palabra copyright por convención internacional, incluso para materiales que están en idiomas diferentes al inglés. La autorización de copia se incluirá en cada uno de los ficheros fuentes y establece, con palabras sencillas, cuál es la licencia bajo la cual se distribuye el programa y dónde se puede leer el texto íntegro de la misma. De este modo, además de mantener el texto íntegro de la licencia en un fichero llamado COPYING, para licenciar bajo la GPL nuestro software, incluiríamos en cada fichero el siguiente encabezado: 16

18 Copyright (C) 2012 Xunta de Galicia This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or(at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program in a file called COPYING. If not, see < No es necesario que nuestro encabezado sea exactamente igual que este ejemplo, solo tendremos que asegurarnos de que incluye la nota del copyright, que deja bien claro cuál es la licencia que estamos usando y dónde podemos encontrar el texto íntegro de la misma Elegir una licencia para la documentación El mundo del software libre ha inspirado licencias libres para otros ámbitos, como la música, las producciones audiovisuales, la fotografía, el diseño u obras literarias. Muchas de ellas han evolucionado a partir de las licencias para la documentación que se han venido utilizando en proyectos de software libre. En la situación actual, cabe destacar por su popularidad, dos principales tendencias a la hora de licenciar la documentación que acompaña a un proyecto libre: la licencia GNU Free Documentation License (GFDL) y las licencias Creative Commons, un completo marco jurídico mediante el cual confeccionar diferentes licencias para obras diversas. La GNU Free Documentation License (GFDL) es la licencia promovida por la Free Software Foundation para contenidos libres. En un principio fue diseñada para manuales, libros de texto y otras obras funcionales, entendiendo por obras funcionales aquellas que nos ayudan a llevar a cabo un trabajo, como los manuales, las guías y la documentación del software. Se definen las obras no funcionales como aquellas obras artísticas cuyo principal objetivo es el entretenimiento, como las películas, las novelas o las canciones. La GFDL asegura que el material pueda ser usado, copiado, modificado y redistribuido manteniendo los términos de la licencia y especifica algunos detalles de la redistribución, como la obligación de proporcionar un formato transparente si se superan los 100 ejemplares o la posibilidad de incluir secciones invariantes, que puede convertirse en un inconveniente. La GFDL presenta también ciertos problemas con su clausula anti-drm, puesto 17

19 que no permite ofuscar las copias (ni las privadas, incluyendo el cifrado), algo que resulta muy poco práctico en algunas situaciones. Además, está demasiado orientada a la impresión y se requiere imprimir una copia de la licencia junto con la obra (o parte de ella) cuando esta se imprime. Por todo esto, en términos generales se recomiendan las licencias Creative Commons para la documentación que acompaña al software, que permiten aplicar el concepto de licencia libre fuera del software de manera generalizada. Creative Commons es una organización con el objetivo de crear un conjunto de licencias que sirvan para cualquier tipo de contenidos, crear un catálogo de obras licenciadas bajo Creative Commons y adaptar internacionalmente el marco completo. Las licencias Creative Commons son muy populares y están muy extendidas por su sencillez. Las licencias Creative Commons se presentan en tres capas, para facilitar su uso y comprensión: Commons deed: es el resumen del texto legal simplificado, indicado para no-abogados e incluyendo iconos. Legal Code: es el texto legal completo Digital Code: es un código digital para motores de búsqueda y otras aplicaciones Las licencias Creative Commons se basan en combinar distintas cláusulas: Reconocimiento (attribution -by): obliga a citar las fuentes y dar crédito al autor No comercial (non-commercial -nc): no permite usos comerciales Sin obra derivada (no derivatives -nd): obliga a la no alteración de la obra Compartir igual (share-alike -sa): obliga a distribuir las obras derivadas bajo la misma licencia que el trabajo original, implementando así el concepto de copyleft en el marco de Creative Commons. Las diferentes combinaciones posibles dan lugar a las 6 posibles licencias, conocidas como las licencias Creative Commons: 1. Reconocimiento (by) 2. Reconocimiento + No Comercial (by-nc) 3. Reconocimiento + Sin Obra Derivada (by-nd) 4. Reconocimiento + Compartir Igual (by-sa) 5. Reconocimiento + No Comercial + Sin Obra Derivada (by-nc-nd) 18

20 6. Reconocimiento + No Comercial + Compartir Igual (by-nc-sa) Hay que tener en cuenta que las licencias con la clausula Sin Obra Derivada (nd) y las licencias con la cláusula No Comercial (nc) no son compatibles con las cuatro libertades del software libre. Así que no deberían ser consideradas como licencias libres según la definición de la Free Software Foundation. Por regla general, si queremos que nuestra documentación sea redistribuida bajo una licencia libre, es posible que nuestra mejor opción sea la licencia Reconocimiento + Compartir Igual (by-sa) y esa es nuestra recomendación. El procedimiento a seguir para incluir la licencia en la documentación que acompaña al software es muy sencillo. Basta con incluir al comienzo de la obra una nota que indique cual es la licencia que hemos escogido y dónde se puede encontrar el texto completo de la misma, por ejemplo: Esta obra está bajo una licencia Atribución-CompartirIgual 3.0 España de Creative Commons. Para ver una copia de la licencia, visite: Otras versiones de la misma nota incluyen a veces la dirección física de la sede de Creative Commons para solicitar una copia del texto de la licencia, aunque esto es ya algo opcional: Este trabajo está publicado bajo una licencia Creative Commons Atribución-Compartirigual 3.0. Para ver una copia de la licencia visite: O envíe una carta a: Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA Licenciamiento dual Un esquema de licenciamiento dual consiste en distribuir dos (o más) versiones diferentes de un producto de software bajo diferentes licencias. Las versiones del programa pueden ser casi iguales, siendo la licencia la única diferencia sustancial. El licenciamiento dual es un intento de conciliar los intereses enfrentados del desarrollo de software libre, devoto de las licencias libres clásicas, y la explotación comercial. Muchos proveedores de software libre han adoptado alguna forma de licenciamiento dual por razones como las siguientes: Para conseguir una mayor compatibilidad del código. Sirva de ejemplo el proceso de relicenciamiento por el que pasó hace poco el proyecto Mozilla. De liberar su código bajo la MPL (Mozilla Public License) pasó a 19

21 hacerlo bajo un sistema de licenciamiento triple MPL/GPL/LGPL, para asegurarse la compatibilidad con la GPL y la LGPL. Para segmentar el mercado. El caso más claro lo protagonizó la compañía MySQL que estableció su modelo de negocio alrededor de dos versiones de su producto principal: una libre en la que aceptaban contribuciones externas y colaboraciones y una propietaria que incluía mejoras y adaptaciones que no se implementaban en la versión libre. Para otorgar diferentes permisos según quién sea el receptor. A veces resulta útil utilizar un sistema de licenciamiento múltiple para definir diferentes condiciones de uso según el receptor del software. Por ejemplo, para ofrecer adaptaciones, adelantos del desarrollo principal o para garantizar derechos extra a terceros Elaboración del Documento de Gestión de Comunidad. Un aspecto clave para obtener los beneficios de la liberación de software es un correcto modelo de gestión de la comunidad en el que desde la administración pública se promueva la participación de las propias empresas TIC locales y las comunidades de desarrollo, de manera que se garantice la sostenibilidad del software liberado. Es decir deberá establecerse cuales serán las normas de gestión y participación en la comunidad que se dedicará a mantener y mejorar el proyecto en el tiempo, con el objetivo de que pueda llegar a ser un proyecto libre autónomo. Existen tantos modelos de gestión de comunidad como proyectos de software libre, pero en líneas generales podemos distinguir dos modelos opuestos: Dictador benevolente, en el que el control del proyecto está centralizado en un único individuo u organización. Los fundadores del proyecto determinan la dirección del proyecto tomando las decisiones finales cuando la comunidad está en desacuerdo. Meritocracia, en el que el control del proyecto se encuentra distribuido entre los miembros de la comunidad en base al reconocimiento de los méritos de cada uno. Es posible encontrar modelos de gestión en cualquier punto dentro del espectro determinado por estos dos modelos. Por supuesto también es posible que el modelo de gestión de un proyecto evolucione con el tiempo, comenzando por ejemplo con un modelo de dictador benevolente puro que a medida que la comunidad y el proyecto van creciendo y madurando evoluciona hacia un modelo más meritocrático. A la hora de definir el modelo de gestión de la comunidad será conveniente te- 20

22 ner presentes las reflexiones realizadas previamente en el apartado Pers pectivas de actividad e implicación futuras sobre cual va a ser el papel de la administración en el futuro del proyecto y dentro de la comunidad. Una vez escogido el modelo de gestión más adecuado deberán plasmarse en un Documento de gestión o plan de comunidad cuales serán las reglas de juego de la comunidad que va a mantener el proyecto. Para conseguir una comunidad fuerte es fundamental que los futuros miembros puedan conocer en todo momento de que forma pueden contribuir a mejorar el proyecto, en que áreas pueden colaborar, que condiciones se deben cumplir para que sus contribuciones sean aceptadas, cual es la política o las reglas para la toma de decisiones dentro del proyecto, cuales son los canales de comunicación principales Estos y otros aspectos deberán incluirse en el Documento de gestión o plan de comunidad que contendrá al menos los siguientes apartados: Descripción del proyecto. Breve resumen de los objetivos del proyecto, cómo se gestiona, incluyendo enlaces al resto de apartados del documento. Además se incluirá en este apartado la licencia del proyecto y quien es el titular de los derechos. El objetivo es ofrecer a la gente una rápida visión global de qué tipo de proyecto es y qué se espera de ellos si se quieren unir a el. Estructura de la comunidad. Esta sección describirá los equipos, los roles y el reparto de responsabilidades, que dependerán del modelo de gestión escogido. Incluirá también el nivel de compromiso necesario para obtener cada rol. Se deberá definir lo más claramente posible quien gestiona el proyecto, quien y como puede contribuir y que pasos es necesario seguir para llegar a poder influir directamente en el futuro del proyecto. Procedimiento de toma de decisiones. Es importante establecer un proceso de toma de decisiones claro, transparente y eficaz. Si el proceso es tedioso y complejo, es posible que las decisiones se prolonguen demasiado, afectando a los tiempos y plazos de desarrollo. Si el proceso no es claro y está poco definido, es posible que las decisiones sean cuestionadas constantemente por los miembros de la comunidad creando malestar y conflictos. Procedimientos de trabajo. (política de contribuciones, política de versionado, ) En esta sección se definirán la política de contribuciones y la política de versionado. La primera documentará cómo se puede contribuir al proyecto y a través de que herramientas. Deberá incluirse también como se va gestionar el copyright de las contribuciones, que estándares de codificación y documentación se van a emplear. Finalmente se debe describir el proceso de aprobación de las contribuciones de terceros así como qué ocurre con aquellas que no se consideren adecuadas para el 21

23 proyecto. El objetivo final de esta política es asegurar que el control de calidad y control legal de todas las contribuciones es adecuado para conseguir un producto atractivo y funcional para los usuarios finales. La política de versionado definirá la periodicidad de las versiones así como quien decidirá el momento de publicación... Infraestructura de la comunidad. En esta sección se indicará cuales son las herramientas de desarrollo, soporte, difusión, comunicación... de las que dispondrá la comunidad. A la hora de elaborar este documento es necesario tener presente que ha de ser un documento vivo que deberá contener las normas iniciales mínimas para que la comunidad pueda funcionar pero que podrá completarse y modificarse en el tiempo por la propia comunidad. 22

24 CAPÍTULO 4.- FASE DE PUBLICACIÓN EN EL REPOSITORIO DE SOFTWARE LIBRE DE LA XUNTA DE GALICIA Una vez identificado el proyecto, verificados los aspectos técnicos y legales que permiten su liberación, escogida la licencia de distribución para el software y para la documentación y elaborado el documento de gestión de la comunidad, es el momento de proceder a la publicación del proyecto en el Repositorio de Software Libre de la Xunta de Galicia. En los apartados siguiente iremos describiendo cuales son los pasos necesarios para realizar esta publicación correctamente Creación del proyecto en el Repositorio de Software Libre de la Xunta de Galicia Para crear un proyecto en el Repositorio de Software Libre de la Xunta de Galicia ( es necesario tener previamente un usuario registrado en dicho servicio, que será el administrador del proyecto. Para crear un usuario se accede al formulario de alta desde la opción Conta nova, situada en la parte superior derecha de la portada de la Forxa. En el formulario de alta que aparece deberán cubrirse al menos los datos obligatorios: Nombre de la cuenta de usuario, contraseña, nombre y apellidos del usuario y correo electrónico. Lo más recomendable es que se cree una cuenta de usuario genérica para el departamento de la Xunta responsable del proyecto, asociada a una cuenta de correo electrónico también genérica. Es preferible esta opción frente al uso de una cuenta personal para evitar pérdida de acceso al proyecto motivadas por traslados del personal entre departamentos. Una vez registrado el usuario, este accederá al sistema para crear el proyecto para lo que deberá seleccionar la opción Registrar un nuevo proyecto y cubrir un formulario como el siguiente: 23

25 Para registrar un proyecto, debe introducir una información básica sobre él. Por favor, lea las descripciones más abajo e introduzca datos completos y comprensibles. Todos los campos son necesarios. 1. Nombre completo del proyecto Debería comenzar especificando el nombre del proyecto. El "nombre completo" es descriptivo, y no tiene ninguna restricción arbitraria (exceptuando un límite de 40 caracteres). Nombre completo: 2. Propósito del proyecto y resumen Por favor, proporcione una descripción detallada y precisa de su proyecto y que recursos de A Forxa piensa utilizar. Esta descripción es básica para aprobar o rechazar el alojamiento de su proyecto en A Forxa, y después, para habilitar el uso de los servicios solicitados. Esta descripción no se utiliza como descripción pública de su proyecto. 3. Descripción Pública del Proyecto Esta es la descripción de su proyecto que se muestra en la página de Sumario del Proyecto, en resultados de búsquedas, etc. La longitud máxima son 255 caracteres. 4. Licencia [Lista desplegable para escoger la licencia: GPL, LGPL, EUPL, BSD, MIT, otra] Si ha elegido "Otra", por favor, introduzca una descripción sobre los términos de su licencia. Emplear otra licencia generalmente no se aprueba. Esto requiere tiempo adicional para tomar una decisión sobre su proyecto ya que es necesario comprobar si la licencia es compatible con la definición de Código Abierto. 5. Nombre Unix del proyecto Además del nombre completo del proyecto, necesita escoger un nombre corto, "Unix", para su proyecto. El "nombre Unix" tiene varias restricciones debido a que se emplea en muchos lugares en todo el sitio web. Las restricciones son: No puede coincidir con el nombre Unix de otro proyecto Debe tener entre 3 y 15 caracteres de longitud Debe estar en minúsculas Solo puede contener letras, números y guiones Debe ser un nombre de usuario unix válido No puede coincidir con el nombre de alguno de nuestros dominios El nombre unix no puede cambiarse para este proyecto Nome unix: 24

26 6. SCM Debe elegir un único sistema entre los diferentes SCM para su proyecto. Debe elegir sólo uno. Por favor, elija el sistema SCM que desea usar. No podrá cambiar una vez registre el proyecto No SCM SVN GIT Es importante destacar que aunque se indica que la elección del Sistema de Control de Versiones no podrá modificarse a posteriori, esto se refiere que no se puede hacer un cambio automático. Sí es posible cambiar de SVN a GIT (o viceversa) para un determinado proyecto. El cambio implica que el repositorio antiguo se desactiva para crear el nuevo. Por esta razón si ya contiene código y no queremos perderlo será imprescindible descargar primero una copia del mismo al equipo local y realizar la migración de SVN a GIT en local y después volver a subirlo a la Forxa una vez creado el nuevo repositorio. Una vez completado el proceso de alta del proyecto, este será validado por los administradores del Repositorio de Software Libre de la Xunta de Galicia que en un breve plazo aprobarán el proyecto si no detectan ningún problema, recibiendo un aviso en el correo electrónico el usuario que lo ha creado. En un par de horas desde la aprobación estarán funcionando todos los servicios para dicho proyecto Alta de usuarios desarrolladores en el proyecto y asignación de permisos Una vez está creado el proyecto, el segundo paso será proceder a la asignación de roles y permisos adecuados a los distintos usuarios que hayan sido aprobados para colaborar en el proyecto. Esto se realiza desde la sección Admin Usuarios del proyecto desde una página como la siguiente: 25

27 En la sección Add User se añade el identificador del usuario y posteriormente se le asigna en la sección Project Members el rol adecuado, que incluya los permisos de colaboración en el proyecto para el usuario añadido. Es posible editar o crear nuevos roles desde la sección Editar Roles. Los roles predefinidos en los proyectos son admin, doc writer, junior developer, senior developer y support tech. Cada uno de ellos otorga distintos permisos o privilegios para cada una de las secciones o herramientas de gestión del proyecto: foros, registro de incidencias, documentación, sistema de control de versiones como se puede ver en los ejemplos de las siguientes figuras que muestran la edición del rol Support Tech. y Junior Developer. 26

28 Los permisos que se puede otorgar varían en función de la sección, que resumimos a continuación: Administración del proyecto Ninguno Administración Publicación de ficheros Lectura Escritura (incluye lectura) Documentación Administración Lectura/publicación Foros Sin acceso Leer Publicar Administración Gestor de incidencias Sin acceso: No puede ver el gestor de incidencias Lectura: Puede crear y seguir incidencias. Puede añadir comentarios pero no puede cambiar, borrar o asignar la incidencia. No puede crear tareas asociadas a la incidencia. No puede configurar el gestor de incidencias creando por ejemplo nuevos campos. Técnicos: tendrá los permisos completos para gestionar y resolver incidencias. Así puede leer las incidencias, puede ser asignado a las incidencias, puede crear tareas asociadas a las incidencias. Puede modi- 27

29 ficar los valores de los campos personalizados, no el resto. No puede borrar ni asignar tickets. No puede configurar el gestor de incidencias. Sólo administración: tendrá los permisos necesarios para asignar incidencias y configurar el gestor. Puede crear tareas asociadas a las incidencias, puede cambiar todos los campos de una incidencia, borrar y asignar incidencias. Puede enviar una incidencia a otro gestor dentro del mismo proyecto, puede administrar completamente el gestor de incidencias. Técnicos / administración: Tiene los privilegios técnicos y de administración. Tareas Sin acceso Lectura Técnicos Sólo administración Técnicos / administración Por supuesto para completar esta tarea será necesario tener presente los roles que se hayan definido en el Documento de Gestión de Comunidad en el apartado de Estructura de la Comunidad Publicación del código en el sistema de control de versiones escogido En este paso se realizará la subida del código fuente del proyecto en el sistema de control de versiones escogido, git o svn. Por supuesto, para realizar este paso previamente se habrá obtenido el Informe de recomendación de licencia y se habrá incluido ésta correctamente en el código según lo descrito en el apartado Elegir una licencia para el software Publicación de documentación Para la publicación de la documentación disponemos de diversas opciones. La primera de ellas es la más simple y consiste en publicar en la sección Documentos del proyecto los ficheros correspondientes a: Documento de gestión de comunidad Manual de uso del software Manual de instalación del software Manual/es de desarrollo y cualquier otra documentación técnica que se considere de interés para nuevos desarrolladores 28

30 Para ello se accede a la sección Documentos de nuestro proyecto y se escoge Publicar nuevos documentos. Si la documentación es extensa, es recomendable organizar los documentos en carpetas, lo que se denomina Grupos de documentos. Estos grupos pueden crearse desde la opción Add/Edit/Delete Document Groups dentro del apartado de Administración de esta sección. Una vez creada la estructura de carpetas y subidos los fichero se vería algo como lo de la siguiente figura. Otra opción que disponemos para la publicación de la documentación es hacerlo mediante la herramienta wiki que nos ofrece la forxa para cada proyecto. 29

31 4.5.- Elaboración y publicación de paquetes de instalación (Opcional recomendable) Como hemos comentado ya en anteriores apartados, el objetivo final de liberar un proyecto propiedad de la Xunta de Galicia es ofrecer a la ciudadanía o a las empresas productos útiles y de interés sobre los que estas últimas pueden generar negocio. Por esta razón es recomendable, para aquellos casos en los que sea aplicable, que además de subir el código fuente del proyecto se creen y se publiquen paquetes de instalación (.deb,.rpm,.exe ) que faciliten el uso y prueba del producto. También es recomendable facilitar la descarga del código de la versión estable, por ejemplo en tar.gz, para evitar que sea necesario acceder al sistema de control de versiones, que es una herramienta menos amigable de cara al usuario final. La siguiente figura muestra un ejemplo de un proyecto con descargas disponibles. Existen dos paquetes de liberaciones (corpus y corpus-xmlrpc) que permiten agrupar distintas descargas relacionadas. La publicación de ficheros se realiza desde la sección Ficheros, Administración. 30

32 Antes de poder subir un fichero es necesario crear primeramente un paquete de liberaciones. Una vez creado ya podremos publicar uno o más ficheros en el. 31

33 CAPÍTULO 5.- FASE DE LIBERACIÓN Finalmente llegamos a la última y más importante fase de todo el proceso, la fase de liberación de software. Si bien siguiendo todos los pasos descritos en el capítulo 4. Publicación en el Repositorio de Software Libre de la Xunta de Galicia, nuestro proyecto ya ha sido puesto a disposición de la comunidad con una licencia libre, entendemos que esto no es suficiente para considerar que se ha liberado el proyecto. El aspecto diferencial será conseguir crear una comunidad en torno a él involucrada en su uso, mantenimiento y evolución, en la que se puedan unir los intereses de la administración pública, empresas TIC, usuarios finales... Recogiendo las ideas expuestas por CENATIC en su decálogo para que la administración pública libere su software 5 entendemos que para alcanzar los beneficios de la liberación de software no es suficiente con su publicación web, sino que es necesario un correcto modelo de explotación y comunidad que, promovido por las propias administraciones públicas y con la imprescindible participación del tejido empresarial TIC local y las comunidades de desarrollo, garantice la sostenibilidad del software liberado a través de la transferencia de conocimiento y la correcta gestión de contribuciones. Por esta razón en el siguiente apartado nos centraremos en describir buenas prácticas orientadas a facilitar la creación de comunidad así como algunos signos o indicadores a los que prestar atención ya que son indicativos de que las cosas no están yendo bien. Estos indicadores son conocidos como anti-patrones Gestión de la comunidad Existen una serie de buenas prácticas que se recomienda seguir si queremos llegar a tener una comunidad de desarrolladores alrededor de nuestro proyecto: Compartir con la comunidad el control del código del proyecto. Un aspecto importante que ya hemos destacado en el apartado de elaboración del documento de gestión de la comunidad, es el control sobre el código de nuestro proyecto. Nuestros potenciales colaboradores tienen multitud de proyectos libres en los que poder colaborar, y suelen tender hacia aquellos en los que es posible la colaboración de pleno derecho. Si bien existen múltiples razones y situaciones que pueden aconsejar mantener el control total sobre qué código será incorporado al nú

34 cleo de nuestro proyecto, si somos demasiado rigurosos en este aspecto corremos el riesgo de perder el interés de la comunidad. Así, en caso de aplicar un modelo de dictador benevolente, se recomienda evitar siempre que sea posible, imponer la obligación de cedernos los derechos de autor de todas las contribuciones, o que los únicos autorizados a realizar commits en el repositorio de código sea nuestro propio personal. Si estas situaciones son imprescindibles, siempre podremos fomentar el desarrollo de otros tipos de comunidad, como por ejemplo de desarrolladores de módulos extra para el núcleo del proyecto, de implantadores o integradores de nuestro producto... Minimizar las barreras de entrada. Hay que tratar de minimizar lo máximo posible o eliminar las barreras de entrada en la comunidad. Por ejemplo, utilizando herramientas de colaboración conocidas y fáciles de usar. En nuestro caso, las herramientas que proporciona el Repositorio de Software Libre de la Xunta son de uso extendido en las comunidades de software libre por lo que no deberían suponer una barrera. Sin embargo, aún así debemos prestar especial atención a su configuración permitiendo por ejemplo el acceso anónimo de lectura al código fuente, que los errores puedan ser remitidos de forma anónima sin necesidad de darse de alta en la forxa... También se considera una importante barrera de entrada la necesidad de firmar un documento de cesión de derechos de autor antes de poder contribuir al proyecto. Simplificar los procesos de gestión de la comunidad manteniendo su eficaces. Además de establecer claramente los distintos roles de colaboración y las condiciones para poder optar a cada uno de ellos, se debe prestar atención a que estos procesos sean justos y se apliquen en todo momento. Es conveniente también conseguir que algunos miembros de la comunidad obtengan lo antes posible permisos para por ejemplo ser moderador de errores, para resolver tareas, para acceder al repositorio de código, Cuanto antes se involucre personal externo, mayor probabilidad tendremos de que se genere comunidad y de obtener todos los beneficios que esto reportará a nuestro proyecto. Dedicar recursos específicamente a la gestión de la comunidad. Si es posible, lo ideal es contar con un Community Manager, que pueda dedicarse total o parcialmente a realizar las tareas de gestión y dinamización de la comunidad. Publicar un roadmap del proyecto y cumplirlo, para que la comunidad pueda conocer hacia donde se dirige el mismo y valorar en que sentido 34

35 puede colaborar. Todas estas recomendaciones o buenas prácticas deben aplicarse en su justa medida, puesto que todo exceso es contraproducente. La aplicación al extremo de estas prácticas puede resultar en un efecto rebote. Existen estudios 6 que han identificado una serie de anti-patrones o indicadores de mala praxis ante los que deberemos actuar en caso de detectarlos. 1. Cookie licker o lo que nosotros podríamos llamar el perro del hortelano. Este antipatrón hace referencia a la típica situación en la que alguien ni come ni deja comer. En la gestión de comunidades de voluntarios en ocasiones se presentan situaciones en las que ciertas tareas están paradas y no avanzan porque alguien ha reservado o ha asumido el compromiso de trabajar sobre una tarea pero por diversas razones no acaba de completarla aduciendo que está casi lista, estoy muy liado, la semana próxima estará, trataré de sacar tiempo Las causas que provocan esta situación suelen deberse al deseo de hacer las cosas bien, a que los mejores colaboradores suelen estar siempre muy ocupados, a que realmente creen que pueden sacar tiempo, al miedo a cometer fallos en público Posibles soluciones para evitar esta situación serían: Establecer un roadmap claro y no permitir que nadie se reserve más tareas de las que puede realizar. Si se trata de trabajar sobre nuevas ideas a desarrollar, no permitir que alguien se la reserve en exclusiva, permitir el desarrollo en paralelo de borradores, prototipos, que se revisen en comunidad y se combinen para obtener un resultado mejor. Establecer tiempos para finalizar las tareas y reasignarlas si no se cumplen. Instaurar en la comunidad la cultura de no penalización del fallo. 2. Water cooler o la máquina del café. Situación en la que la mayor parte de los desarrolladores pertenecen a la misma entidad por lo que evitan realizar las discusiones en listas de correo o foros públicos, y rápidamente solucionan las pequeñas discusiones por ejemplo en torno a la máquina del café. Cuando la mayor parte del trabajo se hace en privado, es difícil que la comunidad entienda y comparta las decisiones, por lo que acaban generándose tensiones y en último extremo puede derivar en forks del proyecto. La forma de evitar esta situación es permitir que las decisiones puedan tomarse en pequeños grupos de trabajo para agilizar el proceso, pero que

36 esto se haga de manera pública de forma que cualquiera pueda consultar como se ha llegado a las decisiones si es necesario. Utilizar por ejemplo listas de correo moderadas, wikis protegidos Bikeshedding. Situación en la que se generan interminables debates y discusiones sobre cuestiones irrelevantes, debido fundamentalmente al deseo de participación en la comunidad de miembros con poca experiencia, que no tiene o creen no tener capacidad para participar en otros debates más productivos. Para evitar esta situación el primer paso es reconocerla. Detectar rápidamente cuándo se está produciendo una discusión de este tipo para atajarla a tiempo. Aconsejar a los desarrolladores seniors que no participen en este tipo de discusiones para minimizar su impacto. Obviamente, este antipatrón está muy relacionado con el anterior. Si se producen demasiados debates largos e improductivos, acabará por instaurarse la tendencia hacia los debates privados. 4. Help Vampire. Se refiere a un miembro de la comunidad que absorbe completamente la capacidad de ayuda de la comunidad. Se trata de alguien que ante cualquier duda o pequeño problema, en la mayoría de las ocasiones, resoluble con una simple búsqueda en google o una lectura del manual, envía consultas a las listas o foros públicos antes de realizar una pequeña investigación por su cuenta. Las recomendaciones para evitar este tipo de situaciones es mantener una buena documentación para los usuarios o desarrolladores noveles, animar a los miembros noveles de la comunidad a responder a cuestiones básicas de otros o responder con información sobre donde y como encontrar la respuesta mejor que con la propia respuesta. Por ejemplo, en el capítulo 4 del manual puedes encontrar las instrucciones que buscas, o en esta pregunta del FAQ (enlace) puedes encontrar la respuesta. De esta forma, al tiempo que se les responde a su duda se les guía y enseña cual es el lugar para resolver ese tipo de dudas. Como siempre es necesario mantener un equilibrio entre facilitar la entrada de nuevos miembros a la comunidad y evitar a los help vampire. Si ante cualquier pregunta de un nuevo usuario se le remite de forma genérica a que lea primera las FAQ, el manual, lo que se conoce como RTFM, lo que conseguiremos es asustar y desanimar a los recién llegados y mermar las posibilidades de crecimiento de nuestra comunidad. 5. Warnock's Dilemma Este dilema se presenta ante la falta de respuesta en un foro o lista de correo, cuando alguien ha remitido un parche a la lista de desarrollo, alguien pregunta sobre la usabilidad de un nuevo servicio o sobre la calidad de una nueva versión del software,... La persona que ha remitido la consulta se puede plantear 5 alternativas ante la falta 36

37 de respuesta: 1. El mensaje es correcto, con toda la información necesaria y no necesita más comentarios, más allá de un Correcto o Estoy de acuerdo 2. El mensaje es banal y absurdo y no merece la pena contestarlo. 3. Nadie ha leído el mensaje 4. Nadie ha entendido el mensaje, pero por cualquier razón no quieren pedir aclaración sobre el mismo. 5. A nadie le importa el mensaje. Como norma general se recomienda añadir en los correos indicación expresa a que se espera recibir una respuesta o feedback del resto de la comunidad para actuar en consecuencia (corregir los posibles errores, mejorar la usabilidad, ) Normalmente esto funciona. Por ejemplo, en lugar de enviar un mensaje indicando Acabo de enviar un parche para el error X notificado el día Y sería aconsejable indicar en el propio mensaje que se esperan revisiones del parche. O incluso si la comunidad ha dado muestras de ser activa, podría emplearse la técnica de consenso laxo, en el que se puede indicar que en ausencia de objeciones en un tiempo determinado se dará por aceptado el mensaje. Existen mucha más información a este respecto que puede consultarse en la web. Aquí se han recogido los síntomas más representativos a los que debemos prestar atención si queremos obtener una comunidad activa, participativa y en constante crecimiento. 37