% \subsection{El bazar y la catedral}


% dgg: Aqui no estaria mal una pequeña introduccion que diga
% dgg: que es lo que vas a explicar en este apartado y porque.

%qué es open source y principales características
Eric S. Raymond, fundador de la OSI \cite{OSI}({\it Open source Fundation}) y promotor del término {\it código abierto}, definió el {\it Open Source} a partir de 10 características:


\begin{enumerate}
\item {\bf Libre redistribución}:
el software debe poder ser regalado o vendido libremente.
En el momento de la compra no habrá {\it royalties} ni ningún otro tipo de tasa.

\item {\bf Código fuente}:
el código fuente será distribuido junto con el código compilado.
De no ser así, se deberá indicar el camino para obtenerlo.

\item {\bf Trabajos derivados}:
La licencia debe permitir modificaciones y trabajos derivados.
El nuevo trabajo debe poder tener las mismas condiciones de licencia que el software original.

\item {\bf Integridad del código fuente del autor}:
la licencia puede restringir la distribución del código fuente {\it sólo} si permite la distibución de parches con el código fuente.
La licencia debe permitir explícitamente la distribución delsoftware creado desde el código fuente modificado.

\item {\bf Sin discriminación de personas o grupos}:
La licencia no debe discriminar a ninguna persona o grupo de personas.

\item {\bf Sin discriminación de áreas de iniciativa}:
La licencia no debe poder restringir la utilización del software en algún campo concreto.

\item {\bf Distribución de la licencia}:
Los derechos que atañen al programa deben aplicarse a todos los usuarios del software de manera ecuánime.

\item {\bf La licencia no debe ser específica de un producto}:
Los derechos que atañen al programa no deben depender de un programa que englobe a éste.

\item {\bf La licencia no debe restringir otro software}:
la licencia no puede obligar a que algún otro software que sea distribuido con el software abierto deba también ser de código abierto.

\item {\bf La licencia debe ser tecnológicamente neutral}:	
no debe requerirse la aceptación de la licencia por medio de un acceso por clic de ratón o de otra forma específica del medio de soporte del software.
\end{enumerate}


%open source Vs Software tradicional
A partir de estos 10 puntos y el libro de {\it El Bazar y la Catedral}\cite{Raymond}, donde comenta el {\it Open Source} comparándolo con metodologías tradicionales, encontramos una serie diferencias en diseño, grupo de trabajo, finalización del proyecto y mantenimiento.
\begin{itemize}
\item Mientras que en metodologías tradicionales el diseño requiere una planificación meticulosa, en el caso del {\it Open Source} el diseño crece junto con el desarrollo.
\item Las decisiones en el caso de metodologías tradicionales, están formados por gente experta y con un alto nivel de conocimiento, en cambio, en metodologías de código abierto tienen cabida los puntos de vista de todos los participantes del proyecto.
Esto no significa que un poryecto {\it Open Source} no pueda estar jerarquizado y organizado.
\item Un software de metodología tradicional no se pondrá en marcha hasta que no se haya finalizado por completo. 
En metodología {\it Open Source} no hay un día concreto de arranque ya que la funcionalidad se amplía gradualmente, con lo cual, en el momento que tiene la funcionalidad mínima, el software ya puede ser usado.
\item El mantenimiento en software de código cerrado únicamente se realiza en el caso que sea estrictamente necesario y, al realizarlo, necesitará una replanificación.
En código abierto, el mantenimiento es contínuo.
\end{itemize}

{\bf ¿Qué beneficios obtenemos de usar herramientas open source?}\\
Las herramientas open source son más adaptables a un problema concreto debido al acceso al código fuente.
Lanzan frecuentemente nuevas versiones con nuevas funcionalidades
que suelen ser fruto de las aportaciones de los usuarios para satisfacer sus propoias necesidades.
Además, si cesa la implicación de los desarrolladores originales en el proyecto,
otro usuario puede retomar el desarrollo de éste. 
Si el proyecto toma una direccion que no nos interesa, se puede hacer un fork,
es decir, crear un proyecto diferente basado en el mismo código.


{\bf ¿Qué beneficios da usar metodologías {\it Open Source} en un proyecto?}\\
El desarrollo ditribuido aporta métodos de comunicación entre desarrolladores
como {\it mailing list} o {\it IRC}.
También aporta herramientas que permiten el desarrollo concurrente ({\it CVS} o {\it Subversion}). 

% 	- rbg: Seguimiento de gestión de bugs
La gestión de bugtracking consta de una lista en la que se indican todos los bugs notificados hasta el momento.
Al identificar un bug, se realiza un seguimiento de su estado hasta que éste desaparezca.
Todos los usuarios tienen la posibilidad de proponer soluciones o
realizar modificaciones en el código para eliminar el bug.
El beneficio del bugtracking es implicar a todos los desarrolladores en la búsqueda de soluciones
y así poder erradicar el bug con mayor rapidez.

% 	- rbg: gestión de tareas. (en tradicional está el project)
Tanto el desarrollo {\it Open Source} como el tradicional tienen herramientas de gestión de tareas.
La diferencia es la flexibilidad a la hora de repartir dichas tareas.
Mientras en las metodologías tradicionales cada participante del proyecto tiene asignada una o varias tareas definidas desde la planificación,
con {\it Open source} las tareas se adjudican cuando se van a realizar y el desarrollador adjudicado puede aceptarla o traspasarla
o bien puede realizarla sin esperar a que se le adjudique.
La libertad de adjudicación de tareas permite que cada desarrollador programe lo que realmente le interesa y la motivación causa beneficios directos al resultado final.

% 	- rbg: gestión de soporte a usuarios.
En {\it Open Source} la línea de soporte existente en metodologías tradicionales cambia por
{\it mailing lists} y {\it ticketing}.
Una {\it mailing list} notifica todos los mensajes enviados a todos los integrantes mediante correo electrónico.
El {\it ticketing} es una duplicación de la lista de bugtracking.
Con {\it ticketing}, el usuario envía su problema, éste queda notificado en un listado y no se borrará hasta que quede eliminado.
el beneficio es que el problema notificado puede ser común en otros usuarios y su tratamiento favorecerá a todos ellos.
los responsables del proyecto han de vigilar que ninguna duda o incidencia quede sin respuesta satisfactoria.
Con lo cual, En el caso que nadie contestar, serían ellos mismos los que atenderían a la duda expuesta.


{\bf ¿Qué beneficios da tener una comunidad open source alrededor de un proyecto?}\\
El código creado está a disposición de todo el mundo interesado,
lo que hace que sea revisado cointínuamente.
en el caso que haya identificado un bug, 
los integrantes de la comunidad pondrán en común sus ideas para solucionar el problema
o bien desarrollarán nuevas funciones.
Ambos medios ayudan al mantenimiento del código y a la ampliación de funcionalidades.


{\bf Qué beneficios da liberar el software?} \\
Como hemos comentado con anterioridad, Al tener el código fuente disponible, atraerá desarrolladores interesados en el software
lo que conlleva a que el código sea revisado contínuamente
favoreciendo el control de bugs
y la incorporación de nuevas ideas de desarrollo.
Además, el hecho de ser libre atraerá usuarios que no se fijarían en el software en el caso de no ser libre.

La decisión de realizar un software libre vino dada por los clientes, los cuales usan y desarrollan software libre y pidieron que el producto presentado en el proyecto se adecuara a sus necesidades.
Al desarrollar el producto siguiendo estas premisas, podré disfrutar de los beneficios comentados anteriormente.


