Ver el código fuente de «Problemas en el desarrollo de Software Libre»

De Grupo GNU/Linux de la Universidad del Cauca

← Problemas en el desarrollo de Software Libre

No tienes permiso para modificar esta página, por el siguiente motivo:

---

Puedes ver y copiar el código fuente de esta página:

'''Agosto 25 de 2.004''' '''Por [[Usuario:Ceronman|Manuel Alejandro Cerón Estrada]]'''. ---- En este artículo voy a mencionar algunos de los que, pienso, son problemas que entorpecen un procesos óptimo de desarrollo de software libre y para plataformas libres. Estos han hecho que la adopción del software libre por parte de los usuarios y los desarrolladores sea lenta. Afortunadamente existen proyectos que buscan brindar una solución para estos problemas. == Poca reutilización de código. == Como lo dice Miguel de Icaza en su artículo [http://primates.ximian.com/%7Emiguel/bongo-bong.html “Let's Make Unix Not Suck”], los proyectos libres más importantes prácticamente no comparten nada de código entre si. Proyectos como [http://www.apache.org Apache], [http://www.sendmail.org Sendmail], [http://www.samba.org Samba], [http://www.bind.com Bind], escasamente comparten las funciones básicas de la librería [http://www.gnu.org/software/libc/libc.html glibc]. Se está repitiendo mucho trabajo en diseño, codificación y depuración. Todo ese trabajo repetido podría utilizarse en nuevas y mejores características si dichos proyectos compartieran componentes en común. Otro ejemplo de proyectos repitiendo el mismo trabajo una y otra vez, es el de los entornos de escritorio para GNU/Linux: [http://www.gnome.org Gnome] y [http://www.kde.org KDE]. Los dos escritorios han estado duplicando funcionalidad en casi todos los aspectos del entorno operativo. Algunas iniciativas como la de [http://www.freedesktop.org FreeDesktop.org] están tratando de que ambos escritorio usen componentes en común, pero aún así, la cantidad de trabajo duplicado es enorme. ¿Alguien puede imaginarse como estarían estos dos proyectos en este momento, si hubieran reutilizado entre si lo que ya han hecho y el trabajo duplicado fuera invertido en mejoras y nuevas características? En mi opinión, si dentro del mundo del software libre no existiera la duplicación de trabajo, los proyectos avanzarían muchas veces más rápido que lo que avanzan actualmente, el modelo de desarrollo de software libre no tendría competencia. == La barrera del idioma. == Me refiero a los lenguajes de programación. En estos días, los proyectos de software libre limitan la participación de muchas personas debido al lenguaje de programación. Por ejemplo, si un grupo de desarrolladores deciden hacer una aplicación web en [http://www.perl.com/ Perl], entonces muchos programadores de [http://www.php.net PHP], o cualquier otro lenguaje de programación, que no sepan Perl, no van a poder colaborar fácilmente en el proyecto a menos que lo aprendan. ¿Que pasaría si en un mismo proyecto de software libre pudiera colaborar cualquier persona, sin importar el lenguaje de programación sepa usar? Otra situación donde la barrera del idioma causa estragos es el de las especializaciones de los lenguajes. Me refiero al hecho de que algunos lenguajes de programación se han especializado en un campo especifico y único. Por ejemplo, el lenguaje PHP es especializado para crear aplicaciones web, pero C no lo es. Esto tiene el problema de que si una persona es programador de C, probablemente no va a poder hacer, sin un esfuerzo grande, una aplicación Web; probablemente sea más fácil para él aprender PHP que desarrollar la aplicación con C. Aprender un nuevo lenguaje de programación es una tarea que lleva tiempo y esfuerzo. Una consecuencia de este problema es la aparición de librerías con cierta funcionalidad, que son especificas de un lenguaje determinado. Por ejemplo, existe una gran cantidad de funciones matemáticas avanzadas para el lenguaje FORTRAN, que, por supuesto, solo pueden se accedidas desde dicho lenguaje. Así que si alguien quisiera usar dicha funcionalidad, solo tiene la opción de aprender FORTRAN, lo cual, repito, conlleva tiempo y esfuerzo. Algunos proyectos de software libre han hecho grandes esfuerzos por lograr una cierta independencia del lenguaje de programación. El sistema [http://developer.gnome.org/arch/component/bonobo.html Bonobo] de la [http://www.gnome.org Plataforma de Desarrollo Gnome] es una de ellas. Sin embargo, estos aún no han logrado una buena independencia, y han creado trabajo extra para los desarrolladores de librerías y frameworks. == No existe una librería de funcionalidad unificada y homogénea. == Por lo general cuando se desarrolla software libre, no se encuentra la funcionalidad que uno necesita en un solo paquete, sino que todo viene esparcido en distintas librerías. Por ejemplo, si alguien quisiera realizar un juego, podría encontrar la funcionalidad más básica en la librería glibc, pero para realizar la interfaz gráfica de usuario (GUI) se necesita otra librería como [http://www.trolltech.com Qt]; para unos buenos gráficos, [http://www.mesa3d.org MESA] o [http://www.libsdl.org SDL]; para sonido 3D, [http://www.openal.org OpenAL]; para red [http://www.libsdl.net SDL NET]; y así sucesivamente. El resultado final es una aplicación con muchas dependencias. Cada librería es un proyecto individual que evoluciona de manera separada, a veces volviéndose incompatible con versiones anteriores. De otra parte, cada API tiene su estilo de codificación propio, y la aplicación general queda con una mezcolanza de estilos, se vuelve más difícil de mantener. Proyectos como la Plataforma de Desarrollo Gnome, han tratado de unificar un conjunto de funcionalidades para facilitarle la vida a los desarrolladores de software. Pero han caído en los problemas anteriores como la duplicación de esfuerzo y la barrera de los lenguajes de programación. == Portar es cada vez más difícil. == Construir aplicaciones que funcionen en distintos sistemas operativos y plataformas de hardware es cada vez más difícil. Especialmente porque las librerías que se requieren no están disponibles en todas las plataformas o son distintas para cada una. Esto ha llevado a que los grandes proyectos como [http://www.mozilla.org Mozilla] y [http://www.openoffice.org OpenOffice.org], tengan que duplicar esfuerzo, construyendo librerías propias con cierta funcionalidad y sin poder reutilizar lo que ya esta hecho, simplemente por que no es multiplataforma. Compilar a código nativo es un problema también, no solo por el hecho de que hay que construir una versión para cada sistema operativo y cada arquitectura de hardware, sino también por que una vez se obtiene el binario para una plataforma determinada, ya no hay manera de hacerlo funcionar en algo diferente. Por ejemplo, el plugin de Flash para Linux que saca [http://www.macromedia.com Macromedia], es un binario que solo funciona en arquitecturas x86, si se tiene por ejemplo, un Power PC, el plugin es completamente inútil. La primera solución al problema de la multipataforma llegó de la mano de [http://www.sun.com SUN Microsystems] con [http://java.sun.com Java] y su maquina virtual. Sin embargo, la mayoría de las implementaciones de Java son propietarias y su rendimiento no es el mejor. == La solución. == La solución a todos estos problemas, viene de la mano de de un proyecto que ha llamado mucho mi atención en las últimas semanas: [http://www.go-mono.org Mono], la implementación libre del framework de .NET. Es de este proyecto que pienso hablar en el artículo de la próxima semana... ---- ''El contenido del material publicado por nuestros columnistas es responsabilidad de sus autores.'' Para saber más sobre la programación y naturaleza de nuestros artículos y columnas, haga clic '''[[Artículos y Columnas|aquí]]'''. [[Categoría:Artículos y Columnas]]

Volver a Problemas en el desarrollo de Software Libre.