En este comentario, 9 de cada 10 melenas recomiendan el uso de Tinydns como sustituto de BIND. En las páginas de Dan Bernstein, autor de djbdns, hay muchísimas críticas a ISC y Nominum, ambas empresas de BIND Company, sobre sus productos y su forma de desarrollo (además de múltiples quejas sobre los protocolos de DNS.
Esto me ha traído a la memoria otros proyectos de código abierto con los que he tenido contacto (en este caso profesional) que no funcionan todo lo bien que deberían. ¿Qué es lo que falla?
Caso número 1: Apache Axis (o el cabo del ovillo)
Apache Axis es una librería de servicios web, que reemplaza totalmente a la antigua Apache SOAP. En este contexto, los servicios web son un método de llamada a procedimientos remotos a través de HTTP.
Para mi eterno desasosiego, tuve que extender la librería: necesitaba algunas funcionalidades que no estaban soportadas. Un vistazo al código es peor que una pesadilla con Freddy Krueger: una arquitectura de locos, clases de 2700 líneas, con métodos de 700 líneas, estándares a medio implementar, funcionalidad duplicada... Es el perfecto contraejemplo de programación orientada a objetos (para cualquier mala práctica se pueden encontrar varios casos). ¿Que quieres encontrar un ejemplo de antipatrón blob?, nada más fácil: una clase que aglutina información no relacionada.
Siguiendo el consejo de colaborar antes de quejarse, he contribuido dos parches a Axis. El primero era bastante primitivo, con mi extensión. Recibí un timeout. Tras mucho dar la vara, me contaron que estaban muy ocupados con la release 1.0. Tiempo después, me encontré con que el rendimiento es penoso (unas 3 peticiones por segundo). Envié un parche para corregirlo (y llegar a 80 peticiones por segundo), y de paso reestructurar un poco el lío.
Esta vez me explicaron el proceso correcto, que incluye ejecutar las pruebas automáticas. Pues bien, una de las pruebas automáticas explícitamente prohíbe la refactorización que yo había hecho, al manipular un mensaje tras su creación. Es decir, que no se puede desenredar la madeja. (Si os molestáis en echar un vistazo a mi particular bestia parda, veréis que es una gran madeja.)
Mi problema personal no es grave, por supuesto. Que un diseño y un código tan malos hayan pasado las revisiones sí. Si nos fijamos en la lista de desarrolladores, no hay casi voluntarios; los más activos son bien de IBM, bien de MacroMedia. Sus empresas les pagan por estar ahí (hay gente con suerte), y no parece que estén muy familiarizados con el proceso de desarrollo libre.
Caso número 2: Tomcat 3.3 (ramificaciones inesperadas)
Tomcat es la implementación estándar de la especificación de servlets, y una de las aplicaciones estrella de Jakarta. Tras salir la versión 3.2, y mientras la versión 4 maduraba (completamente rediseñada para cumplir la nueva especificación de servlets), unos cuantos desarrolladores rebeldes se negaron a trabajar en ella; en su lugar, se empeñaron en refactorizar la versión existente y sacar la versión 3.3. Es lo que se conoce como una bifurcación (fork) del código: cuando a uno no le gusta la dirección que está tomando un proyecto, se va con el código a otra rama.
Las implicaciones para Sun Microsystems eran bastante negativas. No sólo la versión 4 de Tomcat tardaría más en salir, sino que su público podría optar por quedarse anclado en la antigua especificación. (Conviene señalar que los principales desarrolladores de Tomcat, en particular los dos antagonistas de este drama, trabajan para Sun; y además como animales.) De forma que se empezaron a notar presiones "bajo cuerda" dentro de Sun para que se abandonara la versión 3.3.
Para no alargarnos demasiado, unos diez mil mensajes después salió la versión 3.3 (casi al mismo tiempo que la 4), con lo cual nos dieron un poco de cuartelillo a los que no queríamos tragarnos la nueva especificación.
Caso número 3: JBoss (o la extorsión de los ultracuerpos)
La Fundación Apache está en proceso de creación de su propia implementación de J2EE, Geronimo. Por supuesto, en competencia directa con JBoss. Desde Sun Microsystems, responsables de la certificación J2EE, prometen que permitirán su certificación por un precio reducido, cosa que la empresa responsable de JBoss lleva pidiendo varios años.
De repente, Bill Burke de JBoss acusa a la fundación de copiar su código en Geronimo:
Como desarrollador de código abierto, elijo distribuir mi código bajo la licencia LGPL porque así me aseguro de que seguirá siendo abierto, y al mismo tiempo la licencia es lo bastante flexible como para incorporarla a otro código. Cuando me enteré de la existencia de Geronimo, le eché un vistazo a la distribución por curiosidad, y me encontré de que mi código y algunas derivaciones estaban siendo distribuidos bajo la licencia ASL.
Como en cualquier otro proyecto de código abierto, la copia no autorizada de código se toma bastante en serio en Apache; la mera mención de acciones legales es el incentivo definitivo para cualquier desarrollador. Pero la acusación en este caso no era una inocente petición para reemplazar el código en cuestión; pocos mensajes después, nos enterábamos en general@jakarta del motivo del revuelo cortesía de Vic Cekvenich.
He estado pensándolo, y no creo que eliminar el código en litigio sea apropiado ni suficiente.
Si se demuestra, [...] el proyecto debería ser retirado. Que viva en SourceForge, por qué defenderlo (de otra manera la ASF tiene que usar sus abogados / recursos)
La Fundación Apache debería pedir disculpas en público, y como signo de amistad hacia el código abierto, hacer algo para ayudar a jBoss, como ayudar con la certificación J2EE, o con el código o algo.
Es decir, el grupo JBoss quiere quitarse la competencia de encima, y además pide la ayuda del grupo Apache para conseguir una certificación a bajo precio; a cambio de "olvidar el incidente". Esto, en mi librillo de maestrillo, es una extorsión a todas luces.
Si seguís el hilo de la discusión, la supuesta copia parece no tener una base muy sólida. Se basa en métodos tan complejos como getVariable() { return variable; }, y en código a su vez copiado de proyectos de Apache como log4j. Pero el daño ya estaba hecho.
¿Conclusiones?
Los desarrolladores de software libre no son santos. Sobre todo cuando se pretende comer de lo que uno hace: parece que, en esta situación, la ética pasa a un segundo plano. El mundo ideal del ejército de voluntarios dispuestos a todo se va encontrando cada vez más con el infra-mundo de las tácticas empresariales barriobajeras. O, aún peor, con la inanidad del desarrollo en las grandes empresas.
El problema no está tanto en la calidad. Cualquiera que haya trabajado como desarrollador ha visto los desatinos que se suelen hacer colar como "productos". Las ventajas apabullantes del código abierto siguen valiendo: que tanto el proceso como su resultado están a la vista de todo el que quiera seguirlo. Por lo menos, no te pueden colar un truño como bueno, si te molestas en mirar el código fuente.
Pero hay un asunto más fundamental: el conflicto de intereses que viene de la mano del modelo de servicio abogado por luminarias del movimiento (no pagar por el software, sino por el soporte). Si una empresa lanza un programa libre perfecto (fácil de instalar, sin agujeros de seguridad, y con toda la funcionalidad necesaria) ¿quién necesita soporte técnico? Parecería que les trae más cuenta distribuir programas con errores, agujeros de seguridad, funcionalidad la justa, y documentación penosa, como podría ser el caso de BIND.
Un tercer problema son las empresas que se vuelven avariciosas, cambian las condiciones de juego y a veces pierden el norte, ejemplo nefario SCO. (Si tuviera mi traje de neopreno cerca, mencionaría cierto sombrero de cierto color.) Gracias a las licencias libres, no les resulta tan fácil decir "mi código es mío y me lo llevo", pero ¿puede una empresa secuestrar el propio proceso de desarrollo para sus propios fines?
Bueno, lo que más me interesa es oir vuestras opiniones, así que me callo ya.
