¿Cuánto dinero genera el spam?

Hace unas cuantas semanas hablamos sobre las Estadísticas del Nuevo Mundo y sorprendía ver como la pornografía por Internet mueve alrededor de 3.000 $ por segundo. Pruebe a chasquear los dedos y piense que cada vez que lo hace ese negocio genera 3.000 $. Impactante. Y viendo lo realmente increíble de la cifra se plantea la cuestión de si otros negocios underground en la Red son igualmente rentables, por ejemplo, el spam.

El origen de la palabra spam se sitúa en 1937, cuando Hormel Foods lanzó carne enlatada (spiced ham) que no requería refrigeración. Un ejecutivo de la compañía decidió llamarlo SPAM como acrónimo de Shoulder of Pork And haM. El producto fue un enorme éxito comercial durante la segunda guerra mundial al no requerir refrigeración, lo que permitió que fuese casi ubicuo. Esta ubicuidad es la base de una genial secuencia de Monthy Phyton en la que se puede ver como un camarero lee un menú en el que todos los platos son algo con spam o spam con algo.

No en vano, el spam eclipsa por completo al correo electrónico lícito. Las cifras que maneja cualquier director de sistemas hablan de un porcentaje de spam en torno a un 95% sobre el total de correo electrónico recibido.


¿Quiénes son los productores de spam?

El spam, conocido como fenómeno de masas, se crea a finales del siglo XX. Hay una anécdota de la época según la cual a uno de los mayores productores de spam estadounidenses se le escapó su dirección real (la postal) durante una entrevista de televisión. Sus 'clientes' reaccionaron de forma inmediata y no organizada enviándole bolsas de basura (de la de verdad) a su casa mediante empresas de mensajería urgente.
Eran tiempos en los que el spam era molesto, muy molesto, pero no estaba dominado por las mafias organizadas como lo está ahora.

Existen múltiples listas con los spammers más prolíficos y solo coinciden en un aspecto: todos actúan al margen de la ley. Por ejemplo, la lista Rokso identifica a los 100 principales spammers que se cree que son responsables del 80% del correo basura. La primera sorpresa surge cuando se observa que una gran mayoría de ellos procede de EEUU frente a la creencia generalizada de que el origen está en China, las ex-repúblicas soviéticas o países con leyes muy tolerantes frente a estos delitos.

En octubre de 2007 se publicaba una noticia que mostraba a las claras que el spam no era ya cosa de niños traviesos con un ordenador y mucha imaginación. En esa fecha aparecía asesinado en su lujosa vivienda de Moscú uno de los principales 'empresarios' del negocio, Alexey Tolstokozhev. Se cree que Alexey era en ese momento responsable del 30% del spam mundial y de campañas tan conocidas como 'buy viagra'.

Hace tan solo dos días se hacía público que las autoridades rusas, que recientemente han endurecido las leyes frente a la piratería y los delitos en la Red, han dictado orden de busca y captura internacional contra Ígor Gúsev, uno de los herederos del negocio de Tolstokozhev. Su empresa, Canadian Pharmacy, situada en los primeros puestos de la lista Rokso y con sede en Ucrania, se dedica principalmente a la distribución de falsificaciones de productos como Viagra o Cialis.


El spam en cifras

La Asociación Rusa de Comunicación Electrónica estima que Gúsev habría ganado en los tres últimos años una cifra aproximada a los 1.400 millones de euros gracias al spam y la venta de productos falsos mediante él. La cifra asciende a casi 4.000 millones de euros cuando se estiman las ganancias de los productores de spam rusos vistos en su conjunto.

El éxito comercial del spam es ridículo cuando se compara con cualquier otro medio de promocionar un producto, lícito o no. Se estima que únicamente responden a los correos no solicitados 15 personas por cada millón de envíos. Pero incluso ese paupérrimo acierto comercial es una gigantesca mina de oro si se tiene en cuenta que cada año se producen más de 90 billones de mensajes considerados como spam. Las estimaciones más optimistas sitúan el negocio asociado al spam en cifras cercanas a los 10.000 millones de euros anuales. Y eso sin contar, lógicamente, los beneficios de las empresas que se dedican a combatirlo.

Además de los costes que tiene para las empresas, de los que luego hablaremos, eliminar toda esa enorme cantidad de emails tiene un importantísimo coste ecológico. Y es que el hecho de que los emails sean digitales y no consuman papel no quiere decir que sean inocuos para el medio ambiente. La fundación reducetuhuella.org estima que fabricar y mantener en línea los sistemas antispam a nivel mundial (que lógicamente, son proporcionales a la amenaza) genera a diario un buen número de toneladas de CO2; tantas como lo que producen 3,1 millones de coches. Visto desde el punto de vista energético, la potencia utilizada para combatir el spam es equivalente el consumo eléctrico de 2,4 millones de hogares.

El coste para las empresas está, a buen seguro, por encima de los 60 euros anuales por empleado si se tiene en cuenta el coste de las licencias de software utilizadas, el coste energético de los sistemas antispam, el coste por mayor consumo de hardware o el coste de sobre-utilización de las líneas de Internet con contenido que será desechado. Y todo ello, sin tener en cuenta el coste de la no productividad de los empleados con los -muchos o pocos- mensajes que los sistemas antispam no son capaces de detectar.

Respecto a las temáticas de los mensajes de spam, el reparto es bastante previsible. Prácticamente la mitad del spam hace referencia a fármacos falsos (fundamentalmente en el ámbito sexual o estético), software barato e imitaciones de marcas famosas. La otra mitad se la llevan productos financieros, loterías o noticias significadas como el mundial de fútbol, un terremoto importante, una modelo,... es decir, timos.


¿Cómo funciona el negocio?

Lo primero que podría venir a la mente pensando en los spammers es una línea muy potente de conexión a Internet desde la que enviar millones y millones de mensajes. Pero el modelo es un poco más complejo dado que esa línea tendría un elevado coste y además sería muy simple detectarla.

Las mafias asociadas al spam son también productoras de virus. Utilizan virus a los que les falta carga nociva (no rompen nada del PC del usuario) dado que su único fin es introducirse en el PC haciendo el menor 'ruido' posible. De esta forma, consiguen una legión de ordenadores infectados que responderán posteriormente a las órdenes remotas de sus nuevos dueños diciéndoles cuándo y a quién deben enviar correos basura. Estos ordenadores infectados son llamados botnets y... se cuentan por millones.

La siguiente tabla muestra el número de botnets estimado por país en el primer y segundo trimestre de 2010 así como el número de botnets por cada mil ordenadores. Es entonces cuando toma forma el hecho de que EEUU sea el mayor productor de spam dado que es el que tiene mayor número de botnets en valor absoluto (más de dos millones) aunque no sea el primero, ni con mucho, en valor relativo.

Sorprenden Corea, España y México con más de un 1% de equipos infectados. España, por ejemplo, duplica a cualquier otro país de la Unión Europea.

Viendo la misma información de forma gráfica

Esta misma información sobre los spammers puede verse en tiempo real sobre Google Maps en la web del servicio Postini. Tal vez sea un poco de voyerismo pero es curioso saber si hay muchos spammers cerca del lugar de residencia (vaya,  hay quince cerca de la mía... y espero no ser yo uno de esos botnets).


¿Cómo combatirlo?

Simple y claro: en el ámbito judicial. La pena debe ser proporcional al mal generado, que no es poco.

Aunque esto puede ser a veces muy complejo dado que el negocio se genera en los botnets, equipos de usuarios que nada saben del perjuicio que crean. Y quienes dan las órdenes a estos botnets residen, en gran parte de los casos, en países con legislaciones muy relajadas en el ámbito telemático.

Los usuarios pueden colaborar siendo prudentes e instalando un sistema de seguridad antivirus en su equipo, aunque personalmente pienso que esta es la medida que menos aporta dado que el usuario será siempre el eslabón más débil de la cadena (ver Seguridad TI: ¿hemos perdido la batalla?).

Los telcos y proveedores de acceso a la red tienen mucho que decir. El primer paso sería no permitir el envío SMTP a usuarios no identificados y desgraciadamente aún son muchos los ISPs que lo permiten. Pueden  también colaborar poniendo filtros en el core de sus redes. De esta forma podrían eliminar un elevadísimo porcentaje de spam dado que ellas 'ven' todo lo que circula. Operadoras como Telefónica, que recientemente hablaba de pasar de nuevo a facturaciones por consumo en detrimento de la tarifa plana, deberían analizar medidas como estas, más cercanas al pensamiento Google, en lugar de penalizar siempre al usuario final por un consumo de línea ilícito y no deseado. Desde luego, reducirían enormemente el consumo de ancho de banda de sus redes.

Y aún más, ¿por qué no filtrar el spam en los NICs o puntos neutros (Galnix, Euskonix, Catnix, Espanix,...) de conexión transfronteriza de Internet? Con un sistema antispam en los NICs los Gobiernos tienen en su mano acciones muy simples que eliminarían el problema prácticamente de raíz reduciendo de esta forma el elevado coste económico que supone el spam a las empresas y particulares. A fin de cuentas, si leen y espían nuestros emails, lo que ha sido más que evidente en la reciente lucha de varios Gobiernos contra RIM (la idea de fondo era: RIM haz cambios porque Blackberry es tan eficiente cifrando que no podemos ver lo que se dice en los emails, lo que en sí mismo es escandaloso), pues ya de paso que al menos nos los limpien de virus y spam.

Mientras tanto, a seguir soportándolo...


www.tonsofit.com

¡Que poco sexy eres COBOL!

Las universidades lo desprecian, las empresas de tecnología lo obvian, las nuevas generaciones de programadores lo detestan, las consultoras llevan muchos años anunciando su muerte,... pero ahí está, ¡que no muere!

Hace cuatro años Computerworld  apuntaba a COBOL como número uno en la lista de las diez tecnologías que estaban muertas o muriendo. Sin embargo, a día de hoy se estima que hay más de 200.000 millones de líneas de código COBOL activas a nivel mundial y más de un millón de programadores que se ganan la vida con COBOL aportando 1.000 millones de líneas de código nuevas cada año. Más aún, a nivel mundial se estima que cada día se ejecutan más de cien veces más transacciones COBOL que todas las de la Web 2.0 (Google, Facebook, Amazon,...) juntas. No en vano, la mayor parte de la banca, compañías aéreas, telcos, compañías de seguros, médicas, transporte,... basan sus sistemas de backend en aplicaciones COBOL.

Es evidente que hay una falta de alineamiento -una más- entre lo que quiere la industria de TI y lo que ocurre en la vida real. Existe una enorme desconexión entre la programación COBOL y el mundo de Internet porque, en general, las aplicaciones COBOL no miran a la Web.

Mirando al pasado

COBOL nace en el año 1959 (es decir, con sus 50 años bien cumpliditos es más longevo que gran parte de los profesionales de TI en activo) dentro del Conference on Data Systems Languages (CODASYL). Este comité fue auspiciado por el Departamento de Defensa norteamericano y sus miembros eran, casi a partes iguales, personal de la Administración Pública y fabricantes de renombre de la época como IBM, RCA o Burroughs.

Su objetivo era crear un lenguaje de programación que pudiera ser usado en cualquiera de sus equipos independientemente del fabricante de la máquina. Vaya, curiosamente, el mismo objetivo que la máquina virtual Java pero cincuenta años antes.

Desde entonces ha habido varios estándares aceptados por la certificación ISO en los años 1965, 1974. 1985 y 2002 llegando hasta nuestros días en los que COBOL está preparado para soportar programación orientada a objetos (OOP), soportar el procesamiento y generación de formatos XML o ser utilizado en modernos GUI -Windows o la Web, por ejemplo- dirigidos por eventos. La capacidad de adaptación al medio de COBOL es indiscutible.

COBOL desata pasiones

Uno de los mayores teóricos de la computación de la historia, Edsger Dijkstra, dijo una vez de COBOL 'the use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense' (el uso de COBOL paraliza la mente y su enseñanza debería ser considerada como un delito).

Sin embargo, lo simple es bello y es indudable que COBOL es lo más simple que se puede ser siendo lenguaje de programación. Su gramática es tremendamente básica y prácticamente idéntica a como se narrarían las instrucciones en inglés a un profano en la programación.

Es probablemente esa simplicidad lo que tanto gusta a los programadores COBOL. Y es también esa sencillez en el diseño de la gramática del lenguaje la que permite una gran estabilidad y rendimiento a los binarios generados con él. No hay nada en el lenguaje que haga referencia a reserva o liberación de zonas de memoria, punteros o estructuras similares. COBOL no permite la gestión dinámica de la memoria y todas las reservas de zonas de memoria son automáticamente realizadas por el motor de runtime de COBOL lo que, sin duda, evita 'sustos' por accesos a memoria no reservada debido a fallos de programación.

Su acceso a datos, tanto a ficheros como a bases de datos, es totalmente acoplado; el programa COBOL debe conocer de antemano las estructuras de información (las famosas COPYs) a intercambiar con las fuentes de datos. Esto le da una brutal rigidez pero a cambio consigue un extraordinario rendimiento dado que la base de datos conoce de antemano las consultas que el programa realizará y tiene un plan de acceso optimizado para ello.

Por el contrario, quienes repudian a COBOL le achacan la gran cantidad de código que es preciso escribir para tareas, a veces, sencillas. Los lenguajes más modernos tienen a su disposición una gran cantidad de librerías y clases que permiten hacer prácticamente de todo. Su gramática es más compleja pero también mucho más potente lo que permite hacer más con menos aunque a veces sea a costa de empeorar la legibilidad del código que en COBOL es extraordinaria.

Al tiempo, el acceso a datos de lenguajes como C#, Java o VB es significativamente menos eficiente dado que, en general, utilizan métodos de acceso (ADO, ODBC, JDBC,...) desacoplados. El programa determina en tiempo de ejecución los campos a los que accede de la base de datos y ésta debe construir el plan de acceso de forma dinámica o, como mucho, utilizar la experiencia que le aportan los accesos previos. Sin duda, esto es mucho menos eficiente, aunque mucho más flexible, que el SQL estático propio de los programa COBOL.

Otra gran diferencia entre la cultura COBOL y la del resto de lenguajes es la programación mediante componentes. Un ejemplo de ello se percibe en los listados e informes. Si se plantea a un programador COBOL la necesidad de generar un informe probablemente lo diseñará mediante la generación de un fichero de salida que, tal vez, se componga posteriormente con un preformato para darle un aspecto más profesional. Es decir, la generación del informe se realiza a base de programación pura y dura calculando posiciones y tamaños para el posicionamiento de la información. Por el contrario, el mismo problema planteado a un programador Java probablemente se llevará a cabo mediante un generador de informes (Crystal Report, SQL Reporting Services,...) totalmente visual donde no será preciso calcular coordenadas para posicionar campos ni para verificar que no se supera el tamaño de línea. Este listado estará totalmente desacoplado del programa y es probable que no requiera ni una sola línea de programación.
Se percibe como los programadores Java o VB tienen la visión para utilizar componentes externos mientras que los programadores COBOL están fuertemente alineados con que todo debe salir del código de programación.

Se lo han puesto muy fácil

Lo cierto es que, sea o no COBOL un buen lenguaje de programación, la competencia se lo ha puesto tremendamente fácil. Por un lado Java con un pésimo rendimiento a igualdad de hardware, con colapsos de memoria o incomprensibles procesos de garbage collection.
De otra parte Visual Basic con definiciones de variables sin tipo o incluso la utilización de variables no definidas que no hacen sino causar confusión y ambigüedad. Y confusión y ambigüedad mezclada con algo tan determinista como un sistema binario solo lleva al caos.

Afortunadamente, los fabricantes de compiladores y diseñadores de gramáticas han aprendido de sus errores. Hoy no existen ya lenguajes de programación serios que permitan utilizar variables no definidas o variables sin tipo de datos estrictos. Y los rendimientos han mejorado ostensiblemente gracias al JustInTime de Java o al lenguaje intermedio MSIL de .NET, además del exponencial aumento de la potencia del hardware.

COBOL sigue siendo aún más eficiente que cualquiera de sus compañeros de viaje pero las diferencias se igualan cada vez más, casi al mismo ritmo en el que decrecen los costes de hardware, con lo que el rendimiento está dejando de ser un valor diferencial de COBOL. Igualmente, los nuevos lenguajes de programación generan binarios cada vez más estables y más ajustados al juego de instrucciones de los modernos procesadores.

Aún así, cuesta creer que dentro de cinco o diez años veamos las aplicaciones Java o .NET diseñadas hoy funcionando sin cambios y de forma estable, bien sean los cambios derivados de modificaciones de la infraestructura (versión de sistema operativo, JVM, .NET platform,...) o de fallos de programación. Sin embargo, no es difícil encontrar aplicaciones escritas en COBOL que no han sufrido cambios (salvo los evolutivos por nuevas funcionalidades) no ya en los últimos cinco años, ¡en los últimos veinte!

Pero el paso del tiempo juega en su contra

A finales del siglo pasado el cien por cien de las empresas de la lista Fortune 500 mantenía una gran parte de sus sistemas de backend mediante aplicaciones COBOL. Diez años después, la práctica totalidad de las empresas que han entrado en esa lista durante ese periodo, no cuentan con aplicación COBOL alguna. De hecho, hay quien asegura que la fecha de creación de una empresa es un buen indicador para saber si utiliza COBOL o no. La frontera parece estar en algún momento de la década de los '90 del siglo pasado y cualquier empresa de creación posterior a esa fecha no ha utilizado nunca COBOL y probablemente jamás lo hará.

Los programadores COBOL son tremendamente fieles a sus costumbres y formas de hacer pero el lenguaje, en su conjunto, no cuenta con el tiempo como su aliado. Durante una década, cuando menos, las Universidades han obviado este lenguaje de programación en sus planes de estudio y eso se nota.

Es muy significativa la diferencia en la media de edad entre un programador COBOL y un programador Java o C#. De hecho, no creo que resulte descabellado pensar que la media de edad de los programadores COBOL esté entre los 50 y 55 años mientras que la de los programadores en nuevos lenguajes se sitúe en torno a los 30 o 35 años.

Vaya por delante que incluyo el cómic sin el más mínimo ánimo de ofender a nadie

Fue Max Planck quien dijo que 'una nueva verdad científica no triunfa por el convencimiento de sus oponentes y haciéndoles ver la luz, sino más bien porque sus oponentes eventualmente se extinguen, y una nueva generación familiarizada con ella crece'.

En ese sentido, COBOL vivirá sin mayores problemas, probablemente, durante los próximos diez años dado que no hay que olvidar la gigantesca cantidad de líneas de código existentes, la gran cantidad de programadores dispuestos a mantenerlas y los elevados costes que supone plantear una migración en big-bang a un nuevo lenguaje. Pero ¿qué ocurrirá dentro de una década cuando la edad media de los programadores COBOL se acerque a la edad de jubilación?

¿Qué pasará en el futuro?

Hay varias posibles respuestas a esa cuestión pero todas apuntan a una reducción en la capacidad productiva en COBOL lo que implicará una sensible elevación salarial de su legión de programadores por diferencias entre oferta y demanda. Esta subida salarial, a su vez, hará menos interesante en costes la opción de mantener el código COBOL frente a la opción de big-bang en otros lenguajes. Y esto, a su vez, implicará más proyectos de migración a otros lenguajes y con ello una drástica disminución del número de líneas de código COBOL activas. Todo esto, sin olvidar que cualquier planteamiento de migración de lenguaje de programación es y debe ser considerado como un proyecto de ciclo. No es viable pensar en ello como algo que se puede llevar a cabo en seis o doce meses.

De seguir todo como hasta ahora parece claro que en torno a 2020 se podría producir una crisis llamada COBOL dado que el número de líneas no decrece y la fuerza productiva será cada vez menor. Pero todo esto no es más que una perspectiva probable de futuro y los humanos, salvo algún que otro genio, solo sabemos diseñar el futuro en base a proyectar el pasado. Es probable que surja algo disruptivo que haga que todo lo que se cree que ocurrirá simplemente no tenga sentido.

Hay una generación entera de programadores que piensa en COBOL como algo del pasado. Es posible, por tanto, que en base a la edad existan dos tipos de programadores del mismo modo que hay también dos tipos de técnicos de sistemas (ver El técnico de sistemas perfecto).

¡Qué poquito sexy eres COBOL! Tras, cincuenta años de servicio sustentando las grandes instalaciones de TI todo el mundo quiere hacerte desparecer. A fin de cuentas, y volviendo al inicio, el sector de TI lleva 20 años intentando reducirte a la nada y vaya si te resistes...

¿Opiniones?

Y el software libre se hizo negocio...

Tengo una noticia buena y otra mala para quienes piensan que el software libre es creado por personas anónimas y sin ánimo de lucro. La mala es que esa visión es tan idealista como irreal y la buena es que la mayor parte de la sociedad lo percibe de esa forma.

Nota antes de comenzar: Es importante tener claro que todo lo aquí expuesto es de aplicación únicamente a nivel empresarial. En el ámbito doméstico algunas cosas pueden no ser (y de hecho no son) correctas ni ciertas.

En el post anterior (Microsoft: el mayor impulsor del software libre) hablábamos de los orígenes del software libre. Hoy toca hablar de su presente y si es posible de su futuro. Para ello, comencemos desmenuzando sus características fundamentales.

Flexibilidad

La idea fundamental que subyace es que si el código fuente está disponible, los desarrolladores podrán aprender y modificar los programas a su antojo, corrigiendo errores o adaptándolo para realizar tareas específicas. Además, se produce un flujo constante de ideas que mejora la calidad de los programas.

Esto es cierto entre los profesionales del software, es decir, para aquellas compañías del sector TI o para aquellas compañías que tengan la dimensión como plantearse tener personal en plantilla para la corrección de fallos en el software de base, es decir, aquel que sirve como plataforma para las aplicaciones de negocio.

Atribuyen a Einstein la cita de que todo debe ser tan sencillo como sea posible, pero no más. En este sentido, y salvo excepciones, parece poco razonable pensar que disponer del código fuente sea una ventaja competitiva frente a los paquetes de software que no facilitan dicho código. Sería tanto como pensar que un conductor obtendría algún tipo de beneficio si el fabricante del vehículo le adjuntase los planos de ingeniería del motor. Obviamente, sería bueno para las compañías de la competencia y para algún conductor con un elevado nivel de curiosidad y conocimientos pero no para el común de los compradores de coche que prefieren centrarse en su día a día dejando el diseño de motores para aquellos con la formación y conocimientos adecuados. El razonamiento que subyace está basado en el principio Taylorista de especialización. Es más, modificar el corazón de los productos por su cuenta y riesgo (fuera del estándar) puede ser incluso contraproducente teniendo en cuenta que aumentan las papeletas en el particular sorteo de la incompatibilidad con la siguiente versión.

He de decir que no conozco personalmente a nadie que haya modificado el kernel de Linux, ni módulos de Alfreso o MySQL, ni de WMWare, ni de Apache, ni de Firefox... Y si conozco a mucha gente que usa todos esos productos en su día a día; aunque también conozco a los que usan las alternativas de software comercial y la verdad creo que no se diferencien en mucho.

Fiabilidad y seguridad

En este caso, la idea primigenia es que con varios programadores a la vez mirando el mismo trabajo los errores se detectan y corrigen antes, por lo que el producto resultante es más fiable y eficaz que el comercial. Es la alternativa al oscurantismo habitual de las compañías de software que únicamente reconocen los problemas de seguridad cuando no queda más remedio y cuando la explotación de estos problemas pone en riesgo los sistemas.

Tener acceso al código fuente es una ventaja en aquellos proyectos que tienen un gran respaldo de la comunidad y donde el número de desarrolladores es elevado. En este caso se cumple la premisa de que entre muchos se detectan y corrigen los problemas con mayor celeridad. Sin embargo, cuando los proyectos son pequeños y el número de desarrolladores reducido, el riesgo de permitir a cualquiera husmear en el código fuente no se ve recompensado con un gran número de personas dispuestas a solventar problemas. En este caso, menos es más y la táctica del oscurantismo utilizada por la mayor parte de las compañías de software, no permitiendo ver el código fuente a potenciales delincuentes, puede llegar a ser una estrategia más acertada.

Rapidez de desarrollo

En líneas generales se cumplen las mismas premisas que las descritas para la fiabilidad y seguridad. Cuando los proyectos no tienen mucha relevancia el número de personas es igual o inferior a los que cualquier compañía puede disponer en torno a un responsable de desarrollo de producto. Sin embargo, cuando el proyecto de desarrollo tiene mucha relevancia el número de personas dispuestas a donar su tiempo es elevado y los tiempos de desarrollo son extremadamente cortos. Un reciente estudio sobre RedHat fijó el coste de desarrollo de este sistema operativo en torno a un billón de dólares, basando los cálculos en sus 30 millones de líneas de código, para lo que una empresa tradicional que partiese de cero debería contratar una fuerza productiva de 8.000 profesionales FTE. Es difícil pensar que una compañía privada sujeta a cuentas de resultados anuales pueda poner en nómina a un conjunto de personas como los que en ocasiones trabajan en proyectos de Open Source.

Coste

Esta es, como no podía ser de otra forma, la piedra filosofal en torno a lo que, en la práctica gira la existencia y, por qué no, la pervivencia del software libre. Los dos mundos enfrentados se disputan ser los más eficientes en costes en las grandes implantaciones de TI y, como intentaremos demostrar, es posible que ambos tengan razón.

¿Cuánto cuesta el software libre?

Partamos de la base de que el producto de software libre a analizar es gratuito. Es decir, su código fuente circula libremente y además se puede obtener a coste cero. Este bien podría ser el caso de Linux. ¿Querría esto decir que la comparativa entre Windows y Linux se resuelve mediante un “coste de licencia de Microsoft vs cero”? La respuesta claramente es no.

Para entender los motivos que fundamentan esta respuesta se deben analizar los costes reales de los sistemas informáticos. Según un estudio de IDC (Three Year Server TCO), que en líneas generales coincide con estudios de otras consultoras, el coste total de propiedad de un sistema informático, es decir, el coste real que significa ese sistema para las compañías, tiene su sustento básico en dos conceptos: el coste de gestión y mantenimiento del mismo una vez que está en funcionamiento (60%) y el coste del no servicio y falta de productividad, es decir, el coste que significa para las compañías no disponer de ese sistema y las variaciones de la productividad en función de la aceptación de los sistemas por parte de los usuarios (15%).

A cierta distancia se sitúan otros conceptos como el coste de las máquinas y del software con un 7% cada una. Incluso los costes de formación del personal de TI (8%) se sitúan por encima de los costes del software.

Como ya se indicó, el coste más importante, con un porcentaje del 60%, es el de gestión y mantenimiento y, dado su peso en la cifra global, procede un estudio más pormenorizado del mismo.

En este concepto se engloban básicamente los salarios del personal de TI dedicado a la implantación del sistema, a garantizar el correcto funcionamiento una vez que se encuentra en funcionamiento y a resolver las consultas y problemas de los usuarios en su trabajo diario con el mismo. También se incluyen otros conceptos como el coste de soporte de las empresas especializadas, el coste de las herramientas de gestión de utiliza el personal de TI para su trabajo diario, si bien, estos costes son en general menos representativos frente al coste salarial.

Tal y como se indicó al inicio de esta sección, los sistemas informáticos basados en software libre a nivel empresarial no son, ni con mucho, gratuitos pese a que el software que los sustente se distribuya sin coste.

Es importante destacar que este micro-estudio no es extrapolable a cualquier comparativa entre software libre y comercial dado que, en cada caso, sería necesario el análisis de las alternativas, su coste de implantación y gestión, el nivel de aceptación por parte de los usuarios, etc. Por ejemplo, es previsible que en un análisis de coste total de propiedad de las herramientas ofimáticas (Microsoft Office vs Open Office) el concepto ‘user productivity’ tuviese un peso muy superior al que se referencia en el caso de los servidores dado que en ese estudio es el usuario quien trabaja directamente con la herramienta y, por tanto, su formación ad-hoc e incluso sus preferencias son enormemente relevantes. Con toda seguridad, en el caso de las herramientas ofimáticas la productividad del usuario estaría cerca del 50% en peso frente al global del TCO. De ahí que el retador en este mercado -OpenOffice.org- tenga un asombroso parecido al líder -Microsoft Office- en cuanto a apariencia e interfaz de usuario.

Respondiendo a la pregunta que inicia este apartado cabría decir que el coste de propiedad de los sistemas basados en software libre es razonablemente similar al de los basados en software comercial. Dependiendo del software a analizar y de las circunstancias de cada compañía (formación del personal TI en unas u otras tecnologías, perfil, conocimiento y gustos de los usuarios, costes de arrastre respecto a tecnologías preexistentes que deben ser migradas,…) será más óptimo decantarse por una u otra opción. Lo importante a tener en cuenta es que el (no) coste del software en sí mismo no es el valor diferencial.
Hay un 7% (el valor de las licencias de software) donde se puede obtener ventaja pero hay otro 93% donde en función de todo lo anterior se puede (o no) perderlo todo.

¿Quién sustenta el software libre?

Hay una pregunta que, por obvia, tal vez no haya aflorado aún: ¿de qué viven las empresas que se dedican al software libre?

El software libre ha evolucionado enormemente a nivel técnico durante los últimos años, y también lo ha hecho a nivel comercial. Hoy en día, muchas de las empresas que en su momento se iniciaron en el software libre como abanderados del mismo han sido adquiridas por las grandes corporaciones multinacionales en operaciones que, en ocasiones, han sido multimillonarias. Es el ejemplo de Suse Linux que fue sido adquirida por Novell (por doscientos millones de dólares), MySQL adquirida por Sun Microsystems (por mil millones de dólares) que a su vez ha sido fagocitada por Oracle, XenSource adquirida por Citrix (por quinientos millones de dólares), y así hasta completar una extensa lista. Atención, porque hablamos de transacciones comerciales por valor de hasta 900 millones de euros o 150.000 millones de pesetas que impresiona más, en una única operación.
Esto no debería resultar extraño dado que a diferencia de lo que ocurrió en sus inicios, hoy en día el software libre es explotado comercialmente por las empresas de TI.

Las hay que buscan en el Open Source una nueva forma de crear comunidades de usuario como mecanismo de fidelización. Como puede resultar lógico, un potencial cliente se siente más predispuesto a adquirir o continuar con un determinado software cuando existe un lazo íntimo que le une a ese producto más allá de la pura relación comercial.

Otras, en cambio, buscan en la comunidad una forma de aumentar su fuerza productiva sin incrementar por ello sus costes. Donando el código fuente en Internet, inicialmente, se produce una descapitalización en la empresa al perder una ventaja competitiva (los derechos sobre el conocimiento), permitiendo a los competidores acceder a los ‘secretos’ del producto. Pero a medio plazo esa descapitalización se ve compensada al obtener mejoras en el producto provenientes de la comunidad. Es decir, obtener mejoras en el producto a coste prácticamente cero y con la ventaja añadida de que, en ocasiones, al ser el usuario quien las realiza, éstas están totalmente alineadas con sus preferencias sin haber sido necesario un estudio de necesidades.

Hay también corporaciones que buscan en el Open Source una forma de mermar el negocio de la competencia. En ocasiones se hace evidente como algunas compañías impulsan proyectos de software libre cediendo código fuente e incluso personal como forma de atacar los productos más rentables de sus competidores. Esta es, como es lógico, una política absolutamente legal y provechosa al ser una nueva variante de la competencia en los mercados. La comunidad se ve beneficiada al obtener recursos técnicos y económicos para sus proyectos y las compañías ven como su competidor líder tiene que destinar más recursos a potenciar sus productos para no quedarse rezagado limitando con ello su capacidad de actuación en otros ámbitos.

Y por último, existen compañías que, combinando todo lo anterior, trabajan en proyectos de Open Source obteniendo su financiación y beneficios de la venta de licencias (que sea libre no implica que sea gratuito), soporte técnico post-venta, proyectos de implantación, cursos de formación,…

Como se observa, el horizonte está plagado de compañías que han desembarcado en el Open Source con diferentes objetivos técnicos y comerciales. Y hay una máxima que se mantiene invariablemente constante: ninguna de estas compañías, salvo rarísimas excepciones, dona al Open Source su producto cuando éste es líder de mercado y no hay nada en el horizonte que amenace este liderazgo.

Como ejemplo podríamos citar como Oracle mantiene a buen recaudo el código fuente de su motor de base de datos pero al tiempo se involucra a fondo en el Open Source en aquellos segmentos en los que no tiene presencia como la virtualización de hardware o los sistemas operativos. Incluso se da la circunstancia de que Oracle es propietario de un motor de base de datos (el que le da nombre) y de un motor de base de datos Open Source como es MySQL lo que constituye, a buen seguro, un auténtico galimatías estratégico para estar presente simultáneamente en los dos mercados sin que la presencia en uno enturbie su imagen en el otro.
Tanto es así que está comenzando a tener serios problemas con la comunidad Open Source de OpenOffice (donde ya hay un fork oficial, LibreOffice), la de Linux dado que ha desarrollado un Kernel propio (oficialmente dicen que ofrece mucho mejor rendimiento que el estándar) y ha retirado el apoyo a OpenSolaris, la de Java donde está en batallas legales con Google por patentes en Android, al de MySQL por no fijar una clara estrategia de evolución,...

Otro ejemplo podría ser el de IBM y HP que colaboran real y muy activamente con Linux y otros productos de Open Source al tiempo que mantienen a buen recaudo sus sistemas propietarios (y rentables) como zOS, i5/OS, AIX, HP-UX, NonStop, DB2,…

Es curioso ver como el primer acercamiento de ambas compañías a un proyecto siempre es -en el 99% de los casos- con sus sistemas propietarios. Y cuando perciben que esa opción no es válida desenfundan la opción Linux. No es criticable, solo curioso.

Es previsible que las empresas que intentan mantener el equilibrio de la balanza de esta manera terminen generando fricciones con las diferentes comunidades, tal y como ya le está sucediendo a Oracle, porque no se puede estar eternamente en la indefinición.

El último de los ejemplos, por ser muy conocido, es Google al mantener su genial mecanismo de búsqueda fuera del alcance del copyleft al tiempo que anuncia que se involucra en el mundo de los navegadores de Internet con un producto propio en Open Source, Chrome. Esto, incluso, le ha costado las críticas de la comunidad de Open Source que da soporte a Firefox al considerar que era una actuación desleal tras haberse beneficiado del conocimiento de este proyecto durante años.

En situación muy distinta están compañías que han donado sus códigos fuente cuando han visto una merma continuada de ventas o cuando han percibido que el producto se enfrentaría a una situación complicada en el futuro. Entre las más destacadas cesiones podría citarse a Eclipse, Netscape o Solaris. En el primer y segundo caso por la situación de liderazgo de Visual Studio e Internet Explorer y en el tercero por lo complejo que suponía para Sun la estrategia de apoyar el software libre manteniendo un sistema operativo propietario –además de una feroz competencia por ese mercado-. No hay más que ver como Oracle, con infinitamente más músculo financiero que la extinta Sun, ha retirado la versión Open Source de Solaris para continuar el desarrollo por sus propios medios.

El Open Source se ha convertido en la práctica en una nueva forma de concebir el negocio del software en el que se intenta contar con la colaboración y el trabajo de los usuarios para la mejora de los productos, la creación de comunidades que aumenten la fidelización y la obtención de beneficios por vías diferentes a la de la venta de licencias. Pero en definitiva, una nueva forma de entender el negocio.

Por eso, más allá del fanatismo tecnológico, el software libre de calidad será bueno cuando tras quitar el adjetivo libre la frase aún siga teniendo sentido. Es decir, será bueno sí y solo sí el software es de calidad, si  y solo sí se ajusta a las necesidades, preferencias, gustos y cultura de la compañía y si y solo sí presenta el ratio coste/beneficio más óptimo medido en términos de TCO, independientemente de que lo desarrolle una empresa o lo desarrolle una comunidad de vecinos. Perogrullo, vamos... ¿o no?

To be continued...

Microsoft: el mayor impulsor del software libre

Lo sé, el título del post puede sonar a amarillismo o tal vez me he vuelto loco pero si siguen leyendo tres minutos más intentaré demostrar que lo primero no es cierto (o no del todo) y tal vez tenga suerte con lo segundo.

Partiendo de la base de que se tienen claras las libertades básicas del software libre (libertad para usar, estudiar, distribuir y mejorar) y que se tiene claro que software libre no tiene relación biunívoca con software gratuito, empecemos (si no fuera así recomiendo la lectura previa de wikipedia en su entrada sobre software libre).

El software libre suele denominarse también Open Source cuyo desarrollo está impulsado por la Open Software Initiative. Si bien ambos términos no son exactamente sinónimos desde el punto de vista filosófico (el primero hace referencia a planteamientos éticos y morales mientras que Open Source se centra únicamente en aspectos técnicos) son completamente equivalentes desde el punto de vista práctico y, de hecho, ambos movimientos trabajan juntos en el desarrollo de proyectos.

Un poquito de historia (la justa para poner en contexto)

Independientemente del momento en que cada uno apareció en escena existen dos personas claves en el desarrollo del software libre. La primera es Richard Stallman, creador del concepto de software libre y de la fundación que lo promueve. La segunda, como no, es Linus Torvalds, creador original e impulsor del sistema operativo Linux cuyo desarrollo fue la pieza angular del crecimiento y potenciación de los conceptos de software libre y código abierto.

En el caso de Stallman, la historia cuenta que a mediados de los años 80, cuando el software comenzaba a tener restricciones de uso (hasta entonces era desarrollado y compartido fundamentalmente en las  universidades y en una industria absolutamente incipiente), el laboratorio en el que él trabajaba recibió una impresora como donativo. El software que gestionaba esta impresora presentaba algunas carencias que el propio Stallman se ofreció a solventar de manera desinteresada y para ello solicitó el código fuente a la empresa que comercializaba el software. Pese a que su interés no era lucrativo (únicamente quería solventar los problemas del software y estaba dispuesto a donar las mejoras a la empresa propietaria) la respuesta que recibió fue negativa y por ello, en 1984, Stallman comenzó a trabajar en el proyecto GNU, y un año más tarde fundó la Free Software Foundation introduciendo una definición para free software y el concepto de copyleft como mecanismo para dar a los usuarios las libertades citadas en el punto anterior y para restringir las posibilidades de apropiación del software.

Linus Torvalds es el creador del primer núcleo del sistema operativo Linux. Este germen de software, que en su momento tenía no más de 10.000 líneas de código, consta en la actualidad de más de 30 millones y es el exponente máximo de la corriente de software alternativo al de las firmas de software convencionales. Aunque Linus es el autor de no más del 2% de Linux se le sigue considerando el padre del sistema operativo y su persona es un referente para toda la comunidad de software libre.

La razón fundamental para el desarrollo de Linux, según el propio Torvalds, fue su ímpetu por la investigación y la búsqueda de una alternativa al sistema operativo Minix (variante de UNIX con fines educativos). No obstante, en la actualidad, lejos de ser un competidor para UNIX, se ha convertido en el referente de los sistemas operativos junto a Microsoft Windows.

¿Por qué nace el software libre?

Como se vio en el punto anterior, el software libre nace como rechazo al intento de privación de acceso a la propiedad intelectual, máxime cuando este acceso no estaba acompañado del correspondiente ánimo de lucro sino únicamente mejorar lo ya existente.

En este sentido, Free Software Foundation (no tanto Open Source Initiative) considera el software libre como un competidor del capitalismo, una forma de anarquismo práctico donde el copyright es una restricción del legislador sobre los mercados. De hecho, gran parte de las implicaciones políticas y económicas del software libre hacen alusión a varios conceptos y principios de claros tintes socialistas y anarquistas. Y aunque sería un despropósito pensar que el software libre solo tiene aceptación en función de  corrientes políticas (es un fenómeno a escala mundial) no pasa desapercibido el que cuatro de los diez países que más claramente lo apoyan a nivel institucional sean Brasil, Cuba, Venezuela y China.

Este tipo de razonamientos explican en gran parte los orígenes del software libre pero resulta difícil pensar que su enorme desarrollo se deba a elevados niveles de altruismo a nivel mundial o al gusto por los sistemas mutualistas o cooperativistas (formas asociativas muy similares al modo en que se organizan las comunidades de software libre).

Pero entonces, ¿qué ha provocado el enorme auge de este tipo de creación de software? Para intentar dar respuesta a esta cuestión se centrará el estudio en Linux dado que muchas de las respuestas serán posteriormente extrapolables al conjunto del software libre.

Los gurús nos aseguran que en todos los mercados maduros existen siempre tres tipos de actores: el líder, el retador y los peleles. Entre los dos primeros se reparten la mayor parte de la cuota de mercado siendo los peleles dueños de un porcentaje mínimo que habitualmente está asociado a nichos.

Observando el mercado de los sistemas operativos a mediados de los ’90 se constata el enorme crecimiento de Microsoft Windows en cuanto a licencias y cuota de mercado, lo que provocaba un considerable retroceso del resto de competidores. Así, Microsoft consiguió sacar del mercado a sistemas operativos como IBM OS/2, Novell Networks, Banyan Vines,… reduciendo al mismo tiempo la cuota de la mayor parte de los sistemas operativos derivados de UNIX en el mercado en el que en esos años Windows era su competencia (gama media-baja en aquellos momentos). Es decir, Windows estaba constituyéndose como el líder del mercado de sistemas operativos de usuario y de red para entornos de computación medio o bajo.

En esta coyuntura el panorama se pintaba de forma que existía un claro líder pero ¿y el retador? Nadie en la industria del software había conseguido pasar de pelele frente a Windows dado que las cuotas de mercado y aceptación de sus competidores estaban bajo mínimos. Esta estrategia, que podría parecer la ideal para cualquier empresa, maximizando las ventas y por tanto los beneficios, no tardaría en cobrar su peaje a Microsoft.

En la medida en que nadie en la industria de TI era capaz de plantear una alternativa razonable al monopolio de Windows 95/98 y Windows NT y posteriormente al ya omnipresente Windows 2000, las comunidades de software libre tomaron el testigo haciendo evolucionar a Linux hasta posicionarlo como un retador creíble. Es decir, dado que los competidores convencionales no eran capaces de hacer sombra a Windows, apareció la mano invisible (Adam Smith) de la economía reordenando el mercado. Aparecía de este modo un nuevo jugador o, mejor dicho, un nuevo tipo de jugador: el de los fabricantes de software no alineados.

La postura inicial de Microsoft (durante más de 15 años ha sido así) fue la de ningunear a Linux haciendo como si no existiese -no aparece referencia alguna a Linux en los documentos públicos de Microsoft hasta bien entrada la primera década del siglo XXI-.  Parafraseando a Peter Drucker en un texto que bien podría haber sido escrito pensando en la lucha entre Microsoft y Linux los grandes fabricantes y proveedores que predominan en el mercado y que han tenido éxito sin cuestionamiento durante muchos años tienden a ser arrogantes. Al principio, descartan al competidor recién llegado por insignificante y aficionado. Pero incluso cuando ese recién llegado consigue una parte cada vez más grande del negocio, les cuesta trabajo movilizarse para reaccionar. Esto, unido a la animadversión propia hacia los monopolios, no hizo sino echar leña al fuego de la comunidad de software libre.

En resumen, una de las causas principales del repentino y vertiginoso crecimiento de Linux se debe a la no existencia de competencia. Microsoft se erigió como un monopolio de hecho y, aunque es fácil decirlo a posteriori, no supo gestionar adecuadamente su inmejorable posición de liderazgo. Sus tácticas comerciales y de marketing, en ocasiones al límite de la legalidad, asfixiaron hasta tal punto a sus competidores que permitieron la irrupción de un jugador que desequilibraba y no se ajustaba a las estrategias habituales del mercado.

En palabras, nuevamente, de Drucker: Hay una máxima posición de mercado por encima de la cual puede no ser aconsejable colocarse, incluso sin leyes antimonopolio. El dominio del mercado tiende a adormecer al líder y produce una tremenda resistencia interna a cualquier innovación y, por eso, hace sumamente difícil adaptarse al cambio. Y existe también una resistencia muy bien fundada a depender de un proveedor dominante. A nadie le gusta estar a merced de un proveedor monopolista.

No resulta raro que el slogan defensivo de Microsoft frente a las demandas anti-monopolio fuese el de Freedom to innovate, queriendo indicar, es de suponer,  un cambio de estrategia por el cual se abanderaba la innovación como forma de luchar contra la autocomplacencia que provocan las situaciones monopolísticas.

Volviendo al dominio del mercado, obviamente, Microsoft superó ampliamente la posición óptima en varios ámbitos, entre ellos el de los sistemas operativos de equipos de sobremesa, el de los navegadores de Internet y el de las herramientas ofimáticas, donde el dominio llegó a estar –y en algún caso aún está- por encima del 95% del mercado.

Quizá por ello la historia de Linux y su crecimiento es extrapolable en gran medida a muchas otras iniciativas del software libre como el entorno de desarrollo de software Eclipse frente a Microsoft Visual Studio, el navegador de Internet Firefox frente a Microsoft Internet Explorer o la suite ofimática OpenOffice frente a Microsoft Office. En este último caso, la aparición de la suite ofimática de software libre respondía a la desaparición del mercado de suites comerciales como IBM Lotus SmartSuite o paquetes muy populares en su momento como Wordperfect. Nuevamente, la capacidad de Microsoft para llevar al límite las teorías darwinianas en las que solo uno puede sobrevivir propició la aparición de alternativas no previstas, en parte debido a una variante inesperada de la mano invisible.

Otras muchas iniciativas del software libre, en su mayor parte posteriores, han nacido asociadas al notable éxito cosechado por Linux y casi siempre con Microsoft como enemigo irreconciliable. Esto no es casual dado que, con motivos o sin ellos, Microsoft está posicionado como el referente en el polo opuesto a las teorías que promueven las comunidades de Open Source (aunque últimamente Oracle, tras la compra de Sun, parece querer desbancarle de ese dudoso honor tras la retirada de Open Solaris o la demanda contra Google por la patente de Java).

Resumiendo, el auge del software libre se reparte a partes iguales entre una agresiva política comercial y tecnológica de Microsoft frente a sus competidores y a la más absoluta incapacidad del resto del mercado para hacerle sombra tanto técnica como comercialmente.

Volviendo al presente

Para demostrar la teoría anterior analicemos un mercado: el de los sistemas operativos para dispositivos móviles. Hace diez años todo el mundo apostaba por Linux como competidor de Microsoft en el mercado de los dispositivos móviles. De hecho, no había más jugadores, solo estaban Microsoft con Windows Mobile y Linux con su micro-kernel para dispositivos de bolsillo. Hoy en día hay alternativas comerciales a Windows Mobile (Android de Google e iOS en el iPhone de Apple) que incluso le superan ampliamente en cuota de mercado.
¿Alguien se acuerda ya de Linux en teléfonos móviles? La respuesta: nadie, porque Linux tras muchos años intentándolo no pasa de un pírrico 3% de cuota de mercado en este tipo de dispositivos (Ver apartado de Cuota de Mercado en este post).

Otro ejemplo. Durante años la única competencia de Microsoft Office ha sido una iniciativa bastante poco exitosa: Open Office. Esto se produce por la manifiesta incapacidad del mercado para hacer sombra a Microsoft en el segmento ofimático, especialmente por parte de IBM con SmartSuite y Novell con GroupWise (antes WordPerfect).
Hoy en día hay un nuevo actor en escena, Google Apps, con un planteamiento disruptivo en la nube que parece si ser capaz al menos de plantar cara a Microsoft. Apuesto (y no tengo absolutamente ningún dato que lo respalde, es pura intuición) a que Google Apps tendrá más base instalada en 2011 que Open Office en toda su historia.

Lo mismo podría decirse, por qué no, de Mozilla, Internet Explorer y Chrome. En definitiva, aunque como en todo hay algunas honrosas excepciones (quizá Apache sea una), parece claro que cada vez que aparece un competidor digno en el mercado se relega al software libre -al de verdad, no al financiado o auspiciado por empresas concretas- a sus cuarteles de invierno.

Después de todo esto, ¿aún siguen pensando que el título del post es sensacionalista?

To be continued...