Desarrollo de software de código abierto

De Wikipedia, la enciclopedia libre
Ir a la navegación Ir a la búsqueda

Desarrollo del software de código abierto es el proceso por el que se desarrolla el software de código abierto, o de manera similar aquel software cuyo código fuente está disponible de manera pública. Estos son productos de software disponibles con su código fuente bajo una licencia de código abierto que permite estudiar, cambiar y mejorar el diseño de estos programas. Ejemplos de algunos productos populares de software de código abierto son Mozilla Firefox, Google Chromium, Android, LibreOffice y el paquete de oficina Apache OpenOffice Suite. El desarrollo de software de código abierto ha sido una gran parte de la creación de la World Wide Web tal y como la conocemos, con Tim Berners-Lee contribuyendo con su desarrollo de código HTML como la plataforma originaria sobre la que Internet se construye ahora.[1]

Historia[editar]

En 1997, Eric S. Raymond escribió la Catedral y el Bazar. En este libro Raymond [2]​ hace la distinción entre dos tipos de desarrollo de software. El primero es el desarrollo convencional de software de código cerrado. Este tipo de desarrollo de métodos de desarrollo es, de acuerdo con Raymond, como construir una catedral; planificación centralizada organización fija y un proceso desde el comienzo hasta el final. La segunda es el desarrollo del código abierto progresivo, que es más como un gran bazar caótico con gente con muchas agendas diferentes y se acerca a lo que uno entendería por un emergente coherente y estable que solo podría ser posible a través de una sucesión de milagros. Esta analogía se refiere a la discusión que tiene lugar en un proceso de desarrollo de código abierto.

Las diferencias entre los dos estilos de desarrollo, de acuerdo con Bar & Fogel, son en general el manejo y creación de reportes de errores y peticiones de características y las restricciones bajo las cuales los programadores trabajan. En el desarrollo de software de código cerrado, los programadores a menudo gastan mucho tiempo lidiando con informes de errores y creándolos, así como manejando peticiones de nuevas características. Este tiempo se gasta en crear y priorizar desarrollo a más largo plazo. Esto lleva a que parte del equipo de desarrollo gaste mucho tiempo en estas tareas, y no en el desarrollo real del programa. También en los proyectos de código cerrado, los equipos de desarrollo deben a menudo trabajar bajo restricciones relacionadas con la administración (como fechas límites presupuesto etc.) que interfieren con los temas técnicos del software. En el software de código abierto estos problemas se resuelven integrando a los usuarios sobre el proceso de desarrollo, incluso permitiendo que los usuarios construyan el sistema por ellos mismos.

Modelo de desarrollo de software de código abierto[editar]

Modelo de Datos-Proceso para el desarrollo de código abierto

El software de código abierto se puede dividir en varias fases. Las fases especificadas aquí se derivan de Sharma et al. Sharma [3]​ se muestra un diagrama estructura de procesos y datos del desarrollo de código abierto a la derecha. En esta imagen las fases del desarrollo de software de código abierto se pueden ver junto con los datos correspondientes. Este diagrama está hecho usando técnicas de Metamodelado y de Meta-proceso de modelado.

Empezando un proyecto de código abierto[editar]

Hay varias maneras por las cuales un proyecto de código abierto puede empezar:

  1. Por una persona que siente la necesidad de realizar un proyecto y proclama su intención de desarrollar ese proyecto en público.
  2. Por un desarrollador trabajando en una pequeña Base de código, que la libera al público como la primera versión de un programa de código abierto.
  3. El código fuente de un proyecto maduro se libera al público.
  4. Puede que una organización externa interesada en un proyecto de código abierto bien establecido realice una Bifurcación.

Raymond decía en su ensayo The Cathedral and the Bazaar que solo anunciar el intento de un proyecto es peor que liberar proyecto en el que ya se está trabajando al público.

Es un error común empezar un proyecto cuando uno podría contribuir a un proyecto ya existente que es muy similar.(NIH syndrome) Para empezar un proyecto de éxito es muy importante investigar qué es lo que ya hay ahí fuera. El proceso comienza con la elección entre adoptar un proyecto existente, o empezar un nuevo proyecto. Si un nuevo proyecto comienza, el proceso para la fase de iniciación. Si un proyecto existente se adopta, el proceso va directamente a la fase de ejecución.

Tipos de proyectos de código abierto[editar]

Existen varios tipos de proyectos de código abierto. En primer lugar, hay una gran variedad de programas de software y librerías que consisten en piezas independientes de código. Algunos podrían incluso ser dependientes entre otros proyectos de código abierto. Estos proyectos sirven para un propósito específico y satisfacen una necesidad definida. Ejemplos de este tipo de proyectos incluyen el Núcleo Linux, el explorador de Internet Firefox y las herramientas de oficina OpenOffice Apache. Las distribuciones son otro tipo de proyecto de código abierto. Las distribuciones son colecciones de software que se publican desde la misma fuente y con un propósito común. El ejemplo más prominente de una distribución es un sistema operativo. Hay muchas distribuciones de GNU/Linux (como Debian, Fedora Core, Mandriva, Slackware, Ubuntu, etc) que lanzan el núcleo Linux junto con muchos componentes de usuarios. Existen otras distribuciones como ActivePerl, el lenguaje de programación para varios sistemas operativos, y las distribuciones Cygwin de programas de código abierto para Microsoft Windows. Otros proyectos de código abierto, como los derivados BSD, mantienen el código abierto de un sistema operativo entero, el kernel y todos sus componentes base, en un sistema de control de versiones, desarrollando el sistema entero junto con un solo equipo. Estos proyectos de desarrollo de sistemas operativos integran sus herramientas, más que en ningún otro sistema basado en distribuciones.

Finalmente, se hace un libro o documentación de proyecto independiente. Estos objetos normalmente no se dan como parte del paquete de software de código abierto. La documentación del proyecto de Linux mantiene muchos de tales proyectos que documentan varios aspectos del sistema operativo GNU/Linux. Hay muchos otros ejemplos de este tipo en los proyectos de código abierto.

Métodos de desarrollo del software de código abierto[editar]

Es difícil llevar un proyecto de código abierto siguiendo un método de desarrollo de software más tradicional como el modelo en cascada, porque en estos métodos tradicionales no se permite volver atrás a una fase anterior. En el desarrollo de software de código abierto, los requisitos raramente se reúnen antes de empezar el proyecto, en vez de eso estos se basan versiones previas de productos de software, como describe Robbins .[4]​ Más allá de los requisitos, personal voluntario a menudo se ve atraído para ayudar a desarrollar el producto de software basado en las versiones anteriores del software. Este efecto de red es esencial de acuerdo con Abrahamsson et al.:" si el prototipo reúne suficiente atención, gradualmente empezará a atraer a más y más desarrolladores" Abrahamsson et al también apunta que la comunidad es muy dura, tanto como en el mundo empresarial del software de código cerrado: "si encuentras cliente sobrevives, pero sin ellos mueres". [5]

Alfonso Fuggetta menciona que el desarrollo de prototipado rápido, incremental y evolutivo, con el ciclo de vida en espiral, el desarrollo de aplicación rápida, y recientemente, con la programación extrema y el proceso de software ágil pueden ser aplicados igualmente al código propietario y el código abierto. Un método de desarrollo de código abierto mencionado por Fuggetta [6]​ es un método ágil llamado Programación extrema. Todos los métodos ágiles son en esencia aplicables al desarrollo de software de código abierto debido a su carácter iterativo e incremental. Otro método ágil es Internet-Speed Development, también es adecuado para el desarrollo de software de código abierto en particular debido al principio de desarrollo distribuido que adopta. Internet-Speed Development lo usan equipos distribuidos geográficamente alrededor de todo el globo. Este método es mayoritariamente adoptado por grandes compañías de código cerrado como Microsoft, porque solo estas grandes compañías son capaces de crear un centros de desarrollo distribuido en zonas horarias diferentes. Por supuesto si el software se desarrolla por un grupo grande de voluntarios en diferentes países, esto se alcanza de manera natural y sin el apoyo necesario que necesita el desarrollo de software de código cerrado.

Herramientas usadas para el desarrollo de código abierto[editar]

Canal de comunicación[editar]

Desarrolladores y usuarios de un proyecto de código abierto no están todos necesariamente trabajando en el proyecto y están pŕoximos geográficamente. Se necesitan algunos medios electrónicos de comunicaciones. El correo electrónico es una de las formas más comunes de comunicación entre los desarrolladores de código abierto y entre los usuarios. A menudo se usan listas de correo electrónico para asegurarse de que los mensajes de correo electrónico se envían a todas las organizaciones interesadas a la vez. Esto asegura que al menos uno de los miembros puede responder al correo electrónico. Para comunicarse a tiempo real, muchos proyectos usan métodos de mensajería instantánea como el IRC. Los foros web recientemente se han vuelto un medio común para los usuarios para conseguir ayuda con problemas que ellos encuentran cuando usan un proyecto de código abierto. Las wikis se ha vuelto un medio de comunicación amplio tanto para desarrolladores como para usuarios.

Sistemas de control de versiones[editar]

En el desarrollo OSS los participantes, que son en su mayoría voluntarios, se distribuyen entre distintas nln.geográficas de tal manera que se necesitan herramientas para ayudar a los participantes a colaborar en el desarrollo del código fuente. Durante el comienzo de los años 2000 Concurrent Versions System (CVS) fue un ejemplo de herramienta de colaboración de código fuente que se usó en los proyectos OSS. CVS ayuda a administrar los ficheros y el código de un proyecto cuando varias personas están trabajando en el proyecto al mismo tiempo. CVS permite a varias personas trabajan en el mismo fichero a la vez. Esto se hace moviendo el fichero a los directorios de los usuarios y mezclando los archivos cuando los usuarios han acabado. CVS también permite a uno recuperar fácilmente una versión previa del archivo. Durante la mitad de la década de los 2000 el sistema de control de revisiones de subversión SVN se creó para reemplazar al CVS. Está ganando terreno rápidamente como el sistema de control de versiones de un proyecto OSS.

Muchas partes de código abierto ahora están usando sistemas de control de versiones distribuidas, que se escalan mejor que los sistemas centralizados como SVN y CVS. Ejemplos populares son Git, usado por el núcleo Linux, y Mercurial, usado por el lenguaje de programación Python.

Sistemas de seguimiento de errores y listas de tareas[editar]

La mayoría de los proyectos de la gran escala requieren un sistema de seguimiento de errores para mantener un seguimiento del estado de parios problemas en el desarrollo del proyecto. Algunos sistemas de seguimiento de errores incluyen

  • Bugzilla – un sistema sofisticado basado en web de Mozilla.
  • Mantis Bug Tracker – una sistema de seguimiento basado en para PHP/MySQL.
  • Trac – iuna interfaz al SVN.
  • Redmine – escrito en Ruby, integra seguimiento de errores, wiki, foro, novedades, Planificación de proyectos de Gantt e interfaces con directorio de usuario LDAP.
  • Request tracker – escrito en Perl. Dado por defecto en los módulos CPAN – ver rt.cpan.org.
  • SourceForge y sus bifurcaciones proveen de un sistema de seguimiento como parte de sus servicios. Muchos proyectos usan SourceForge.net y servicios similares por este motivo.
  • LibreSource
  • JIRA – Administración de proyecto de Atlassian y herramienta de seguimiento de errores.

Herramientas de testing y depuración[editar]

Desde que los proyectos OSS se someten a integración frecuente, se usan herramientas que ayudan a automatizar el testing durante la integración de sistemas. Un ejemplo de esta herramienta es un Tinderbox. Tinderbox habilita a los participantes en un proyecto OSS a detectar errores durante la integración del sistema. Ejecuta un proceso de construcción continua e informa a los usuarios sobre las partes del código fuente que tienen problemas y en qué plataformas surgen estos problemas. Un depurador es un programa de ordenador que se usa para depurar y algunas veces para testear y optimizar otros programas. El depurador GNU Debugger (GDB) es un ejemplo de un depurador usado en el desarrollo de software de código abierto. Este programa ofrece depuración remota, lo que lo hace especialmente aplicable al desarrollo de software de código abierto.

Una herramienta de filtración de memoria o depuradora de memoria es una herramienta de programación para encontrar filtraciones de memoria o buffer overflows. Una filtración de memoria es un tipo particular de consumición de memoria innecesario por un programa de ordenador, donde el programa falla al liberar memoria que ya no se necesita. Ejemplos de herramientas de detección de filtraciones de memoria usadas por Mozilla son las herrmientas de filtrado de memoria XPCOM. Las herramienta de validación se usan para comprobar si las piezas de código conforman la sintaxis especificada. Un ejemplo de una herramienta de validación es Splint.

Administración de paquetes[editar]

Un Sistema de gestión de paquetes es una colección de herramientas para automatizar el proceso de instalar, actualizar, configurar, y eliminar paquetes de software desde un ordenador. El administrador de paquetes de Red Hat para .rpm y la herramienta de paquetes avanzada APT para formatos de archivos .deb, son sistemas de administración de paquetes usados por un gran número de distribuciones de Linux.

Refactorizacion y reescritura de código[editar]

Los desarrollos de código abierto a veces sienten que su código requiere una refactorización. Esto puede ser porque el código se escribió o se mantenía sin una refactorización adecuada, como suele ser habitual en el caso en el que el código es heredado de un desarrollador previo, o porque una propuesta de mejora o extensión de ella no pudo ser limpiamente implementada sobre la base de código existente. Otra razón para reescribir el código correcto actualizar el código es que el código no se ajuste a los estándar del desarrollador.

Véase también[editar]

Referencias[editar]

  1. Raymond. The Cathedral & the Bazaar. Raymond, E.S. (1999). The Cathedral & the Bazaar. O'Reilly Retrieved from http://www.catb.org/~esr/writings/cathedral-bazaar/. See also: The Cathedral and the Bazaar.
  2. Barfogel. Open Source Development with CVS. Bar, M. & Fogel, K. (2003). Open Source Development with CVS, 3rd Edition. Paraglyph Press. (ISBN 1-932111-81-6)
  3. Sharma. A framework for creating hybrid-open source software communities. Sharma, S., Sugumaran, V. & Rajagopalan, B. (2002). A framework for creating hybrid-open source software communities. Information Systems Journal 12 (1), 7 – 25.
  4. Robbins. Making Sense of the Bazaar: Perspectives on Open Source and Free Software. Robbins, J. E. (2003). Adopting Open Source Software Engineering (OSSE) Practices by Adopting OSSE Tools. Making Sense of the Bazaar: Perspectives on Open Source and Free Software, Fall 2003.
  5. Abrahamsson, P, Salo, O. & Warsta, J. (2002). Agile software development methods: Review and Analysis. VTT Publications.
  6. Fuggetta. Open source software – an evaluation. Fuggetta, A. (2003). Open source software – an evaluation, Journal of Systems and Software, 66, 77 – 90.
  7. Mockus. Two case studies of open source software development: Apache and mozilla. Mockus, A., Fielding, R. & Herbsleb, J. (2002). Two case studies of open source software development: Apache and mozilla, ACM Transactions on Software Engineering and Methodology 11 (3), 1 – 38.
  1. «Tim Berners-Lee on the Web at 25: the past, present and future». Wired UK. 
  2. Raymond. The Cathedral & the Bazaar. 
  3. Sharma. A framework for creating hybrid-open source software communities. 
  4. Robbins. Making Sense of the Bazaar: Perspectives on Open Source and Free Software. 
  5. Abrahamsson. Agile software development methods: Review and Analysis. 
  6. Fuggetta. Open source software – an evaluation. 

Enlaces externos[editar]