Código libre por pragmatismo

Open source, Código libre…

Ya hace tiempo que programo en java. Una de las cosas que más me gusta es la cantidad de utilidades que hay hechas para el desarrollo. Esto permite crear aplicaciones muy potentes minimizando el esfuerzo.

Entre las utilidades, librerias, etc. que se pueden utilizar tenemos dos grandes grupos, las de código libre y las otras.

Hace tiempo trabajé en un laboratorio de software en el que desarrollábamos librerías java de gestión. Dentro de nuestras responsabilidades entraba diseño y programación de componentes, test, documentación, mantenimiento y soporte.

De lo anterior me encantaba el soporte en cliente, sobre todo visto desde mi posición actual.

La situación común era llegar allí en un ambiente complicado. El cliente te esperaba con una mezcla de esperanza y enfado, enfado porque se habían gastado un dinero en software que no les iba bien(ya fuera por desconocimiento de uso o por fallo del producto) y esperanza porque pensaban que lo ibas a arreglar todo.

Al llegar allí y ver la situación la forma de encontrar la solución acostumbraba a ser siempre la misma, depurar el código. Que obvio. ¿Sí?¿De verdad es tan obvio?

Nosotros no entregábamos los fuentes con nuestro producto, de hecho en un principio ni siquiera compilabamos los fuentes con información de debug. Esto hacía que cada vez que algún cliente tenía un problema no supiese si era error suyo al utilizar las librerías, bug del producto o problemas de entorno y cuando quería depurar encontraba una caja negra de la cual no era capaz de extraer ninguna información. En ese momento nos llamaban.

Al depurar su aplicación yo sí llevaba los fuentes. La caja negra se convertía en blanca, más todavía por ser una caja blanca hecha por uno mismo, y al poco tiempo el error se solucionaba. No siempre era error del software, la mayoría de veces era por mal uso de este, pero ese mal uso se identificaba de forma clara al depurar accediendo al fuente.

Así, después de semanas o meses con esa pega, se solucionaba en un par de días de soporte on-site. Estoy seguro que, de tener ellos el código fuente, podrían haber solucionado su problema en esas semanas de discusión con los diversos niveles de soporte.

Hace unos meses me pasó algo parecido pero desde el otro lado. Compramos una librería C para integrarla via JNI.

En poco tiempo localicé un par de errores y me puse a montar los test para verificar que eran errores de librería y no de uso, contacté con soporte, me enviaron preguntas, envié respuestas, me enviaron código, encontré errores, etc…

Al final, después de un par de semanas de correos cruzados, conseguí integrar asumiendo algún error que se quedó ahí pero evitandolo con programación cliente.

Estoy completamente convencido qué de haber tenido el código fuente hubiera arreglado todo en la mitad del tiempo y habiendo adquirido además los conocimientos para manejar un futuro error. No olvidemos que si falla algo en producción y hay que contar con soporte de terceros dependes del tiempo que estos terceros tengan para dedicarte. No esperes mucha colaboración si tu proyecto no es estratégico y tienen a toda su gente ocupada.

La conclusión después de todo este texto es: dadas dos librerías a utilizar, una de código libre(aunque no sea gratis) y otra no, sale más rentable a la larga utilizar la libre, aunque a priori sea de peor calidad que la otra. Además la podrás utilizar para que se ajuste exactamente a tus fines.

Etiquetas: aplicaciones, código libre, desarrollo, opensource, software, terceras partes, third party