Los programadores somos, casi por definición, productores de software. Esto es, producimos programas (que muchas veces hasta son llamados “productos”, según la definición que dicta el marketing). El gran sueño de muchos programadores es desarrollar un “producto” implementando una idea innovadora (o cubriendo un nicho insatisfecho) y vender una gran cantidad de copias, multiplicando las ganancias.

Esta visión, lentamente, está cambiando. Por un lado, las historias de aquellos que hicieron una fortuna (o establecieron una posición económica) mediante la venta de licencias de un programa son, a la vez, cada vez más lejanas y menos frecuentes. Pero, si empezamos a vernos a nosotros mismos también como consumidores de software, el razonamiento cambia radicalmente.

Comparemos

Tomemos como ejemplo el desarrollo de un programa que le demande 5 años de trabajo a un programador altamente calificado y que requiera de las siguientes herramientas:

• Sistema Operativo.
• Compilador.
• Entorno de desarrollo: Depurador, editor de textos, etc.
• Herramientas de modelado: Herramientas para hacer diagramas de diseño, documentación, etc.
• Motor de base de datos.

El lapso de 5 años no es arbitrario: es una buena cota superior del tiempo pasado el cual un desarrollador debe renovar las herramientas que utiliza, si es que desea mantenerse actualizado. (Si lo prefiere, puede suponer la suma de varios desarrollos de menor envergadura, hasta llegar a cubrir dicho tiempo).

Comparemos entonces la cantidad de líneas de código “producidas” respecto de las “consumidas”. El cociente será seguramente bastante cercano a cero. Desde este punto de vista, aún cuando un programador sigue produciendo software, su rol de consumidor es, por mucho, más relevante.

Alguien dirá que al vender muchas licencias del programa producido, su valor se multiplicará. Esto no es así, teniendo en cuenta que, para poder ejecutarse el programa requerirá, nuevamente, de un sistema operativo y del motor de base de datos. No es poco común ver a un programador cobrar determinada suma de dinero por un desarrollo y a su cliente desembolsar bastante más por licencias del software requerido para que funcione.

Un mal negocio

Entre los programadores independientes (o pequeñas empresas de desarrollo) es práctica común usar software sin pagar por sus licencias, con lo cual parte del análisis anterior no los afecta demasiado. Pero sus clientes (y cada vez más) no tienen opción.

Por ejemplo, un sistema que requiera de un servidor con el sistema operativo Windows 2008 y el motor de bases de datos Microsoft SQL Server 2008 para su utilización en 25 puestos de trabajo, requerirá el pago de más de u$s 10.000 en concepto de licencia de uso de dichos productos (en la Argentina, marzo de 2010). ¿Cuánto deberá trabajar el programador para cobrar una suma de dinero similar?

Claramente, esta forma de ver el negocio no tiene mucho sentido (a no ser para aquellas empresas de desarrollo que además son agente de ventas de quienes proveen el software de base y se llevan una jugosa comisión).

Quizá sea por este motivo que las empresas proveedoras de herramientas de desarrollo y software de base invierten tanto dinero para que los programadores se pongan “su camiseta”, recurriendo para esto a discursos motivadores, aportes a instituciones educativas, descuentos, tazas de café, etc.

Asumir que esta es una situación natural es resignarse a ser, ya no un productor, sino un mero promotor de la venta de productos de otro (con un esfuerzo y un riesgo bastante altos).

Una buena alternativa

Debemos reconocernos a nosotros mismos, antes que como productores, como consumidores de software. De esta manera, la salida es clara: debemos reducir los costos de la “materia prima”. Debemos, en la medida de lo posible, utilizar software que no requiera el pago de licencias de uso. De esta manera disminuyen sensiblemente los costos para el desarrollador, como así también los costos extra del cliente. (Y cliente que gasta menos en licencias, tiene más dinero para pagarle al programador).

Si el sistema del ejemplo anterior pudiera correr en un servidor con GNU/Linux y el motor de bases de datos PostgreSQL tendría más de u$s 10.000 de “ventaja” en condiciones similares.

Otro punto importante es el ahorro en hardware, al utilizar productos que reduzcan los requerimientos en este aspecto (característica que distingue a muchos programas libres, respecto de sus contrapartes privativas), aunque dicho análisis escapa al objetivo del presente artículo.

¿Por qué no?

Existe una marcada reticencia en ciertos programadores a analizar seriamente esta alternativa. Dejaremos de lado, por supuesto, el caso de aquellos que actúan, además, como agentes de venta de los proveedores de software de base (su caso es más que claro: ellos se benefician por ambos lados). Analizaremos algunas de las objeciones más comunes:

El sistema operativo libre “X” es difícil de usar. No lo entiendo

En casi todos los casos, “X” se refiere al sistema operativo GNU/Linux (el sistema operativo libre más difundido). Quizás el programador en cuestión haya tenido una mala experiencia tratando de usar alguna versión mal configurada u obsoleta. Seguramente tampoco haya dedicado demasiado tiempo ni esfuerzo a aprender los conceptos básicos (que no son, precisamente, como usar los botones del mouse), y se alejó cual la zorra de Esopo murmurando “están verdes”.

De esto no se desprende que GNU/Linux sea tán fácil, cómodo o agradable de usar que Windows 7 (o más), pero tratándose de un profesional y habiendo tanto dinero de por medio, bien merece algún pequeño sacrificio.

En la empresa en donde se implanta mi sistema usan Windows

Aquí hay una amplia variedad de casos. ¿Usan Windows en los equipos de escritorio? Asumiendo que ya han pagado las licencias (por el tiempo que reste hasta la actualización de los equipos), de todas maneras podría significar un ahorro importante a nivel de los servidores. ¿Usan Windows en los servidores? Proveer una aplicación que no lo requiera, puede significar un valor agregado interesante.

En la mayoría de los casos en que la empresa “usa Windows” es porque las aplicaciones existentes lo requieren. No es, por lo tanto, una excusa para no proveer una alternativa que posibilite un ahorro importante (si no en lo inmediato, en el mediano plazo).

Estoy acostumbrado a desarrollar en (y para) Windows

Todos sabemos que los programadores disponemos de poco tiempo para mantenernos actualizados y lo costoso que resulta abordar el aprendizaje de una nueva tecnología. Cada quién sabrá si realmente se justifica el esfuerzo, poniendo en la balanza costos y beneficios (o, según el planteo de este artículo, costos y ahorros).

No hay un equivalente libre de la herramienta “Y”

Es cierto que en algunos casos (no tantos como se alegan) no hay equivalentes libres a ciertas herramientas privativas. ¿Y aquí termina el análisis? ¿No merece la pena indagar sobre alguna alternativa? ¿Tan útil es la herramienta “Y” que se hace imprescindible e indiscutible?

Si alguien depende exclusivamente de una determinada herramienta para desarrollar software, entonces se encuentra ante un problema bastante más grave que el gastar dinero en licencias de uso. (Preguntar a desarrolladores en Delphi, Visual Fox, Clarion, entre otros. Pero este tema también excede el alcance del presente artículo.).

No hay un equivalente libre del motor de bases de datos “Z”

Aquí “Z” suele tomar la forma de MS SQL Server, Oracle o DB/2. La afirmación suele hacerse seguida de alguna frase que parece extraída de una publicidad del proveedor correspondiente. La realidad es que existen numerosos motores de bases de datos libres, como por ejemplo MySQL para pequeños volúmenes de información, o PostgreSQL que no tiene ninguna característica importante que envidiarle a ningún otro producto.

En el caso de programas libres, nadie me ofrece el soporte que me da la empresa “W”

¿Enserio? Prácticamente todos los programas libres importantes, cuentan con ofertas de soporte incluso mejores que las que puedan conseguirse respecto de programas privativos. Por un lado, el soporte ofrecido es de mejor nivel, ya que se ofrece a nivel de reparación de errores en el código fuente y, por otro, muchas veces existen múltiples proveedores de soporte, que compiten entre si (en el mundo del software privativo el soporte es un monopolio del fabricante).

Porque no

Es cierto que hay algunos casos en donde no hay alternativa (la utilización de determinada tecnología puede ser impuesta como un requerimiento), pero en la mayoría de los casos la situación es que el programador se encuentra “atado” a sus herramientas.

En algunos casos, porque las han utilizado durante mucho tiempo (y tienen una gran cantidad de código desarrollado ligado a ellas) y en otros porque han “comprado” el discurso de su productor, muchos programadores se resisten a realizar cualquier análisis que tenga que ver con cambiar sus herramientas. El caso más grave (y lamentablemente no poco común) es cuando el programador simplemente no puede usar otra tecnología más que la que domina: es la única que conoce.

De más está decir, las inversiones en marketing dan resultado. Hoy nos encontramos a muchos programadores que han sido formados en un ambiente académico muy similar a un “monocultivo” (que, a pesar de ellos, ni siquiera ofrece los amplios márgenes de ganancia de la soja) o que se han entregado más tarde a determinada combinación de herramientas/tecnología y la han abrazado como dispuestos a envejecer (y quedar obsoletos) junto con ella.

Y así es que el negocio seguirá funcionando muy bien para los “grandes productores de software”, en tanto que los pequeños no reconozcan su rol de consumidores. Afortunadamente, la situación ya está cambiando: abundan los ejemplos de quienes, siendo conscientes de esto, están haciendo una diferencia económica significativa.

Adenda

Nótese que en este artículo no se hace alusión a la licencia bajo la cual el programador entrega su programa al cliente final. El término “libre” sólo se aplica a las herramientas utilizadas para el desarrollo y a las requeridas para su posterior ejecución.

El uso de herramientas de desarrollo libre no impone ninguna condición sobre la licencia que acompañará al programa resultante. (Distinta situación puede darse si se incorpora código de un programa libre en uno de producción propia).