procedimiento de liberación de software de la xunta de … · procedimiento de liberación de...

Procedimiento De Liberación DeSoftware De La Xunta De Galicia

Procedimiento De Liberación DeSoftware 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 Creati-ve Commons. Para ver una copia de la licencia, visite:

http://creativecommons.org/licenses/by-sa/3.0/deed.es

Este documento está disponible en el portal web Mancomún de la Xunta de Galicia

http://www.mancomun.org

XUNTA DE GALICIA

Presidencia

Agencia de Modernización Tecnológica de Galicia

Santiago de Compostela

2012

http://www.mancomun.org/

Procedimiento de liberación de software de la Xunta de Galicia

ÍNDICE

CAPÍTULO 1.- INTRODUCCIÓN ................................................................. 3

CAPÍTULO 2.- FASE DE IDENTIFICACIÓN ................................................. 5

2.1.- FICHA DE IDENTIFICACIÓN DEL PROYECTO .................................................................... 5 2.2.- 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 ....................................................... 9

2.3.- PERSPECTIVAS DE ACTIVIDAD E IMPLICACIÓN FUTURAS ................................................... 10

CAPÍTULO 3.- FASE DE PREPARACIÓN ................................................... 13

3.1.- LICENCIAMIENTO DEL PROYECTO .............................................................................. 13 Informe de recomendación de licencia ................................................................. 13

3.2.- ELEGIR UNA LICENCIA PARA EL SOFTWARE ................................................................. 14 3.3.- ELEGIR UNA LICENCIA PARA LA DOCUMENTACIÓN ........................................................ 17 3.4.- LICENCIAMIENTO DUAL .......................................................................................... 19 3.5.- ELABORACIÓN DEL DOCUMENTO DE GESTIÓN DE COMUNIDAD. ....................................... 20

CAPÍTULO 4.- FASE DE PUBLICACIÓN EN EL REPOSITORIO DE SOFTWARE LIBRE DE LA XUNTA DE GALICIA ....................................... 23

4.1.- CREACIÓN DEL PROYECTO EN EL REPOSITORIO DE SOFTWARE LIBRE DE LA XUNTA DE GALICIA ............................................................................................................................. 23 4.2.- ALTA DE USUARIOS DESARROLLADORES EN EL PROYECTO Y ASIGNACIÓN DE PERMISOS ............. 25 4.3.- PUBLICACIÓN DEL CÓDIGO EN EL SISTEMA DE CONTROL DE VERSIONES ESCOGIDO ................... 28 4.4.- PUBLICACIÓN DE DOCUMENTACIÓN ........................................................................... 28 4.5.- ELABORACIÓN Y PUBLICACIÓN DE PAQUETES DE INSTALACIÓN (OPCIONAL RECOMENDABLE) ...... 30

CAPÍTULO 5.- FASE DE LIBERACIÓN ....................................................... 33

5.1.- GESTIÓN DE LA COMUNIDAD ................................................................................... 33

1


CAPÍTULO 1.- INTRODUCCIÓN

Desde la concepción de la industria del software, usuarios y clientes han tenidoque aceptar alguna vez las restricciones y condiciones impuestas por aquellosque venden licencias de uso de sus programas. El software privativo no pue-de (por regla general) ser redistribuido, mejorado, adaptado a las necesida-des particulares o siquiera ser reparado por quien lo está usando cuando nofunciona 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 unasolución software es una entidad pública. Al no poder redistribuir el softwa-re que ha adquirido, no puede ponerlo a disposición de sus ciudadanos en unmomento determinado, no puede mejorarlo y adaptarlo para dar un mejor ser-vicio y, al no poder estudiar sus mecanismos internos, podría incluso estar su-friendo una gestión indebida de datos sin ni siquiera ser consciente de la posi-bilidad.

Llamamos software libre a aquellos programas informáticos que, a través deun modelo de gestión de la propiedad intelectual alternativo, aseguranpara sus usuarios las siguientes cuatro libertades1:

• 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 loscuales repercuten en beneficio de la ciudadanía2:

El software libre ahorra costes de licencias, cumple las directivas legalescomo la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos alos Servicios Públicos, favorece la transparencia y la interoperabilidad en-tre sistemas y facilita la adaptación en materia lingüística, legislativa o de ac-cesibilidad, entre otros motivos.

La industria y la economía también se benefician de que las entidades públicasliberen el software que han creado o adquirido. El tejido empresarial local seve reforzado por la apertura de mercado que supone la independencia a lahora de buscar proveedores de servicios de software. También se ponen a dis-posición de empresas conocimiento y tecnologías nuevos y se fomenta la co-operación entre universidades, empresas y centros de I+D.1 Adaptado de http://www.gnu.org/philosophy/free-sw.html 2 Más información en http://www.cenatic.es/index.php?option=com_content&view=article&id=33078

3

http://www.cenatic.es/index.php?option=com_content&view=article&id=33078

http://www.gnu.org/philosophy/free-sw.html


Por todo esto, el presente documento conforma una guía para el procedimien-to estandarizado de liberación de software para la Xunta de Galicia y en lossiguientes apartados se abordarán los métodos de actuación para las siguientesfases de dicho proceso:

• Fase de Identificación, durante la cual habrá de recogerse informacióncorrespondiente al proyecto, que ayude en las sucesivas tomas de deci-siones relativas al mismo.

• Fase de Preparación, en la que deberán tomarse la mayoría de las deci-siones relativas a licenciamiento, modelo de gestión de comunidad y ob-jetivos y motivaciones del proyecto.

• Fase de Publicación, durante la cual se llevará a cabo gran parte del tra-bajo técnico de puesta del software a disposición pública en repositoriosde código fuente, la creación de documentación, el empaquetado y en re-sumen lo que podríamos llamar la publicación de un producto software.

• Fase de Liberación, donde se perseguirá la autonomía del proyecto desoftware libre, sustentado en su propia comunidad con sus propios me-canismos.

4


CAPÍTULO 2.- FASE DE IDENTIFICACIÓN

Para llevar a cabo una transición a proyecto libre de un desarrollo existente opara crear una comunidad a partir de un proyecto que da comienzo práctica-mente desde cero, habrá que pasar por varias fases y tomar numerosas decisio-nes. Esta fase de identificación tiene por objeto recoger toda la informaciónprecisa sobre el proyecto, que ayude tanto en la toma de decisiones durante elproceso 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 po-damos, para poder facilitar el resto del proceso. Para llevar a cabo dicha tarease proporciona la siguiente ficha de identificación del proyecto. Una herra-mienta que servirá para categorizar el proyecto y adecuar el resto de las accio-nes hasta la liberación al caso particular que nos ocupe.

2.1.- Ficha de identificación del proyecto

Ficha de identificación de proyectoNombre del proyecto

Nombre completo del proyecto

Nombre en clave Si existe un acrónimo, abreviatura o identificador interno

Fecha de comienzo Si el proyecto está ya en marcha, indicar fecha de comienzo

Descripción 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

Estado Contratación, Diseño, Desarrollo, Producción

Contacto 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

Organismo ejecutante

Consejería, Subdirección, Departamento o entidad responsable del proyecto

• Nombre completo• Dirección de su sitio web• Persona de contacto

5


Colaboradores 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

Funcionalidad 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

Sitio web del proyecto

Direcciones en Internet del proyecto (incluir varias, si existeno 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

Lenguajes de programación y plataformas de desarrolloempleadas en el desarrollo del proyecto. Indicando cuandosea posible:

• Número de versión y sistema operativo• Dependencias de librerías• APIs o servicios web utilizados

Sistemas operativos Sistemas operativos en los que es posible desplegar lasolución. Indicando cuando sea posible:

• Arquitecturas• Números de versión

Estándares empleados

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

Requisitos Software Especificar requisitos software específicos para el desplieguede 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


Requisitos Hardware

Especificar requisitos hardware específicos para el desplieguede la solución. Indicando cuando sea posible:

• Requisitos mínimos• Requisitos recomendados

Tipología del desarrollo

Interno¿Desarrollo interno propio de la Xunta?

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á precisodefinir otra serie de aspectos importantes en el proceso de liberación, de mane-ra menos esquemática. Las secciones siguientes pretenden dar diferentes orien-taciones para la toma de decisiones temprana en dicho proceso.

2.2.- Eligiendo momento y estrategia de liberación

En esta sección nos detenemos para elegir un momento y una estrategia de li-beración adecuadas a nuestros objetivos y al proyecto en particular que este-mos tratando. Si dicho proyecto se encuentra ya en fase de producción se puedepasar al siguiente punto: 2.3. Perspectivas de desarrollo futuro del proyecto.

Resulta de mucha ayuda para la posterior toma de decisiones saber en este pun-to temprano del proceso cuál será nuestra estrategia de liberación. Tal vez lamás importante de las cuestiones a decidir es el momento de la liberación delproyecto. Para lo cual se presentan principalmente dos opciones:

A. Desarrollo del proyecto en abierto desde el inicio. Que consistiríaen realizar una liberación temprana del proyecto, buscando la máxi-ma implicación de la comunidad a costa, tal vez, de cierta perdida decontrol sobre el proyecto.

B. Liberación del proyecto ya en fase de producción. Que conllevaríamás trabajo interno para la entidad que lidera el proyecto, especial-mente en las fases de publicación. Pero a cambio permite un mayorcontrol sobre el proyecto.

De sarrollo 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


libre y el desarrollo en comunidades. El lema release early release often3 (liberapronto, libera a menudo), ha sido desde hace tiempo directiva principal paramuchos proyectos libres exitosos. Entre las ventajas de liberar temprano cabereseñar:

• Crear comunidad más fácilmente y asegurarse de que será más maduracuando 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 esexcitante y novedoso.

• Se estimula y agradece a los potenciales contribuidores de la comuni-dad 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 elsometimiento temprano y continuo del código a escrutinio público.

• El proyecto se beneficia de la innovación abierta y la aportación deideas provenientes de la comunidad, que podrían no haber surgido de ungrupo pequeño y dedicado.

El desarrollo en abierto desde el principio puede no resultar tan adecuadosi necesitamos tener un control estricto sobre el proyecto. Dado que la prin-cipal desventaja de este curso de acción es la cesión de protagonismo a una co-munidad de agentes externos, que aunque podría ser muy fuerte, sana y bienin-tencionada no tiene por qué perseguir nuestros mismos objetivos. Una situaciónasí 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 sistemasde desarrollo colaborativo que se utilicen (preferentemente el Reposito-rio de Software Libre de la Xunta de Galicia). Tanto para forjas, comopara repositorios de código.

• También habrá que definir políticas de usuarios para wikis de docu-mentación, listas de correo y otros canales de comunicación.

• Definir una política de aceptación de cambios en la rama principaldel código en el sistema de control de versiones, que podrá incluir o noun proceso de revisión por parte de la Xunta o la entidad responsabledel área técnica correspondiente.

• Habrá que decidir si los colaboradores externos, como por ejemplo

3 Popularizado por Eric S. Raymond en http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

8

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/


empresas contratadas por la Xunta, tendrán permisos para modificarel código a discreción según tengan nuevas aportaciones o si enviaránsus cambios por lotes.

• Resultará especialmente sensible en este modelo de liberación tempra-na la correcta y atenta gestión de la comunidad. Asuntos que podránestudiarse en mayor profundidad en las secciones 3.2. Elaboración delDocumento 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 yaen fase de producción. Bien porque se quiere mantener un control estricto deldesarrollo o bien porque tratemos de liberar un proyecto que originalmentefuera software privativo. Las ventajas de este modelo son las siguientes:

• Se evita un posible fork del proyecto en fase de desarrollo. Un fork esuna división de opiniones técnicas o personales que genera la creaciónde una versión alternativa del proyecto. A menudo los fork son conside-rados dañinos para los proyectos.

• Resulta mucho más fácil controlar la consecución de objetivos delproyecto y mantener el foco sobre los intereses principales. Al elimi-nar el elemento de deriva que introduce la innovación abierta.

• Resulta más fácil controlar los tiempos del proyecto al no ser neces-ario invertir tiempo y recursos en la gestión de la comunidad, aunquecomo contrapartida el desarrollo dependerá exclusivamente de los re-cursos internos.

• La imagen del proyecto y su percepción externa es controlable a tra-vés de métodos tradicionales de marketing y recae principalmente en losactores internos.

• Existe una ventaja competitiva de explotación comercial a través deconsultoría o servicios de formación o adaptación, para los participan-tes internos sobre aquellos que adoptarán el proyecto más tarde, en suliberación.

Esta última ventaja podría convertirse en una potencial merma de imparciali-dad en el caso de que se espere que sean varias las empresas que exploten elproyecto y algunas de ellas no hubieran participado en el desarrollo desde el co-mienzo. Sin duda tendrían ventaja, en forma de un mayor conocimiento, aque-llas que hubieran estado en él desde el principio.

Otra desventaja de este modelo de liberación reside en la mayor disposiciónde recursos que se requiere por parte de los ejecutantes, al no haber aporta-ción de la comunidad durante el desarrollo. Esto nos lleva a la mayor desventa-

9


ja; la creación de una comunidad a posteriori, cuando el proyecto ya está ma-duro, será mucho más difícil. La percepción que tengan del proyecto los po-tenciales contribuidores será menos motivadora y excitante que la de aquellosproyectos 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 encuenta los siguientes puntos en nuestro curso de acción:

• Elegir una licencia atractiva para la comunidad. Crear comunidadserá el reto más complejo de un proyecto liberado en fase de produccióny elegir una licencia oscura, poco conocida o con mala reputación podríaser un lastre importante para este objetivo.

• Definir con especial cuidado la documentación tanto de usuariocomo para desarrolladores. Habrá que facilitar la entrada de agentesexternos a un proyecto que ya está maduro. Si no van a poder hacer lascosas a su manera, al menos habrá de estar claro cuál es la manera ade-cuada de hacerlas.

• Hacer buena publicidad del proyecto y mantener canales de comuni-cación abiertos y claros. Establecer un buen canal de noticias, anunciarlos bugs y los avances con regularidad y mantenerse atento para respon-der adecuadamente a sugerencias y ofertas de colaboración.

2.3.- Perspectivas de actividad e implicación futuras

Con el objeto de decidir el nivel de implicación y recursos que habrán de de-dicarse al proyecto en el futuro, tendremos que tener claros algunos puntos du-rante la fase de identificación. Principalmente deberíamos sopesar aquellas cir-cunstancias que nos indiquen la importancia del proyecto para nuestros intere-ses, tales como si resulta una dependencia importante para otros proyectos in-teresantes, si es un proyecto que proporciona una buena imagen o si se esperaque la comunidad crezca rápido.

El siguiente cuestionario comentado sitúa el foco en algunas de los principalesaspectos a tener en cuenta a la hora de decidir la dedicación e implicación segúnnuestros intereses:

• ¿Tenemos recursos humanos y económicos que dedicar al proyecto? Aveces la escasez de recursos o incapacidad de actuación en un determina-do momento puede hacer que descuidemos el proyecto. Pero hay muchascosas que se pueden hacer por un proyecto que no cuestan mucho dineroy que no llevan demasiado tiempo, como por ejemplo hacer difusión delmismo 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


to una vez esté liberado o preferimos ser usuarios u observadores? Puederesultar que todo lo que necesitamos de un proyecto sea cubierto por sucomunidad. En ese caso podríamos decidir no implicarnos más allá de serusuarios.

• ¿Queremos ofrecer servicios de informe de fallos, canales de comunica-ción, página web y otras infraestructuras? A menudo las infraestructu-ras están presentes para otros proyectos. Deberíamos decidir si vamos aquerer mantenerlas, si vamos a solucionar los errores que se reporten ysi vamos a frecuentar los canales de chat, por ejemplo.

• ¿Queremos participar activamente en el desarrollo? Habrá que decidir sivamos a invertir tiempo de desarrolladores en el proyecto, si merece lapena y si necesitamos ese tipo de control.

• ¿Necesitamos establecer un control sobre los objetivos y la evolucióndel proyecto? Si es así, habremos de considerar el pertenecer a su comu-nidad de manera activa y mantener una buena comunicación con el restode participantes.

Según el tipo de respuestas que queramos dar a este conjunto de preguntas, po-dremos situarnos principalmente en cuatro posturas respecto del proyecto unavez liberado, de menor a mayor implicación, serían:

• Desvincularse y no participar en la comunidad, de manera que unavez liberado el proyecto, si no nos interesa o no podemos permitirnos elesfuerzo que conlleva, lo abandonemos independientemente de queotros actores intervengan o no. En este caso sería suficiente con publicarel proyecto siguiendo los pasos descritos en el apartado 4.Fase de publi-cación en el Repositorio de Software Libre de la Xunta de Galicia.

• Participar en la comunidad de manera pasiva. Consistiría en un modode colaboración de baja actividad, pero presencia notable. Una buena po-sibilidad es mantener vigilancia en los foros del proyecto, ofreciendo res-puestas a las dudas de los agentes externos que se interesen en el pro-yecto o publicando nueva documentación que se vaya elaborando duran-te el uso del proyecto, … Esta actividad no supone una dedicación excesi-va mientras que el valor añadido y la visibilidad que ofrece el ser el en-cargado de las infraestructuras de un proyecto son muy grandes.

• Participar activamente en la comunidad. Por supuesto, además detodo lo anterior, participar activamente en la comunidad aunque sea sinaportar mucho código, es una manera de elevar el grado de implicación.Existen muchas tareas accesorias al desarrollo que son muy valiosas parael proyecto y que pueden dar mucha visibilidad y otorgar méritos a nues-tra 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


eventos, la promoción del proyecto y la productización en general.

• Participar activamente en el desarrollo. Idealmente, siempre que casecon nuestros intereses y los recursos disponibles lo permitan, la relaciónperfecta con un proyecto es participar de manera sustancial en el desa-rrollo del código. Esto nos dará máxima visibilidad y control tanto en as-pectos técnicos como en la dirección del proyecto y sus objetivos.

Otro aspecto importante que conviene definir en esta fase (sobre el que seampliará información en el capítulo 3.2. Elaboración del Documento de Gestiónde Comunidad) es el modelo de comunidad que queremos implantar. Porqueaunque no existe una categorización comúnmente extendida para clasificar lasdiferentes comunidades, sí se puede hacer una diferenciación importanteajustando roles y características de la comunidad, tales como el control quese ejerce sobre el proyecto, las barreras de entrada que se establecen, los proce-sos internos o las infraestructuras y herramientas.

Una vez hemos concluido la identificación del proyecto y tenemos clara la es-trategia de liberación y el tipo de implicación que planeamos tener a lo largodel la vida del proyecto, pasaremos a la Fase de Preparación.

12


CAPÍTULO 3.- FASE DE PREPARACIÓN

3.1.- Licenciamiento del proyecto

La diferencia fundamental entre el software libre y el resto del software es lalicencia, que en el caso del software libre permite una gestión alternativa de lapropiedad intelectual. Una de las principales decisiones que habremos de to-mar a la hora de liberar un proyecto de software libre es sin duda la licenciaque le queremos dar al código, dado que las diferencias entre las licencias im-plican condiciones de uso y redistribución totalmente diferentes.

En términos sencillos se puede pensar en la licencia como un contrato unilate-ral 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 de-cir, las condiciones y restricciones impuestas por las licencias sólo puedenser definidas por los propietarios de los derechos del software. Un aspectoimportante a destacar es que la propiedad intelectual seguirá siendo suyapuesto que la licencia no conlleva la trasmisión de los derechos. Tan solo segarantizan derechos de uso y en algunos casos de distribución.

También conviene recordar que cada nueva versión de un programa es con-siderada una nueva obra. Esto significa que el dueño de los derechos puedeelegir distribuir cada nueva versión de su programa bajo una licencia diferentecada vez, si así lo desea.

Una licencia de software es una licencia libre si cumple con las cuatro liberta-des del software libre que se detallaron en el capítulo 1. Introducción. Según laFree Software Foundation y la Open Source Initiative, no son licencias libresaquellas que pretenden evitar usos determinados del software (por ejem-plo, impidiendo su uso militar o comercial o restringiendo su uso exclusiva-mente para entornos educativos) ni las que impiden la creación de obrasderivadas.

Informe de recomendación de licencia

Antes de proceder a realizar el licenciamiento del proyecto deberá realizarseuna consulta técnico-legal a la Oficina de Coordinación de Software Libre dela Xunta de Galicia para que pueda analizar las posibles dependencias softwaredel proyecto y sus correspondientes licencias para detectar posibles incompa-tibilidades de cara a elaborar un informe de recomendación de licencia parti-cular.

La Oficina de Coordinación de Software Libre contará para esta tarea con el

13


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 dispo-ner de esta documentación completa la Oficina proporcionará un Docu-mento de cesión de derechos que deberán firmar todas las empresas o terce-ras partes involucradas en el desarrollo para garantizar que la Xunta deGalicia 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 so-ftware y licencias para la documentación que lo acompaña, ya que tanto la li-cencia como la manera de incluirla difiere en ambos casos. También hablaremosde cómo elegirlas y repasaremos algunos conceptos generales, como el licencia-miento dual.

3.2.- Elegir una licencia para el software

Aunque la Comisión Europea recomienda emplear la licencia EUPL4 para los de-sarrollos de las administraciones públicas, será preciso evaluar cada caso parti-cular para analizar la conveniencia o necesidad de escoger esta u otra licencia oincluso realizar un licenciamiento dual.

En cualquier caso debemos evitar siempre la creación de una nueva licencia pordos razones fundamentales:

• Familiaridad. Si usamos una licencia bastante popular, los potencialescontribuidores al proyecto sentirán que conocen las bases del trato quese les propone.

• Calidad. Resulta muy complicado elaborar una licencia nueva que seasó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 esco-ger. La mayoría no tendremos por qué considerarlas ya que fueron elaboradaspara satisfacer necesidades legales particulares de proyectos concretos. De ma-nera que lo ideal sería escoger entre las licencias más utilizadas puesto quees muy probable que alguna se ajuste a nuestras necesidades.

Para tener en cuenta todos los factores que entran en juego al escoger una licen-cia, hemos de hacernos las siguientes preguntas:

4http://www.osor.yo/eupl/european-union-public-licence-eupl-v.1.1

14


• ¿Queremos que la gente sea capaz de hacer sus modificaciones priva-das? Si queremos que los cambios que otros hagan al código sean hechospúblicos al redistribuirlo, habremos de escoger una licencia que así lo or-dene. Como por ejemplo la GPL o la LGPL. Si no nos importa, podríamosusar una licencia que no lo requiera, como la Apache 2.0.

• ¿Queremos que nuestro programa se pueda mezclar con software pro-pietario? Si es así, podríamos querer usar la LGPL que permite explícita-mente mezclar el software privativo con el software LGPL si este últimono se modifica. También podríamos usar las licencias estilo BSD como laApache 2.0 que permiten que las modificaciones que hagamos a proyec-tos bajo ellas pasen a ser software privativo.

• ¿Queremos que algunas personas puedan comprar versiones con licen-cias propietarias del software? Entonces lo ideal sería establecer un li-cenciamiento dual, por ejemplo usando la GPL como licencia libre y ade-más una licencia privativa que se aplicará a una versión diferente del so-ftware.

• ¿Es importante para nosotros el modelo de negocio para la explotacióndel proyecto? Esta pregunta también puede influir en nuestra decisión ala hora de escoger una licencia puesto que diferentes modelos de negociopueden requerir o recomendar diferentes licencias.

• ¿Planeamos integrar software de diferentes fuentes? Si la respuesta essí, habremos de prestar mucha atención a las compatibilidades e incom-patibilidades entre licencias. Especialmente respecto de la GPL, debido asu importancia y difusión.

La siguiente tabla presenta algunas de las licencias de software libre más popu-lares y algunas de sus características:

Licencias populares de software libre

Licencia Enlazado consoftware

propietario

Distribucióndel trabajo

original

Redistribucióndel códigomodificado

Compatiblecon la GPL

BerkeleySoftwareDistributionLicense (BSD)

Permitido. Permitido. Permitido. Sí.

ApacheLicense 2.0

Permitido. Permitido. Permitido. Solo con laGPLv3.

MozillaPublicLicense (MPL)

Permitido. Permitido. Solo bajo la MPLde nuevo.

No.

15


Licencias populares de software libre

Lesser GNUPublicLicense(LGPL)

Permitido.Permitido con

algunasrestricciones.

Solo bajo LGPL oGPL. Sí.

Affero GPLLicense

No permitido. Permitido. Permitido. Con laGPLv3.

GNU PublicLicense (GPL)

No permitido.

No permitidocon softwarecuya licencia

no escompatible

con GPL.

Solo bajo la GPL. Sí.

Una vez escogida la licencia idónea, el procedimiento a seguir para su correctaaplicación al proyecto puede variar según la licencia y el tipo de proyecto, peroen líneas generales es el siguiente:

1. Conviene publicar en la página web del proyecto cuál es la licencia quehemos 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 elcódigo fuente del programa. Esto se hace adjuntando una copia de tex-to íntegro de la licencia en un fichero junto con la distribución. Ge-neralmente en un fichero llamado COPYING.

3. También debemos incluir en cada fichero de código fuente una nota delcopyright y una autorización de copia, estableciendo que el programase distribuye bajo la licencia correspondiente.

◦ La nota de copyright se incluirá, como decimos, en cada uno de los fi-cheros fuentes. Deberá indicar el año y el dueño del copyright. Algocon este formato resulta adecuado: Copyright 2012 Xunta de Galicia. Seutiliza la palabra copyright por convención internacional, inclusopara materiales que están en idiomas diferentes al inglés.

◦ La autorización de copia se incluirá en cada uno de los ficheros fuen-tes y establece, con palabras sencillas, cuál es la licencia bajo lacual se distribuye el programa y dónde se puede leer el texto ín-tegro de la misma.

De este modo, además de mantener el texto íntegro de la licencia en un ficherollamado COPYING, para licenciar bajo la GPL nuestro software, incluiríamos encada fichero el siguiente encabezado:

16


Copyright (C) 2012 Xunta de Galicia

This program is free software: you can redistribute it and/ormodify 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. Ifnot, see <http://www.gnu.org/licenses/>

No es necesario que nuestro encabezado sea exactamente igual que este ejem-plo, solo tendremos que asegurarnos de que incluye la nota del copyright, quedeja bien claro cuál es la licencia que estamos usando y dónde podemos encon-trar el texto íntegro de la misma.

3.3.- 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 obrasliterarias. Muchas de ellas han evolucionado a partir de las licencias para ladocumentación que se han venido utilizando en proyectos de software libre.

En la situación actual, cabe destacar por su popularidad, dos principales tenden-cias 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 CreativeCommons, un completo marco jurídico mediante el cual confeccionar diferen-tes licencias para obras diversas.

La GNU Free Documentation License (GFDL) es la licencia promovida por laFree Software Foundation para contenidos libres. En un principio fue diseñadapara manuales, libros de texto y otras obras funcionales, entendiendo por obrasfuncionales aquellas que nos ayudan a llevar a cabo un trabajo, como los manua-les, las guías y la documentación del software. Se definen las obras no funciona-les 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 redis-tribuido manteniendo los términos de la licencia y especifica algunos detalles dela redistribución, como la obligación de proporcionar un formato transparentesi 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


que no permite ofuscar las copias (ni las privadas, incluyendo el cifrado), algoque resulta muy poco práctico en algunas situaciones. Además, está demasiadoorientada a la impresión y se requiere imprimir una copia de la licencia juntocon la obra (o parte de ella) cuando esta se imprime.

Por todo esto, en términos generales se recomiendan las licencias Creative Co-mmons para la documentación que acompaña al software, que permiten aplicarel concepto de licencia libre fuera del software de manera generalizada.

Creative Commons es una organización con el objetivo de crear un conjunto delicencias que sirvan para cualquier tipo de contenidos, crear un catálogo deobras licenciadas bajo Creative Commons y adaptar internacionalmente el mar-co completo. Las licencias Creative Commons son muy populares y están muyextendidas por su sencillez.

Las licencias Creative Commons se presentan en tres capas, para facilitar su usoy comprensión:

• Commons deed: es el resumen del texto legal simplificado, indicado parano-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 apli-caciones

Las licencias Creative Commons se basan en combinar distintas cláusulas:

• Reconocimiento (attribution -by): obliga a citar las fuentes y dar créditoal autor

• No comercial (non-commercial -nc): no permite usos comerciales

• Sin obra derivada (no derivatives -nd): obliga a la no alteración de laobra

• Compartir igual (share-alike -sa): obliga a distribuir las obras derivadasbajo la misma licencia que el trabajo original, implementando así el con-cepto de copyleft en el marco de Creative Commons.

Las diferentes combinaciones posibles dan lugar a las 6 posibles licencias, cono-cidas 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


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 compatiblescon las cuatro libertades del software libre. Así que no deberían ser considera-das como licencias libres según la definición de la Free Software Foundation.

Por regla general, si queremos que nuestra documentación sea redistribuidabajo una licencia libre, es posible que nuestra mejor opción sea la licencia Re-conocimiento + Compartir Igual (by-sa) y esa es nuestra recomendación.

El procedimiento a seguir para incluir la licencia en la documentación queacompaña al software es muy sencillo. Basta con incluir al comienzo de laobra una nota que indique cual es la licencia que hemos escogido y dóndese puede encontrar el texto completo de la misma, por ejemplo:

Esta obra está bajo una licencia Atribución-CompartirIgual3.0 España de Creative Commons. Para ver una copia de la li-cencia, visite:


Otras versiones de la misma nota incluyen a veces la dirección física de la sedede Creative Commons para solicitar una copia del texto de la licencia, aunqueesto es ya algo opcional:

Este trabajo está publicado bajo una licencia Creative Com-mons Atribución-Compartirigual 3.0. Para ver una copia de lalicencia visite:

http://creativecommons.org/licenses/by-sa/3.0/

O envíe una carta a:

Creative Commons, 444 Castro Street, Suite 900,

Mountain View, California, 94041, USA.

3.4.- Licenciamiento dual

Un esquema de licenciamiento dual consiste en distribuir dos (o más) versionesdiferentes de un producto de software bajo diferentes licencias. Las versionesdel programa pueden ser casi iguales, siendo la licencia la única diferencia sus-tancial.

El licenciamiento dual es un intento de conciliar los intereses enfrentados deldesarrollo de software libre, devoto de las licencias libres clásicas, y la explota-ción comercial. Muchos proveedores de software libre han adoptado alguna for-ma de licenciamiento dual por razones como las siguientes:

• Para conseguir una mayor compatibilidad del código. Sirva de ejem-plo el proceso de relicenciamiento por el que pasó hace poco el proyectoMozilla. De liberar su código bajo la MPL (Mozilla Public License) pasó a

19

http://creativecommons.org/licenses/by-sa/3.0/



hacerlo bajo un sistema de licenciamiento triple MPL/GPL/LGPL, paraasegurarse 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 versio-nes de su producto principal: una libre en la que aceptaban contribucio-nes externas y colaboraciones y una propietaria que incluía mejoras yadaptaciones que no se implementaban en la versión libre.

• Para otorgar diferentes permisos según quién sea el receptor. A ve-ces resulta útil utilizar un sistema de licenciamiento múltiple para defi-nir diferentes condiciones de uso según el receptor del software. Porejemplo, para ofrecer adaptaciones, adelantos del desarrollo principal opara garantizar derechos extra a terceros.

3.5.- Elaboración del Documento de Gestión de Comunidad.

Un aspecto clave para obtener los beneficios de la liberación de software es uncorrecto modelo de gestión de la comunidad en el que desde la administraciónpública se promueva la participación de las propias empresas TIC locales y lascomunidades de desarrollo, de manera que se garantice la sostenibilidad del so-ftware liberado. Es decir deberá establecerse cuales serán las normas de gestióny participación en la comunidad que se dedicará a mantener y mejorar el pro-yecto en el tiempo, con el objetivo de que pueda llegar a ser un proyecto libreautónomo.

Existen tantos modelos de gestión de comunidad como proyectos de software li-bre, pero en líneas generales podemos distinguir dos modelos opuestos:

• Dictador benevolente, en el que el control del proyecto está centraliza-do en un único individuo u organización. Los fundadores del proyectodeterminan la dirección del proyecto tomando las decisiones finalescuando la comunidad está en desacuerdo.

• Meritocracia, en el que el control del proyecto se encuentra distribuidoentre los miembros de la comunidad en base al reconocimiento de losméritos de cada uno.

Es posible encontrar modelos de gestión en cualquier punto dentro del espectrodeterminado por estos dos modelos. Por supuesto también es posible que el mo-delo de gestión de un proyecto evolucione con el tiempo, comenzando por ejem-plo con un modelo de dictador benevolente puro que a medida que la comuni-dad y el proyecto van creciendo y madurando evoluciona hacia un modelo másmeritocrático.

A la hora de definir el modelo de gestión de la comunidad será conveniente te-

20


ner presentes las reflexiones realizadas previamente en el apartado 2.3.-Pers pectivas de actividad e implicación futuras sobre cual va a ser el papel de laadministració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 unDocumento de gestión o plan de comunidad cuales serán las reglas de juego de la co-munidad que va a mantener el proyecto.

Para conseguir una comunidad fuerte es fundamental que los futuros miembrospuedan conocer en todo momento de que forma pueden contribuir a mejorar elproyecto, en que áreas pueden colaborar, que condiciones se deben cumplirpara que sus contribuciones sean aceptadas, cual es la política o las reglas parala toma de decisiones dentro del proyecto, cuales son los canales de comunica-ción principales … Estos y otros aspectos deberán incluirse en el Documento degestió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 documen-to. Además se incluirá en este apartado la licencia del proyecto y quienes el titular de los derechos. El objetivo es ofrecer a la gente una rápidavisión global de qué tipo de proyecto es y qué se espera de ellos si sequieren unir a el.

• Estructura de la comunidad. Esta sección describirá los equipos, los ro-les y el reparto de responsabilidades, que dependerán del modelo de ges-tión escogido. Incluirá también el nivel de compromiso necesario paraobtener cada rol. Se deberá definir lo más claramente posible quien ges-tiona el proyecto, quien y como puede contribuir y que pasos es neces-ario seguir para llegar a poder influir directamente en el futuro del pro-yecto.

• Procedimiento de toma de decisiones. Es importante establecer unproceso de toma de decisiones claro, transparente y eficaz. Si el procesoes tedioso y complejo, es posible que las decisiones se prolonguen dema-siado, afectando a los tiempos y plazos de desarrollo. Si el proceso no esclaro y está poco definido, es posible que las decisiones sean cuestiona-das constantemente por los miembros de la comunidad creando malestary conflictos.

• Procedimientos de trabajo. (política de contribuciones, política de ver-sionado, …) En esta sección se definirán la política de contribuciones yla política de versionado. La primera documentará cómo se puede con-tribuir al proyecto y a través de que herramientas. Deberá incluirse tam-bién como se va gestionar el copyright de las contribuciones, que están-dares de codificación y documentación se van a emplear. Finalmente sedebe describir el proceso de aprobación de las contribuciones de tercerosasí como qué ocurre con aquellas que no se consideren adecuadas para el

21


proyecto. El objetivo final de esta política es asegurar que el control decalidad y control legal de todas las contribuciones es adecuado para con-seguir un producto atractivo y funcional para los usuarios finales. La po-lítica de versionado definirá la periodicidad de las versiones así comoquien decidirá el momento de publicación...

• Infraestructura de la comunidad. En esta sección se indicará cualesson las herramientas de desarrollo, soporte, difusión, comunicación ... delas que dispondrá la comunidad.

A la hora de elaborar este documento es necesario tener presente que ha de serun documento vivo que deberá contener las normas iniciales mínimas para quela comunidad pueda funcionar pero que podrá completarse y modificarse en eltiempo por la propia comunidad.

22


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 quepermiten su liberación, escogida la licencia de distribución para el software ypara 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 deSoftware Libre de la Xunta de Galicia.

En los apartados siguiente iremos describiendo cuales son los pasos necesariospara realizar esta publicación correctamente.

4.1.- Creación del proyecto en el Repositorio de Software Libre de la Xunta deGalicia

Para crear un proyecto en el Repositorio de Software Libre de la Xunta de Gali-cia (http://forxa.mancomun.org) es necesario tener previamente un usuarioregistrado en dicho servicio, que será el administrador del proyecto.

Para crear un usuario se accede al formulario de alta desde la opción Contanova, 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 obli-gatorios: Nombre de la cuenta de usuario, contraseña, nombre y apellidos delusuario y correo electrónico.

Lo más recomendable es que se cree una cuenta de usuario genérica para el de-partamento de la Xunta responsable del proyecto, asociada a una cuenta de co-rreo electrónico también genérica. Es preferible esta opción frente al uso deuna cuenta personal para evitar pérdida de acceso al proyecto motivadas portraslados del personal entre departamentos.

Una vez registrado el usuario, este accederá al sistema para crear el proyectopara lo que deberá seleccionar la opción Registrar un nuevo proyecto y cu-brir un formulario como el siguiente:

23

https://forxa.mancomun.org/register/

http://forxa.mancomun.org/


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 ycomprensibles. Todos los campos son necesarios.

1. Nombre completo del proyecto

Debería comenzar especificando el nombre del proyecto. El "nombre comple-to" es descriptivo, y no tiene ninguna restricción arbitraria (exceptuando unlí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 yque recursos de A Forxa piensa utilizar. Esta descripción es básica para apro-bar o rechazar el alojamiento de su proyecto en A Forxa, y después, para ha-bilitar el uso de los servicios solicitados. Esta descripción no se utiliza comodescripció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 Sumariodel Proyecto, en resultados de búsquedas, etc. La longitud máxima son 255 ca-racteres.

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érminosde su licencia. Emplear otra licencia generalmente no se aprueba. Esto requie-re tiempo adicional para tomar una decisión sobre su proyecto ya que es ne-cesario comprobar si la licencia es compatible con la definición de CódigoAbierto.

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 mu-chos 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


6. SCM

Debe elegir un único sistema entre los diferentes SCM para su proyecto. Debeelegir 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 Con-trol de Versiones no podrá modificarse a posteriori, esto se refiere que no sepuede hacer un cambio automático. Sí es posible cambiar de SVN a GIT (o vice-versa) para un determinado proyecto. El cambio implica que el repositorio anti-guo se desactiva para crear el nuevo. Por esta razón si ya contiene código y noqueremos perderlo será imprescindible descargar primero una copia del mismoal equipo local y realizar la migración de SVN a GIT en local y después volver asubirlo a la Forxa una vez creado el nuevo repositorio.

Una vez completado el proceso de alta del proyecto, este será validado por losadministradores del Repositorio de Software Libre de la Xunta de Galicia que enun breve plazo aprobarán el proyecto si no detectan ningún problema, recibien-do un aviso en el correo electrónico el usuario que lo ha creado. En un par dehoras desde la aprobación estarán funcionando todos los servicios para dichoproyecto.

4.2.- 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ónde roles y permisos adecuados a los distintos usuarios que hayan sido aprobadospara colaborar en el proyecto.

Esto se realiza desde la sección Admin – Usuarios del proyecto desde una páginacomo la siguiente:

25


En la sección Add User se añade el identificador del usuario y posteriormente sele asigna en la sección Project Members el rol adecuado, que incluya los permisosde 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 pre-definidos en los proyectos son admin, doc writer, junior developer, senior developer ysupport tech. Cada uno de ellos otorga distintos permisos o privilegios para cadauna de las secciones o herramientas de gestión del proyecto: foros, registro deincidencias, documentación, sistema de control de versiones … como se puedever en los ejemplos de las siguientes figuras que muestran la edición del rol Su-pport Tech. y Junior Developer.

26


Los permisos que se puede otorgar varían en función de la sección, que resumi-mos 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 puedecrear tareas asociadas a la incidencia. No puede configurar el gestorde incidencias creando por ejemplo nuevos campos.

◦ Técnicos: tendrá los permisos completos para gestionar y resolver in-cidencias. Así puede leer las incidencias, puede ser asignado a las in-cidencias, puede crear tareas asociadas a las incidencias. Puede modi-

27


ficar los valores de los campos personalizados, no el resto. No puedeborrar ni asignar tickets. No puede configurar el gestor de inciden-cias.

◦ Sólo administración: tendrá los permisos necesarios para asignar in-cidencias y configurar el gestor. Puede crear tareas asociadas a las in-cidencias, puede cambiar todos los campos de una incidencia, borrary asignar incidencias. Puede enviar una incidencia a otro gestor den-tro del mismo proyecto, puede administrar completamente el gestorde incidencias.

◦ Técnicos / administración: Tiene los privilegios técnicos y de admi-nistració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 rolesque se hayan definido en el Documento de Gestión de Comunidad en el apartadode Estructura de la Comunidad.

4.3.- 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 sistemade control de versiones escogido, git o svn.

Por supuesto, para realizar este paso previamente se habrá obtenido el Informede recomendación de licencia y se habrá incluido ésta correctamente en el códi-go según lo descrito en el apartado Elegir una licencia para el software.

4.4.- Publicación de documentación

Para la publicación de la documentación disponemos de diversas opciones. Laprimera de ellas es la más simple y consiste en publicar en la sección Documentosdel 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 seconsidere de interés para nuevos desarrolladores …

28


Para ello se accede a la sección Documentos de nuestro proyecto y se escoge Pu-blicar nuevos documentos.

Si la documentación es extensa, es recomendable organizar los documentos encarpetas, lo que se denomina Grupos de documentos. Estos grupos puedencrearse desde la opción Add/Edit/Delete Document Groups dentro del apartadode Administración de esta sección.

Una vez creada la estructura de carpetas y subidos los fichero se vería algocomo lo de la siguiente figura.

Otra opción que disponemos para la publicación de la documentación es hacerlomediante la herramienta wiki que nos ofrece la forxa para cada proyecto.

29


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 liberarun proyecto propiedad de la Xunta de Galicia es ofrecer a la ciudadanía o a lasempresas productos útiles y de interés sobre los que estas últimas pueden gene-rar 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 pa-quetes de instalación (.deb, .rpm, .exe …) que faciliten el uso y prueba del pro-ducto. También es recomendable facilitar la descarga del código de la versiónestable, por ejemplo en tar.gz, para evitar que sea necesario acceder al sistemade control de versiones, que es una herramienta menos amigable de cara alusuario final.

La siguiente figura muestra un ejemplo de un proyecto con descargas disponi-bles. Existen dos paquetes de liberaciones (corpus y corpus-xmlrpc) que permitenagrupar distintas descargas relacionadas.

La publicación de ficheros se realiza desde la sección Ficheros, Administración.

30


Antes de poder subir un fichero es necesario crear primeramente un paquete deliberaciones.

Una vez creado ya podremos publicar uno o más ficheros en el.

31


CAPÍTULO 5.- FASE DE LIBERACIÓN

Finalmente llegamos a la última y más importante fase de todo el proceso, lafase de liberación de software.

Si bien siguiendo todos los pasos descritos en el capítulo 4. Publicación en elRepositorio de Software Libre de la Xunta de Galicia , nuestro proyecto ya hasido puesto a disposición de la comunidad con una licencia libre, entendemosque esto no es suficiente para considerar que se ha liberado el proyecto. El as-pecto diferencial será conseguir crear una comunidad en torno a él involucra-da en su uso, mantenimiento y evolución, en la que se puedan unir los intere-ses de la administración pública, empresas TIC, usuarios finales ...

Recogiendo las ideas expuestas por CENATIC en su decálogo para que la admi-nistración pública libere su software5 entendemos que “para alcanzar los benefi-cios de la liberación de software no es suficiente con su publicación web, sino que esnecesario un correcto modelo de explotación y comunidad que, promovido por las pro-pias administraciones públicas y con la imprescindible participación del tejido empre-sarial TIC local y las comunidades de desarrollo, garantice la sostenibilidad del softwa-re liberado a través de la transferencia de conocimiento y la correcta gestión de contri-buciones.”

Por esta razón en el siguiente apartado nos centraremos en describir buenasprácticas orientadas a facilitar la creación de comunidad así como algunos sig-nos o indicadores a los que prestar atención ya que son indicativos de que lascosas no están yendo bien. Estos indicadores son conocidos como anti-patro-nes.

5.1.- Gestión de la comunidad

Existen una serie de buenas prácticas que se recomienda seguir si queremosllegar a tener una comunidad de desarrolladores alrededor de nuestro proyec-to:

• Compartir con la comunidad el control del código del proyecto . Unaspecto importante que ya hemos destacado en el apartado de elabora-ción del documento de gestión de la comunidad, es el control sobre elcódigo de nuestro proyecto. Nuestros potenciales colaboradores tienenmultitud de proyectos libres en los que poder colaborar, y suelen ten-der hacia aquellos en los que es posible la colaboración de pleno dere-cho. Si bien existen múltiples razones y situaciones que pueden aconse-jar mantener el control total sobre qué código será incorporado al nú-

5 http://www.cenatic.es/hemeroteca-de-cenatic/1-actualidad-cenatic/33079-10-razones-para-que-la-administracion-libere-software

33

http://www.cenatic.es/hemeroteca-de-cenatic/1-actualidad-cenatic/33079-10-razones-para-que-la-administracion-libere-software

http://www.cenatic.es/hemeroteca-de-cenatic/1-actualidad-cenatic/33079-10-razones-para-que-la-administracion-libere-software


cleo de nuestro proyecto, si somos demasiado rigurosos en este aspectocorremos el riesgo de perder el interés de la comunidad.

Así, en caso de aplicar un modelo de dictador benevolente, se recomien-da evitar siempre que sea posible, imponer la obligación de cedernos losderechos de autor de todas las contribuciones, o que los únicos autoriza-dos a realizar commits en el repositorio de código sea nuestro propiopersonal.

Si estas situaciones son imprescindibles, siempre podremos fomentar eldesarrollo de otros tipos de comunidad, como por ejemplo de desarrolla-dores de módulos extra para el núcleo del proyecto, de implantadores ointegradores de nuestro producto...

• Minimizar las barreras de entrada. Hay que tratar de minimizar lomáximo posible o eliminar las barreras de entrada en la comunidad. Porejemplo, utilizando herramientas de colaboración conocidas y fáciles deusar. En nuestro caso, las herramientas que proporciona el Repositoriode Software Libre de la Xunta son de uso extendido en las comunida-des de software libre por lo que no deberían suponer una barrera. Sinembargo, aún así debemos prestar especial atención a su configuraciónpermitiendo por ejemplo el acceso anónimo de lectura al código fuente,que los errores puedan ser remitidos de forma anónima sin necesidad dedarse de alta en la forxa... También se considera una importante barrerade entrada la necesidad de firmar un documento de cesión de derechosde autor antes de poder contribuir al proyecto.

• Simplificar los procesos de gestión de la comunidad manteniendo sueficaces. Además de establecer claramente los distintos roles de colabo-ración y las condiciones para poder optar a cada uno de ellos, se debeprestar atención a que estos procesos sean justos y se apliquen en todomomento.

Es conveniente también conseguir que algunos miembros de la comuni-dad obtengan lo antes posible permisos para por ejemplo ser moderadorde errores, para resolver tareas, para acceder al repositorio de código, …Cuanto antes se involucre personal externo, mayor probabilidad tendre-mos de que se genere comunidad y de obtener todos los beneficios queesto reportará a nuestro proyecto.

• Dedicar recursos específicamente a la gestión de la comunidad. Si es po-sible, lo ideal es contar con un Community Manager, que pueda dedi-carse total o parcialmente a realizar las tareas de gestión y dinamizaciónde la comunidad.

• Publicar un roadmap del proyecto y cumplirlo, para que la comunidadpueda conocer hacia donde se dirige el mismo y valorar en que sentido

34


puede colaborar.

Todas estas recomendaciones o buenas prácticas deben aplicarse en su justa me-dida, puesto que todo exceso es contraproducente. La aplicación al extremo deestas prácticas puede resultar en un efecto rebote.

Existen estudios6 que han identificado una serie de anti-patrones o indicadoresde mala praxis ante los que deberemos actuar en caso de detectarlos.

1. “Cookie licker” o lo que nosotros podríamos llamar “el perro del horte-lano”. Este antipatrón hace referencia a la típica situación en la que al-guien ni come ni deja comer. En la gestión de comunidades de volunta-rios en ocasiones se presentan situaciones en las que ciertas tareas estánparadas y no avanzan porque alguien ha reservado o ha asumido el com-promiso de trabajar sobre una tarea pero por diversas razones no acabade completarla aduciendo que “está casi lista”, “estoy muy liado, la se-mana próxima estará”, “trataré de sacar tiempo” …

Las causas que provocan esta situación suelen deberse al deseo de hacerlas cosas bien, a que los mejores colaboradores suelen estar siempre muyocupados, a que realmente creen que pueden sacar tiempo, al miedo acometer fallos en público…

Posibles soluciones para evitar esta situación serían:

• Establecer un roadmap claro y no permitir que nadie se reservemás tareas de las que puede realizar.

• Si se trata de trabajar sobre nuevas ideas a desarrollar, no permi-tir que alguien se la reserve en exclusiva, permitir el desarrollo enparalelo de borradores, prototipos, … que se revisen en comuni-dad y se combinen para obtener un resultado mejor.

• Establecer tiempos para finalizar las tareas y reasignarlas si no secumplen. Instaurar en la comunidad la cultura de no penalizacióndel fallo.

2. “Water cooler” o la “máquina del café”. Situación en la que la mayor par-te de los desarrolladores pertenecen a la misma entidad por lo que evi-tan realizar las discusiones en listas de correo o foros públicos, y rápida-mente solucionan las pequeñas discusiones por ejemplo en torno a lamáquina del café.

Cuando la mayor parte del trabajo se hace en privado, es difícil que la co-munidad entienda y comparta las decisiones, por lo que acaban generán-dose tensiones y en último extremo puede derivar en forks del proyecto.

La forma de evitar esta situación es permitir que las decisiones puedantomarse en pequeños grupos de trabajo para agilizar el proceso, pero que

6http://communitymgt.wikia.com/wiki/Category:Anti-patterns

35

http://communitymgt.wikia.com/wiki/Category:Anti-patterns


esto se haga de manera pública de forma que cualquiera pueda consultarcomo se ha llegado a las decisiones si es necesario. Utilizar por ejemplolistas de correo moderadas, wikis protegidos ...

3. “Bikeshedding”. Situación en la que se generan interminables debates ydiscusiones sobre cuestiones irrelevantes, debido fundamentalmente aldeseo de participación en la comunidad de miembros con poca experien-cia, que no tiene o creen no tener capacidad para participar en otros de-bates más productivos.

Para evitar esta situación el primer paso es reconocerla. Detectar rápida-mente cuándo se está produciendo una discusión de este tipo para ata-jarla a tiempo. Aconsejar a los desarrolladores seniors que no participenen este tipo de discusiones para minimizar su impacto.

Obviamente, este antipatrón está muy relacionado con el anterior. Si seproducen demasiados debates largos e improductivos, acabará por ins-taurarse la tendencia hacia los debates privados.

4. “Help Vampire”. Se refiere a un miembro de la comunidad que absorbecompletamente la capacidad de ayuda de la comunidad. Se trata de al-guien que ante cualquier duda o pequeño problema, en la mayoría de lasocasiones, resoluble con una simple búsqueda en google o una lectura delmanual, envía consultas a las listas o foros públicos antes de realizar unapequeña investigación por su cuenta.

Las recomendaciones para evitar este tipo de situaciones es manteneruna buena documentación para los usuarios o desarrolladores noveles,animar a los miembros noveles de la comunidad a responder a cuestio-nes básicas de otros o responder con información sobre donde y comoencontrar la respuesta mejor que con la propia respuesta. Por ejemplo,“en el capítulo 4 del manual puedes encontrar las instrucciones que bus-cas”, o “en esta pregunta del FAQ (enlace) puedes encontrar larespuesta”. De esta forma, al tiempo que se les responde a su duda se lesguía y enseña cual es el lugar para resolver ese tipo de dudas.

Como siempre es necesario mantener un equilibrio entre facilitar la en-trada 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 ge-né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 llega-dos y mermar las posibilidades de crecimiento de nuestra comunidad.

5. “Warnock's Dilemma” Este dilema se presenta ante la falta de respuestaen un foro o lista de correo, cuando alguien ha remitido un parche a lalista de desarrollo, alguien pregunta sobre la usabilidad de un nuevo ser-vicio o sobre la calidad de una nueva versión del software, ... La personaque ha remitido la consulta se puede plantear 5 alternativas ante la falta

36


de respuesta:

1. El mensaje es correcto, con toda la información necesaria y no nece-sita 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 quierenpedir aclaración sobre el mismo.

5. A nadie le importa el mensaje.

Como norma general se recomienda añadir en los correos indicación ex-presa a que se espera recibir una respuesta o feedback del resto de la co-munidad para actuar en consecuencia (corregir los posibles errores, me-jorar la usabilidad, …) Normalmente esto funciona. Por ejemplo, en lugarde enviar un mensaje indicando “Acabo de enviar un parche para elerror X notificado el día Y” sería aconsejable indicar en el propio mensa-je que se esperan revisiones del parche. O incluso si la comunidad hadado 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 tiempodeterminado se dará por aceptado el mensaje.

Existen mucha más información a este respecto que puede consultarse en laweb. Aquí se han recogido los síntomas más representativos a los que debemosprestar atención si queremos obtener una comunidad activa, participativa y enconstante crecimiento.

37

procedimiento de liberación de software de la xunta de … · procedimiento de liberación de...

Documents