Alucino con el mecanismo psicológico en el que se basan las redes sociales como Tuenti o Facebook, que, al final, consiste simple y llanamente en la necesidad de verse reconocido y querido por los demás.

Adrián Segovia publica Cosas que pasan en las Redes Sociales Generalistas en Espacio Fílmica. Donde cuenta cómo lo importante en una red social no es su capacidad para atraer usuarios, sino su capacidad para generar actividad tras el registro, poniendo como claro exponente el caso del pelotazo de Tuenti que, según mi amiga Mar Monsoriu, se basa en que "entre los chavales de 12 años si no estás en Tuenti no eres nadie".

Cuando alguien te diga algo y no lo entiendas, en realidad te está queriendo decir: "dime que me quieres". Siempre, siempre es así. Si no me crees, mira este video.

The Rise and Fall of Twitter by John Biggs

Voy a contar una historia que ilustra cómo cerrar código publicando sus fuentes.

Hace un par de semanas iniciamos una integración de una herramienta de reporting en hipergate para un proyecto.
Emilio Arias de Stratebi tuvo la amabilidad de pasarme un informe que ellos habían hecho comparando varias herramientas, Pentaho entre ellas, como la plataforma de referencia en Stratebi.
Poco después, José Luis Ramírez de i2e me comentó que ellos usaban BIRT.

Me puse a evaluar ambas opciones pues, y ahí empezó el calvario. En 12 días de intentos he sido incapaz de diseñar y sacar un informe por pantalla. Con BIRT porque la instalación sobre My Eclipse 6 (que es lo que yo uso) empieza a decir que no le gustan las librerías base, y falla el diseñador. Y en Pentaho porque el runtime de JFreeReports 0.9 parece que no reconoce bien los informes del Report Designer. En fin, un desastre.

Como parte del proceso de googlear en busca de soluciones a mis penurias, encontré este post de SZ Quadri sobre BIRT, JasperReports y JFreeReports en el cual aboga por BIRT frente a Jasper y Pentaho por lo siguientes motivos:

1. BIRT es un proyecto Eclipse: Esto asegura que seguirá vivo y evolucionando (como proyecto libre). Estamos seguros de que nadie va a cerrar el código directa o indirectamente (por ejemplo vendiendo la documentación).

5. BIRT tiene documentación de calidad: Una base de datos e informes de ejemplo. Todo ello para reducir la curva de aprendizaje.

Es decir, que BIRT sería la panacea si consiguiese hacerlo funcionar.

Y ahora voy a relatar la típica historia con el típico Software Libre de segunda división y cuando digo "segunda división" me refiero a todo lo que no sea Linux, Apache Web Server, Tomcat, MySQL, PostgreSQL, PHP y Java:

1. Buscas por la red y descubres que, al parecer, existe un producto libre que cubre todas tus necesidades.

2. Lleno de excitación te descargas el producto.

3. Al descomprimir el ZIP te percatas de que el documento de instalación consiste en una pegatina de Anís del Mono.

4. Tras luchar a brazo partido durante dos días con setup por fin consigues que arranque.

5. Al hacer click en cualquier opción de menú no trivial, peta algo.

6. Te pones a buscar qué has hecho mal. Entonces descubres que: a) el fabricante sólo te ayuda si le pagas primero, b) la documentación previa sobre errores reconocidos es una mierda como una casa de doce pisos.

7. Tratas de bucear tu mismo en el código a ver si encuentras la fuente del error. Proceso durante el cual te percatas de que careces de todos los fuentes y de que, además, el control de versiones publicadas es un carajal.

8. Tras unas cuantas ñapas y algún que otro milagro, consigues echar a andar el programa. Momento en el cual te das cuenta de que hace alguna burrada, del estilo de cargar un millón de registros en memoria si tiene una tabla algo grande.

9. Para entonces tienes un Alien metido en tu programa. Has perdido dos o tres semanas de proyecto superando la curva de aprendizaje y ahora resulta que te topas con un muro.

10. Desesperado, llamas al fabricante para pagarle un contrato de soporte. Pero, como estás en zona EMEA, te asignan a un becario al cual le acabas haciendo el trabajo de explicarle dónde están los bugs para que haga de correveidile al equipo de desarrollo.

No sé si me dejo algo en el tintero, pero la moraleja es que existen muchos productos cuyo código es abierto y ello no supone ninguna diferencia respecto del software comercial. Es así porque los fabricantes han hallado la manera de subvertir el espíritu del Software Libre, abriendo el código pero haciéndolo inútil a casi todos los efectos a menos que le pagues al fabricante.

Y conste que estoy 100% de acuerdo en que las empresas desarrolladoras de Software Libre busquen fórmulas para financiarse y cobrar legítimamente a los clientes. Lo que no es éticamente correcto es que distribuyan productos que no funcionan bien y luego cobren por arreglarlos.

Por último, bueno, sí, será que me siento cansado y frustrado de pelear a brazo partido con JARs y ficheros . properties o que soy un melón con patas como programador y no me entero de nada. Pero vale ya de webs bonitas y productos asquerosos, GÑE >:-\

Post relacionado: Terapia Hacker: intenta compilar OpenOffice.org (Juantomás)