Diferencia entre revisiones de «La catedral y el bazar en Software libre»

De wiki EOI de documentación docente
Saltar a: navegación, buscar
(Página creada con «{{Sección |Título=La catedral y el bazar |Libro=Software libre |Capítulo=Ingeniería del software libre |Número sección=1 |Introducción=Aunque hace ya varias décadas...»)
 
 
Línea 28: Línea 28:
 
Para evitar que la publicación frecuente asuste a usuarios que prioricen la estabilidad sobre la rapidez con la que el software evoluciona, algunos proyectos de software libre cuentan con varias ramas de desarrollo en paralelo. El caso más conocido es el del núcleo Linux, que tiene una rama estable -dirigida a aquellas personas que estiman su fiabilidad- y otra inestable -pensada para desarrolladores- con las últimas innovaciones y novedades.
 
Para evitar que la publicación frecuente asuste a usuarios que prioricen la estabilidad sobre la rapidez con la que el software evoluciona, algunos proyectos de software libre cuentan con varias ramas de desarrollo en paralelo. El caso más conocido es el del núcleo Linux, que tiene una rama estable -dirigida a aquellas personas que estiman su fiabilidad- y otra inestable -pensada para desarrolladores- con las últimas innovaciones y novedades.
 
|Apartados=
 
|Apartados=
|Estado=esbozo
+
|Estado=completo
 
}}
 
}}
 
{{Prueba
 
{{Prueba
|Prueba=f
+
|Prueba=No
 
}}
 
}}

Revisión actual del 17:42 23 may 2012


Estado de desarrollo de la sección: completo completo

Wikilibro: Software libre > Capítulo 6: Ingeniería del software libre

Sección 1

La catedral y el bazar
Aunque hace ya varias décadas que se desarrolla software libre, sólo desde hace unos pocos años se ha empezado a prestar atención a sus modelos y procesos de desarrollo desde el punto de vista de la ingeniería del software. Igual que no hay un único modelo de desarrollo de software propietario, tampoco lo hay en el mundo del software libre [5], pero aún así pueden encontrarse interesantes características que comparten gran parte de los proyectos estudiados, y que podrían estar enraizadas en las propiedades de los programas libres.

En 1997 Eric S. Raymond publicó el primer artículo ampliamente difundido, La catedral y el bazar [raymond:cathedral-bazaar], en el que se trataba de describir algunas características de los modelos de desarrollo de software libre, haciendo especial énfasis en lo que diferencia estos modelos de los de desarrollo propietario. Este artículo se ha convertido desde entonces en uno de los más conocidos (y criticados) del mundo del software libre, y hasta cierto punto, en la señal de comienzo para el desarrollo de la ingeniería del software libre.

Raymond establece una analogía entre la forma de construir las catedrales medievales y la manera clásica de producir software. Argumenta que en ambos casos existe una clara distribución de tareas y roles, destacando la existencia de un diseñador que está por encima de todo y que ha de controlar en todo momento el desarrollo de la actividad. Asimismo, la planificación está estrictamente controlada, dando lugar a unos procesos claramente detallados en los que idealmente cada participante en la actividad tiene un rol específico muy delimitado.

Dentro de lo que Raymond toma como el modelo de creación de catedrales no sólo tienen cabida los procesos pesados que podemos encontrar en la industria del software (el modelo en cascada clásico, las diferentes vertientes del Rational Unified Process, etc.), sino que también entran en él proyectos de software libre, como es el caso de GNU y NetBSD. Para Raymond, estos proyectos se encuentran fuertemente centralizados, ya que unas pocas personas son las que realizan el diseño e implementación del software. Las tareas que desempeñan estas personas, así como sus roles están perfectamente definidos y alguien que quisiera entrar a formar parte del equipo de desarrollo necesitaría que se le asignara una tarea y un rol según las necesidades del proyecto. Por otra parte, las entregas de este tipo de programas se encuentran espaciadas en el tiempo siguiendo una planificación bastante estricta. Esto supone tener pocas entregas del software y ciclos entre las entregas largos y que constan de varias etapas.

El modelo antagónico al de la catedral es el bazar. Según Raymond, algunos de los programas de software libre, en especial el núcleo Linux, se han desarrollado siguiendo un esquema similar al de un bazar oriental. En un bazar no existe una máxima autoridad que controle los procesos que se están desarrollando ni que planifique estrictamente lo que ha de suceder. Por otro lado, los roles de los participantes pueden cambiar de manera continua (los vendedores pueden pasar a ser clientes) y sin indicación externa.

Pero lo más novedoso de La Catedral y el Bazar es la descripción del proceso que ha hecho de Linux un éxito dentro del mundo del software libre; es una sucesión de buenas maneras para aprovechar al máximo las posibilidades que ofrece la disponibilidad de código fuente y la interactividad mediante el uso de sistemas y herramientas telemáticas.

Un proyecto de software libre suele surgir a raíz de una acción puramente personal; la causa se ha de buscar en un desarrollador que vea limitada su capacidad de resolver un problema. El desarrollador ha de tener los conocimientos necesarios para, por lo menos, empezar a resolverlo. Una vez que haya conseguido tener algo usable, con algo de funcionalidad, sencillo y, a ser posible, bien diseñado o escrito, lo mejor que puede hacer es compartir esa solución con la comunidad del software libre. Es lo que se denomina la publicación prontía (release early en inglés) y que permite llamar la atención de otras personas (generalmente desarrolladores) que tengan el mismo problema y que puedan estar interesados en la solución.

Uno de los principios básicos de este modelo de desarrollo es considerar a los usuarios como codesarrolladores. Ha de tratárseles con mimo, no sólo porque pueden proporcionar publicidad mediante el boca a boca, sino también por el hecho de que realizarán una de las tareas más costosas que existe en la generación de software: las pruebas. Al contrario que el codesarrollo, que es difícilmente escalable, la depuración y las pruebas tienen la propiedad de ser altamente paralelizables. El usuario será el que tome el software y lo pruebe en su máquina bajo unas condiciones específicas (una arquitectura, unas herramientas, etc.), una tarea que multiplicada por un gran número de arquitecturas y entornos supondría un gran esfuerzo para el equipo de desarrollo.

Si se trata a los usuarios como desarrolladores puede darse el caso de que alguno de ellos encuentre un error y lo solucione, enviando un parche al desarrollador del proyecto para que el problema esté solucionado en la siguiente versión. También puede suceder, por ejemplo, que una persona diferente al que descubra un error sea la que finalmente lo entienda y corrija. En cualquier caso, todas estas circunstancias son muy provechosas para el desarrollo del software, por lo que es muy beneficioso entrar en una dinámica de esta índole.

Esta situación se torna más efectiva con entregas frecuentes, ya que la motivación para encontrar, notificar y corregir errores es alta debido a que se supone que va ser atendido inmediatamente. Además, se consiguen ventajas secundarias, como el hecho de que al integrar frecuentemente -idealmente una o más veces al día- no haga falta una última fase de integración de los módulos que componen el programa. Esto se ha denominado publicación frecuente (en la terminología anglosajona se conoce como release often) y posibilita una gran modularidad [narduzzo:modularity:03] a la vez que maximiza el efecto propagandístico que tiene publicar una nueva versión del software.

Nota: La gestión de nuevas versiones depende lógicamente del tamaño del proyecto, ya que la problemática a la que hay que enfrentarse no es igual cuando el equipo de desarrollo tiene dos componentes a cuando son cientos. Mientras en los proyectos pequeños en general este proceso es más bien informal, la gestión de entregas en los proyectos grandes suele seguir un proceso definido no exento de cierta complejidad. Existe un artículo titulado Release Management Within Open Source Projects [ehrenkrantz03:release] que describe detalladamente la secuencia que se sigue en el servidor web Apache, el núcleo del sistema operativo Linux y el sistema de versiones Subversion.
Para evitar que la publicación frecuente asuste a usuarios que prioricen la estabilidad sobre la rapidez con la que el software evoluciona, algunos proyectos de software libre cuentan con varias ramas de desarrollo en paralelo. El caso más conocido es el del núcleo Linux, que tiene una rama estable -dirigida a aquellas personas que estiman su fiabilidad- y otra inestable -pensada para desarrolladores- con las últimas innovaciones y novedades.

Sección siguiente >
Liderazgo y toma de decisiones en el bazar