Software libre para lograr calidad

El desarrollo de sistemas complejos debe ser realizado con un pensamiento sistémico para lograr el éxito. Al igual que el cerebro humano, compuesto por millones de neuronas donde ninguna es indispensable sino que el sistema como un todo se adapta a la situaciones internas y externas (recuerdo haber escuchado del caso de una persona que vivía con medio cerebro), así se adapta un equipo de desarrollo de software libre: el conocimiento se gestiona y comparte de tal manera que ningún integrante es indispensable. Para su ejecución, estos tipos de proyectos se basan en la conformación de una comunidad de individuos que tienen a ese software como la intersección de sus intereses heterogéneos, y que lo enriquecen con sus visiones complementarias. En este esquema, nadie es el dueño de la verdad, ni siquiera el que coordina el proyecto; como máximo se tienen a los que sirven de catalizadores, que con sus ideas individuales inspiran al grupo y generan funcionalidades más completas que la idea original. En ese sentido, el grupo se autoregula para obtener el resultado más óptimo y simple que, primero, cumpla con el objetivo del programa, y segundo, satisfaga de la mejor manera los distintos intereses de los involucrados en su desarrollo. Creo que esto es lo que más dificulta de entender para las personas acostumbradas a los proyectos jerarquizados, necesidades estáticas y conceptos etiquetados: un proyecto de software libre puede subsistir en el tiempo y presentar resultados de calidad por el pensamiento sistémico implícito que surge, con el tiempo, en todo grupo humano lo suficientemente grande que es libre de autoregularse. Este tiempo depende del coordinador, de su pericia en ser un catalizador de preguntas más que un dictador de respuestas.

Creo que lo anterior se podría resumir en: el software propietario se basa en el dinero y para su desarrollo depende de una cabeza que sepa dar órdenes claras, mientras que el software libre se basa en el ego y para su desarrollo depende de la comunicación y gestión del conocimiento entre varias cabezas.

Ahora, lo dicho puede resultar preocupante para una persona que confíe en el dinero más que en el ego, y puede provocar sofismos del tipo “no confío en su forma de desarrollo, por lo tanto su producto tiene que ser de baja calidad”. Ambos conceptos, filosofía de desarrollo y calidad del producto, son hasta cierto punto independientes ya que en ambos bandos hay buenos y malos productos. Todo se basa en la simple pregunta de que si el software satisface o no mis necesidades o las de mi organización, y qué tan confiable es la solución. Con el software privativo se tienen soluciones que “nunca” se dañan, que “siempre” cuentan con soporte. Y bueno, cuando se dañan es que nos hemos topado con la aguja en el pajar, pero el fabricante siempre nos da una solución para que eso nunca más vuelva a pasar. Lamentablemente, la solución es como el amor: eterno mientras dura. Y así se va parchando y parchando el software, agradecidos que existe ese proveedor que nos ofrece su maná del cielo en medio de nuestro inevitable desierto-purgatorio de software. Lo malo es que con el software libre pasa exactamente lo mismo: tal vez su maná no sabe a coca cola sino a limonada. Pero se tiene el poder para discernir mentiras y verdades, ya que a más de la respuesta ante el fallo nos dan los fundamentos de tal respuesta y la posibilidad de verificarla. Sin esta capacidad se aumenta el riesgo de que pase un hecho altamente improbable, y su correspondiente impacto fuera de toda previsión. La única forma de minimizar tal tipo de riesgo es disponiendo de la mayor cantidad de información disponible, lo cual cumple el software libre ya que entrega el código fuente de la aplicación y una comunidad de desarrolladores abierta a preguntas.