Curso Liberacin del Cdigo

ndice de contenido
1. Preparando el cdigo ...................................................................................................................................2
1.1 Siguiendo metodologas de desarrollo...................................................................................................3
1.2 Estructurando el programa en mdulos.................................................................................................5
1.3 Facilitando la lectura del cdigo ............................................................................................................6
2. Elaborando la documentacin para ser liberada...........................................................................................7
2.1 Cmo gestionar la documentacin........................................................................................................8
2.2 Generando la documentacin automticamente...................................................................................9
3. Qu documentacin debes de tener en cuenta? .....................................................................................11
3.1 Documentacin a incluir.......................................................................................................................13
3.2 Documentacin recomendable............................................................................................................14
4. Herramientas para la liberacin..................................................................................................................16
4.1 Forja de proyectos...............................................................................................................................17
4.2 Repositorios.........................................................................................................................................20
4.2.1 Cmo funciona un Sistema de Gestin de Versiones (SGV)?...................................................21
4.3 Difusin: Blogs y Webs........................................................................................................................22
4.4 Comunicacin: Listas de correo e IRC.................................................................................................23
Glosario de trminos.......................................................................................................................................25
Material de Referencia....................................................................................................................................26
Material de Consulta.......................................................................................................................................28

Mdulo 3. Conociendo los aspectos tcnicos de la liberacin

Objetivos:

1. Ser conscientes de los aspectos a tener en cuenta para la liberacin del cdigo a nivel
tcnico.
2. Conocer cmo se debe modificar el cdigo para facilitar la inclusin de nuevos participantes
en el desarrollo del mismo.
3. Identificar la documentacin importante y til para la Comunidad.
4. Conocer las principales herramientas para la liberacin.

Esta obra est distribuida bajo la licencia

Reconocimiento-Compartir bajo la misma licencia 3.0 Espaa de Creative Commons

Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-sa/3.0/deed.es

Fundacin CENATIC
1. Preparando el cdigo
La empresa de David lleva un tiempo analizando la situacin de liberar el cdigo del producto
desarrollado, sopesando las ventajas e inconvenientes que conllevara y finalmente la Direccin da el
paso y opta por abordar dicha liberacin.
Tenemos luz verde! El equipo de David est muy entusiasmado con este proyecto, aunque va a ser todo
un reto para ellos pues nunca antes haban liberado cdigo Por dnde empezar?

Para dar los primeros pasos en la liberacin de cdigo, lo idneo es que comiences llevando a cabo una
serie de buenas prcticas tanto de desarrollo como de documentacin.
Entre las buenas prcticas de desarrollo vers las metodologas de desarrollo y gestin de proyectos (XP,
Mtrica, SCRUM, CMMI, etc.) as como el respeto a los diversos paradigmas de programacin existentes
(modular, OOP, POA, etc.).

Es importante que analices cul es la metodologa ms conveniente para el

proyecto y ser fiel a esta decisin antes de la liberacin y despus de realizarla.

Pregunta de Autoevaluacin
A la hora de liberar el cdigo:
a) Tengo que elegir mi propia metodologa de desarrollo.
b) Tengo que elegir la metodologa de desarrollo al finalizar la liberacin.
c) *Tengo que analizar la metodologa de desarrollo ms conveniente para el proyecto.
 1.1 Siguiendo metodologas de desarrollo
Entre las ventajas estudiadas por la empresa de David, la ms llamativa fue la oportunidad de
crecimiento y mejora que la comunidad ofrece al software desarrollado, diversificando y aumentando as
los potenciales clientes.
Pero para crear dicha comunidad, adems de una idea atractiva y un software funcional para los clientes,
tambin es necesario que pongas a disposicin pblica el cdigo fuente... De cualquier forma? O debe
estar estructurado de un modo concreto?

Y es que para facilitar la participacin de la comunidad en el desarrollo y el trabajo en grupo ser esencial
que publiques un cdigo fuente legible, documentado y bien estructurado.

Para ello emplea alguna de estas metodologas de desarrollo, usadas habitualmente en entornos de
software libre.

Metodologas de desarrollo

Test Driven Metodologa de desarrollo en la que primero escribes las pruebas del software y
Development (TDD) luego vas desarrollando el cdigo capaz de superar esas pruebas.

Metodologa de gestin de desarrollos en la que agrupas las tareas por orden de

importancia, y en cada interaccin el equipo se compromete a finalizar una serie
concreta de ellas.

Scrum Aunque la idea no es nueva, la filosofa gil de aceptacin del cambio hace que
esta metodologa se adapte muy bien a los entornos de desarrollo de software
libre, donde los cambios de requisitos son continuos, pues no existe un cliente o
dueo del producto que especifique sus necesidades desde el principio del
desarrollo.

Esta metodologa sostiene que la programacin en parejas aumenta el

rendimiento y la calidad del cdigo al doblarse no solo el nmero de personas que
intentan resolver el problema, sino la concentracin del autor por la presin de
saberse observado por el compaero.
XP o eXtreme Es difcil llevar a la prctica esta metodologa cuando los colaboradores suelen
Programming estar dispersos geogrficamente, sin embargo los desarrolladores adoptan casi
inconscientemente este tipo de metodologa de trabajo cuando se comunican con
otros colaboradores a travs de diversos medios de comunicacin en Internet
como el chat (IRC), las listas de correo o en los encuentros presenciales de
desarrollo.
Independientemente de la metodologa de desarrollo que emplees, es importante que tambin asumas un
paradigma de programacin, entre los ms comunes en software libre encontrars los siguientes:

Paradigmas de programacin

La programacin modular, consiste en dividir un problema complejo en varios

subproblemas ms simples, y stos a su vez en otros subproblemas ms
simples.
Esto debes hacerlo hasta obtener subproblemas lo suficientemente simples como
Modular para poderlos resolver fcilmente con algn lenguaje de programacin. sta
tcnica se llama refinamiento sucesivo, divide-y-vencers o anlisis
descendente.
De esta forma, un mdulo es una parte del programa que resuelve uno de estos
subproblemas por s mismo o usando a su vez otros mdulos.

La orientacin a objetos (Object Oriented Programming) consiste en identificar los

diferentes objetos o actores que intervienen en el programa y hacerlos unidades
independientes entre s. Estas unidades tienen una serie de acciones (mtodos) y
caractersticas (atributos) que lo definen.
El ejemplo clsico es el de un programa que simule un vehculo. Un ejemplo de
objeto sera coche, que podra realizar una serie de acciones como arrancar,
frenar, acelerar, girar, etc.
OOP
Tambin tendra una serie de caractersticas que lo definiran, como el color,
nmero de puertas, etc. A su vez, podra existir otro objeto llamado motor que
formara parte del coche con sus propias caractersticas y atributos (caballos,
potencia, tipo de combustible, etc).
Algunas acciones del objeto coche seran llevadas a cabo por l directamente,
como girar o frenar, mientras que otras se delegaran en el objeto motor (arrancar,
acelerar...) y no las realizara directamente la clase coche.

Es un error muy comn comenzar el desarrollo con intencin de usar un paradigma y terminar usando otro.
Por ejemplo, que inicies el software como orientado a objetos y acabe siendo un gran programa modular
encapsulado en una nica clase.

Es importante que identifiques el paradigma que mejor se adapta al problema a

resolver y mantenerte fiel a l.

Este tipo de errores no solo tienen impacto directo en la calidad del software sino tambin en la imagen de
inconsistencia que transmites a la comunidad, muy sensible con cualquier aspecto tcnico que indique falta
de seriedad o compromiso con la calidad del producto.

Quieres saber ms...?

Descubre ms acerca de las metodologas de desarrollo
de software visitando la siguiente pgina.

http://www.slideshare.net/kinfantas/metodologia-de-
desarrollo-de-software
 1.2 Estructurando el programa en mdulos
Aparte del paradigma de programacin seguido para el diseo del software, tendrs que respetar un
aspecto comn no solo por diseo, sino tambin por facilitar su uso, desarrollo y comprensin del cdigo,
que es la modularidad del mismo.

Estructurar un programa en mdulos consiste en que identifiques las

funcionalidades o diferentes aspectos del programa y separes claramente estos
en mdulos independientes, cajas negras, que funcionan por si mismos.

Toma como ejemplo de esta modularizacin el diagrama UML de los distintos mdulos de un software y la
relacin entre ellos:

A pesar de la falta de conocimiento de este software en concreto, puedes apreciar los diferentes
componentes del sistema gracias a la separacin en mdulos. As por ejemplo, puedes adivinar que si
quisieras modificar la interfaz de usuario de los profesores tendras que modificar el mdulo SguiProfe.

Con la separacin en mdulos evitars el estudiar la estructura completa de un programa para saber
cmo funciona un mdulo en concreto. Esto es importante no solo en desarrollos privados, sino
especialmente en desarrollos abiertos donde cualquier persona puede aportar valor al producto.

La facilidad de comprensin del diseo y de las decisiones tomadas es clave

para la colaboracin de la comunidad.
 1.3 Facilitando la lectura del cdigo
Puedes tomar varias estrategias para facilitar la lectura y compresin del cdigo fuente de un programa:
Adoptando un estilo de cdigo comn y consistente entre todos los contribuyentes. Esto lo
conseguirs mediante las llamadas guas de estilo. Estas guas determinan la forma en que debes
escribir el cdigo, los comentarios del mismo, la convencin a usar para el nombrado de los
diferentes componentes del sistema, etc.

Sabas que algunas guas de estilo llegan a tal nivel de detalle que especifican
incluso el nmero de espacios que debe existir entre diferentes elementos como
las asignaciones a variables (a=2 por contra de a = 2)?

As logrars que todas las aportaciones realizadas al proyecto encajen de forma homognea y
aumente la legibilidad del cdigo (el cdigo se lee ms veces de las que se escribe).

Documentando el sistema y todos sus componentes: Los mdulos, clases, mtodos y

funciones, as como los diferentes algoritmos y decisiones de funcionamiento. Comprenders que
esta documentacin es clave para la colaboracin comunitaria, pues es poco probable que alguien
centre sus esfuerzos y atencin en un proyecto que no cuida aspectos tan delicados como son los
mencionados no crees?.

Y es que entender el software escrito por un tercero ya es suficientemente complejo de por s como
para no disponer de ninguna ayuda que facilite lo mximo posible la comprensin del sistema
software. Esto es clave para que atraigas no solo a colaboradores, sino tambin a usuarios
deseosos de conocer el funcionamiento interno.

Para ello te pueden interesar los sistemas de generacin de documentacin automticos como
doxygen o sphinx, que extraen informacin sobre el cdigo fuente y generan documentacin en
varios formatos que te ser de gran ayuda a la hora de comprender y estudiar el cdigo.

Pregunta de Autoevaluacin
Cmo puedes facilitar la lectura del cdigo?
a) Documentando el sistema y todos sus componentes.
b) Adoptando un estilo de cdigo comn.
c) *Todas son correctas.
2. Elaborando la documentacin para ser liberada
David saba que llevar a cabo el proyecto de liberacin de la aplicacin no iba a ser coser y cantar, ya
que va ms all del simple hecho de hacer pblico el cdigo. Deben seguir una metodologa, de
desarrollo, modularizar el programa y facilitar la lectura del cdigo.
Pero... esto es suficiente para que la comunidad colabore en el desarrollo?

Y es que la liberacin no solo es que pongas el cdigo a disposicin del pblico, sino tambin documentarlo
y facilitar en la medida de lo posible la comprensin del mismo a travs de esa informacin.
 2.1 Cmo gestionar la documentacin

David cae en la cuenta de que cuando lleven a cabo la liberacin, sern muchas las personas quienes
modificarn el cdigo... Cmo controlar los cambios que hagan los colaboradores? y si lo hacen
simultneamente Sobrescribir los archivos y cambios de alguien ms sin querer?

Dispones de programas especialmente diseados para gestionar documentacin como Nuxeo o Alfresco ,
pero normalmente son programas complejos y pesados que estn sobrecargados de funcionalidades que no
necesita un proyecto de software libre.

Adems lo cierto es que parte de la documentacin del software se encuentra incluida dentro del mismo
cdigo, por lo que los sistemas de gestin como los comentados no resultan prcticos.

Por estos motivos, normalmente te resultarn ms prcticos sistemas no orientados a la gestin documental
propiamente dicha, pero que te ofrecen un equilibrio adecuado a las necesidades del proyecto, que suelen
ser:
Descentralizacin: Cualquier colaborador debe poder acceder a la documentacin desde
cualquier lugar del mundo en cualquier momento.

Histrico de cambios: Debe poder accederse a versiones antiguas de los documentos as como a
la informacin de los cambios, como autor, fecha, cambio realizado, etc.

Facilidad de acceso: Debe poderse acceder de forma annima para consulta y de forma
autenticada para realizar cambios en los documentos.

Gestionando la documentacin y el cdigo fuente del software mediante

sistemas de control de versiones, como subversion o git, te facilitarn la
generacin automtica de la documentacin tcnica a partir del cdigo fuente del
software, pues al estar ambas cosas, fuentes y documentacin, en el mismo
sistema se simplifica enormemente la tarea de mantenerlos sincronizados.

En cualquier caso, debes tener presente que la gestin de la documentacin es algo tan variable como los
distintos tipos de proyectos que pueden existir. Cada uno tiene una serie de caractersticas y necesidades
que pueden hacer inviable este tipo de gestin de documentacin o que haga necesario un sistema de
gestin de la documentacin completo.

Pregunta de Autoevaluacin
Qu propiedades debes buscar en un sistema de gestin de la documentacin?
a) Que permita acceder slo al administrador, sin necesidad de autenticarse y que guarde el histrico de
cambios.
b) *Que permita acceder a cualquier colaborador, con o sin autentificacin y que guarde el histrico de
cambios.
c) Que permita el acceso a cualquier colaborador, con o sin autentificacin y que guarde el histrico de
visitas.
 2.2 Generando la documentacin automticamente
Como recordars del punto anterior, muchas veces es necesario y especialmente deseable que la
documentacin la generes automticamente a partir del cdigo fuente.

Para ello emplea sistemas especializados en este tipo de tareas, que generen de forma automtica la
documentacin tcnica del proyecto a partir de los fuentes y una serie de marcas, que enlazan incluso las
partes relacionadas entre s del sistema.

Estos sistemas de generacin de documentacin se basan en las marcas, comentarios e indicaciones que
el desarrollador coloca estratgicamente para que el sistema sepa qu parte del cdigo se est
documentando.

Por ello, resulta esencial que seas consciente desde el principio del proyecto o
durante el proceso de liberacin deberas usar un sistema de generacin
automtica de documentacin, para incluir su uso en las guas de estilo de
cdigo.

Por otro lado, la generacin automtica de documentacin se refiere normalmente a la documentacin

tcnica de los fuentes del proyecto, pero adems es posible aplicarla a la documentacin de usuario.

Puedes usar este tipo de sistemas para ambos cometidos, pero ten presente que requiere de un esfuerzo
adicional por parte de los desarrolladores y las personas a cargo de la documentacin, pues tienes que
coordinar en un mismo documento la informacin destinada al usuario final con la destinada a los
desarrolladores.

Puedes ver como ejemplo de sistemas de generacin de documentacin los siguientes:

Sphinx: Creado originalmente para documentar el lenguaje de programacin python

(http://docs.python.org/dev/), es uno de los sistemas ms usados para documentar proyectos
creados en este lenguaje. Usa un lenguaje de marcas llamado reStructuredText para marcar los
diferentes aspectos de la documentacin.

Doxygen: Posiblemente el sistema de generacin de documentacin ms conocido y usado dentro

de la comunidad del software libre. Su potencia es tal que es posible generar documentacin a
partir de los fuentes sin necesidad de prepararlos, es decir, sin incluir ningn tipo de marca o
smbolo especial.
En palabras del autor: You can configure doxygen to extract the code structure from undocumented
source files, You can even `abuse' doxygen for creating normal documentation (as I did for this
manual).

Normalmente estos generadores de documentacin pueden crear documentos de varios tipos, siendo los
ms comunes HTML, Latex y PDF.

Quieres saber ms...?

Si quieres conocer ms acerca de la generacin de
documentacin de manera automtica con Doxygen,
puedes visualizar el siguiente vdeo:

http://www.youtube.com/watch?v=9u1mrVTRt4w

Pregunta de Autoevaluacin
Cmo puedes generar la documentacin automticamente?
a) *Usando sistemas que se basan en las marcas, comentarios e indicaciones que el desarrollador coloca
estrategicamente para documentarlo.
b) Usando sistemas que se basan en los estilos que el desarrollador ha documentado previamente en la
gua de estilo de cdigo.
c) Usando sistemas que se basan en las versiones que el desarrollador realiza sobre las modificaciones
efectuadas en el cdigo.
3. Qu documentacin debes de tener en cuenta?
David y sus compaeros llevan algunas semanas centrando sus esfuerzos en modularizar y documentar
el cdigo. Han descrito el propsito de cada subsistema y documentado sus interfaces y la forma en que
cada subsistema se comunica con el resto y con el exterior.
Es decir, que han documentado las entraas de la aplicacin, ahora bien, David ve que otra cuestin
diferente es explicar cmo el usuario puede usarla o describir los pasos para instalarla. De hecho, no
est del todo seguro de si es necesario incluir esa informacin, ni cmo hacerlo Sobre qu otros
aspectos deber informar a los desarrolladores?

David est en lo cierto al pensar que debe proporcionar ms detalles del producto para que los usuarios
sepan utilizarlo. Para esto tienes que elaborar la documentacin tcnica y de usuario.

La documentacin tcnica se refiere a los diferentes documentos informativos que posee un determinado
Software y en los que suele informarte de:
1.La definicin tcnica del producto y sus especificaciones.
2.El diseo del producto.
3.La descripcin de las propiedades del producto.
4.La Interfaz y las funciones del producto.
El objetivo de este tipo de documentacin es transmitir la informacin tcnica de un producto de manera
clara y ordenada a una audiencia determinada, adaptndola a las necesidades de sta. Gracias a esto
familiarizas al usuario con el producto y le ayudas a usarlo satisfactoriamente.
Este tipo de informacin suele ser utilizada por desarrolladores, usuarios avanzados, etc.

La documentacin tcnica se ha convertido en una parte vital, aadindole valor

e incrementando la satisfaccin del usuario, puesto que ste asocia la calidad de
la documentacin con la calidad del producto.

Teniendo en cuenta que el producto puede cambiar en un corto perodo de tiempo, debes actualizar
continuamente la documentacin, por ello te resultarn tiles las herramientas como Doxygen, Ndoc,
TwinText, etc, que extraen los comentarios del cdigo del producto y crean guas de referencia, muy tiles
para desarrolladores que necesitan conocer de manera rpida que hace una determinada parte del
producto.

Ejemplo de documentacin autogenerada

Respecto a la documentacin de usuario, describe cmo usar el producto en cuestin, as como sus
caractersticas, y asiste al usuario en la realizacin de la misma.

Es importante que elabores la documentacin de usuario de forma que no sea confusa y que est
actualizada. Adems, incluye un ndice de temario, aunque no est organizado de una manera en particular,
y una parte de Solucin de errores.

Puedes organizar la documentacin de usuario de tres formas diferentes:

1.Tutoriales: Este tipo de documento es considerado como el ms til para un usuario nuevo,
en l guas al usuario paso a paso para llevar a cabo una serie de tareas especficas.
2.Documento divido en temas: Este tipo de documento suele estar dividido en captulos o
secciones que abarcan determinadas reas de inters del producto, suele ser usado por
usuarios intermedios.
3.Gua de referencia: Se basa en listar alfabticamente las diferentes tareas que se pueden
realizar con el producto. Suele ser utilizada por usuarios avanzados.

Ejemplo de manual de usuario de Ubuntu

 3.1 Documentacin a incluir
Existe una serie de documentos que se consideran esenciales:

Manuales de uso: Utiliza este tipo de documento para describir cmo usar un determinado
producto, estructurndolo en forma de tutorial gua al usuario a desempear las tareas ms
comunes en el producto.

Manuales de instalacin y administracin: En el manual de instalacin describes el proceso de

instalacin del producto en un entorno determinado, asistiendo al usuario en las principales tareas
para administrarlo. Organzalo por secciones, y en cada seccin tipifica como administrar una
determinada caracterstica del producto. Adems, debes incluir una seccin de Requisitos, en la
cual tipifiques lo que es necesario para poder instalar el producto correctamente.

Licencia: La licencia es un contrato entre el creador del producto y el usuario que utiliza el
producto. Mediante las licencias de software Libre puedes establecer criterios sobre el uso de
determinadas partes del producto, esto ir en funcin del elemento que hayas utilizado en el
producto y la licencia del mismo. Las licencias de SL pueden obligar a hacer cambios en el cdigo
(caso de BSD y/o GPL). Es necesario efectuar estos cambios antes de liberar el cdigo...

Informacin de contacto: En este tipo de documentos indicas los diferentes mtodos de contacto
que posee el creador del producto en cuestin. Se suele indicar una direccin fsica, un direccin de
correo electrnico, una pgina web, etc.

Pregunta de Autoevaluacin
Qu documentos no puedes olvidar para la liberacin?
a) *La licencia, los datos de contacto y los manuales de uso, instalacin y administracin.
b) La licencia, los datos de contacto y los manuales de uso, organizacin y administracin.
c) La licencia, los autores y los manuales de uso, instalacin y administracin.
 3.2 Documentacin recomendable
Aparte de la documentacin de obligada inclusin, hay una serie de documentos que si bien no son
esenciales, s es recomendable que proporciones:

Documentos de diseo del software: Mediante estos documentos muestras cmo funciona el
producto a nivel interno, cules son los posibles usos del producto, etc. Tienes que organizarlos
como un diagrama de clases que explique la estructuracin y el flujo de trabajo del producto a
nivel interno, as como un diagrama de casos de uso en los que expliques los diferentes usos del
producto por parte de un usuario.

Ejemplo de Casos de uso

Documentacin de la API: Se trata de un documento donde los desarrolladores del producto

detallan un conjunto de funciones y procedimientos del mismo que pueden ser utilizados por otro
software.

Documentacin tcnica de diseo

Quieres saber ms...?
La documentacin de la API es una parte vital en los
tiempos que corren, si quieres conocer un ejemplo de xito,
visita esta pgina:

http://apiwiki.twitter.com/
4. Herramientas para la liberacin
El equipo de David ha investigado sobre las herramientas y sistemas abiertos para el proceso de
desarrollo. Aunque su proyecto sigue sus propias reglas, y usa su propio conjunto de herramientas,
saben que hay ciertas prcticas, entornos y tecnologas que son habituales en el mundo del desarrollo
del SFA.
Ahora se encuentran ante un dilema: Deben facilitar estas herramientas o pueden utilizar plataformas
especializadas ya disponibles?

Con carcter general, ser recomendable que se utilices plataformas ya existentes, pues suelen albergar
mltiples proyectos de software en los que los desarrolladores han de registrarse para poder contribuir.
Adems consta de numerosas aplicaciones normalmente con interfaz web para la administracin y
desarrollo de estos proyectos en comn.

Antes de repasar herramientas concretas, vas a ver las caractersticas y propiedades generales que tienen
en funcin del trabajo a realizar y el modo de organizarse los desarrolladores.

Es habitual que tanto el entorno como las herramientas de desarrollo e incluso la mquina
virtual (cuando la hay) sean tambin libres, pues ser imprescindible para que los
desarrolladores que las posean y puedan colaborar. En el caso de que sean privadas, el entorno y/o
la mquina virtual han de estar lo suficientemente difundidas y ser lo bastante econmicas como
para poder reunir suficientes desarrolladores que dispongan de esas herramientas.

Tambin para atraer el mayor nmero de desarrolladores, las herramientas deben ser sencillas,
ampliamente conocidas y aprovechen al mximo las capacidades del hardware. Posiblemente
por estas razones el mundo del software libre es relativamente conservador en lenguajes,
herramientas y entornos.

El modelo de desarrollo de software libre suele ser eminentemente distribuido, con muchos
colaboradores potenciales repartidos por todo el mundo. Por ello son precisas herramientas de
colaboracin, generalmente asncronas, que permitan que el desarrollo avance con facilidad,
independientemente de la cantidad y ritmo de trabajo de cada colaborador, sin retrasar a nadie.

Es conveniente proporcionar a los desarrolladores de recursos de los que carecen, como

mquinas de arquitecturas diversas (sean reales o virtuales), donde puedan compilar y probar sus
programas.

En este sentido, para facilitar el trabajo del desarrollador puedes utilizar un Entorno Integrado de
Desarrollo (IDE, Integrated Development Environment). Se trata de un sistema que integra slidamente la
edicin orientada al lenguaje, la compilacin o interpretacin, la depuracin, las medidas de rendimiento, la
incorporacin de los fuentes a un sistema de control de fuentes, etc., normalmente de forma modular.
No obstante, a todos los desarrolladores no les gustan estas herramientas, a pesar de que su uso se ha ido
extendiendo progresivamente, por lo que su uso ser opcional.

A continuacin, repasa los entornos ms comunes y su impacto en la gestin y evolucin de los proyectos.
 4.1 Forja de proyectos
Utilizando una forja de software te permitir el desarrollo de software en colaboracin a travs de Internet.
Por este motivo la forja se ha hecho popular, desarrollando un gran nmero de proyectos de software libre
en los ltimos aos.

Este tipo de plataforma engloba un conjunto de aplicaciones bajo una interfaz Web integrada, que
generalmente hospeda varios proyectos independientes. En ella los desarrolladores, que estn registrados
como contribuyentes, pueden utilizar las herramientas de gestin de proyectos y las herramientas de
desarrollo de software diferentes.

Dos tipos de conceptos estn generalmente unidos al trmino forja:

1. Un servicio ofrecido en una plataforma web para hospedar proyectos de desarrollo de software
2. Un conjunto integrado de elementos de software que producen dichas plataformas, listas para su
distribucin en una organizacin o en Internet.

En general, todas estas plataformas ofrecen herramientas similares para los desarrolladores de software
que trabajan en los proyectos alojados:
Sistemas de gestin de cdigo fuente (compatible con otros SGV)
Listas de correo o foros
Wikis
Servicios de descarga de software
Sistema de seguimiento de errores
Servicios de copias de seguridad

Con el uso de estas herramientas atraers a los desarrolladores para encontrar, unir y contribuir en el
proyecto. No obstante, para que esto suceda las herramientas debes emplearlas con cuidado, pues el uso
de un sistema de colaboracin abierta debe de hacerte consciente que se trata de un sistema:

Los miembros del proyecto debes verlos como alguien que viene a ayudar, en
Igualitario lugar de verlos como un elemento externo. La documentacin del proyecto para
los futuros colaboradores es un aspecto a tener en cuenta.

Los miembros del proyecto tienen que darse cuenta que las aportaciones y
Meritocrtico
contribuciones importantes puede venir de todas partes.

Aunque el proyecto cuente a nivel interno con procesos bien definidos de

desarrollo, debe ser permisivo con sus voluntarios. Para estos, la contribucin y la
recepcin de comentarios positivos del proyecto es la principal recompensa.

Auto-organizativo Puedes potenciar an ms esta recompensa mediante formas creativas de

expresar tu agradecimiento. Formas sencillas de hacerlo son por ejemplo: La
entrega de merchandising del proyecto, esponsorizacin de desarrolladores
para asistir a eventos o servir de currculum a la hora de formar parte de la
empresa.

Esto convierte a las forjas en el tipo de herramienta perfecto para obtener todo el entorno listo para liberar tu
software, sin la necesidad de realizar desembolso alguno en infraestructuras, facilitando la participacin
de desarrolladores, as como la fcil gestin del proyecto.

De hecho, el xito que han tenido las forjas en el mundo del SFA ha llevado a gran cantidad de empresas a
implantarlas internamente. Conoce algunos ejemplos exitosos de forjas:
 Sourceforge (www.sf.net)

Forja Linex (http://forjamari.linex.org/)

 Google Code (code.google.com)
 4.2 Repositorios

Durante el desarrollo de tu software, una modificacin produce un error oculto que descubres tardamente
No querras recuperar el original para analizar el problema? Por este motivo, es importante que todo
proyecto de desarrollo de programas guarde la historia del mismo.
Adems, si el proyecto lo desarrollan varias personas, es necesario tambin registrar el autor de cada
cambio, con las razones del mismo explicadas.
Asimismo, en caso de que hagas entregas versionadas del proyecto, tendrs que saber exactamente las
versiones de cada mdulo que forman dichas entregas. Muchas veces, un proyecto mantiene una versin
estable y otra experimental, que tendrs que mantenerlas, corregir sus errores y transferir errores corregidos
de una versin a la otra.
Pues esto es lo que normalmente hace un sistema de control de fuentes, tambin llamado Sistema de
Gestin de Versiones (SGV).

Un sistema de gestin de versiones registra la historia de los ficheros como un

conjunto de diferencias sobre un patrn (normalmente el ms reciente),
etiquetando adems cada diferencia con los meta-datos necesarios.

As pues, un sistema de control de versiones debe proporcionar:

Mecanismo de almacenaje de los elementos que deba gestionar (ej. archivos de texto, imgenes,
documentacin...)
Posibilidad de realizar cambios sobre los elementos almacenados (ej. modificaciones parciales,
aadir, borrar, renombrar o mover elementos)
Registro histrico de las acciones realizadas con cada elemento o conjunto de elementos
(normalmente pudiendo volver o extraer un estado anterior del producto)
Aunque no es estrictamente necesario, encontrars muy til la generacin de informes con los cambios
introducidos entre dos versiones, informes de estado, marcado con nombre identificativo de la versin de
un conjunto de ficheros, etctera.

Analizando los tipos de repositorios, la principal clasificacin est basada en el almacenamiento del cdigo:

Centralizados Distribuidos
Existe un repositorio centralizado de todo el cdigo, Cada usuario tiene su propio repositorio, por lo que
del cual es responsable un nico usuario (o conjunto no es necesario tomar decisiones
de ellos). centralizadamente.
Se facilitan las tareas administrativas a cambio de Los distintos repositorios pueden intercambiar y
reducir flexibilidad, pues todas las decisiones fuertes mezclar revisiones entre ellos.
(como crear una nueva rama) necesitan la
aprobacin del responsable.
Ejemplos: Git y Mercurial.
Algunos ejemplos son CVS y Subversion.
 4.2.1 Cmo funciona un Sistema de Gestin de Versiones (SGV)?
El sistema permite que varios usuarios obtengan copias del proyecto al mismo tiempo, de forma que cuando
introducen las modificaciones, el servidor intenta acoplarlas.

Si no es posible encajarlas, por ejemplo porque dos clientes estn intentando cambiar la misma
lnea de un mismo archivo, entonces el servidor deniega el segundo ingreso e informa al cliente
sobre el conflicto, que el usuario deber resolver manualmente.

Si la introduccin de la modificacin tiene xito, entonces los nmeros de versin de todos los
archivos implicados se incrementan automticamente, y el servidor escribe una lnea de descripcin
suministrada por el usuario, la fecha y el nombre del autor.

Otras funcionalidades que dispones en SGV, es comparar diferentes versiones de archivos, solicitar una
historia completa de los cambios, ver el estado del proyecto en una fecha determinada o en un nmero de
revisin determinado.

Muchos proyectos open source permiten el acceso de lectura annimo, este tipo de acceso te permite
sacar y comparar versiones sin necesidad de introducir una contrasea, necesaria slo si quieres introducir
modificaciones en los archivos.
Dispones tambin de una orden de actualizacin, que tes permite tener tus copias al da, con la ltima
versin que se encuentra en el servidor, evitndote as el tener que repetir las descargas del proyecto
completo.

Un SGV tambin puede mantener distintas ramas de un mismo proyecto. Por ejemplo,una versin difundida
de un proyecto puede formar una rama y ser utilizada para corregir errores. Todo esto se puede realizar
siempre que la versin que se encuentra actualmente en desarrollo y posee cambios mayores con nuevas
caractersticas se encuentre en otra lnea formando otra rama separada.

La estructura habitual de un repositorio de un SGV, salvando las diferencias entre las herramientas
utilizadas es:
Trunk: Desarrollo principal.
Tags: Ubicacin de las versiones congeladas.
Branches: Ubicacin con versiones de desarrollo paralelas al trunk.

Pregunta de Autoevaluacin
Cuando dos usuarios introducen modificaciones que generan un conflicto que el servidor no puede
encajar Cmo lo resuelve?
a) El servidor genera dos versiones para cada usuario.
b) *El servidor deniega el segundo ingreso e informa al cliente sobre el conflicto, que el usuario deber
resolver manualmente.
c) El servidor deniega el primer ingreso e informa al cliente sobre el conflicto, que el usuario deber
resolver manualmente.
 4.3 Difusin: Blogs y Webs
Para llevar a cabo la difusin de tu proyecto dispones de diversos medios. Entre los ms usados y visitados
estn las pginas web especializadas en tecnologa y SFA, que gustan de hacer eco de noticias de
liberaciones y nuevos proyectos libres.

Puedes distinguir principalmente dos tipos webs especializadas en difusin.

Por una parte, las webs colaborativas publican peridicamente informacin sobre nuevos proyectos libres,
liberaciones y noticias generales sobre proyectos de SFA.
En estas pginas puedes encontrar las noticias sobre productos o eventos que los usuarios consideran
importantes y de acuerdo a un sistema de votacin comunitaria, las ms populares salen a portada.

Algunos ejemplos de estas pginas son Slashdot, Reddit y Digg en ingls y Barrapunto en espaol.

Y por otro, dispones de los Weblogs o blogs, que son pginas de individuos, instituciones o empresas
donde se publican noticias relacionadas con productos o proyectos propios.

Normalmente los proyectos libres disponen de uno o varios blogs donde los autores o el grupo de trabajo
encargado, publican informacin relevante sobre el proyecto y comparten con la comunidad las nuevas
ideas, los problemas que se estn atravesando o las futuras caractersticas de los productos.

Los blogs sirven tambin como medio de conversacin entre los autores del
software y los usuarios finales a travs de los comentarios.

Algunos ejemplos de este tipo de pginas son los blogs de la Apache Fundation, del equipo de Mozilla o del
fundador de Ubuntu, Mark Shuttleworth.

Pregunta de Autoevaluacin
En qu se diferencian los blogs de las webs?
a) Las webs recogen noticias generales de tecnologa, mientras que los blogs son pginas o espacios
personales.
b) *Los blogs permiten mantener un dilogo directo con los autores del software, mientras que las webs
son publicaciones.
c) Los blogs estn ms actualizados que las webs.
 4.4 Comunicacin: Listas de correo e IRC
Tampoco olvides que dispones de otros medios de comunicacin, eso s, ms clsicos. Hablamos de las
listas de correo y el IRC (Internet Relay Chat), que a diferencia de las pginas web, requieren de
programas especializados para su manejo, como un cliente de correo y de IRC, pero que cada vez es ms
comn el acceso mediante un navegador web.

Las listas de correo son un uso especial del correo electrnico que permite la distribucin masiva
de informacin entre mltiples usuarios de Internet. De esta forma, los proyectos disponen de una
forma sencilla de comunicacin entre todas las personas interesadas, centrada en una nica
direccin de correo electrnico.

Suscribindote a una lista de correo recibirs noticias sobre actualizaciones, fallos,

nuevos proyectos, etc.

Por ejemplo, un proyecto podra tener una lista de correo centrada en el desarrollo del software, otra
para compartir informacin sobre los problemas que se encuentran y una ltima destinada a los
usuarios finales, donde comparten experiencias y dudas sobre el uso.
De esta forma, si te interesa slo el tema de la colaboracin con el proyecto te suscribes a las listas
de desarrollo y problemas.

En cuanto al IRC, se trata de un protocolo de comunicacin en tiempo real basado en texto, que
permite charlas entre dos o ms personas en compartimentos semi-privados llamados salas. Estas
salas se crean en los servidores de IRC y permiten la comunicacin entre los usuarios que estis
suscritos a dicha sala.

Como ejemplo, el proyecto python dispone de una sala llamada #python en el servidor de IRC
irc.freenode.org. Al igual que las listas de correo, los canales de irc tambin pueden especializarse,
de forma que puedes encontrar canales en distintos idiomas (#python-es, #python-it, #python-fr, ),
distintos aspectos del producto (#python-devel, #python-bugs, etc).

A travs de estas salas, puedes comunicarte en tiempo real no slo con otros
usuarios del software, sino tambin con los propios autores del mismo.

Estos dos sistemas tienen una serie de virtudes y defectos que se complementan:

En IRC, aunque un usuario est presente en la sala, nada garantiza que la persona
est disponible para interactuar. De hecho existen ocasiones en las que los
usuarios de IRC pasan das o semanas conectados sin prestar atencin a lo que
Disponibilidad ocurre en el canal.
Por contra, en las listas de correo aunque el tiempo para obtener respuesta a los
mensajes es mayor, por lo general se garantiza que alguien leer y prestar
atencin al correo.

Al ser un protocolo de tiempo real, la interaccin entre los usuarios de IRC, cuando
existe, es casi instantnea, de forma que pueden darse conversaciones limitadas
solo por la velocidad de escritura de los participantes y su capacidad de expresin.
Tiempo de respuesta
En cambio, en las listas de correo pueden pasar semanas hasta que un mensaje
recibe respuesta, ya que no slo debe ser ledo, sino que la persona que responda
debe disponer del tiempo suficiente para elaborar el mensaje de respuesta.

Claridad En las listas de correo, al ser mayores los tiempos de respuesta se aprecia una
claridad en el orden de las mismas, haciendo que en la mayora de los casos sea
fcil seguir una conversacin.
En cambio en IRC, al ser conversaciones en tiempo real, no es raro que se de el
caso de conversaciones mezcladas o personas respondiendo cuestiones de forma
 desordenada.
Por lo general es fcil perderse en una conversacin con muchos participantes en
IRC. Por este motivo, en reuniones oficiales de proyectos en IRC suele existir la
figura del moderador, que cede turnos de palabra a los distintos partipantes.

Las lista de correo son fcilmente consultables, pues los servidores disponen de
un histrico de los mensajes que se han enviado incluso indexados para permitir la
bsqueda de informacin dentro de los mismos.

Histrico Sin embargo, son raros los servidores de IRC que guardan en copia las
conversaciones de los canales que albergan. Normalmente esto se lleva a cabo
mediante bots de IRC que se limitan a guardar todas las conversaciones que
ocurren en un canal determinado. Estos registros tienen la desventaja de que
suelen existir solo como texto plano en los que es tedioso realizar bsquedas

Las listas de correo y el IRC requieren de una infraestructura modesta para funcionar y existen servidores
gratuitos de ambos medios. Pueden parecerte que, por sus caractersticas y aspecto, son servicios y medios
poco potentes y carentes de atractivo, pero han demostrado ser los medios ms eficientes para la
comunicacin en proyectos de SFA.
Glosario de trminos
Bot de IRC: Programa de ordenador diseado para conectarse a redes de IRC y ejecutar acciones
automticamente o bajo peticiones de usuarios. Un ejemplo son los bots informativos del canal #ubuntu, que
pueden dar informacin variada sobre, por ejemplo, paquetera. Otro uso ms extendido de los bots de IRC
es el de guardar un registro de las conversaciones mantenidas en el canal.

Branch: es la duplicacin de un objeto bajo control de revisiones (por ejemplo, un archivo de cdigo fuente,
o un rbol de directorios) de modo que las modificaciones que puede suceder de forma paralela a lo largo
de las dos ramas.

Comunidad: La comunidad del software libre es un trmino que hace referencia informal a los usuarios y
desarrolladores de software libre, as como los partidarios del movimiento de software libre.

Git: Software de control de versiones diseado por Linus Torvalds, pensando en la eficiencia y la
confiabilidad del mantenimiento de versiones de aplicaciones cuando estas tienen un gran nmero
archivos de cdigo fuente.

IRC (Internet Relay Chat): Es un protocolo de comunicacin en tiempo real basado en texto, que permite
debates entre dos o ms personas. Se diferencia de la mensajera instantnea en que los usuarios no
deben acceder a establecer la comunicacin de antemano, de tal forma que todos los usuarios que se
encuentran en un canal pueden comunicarse entre s, aunque no hayan tenido ningn contacto anterior.

Merge: en un control de revisiones, es una operacin fundamental que reconcilia los mltiples cambios
realizados a una coleccin de archivos controlados por un SGV. Es necesario cuando un archivo se
modifica por dos personas en dos ordenadores diferentes al mismo tiempo. Cuando dos ramas se mezclan,
el resultado es una coleccin nica de los archivos que contiene dos conjuntos de cambios.

Sistemas de Gestin de Versiones (SGV): Se llama control de versiones a la gestin de los diversos
cambios que se realizan sobre los elementos de algn producto o una configuracin del mismo.

Subversion (svn): Es un sistema de gestin de fuentes centralizado diseado para sustituir al antiqusimo
CVS y que es el usado por la gran mayora en los proyectos libres.
Utiliza un repositorio central al que se accede segn un sistema cliente/servidor, donde el administrador del
sitio puede decidir quienes tienen acceso al repositorio o a qu partes del repositorio. Adems puede
permitirse un acceso annimo, slo en lectura a todo el mundo.
Material de Referencia
Metodologa de desarrollo de software. Consultado el 23 de julio de 2010,
Wikipedia:
http://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software

Desarrollo gil de software. Consultado el 23 de julio de 2010, Wikipedia:

http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software

Style Guide for Python Code. Consultado el 23 de julio de 2010:

http://www.python.org/dev/peps/pep-0008/

Pgina web de Nuxeo.Consultado el 23 de julio de 2010:

http://www.nuxeo.com/en

Pgina web de Alfresco. Consultado el 23 de julio de 2010:

http://www.alfresco.com/

Pgina web de Sphinx.Consultado el 23 de julio de 2010:

http://sphinx.pocoo.org/

reStructuredText .Consultado el 23 de julio de 2010:

http://docutils.sourceforge.net/rst.html

Pgina web de Doxygen.Consultado el 23 de julio de 2010:

http://www.stack.nl/~dimitri/doxygen/

Software Documentation. Consultado el 23 de julio de 2010, Wikipedia:

http://en.wikipedia.org/wiki/Software_documentation

SForge (software). Consultado el 23 de julio de 2010, Wikipedia:

http://en.wikipedia.org/wiki/Forge_%28software%29

SourceForge . Consultado el 23 de julio de 2010:

http://sourceforge.net/

Pgina web de slashdot.Consultado el 23 de julio de 2010:

http://slashdot.org/

Reddit programming.Consultado el 23 de julio de 2010:

http://www.reddit.com/r/programming

Reddit freeculture.Consultado el 23 de julio de 2010:

http://www.reddit.com/r/freeculture/

Digg. Consultado el 23 de julio de 2010:

http://digg.com/technology

Barrapunto.com. Consultado el 23 de julio de 2010:

http://barrapunto.com/

Blogg de Apache. Consultado el 23 de julio de 2010:

http://blogs.apache.org/foundation/

Blogg de Mozilla. Consultado el 23 de julio de 2010:

http://blog.mozilla.com/

200 issues of Ubuntu Weekly News wonderfully done! Consultado el 23 de julio de

2010:
http://www.markshuttleworth.com/

Ejemplo de histrico. Consultado el 23 de julio de 2010:

 https://lists.ubuntu.com/archives/ubuntu-users/

Wiki de Ubuntu. Consultado el 23 de julio de 2010:

https://wiki.ubuntu.com/IRC/Bots

Apache Subversion. Consultado el 23 de julio de 2010:

http://subversion.apache.org/
Material de Consulta
Sitio web donde puedes examinar las estadsticas de casi cualquier proyecto
OpenSource incluyendo licencias, n de descargas, n contribuciones, etc. Es muy
intersante, dado que permite determinar el estado de salud de un proyecto. Por
ejemplo: http://www.ohloh.net/p/firefox/analyses/latest. Consultado el 21 de julio de
2010:
http://www.ohloh.net/

Sourceforge. Sitio web donde se describe con gran detalle las tecnologas y
servicios disponibles en Sourceforge. Tambin sirve como ejemplo si se desea
montar un sistema similar. Consultado el 21 de julio de 2010:
http://sourceforge.net/apps/trac/sourceforge/wiki/WikiStart

GNU. Sitio web donde se describe que es el software libre. Consultado el 21 de

julio de 2010:
http://www.gnu.org/philosophy/free-sw.es.html

Sitio web de "La Free Software Foundation (FSF)". Consultado el 21 de julio de

2010, organizacin sin nimo de lucro que promociona la libertad de los usuarios de
ordenadores, y defiende los derechos de los usuarios de software libre:
http://www.fsf.org/

Sitio web del Centro Nacional de Referencia de Aplicacin de las TIC basadas en
fuentes abiertas. Consultado el 21 de julio de 2010:
http://www.cenatic.es/

Sitio web donde se informa de forma detallada, a travs de una tabla comparativa,
los diferentes servicios de hosting para los proyectos de software libre. Consultado
el 21 de julio de 2010:
http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities

Sitio web donde se informa de forma detallada, a travs de una tabla comparativa,
las diferentes herramientas de control de versiones para el software. Consultado el
21 de julio de 2010:
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

Directorio web con informacin relativa a las forjas de Software Libre. Consultado el
21 de julio de 2010:
http://wiki.planetforge.org/index.php/Special:AllPages