Ricardo Galli, de software libre

El día 4 de julio de 1997 el Mars Pathfinder  aterriza en Marte y a las pocas horas empieza a enviar las fotos de Marte en alta calidad que todos conocemos. La misión hasta ese momento de calificó de éxito. Se despliega la nave que sirvió para el viaje y para el aterrizaje –el SpaceCraft/Lander (diagrama inferior)– para dejar salir al Sojounder Rover (la conocida imagen de la derecha).

A los pocos días se detectan continuos reinicios del ordenador del Lander cuando intentaba enviar datos metereológicos y científicos a la Tierra. Los reinicios del ordenador estaban ocasionados por una tarea (bc_sched) que verifica si otras han acabado, de no ser así reinicia todo el software (sin pérdidas de los datos obtenidos, que se mantienen en la RAM).

El hardware

El ordenador de la nave era un Power1/RS6000 de IBM, conectada a un bus VME con interfaces para la cámara, la radio y un bus 1553. El bus 1553 tenía dos partes, una usada para navegación espacial (aceleradores, válvulas, sensor solar y scanner de estrellas) y otra para el aterrizaje  con interfaz para el acelerómetro, radar de altitud y lo sinstrumentos meteorológicos-científicos: el ASI/MET. El hardware del 1553 fue heredado de la sonda Cassini y tenía un modo de funcionamiento simple y obligatorio, el software controlador y toma de datos debía planificarse exactamente cada 0.125 segundos (u 8 Hz).

El software

El sistema operativo usado era el VxWorks, adaptado específicamente al procesador RS600. VxWorks es un Unix de tiempo real desarrollado por Wind River y comprada completamente por Intel hace pocos días (el 17 de julio). La arquitectura del software era la siguiente:

1. bc_sched: Era la tarea con máxima prioridad y se encargaba de preparar las “transacciones” para el siguiente ciclo de 0.125 segs sobre el bus 1553.
2. entry+landing: La tarea con la segunda prioridad, ya inactiva.
3. bc_dist: La tarea de tercera prioridad, toma datos del 1553 y las coloca en un doble buffer circular desde donde extraen información las otras tareas, salvo las ASI/MET.
4. Otras tareas de baja prioridad de la nave.
5. ASI/MET: es la tarea de menor prioridad junto con las otras tareas científicas (generación y compresión de imágenes, etc.). A diferencia de las otras tareas, la ASI/MET toma datos al 1553 a través de un mecanismo de comunicación entre procesos usando el pipe() de vxWorks (es estándard de Unix).

El problema

Luego de detectado el problema se obtuvieron datos de debug del Mars Pathfinder y se simularon condiciones similares con un sistema gemelo en la Tierra trabajando junto con desarrolladores de VxWorks.  Luego de 18 horas de simulaciones descubrieron lo que estaba pasando: por sobrecarga de tomas de datos –era mejor de lo que se esperaban– el sistema estaba más cargado que el peor caso probado en Tierra y ocasionaba la inversión de prioridades que impedía que la tarea bc_dist pudiese acabar… por culpa de la ASI/MET, aunque esta era de menor prioridad.

Inversión de prioridades

Este es un tema que ya se conocía en la “culturilla” informática, aunque no había nada forma ni soluciones hasta 1980 que se presentó una solución en el artículo Experience with processes and monitors in Mesa. Actualmente es un tema muy estudiado en las asignaturas de sistemas operativo o concurrencia, pero sobre la cuál no hay un consenso unánime sobre la mejor solución, aunque la más usada y simple es conocida como herencia de prioridades.

La inversión de prioridades es un problema que se pueden presentar en todos los sistema de multiprogramación cuando se usan mecanismos para controlar la exclusión mutua al acceso de recursos compartidos –como los semáforos mutex–. Antes que un proceso pueda acceder a esa sección crítica debe hacer una operación de wait sobre el semáforo, esta operación puede generar que el sistema operativo bloquee a ese proceso hasta que el proceso que está en la sección crítica en ese momento salga de ella.

Pero puede ocurrir lo siguiente.

Supongamos que A sea el proceso de mayor prioridad, B una de prioridad intermedia y C la de menor prioridad. C entra a una sección crítica, mientras está en ella es “quitada” –preempted– de la CPU para ejecutar el proceso B que tiene mayor prioridad. En ese momento A se ejecuta e intenta entrar en la misma sección crítica que C, como C está en ella A es bloqueado y el planificador del –el scheduler– sistema operativo vuelve a ejecutar el proceso B.

Es decir, C nunca sale de la sección crítica porque hay un proceso B con mayor prioridad, A que tiene mayor prioridad que los demás tampoco se ejecuta porque está esperando que C salga de la sección crítica… pero ésta no sale porque B tiene preferencia.

Este efecto es el conocido como inversión de prioridades y es lo que pasó en el Mars Pathfinder, bc_dist es equivalente a A, las otras tareas de baja prioridad de la nave son B y ASI/MET es C. ASI/MET fue preempted durante  la llamada a la función select() (también estándar de Unix) que daba “acceso” al descriptor del pipe. Esta llama entra a una sección crítica mediante un semáforo mutex que es el que ocasionó la espera infinita de bc_dist.

El diagrama siguiente (obtenido de este PDF) muestra gráficamente lo que acabo de describir:

Cuando se ejecutaba bc_sched, la de mayor prioridad de todas las tareas, ésta detectaba que bc_dist no había acabado su ciclo y reiniciaba el sistema.

Nota: la terminología más apropiada quizás sea “proceso” en vez de “tarea” (no conozco más detalles de cómo están implementados), pero preferí respetar la terminología de los informes oficiales.

La solución

VxWorks sí tenía la opción de habilitar la herencia de prioridades, pero el JPL de la NASA había decido no habilitarla ya que era una variable global que afectaba a todos los semáforos. Una vez confirmado que se trataba de un problema de inversión de prioridades pidieron a VxWorks que analice el efecto global, estos respondieron que afectaría muy poco al rendimiento y que el sistema se comportaría de la misma forma siempre que hubiese un sólo proceso en las colas de espera de los semáforos. Como éste era el caso decidieron que habilitarían la herencia de prioridades de forma global.

Pero no tenían forma de cambiar esa variable directamente en el Mars Pathfinder, el procedimiento era que se debía enviar un parche binario con las diferencias entre el software de Marte con el que tenían en Tierra. Así que tuvieron que seguir este procedimiento, generar el parche y enviarlo por radio a Marte donde un programa preparado lo valida estrictamente y luego lo aplica (es similar  por ejemplo al sistema de parches que se usa para actualizar los teléfonos con Android).

Este “parchado” quizás debería figurar como la actualización remota más lejana realizada a un sistema operativo.

Más información:

• ¿Qué pasó realmente en Marte? [*]
• Página web del Mars Pathfinder

[*] Este es el “resumen oficial” de Glenn Reeves, director del equipo de software de Mars Pathfinder en el JPL de la NASA. Fue una respuesta con correcciones a un resumen de Mike Jones (de Microsoft Research) sobre una keynote de Dave Wilner (CTO de Wind River).

Curiosidad: Como le han “colado” la herencia de prioridades a Linus Torvalds

Linus Torvalds fue siempre reacio a implementar herencia de prioridades en Linux. Lo dejó bastante claro en un email del 2005:

“Los amigos no dejan que los amigos usen herencia de prioridades”
No lo hagas. Si realmente lo necesitas de todas formas tu sistema ya está roto.

Pero resulta que Linux sí soporta la herencia de prioridades desde la versión 2.6.18. ¿Quién lo logró? El fantástico Ingo Molnar. Éste había desarrollado la nueva interfaz de semáforos futex, era una optimización importante ya que casi todo el código se ejecutaba en modo usuario sin necesidad de hacer “costosas” llamadas de sistema en cada operación de semáforos. Estas últimas sólo se hacen en caso de contención entre varios procesos.

Este nuevo método era mucho más eficiente y fue aceptado para el kernel. Años después Ingo introdujo sin demasiada fanfarria –pero muy bien explicado y argumentado– el PI-futex, o lightweight userspace priority inheritance. Así tenemos en Linux un sistema de semáforos con rendimiento similar a los sistemas de tiempo real, además con herencia de prioridades… a pesar que Linus lo había prohibido expresamente tres meses antes. Ingo, genial como siempre

Los que leen habitualmente mi blog conocen mi opinión sobre la “ingeniería del software tradicional”, muchas veces hablé de ello y del “mal” que hacen en general a la profesión, y hasta como limitan la innovación.

Nunca me gustó que se llame “ingeniería” a un proceso que tiene poco que ver con los de las ingenierías tradicionales, entre ellas que las tradicionales poseen una serie de herramientas analíticas y cuantitativas para evaluar y estimar riesgos y tolerancias. En el desarrollo de software no tenemos esas herramientas, quizás nunca las tengamos: no es lo mismo trabajar en la construcción de elementos físicos, limitados por leyes fundamentales de la física, con pocas combinaciones posibles, con la construcción de programas informáticos que no tienen esas limitaciones físicas, ni en las combinaciones posibles.

Este tipo de visión propuesta desde el mismo nombre “ingeniería” nos lleva a errores muy importantes, por ejemplo el de suponer que las construcciones físicas y las matemáticas [los programas] son equivalentes. No sólo hace “daño” a los proyectos que nunca pueden cumplir plazos y presupuestos, sino también a la propia “ciencia” y profesión informática. Es un engaño, fundamentalmente a los propios profesionales. Así se cometen errores derivados como reclamar colegios, regulaciones y normas y procedimientos similares a otras ingenierías: las soluciones equivocadas son más perjudiciales que los problemas abiertos. Además es ponernos una venda en los ojos para no observar el verdadero potencial de la informática, ni para darnos cuenta de dónde está la innovación (que no es precisamente seguir haciendo el mismo software de siempre).

Escribí bastante sobre estos temas, fundamentalmente en apuntes críticos con la creación de los colegios oficiales informáticos. El núcleo de la argumentación es la que comentaba antes, incluso de crear una “pseudociencia” (p.e. en Recursividad, punteros, estadísticas y pseudociencia del software, Diseño, ingeniería, ágiles… y frameworks, Redescubriendo al Dijkstra provocador 18 años después), además enseñado en la universidad como si de leyes científicas se tratasen –quizás lo que más daño hace–.

También critiqué al establishment de la “ingenieria del software”, dominado por tecnológos pocos “científicos” –en su mayoría empleados de grandes corporaciones de desarrollo de software para empresa de Fortune 500– que en ninguna de sus publicaciones científicas presentan los datos para que puedan ser contrastados (algo inherente del software privativo) y sometidos al peer review (que no es aceptable en ninguna otra rama científica). Este mismo establishment ha ignorado durante muchos años al software libre con sus métodos de diseño y desarrollo completamente contradictorios con los propuestos por la “ingeniería tradicional” (muy bien expuesto en al “Catedral y el Bazar” de Eric Raymond).

Muchas de las respuestas que tuve –incluso entre supuestos reputados profesionales– es que “hago daño a la profesión” [sic].

Pero ahora está surgiendo el mea culpa de los gurús incondicionales de la “ingeniería del software”. El reconocido gurú Tom DeMarco (gracias Paco) que escribió el artículo de opinión Software Engineering: An Idea Whose Time Has Come and Gone? (algo así como “Ingeniería del software: ¿una idea de tiempos pasados?”) que es en gran parte una autocrítica a sus ideas y libro de referencia Controlling Software Projects: Management, Measurement, and Estimation.

Resumo sus ideas fundamentales con algunas de sus frases traducidas literalmente:

• Hoy en día todos comprendemos que las métricas de software cuestan dinero y tiempo, y que deben ser usadas con moderación.
• El desarrollo de software es inherentemente diferente de las ciencias naturales tales como las física, por lo que sus métricas son muchas menos precisas para capturar lo que deben describir.
• La frase más citada del libre es «No puedes controlar lo que no puedes medir». Esta frase contiene una verdad real, pero cada vez me sentía más incómodo con el uso que hice de ella. Está implícita en la frase (y en título del libro) que el control es un aspecto importante, quizás el más importante, de cualquier proyecto de software. Pero no lo es.
• Muchos proyectos se han realizado sin demasiado control pero han generado productos maravillosos tales como Google Earth o la Wikipedia.
• Esto nos lleva a la desagradable conclusión que el control estricto es algo que importa mucho en proyectos relativamente inútiles y mucho menos en proyectos útiles. Sugiere que mientras más te enfoques en el control aumenta la probabilidad de que estás trabajando en un proyecto que se esfuerza por generar algo de valor relativamente menor.
• ¿Estoy diciendo que está bien ejecutar proyecto sin control o con un control relativamente menor? Casi. Estoy sugiriendo que deberíamos seleccionar primero a los proyectos cuyo control preciso no importe demasiado.
• Estoy llegando gradualmente a la conclusión que el momento de la ingeniería del software vino y se marchó.
• En los últimos 40 años nos hemos torturado por nuestra ineptitud en acabar proyectos a tiempo y con el presupuesto previsto. Pero como sugerí antes, no debería haber sido el objetivo supremo.
• El objetivo más importante es la transformación, crear software que cambie el mundo, o que transforme una empresa, o la forma en que hace negocios.
• El desarrollo de software es y será siempre algo experimental. Lo construcción real de software no es necesariamente experimental, pero sí lo es su concepción. Allí deberíamos enfocar nuestros esfuerzos. Allí es donde deberíamos haberlo hecho siempre.

Está muy bien que por fin los gurús de la “ingeniería [tradicional] de software” comiencen a reconocer errores y dejar de ignorar a los métodos y filosofías tan habituales del software libre y de proyectos que han sido realmente innovadores desde el punto de vista de gestión de proyectos de software. Todavía se queda corto y esta opinión me deja la misma sensación de dejè vu que me produjo hace unos diez años la moda de lo métodos ágiles y la programación extrema: era algo que ya se veía hace tiempo en el software libre y de hecho era mucho más radical que las “radicales” nuevas metodologías y métricas. Por ejemplo.

Tom DeMarco cita a dos proyectos que le parecen notables para mostrar la contradicción con las ideas tradicionales: Wikipedia y Google Earth. Pero resulta que ambos tienen muy poco que ver y no han sido “seminales” en sus aŕeas.

El software de la Wikipedia [un wiki colaborativo] es muy sencillo y no fue el primero en hacer un programa de este estilo. el éxito e importancia social de al Wikipedia es el proyecto global, y cómo ha conseguido formar una enorme comunidad de gente que comparte valores de fomentar la divulgación libre del conocimiento. Poco tiene nada que ver con “desarrollo de software”, sino con valores y conceptos mucho más amplios.

Google Earth es un programa mucho más complejo pero que ya eran comunes desde principios de la década de los ‘90, con el auge de las estaciones 3D (el líder indiscutible era Silicon Graphics, SGI) y la realidad virtual. De hecho Google Earth surge de la compra de una empresa (Keyhole) que a su vez se basó en otras ideas e implementaciones previas de 1994. El logro fundamental de Google Earth poder acceder a esa cantidad de datos y dejarlos a disposición de todo el mundo, algo que antes sólo podían hacer muy pocas empresas. (En todo caso yo hubiese mencionada a Google Maps, porque mostrar esa información usando sólo HTML y Javascript sí fue una innovación importante, junto con Gmail mostraron el camino del desarrollo de aplicaciones Web/Ajax complejas).

Si yo tuviese que elegir proyectos de software realmente indicativo de las contradicciones con las “métricas tradiconales”, por ejemplo:

• Núcleo Linux: Es muy complejo desarrollaro un núcleo de sistema operativo, la variedad de hardware es enorme, los bugs tienen consecuencias graves, se necesitan mucho conocimientos, tiene una enorme cantidad de elementos independientes, las combinaciones de caminos de ejecución de casi infinitas. Aún así se desarrolló uno que funciona desde los superordenadores más grandes del mundo a los teléfonos móviles, con el aporte de miles de programadores sin ningún tipo de reuniones, coordinación, diseño previo o siquiera documentación básica (ahora ya hay bastantes libros y documentos).
• KDE/Gnome: Dos proyectos complejos, independientes pero competidores e incluso “con esfuerzos inaceptablemente duplicados”, pero que cada uno aportó innovaciones en distintas áreas y se integran o usan en entornos diversos como escritorios completos a dispositivos móviles o multimedias (por ejemplo el Sfari/Webkit que se ejcuta en Mac, iPhones, Androids y Nokias es derivado directo del KHTML de KDE).
• Sistema GNU/Linux o BSD (+ X.org, +GNOME/KDE, +multitud de software): Ejemplo radical de cómo se pueden construir sistemas complejos muy completos basados sólo en una coordinación o consenso mínimó para las interfaces entre ellos. Estas interfaces además son muy simples y no han dejado de evolucionar sin necesidad de “cambios drásticos”.

Cualquiera de los tres proyectos es –en código fuente– órdenes de magnitud más grande que la Wikipedia o Google Earth, además ninguno de ellos dependió de una empresa o fundación, y tienen una complejidad y diversad de uso mucho mayor.

Por eso, está muy bien que empiecen a descubrir todo un mundo allí fuera, que creció y se desarrolló sin seguir las métricas y métodos “tradicionales”. Es aún una mejor noticia que los gurús de la ingeniería del software empiecen la autocrítica de las ideas erróneas que han fomentado durante 40 años.

Estaría ahora muy bien que los fanboys de esa “ingeniería” empiecen a aceptarlo. Pero sería mucho mejor que los responsables de planes de estudio y asignaturas de “ingeniería del software” en las carreras informáticas sean conscientes del problema, al menos ya tienen a uno de sus gurús poniendo en dudas los cimientos de su [pseudo] ciencia. Quizás así dejaremos de leer y escuchar falacias tales como “para ser buen director de proyecto no hace falta saber programar”, “un proyecto es malo si no tiene un diseño previo bien especificado y documentado”, o el mantra:

[...] podemos y/o debemos gestionar un proyecto de software de la misma forma que un proyecto de arquitectura.

Futurología: en unos pocos años veremos que el hot topic en las publicaciones de ingeniería del software serán estudios de caso de grandes proyectos de software libre. Nos hablarán de la radicalidad de los métodos ágiles usados, la coordinación debil, el software evolutivo, la complejidad de las relaciones sociales entre programadores y usuarios, la influencia del uso real de los usuarios para el diseño del software, la importancia del release often, del peer review, los casos reales de uso no previstos por los programadores… y volveré a sentir una sensación de dejà vu.

El título es un homenaje a la excelente serie United States of Tara (que me tiene toda la semana en espera para verla los lunes por Fox Paramount). Se trata de una mujer ama de casa –protagonizada muy acertadamente por Toni Collete– que sufre del trastorno de identidad disociativo. Sobre este último está relacionada esta curioso historia que nos pasó ayer, si la hubiese seguido un psiquiatra [*] seguramente habría sospechado del mismo trastorno

El resumen del historia.

En el Menéame somos muy estrictos controlando el envío y votos con usuarios clones, como así también el astroturfing.   Dedicamos mucho esfuerzo desarrollando el software para que lo detecte automáticamente, y también “horas-persona” controlando y verificando. Somos muy estrictos con esto ya que al principio del menéame empezamos a notar era el truco usado por empresas y redes de blogs para promocionar artificialmente sus envíos. Además de ser una “trampa” nada honesta, es injusta ya que perjudica a los pequeños blogs que no tiene los recursos o tiempo para dedicarse a crear muchas cuentas, reiniciar routers, comentar con “personalidad disociada”… o simplemente que sus principios les impide hacer este tipo de trampas [**]

Digamos que hay un blog XYZ y dos usuarios clones A y B. Hace dos días A hace su segundo envío, ambos del blog XYZ. Casi inmediatamente el usuario B comenta en la misma noticia. El sistema nos avisa de posible astroturfing, vamos a verificar y vemos que:

• A y B son usuarios clones, usaban el mismo ordenador, el mismo navegador e incluso el mismo perfil (el software del menéame detecta esto, cualquier programador podría encontrarlo rápidamente).
• B había votado los dos envíos de A a los pocos minutos, para poder hacerlo tuvo que reniciar su router para coger una IP diferente.
• B también había comentado en los dos envíos de A, por supuesto con opiniones favorables.
• Un usuario deja un comentario diciendo que es “spam”, el usuario B afirma que el blog es de él y le pide a A que deje de enviar de su blog para que no crean que B hace spam.
• El email de A es XYZ@gmail.com (el mismo nombre que el blog que B dice ser el autor).

Verificados todos esos datos procedemos a banear el blog temporalmente –un mes– y deshabilitamos al usuario A. Dejamos un comentario en el mismo envío enlazando a las normas y copiando el texto específico:

meneame.net/legal.php#tos
El usuario se abstendrá de crear múltiples cuentas con el fin de promocionar sitios webs, participar en discusiones simulando las opiniones de personas distintas (astroturfing)…

A las pocas horas –ayer– recibimos el siguiente email de queja:

Humillación y baneo injusto a unos usuarios legítimos

Han cometido un error al banear al usuario A por astroturfing, ya que es una persona diferente al usuario que hay detrás de B. Le expongo los hechos, punto por punto:

• Yo soy B y A es mi hermano.
• El blog es mío y no quería aparecer en Menéame ya que, como todos sabemos, las visitas que genera son de muy baja calidad (con esto me refiero a esporádicas y con un índice bajísimo de fidelización). Tampoco quería que mis contenidos enriqueciesen a unos pocos listos, cosa que a mi no me pasa al querer ofrecer un blog libre de publicidad.
• Hace unos días le dije a mi hermano que se registrara en Menéame (craso error, ya que en su lugar debería haberme ido yo) y él quería enviar noticias. Sin embargo, la mayoría de las noticias de sus blogs preferidos ya estaban meneadas y enviaba las de mi blog. En los comentarios de la noticia en cuestión le digo que no menee mis noticias.

Revisen los comentarios y verán que se han equivocado. Sin embargo, sé que no lo reconocerán por vuestro afán de poder y ego desmesurado ¡Qué lástima que no aprendieran nada sobre el abuso de poder en aquella revolución virtual que hubo!

Por último me gustaría hacerle llegar la opinión de mi hermano y que yo comparto: Sois unos auténticos dictadores. Espero que se dignen a responder a estos ex-usuarios que con sus actividades algo habrán contribuido a vuestros cuantiosos ingresos, cosa que dudo de unos tipos de tal catadura moral.

Emails como estos, de clones que niegan ser la misma persona y que contratacan con insultos e incluso amenazas de publicar en blogs, son cosas casi de todos los días. Pero tenía varias cosas que me llamaron la atención y me parecían que tenían chicha para averiguar qué más había:

• Habla de “baja calidad” y “fidelización” para un blog que tiene sólo dos entradas y que habían sido enviadas al Menéame en menos de 24 horas.
• Sabía el truco de reiniciar routers para poder votar la noticia de su otro clon. Hablaba del banday –la típica excusa– así que no podía ser un usuario novato ni con intenciones de “arreglarlo”, sino lo contrario.
  
• Nos acusa e insulta siguiendo el “patrón habitual” del  que escribirá un apunte comentando lo malos-malosos que somos los del Menéame.

Así decido contestar y enterarme qué o quién estaba por detrás. Recibimos la respuesta, la parte interesante:

Perdóname Sr Gallir por estar de vacaciones en mi casa y hacer uso del ordenador familiar. También perdóneme por no empezar todos mis comentarios con un ¿Sabía que el usuario A es mi hermano?

Le voy a ser sincero, lo del cambio de IP fue precisamente porque creí que podían pensar que estábamos haciendo astroturfing y supongo que no hay medios para saber si verdaderamente hay dos personas. Después pensé que era una paranoia mía y no volvía a hacerlo.

Seguían sin cuadrarme las cosas, el email de su hermano era en realidad el del blog, más los votos y comentarios en ambas noticias desde el mismo perfil del navegador y con pocos minutos de diferencia nos hacían estar casi seguro de que no era toda la historía.

Respondí nuevamente.

El siguiente email aclaraba todo el asunto, o no, pero al menos es un poco más creible:

Le voy a contar toda la verdad para terminar de una vez con esto. El autor es A (mi hermano pequeño) que inició el blog a petición mía para que se introdujera en este mundillo. Me dijo que meneará algún post suyo para darse a conocer, pero yo no podía debido a que no tenía el karma suficiente. Se registró y meneo su primer post. Me dijo que le habían acusado de Spam, y para que no lo masacraran a negativos dije que el blog era mío. No hay astroturfing, sólo un caso muy dudoso (sólo dos post) de Spam. Le cuento esto para que sepa la verdad, ya que no me gusta mentir. Créalo o no, sinceramente me da igual.

Una historia muy curiosa (mi respuesta final), de las tantas que tenemos y que la falta de tiempo, obligada discreción y la LOPD nos impide contar con toda su sofisticada belleza disociada que envidiarían hasta los guionistas de United States of Tara

——

[*] Uno de los admins del Menéame es un reconocido psiquiatra madrileño –un puto crack como profesional, mejor aún como persona–. Muchas veces nos asesora en estos temas, y me parece que muchas veces tampoco encuentra explicación

[**] Este control es lo que más problemas y críticas genera. Muchos de esos apuntes de blog criticando tan ferozmente porque somos unos fascistas dictadores censores, o que no permitimos la promoción de blogs son derivados de las medidas que tomamos cuando detectamos estos abusos con clones. Lo que pasa es que esa parte de la historia no la cuentan, ya nos lo tomamos casi en broma, pero antes me afectaba mucho personalmente.

El tema de los concursos y rankings de blogs nunca me ha gustado demasiado. Hay muchos bien intencionados, pero en general se suele usar como herramienta de promoción. ¿Cuántos son los blogs que no mencionan o enlazan los rankings donde aparecen o los concursos que han ganado?

En Menéame hemos discutido varias veces sobre el tema. A veces, viendo la calidad de algunos blogs y el éxito que tienen en votos o publicadas nos daban ganas de entregarles un premio, por ejemplo obteniendo la lista de blogs más publicados se pueden obtener muchos premios: los más populares, los revelación, los más votados, los que más se envían. No nos costaría casi nada, extraer datos, imprimir unos diplomas y un apunte en el blog. Pero siempre nos echamos atrás,  la siguiente es la lista de los merecidos candidatos de premios que nunca hemos entregado en el último año (las estadísticas son del último año, el número de la derecha es el número de publicadas):

Actualización: @Kurioso se curró unas hojas de cálculo ordenadas por tres parámetros: porcentaje de publicadas, enviadas y publicadas.

• Aldea Irreductible, 107
• Fogonazos, 62
• Abadia Digital, 55
• Ver tele, 54
• Maikelnai, 53
• Alt1040, 47
• Ciencia Kanija, 45
• Kurioso, 41
• Formula TV, 38
• Microsiervos, 38
• Mi mesa cojea, 37
• Enrique Dans, 35
• Vaya Tele, 31
• Desequilibrios, 30
• Manel, 30
• Historias con historia, 29
• Neoteo, 29
• Genciencia, 29
• Rayos y centellas, 28
• Diviendo entre cero, 24
• No puedo creer, 23
• Matías Callone, 22
• David Bravo, 22
• Mangas verdes, 21
• Gran angular, 21
• JR Mora, 21
• Genbeta, 21
• Electrónica fácil, 21
• El blog salmón, 20
• Pixfans, 19
• Fotos de tiempos pasados, 19
• Eliax, 17
• 233 grados, 17
• Elzo Meridianos, 17
• Sin dinero, 17
• Alpoma, 17
• WTF.Microsiervos, 17
• Tu experto, 16
• Gizmodo, 15
• Curistoria, 15
• Por antonomasia, 15
• Rinzewind, 15
• Samuel Parra, 15
• gallir, 14
• Fayerwayer, 14
• Vergara, 13

Pero la lista es injusta por varios motivos:

• Los blogs más leídos son en general los más enviados, con las listas de este tipo sólo se realimenta la endogamia (aunque claramente hay blogs nuevos que son revelación, como el de kurioso, aldea irreductible, mimesacojea, dividiendoentrecero…)
• Hay blogs que escriben con mucha frecuencia, en cambio otros unos pocos al mes por lo que es difícil que puedan estar en el “top” de publicadas (salvo algunas de las “revelaciones”)
• Hay blogs muy buenos que no se envían o votan (por ejemplo porque sus lectores no conocen Menéame).
• Hay autores que son usuarios de Menéame, con sus amigos y seguidores, y otros que promocionan ellos mismos (o sus amigos) en otras redes o sitios.
• Que escriba sobre temáticas que no interesan en Menéame, o que cuando lo hace es un tema del que ya se ha hablado mucho y luego recibe votos de “duplicada” o “cansina”.
• etc. etc.

Son tantos matices que habría que explicar que para eso es mejor no hacer ninguna lista. Pero aún más problemas. Hacer rankings y dar premios es una buena medida de promocionar el sitio, y aunque al principio lo hagas con buena voluntad una vez superado el límite y comprobado que genera páginas vistas y enlaces es muy difícil resisitir la tentación y volver atrás.

¿Bajan las visitas en verano o vacaciones? creas otro ranking, ¿surge un competidor? creas otros premios, ¿disminuyeron los ingresos publicitarios? inventas unos premios patrocinados, ¿necesitas más ingresos? mezclas noticias con publicidad sin diferenciarlas… y así hasta que te has dado cuenta que has perdido la neutralidad [*] y toda la credibilidad.

[*] Hace poco tiempo, durante el lanzamiento de la Fonera 2, Martín Varsasvky –socio de Menéame– nos pidió contratar publicidad en el Menéame con un pequeño descuento. Le dijimos que no podíamos ya que aunque pague precios de mercado la gente no se lo creería, pondría en dudas nuestra neutralidad. Le pedimos que lo contrate como todos a través de Social Media SL, así lo hizo, y ambos perdimos algo de dinero, pero cuando hay dinero de por medio se debe ser extremadamente cuidadoso.

Tampoco me agrada demasiado el tema de la “promoción 2.0″, antiguamente conocida como “spam”. Una de las técnicas más usadas por las empresas es hacer que hablen de tí y conseguir enlaces, por ejemplo vía virales… o hacer concursos que para participar hay que escribir sobre la empresa que patrocina –y paga– el concurso.

Este último caso me parece la peor de las técnicas SEO-spammer: gastar muy poco dinero en premios “geek” y obtener a cambio muchos apuntes que terminan siendo igual que los patrocinados, pero aún más barato. La regla en Internet es sencilla. Puedes engañar a unos pocos por mucho tiempo, o a todos por poco tiempo. Pero nunca se puede engañar a todos durante mucho tiempo.

Sin embargo este tipo de virales y concursos promocionales se ha vuelto tan común (por ejemplo con los hashtags de Twitter) que hasta la la Asociación de Anunciantes online publicó un estudio para generar un código de conducta.

Esta reflexión me vino de una “conversación” por Twitter que acabó de forma bastante desagradable. No pondré nombres ni enlaces porque con el típico maniqueismo se verá como una pelea entre empresas (será imposible, pero no ayudaré, ni estaré de acuerdo).

Hace pocos días estuve en Gijón, conocí a una persona que trabaja en una empresa relacionada con blogs bastante conocida, me enteré que tenía Twitter y lo agregué inmediatamente (soy bastante conservador agregando gente a mi lista, no quiero repetir mi pésima experiencia con FriendFeed y el autobombo-spam exagerado).

Esta persona puso ayer un enlace para una encuesta sobre un concurso que organizan, como no quieren ser como “otros” –seguramente como el de 20Minutos– afirmaban que querían oír las opiniones de sus lectores y por lo tanto pusieron una encuesta sobre si preferían la “nominación” o la “inscripción”. Aunque no soy amigo de esos concursos de blogs me pareció interesante e incluso voté (aunque luego verifiqué que se puede vitar varias veces, aunque como tampoco pude ver los resultados no sé si se contabilizan correctamente).

Pero hoy pone otro enlace de otro concurso que organizaban. Éste era patrocinado por una empresa –con claras intenciones de promoción–, los premios consistían en tres “ultraportátiles” y para participar había que escribir apuntes hablando de la empresa. Obviamente no estuve de acuerdo, esta fue la conversación después que ví el enlace que pasó por Twitter:

- Yo: ¿No os da ni un mínimo de repeluz esas técnicas SEO-spam “bloguea sobre nosotros para participar en el concurso”?

- Otro: 140 caracteres no son suficientes para explicar un modelo en el que todas las partes ganan, más allá de técnicas SEO.

- Yo: Ganan sólo *tres* partes, pierden credibilidad las demás. Solo una forma de hacer promoción comercial gastando casi nada… después criticamos a las revistas que no separan publicidad con información, esto es lo mismo, o peor

- Otro: hay libertad absoluta a la hora valorar. Es lo que debe tener en cuenta una empresa cuando entra en La Conversación.

- Yo: ¿Valorar qué? ¿libertad? ¿la de falsear “La Conversación” [sic] pagando con la participación en un concurso? Malas excusas new age.

- Otro: no son excusas

- Yo: Ah, vale, supongo que la inclusión de palabras grandilocuentes como “libertad” y “La Conversación” en mayúsculas lo dejan claro

- Otro: ya te dije que hay mil argumentos. De todas formas, gracias por referirte a nosotros después de 7 años, aunq sea para mal.

- Yo: WTF??? Tuiteas el enlace de un concurso de tu empresa, ante la mínima crítica es de *malvados*. OK, ¡es genial! (vaya sensibilidad).

En pocas palabras. Un día afirmo que quiero hacer un concurso de otra forma, con la opinión de los lectores. Al día siguiente hago autobombo de otro concurso con la filosofía contraria. Si se critica al concurso no sólo que no doy argumentos, también uso palabras grandilocuentes como “libertad” y “Conversación”, y si no cuela recurro a la falacia: nunca has hablado bien de nosotros en años, ahora no tienes derecho a criticarnos (y seguramente tienes interés en jodernos).

Lo siento, pero no era nada personal, si no dije nada antes es porque no te seguía en Twitter ni lo que hace tu empresa (ni siquiera sé cuál es tu relación con la misma, lo siento, soy despistado), y fundamentalmente porque no pude callar con algo que me chirría tanto. Supongo que ya está claro que no me agradan los concursos, menos aún los promocionales para generar buzz de terceros que pagan sólo por publicidad y que no se gastan mucho dinero.

Ahora también debo decir que me alucina eso de decir que se está interesado en la opinión de los lectores y escribir “La Conversación” para que a la mínima opinión crítica en una “Conversación” se mande a tomar por culo al interlocutor con las tópicas falacias maniqueas, con lo fácil que era explicar en varios tuits o en un apunte.

¿Lógica? La que convenga en su momento. ¿Conversación? Sí, sólo si eres siempre que vayas de buen rollito y estés de acuerdo con la “ética” de mis negocios.

Disclaimer: Quizás mi manía contra concursos sea excesiva, podría ser resultado de haber tenido un padre ludópata que perdió absolutamente todo por culpa de su adicción.