• Falta de incentivos, o incentivos equivocados.
• Dar mayor importancia a cumplir los planes establecidos sin desviaciones que aceptar cambios no planificados para mejorar la calidad del producto.
• La carencia de programadores con experiencia, o el exceso de programadores recién graduados.

Es muy interesante la lectura, desvela los problemas de gestionar y programar sistemas complejos. Cualquier economista explicaría que hay que establecer los incentivos adecuados, sobre todo en entornos como la programación donde se trata de desarrollar sistemas tan complejos que tienen más componentes que el avión más grande del mundo y tantas formas de interacción -muchas órdenes de magnitud superior a cualquier sistema de componentes físicos- que escapan a nuestra capacidad de comprensión.

Ese incapacidad cognitiva de siquiera conocer la magnitud de la complejidad hace que sea imposible hacer un diseño inicial que tenga en cuenta todas las interacciones y casos. Por ello es imposible asegurar que no haya bugs y, por supuesto, que el sistema desarrollado sea eficiente. Eso requiere, tal como ya lo contaba Brooks en los ’70, el “mantenimiento” de los programas, que consiste en la mayor parte del ciclo de vida del software. Ese mantenimiento no consiste sólo en arreglar problemas, también en mejorar el código (para controlar mejor la creciente complejidad) y la eficiencia.

En el núcleo Linux es un buen ejemplo en ese sentido: se usaron las ideas y principios de modularidad de Unix, es software libre con todo a la vista del público (el código, y las discusiones técnicas), la gestión de Linus Torvalds (y los responsables de módulos) han creado una comunidad muy meritocrática (talk is cheap, show me the code) donde el respeto a los clientes (desarrolladores de programas a nivel usuario) es prioritaria, revisión de pares, se debate con dureza cada propuesta y cambio, se critica duro al que presenta propuestas malas, pero también se reconoce y halaga al que consigue mejorar funcionalidades ya establecidas y maduras.

Esa es una de las principales diferencias que se extraen del artículo.

En Microsoft [presuntamente] no funciona así, los responsables de módulos tienen más razones para rechazar mejoras que para introducirlas,  los Project Managers no ven con buenos ojos que haya desvíos del plan de trabajo, los grupos de testing no quieren saber nada de volver a probar y adaptar unidades de verificación. Es decir, no hay incentivos para mejorar las funcionalidades existentes y que no sean prioritarias en la empresa. En consecuencia, la eficiencia de sistemas con modelos de desarrollo más similares a Linux acaban siendo superior, sobre todo en las áreas y funcionalidades ya maduras.

Otro de los problemas que se menciona es el abandono de los programadores senior y la contratación de nuevos que acaban de salir de la universidad. Estos no son capaces de valorar la complejidad del sistema, ni de conocer por qué fueron tomadas las decisiones técnicas anteriores.

Este último punto es interesante, sobre todo en un gremio -y en un país- donde se valora poco la experiencia de los programadores. Salvo las empresas punteras en desarrollo de software equiparan los [excelentes] salarios de los programadores con la de los gestores (no es nada raro que un programador senior de Google cobre 150.000€). Ocurre en muchos países, pero sobre todo en España, tener 40 años y seguir programando parece más un fracaso profesional que el éxito de un programador apasionado.

Tampoco es culpa de las “empresas” o el “mercado”, desde la propia universidad solemos transmitir el mensaje equivocado:

Un ingeniero informático no programa, dirige proyectos

Ese mantra lo oí muchas veces y los alumnos lo escuchan frecuentemente en clases. El error es múltiple, por un lado transmitimos la idea que un ingeniero graduado sabe todo lo necesario, que no hace falta experiencia en programación, y que programar es de pringaos.

Además de lo mejorable que es nuestra educación, y como últimamente me está apasionando el tema de gestión de desarrollo de software, del comentario me han quedado algunas cosas más claras:

• Los planes y metodologías son herramientas, no un fin en sí mismo, como terminan de creerse sus responsables y evangelistas.
• Se deben crear incentivos, no sólo monetarios, para motivar a que los programadores desarrollen mejoras para cualquier parte del sistema. Esto implica, entre otras cosas, descontar un porcentaje de los recursos disponibles para implementar nuevas funcionalidades y reservarlos para mejora de la “calidad global”.
• Valorar debidamente a los programadores experimentados, que empieza por reconocer -sobre todo entre nosotros mismos- las carencias inevitables de un recién graduado, y la rápida evolución de la ciencia y tecnologías informáticas.
• Debemos empezar a esforzarnos en formar a profesionales cuyo objetivo sean jubilarse como programadores, no sólo un camino intermedio para lograr mejores salarios en otros puestos de gestión o dirección.
• Sobre todo, reconocer que tenemos problemas cognitivos para visualizar mental y adecuadamente la enorme complejidad de los grandes sistemas informáticos.

Hace dos años:

Hace un año:

Hace seis meses:

Ahora:

El último fin de semana:

Conclusión: Android es el segundo sistema operativo, iOS es el tercero. Por encima de Mac y GNU/Linux. Android e iOS representan el 30% de las visitas. La inmensa mayoría del crecimiento se dio en los últimos dos años.

¿Cómo están los medios adaptándose a este cambio tan radical de la forma de acceder a las noticias?

Por las capturas de algunos de ellos (en un Galaxy Nexus, tomadas casi al azar, de las últimas 3 páginas de portadas de Menéame), veréis que en general muy mal. Sólo tres tenían una versión optimizada para móviles. Los demás es la misma versión web, que obliga a hacer zoom en la pantalla, a veces con pésimos resultados. Y en la mayoría la página tarda eones en cargar, especialmente por la publicidad. En otros incluso te aparece un intersticial con el botón de cerrar tan pequeño y tan en el borde, que es casi tarea imposible.

Todos nos haríamos un favor si se molesta menos al usuario, a veces basta con ocultar una columna con el CSS, y/o quitar una parte de la publicidad.

Hace cinco años escribí un apunte muy largo sobre este tema: Sintonizar universidades y empresas, pero ¿qué debe saber un ingeniero? (y hay más, de gente más importante y valiosa que yo, como ¿Qué deberíamos enseñar a los nuevos desarrolladores? de Bjarne Stroustrup), ahora intentaré ser muy breve para contestar a esos dos temas.

No creo en ello, ni afirmé, que se deba enseñar GNU/Linux porque es lo que demanda el mercado, sólo demostré la falacia de justificar su casi prohibición en la universidad basada en el argumento que no es lo que el “mercado quiere”, o que es “poco profesional”  (prometo que me cansé de oír esas frases repetida por los burócratas de las TI de mi universidad).

No sé qué tecnologías se usarán dentro de diez años, pero vista la evolución actual (Linux hasta en los bolsillos…), apostaría a que es más probable que siga habiendo un uso importante de Linux y sistemas derivados. Con lo que eso provoca social, económica, y empresarialmente.

Aún así, no me cerraría en ello, si viese que surgen alternativas diferentes, tecnológicamente seductoras, prometedoras, y con una comunidad de frikis early adopters entusiasmados, las analizaría con mucha curiosidad y dejaría que esa comunidad crezca y ponga sus herramientas al límite. Si fuese una autoridad académica, haría lo posible para favorecer esas iniciativas, porque no podemos estar seguro de si será nuestro entorno profesional del futuro.

Lo que nunca haría es basar decisiones universitaria-académicas únicamente a lo que el “mercado demanda”, y mucho menos intentaría perjudicar a iniciativas alternativas al status quo. Sólo de una cosa estoy seguro: el status quo tiene caducidad, aunque no sepamos la fecha.

Por otro lado, son típicas las quejas del tipo (ejemplo real, de Twitter)

Salí de la universidad sin saber qué era un servidor de aplicaciones. ¡Qué atrasados!

En este caso en particular, no veo el problema. Un servidor de aplicaciones es sólo un servidor que implementa paso de mensajes distribuidos con mecanismo de rendevouz cliente-servidor (i.e. el servidor espera por conexiones que inician los clientes), y sincronización general de llamada a procedimientos remoto (i.e. bloqueo del emisor hasta recibir respuesta del receptor, en este caso el servidor), con técnicas para minimizar los tiempos de esperas, como mantener un pool de hilos en marcha (i.e. temas simples de gestión de procesos).

Conociendo esos temas fundamentales -los estudiaron en redes y algoritmos concurrentes y distribuidos- no hace falta conocer al detalle la tecnología de un fabricante o plataforma en particular (en este caso seguramente se refería a la plataforma Java 2 Enterprise Edition) para poder coger el manual y empezar a producir en pocas horas.

Otro tipo de queja habitual es (elijo este ejemplo porque además incluye el hype de moda, NoSQL):

Tuve dos asignaturas de bases de datos relacionales, y cuando voy a una empresa usan NoSQL, que nunca vimos en la universidad ¡Qué atrasados!

Parece creer que las base de datos relacionales tuviesen los días contados, y no involucrase conceptos importantes como álgebra, almacenamiento, atomicidad, concurrencia, serialización de operaciones, etc. Pero lo más importante, el NoSQL es sólo volver a usar los viejos sistemas de bases de datos simples con hashes o B-Trees pero con esteroides: replicación, distribución, índices multi columnas. Con saber los conceptos básicos de ficheros, estructuras de árboles de búsquedas, consultas algebraicas (estudiadas en base de datos) y algoritmos distribuidos ya  se tienen las nociones importantes para saber cómo funcionan e implementan esos sistemas. No tiene sentido que se pierda tiempo aprendiendo los detalles de Redis, Memcached, Cassandra, MongoDB, etc. durante la carrera. El tiempo es limitado, y quizás cuando acaben la carrera en un par de años, esas herramientas hayan cambiado mucho.

Un problema es no saber distinguir los conceptos fundamentales de las implementaciones tecnológicas particulares (y el hype de los vendedores de la plataforma). El otro problema es no saber que, aunque se quejan del tiempo que pasan en clases, el tiempo es finito y es imposible enseñar y entrenar en cada una de las tecnologías y productos que se usan en el mercado. Menos aún si queremos formar a los alumnos para que sean profesionales en cualquier “mercado”, no sólo en el que rodea a cada universidad.

Estos temas más locales, o de formación más profesional -es decir, con entrenamiento que demanda el mercado- deberían dejarse en todo caso para los master profesionales.

Pequeño bonus

Muchos se preguntarán qué conceptos fundamentales deberían conocerse en la carrera, no puedo hacer una lista exhaustiva, pero aquí van unos pocos ejemplos.

Programación en C. Es un lenguaje muy sencillo, pero que obliga a pensar y programar a un nivel muy próximo a la arquitectura de ordenadores. Por ejemplo, saber cómo se almacenan los datos en memoria, y la necesidad de manipular punteros. Esto de una idea del trabajo de los compiladores e intérpretes de otros lenguajes a la hora de convertir gestión de estructuras sofisticadas al nivel de ejecución.

Estructuras de datos. Arrays, listas, colas, pilas, colas con prioridad, heaps, hashes, árboles balanceados, árboles balanceados de búsqueda, árboles radix, representaciones de grafos, B-Trees.

Algoritmos fundamentales. Se debería conocer los algoritmos de ordenamientos y sus análisis de complejidad, diferencias entre P, NP y NP completo, implementar de memoria al menos el quicksort y mergesort. Recursividad, algoritmos de grafos, se debería saber implementar de memoria un depth-first-search, breadth-first search (y su “primo”, el algoritmo del camino más corto de Dijkstra), backtracking, manipulación y operaciones de datos binarios, programación dinámica, algoritmos distribuidos, operaciones matriciales, patrones de strings, expresiones regulares, geometría computacional, etc.

Programación orientada a objetos. Dominar al menos un lenguaje orientado a objetos, como C++, Java, C# o incluso Python (con objetos).

Conceptos básicos de sistemas operativos. Gestión de memoria, de procesos, sistemas de ficheros (se debería ser capaz de implementar un sistema de ficheros completo, uno basado en i-nodos no toma más de 2000 líneas en C, un FAT es aún más sencillo).

Gestión de procesos y concurrencia. Los procesos son la unidad de ejecución fundamental, hay que conocer cómo están estructurados y gestionados por el sistema operativo, y los problemas de acceso concurrente a recursos compartidos (secciones críticas, exclusión mutua, interbloqueo, esperas infinitas, spinlocks, instrucciones de hardware, mutexes, semáforos, monitores, lectores escritores, mensajes, sincronización, etc.)

Administración de Sistemas. Linea de comandos en Unix, programación en shell y en al menos otro lenguaje de scripting como Python, Perl o Ruby. Gestión de procesos, usuarios, grupos y permisos. Comandos más utiles y usados, grep, find, awk, sort, netcat, tcpdump…  Sistema de arranque. Configuración de correo, servidores web, interfaces de red, ssh (y derivados), gestión de claves y certificados, manipulación y recuperación de sistemas de ficheros, sistemas de ficheros remotos (NFS, SMB…).

Esta es una lista pequeña e incompleta, pero creo que forman parte del “núcleo”, de lo que considero debe dominar un ingeniero informático cuando acaba su carrera, en cualquier de las ramas. La mayoría de ellos se estudian en clases (o deberían), pero hay otros que son de “cultura general”, o que deberían aprender los alumnos por sí mismos. Por ejemplo, no tiene sentido que se dediquen horas de clases a enseñar programación en shell o ssh, sino que cada uno debe estar motivado para aprenderlo durante su carrera, o el profesor incentivar a que lo hagan, porque también facilitan el trabajo a los alumnos.

Si eres ingeniero informático y hay algunos de esos temas que no sabes, todavía tienes tiempo de aprender. Muchos de los temas que menciono los aprendí después de acabar la carrera -imagina el nivel, además la hice cuando no había libros de textos de algunos de los temas más novedosos-, a otros los aprendí de verdad cuando tuve que enseñarlos. Es en ese momento cuando te das cuenta de los agujeros del conocimiento que tienes (es la mayor ventaja de dar clases).

Empecé a dar las asignaturas de sistemas operativos en el curso 1993-1994, los primeros dos con Minix (sólo teníamos Macs Performa, y adapté el kernel MacMinix para que funcione en ellas). Luego quitaron los Mac, pusieron PCs con Windows NT y no me dejaron instalar Linux. Tuve que dar un curso con las prácticas con Cygwin sobre esos Windows, o vía telnet al VAX VMS con los alumnos. El primero pasable -aunque doloroso-, el segundo infumable. El C del VMS era muy poco compatible en temas de llamadas de sistemas, y cada clase de viernes a la tarde se colgaba, o fallaba con tantos usuarios.

Finalmente conseguí que el responsable de las aulas informáticas (¡gracias Albert!) me dejase instalar una distro (creo que fue RedHat 5) de estranjis en una partición de 500 MB. Los directivos del centro de cálculo no permitieron que se instale GNU/Linux en ninguna máquina, y mucho menos tener arranques duales (como ya hacían otras universidades). “Linux es inseguro” era la excusa habitual. Y así la pasé canutas para mantener esa distro en los 500 MB de disco hasta 2004 o 2005 que abrimos la primera “aula linux” (actualmente hay dos).

No era sólo la universidad la que se resistía al cambio. Hasta hace pocos años, quizás hasta el 2006  o 2007, al principio del curso recibía la llamada del director del Dept: “Ricardo, recibí quejas de alumnos porque les obligas a  usar Linux (¡y C!)”. Los últimos años ya nos reíamos (¡gracias Llorenç y Arnau!), y respondía: “Usa mi misma respuesta del año anterior”. No sólo que era mentira (les expliqué que pueden compilar con C POSIX en Visual Estudio, o usar Cygwin que es software libre), sino que casi los demás 100 profesores del Dept. les “obligan” a usar Windows, y no se quejan de eso. La excusa de los alumnos, como de algunos directivos, era que “Linux no es lo que demanda el mercado”.

Así, 10 o 15 años después nos encontramos con que lo que “demanda el mercado”, al menos las mejores empresas del mundo, es GNU/Linux. Mucho GNU/Linux. Están desesperados buscando expertos.

Es el problema de pensar que la universidad sólo tiene que pensar en lo que demanda el mercado… en ese momento.

No se dan cuenta que lo que la tecnología del día es lo obsoleto dentro de unos años, cuando nuestros alumnos intenten “entrar al mercado”. Nadie puede predecir el futuro, no sabemos cuál será la tecnología mejor o dominante en diez años, por eso la universidad no puede tener las anteojeras puestas y mirar sólo lo que hay al lado de sus pies. Debería ser todo lo contrario, es allí donde se debe permitir que alumnos y profesores aprendan y juegues con diferentes tecnologías, sobre todo aquellas que están surgiendo ahora, quizás alguna de ellas sean “las del futuro”. Pero no.

Muchas universidades, con el apoyo de los “burócratas de las tecnologías de la información”, se convierten en sitios muy conservadores, donde se molesta, se ponen trabas, o incluso son objeto de burlas los que quieren probar tecnologías nuevas, sobre todo si vienen del “software libre”. Muy contradictorio y triste, pero es lo que observé en mis 21 años de profesor universitario.

Es aún peor el tema en mi caso. En la UIB teníamos una comunidad muy activa de software libre, con ganas y que hizo muchas cosas (como ayudarme a instalar y mantener el GNU/Linux estranjis del aula informática). Podríamos haber sido un lugar de referencia, pero quedó todo en nada. Y no hacía falta invertir muchos esfuerzos, sólo dar pequeñas ayudas y demostrar respeto. Ni eso.

Pasaron 15 o 10 años, y resulta que por esas cosas de la vida, lo que era una cosa de frikis se convirtió en un área muy demandada profesionalmente. Mientras tanto, en muchas universidades (la mía también), sólo unas pocas asignaturas de la carrera se dan sobre GNU/Linux (creo que el 80-90% de ellas son las mías), las demás todas sobre Windows. Tan moderno.

Nadie pedirá cambios, nadie entonará mea culpas, nadie pedirá disculpas por los años que -como directivos y autoridades universitarias- han tocado los cojones a esos “profesores molestos” que no querían usar “lo que demandaba el mercado”, ni era “profesional” ni “seguro”.

Menos mal que sólo me desahogo por Twitter, o mi blog. Algunos ni se avergonzarán de las burradas casposas que hicieron y sostuvieron durante tantos años.

PS: Alerta, antes de extrapolar conclusiones precipitadas de este apunte: Sintonizar universidades y empresas, pero ¿qué debe saber un ingeniero? o El largo y difícil camino de la profesión. O mejor, la continuación de este apunte: Lo que se aprende, o debería, en la carrera de informática.

En 2010, el sistema universitario público español obtuvo 401 patentes. Robert Samuel Langer, un investigador químico del Massachusetts Institute of Technology (MIT), él solo, tiene 810, más del doble.

Desde hace varios años se insisten con estos argumentos, como si las patentes fuesen un medidor válido de la calidad de la investigación. En términos generales no lo es, y menos cuando se trata de medir investigación, la “I” de I+D.

La “certificación” que un trabajo produce un avance en el conocimiento científico se da a través del “reconocimiento de los pares”, que es el proceso más importante de una publicación científica, y uno de los grandes logros de la comunidad científica. Por supuesto, como toda comunidad y organización humana, no es perfecta, se producen errores, y hay niveles. La revisión de pares falla (son humanos, con sus sesgos y manías), no todos los revisores tienen el nivel adecuado, hay errores que no se detectan, y hay revistas que no tienen el nivel adecuado. Pero a la larga, las publicaciones están disponibles  (aunque no todas son gratis ni baratas, otro problema) y los errores se terminan corrigiendo.

Aún con todos esos matices y problemas, la publicación de un trabajo en una revista reconocida, su permanencia con el tiempo, y las citas de otros investigadores, son los que terminan certificando que ese trabajo es de calidad, y que se produjo un avance del conocimiento.

Además, y lo importante, esas nuevas ideas o descubrimiento se van añadiendo al corpus del conocimiento, así se producen los avances científicos, en su inmensa mayoría son pequeños pasos (a veces con pasos hacia atrás para corregir) que se mejoran o corrigen con las aportaciones de los demás, vía las publicaciones de la comunidad científica.

Por otro lado, una patente es un monopolio que otorga un o varios estados a la utilización de una “idea”. El objetivo -original, ya olvidado- era promover que los inventores hagan pública la idea a cambio de un monopolio sobre ella por un tiempo finito (actualmente, de 16 a 25 años). Pero esa “idea” no pasa en ningún caso un proceso de revisión de pares como las publicaciones científicas, es decir, no “certifican” que aporten conocimiento, ni siquiera que funcionen o tengan utilidad. Lo único que hacen es verificar que esa misma idea no esté ya registrada en su base de datos (de la oficina del país que la otorga), y si se detecta que esa patente no es válida, exige esfuerzo y dinero del litigante (a diferencia de la comunidad científica).

Hay multitud de ejemplos de patentes que cuelan sin la mínima verificación de que ya haya “arte previo”  -como la patente a la rueda, en 2001-, a las absurdas patentes de software en muchos países (incluido EEUU, que fue el primero en adoptarlas por una sentencia de la Corte Suprema) que llevan a la creación de empresas sólo dedicadas a crear patentes submarinas para el futuro, o los “patent trolls” que consiguen patentes sólo para amenazar o demandar a grandes empresas, o la multitud de patentes ridículas que se registran sólo para protegerse de demandas -caso muy reciente y conocido, el de Twitter-.

En pocas palabras, las patentes son un “monopolio estatutario”, se está abusando de ellas con fines sólo económicos (muchas veces rozando o cayendo en el fraude puro y duro),  no certifican avance científico, cuestan dinero, y varían mucho entre qué es patentable y cómo se evalúan según las diferentes oficinas de patentes.

¿Qué aporta una patente? La capacidad de recaudar dinero con ella, bien legítimamente usando la idea para fabricar productos -directa o indirectamente vía licencias a terceros-, o de forma ilegítima para conseguir el control de un mercado, o demandar a las que la tienen.

Si el objetivo de una patente es fundamentalmente económico, ¿qué sentido tiene en una universidad pública? Es un tema que pocas veces se debate, y por supuesto, no lo hacen los que usan el “número de patentes” como excusa para criticar un modelo, o halagar otros. Hay un dilema ético: si la sociedad paga a investigadores de la universidad ¿cómo se justifica que esos mismos investigadores -o institución- reclamen un monopolio sobre la idea resultado de la financiación pública?

Es lógico que se pensase en ellas como un incentivo económico para que las universidades recauden más dinero para invertirlo en más investigación. Pero no suele ser el caso. La justificación habitual suele ser “para que otro no la patente, y no podamos seguir con nuestras investigaciones”. Por lo que entramos de nuevo en el problema de fondo, la perversión del sistema de patentes, al que se reclama su profunda modificación desde diferentes estamentos académicos y empresariales.

A esto se suma otro dilema, poco discutido.

A la hora de puntos al currículum de los investigadores universitarios, históricamente, las patentes contaban menos que las publicaciones científicas. Se consideran una “doble bonificación”, la primera es por la publicación, a la que le dan otra adicional por lograr la patente. Pero hay un movimiento dentro de las universidades -seguramente apoyados por los mismos que escriben de las bondades de patentes- de que éstas cuenten igual o más que las publicaciones científicas.

Por supuesto, esos que lo demandan no parecen haberse planteado el dilema. Tampoco parece -dado que los controles de patentes son mucho más laxos que los de buenas revistas científicas- que estén muy preocupados en mejorar la calidad de la investigación. Mas bien parece un intento de poder mejorar el currículum más fácilmente, o de intentar conseguir dinero.

¡Dinero!, pero tampoco parece ser la razón principal, porque si alguien se pone a analizar lo que se recauda por patentes -por fabricación o licencias- quizás se lleven una mala sorpresa. Si están tan convencidos que las patentes son un buen indicador, deberían ir al fondo del tema, no quedarse sólo con su número, sino con cuanto dinero se recauda con esas patentes. Al fin y al cabo es la única forma de medir la calidad de las mismas.

Pero no lo harán, porque esos “académicos” que hablan tanto sobre la utilidad de las patentes -un “monopolio” mercantilista- parecen vivir en una realidad diferente, o pretenden moldear la realidad a su gusto. De hacerles caso, acabaremos reemplazando a la comunidad científica por las oficinas de patentes.

El número de publicaciones científicas, o el “impacto” de las mismas (otra medición, dominada por monopolios empresariales privados) no puede ser el único baremo para medir la salud de un sistema de I+D (como lo llaman ahora, el I+D+i, ese “fraude intelectual” para justificar dinero gastado en empresas que no hacen I+D). Las cosas son más complejas, hay que medir muchos factores diferentes, desde los puramente académicos a otros como la calidad de la formación de profesionales, las empresas que hacen I+D, el nivel tecnológico de las empresas de un país, cuánto invierten en I+D, cuál es el volumen de negocio generado por productos elaborados con las ideas publicadas o patentadas, etc.

Lo que no se puede hacer es engañar al público haciéndoles creer que medir las patentes es un buen indicador, y menos que el objetivo principal de nuestras universidades y centros de investigación sea producir patentes. Crean un dilema importante.

Aún así, si están seguros que el sistema de patentes es el indicado, que vayan al fondo y midan la cantidad de dinero que generan, no los sellos que les puso un funcionario que ni siquiera es experto en el tema. ¡No! dirán, no se puede tratar a la investigación como si fuese sólo un negocio. Lo siento, pero las patentes se usan para eso, lo que no cuentan es que hay tantas patentes basura que no interesan a nadie, y que ya se considera a la perversión como la norma.

PS: Imaginaros un sistema de investigación público donde el objetivo fundamental sea conseguir dinero vía patentes, y en qué se trabajaría, y qué temas de investigación básica, o de “naturales” quedarían de lado. Luego nos quejamos de las “big pharmas” y sus patentes, o que se patenten genes o modelos matemáticos.

Iba a escribir algo muy corto y me salió más largo de lo pensado, si no lo hubiese puesto como apnte aquí. Estoy bastante molesto por cómo se ríen de los que hacen el esfuerzo de hablar inglés en público. Hoy es Ana Botella, pero ayer fueron otros. Un mensaje de burla y castigo al que se esfuerza por superar sus limitaciones.

Es fiable esa tendencia

Hummmm… me la están intentando colar, mejor pregunto a especialistas

Ejemplo práctico analizado con más profundidad en estadísticas por todas partes.

Después de dos años de mucha genta contra la Ley Sinde/Wert dos años, explicando que no funcionaría, el PP la aprueba. Un año después, verificado el fracaso, pretenden modificar la LPI con lo que conocemos como “Ley Lasalle”. Otra vez insisten en “proteger” a un sector industrial (¿cultural?). Este nuevo borrador, de nuevo, entra en conflicto con derechos fundamentales (privacidad de comunicaciones, derecho a defensa, juicio justo) y seguramente producirá efectos negativos en los negocios digitales básicos (como explica Julio Alonso en Diario Turing).

El borrador de la nueva LPI no mejora derechos fundamentales, chirría con ellos.

Tampoco crea o amplía derechos individuales, los reduce.

Su única justificación es la de “mejorar la economía de una industria”, en detrimento de otras.

Como ejercicio intelectual simple, ubique en el gráfico a qué industrias podría favorecer, a cuáles podría perjudicar, y el volumen de negocio (y capacidad de generar empleo) de cada una de ellas. Si encuentra la justificación, me lo cuenta.

Fuentes de cifras

• INFORME 2010 DEL MACROSECTOR  TIC EN ESPAÑA
• Sinde y el 2% del PIB de la industria editorial
• Conviene recordar algunos datos sobre la propiedad intelectual y la ley Sinde

Hace unos días fue la presentación del Galaxy S4, entre otras cosas mostraron su “novedosa” y “exclusiva” aplicación para poner voz a las fotos, muy similar al SpokenPic (prometo que sonreía, no hay mejor halago que una gran multinacional tecnológica haga algo igual casi un año después, y que lo presenten en un gran cutre show como una “innovación”). Eso me hizo acordar que habíamos prometido liberar el código,  que estaba prácticamente abandonado.

El SpokenPic fue un fracaso, sin paliativos[*]. Aunque tiene buenas críticas y estrellitas en Google Play, sólo tuvo 2.000 descargas, y ahora hay sólo 600 instalaciones activas. Aunque nos llevó dos meses de trabajo a tope (no sé cómo sobreviví haber pasado tantos días durmiendo sólo 4 horas, y dándome de hostias con el Java, el API de Android, y hasta la documentación oficial errónea de la cámara), hasta con lanzamiento grupal emocionado (foto de la derecha), lo cierto es que no caló, y que no tuvimos tiempo para mejorarlo, ni siquiera en las funcionalidades que teníamos previstas (como la de clips con múltiples fotos). Visto en retrospectiva, fue el desánimo que nos desmotivó.

Aún así, es una app compleja. Tuvimos que incluir codificación Vorbis en código C, un API de conexión con el servidor que está muy bien diseñado (mérito de Antoni Aloy), y gestión de cámara y audio bastante completo y muy optimizado. Para que sea compatible con versiones anteriores a la 4.0 de Android tuvimos que usar las librerías Sherlock, que además de complicarnos y limitarnos con el código, también lo hizo en la estética (era muy difícil hacer que se vea igual en Android 2.3, 3, y 4.x).

Era una pena que el código estuviese “muerto”, y casi olvidado. Hasta que el anuncio de Samsung me hizo recordar que hay gente que lo considera interesante, que quizás sea útil para probar otras cosas, que alguien quiera limpiar el código haciendo que sólo funcione más eficientemente (usando Fragments) con Android 4.0 en adelante, o incluso que algunas clases puedan servidor para aplicaciones diferentes.

No había más excusas, le agregué al código las notas legales y licencias (GPL3 para el código, CC-SA para los gráficos), y lo subí a GitHub. El proyecto publicado debería compilar correctamente, creo que no falta nada. Si es así, avisadme en un comentario, o mejor, pasadme el parche (en diff) para lo aplique. Lo único que os pido: si hacéis un “clon” de la app, usad otro nombre diferente, y dejad claro que no es el original, no quiero quejas por problemas o fallos de apps de terceros. Por supuesto, no os olvidéis de publicar el código con la misma licencia.

En cuanto tenga tiempo prepararé documentación en inglés con la estructura básica del programa. Mientras, espero que sea útil para alguien.

[*] No me arrepiento, sin probarlo no lo hubiésemos sabido. Los programas exitosos, además de requerir suerte, son minoritarias entre multitud de fracasos. Además, una de las motivaciones era aprender, vaya si he aprendido.

PS: Los chicos de APSL fueron los que desarrollaron toda la parte del servidor. Quizás también sea liberado, pero necesitan tiempo para revisarlo y prepararlo.

La base de datos principal de Menéame está en MySQL sobre Amazon RDS, con Multi AZ, lo que significa que tenemos failback y failover over automático y desantendido si el master falla. Da mucha comodidad, pero también tiene su coste: se paga el doble (el tamaño que tenemos es el large).

Llevábamos varias semanas que a a veces superábamos el 90% de uso de CPU del master, por consumo exclusivo de las consultas web. La solución sencilla pero cara es “escalar verticalmente” la base de datos, pagaríamos el doble. La otra es tener un slave del mismo tamaño, y pagar un 50% más, pero aunque el software lo puede hacer, no me gustaba por la sobrecarga y verificación para enviar las modificaciones (y consultas posteriores del mismo script) sólo al master.

Pero hay otras posibilidades, como el particionado funcional. Es decir, distribuir los datos según las funciones que lo usan. El ejemplo de manual es poner por ejemplo los artículos en un servidor, y los comentarios en otros. Pero tampoco me llega a convencer esta idea. Hay otra que es mucho más sencilla y no requiere particionar la base de datos, sino hacer que algunos scripts consulten a un servidor slave, diferente. Esto es bastante habitual para consultas “pesadas”, u offline.

Ya la usábamos con las llamadas al API para consultar el estado de las noticias, ese botón de Menéame con el número de votos que se ven en algunos sitios. El software permite especificar un servidor diferente por script, pero sólo lo usábamos para ese, para que consulte a un slave de tamaño pequeño, y usado también para otras operaciones, como generar los índices para el buscador con Sphinx.

Era raro que tuviésemos tanto consumo, las consultas más frecuentes ya estaban muy optimizadas, por lo que analicé qué scripts producían mayor consumo. Me llevé una sorpresa. Uno de ellos era el de la notificación de los mensajes y respuestas a comentarios y notas que se muestra en la parte superior (cuando se está autentificado, y que llama cada pocos segundos para actualizar). El otro script que consumía bastante CPU es el que genera el número de respuestas de cada comentario ().

Ambos scripts son llamados desde Javascript, y cuando la página ya fue descargada, por lo que no son “bloqueantes”. La solución fue simple: hacer que esos scripts no bloqueantes y que no necesitan tiempos de respuestas de milésimas se segundos consulten al slave. Para ello aumentamos el tamaño del slave de small a medium (menos de 50 € adicionales al mes), y configuramos para lo usen.

Así logramos reducir la carga del máster de picos habituales superiores al 80%, y medias superiores al 60% durante horas de tráfico elevado, a picos que rara vez superan el 60%, y medias de alrededor del 30%:

Este es el consumo del slave (antes no llegaba al 10%, con una capacidad inferior):

En resumen: haciendo que las consultas que no son necesarias para generar la página inmediatamente consulten a un slave, en vez de al master Multi AZ, hizo que por unos 50€ más al mes prácticamente se duplique la capacidad del master.

Se podría explicar de otra forma: no hace falta que la base de datos Multi AZ esté configurado al máximo, posible, se ahorra mucho usando slaves, que son más baratos y muy fáciles de administrar. Tampoco hace falta que se haga un balanceo de carga entre el máster y el slave, basta con “particionar” las llamadas y hacer que los scripts que no forman parte del fast path, ni necesiten sincronía, usen un slave para sus consultas. Esta solución es mucho más sencilla y barata (no necesita slaves de la misma capacidad que el master) que un balanceo entre slaves y el master (también se podría balancear sólo entre slaves, y usar el master únicamente para updates e inserts, pero es algo más complicado, delicado, y no tan barato).

Cachea todo, ¡estúpido!

Justo cuando estaba dando la charla en Youzzing (en Palma Activa, aquí la presentación en PDF) se produjo la elección del nuevo Papa, lo que hizo que el tráfico se incrementase a valores record, llegamos a tener 10 servidores webs en marcha. Aunque los servidores tenían capacidad de sobra, daba muchos fallos 502, no había suficientes procesos disponibles para ejecutar los scripts. Miré la carga del master de la base de datos, y estaba a menos del 50%, pero cuando fui a ver el slave, estaba al 100%. Era éste el que bloqueaba los scripts durante demasiado tiempo y generaba los errores.

En cuanto llegué a casa (¡maldición, cómo tardó en llegar el taxi!, mientras esperaba bajo la lluvia) me puse a analizar, era el script del API para los botoncitos de Menéame en otros sitios el que producía esa saturación. Estaba generando varios miles de peticiones por segundo al “pobre” slave (de la mitad de capacidad del master), una de las principales responsables fue la página en directo de La Vanguardia, que se recargaba automáticamente cada pocos segundos, haciendo que todos los navegadores vuelvan a consultar al API de Menéame, sumando otra conexión a la base de datos. Desactivé el script momentáneamente (haciendo que devuelva siempre “no”), y vi que la carga se redujo inmediatamente a menos del 20%.

Inmediatamente me di cuenta de cuál era la solución: cachear los resultados durante unos pocos segundos (lo puse para 5 segundos) en el memcached/xcache [*] de cada instancia web, para cada URL que se consulta. Esto hace que se incremente algo el consumo de CPU en cada instancia web, pero de eso teníamos de sobra y su escalado es automático. También incrementa el uso de RAM, pensé que sería mucho -era mi miedo, se hacen muchas consultas de diferentes URLs-, pero luego pude comprobar que no llega ni a 1 MB por instancia.

[*] Podemos usar el memcached o una funcionalidad equivalente del xcache, es configurable. Usamos este último, porque reduce conexiones vía sockets, ahorrando algunos microsegundos de latencia

La modificación para cachear no me tomó mas de 15 minutos, y cuando la habilité, el consumo del script durante esas horas de alto tráfico no llegó ni al 15%.

En resumen, aunque parezca que tienes todo bajo control, siempre ocurrirá un evento que superará tus expectativas, y cuando se trata de consultas a la base de datos, esta es la parte más débil de la cadena. Es decir, si es posible y no provoca problemas es mejor  cachear los datos temporalmente en aquellos sitios que puedes escalar mejor.

Y mi pregunta es ¿por qué no lo hice antes? Hay que ser estúpido.

Nota: uso la palabra “particionado funcional” sin que sea un particionado de verdad, la base de datos es única y completa, pero no se me ocurrió otro nombre para describirlo y que se entienda la idea. Perdón, por si acaso.

Este año me tocó dar Programación Concurrente y Distribuida, por lo que tuve que dedicar tiempo no sólo a aprender los algoritmos, sino a estudiarlos en profundidad para poder explicarlos, responder a todas las preguntas posibles, y además diseñar las prácticas en laboratorio. Así, de tanto estudiarlos llegó un momento que dije ¡hostia, que guapo y simple es!. Me pasó con el algoritmo de Chandy-Lamport para ”snapshots” de sistemas distribuidos.

El estado de un sistema distribuido en un momento dado es imposible de obtener, ni tiene sentido. Pero sí que tiene encontrar un “estado consistente”. Este estado se refiere a qué mensajes se enviaron desde cada nodo (u ordenador), y qué mensajes estaban en tránsito en cada arista (o canal de comunicación). Es lo que hace el algoritmo de Chandy-Lamport. Si estás flojo en algoritmos distribuidos, o no recuerdas, o piensas que es muy complicado, te recomiendo que lo implementes. Es una “belleza”, en muchos sentidos. Pero mejor que lo saborees tú mismo

Alerta

Implementar y probar algoritmos distribuidos en un único ordenador suele ser un coñazo. Hay muchos sistemas, pero hay que aprenderlos. Yo encontré que lo mejor es un sistema de paso de mensajes distribuidos, pero usándolo desde un único ordenador. Creo que no hay sistema de mensajes más simple, y con librerías para casi todos los lenguajes, que el Beanstalkd. Te lo recomiendo. De paso aprendes los conceptos básicos de estos sistemas, si es que no lo sabes. Recomendación: que cada nodo tenga un canal (o tubería en terminología beanstalkd) para recibir mensajes hacia él, es lo más simple, y simula perfectamente un sistema distribuido (cada nodo puede ser un proceso, o un hilo, tanto monta, siempre que las variables de los algoritmos no sean compartidas).

Quizás es recomendable implementar antes el algoritmo de “terminación distribuida” de Dijkstra-Scholten. Se usa la misma estructura de procesos y colas de mensajes, es más sencillo de entender (creo), y también es un algoritmo guapo.

Si implementas esto, y los entiendes, será como andar en bicicleta, no te olvidarás más. Y te gustará más la informática

Nada más conocer la decisión de la compañía, algunos compañeros de redacción se apresuraron a calificar la actuación de Globalia de censura y no pocos me recordaron los infaustos tiempos de Maria Antònia Munar en el Consell de Mallorca.

Aunque a estas alturas ya no debería hacerlo, este victimismo y falta de análisis crítico del colectivo de periodistas no deja de sorprenderme. No entiendo cómo algunos pueden pretender que una empresa privada no sea capaz de decidir como mejor le venga en gana si poner dinero de publicidad en uno u otro periódico [privado].

Sí, es perjudicial para el periódico, y el periodismo en general, que las grandes empresas eliminen la publicidad por las críticas, haciendo aún más difícil el periodismo independiente, y la supervivencia del medio. Pero no es problema de los anunciantes, es problema de la propia fragilidad del negocio propiciado por las propias empresas periodísticas.

Desde hace varias décadas el negocio de los medios, sobre todo periódicos, pasó de estar sostenido en gran parte por numerosos lectores, a que una parte cada vez mayor de esos ingresos sean de grandes anunciantes: la administración -dirigida por los políticos de turno-, y las grandes empresas. Nadie está libre de estas culpas: los anunciantes que no quieren críticas, y los medios que ofrecían el “no disparar contra el anunciante” y vender así a mejor precio sus anuncios.

Con la aparición de los medios on-line, el problema sólo se agravó, se borró de un plumazo el ingreso de los lectores, el precio de la publicidad web es muy baja, y conseguir “grandes anunciantes” es una cuestión prioritaria. Por supuesto, hay muchos menos grandes anunciantes que lectores, por lo que la supervivencia de los medios se basan casi exclusivamente en conseguir que un banco, telefónica, eléctrica o aseguradora pague precios premium.

Independientemente de la honestidad del anunciante, que puede o no exigir contraprestaciones de “no dispararles”, esa dependencia crea ya un hábito de autocensura difícil de evitar, y, sobre todo, una fragilidad enorme a la empresa: su supervivencia no depende de las decisiones independientes y distribuidas de miles de lectores y anunciantes, sino de unas pocas: los directivos de unas pocas empresas.

La fragilidad es la única responsable de este problema, no la censura. Esa fragilidad fue incrementándose con los años, aunque la época dulce de subvenciones del estado (por vías directas -publicidad institucional-,  o indirectas -anuncios de grandes empresas con negocios con el estado-) ayudó a ocultarla, convenientemente. Como la anécdota del pavo, que creía que su buena vida de engordar sería eterna, ya que tenían un cuidador que parecía feliz dándoles de comer… hasta que llegó el día de acción de gracias. Al pavo, como al periodismo, le apareció el “cisne negro” que creían tan poco probable, y no estaban preparados.

La solución para evitar que los “cisnes negros”  te hagan desaparecer es estar preparados, aumentando la robustez para aguantar el golpe. O mejor aún, aumentar la antifragilidad para poder obtener beneficios de esos eventos inesperados. Pero ha ocurrido lo contrario, en muchos aspectos, desde el sistema bancario, pasando por la burbuja inmobiliaria, hasta la situación de los medios.

Al hablar de “censura” no sólo se está tomando una postura victimista (¡no nos pueden hacer eso a nosotros!), también se están reclamando medidas intervencionistas (¡alguien debería hacer algo!), como subvenciones del estado, cobrar a Google, o leyes de copyright más restrictivas para los ciudadanos. Pero eso sólo aumentaría la fragilidad, y los llantos volverían en pocos años.

Si se pretende reducir esa fragilidad, hay que convencer a los lectores de la importancia de un buen periodismo, y que tengan ganas de pagar por ello. Es muy difícil, pero seguro que no se conseguirá con periodismo de baja calidad, con hacerse las víctimas de una injusticia del sistema, ni reclamando que el público -u otras empresas- tienen la obligación de mantenerlos, sólo porque son importantes para la democracia.

PS: Si te llamó la atención el uso de las palabras fragilidad, robustez y  anti fragilidad, te recomiendo este libro.

1. Sí es posible que una persona firme varias veces con correos electrónicos diferentes, sin que se verifique ni que los datos (ni siquiera el código postal) correspondan.
2. No hay verificación de los datos del formulario, ni siquiera para esos emails que ya tienen cuenta creada en change.org.
3. No hay verificación de que el email pertenece a la persona que lo pone, y que esa personas tenía la intención de “firmar”.
4. Sí es sencillo “firmar” automáticamente con un programa.
5. Aunque creador de la petición recibe la lista (en PDF) de “firmantes” (con los datos falsos y sin especificar el email), y que change.org está en EEUU, argumentan que no pueden hacerla pública por la LOPD. Hay algo que no cuadra ¿no?.

A las pruebas, breves y preparadas sólo para esta respuesta, me remito.

Repito, a las pruebas me remito.

Actualización (Feb 7, 10 hs): Por el comentario de Carles Mateu, he modificado el bot, y he logrado cientos de “firmas válidas” y confirmadas con una única dirección de email (desde ayer no puedo acceder a change.org desde la IP de casa, han puesto mis peticiones de prueba con captcha, y eliminaron esas firmas con gallir+xxxx, espero que sea porque solucionaron este problema en general).

Creo que son bastante claras: un programa que demuestra los 5 puntos anteriores (que ya había explicado en el apunte anterior). Solo puede negar estos hechos alguien que ni siquiera conoce en profundidad el funcionamiento técnica de la plataforma, no le interesa averiguar, y que se intente ocultar los serios problemas de poner un sistema de “firmas” en Internet (que no hace el mínimo de verificaciones para asegurarse por lo menos que la dirección de email es de la persona que lo puso. Un requerimiento básico).

Ahora paso a contestar cada una de las respuestas relevantes de Francisco Polo.

Ahora bien, si vuelves a poner todos tus datos, la plataforma te ‘loguea’.

No sé qué explica esto, pero tampoco funciona así, si no sería un problema de seguridad. Podéis probar que sucede “firmando” con mi email -por ejemplo-, os saldrá mi avatar (¿?), pero no estáis logueados con mi usuario.

 Una petición no se puede firmar dos veces, ni tres, ni cuatro con el mismo correo. Con lo cual, lo que se ha dicho este fin de semana es falso.

Falso, demostrado arriba. Y en el apunte anterior, no se hablaba de correos duplicados, sino de la misma persona con correos diferentes, y de hacerlo con programas. El primer programa con el que hice esas primeras generaba -adrede- direcciones muy poco probables agregando un número de varias cifras (más de 4) al final sólo para evitar llenar de “spam” a la gente que le coincidiera la dirección de email. Es muy fácil que coincidan direcciones como josemaria en gmail.com o mariagarcia en hotmail.com, o imaginaros que tuviese a disposición una lista de emails… no es nada complicado, también se compran, o se obtienen de “tu empresa”.

En este terreno nosotros tenemos un sistema de detección automática de ataques de spam. Cuando nuestro sistema aprecia que hay unas firmas de carácter continuado, generalmente desde una misma IP y siguiendo un patrón definido, lo detecta y las retira. Además tenemos sistemas manuales de comprobación. Comprobamos que no haya correos electrónicos extraños, o similares a los que utilizan para hacer ataques de spam, muchas firmas desde una misma dirección IP, etc. De hecho, en peticiones con tanto flujo mediático como puede ser la de la petición de la dimisión del PP, lo hemos pedido.  La respuesta de la comprobación manual fue que no había ningún indicio de ataque de spam. Con la mayor de las probabilidades podemos afirmar que las firmas que hay en esa petición son fidedignas.

El 100% de las peticiones de arriba no son “fidedignas”, además de demostrar que una persona puede firmar con muchos emails diferentes, como si fuesen “personas diferentes”, y que cuentan en el final. Tampoco hubo intervención manual, y no sé cuánto personal tienen para analizar cientos de miles de firmas.

En el caso de esta petición, hay “firmas fraudulentas”, la mía y de varias personas, pero siguen allí, y sin dar explicaciones. Responde como si estos casos no existiesen, roza el absurdo.

Nosotros no buscamos iniciar un proceso jurídico.

Ya, pero no se privan de contactar a todos los medios y agencias de noticias con titulares como Más de 700.000 personas firmaron la petición. Nadie firmó nada, y ni siquiera se puede asegurar que fueron todas “personas”, ni que los propietarios de las cuentas de correo siquiera hayan oído hablar de la petición.

Nosotros lo que hacemos es que después de firmar una petición el sistema te envía un correo electrónico de agradecimiento por firmar la petición. Si este correo se envía a una dirección inexistente, el mail rebota. Por lo que, entre cinco minutos y dos horas, esa firma falsa se retira.

Demostrado que se pueden usar emails diferentes, que son fáciles de generar “emails válidos” (imaginad que saque la lista de emails de mi buzón de entrada, puedo generar decenas de miles de “firmas válidas” en poco tiempo usando TOR (el ejemplo de arriba usa TOR, y ni detectan que sean IPs de TOR).

En el corro que envían tampoco hay un enlace para eliminar la “firma” de esa petición, solo para “anular” tu email (como creo que me pasó con gallir en uib.es del ejemplo).

En el caso de que tú introdujeras por ejemplo 20 correos electrónicos de gente que existe nosotros realizamos una comprobación manual y podemos ver que esos correos electrónicos provienen de la misma IP, entonces los retiramos. En el caso de que una persona firme por ti,

No lo he visto, ni explican cómo lo hacen, ni cuantas IPs diferentes tienen, por ejemplo, en sus peticiones más populares.

estamos ante un caso de “suplantación de la identidad”, algo que puede ocurrir en Twitter, Facebook… y que a nosotros nos ha pasado en un puñado de ocasiones desde la existencia de Change.org.

Ahora la culpa es de los demás, no de la debilidad de sus sistema de votos, diseñado específicamente para minimizar la “resistencia”, por lo que se fomenta este tipo acciones, que afortunadamente -¡oh, casualidad!- hacen subir los contadores. Además, no es suplantación de identidad, ni tiene nada que ver con Twitter o Facebook: se pueden poner datos falsos, y nunca hubo que confirmar ni un correo electrónico (como hacen todas las plataformas “serias”, desde Facebook hasta oiga.me).

Cuando eso ha ocurrido la persona se pone en contacto con nosotros y lo que hacemos es comprobar qué ha pasado. Si ha sido una verdadera suplantación, ayudamos a esa persona a hacer todas las comprobaciones y retiramos su firma. En el caso de que esa persona quisiera poner una querella contra quien ha suplantado su identidad, nosotros como cualquier otra organización, colaboraríamos con la justicia para esclarecer el caso.

Falso otra vez.

Todo esto comenzó porque detecté que usaron mi email para firmar la “famosa” petición al PP, es público, me respondieron (con excusas por Twitter y Google+), y me está respondiendo su director en un medio de comunicación. Pero no se pusieron en contacto conmigo para informarme nada de lo que había pasado, ni sé quién, dónde o cómo firmaron “en mi nombre” (esa y las demás que usaron también mi email). Otras personas también se quejaron de lo mismo, no he visto tampoco ninguna explicación sobre esas firmas falsas. Como si nunca hubiese ocurrido… exigen transparencia pero no dan ningún dato real, sólo excusas en el aire.

Si no tienes idea de la técnica, no publiques excusas tontas para desacreditar a un programador que te está indicando los problemas que tienes. No vaya a ser que se rebote y haga el programa para demostrarlo. En serio, es ridículo, y desperdiciamos tiempo todos.

Hace dos días me quejé públicamente de que en change.org cuentan como que “firmé” peticiones aunque no lo había hecho, incluso la tan mediática del millón de firmas por la dimisión de la cúpula del PP. En el blog Ciencias y cosas recogieron esa info y la ampliaron con más casos. En vez de reconocer el problema, me acusaron de mentir y no comprobar antes de acusar, por lo que hice un vídeo demostrando lo fácil que era. Aún así, responsables de comunicación de change.org España negaban lo evidente y ponían excusas ridículas, llegando a decir que hay que confiar en la honestidad de los usuarios, y que tiene medidas de seguridad para evitar las firmas falsas.

A pesar de lo expuesto, sigo apareciendo como firmante en peticiones que nunca firmé (de todas en la que aparezco como firmante, sólo voté la primera, de hace más de un año, por la ley de transparencia) sin que haya un mínimo control, y a pesar de que tengo usuario creado (por lo que el control es más sencillo, exigir que esté autentificado). Responsables de change.org España reconocieron que es un problema, que “alguien votó por mí” (aunque otros llegaron a decir que “tengo problemas de seguridad con mi email” [sic]), pero ante la petición que hagan pública la lista de votante  la respuesta fue que no les permite la LOPD. Podría ser, pero en ese caso tampoco deberían pasar, como hacen, la lista al que inició una petición. No es de la empresa, es un tercero sin relación, y aún así accede a los datos.

Es ridículo lo de exigir transparencia y no cumplirla. Es ridículo saber que se pueden hacer trampas de forma tan sencilla, y aún así seguir saliendo en los medios asegurando que “más de 700.000 personas firmaron” cuando:

• No es ninguna “firma”.
• No se hacen controles para minimizar los abusos.
• Hay evidencias de que hay “firmas” falsas, y lo reconocen (con la boca pequeña).
• No hay el mínimo de transparencia, ni en el código ni en la lista de “firmantes”, en un sitio que presume de acciones éticas.

Están engañando deliberadamente.

A pesar de ello, no se hizo nada, ni se dieron respuestas. Ayer domingo me puse a trabajar analizando los controles que hacen en la web al momento de “firmar” una petición. El resultado fue un bot que publiqué anoche, que es capaz de firmar decenas de veces por minuto (sólo depende de la red y velocidad de servidores, en el ejemplo puse un retraso deliberado, para no sobrecargar los servidorees de change.org). Cuando lo publiqué había llegado a casi 100 votos de una petición “de prueba” en pocos minutos, inmediatamente empezaron a reducirse, no sé si por los controles “a posteriori” (aunque el contador ya se había incrementado). Luego hice pruebas con otra petición (creada por Alejandra Ventura), y se llegó al objetivo rápidamente, desde una instancia de Amazon en Irlanda.

Es decir, se pueden hacer trampas fácilmente, por el propio diseño e implementación de change.org. Ellos lo saben perfectamente, aunque lo nieguen en público, hay suficientes evidencias,  se niegan a ser transparentes poniendo como excusa la LOPD (que es razonable) al mismo tiempo que se contradicen permitiendo que un tercero baja la lista completa en PDF, pero no cesan en el autobombo y ruido mediático hablando de “personas que han firmado”.

Si exiges transparencia y ética, comienza por dar el ejemplo. Sobre todo si ya hay personas que se están quejando de sus “firmas” fraudulentas, y tu negocio se basa en hacerte publicidad con titulares mediáticos gracias a  la indignación y desgracias de los demás.

Tampoco vale lo de justificar mentiras y trampas porque el objetivo de las campañas son peores, no puedes ir exigiendo ética, responsabilidad y transparencia con métodos que se saltan las tres. Por otro lado, como dice Nicholas Taleb:

Si ves fraude y no le llamas fraude, eres un fraude.

En primer lugar debo decir que me gusta mucho la creación de Firefox OS, por varios motivos.

• Es una forma de potenciar el desarrollo en estándares HTML5/Javascript, y alejarse del modelo pernicioso y costoso de desarrollos de aplicaciones nativas para cada plataforma móvil.
• La única forma de innovar es probar nuevas cosas, y los intentos por hacerlo están muy bien, aunque luego fallen estrepitosamente, a priori nunca se puede saber con certeza si algo nuevo funcionará o no.
• El proyecto es completamente software libre, y bajo el paraguas de una fundación con tanto prestigio, y que tanto bien ha hecho, como Mozilla.
• Un orgullo chauvinista de ver que uno de los auspiciantes y colaboradores principales del proyecto, que además es software libre, sea una empresa española.

Dicho eso, mi detector de bullshit se fue de escala con muchas de las cosas que me respondieron en Twitter relacionadas con “eficiencia”, innovación técnica, independencia de los desarrolladores, fabricantes y teleoperadoras.

Innovación técnica

Primero hay que explicar en qué consiste Firefox OS. Está formado por tres componentes fundamentales:

• Gonk: Es el sistema operativo básico, consiste del núcleo Linux, herramientas del sistema y librerías, hasta aquí muy similar al sistema Android, de hecho usan algunas librerías de ese proyecto.
• Gecko: El programa que se encarga de interpretar HTML más el intérprete de Javascript. Estos se ejecutan “sobre” el núcleo Linux de forma nativa. Es similar a los navegadores basados en Webkit para Android (como el Chrome) e iOS. En ambos casos, también en forma nativa (en Android, el código es nativo y compilado para cada tipo de procesador, está en la libchromeview.so de la app, compilado para cada tipo de procesador).
• Gaia: Interfaz de usuario con el sistema operativo, e implementación de las aplicaciones básicas (SMS, cámara, teléfono…). Estas aplicaciones están (presuntamente) todas implementadas en HTML5 y Javascript, las equivalentes en Android están implementadas en Java/Dalvik, y en Objective C (es decir, se compila a código nativo) en iOS.

Es decir, el Firefox OS es un sistema que aunque seguramente se podrán incluir librerías en código nativo (no hay forma de evitarlo), limita el desarrollo de aplicaciones a sólo HTML5 y Javascript. Por el contrario, en Android o iOS se puede hacer sólo en eso HTML5 y Javascript, o en aplicaciones nativas.

¿Cuál es la innovación técnica real? Para permitir que se pueda desarrollar cualquier tipo de aplicación se deben proveer funciones Javascript adicionales para manipular dispositivos (cámara, micrófono…) y funcionalidades no previstas en el estándar Javascript (red, telefonía, reproducción de audio y vídeo, etc.). Según alguna gente de Mozilla, esto es la innovación de Firefox OS, pero no es así, PhoneGap ya había implementado funcionalidades similares, aunque quizás su interés nunca fue intentar convertirlas en un estándar (no lo sé).

La presunta “innovación” por la ampliación las funcionalidades “estándares” de Javascript para gestionar los dispositivos no es tal, es simplemente una evolución natural, es lo que pasa cada día en informática. En todo caso tocaría analizar si hay innovaciones en la “forma” de la implementación, pero esto está a otro nivel, y no implica innovación de cara al sistema completo, sólo mejoras de eficiencia.

Eficiencia

Otros de los argumentos es la presunta eficiencia de Firefox OS comparado con Android (fundamentalmente). Eso está por verse, y en qué condiciones. Como expliqué anteriormente, el sistema de interpretación de HTML  y Javascript en Android e iOS es muy similar: programas compilados en código nativo para cada procesador. Además, Webkit es muy eficiente para el HTML, y el intérprete de Javascript de Chrome es de los más rápidos según todos los benchmarcks, por lo que no puede haber diferencias notables en la velocidad de ejecución de apolicaciones HTML5.

Sí podría haber por otros factores, por ejemplo que se prueben en dispositivos de poca memoria. Al ser Firefox OS un sistema mucho más simple y con menos programas y librerías cargadas, en casos extremos de limitaciones de memoria RAM podrían notarse diferencias en “suavidad” de ejecución.

Por otro lado, Firefox OS tiene un problema. En Android se puede optar a desarrollar en HTML5 o en aplicaciones nativas en Java. La máquina virtual que se usa, Dalvik, es todavía mucho más eficiente que aplicaciones con Javascript y HTML5, por lo que en general, las aplicaciones nativas de Android se ejecutarán más eficientemente. A menos que hagan casi “milagros” con el interprete de Javascript en Firefox, pero Java les lleva mucha ventaja en ese aspecto (y seguirán mejorando).

Independencia de fabricantes y desarrolladores

Es verdad que iOS está controlado exclusivamente por una empresa, pero en Android es muy diferente. El código es libre, por lo que cualquier fabricante o empresa puede usar el código como quiera, aunque deba respetar las marcas y licencias de Google, por ejemplo las marcas registradas (al igual que los productos de Mozilla), o la distribución de programas que son exclusivos de Google, como el Google Play, Gmail, etc. Pero cualquier fabricante es libre de instalar su propio “market”, o cualquier otra aplicación. Es lo que está haciendo Amazon, sin problemas legales.

Las empresas que apoyan a Firefox OS por su independiencia podrían haber optado, con mucho menos trabajo, a desarrollar sus propios sistemas de distribución y cobro de aplicaciones para reemplazar al Play de Google. Lo tienen que hacer igualmente para Firefox OS, así que no hay costes extras, ni problemas legales.

Es decir, el argumento de que no podían hacerlo con Android no es cierto. Posiblemente la elección de desarrollar Firefox OS tenga ventajas en cuanto al “negocio”, pero es falso que no pudiesen lograr la misma “independencia” con Android (de nuevo, a Amazon me remito como ejemplo).

Teléfonos de más bajo coste

Es verdad que un teléfono Firefox OS requeriría menos hardware, pero sólo memoria. En otros aspectos, como la potencia de la CPU, es más exigente que aplicaciones nativas de otras plataformas. El precio la memoria RAM no es lo que más influye en el precio, y además ya se consiguen teléfonos Android a menos de 100 € (que fue una de las cifras citadas), y seguirán bajando, como ha pasado siempre.

Así que el precio tampoco es un factor determinante.

En resumen

No se trata de un problema de eficiencia, ni independencia de fabricantes, ni de coste. En todo caso es una ventaja para las empresas que quieren alejarse de la marca Google, que de alguna forma influye mucho en la comercialización de la marca Android, y que obtiene beneficios por el uso masivo del buscador, o de killer aplications como Google Maps. Esta nueva plataforma, de triunfar, volvería a nivelar el campo de juego… de las empresas, que no de los usuarios.

Como dije antes, una de las ventajas “globales” es la promoción del desarrollo en HTML5, que funcionaría en todas las plataformas y con menor coste y esfuerzo de empresas y programadores.  Pero por ahora, y durante un tiempo, exigirá mayor esfuerzo, hasta que las demás plataformas implementen el nuevo “estándar” que define Firefox OS… y la mayoría de los teléfonos las tengan instaladas (lo que puede tomar muchos años).

Se dicen muchas cosas, esas posibles ventajas técnicas, económicas e independencia todavía han de demostrarlo, y toca ver si Firefox OS tiene éxito primero entre desarrolladores, y luego en los usuarios. No lo tiene nada simple.

Así y todo, ojalá sea un éxito, o que al menos obligue a mejorar a los demás sistemas operativos, pero no hay que creerse ni dar alas a tanto wishful thinking basado en premisas falsas.

Relacionado: Android, iOS, tiempos de respuestas y por qué nada es gratis en sistemas informáticos.

“Si la semana pasada fue demoledora, ¿qué decir de esta? La verdad es que van faltando las palabras, incluso a quienes nos dedicamos a escribir”, asegura el bloguero, que muestra su indignación ante la continua aparición de casos de corrupción. “Como mínimo, y sin que me conste nada más grave de qué acusar a El Mundo, fueron unos irresponsables y negligentes porque no controlaron a quien debían mostrar la información.”, denuncia Galli, entre otros temas, en el escrito de su blog.

ÉXITO BRUTAL EN TWITTER
Los tuiteros han felicitado con fervor al bloguer por su “concisión, claridad y valentía” y han convertido el artículo en uno de los más leídos durante varios días en su blog y, sin duda, en uno de los más compartidos en las redes.

—-

Absoluta y tremendamente ridículo, ¿no? Antes de insultarme en los comentarios por favor lee Éxito rotundo en las redes del artículo de Pepa Bueno sobre el ‘caso Bárcenas’ que salió en un “medio serio”, escrito por “periodistas”. Luego me dices.

Vía http://www.meneame.net/story/exito-rotundo-redes-articulo-pepa-bueno-sobre-caso-barcenas

Vale, bien, pero el problema es el mismo que ellos reconocen:

Como periodistas que defendemos la transparencia lamentamos tener que empezar de forma anónima, pero eso cambiará.

La enorme contradicción de esa frase resume muy bien el porqué son el hazmerreír.

Unos señores que se presentan como periodistas solicitan ayuda a los ciudadanos para defender a su empresa (pública), pero no se atreven a firmar ni decir quiénes son. Unos periodistas que dicen saber cómo hacer una radio crítica y profesional hacen acusaciones graves contra directivos de su empresa (pública), pero sin citar ningún nombre, ni de acusados ni de los críticos. Periodistas que reclaman transparencia y valentía, que no son capaces de decir quiénes son, ni siquiera cuántos.

¿De verdad saben qué es periodismo? ¿Creen que existe el periodismo crítico sin ningún riesgo y sólo de palmaditas en la espalda? ¿O es la moda de la rebeldía anónima para no tener problemas en su trabajo ni arriesgar su nómina?

Es muy habitual tener problemas con su empleador, yo mismo lo he tenido. Hice críticas a mi universidad cuando era mi única fuente de ingresos y tenía que mantener a una familia con esos únicos ingresos (y sin otros familiares que me sirviesen de colchón familiar). Me acarrearon muchos problemas y pedidos de “despido” y “expediente”, incluso por parte de altas autoridades. Lo pasé muy mal, pero si critiqué es porque creía que era lo que tocaba, y nunca lo hice de forma anónima, a pesar de que no estudié (ni pretendo hacer) “periodismo crítico”, ni mucho menos ser el héroe de la disidencia.

Pero ahora tengo que ver, una vez más, señores que dicen apostar por la transparencia y profesionalidad del periodismo en su medio, que piden ayuda para lograrlo, publicando acusaciones graves desde la comodidad del anonimato. Muy profesional. Siendo así, no quiero este tipo de “periodistas” en una radio pública, ni quiero un medio público gestionada por este tipo de periodistas que en vez de decir las cosas claras y de frente -tienen los medios-, se dedican a la agitación anónima.

Si quieren provocar los cambios tan necesarios, deberían empezar por cambiar ellos y dar ejemplo de coherencia de lo que demandan, desde el minuto cero (y no lanzar globos sondas antes, para ver qué pasa).

PS: Lo más triste es que lo que dicen defender a un periodismo de calidad en la radio pública -periodistas incluidos- no sólo no critican estas contradicciones tan poco profesionales, la festejan. Es de locos.

Relacionadas

•  TVE, iNews y el dilema ético de la transparencia
• Salvemos TVE, que no sé de quién es, pero mía no…
• Periodismo basura, y ¿objetividad? en la TV pública.

Esta mañana me levanté y escribí, como sarcasmo a lo que acabo de explicar: Me desperté temprano, ansioso, para seguir leyendo chistes de los 22 millones. @cpelota me responde que hoy me cansaría con lo de los sobresueldos. No sabía de lo que hablaba, voy a Menéame y la veo primera en portada… la portada de papel de El Mundo que un tercero la subió a otro sitio:

Voy a la portada de ElMundo.es, veo el titular y me encuentro que no está disponible para todos.

Me sorprendió.

Era la noticia del día, quizás la del mes, quizás la del año, todo el mundo hablando de ello, se estaba replicando en los demás medios, pero nadie podía enlazar al que se tomó el trabajo de investigar. Dejar esa noticia sólo accesible bajo el paywall perjudicó solamente al que la generó, y benefició a los demás medios y sitios que se limitaron a replicarla.

Luego se divulgó un enlace a “redes sociales” de Orbyt, pero el daño ya estaba hecho, y dicha página no mejora nada, el URL no es accesible fácilmente, no tiene el mismo peso como noticia de elmundo.es, y por no tener, ni siquiera tiene publicidad.

Fue todo un disparo en el pie del paywall Orbyt. Por supuesto, los directivos de El Mundo, tienen el derecho de intentar cobrar por una noticia que les cuesta dinero y esfuerzo, pero creo que no se han dado cuenta de la gran paradoja de las noticias: las que son importantes, las que presuntamente tienen más “valor de mercado”, son rápidamente replicadas por lo que rápidamente se convierten en una commodity, y sólo benefician a los medos más pequeños y sin recursos que se dedican a copipastearla (por ejemplo) o resumirla y opinar. Con el agravante de que lo importante de la noticia se resume en el titular y en unas pocas oraciones que una vez leídas hacen que el original de pago tenga un valor muy residual.

Me da pena que sucedan estas cosas. Por la ceguera de pensar que un paywall es la solución, los mayores perjudicados son el medio y los periodistas que se tomaron el trabajo y la valentía de bucear en los entresijos de la noticia del día anterior, y que generaron una noticia con un calado político aún más importante.

Actualización: otro punto de vista, parecido, en error500. Otra, con más profundidad, de Juan Varela.

PS: Por supuesto, queda por ver qué hay de cierto en todo lo que publicaron, pero esta mañana ya era “la noticia”.

Cuando critico la manipulación y divulgación de “mala ciencia” en los medios, suelo mencionar a la pésima formación científica de las carreras de “periodismo”, especialmente la inexistencia de asignaturas fundamentales para “explicar el mundo”, como la estadística. Lo último se hace más evidente en cada sorteo del Gordo de Navidad.

Los juegos de azar son ejemplo típicos usados en estadística para enseñar y analizar probabilidades, por su simplicidad, reglas bien definidas e independencia de eventos. Así, es extremadamente fácil calcular cuál es la probabilidad de ganar el Gordo de Navidad: si son 100.000 números diferentes, y compras uno, la probabilidad es 1 entre 100.000. No hay más truco. Y esa misma regla se aplica a la serie completa, o a los décimos. Si compras dos números diferentes, entonces será 1 entre 50.000. Si compras 10 será 1 entre 10.000.

Fácil, ¿no?

Pues parece que para algunos es muy complicado entenderlo, aunque sean periodistas que escriben en un periódico y que intentan aclarar las probabilidades. En Ser presidente del Gobierno o salir con una supermodelo: cosas que son más probables que te pasen antes de que te toque El Gordo dicen:

La posibilidad de haber comprado un décimo agraciado con el mayor premio en el sorteo de lotería de Navidad es de una entre 14,5 millones. [...]

Sin embargo, que nos toque el Gordo es casi un milagro: la probabilidad es sólo de una entre 14,5 millones, nada menos. Para que te hagas una idea, es casi más fácil que llegues a la luna.

¿De dónde ha sacado ese número? No me lo explico todavía, no puedo entender qué modo de pensar o qué formación pudo haber recibido para escribir semejante tontería cuando la respuesta es muy sencilla.

Pero no queda allí, el mismo titular es digno de entrar en los anales de las estupideces derivadas de no saber hacer operaciones simples para calcular probabilidades. ¿Realmente es más fácil ser presidente que ganar el Gordo? No, y la respuesta es muy sencilla.

Supongamos que compras un número del Gordo desde 1982 (30 años), ¿cuál es la probabilidad de ganar el gordo? 1 en 3.333 3.333,8166916544 (o aproximadamente 30 en 100.000), cuál fue tu probabilidad “simple” (no es tan simple, se debería usar Bayes para hacer una predicción basada en probabilidades a priori, como mínimo) de haber sido presidente? Hubo 4 presidentes entre 45.000.000 de habitantes, eso da aproximadamente 1 entre 10.000.000, es decir muchísima menor probabilidad que ganar el gordo en esos 30 años. Pero no hace falta complicarse la vida con números tan gordos. Sólo considerando una serie del Gordo, en 30 años hubo al menos 30 ganadores del Gordo (o 300 ganadores de décimos), mientra que sólo tuvimos 4 presidentes.

Es demasiado fácil y obvio para escribir un artículo divulgativo tan erróneo (si hiciese el cálculo de cuántos hombres han llegado a la luna sobre la población total, la afirmación es aún más lunáticamente errónea, pun intended).

Lo que sí es cierto es que es más fácil ser millonario por otros métodos (1 de cada 500 personas en el mundo es “millonaria”) que ganar el Gordo en un único sorteo (1 de cada 100.000), por lo que se necesitarían jugar 200 números diferentes en un año, o 7 números cada año, durante 30 años, para tener la misma probabilidad de ser millonario con el Gordo.

Este tipo de artículos y los diversos comentarios en los medios durante el día de ayer indican la paupérrima formación en áreas tan fundamentales como la estadística. Por ello no entiendo que en muchas universidades hayan eliminado las asignaturas de estadística de sus grados de periodismo, o que le dediquen tan poco tiempo. Lo considero un fraude intelectual de la universidad, y una deficiencia formativa inadmisible para profesionales. Al menos la “academia” debería hacer una profunda reflexión de qué es lo que están haciendo.

Por otro lado, desde ayer leí en Twitter a los típicos attention whore que escriben buscando aplausos o RTs recurriendo a la demagogia y populismo ignorante, por ejemplo criticando el supuesto afan recaudatorio exagerado del estado. Para ello decían cosas como “el estado se queda con 144 millones” de la Lotería, es una vergüenza/robo/engaño/etc”, pero no se citan lo importante: eso es “sólo” el 30% de la recaudación total, prácticamente lo mismo que pago sólo de IRPF, y mucho menos que otros juegos de azar, como ya lo explicó gaussianos el año pasado.

Debo decir que tampoco entiendo que los mismos que exigen mayores gastos del estado para sostener el estado del bienestar, luego griten rabiosos porque el estado recaude más en los “impuestos voluntarios a la ignorancia” de juegos de azar.  ¿Pretenden que el estado no recaude nada? ¿que el estado no participe en juegos de azar, sólo las empresas? (de tanto ir de progres por las redes sociales acaban usando argumentos neoliberales).

Considero que el estado no debe fomentar en ningún caso este tipo de juegos de azar, es un abuso a la ignorancia numérica de la gente y el fomento a la ludopatía que arruina a tantas familias. Pero luego pienso que quizás esté bien que el estado recaude impuestos voluntarios a esa ignorancia y haga un Gordo de Navidad cada sábado (aunque debería invertir más en asistencia a la familia directa de los jugadores, víctimas inocentes de la ludopatía).

Sesgos y mala información

Está estudiado, experimentado, demostrado y ampliamente reconocido en el ambiente académico y profesional de la psicología y psiquiatría el problema de los sesgos. Éste es inevitable, nos afecta a todos, cada minuto, cada opinión y cada percepción que tenemos del mundo. Es el que nos hace ignorar la información que no se ajusta a nuestros patrones y conocimiento adquirido previamente, el que selecciona aquella información que revalida lo que pensamos (sesgo de selección) e ignora aquello que lo contradice.

Hay muchos libros que explican nuestros sesgos, uno reciente Thinking, Fast and Slow, del Nobel Daniel Kahneman, que investigó mucho sobre el tema. Tenemos dos forma de pensar, la más “intuitiva” y de “sentido común”, y otra más racional. Kahneman denomina al primero “Sistema 1″ y “Sistema 2″ al segundo.

Al contrario de lo que parece afirmar Punset, el Sistema 1 está siempre funcionando  no se detiene, es el que toma las decisiones rápidas y las que llamamos de “intuición” y “sentido común”, aquellas que no necesitan laboriosos razonamientos o cálculos. Usa “trucos”, como la “asociación”, cuando percibe algo nuevo lo asocia inmediatamente con algo conocido. Es el Sistema 1 es el principal responsable de nuestros sesgos.

El único que puede minimizar los sesgos es el Sistema 2, pero éste es muy “perezoso”, cuesta ponerlo en marcha, y es agotador (consume tanta energía que cuando estamos concentrados nos hace consumir más glucosa). Además, el Sistema 2 está influido por las primeras impresiones o decisiones que ha tomado el Sistema 1 (por ejemplo, el muy conocido “truco” del priming), por lo que la tarea de elimina nuestros sesgos no sólo es muy dura, es imposible eliminarlos completamente.

En diversos estudios y experimentos se ha comprobado que el sesgo es normalmente amplificado en un grupo. Si una persona se “mueve” un poco, todo el grupo la acompaña. Así, un grupo puede tomar decisiones aún más radicalizadas y sesgadas de las que tomaría cada uno de los individuos por separado. Por ello, entre otras razones, James Surowiecki en su libro The Wisdom of the Crowds pone determinadas reglas para que realmente pueda extraerse una respuesta válida de un grupo de personas, entre ellas, la independencia.

El sesgo amplificado de un grupo suele generar que una persona antes tolerante con las opiniones discordantes, se vuelva intolerante a esas mismas opiniones, no le otorga ninguna validez. Esto genera una realimentación positiva, se minimiza o destruye toda interacción con personas de opiniones diferentes, lo que se conoce como el efecto cámara de eco.

Internet es muy vulnerable a las cámaras de eco. Hay sistema de “redes sociales” que fomentan la comunicación de entre personas similares, y por lo tanto facilitan la creación de las cámaras de eco. Es un efecto muy común en Twitter, o Facebook. Pero no es exclusividad sólo de esas redes sociales, pasa en los foros, en Menéame, y en cualquier sistema que se use para divulgar y compartir información.

Este problema de amplificación de sesgos está relacionado con otro cada días más habitual, la creación y divulgación de bulos y noticias falsas. Pero no es un problema de Internet, ésta sólo lo hizo más rápido. Nate Silver lo explica en su libro The signal and the noise. Los errores y malas interpretaciones son comunes en la comunicación humana. Antes los errores  los cometían los escribas al copiar los libros. La imprenta disminuyó la tasa de errores, pero permitió que los que se producían se divulgasen muchísimo más rápido. Cito una frase del libro:

La imprenta cambió la forma en que cometemos errores. Los errores rutinarios de transcripción se hicieron menos comunes. Pero cuando hubo uno, se reproducía mucho más, como en el caso de la Biblia Adúltera. Los sistemas complejos como la web tienen esta propiedad. Pueden no fallar tan a menudo como sistemas más simples, pero cuando fallan, fallan estrepitosamente. El capitalismo e Internet, ambos increíblemente eficientes para divulgar información, crean la oportunidad de divulgación tanto a las buenas como a las malas ideas. Las malas ideas pueden producir efectos desproporcionados.

Ejemplos de esos efectos desproporcionados: burbujas hipotecarias, decenas de miles de personas acusando de pedófilo a un inocente, políticos que convocan elecciones anticipadas porque le convencieron que aumentaría su ventaja, o hasta miles de personas que acuden a una fiesta convocada por error en Facebook.

También produce otros efectos, como información y datos erróneos u obsoletos que perduran duran hasta siglos. Tenemos incontables mitos que damos por cierto, pero no son más que eso, información errónea, que se divulgó rápidamente, y que es imposible rectificar. Lo explica muy bien Samuel Arbesman en su libro The Half-life of Facts: Why Everything We Know Has an Expiration Date (que también habla de la rapidez con que se divulga la información errónea).

Por ejemplo, es falso que el director de la oficina de patentes de EEUU (Henry Ellsworth) haya declarado en el Congreso que no tenía sentido mantener la oficina porque no habría más invenciones, en realidad dijo todo lo contrario. También es falso que las ranas no saltan de una olla si se calienta el agua lentamente (en The Atlantic intentaron matar este mito, varias veces, sin éxito aparente) o que los luditas luchasen contra las máquinas tejedoras (en realidad reclamaban que les den formación, eran muy complejas para su época, y tenían que manejarlas sin conocerlas).

Se puede decir que vivimos rodeados de información, que se divulga muy rápidamente, y nos encontramos con los siguientes problemas:

• Sesgos inevitables que nos hacen aceptar acríticamente la información que confirma nuestras creencias.
• La divulgación de la información es muy rápida, pero también pasa con la información errónea.
• La información errónea, una vez divulgada, es muy difícil de corregir.
• Se crean cámaras de ecos que radicalizan y amplifican los errores.
• Información errónea que persiste durante mucho tiempo.
• Tomamos decisiones importante -personales y sociales- con nuestro sesgo, ignorando la enorme complejidad del mundo, y encima basado en información errónea.

Al que me haya leído hasta aquí, posiblemente esté pensando:

Vale, ¿y qué haces para evitar esos problemas en Menéame?

La realidad es que el objetivo para este apunte era contar lo que pusimos en marcha hace unas semanas, para evitar esos problemas, y los [buenos] resultados que está dando. Quise hacer una pequeña introducción al problema, lo difícil que es encontrar una solución -incluso lo difícil que es analizarlo correctamente-, relatar algo de lo que había estudiado (recomiendo los libros citados), y me salió el ladrillo que habéis leído.

Ahora, al grano.

Beneficiar al disenso en Menéame

Somos conscientes de los problemas de sesgo, presente en todas las redes, y también en Menéame. A diferencia de otras redes, en Menéame no se fomenta las cámaras de eco, sino el debate, pero igualmente sufre de los mismos problemas, y el cabreo [también muy humano] que produce debatir con otros con opiniones muy discordantes. Con un agravante, Menéame produce un “resultado” de esa interacción de usuarios, son las noticias en portada, que a su vez son leídas y visitadas por cientos de miles de personas cada día (y que se replican en otras redes, y medios, aunque nunca citan dónde lo vieron), por lo que de alguna forma es “colaborador” cuando se divulgan noticias erróneas.

En este aspecto, hace tiempo ya implementamos un método para resaltar aquellos comentarios que disienten con la noticia, lo describo en El valor de las opiniones discordantes. Aunque tenía efectos positivos, los comentarios críticos con la noticia se resaltaban con menos votos (y obtenían así más votos), no era leído por los que accedían y comentaban en Menéame: había que hacer un clic adicional, o al menos posicionarse sobre el avatar para leer el texto del comentario.

Luego de pensar y hacer varias pruebas, ahora se muestra también un resumen (hasta 600 caracteres) del comentario “crítico” que está en primer lugar. Ha dado muy buenos resultados. Por ejemplo, en la noticia de hoy sobre las fotos presuntamente robadas en Deusto (aunque ya sabemos que muchas de ellas son falsas) podemos ver los comentarios resaltados:

Ese comentario crítico resaltado fue escrito a las 17:15 hs, a las 18:10 hs la noticia ya fue quitada de portada por los votos de los usuarios. Se cumplen los dos objetivos que buscábamos para este tipo de noticias:

• Que el lector tenga información crítica adicional al titular y entradilla.
• Que si es “errónea” y está portada sean los propios usuarios los que la quiten.

Hay muchos casos similares. A las pocas horas que lo pusimos en marcha ya tuvo efectos positivos en esta noticia conspiranoica que fue quitada de la portada (siempre por los votos negativos).

O en esta otra, sobre el bulo de que un antidisturbios había empujado a una mujer por las escaleras del metro (se empezó a divulgar desde Facebook).

Esa noticia también salió de portada, aunque varias horas después del comentario crítico.

Aunque en otros casos no se consiguen ambos objetivos, la noticia queda en portada, pero al menos queda visible el comentario crítico casi al mismo nivel que la entradilla, como en este caso del suicidio en Córdoba (el comentario es mío, apenas me enteré que fueron problemas familiares más que de ejecución de hipoteca).

Bueno, esto es lo que quería contar, la nueva forma de resaltar -automáticamente- esos comentarios críticos, para ayudar a reducir el efecto negativo de los sesgos que sufrimos todos. Aunque en perspectiva y a toro pasado parezca obvio, no es sencillo encontrar la solución al problema -que además no es unidimensional-. No conozco ningún sistema similar (foros, Digg, Reddit…) que haya implementado sistemas similares para favorecer a los que tienen opiniones discordantes con la mayoría (si sabéis de alguno, avisadme, por favor).

Por si no lo habéis leído, hace menos de un mes pusimos en marcha un algoritmo que beneficia a la diversidad de votos. está teniendo muy buenos resultados, pero a esto lo contaré en otro apunte.