Nota previa: Este post se me ocurrió tras leer otro en el blog de Juantomás, y tiene un tono incendiario y provocador. De modo que, para los que tienen tendencia a cabrearse por cualquier cosa, por favor, un poquito de sentido del humor y autocrítica al leerlo.

Algunos de los tipos más tontos que conozco se mueven en el entorno del Software Libre. La suya es una tontería superlativa, porque, curiosamente, nacieron con una inteligencia superior a la media, pero en un momento determinado de su vida sufrieron un cambio emergente de actividad y se volvieron estúpidos premeditados.

Tan estúpidos como para empezar a regalar su propiedad intelectual, por ejemplo. Pero quizá una de las cúspides más gloriosas de su sectario suicido colectivo ha sido la popularización de la idea de que la meritocracia es intrínsecamente una buena cosa.

La meritocracia es una manzana envenenada como pocas. En principio, suena muy bien que cada uno sea retribuido por sus méritos. Hasta que te das cuenta de que para que te sigan retribuyendo tienes que seguir haciendo méritos. Y hacer méritos constantemente es muy fatigoso. El retirado futbolista Zinedine Zidane dijo en una ocasión: "Me cuesta mucho llegar a mi nivel" (los años no pasan en balde).

Derivada de la meritocracia es la idea que comentaba Juantomás sobre tratar de reclutar siempre gente más inteligente que tu mismo para tu empresa ¡Menuda gilipollez! ¿Qué clase de idiota enrolaría al Capitán Jack Sparrow como segundo de abordo en su barco pirata? Los tipos listos nunca son de fiar. A la mínima oportunidad se enrolan en otro barco donde haya mejor botín. O, peor, se compran su propia nave y se dedican a expoliar las mismas rutas marítimas que tu.

La pericia de un jefe no se demuestra cuando es capaz de crear una gran empresa con grandes trabajadores, sino cuando es capaz de crear una gran empresa con gente mediocre.

Para empezar, es prácticamente imposible reclutar sólo buenos trabajadores, porque el porcentaje de vagos e idiotas por metro cuadrado es aproximadamente el mismo en todo el mercado laboral, y es extremadamente caro cribar las pepitas de oro de la arena.

En segundo lugar, existen problemas intrínsecos a la situación de que todo el mundo sea una primera bailarina. Tal es el caso de los equipos de fútbol de primera división que, ni abarrotados de estrellas rutilantes, consiguen en ocasiones dar pie con bola.

En realidad lo más rentable a nivel personal, es acumular unos cuantos méritos notables durante un tiempo y luego vivir de sus réditos a lo David Beckham.

Quizá el caso de antimeritocracia más notable en toda la historia sea el de Napoleón Bonaparte. Napoleón no ganaba las guerras gracias a un ejército de calidad excepcional. Sus soldados eran tropa de leva, y, al menos en equipamiento y pericia de maniobra, eran netamente inferiores a los prusianos. Lo que Napoleón hacía excepcionalmente bien era emplear con astucia aquellos recursos que tenía disponibles.

Para terminar, debo reconocer que la meritocracia tiene al menos un aspecto positivo. El grado de problemas y stress que se sufre como jefe de una empresa no depende de los factores externos a la empresa ni de como esté organizada, sino casi exclusivamente de la cantidad de subordinados que tengas con capacidad para meterte en un buen lio. Lo bueno de disponer de gente realmente meritoria es que te puedes ir a casa a las cinco tranquilamemte sin sufrir insomnio por la incertidumbre de qué desastre sucederá como consecuacia de haber dejado solos a tus trabajadores durante un par de horas.

Post relacionado: Incompetencia calculada

La falange griega es una de las formaciones de combate cerradas más eficaces de la antigüedad. Se trataba del orden de batalla empleado por los homoioi espartanos en las guerras médicas y, particularmente, en la mítica batalla del desfiladero de las Termópilas contra Jerjes. Una formación donde los hombres se agrupaban en formaciones de 4 a 8 filas de fondo y combatian estrechamente hombro con hombro protegiéndose mutuamente con el hoplón y la lanza.

Menos conocido, en cambio, es el papel que jugaban los peltastas originarios de Tracia y que, a diferencia de los pesados hoplitas de la falange, combatían sin armadura, protegidos sólo por un ligero escudo de mimbre. La menor protección de los peltastas les permitía hostigar las líneas de la falange lanzando jabalinas, pero evitando siempre entrar en contacto cuerpo a cuerpo con la falange debido a su mayor movilidad para escapar.

Bernard Golden cuenta en CIO una historia de David Packard (Fundador) y Chuck House (ejecutivo senior) hace muchos años en HP.

Un día Packard entró en el laboratorio donde trabajaba House a ver un producto que no andaba bien en las pruebas. Packard se enojó y vociferó: "la próxima vez que venga aquí no quiero ver ese producto en el laboratorio". Al dia siguiente House recibió las malas noticias de su jefe, a las cuales le respondió "¿y qué tal si lo ponemos en producción?". El producto empezó a funcionar y la siguiente vez Packard dijo: "¿no os había dicho que os deshiciéseis de ese producto?" House le replicó: "no, usted dijo sólo que no quería ver el produto en el laboratorio, y ya no está en el laboratorio".

Creo que la historia muestra una importante diferencia cultural que tenemos los españoles con los norteamericanos. Estoy firmemente convencido de que en la típica empresa española a Chuck House le habrían despedido fulminantemente de una patada en el trasero por semejante indisciplina. Pero David Packard era más listo que eso y permitió que la carrera de House prosperase.

Guerras sin general se sabe por las crónicas que se han ganado muchas, pero nunca ha habido general alguno que ganara una guerra sin buenas tropas. Creo que los americanos conocen bien este hecho y por eso sienten un mayor respeto por los escaramuzadores guerrilleros: desde policías solitarios a lo Harry Calahan o Martin Riggs, hasta el nada convencional doctor Gregory House, la filmografía norteamericana está llena de héroes que celebran los beneficios de la iniciativa personal por encima de la burocrática cadena de mando.

No se trata de fomentar a los lobos solitarios. Los mejores resultados se obtienen cuando se permite que las personas empleen su talento de forma creativa y se logra coordinar esa innovación con el grueso de las fuerzas, pero para eso hay que estar dispuesto a saltarse la forma ortodoxa de hacer las cosas de vez en cuando.

A quien haya leído un poco sobre Software Libre y el desarrollo colaborativo de software, le sonará el famoso artículo de Eric S. Raymon "La Catedral y el Bazar", en el que se enfentaba el estilo de desarrollo, todavía predominante, de una organización jerárquica con planificaciones estrictas, ISOs y la obligada burocracia, con una sorprendente nuevo tipo de organización más espontánea en el que no había un plan rígido definido a priori y en el que mucha gente participaba codificando partes de un todo no sin ningún control, no exageremos, pero desde luego con menos restricciones.

Sin tratar de ser purista, siempre he pesando que puede desarrollarse software libre sin basarse en un modelo colaborativo, pero un modelo colaborativo abierto a cualquiera y aplicado a la construcción de un software si determina que éste sea libre.

Lo primero ocurre con naturalidad: ¿cuántos proyectos de software libre no cuentan con una comunidad activa detrás? Ahí tienes el proyecto y al menos su código, pero no te interesan, o no tienes tiempo, o no hay homínido que le meta mano, y en definitiva en la mayoría de los proyectos referirse al grupito que lo empuja como una comunidad a mi me parece exagerar. Quizás hablaría de comunidad potencial. Puede que tengas un porrón de usuarios trabajando activamente. Puede, pero lo que está claro es que si cierras tu código ni potencialmente puede haber una comunidad en la que cualquiera pueda acercarse y aportar.

En Cueva o Comunidad" Sandeep Krishnamurthy (hablamos del año 2000, ¡qué barbaridad!) y después de haber estudiado datos sobre cien proyectos maduros de SourceForge concluyen que la media de desarrolladores es cuatro y lo más común es que haya uno.

Es en proyectos como el kernel de Linux en donde si me parece apropiado hablar de comunidad.

La organización "The Linux Foundation" publica ahora el artículo "Who writes Linux?" un artículo que se basa en:

• Periodo de desarrollo desde 2005 a 2008


• Durante el que se liberaron 14 versiones del kernel


• Líneas de Código: 3621 añadidas - 1550 borradas - 1425 cambiada (aquí no he visto conclusiones pero me intrigan estos ratios)


• 3600 desarrolladores y más de 270 empresas

Hay datos y conclusiones muy curiosas pero llama la atención que el 70% del desarrollo está hecho por personas a las que se les paga por su trabajo.

Yo no sé si es malo o es bueno, pero no es lo mismo. No es lo mismo ¿no? Si creo malo ignorar algunas cosas o basarme en suposiciones erróneas.

JP Rangaswami en Musing about “commercial” development of Linux se plantea esto mismo y también pide ayuda, puntos de vista.

Es una máxima bien conocida en política que se puede dejar al legislador dictar las leyes que quiera siempre y cuando le deje a uno escribir el reglamento de cómo aplicarlas.

Algo en esa línea describe Michael Dolan en su post Comparing “open source” projects? en el cual invita en primer lugar a pensar porqué existe el proyecto para entender su naturaleza. El argumento de Dolan es que un proyecto no sería libre si no existiese una justificación económica para ello. De modo que, aunque no la entendamos, tiene que haberla.

Es significativo también que Dolan emplee el término “open source” entre comillas, síntoma de lo gastado y distorsionado que empieza a estar en la mente de los usuarios.

Yo discrepo de la tesis principal de que si OpenSolaris es abierto debe ser necesariamente porque Sun obtiene un mayor beneficio con ello que si es privativo. Opino que Sun ha sido antaño una empresa ferozmente propietaria y que abrieron el fuente de OpenSolaris porque o lo abrían o moría.

No sólo son un puñado de programadores locos los que se han lanzado alegremente a escribir Software Libre sin tener un modelo de negocio. Algunas empresas (no todas) también se apuntaron al carro del Open Source con catastróficos resultados (sobre todo en los noventa).

En ocasiones un paradigma puede arrastrar a toda una industria hacia el éxito o hacia el desastre.

Dolan dice que dos contribuidores de OpenSolaris (Juergen Keil y Richard Lowe) suman el 40% de las contribuciones, y que en total hay menos de 100 contribuidores, la mayoria de ellos con aportaciones nimias como correcciones de errores tipográficos. Y compara esta cifra con la de miles de contribuidores al kernel de Linux.

El caso es que una licencia libre es condición necesaria pero no suficiente para crear una Comunidad. La licencia es como la ley, pero luego viene el reglamento, que, para que se forme una Comunidad requiere:

1º) El propietario del código debe estar dispuesto a perder al menos parte del control sobre su evolución. La Comunidad puede tener interesés en que el código evolucione por líneas diferentes a las que más convienen al propietario. Si no se permite cierta libertad a los contribuidores de la Comunidad, normalmente estos se enfadan y dejan de contribuir.

2º) La estructura interna del producto debe ser lo bastante modular como para que se puedan añadir extensiones en pequeños trozos.

3º) Debe existir un proceso de aprobación de contribuciones transparente, justo y eficiente. Si alguien contribuye una pieza de código y dicha contribución es ignorada o rechazada injustificadamente, tal persona no sólo no contribuirá nada más sino que, además, desanimará a otros y hará que tampoco contribuyan.

4º) El proyecto debe tener un buen grado de buzz y hype. La gran mayoría de los usuarios, incluídos los programadores, en realidad no tienen un criterio técnico muy fino para distinguir un producto de otro y simplemente tiran al bulto. La gente contribuirá más al producto más conocido, simplemente porque es el más conocido.

Artículo relacionado: Communities, Then Customers (Forrester on OpenSolaris) (Jhonathan Schwartz)

Post relacionado: Cómo mover a la gente a que participe.

El nuevo Marketplace de SourceForge me parece definitivamente una mala idea.

Su reclamo publicitario dice: "Compre directamente de expertos", "Compre con confianza". Pero el problema es que el marketplace ahora mismo no ofrece ningún mecanismo para garantizar la veracidad de lo que afirmen los proveedores de servicios.

El sistema de rating de clientes satisfechos/insatisfechos es claramente insuficiente e ineficaz para discriminar a un proveedor frente a otro.
Éxitos pasados no aseguran éxitos futuros (sobre todo si la persona que los obtuvo ha dejado la empresa).

Lo más probable es que en poco tiempo el directorio esté lleno de spammers que busquen promocionar su compañía con falsas promesas sobre sus capacidades de servios, o factorias de software ultra-low-cost que prometan el oro y el moro por dos chavos.

No hay que ser en general pesimista ni agorero del desastre. Pero SourceForge no debería meterse a intermediar en servicios profesionales dado que ese tipo de mercado funciona mejor gestionado por los fabricantes a través de programas de partners certificados.

Al hilo del post anterior sobre sistemas descentralizados. Ayer estuve viendo la peli Banderas de Nuestros Padres (la verdad es que no veo casi nada de cine). Me vino a la cabeza una vieja idea de Frank Herbert (el de Dune) acerca de las consecuencias catastróficas de confiar el destino de la humanidad en las manos de un superhéroe.

La observación personal me ha convencido de que en la política y en su continuación por otros medios, la guerra, existe la tendencia a delegar toda la capacidad de decisión en cualuier líder que pueda perfilarse a si mismo dentro de la fábrica de mitos de la sociedad".

Se producen enormes problemas cuando los errores humanos acaecen en la grandiosa escala accesible a un superhérore".

Incluso si se encuentra a un héroe real e infalible, eventualmente los meros mortales acaban haciéndose con el control de la estructura de poder del superhéroe".

Es demostrable que las estructuras de poder tienden a atraer a personas que desean el poder simplemente para ejercerlo y que una fracción significativa de dichas personas están mentalmente desequilibradas y, en resumen, enfermas".

Fuente: Dune Genesis, Omni Magazine 1980

Ciertamente no quiero imaginarme cómo sería la Oficina de Gestión de Heroicidades de Superman. Lo más probable es que acabase tan plagada de corruptos, trepas y estafadores que tarde o temprano Superman acabaría dando con sus huesos en la cárcel como responsable subsidiario de las acciones de sus gestores.

He descubierto algo bastante viejo, aunque no por ello menos interesante (al menos para mi) se trata del concepto de organizaciones caórdicas (caos+orden) término acuñado por Dee Hock, fundador y ex-CEO de VISA.

VISA puede considerarse una organización totalmente excepcional. Ha conseguido coordinar nada menos que a 22.000 bancos en todo el mundo que emiten tarjetas de crédito.

He aquí los principios de Hock para dichas organizaciones:

• El poder y las competencias deben estar distribuidas en la mayor medida posibles. Ninguna función que pueda ser desempeñada por una unidad periférica debe ser desempeñada por una parte central de la organización. Ningún poder debe ser conferido a una división mayor que pueda ser ejercido razonablemente por un departamento más pequeño.

• El sistema debe auto-organizarse. Todos los participantes deben tener el derecho de organizar un auto-gobierno en cualquier momento, por cualquier circunstancia y a cualquier escala, con derechos irrevocables de participación de dicho auto-gobierno en entidades de nivel superior.

• El gobierno debe ser distribuido. Ningún individuo, institución o combinaciónd e ambos debe dominar las deliberaciones ni controlar las decisiones a ningún nivel.

• Debe combinarse cooperación y competición. Todas las partes deben ser libres de competir de forma única e independiente, pero asimismo estar unidas de forma que sean sensibles a las necesidades de otras partes, dejando a un lado el interés propio y cooperando cuando ello sea necesario para el bien del conjunto.

• Debe ser infinitamente maleable y al mismo tiempo extremadamente duradera. Debe ser capaz de auto-generar constantes cambios de forma y funciones, sin sacrificar su propósito esencial, su naturaleza ni sus principios.

• Su propiedad debe ser cooperativa y equitativa. Todas las partes afectadas deben ser elegibls para participar en funciones de gobierno y administración.

Vale la pena comparar estos principios con los de los bancos a los que VISA presta servicio (al menos los españoles) controlados jeráquica y burocráticamente hasta la médula y donde los directores de sucursal son meros ordenanzas de los departamentos centrales de riesgos y sus programas informatizados.

Ya me había topado antes con el concepto de organizaciones fractales, donde una parte de la organización realiza funciones similares, aunque no idénticas a otra. El problema de dichas organizaciones suele ser el caos. La mitad de la empresa no sabe lo que está haciendo la otra mitad, se trabaja y re-trabaja independientemente en lo mismo en un montón de sitios (en el caso del software esto puede ser fatal a la hora de integrar finalmente varias piezas de un producto).

Microsoft inventó ya hace mucho años una técnica llamada synchronize and stabilize basada en frecuentes hitos de sincronización y estabilización entre componentes independientes para poder desarrollarlos en paralelo pero manteniendo la compatibilidad entre ellos.

Yo creo que la clave está en la palabra auto-organización. Si consigues establecer una serie de directrices para que el sistema se regule él sólo (algo así como una solución tamponada a pH fijo) entonces tienes la clave para que pueda funcionar en modo caórdico.

Chris Anderson (editor de Wired y autor del popular libro Long Tail) ha publicado en su blog un post titulado la belleza de los ciclos libres [de reloj] en el cual comenta como gracias al aburrimiento han sugido mágicamente de la nada cosas maravillosas como la Wikipedia.

A veces hay cosas que ya todos sabemos, sólo que si de repente las dice un gurú, pues como que parece que sientan cátedra. Desde la propia Wired, Scott Gilbertson le ha respondido que actualmente la mayoría de las contribuciones importantes a los proyectos de primera división provienen de empresas y no de voluntarios.

Desde mi punto de vista el problema de la producción basada en ciclos libres de reloj es que está muy bien siempre y cuando no se requiera que el resultado sea 100% exacto ni fiable. La producción peer-to-peer es muy eficiente cuando se trata de producir cosas como SETI, Wikipedia o eMule, donde no importa realmente si alguna de las piezas producidas está mal. Pero en el caso del software eso no es así, porque un fallo en un sistema periférico (como el driver de una impresora, por ejemplo) puede afectar potencialmente a todo el sistema.
No es sólo que diseñar y controlar procesos de producción distribuidos sea más difícil que diseñar y controlar procesos centralizados, es que, además, no existen (que yo sepa) métodos generales bien conocidos y aceptados para garantizar la calidad de la producción distribuida.

Post relacionado: El mito del programador en sus ratos libres (Enrique Dans)

Hace algo más de un mes escribí un post titulado uno currando y diez mirando, pero al parecer me quedé corto. Mario Carbonell menciona en su post animando a los usuarios a participar que, según Jakob Nielsen, el 1% de los usuarios de una Comunidad hace prácticamente todas las contribuciones.

Por cierto que ayer leía en El Mundo que en Israel están privatizando los Kibbutz y que casi un siglo después de su creación, la histórica comuna de Degania acaba con su tradicional igualitarismo social.

Dicen que hoy vivimos en un tiempo donde no es factible mantener el sistema de reparto de bienes de los Kibbutz. O quizá será que, como dijo Abraham Lincoln: "la auténtica igualdad es tratar diferente a quien es diferente".

Ayer estuve cenado con Raquel en casa de mi buen amigo y ex-compañero David San Prudencio. De alguna forma salió el tema de cierto empleado al parecer bastante incompetente pero bien situado en la jerarquía de una empresa.
David, que ya tiene experiencia en estos temas, señaló que es precisamente su incompetencia lo que aumenta sus probabilidades de ascender. Este fenómeno ya fue enunciado en el Principio de Peter en 1969 y más tarde en el archipopular Principio de Dilbert.

Tomando café y un poco del excelente whisky escocés de Davd, hablábamos de otra muy buena razón para ascender a los imcompetentes de forma premeditada: impedir que una persona excesivamente competente adquiera conocimientos hasta el punto de poder organizar un asalto al poder.

En el área de Silicon Valley saben bien que el peor enemigo del dpto. de RR.HH. de una empresa boyante no son los dptos. de reclutamiento de otras empresas, sino la tendencia espontánea de los empleados más brillantes a declararse república independiente y montárselo por su cuenta.

Es por esto que en Google dan todo tipo de incentivos para que la gente más valiosa no se sienta motivada a independizarse. Incluso (táctica magistral) proporcionan un 20% de tiempo "libre" para que los empleados se dediquen a sus propios proyectos. Proyectos que, por cierto, al haber sido realizados durante la jornada de trabajo quedarán ineludiblemente en propiedad de Google, impidiendo en la práctica que ningún empleado monte una empresa que pueda robar un nicho a Google, usando la demanda judicial como amenaza.

No interesa que el mejor técnico de la empresa sepa demasiado sobre la cartera de clientes, lo mismo que tampoco interesa que el director regional de la zona estrella de ventas sea lo bastante hábil y tenga suficientes contactos como para montar un spin-off y quedarse con una parte del negocio.

En definitiva, la conclusión a la que quiero llegar es que las empresas no siempre promocionan a gente incompetente por error o desconocimiento, en ocasiones lo hacen de forma premeditada como una forma de preservar el status quo.

Por cierto, que Joserra cita la Tira de Dilbert con el jefe ese del cabello cornudo que tan satíricamente ejemplifica lo que quiero decir.

Este ascenso del hombre del traje gris lo comenta Carl Icahn en BusinesWeek:

"Yo tengo mi metáfora anti-darwiniana, el CEO es la clase de tipo fraternal que es fantástico para tomarse una copa con él. Es un superviviente y quizá para nada brillante, pero se labró su camino hacia arriba en la corporación. Y si eres un superviviente, entonces no tienes a nadie por debajo tuyo que sea más inteligente que tu. Así que eventualmente acabas rodeado de idiotas en todos los puestos de gestión".

El mecanismo descrito por Icahn es especialmente interesante porque explica la causa de que las empresas tiendan a destruir valor y buenas ideas antes que a crearlo. Si aceptamos las hipótesis de que a) un subordinado es aquella persona que siempre hará cualquier cosa un poquito peor de lo que su jefe la haría, y b) para ascender es necesario cierto grado de ineptitud. Entonces terminamos teniendo empresas que son maquinarias de matar la iniciativa y las buenas ideas.

Post relacionado: Incompetencia Calculada (VersiónCerø)

Ya he escrito con anterioridad sobre El mito de La Comunidad y sobre cómo la práctica totalidad de los desarrollos realmente notorios los ha escrito un grupo muy reducido de personas (amenudo una sola).

En ocasiones me gusta bromear diciendo que "el trabajo en equipo es un montón de gente haciendo lo que yo digo". En realidad no creo eso, pero sí creo que, todavía, y quizá por largo tiempo, la mejor manera de abstraer, sintetizar, coordinar, homogeneizar y ocultar la complejidad de algo tan complicado como un programa informático es dentro de la cabeza de una sola persona.

Ese es más o menos uno de los hallazgos del los Casos de Estudio de Mozilla y Apache de Audrius Mockus, Roy T. Fielding y James Herbsleb preparados para su publicación en ACM Transactions on Software Engineering and Methodology.

Es decir, incluso en los proyectos más grandes el grupo que realmente desarrolla el producto es pequeño.

Lo que considero más interesante del estudio es la hipótesis 4ª del apartado 3.3:
Los desarrollos Open Source que tengan un núcleo fuerte de desarrolladores pero no consingan un gran número de contribuidores más hallá de dicho núcleo, serán capaces de crear nuevas funcionalidades, pero fracasarán debido a la falta de recursos dedicados a encontrar y subsanar defectos.

¿Se entiende ahora un poco mejor porqué por mucho dinero que metas en un desarrollo propietario es prácticamente imposible dejarlo igual de estable que uno abierto?

Interesante el estudio Intrinsic vs. extrinsic incentives in profit-oriented firms supplying Open Source de Cristina Rossi y Andrea Bonaccorsi en fi®st m¤ñd@¥.

Se ha hablado por un lado sobre los modelos de negocio del Sw Libre, y por otro sobre las motivaciones individuales, pero este estudio trata de establecer la relación entre el modelo de negocio de una empresa, su actitud y sus acciones reales respecto al Software Libre.

La conclusión del estudio es que la percepción favorable hacia el software libre no implica acciones coherentes respecto al mismo. De hecho, la correlación entre la percepción empresarial sobre el software libre y lo que hacen esas mismas empresas al respecto es prácticamente nula.

El estudio incuye 146 empresas italianas divididas en 4 grupos:

1º) Empresas no orientadas a la comunidad (34,2%).
No perciben favorablemente el software libre y no hacen nada para apoyarlo.

2º) Empresas incógnita (8,9%).
No perciben favorablemente el software libre y, sin embargo, parece que nadan a favor de la corriente para apoyarlo.

3º) Empresas orientadas a la comunidad (18,5%).
Perciben favorablemente el software libre y actuan apoyándolo en consecuencia.

4º) Empresas oportunistas (30,8%).
Predican su respaldo al software libre pero en la práctica no hacen nada para apoyarlo sino justo lo contrario.

Sobre estos hallazgos, Rossi y Bonaccorsi plantean la siguiente

Hipótesis: Las actitudes y los comportamientos de las empresas dependen de la fortaleza de su compromiso con el nuevo paradigma. La empresas con un fuerte compromiso, tienen una actitud favorable y se comportan de forma consistente con él. En cambio, las empresas con bajo compromiso o bien están abiertamente en contra (Grupo 1) o bien tienen una actitud claramente incoherente (Grupo 4).

Mi opinión personal, al margen del estudio, es que las empresas del Grupo 4 hablan de Software Libre porque les conviene, pero en la práctica proponen soluciones abiertas sólo cuando no tienen otra opción, y tampoco contribuyen en nada a La Comunidad.

Artículo relacionado: Loves Linux, Runs Windows (Bruce Gain, Wired)

Provocador el post el open source no es negocio de Diego F. Glez. en Serial Blogger comparando menéame con Fresqui, en el cual sugiere que depender demasiado de la opinión de la Comunidad puede ser más un handicap que una ventaja.

No estoy de acuerdo con la idea de que una comunidad amplia sea un inconveniente. Con una única excepción, cuando cada nuevo usuario te cuesta dinero extra, y cuanto más creces más pierdes, y, además, no existe una estrategia para cambiar dicha situación en el futuro.

¿Cuando es bueno dejar de escuchar a los clientes/usuarios? Yo pondría una regla del dedo gordo muy simple: cuando empiezan a hacer sugerencias que sólo generan gastos extra y no mejoran en nada la rentabilidad del negocio para el empresario.

En el caso de Internet, dejados a su libre albedrío los usuarios no pagarían nunca nada por ningún servicio. Me hacen gracia los estudios esos de mercado donde le preguntan a la gente: "Oiga, ¿usted querría tener correo en el móvil?". Y responden en masa: "¡¡¡SIIII!!!". Sólo que el encuestador se olvida (normalmente) de preguntar: "¿Y estaría dispuesto a pagar 500€ por un terminal con e-mail push y 12€ de cuota mensual por 1Gb de tráfico?" : "¡¡¡NOOO!!!"

Artículo relacionado: Does Web 2.0 bubble have a silver lining? (Martin LaMonica)

Post relacionado: Cambios en Fresqui e inversión en Menéame (Antonio Ortiz)

¡Ay de los que juntan casa a casa y añaden hacienda a hasta ocuparlo todo! ¿Habitaréis vosotros solos en medio de la tierra?
Isaías 5:8

Las reglas del enfrentamiento entre fabricantes de software son como las de Los Inmortales: sólo puede quedar uno. Bueno, en realidad, es una mezcla entre Inmortales y Borgs: o mueres o eres "asimilado" que viene a ser lo mismo.

Ahora Los Inmortales se han puesto de acuerdo para decapitar a Red Hat. La existencia de Red Hat no le interesa a nadie: ni a Microsoft, ni a Novell, ni a Oracle, ni IBM, ni a Sun. Es un contendiente demasiado molesto. Oracle, en su habitual costumbre fagocitaria, ya se ha propuesto engullirlo. Microsoft, fiel a su tradición de competencia por aplastamiento militar, se ha aliado con Novell para debilitarlo.

Red Hat no interesa porque ha llegado la hora de privatizar La Comunidad. Es muy americano pensar que si existe una fuente de riqueza, alguien tiene que se necesariamente el propietario de esa fuente. Así que si hay riqueza (del tipo que sea) en La Comunidad, entonces alguien debe ser el propietario de dicha riqueza. Yo creo que las palabras de Steve Balmer pensando en Novell como un proxy con los clientes son toda una revelación.

A ver, tienes un portfolio de patentes de software por un lado, que te ha costado una pasta registrar. Y por otro lado hay una masa de usuarios "gorrones" que no quieren pagar ni un duro por esas patentes. Ya se ha comprobado (con Napster, AudioGalaxy, Kazaa, eMule, BitTorrent, etc.) que es imposible querellarse contra la muchedumbre en su conjunto. Porque tan pronto como cierras una fuente de violación de los presuntos derechos de propiedad intelectual aparece otra aún más sofisticada, popular y perversa.

Entonces introduces una entidad jurídica interpuesta. Alguien que de alguna forma ya esté haciendo dinero de La Comunidad pero con quien te puedas querellar y reclamarle royalties por las patentes vía judicial. Así cambias tu negocio de fabricar y comercializar algo, por el de sencillamente sentarte a esperar cómo te llueve el dinero.

La existencia de compañías como Red Hat o MySQL, que van por ahí navegando al estilo del capitan Jean-Luc Picard en su flamante Enterprise, es en si misma un desafio obsceno a la mentalidad latifundista de los grandes fabricantes.

Posts relacionados:
Microsoft llega a un acuerdo de cooperación con Novell (Sergio Montoro Ten)
Microsoft: Si te pasas a Linux podrás correr pero no esconderte (Sergio Montoro Ten)
Are you assimilated? (Matt Asay)

José Luis me mandó hace unos días una referencia a Knocking the exuberance out of employees, un post de Kathy Sierra.

Dieciseis razones por las cuales un robot es mejor que un empleado

1ª) Los robots no desafían el status quo.
2ª) No hecen preguntas incómodas.
3ª) Son 100% obedientes.
4ª) No necesitan días libres para sus asuntos personales.
5ª) No tienen vida fuera del trabajo.
6ª) Nunca hacen quedar mal al jefe.
7ª) Se visten exactamente como tu quieres.
8ª) No tienen opiniones obstinadas.
9ª) No tienen pasión, y, por tanto, nada por lo que "luchar".
10ª) Siempre están dispuestos a hacer cualquier cosa por ingrata que sea.
11ª) Son los genuinos trabajadores en equipo.
12ª) No protestan cuando los controlas hasta el último detalle.
13ª) No les importa como sea su puesto de trabajo ni equipamiento.
14ª) Nunca piensan en robarte el puesto.
15ª) Son chivos expiatorios perfectos.
16ª) Se llevan bien con los zombies.

¡¡¡Peeeero....

Todo esto estaría muy bien si los otros empleados y los clientes fuesen realmente robots PERO NO LO SON.

Hubo un tiempo en el cual las series de televisión representaban la quinesencia de la inteligencia como un ser que se había liberado de sus emociones hasta alcanzar la lógica pura.

Ahora sabemos que precisamente por estar desprovisto de la capacidad para reconocer e interpretar las emociones dicho ser no podía ser inteligente.

Los propios creadores de la serie se dieron cuenta de esta limitación y, en el siguiente generación, trataron de mostrar los problemas intrínsecos que acarrea la incapacidad para sentir empatía.

¿Y qué tiene esto que ver con el Software Libre?

Muy sencillo, lo que los altos ejecutivos de las empresas de software propietario no han entendido es que el Software Libre no es sólo un producto o una marca, sino también un mensaje emocional dirigido al corazón de las personas.

Durante los años 80 se desarrolló la creencia de que en última instancia, las multinacionales debían invertir en la creación de marcas y no de productos. Eso lllevó al cierre de muchas grandes factorías estadounidenses e inaguró la era de la deslocalización. Hasta la fecha actual en que lo que se lleva es capitalizar una marca al estilo de lo que ha hecho Apple con iPod.

Véase el BrandChannel reader's choice 2005

Fuente: brandchannel.com

Vale la penar notar que muchas de estas marcas no están basadas en el producto sino en la experiencia de usuario o incluso en sus valores: "no evil" en el caso de Google, "innovación y diseño" en Apple, "comercio justo" en Starbucks, "libertad" en Firefox.

Esto es porque la siguiente gran era del marketing no son los productos ni las marcas, son las emociones. Y para transmitir emociones se necesitan empleados capaces de sentirlas. En el opulento primer mundo los clientes ya tienen todas sus necesidades básicas más que satisfechas y sólo buscan esencialmente dos cosas: comodidad y sentimientos. Por eso nadie que siga esforzándose en crear una factoría de robots tiene ningún futuro empresarial.

A modo de ejemplo de lo que digo ver el spot del 50 aniversario de TVE.

Posts relacionados:
¿Cómo se gesta un empleado? (Cebolla)
La personalidad del trabajador moderno (Onésimo Alvarez-Moro)

El pasado jueves estuve cenando con mi amiga Sabina. Sabina ha vivido unos años en Dubai, y, por tanto, conoce mucho mejor que yo la cultura árabe. Aproveché la ocasión para preguntarle su opinión sobre porqué si los extremistas islámicos son tan enfervorizados creyentes, luego resultan ser tan malos soldados, con pésimos resultados en la mayoría de las guerras en las que participan.

Su explicación tiene que ver con la cadena de mando: "mira ­−me dijo− estos hombres árabes siempre están intentando mandar sobre alguna cosa, bien sea su pais, su esposa, sus hijos o lo que sea, por ese motivo tienen problemas para aceptar órdenes de nadie, lo cual es la base de la disciplina militar". Curiosamente el mismo problema es descrito por los marines estadounidenses cuando se quejan de que la tropa iraquí se niega a menudo a obedecer órdenes "porque ahora son hombres libres".

En los grupos de trabajo puede haber dos tipos de falsos consensos:

a) Cuando un grupo expresa su acuerdo de palabra, pero en el fondo no están conformes con la situación.
b) Cuando un grupo se pone de acuerdo para aceptar un hecho falso.

En informática, el primer caso sucede a menudo cuando se obliga a un programador a utilizar una tecnología o una metodología en contra de su voluntad. El resultado final suele ser muchas veces que el programador encuentra la manera de soslayar las imposiciones y hacerlo "a su manera", lo cual casi siempre acaba causando problemas a posteriori.

También es posible que el grupo en bloque esté disconforme, como por ejemplo cuando el cliente impone algo por la fuerza. La mejor solución para esto es, simplemente dejar que el grupo fije sus propios objetivos. Obviamente no se puede dejar a los programadores 100% a su libre albedrío (de ser así nunca fabricarían nada que realmente funcionase y fuese útil para un ser humano normal) pero, en la medida de lo posible, es mejor preguntar al grupo qué cree que es lo que ellos mismos deben hacer antes que dictárselo.

El consenso sobre hechos falsos se produce con frecuencia cuando todas las personas implicadas están deseosas de creer en la falsedad, porque la realidad les asusta o les resulta demasiado dura de aceptar. Por ejemplo, ponerse de acuerdo en que se puede realizar un proyecto en un plazo realmente imposible simplemente porque ello es conveniente para la organización.

Es muy difícil disuadir a las personas de una falsa creencia cuando sólo pensar en ella les produce un shock emocional (todo el mundo cree lo que quiere creer). Lo mejor en estos casos es una estrategia de contención de daños para conseguir que cuando, al final, la verdad brille, no sea demasiado tarde, o demasiado catastrófico.

Ethan Zuckerman escribe en su post Wikipedia and F/LOSS - some challenging comparisons algunos comentarios sobre el panel de Siobhan O'Mahony en Wikimania 2006.

A mi personalmente me preocupa que bajo el paraguas de Software Libre o Cultura Libre se acaben englobando tantas cosas que se desvirtue el concepto original.

Creo que es un peligro análogo a cuando la Iglesia Católica permitió que se instaurase el término "matrimonio civil". En un intento de reforzar el matrimonio eclesiástico (muchos curas no te casan en la iglesia si no te has casado primero en el juzgado) se fomentó el uso de "matrimonio civil" en vez de "unión civil", y en el proceso, la Iglesia perdió, sin darse cuenta, la exclusividad de uso de la palabra "matrimonio". No es que haya nada malo en el matrimonio entre personas del mismo sexo, sólo que al final el uso lingüístico se convierte en algo como la palabra "objeto" en informática que se ha sobre-utilizado hasta el punto en que sirve para designar prácticamente cualquier y ninguna cosa.

Volviendo a la Wikipedia, existen algunas diferencias notorias con el Software Libre:

• La Wikipedia difiere del Software Libre en un parámetro crucial: la permeabilidad. El nivel de apertura de una organización se mide por dos factores: su transparencia (la capacidad para ver desde fuera lo que está pasando) y la permeabilidad (la capacidad para influir en lo que sucede). Con esta métrica la Wikipedia es muchísimo más permeable que el software porque la barrera de entrada para participar en Wikipedia es mucho más baja que en el Software Libre.

• La Wikipedia no tiene algo así como una versión o release, sino que evoluciona de forma continuada a cada instante.

• La enorme extensión del ámbito de la Wikipedia puede crear zonas de calidad muy desigual. Aunque afortunadamente los errores en un sitio afectan mucho menos a otros en la Wikipedia. En un programa un bug en algún módulo ignoto puede hacer caer todo el sistema como un castillo de naipes.

• Los mecanismos de control sobre los contenidos son completamente diferentes en la Wikipedia y en el Software Libre. En el software las decisiones finales las toma el equipo nuclear que maneja el proyecto mediante una "dictadura benévola".

• El protocolo de comunicación entre los contribuidores es también diferente. Los escribientes de la Wikipedia no se comunican entre ellos con listas de correo y bug trackers como los programadores.

• La atribución de autoría es mucho más difusa en Wikipedia. De hecho uno de los problemas que yo creo que se debería solucionar en Wikipedia es que debería ser obligatorio citar el autor y la fuente de la información para poder contrastarla.

Yo creo que parte de la solución puede estar relacionada con una técnica de divide y vencerás, creando "Minipedias Temáticas" al estilo de Cordobapedia. No importa si la proliferación de Minipedias genera cierto grado de redundancia en la información, porque es imposible que una única fuente proporcione toda la información relevante. Si hubiese una Wikipedia de la Guerra Civil española, tendría que tener al menos dos versiones paralelas. Lo contrario sería dejar que un bando re-escribiese la memoria histórica.

Post relacionado: Open source as metaphor (Nicholas Carr)
Artículo relacionado: Internet encyclopaedias go head to head (Jim Giles)

Tengo tantos libros que a veces me paseo por mis viejas estanterías y encuentro algo que ni siquiera sabía que tenía. Es como hacer arqueología, y de vez en cuando se encuentra alguna gema preciosa.

Ayer encontré un grueso volumen de Oson Scott Card titulado Mapas en un espejo. Una recopilación de cuentos que trae, entre otras cosas, una narración titulada El Originista, relacionada con Hari Seldon y la Fundación de Asimov. En una parte de la historia la antropóloga Deet explica que :

El vigor de una Comunidad depende de la lealtad de sus miembros, y dicha lealtad se puede generar y reforzar mediante la diseminación de relatos épicos [....] Historias que permiten que La Comunidad parezca más importante, más crucial para la vida humana.

Al leerlo me acordé de una exhibición aérea a la que asistí hace un tiempo. Asombrada por las acrobacias una mujer de la grada exclamó: "¡Vaya! Parece mentira lo que hacen los aviones modernos" Un hombre a su lado la corrigió diciendo: "No señora, esas acrobacias no las hace el avión, las hace exclusivamente el piloto".

Un poco lo mismo pasa con el software. Cuando abres el código y te pones a leerlo, está llenos de relatos épicos con nombre y apellidos.

Parece mentira que a estas alturas muchos supuestos profesionales del sector TIC aún no hayan entendido que los programas los escribe una persona. Todos los programas realmente meritorios que conozco los ha escrito, en principio, una única persona (dos a lo más) prácticamente en solitario.

Es una regla de los sistemas informáticos que le leí una vez a Bjarne Stroustrup (el creador de C++): Todo sistema grande y complejo que no ha evolucionado a partir de otro más simple, no funciona y además es imposible arreglarlo para que funcione.

Así es la historia del Software Libre, empieza con un relato épico, de algún programador que pensó que realmente podía escribir algo que marcase una diferencia.

Post relacionado: Cómo mover a la gente a que participe
Relato épico relacionado: Gentoo al desnudo (Libertonia)

En el post How Amazon/AMT can change the internet economy del blog de Bitporters Media se describe un concepto llamado Workware que propone fusionar Amazon Mechanical Turk (AMT) con Google AdSense para generar una fuente de ingresos.

El problema es el siguiente: muchas personas visitan un site por sus contenidos o para obtener una descarga gratuita. Estas personas no están dispuestas a pagar ningún dinero, de modo que hay que buscar otras formas de que ofrezcan una compensación por lo que obtienen.

El Workware está basado en el poder de muchos. Se exige a la persona que va a obtener el producto que primero realice una pequeña tarea, por ejemplo señalar una dirección en una fotografía con AMT. A cambio de esta tarea obtiene el producto.

Nota: Amazon Mechanical Turk es un entorno de trabajo distribuido en el cual Amazon paga pequeñas cantidades de dinero a personas que realizan micro-tareas. Suelen ser cosas como reconocimiento de patrones visuales que para el ordenador son muy complicadas pero que un humano puede hacer de un plumazo a simple vista. AMT lanzó recientemente un Web Service que permite realizar las micro-tareas directamente desde otro site sin conectarse a Amazon.

Regla de oro de la rotación de personal: Independientemente de los cambios que haya en la plantilla de una empresa, lo que curran de verdad siempre siguen siendo los mismos.

Vía Barrapunto se llega a un anuncio en masGuadalinex informando de que los 5 gatos de Gimp necesitan ayuda.

Los casos prácticos están demostrando que es muy difícil reclutar programadores voluntarios que tengan continuidad en el proyecto. Si el proyecto, además, no tiene un proceso de desarrollo inherentemente distribuido, la cruzada se convierte poco menos que en misión imposible.

En tecnocidanos, Antonio Lafuente cita en su post la descorporativización del talento en referencia al término Crowdsourcing acuñado por Jeff Howe en Wired (The Rise of Crowdsourcing) para referirse a la variante de externalización de tareas outsourcing pero sin emplear terceras empresas.

Según Lafuente: "la gente puede autoorganizarse siempre que la tecnología lo tolere o, en otras palabras, siempre que permita a los participantes cogestionar todas las fases del producto resultante".

Ya es un hecho bien establecido que en los nuevos modelos de desarrollo los aspectos sociales son inseparables de la tecnología. Yo creo que la Web 2.0 auténtica tiene mucho de esto: una fusion de tecnología y personas estilo ciborg.

Sin darnos cuenta ya empezamos a usar este tipo de Crowdsourcing. En la boda de Alfredo Romeo, los novios tomaron la decisión de abrir un álbum público de fotos en Flickr. ¿Qué las fotos del fotografo profesional no te parecen suficiente? Pues le pides a los invitados que se lleven una cámara (ahora pesan poco) y que hagan fotos para luego compartirlas en Flickr ¡eso es crowdsourcing!

El Crowdsourcing, sin embargo, no es la panacea, la clave estriba en darse cuenta de que las empresas no aportan materia gris. La materia gris la aportan las personas. Lo que las empresas aportan es el tinglado legal necesario para que sea posible delegar el trabajo bajo unas condiciones previamente pactadas que aseguren la predictibilidad del resultado.

Las empresas de outsourcing no suelen ser fuentes de conocimiento añadido. En la mayoría de casos chupan conocimiento del cliente, aportando, como mucho, unas pocas competencias técnicas.

El Crowdsourcing es una idea interesante, una PO (provocación) diría Edward DeBono. Pero sólo puede funcionar si se complementa con algunos mecanismos regulatorios.

Artículos relacionados:
Las muchedumbres en los negocios y la investigación (Francis Pisani)
Superstruct: Crowdsource the Future (Brady Forrest)

Juantomás contaba en la LinuxWorld Expo de Madrid, que los servicios de inteligencia estadounidenses en Irak habían decidido bloggear (de forma privada) la información que proporcionaban los espías sobre el terreno acerca de los grupos insurgentes. Está claro que un flujo constante de comunicados sobre actividades sospechosas supone una sobrecarga de información demasiado pesada de digerir para cualquier oficial al mando. Es mucho mejor simplemente escribir los informes, ponerles tags, indexarlos y dejar que las personas interesadas los busquen y los consuman cuando crea necesario.

En relación a este tipo de comunicación, me ha llamado mucho la antención el comentario de Rafael Chamorro sobre Interoperabilidad entre Administraciones Públicas acerca del wiki internet & euskadi.

Si es tan costoso coordinar de forma centralizada a las administraciones públicas, quizá lo mejor sea no intentarlo con tanto ahínco, y, en cambio, facilitar herramientas de "divide y vencerás" mediante las cuales puedan cooperar ellas mismas de forma descentralizada.

Collin Powell es una de mis fuentes de citas favoritas. En una ocasión dijo: "No battle plan survives contact with the enemy".

Probablemente estaba pensando en una situación que se conoce como fog of war (niebla de guerra). Cuando empieza la batalla las unidades se dispersan, el plan inicial se desbarata, y el mando central puede perder el control de dónde está cada unidad y lo que está haciendo. Incluso si se sabe dónde está cada unidad, la sobrecarga de información procedente de los múltiples puntos de contacto armado hace muy difícil la toma de decisiones de coordinación en tiempo real. Todo el mundo grita al mismo tiempo por el canal de radio diciendo que tienen bajas y pidiendo evacuación aérea y fuego de artillería.

En medio de la niebla de guerra es posible mantaner la iniciativa bélica si se cuenta con unidades preparadas para tomar deciciones tácticas independientemente, aunque estas decisiones no estén coordinadas, en principio, con una estrategia global; la ejecución operativa eficiente puede ganar tiempo suficiente como para que el mando estratégico tenga tiempo de analizar la situación y coordinar una respuesta.

Curiosamente esto suele ser lo contrario de lo que hacen las empresas. Cuando hay crisis todo el mundo se detiene esperando a ver lo que hace el de arriba. Se bloquean las iniciativas departamentales por miedo y con el fin de evitar males mayores.

Por mucho que deslumbren flamantes porta-aviones, los que al final determinan el resultado de la guerra son los del fusil al hombro que andan cada día batiéndose el cobre con el enemigo.

Así que, señor presidente: si no sabe usted qué hacer, suelte a los perros de la guerra. Soldados sin general, ganaron muchas contiendas, generales sin soldados, que se sepa, no ganaron ninguna.

Hace tiempo que me resisto a escribir un post que trate de blogs.
Un montón de geeks mirándose en el ombligo en la blogocosa me parece el colmo de la endogamia.
No obstante, he superado mi fobia y me dispongo a aportar mi granito de arena sobre el porqué de los blogs.

Existe cierta discusión sobre si los blogs desplazarán a los medios tradicionales o no. Mi opinión es que no ocurrirá ni una cosa ni la otra. La red funciona bajo la economía de la antención. Por consiguiente el lugar que ocupen los blogs está determinado por la forma en la que puedan influir en dicha economía de la atención.

La atención está motivada por el interés y, como describe Edward de Bono, las operaciones básicas del interés son :

•La posibilidad Los blogs pueden plantear hipótesis, conjeturas y posibilidades que los medios tradicionales no pueden sugerir debido a su necesidad de parecer 100% objetivos.

•La alternativa Los blogs pueden proponer abiertamente soluciones alternativas. Aunque estas no estén, en principio, bien fundadas ni comprobadas, pueden inducir un brainstorming.

•La conceptualización Un post puede servir para explicar un concepto. Esto muy rara vez se hace en prensa escrita clásica.

•La vinculación Los mejores ensayistas vinculas los hechos inmediatos con causas previas, así como hechos aparentemente inconexos para ampliar el campo de interés.

•La futurología Es muy divertido hacer predicciones. Visualizar, imaginar.

•La provocación La provocación es la base de la creatividad. Además sirve para echar carnaza a la audiencia. Cada lector lleva una "maruja" latente dentro.

•La focalización Un blog puede centrar la atención sobre un tema que, por el motivo que sea, no interesa a los periódicos.

•La catalogación Un post puede ser algo meramente explicativo. Que resume, sintetiza, y explica las cosas bien con analogías claras y adecuadas.

Guy Kawasaki dice que hay tres tipos de bloggers: los newsbots humanos, los criticones y los ensayistas. Yo añadiría los que simplemente escriben un diario sobre su vida. Para Kawasaki los más interesantes son los ensayistas, y probablemente tiene razón, pues son los que pueden ayudarnos a dirigir eficientemente nuestra atención hacia los temas que nos interesan.

Cuentan los expertos militares, que una de las peculiaridades del ejército israelí es que el comandante de la unidad suele marchar al frente de la columna y no en la retaguardia, como ejemplo de una cultura donde los oficiales deben batirse el cobre codo con codo con la tropa.

Esta mañana andaba leyendo un post en el blog de Matt Assay acerca del libro Trust de Francis Fukuyama.

Matt muestra en un excelente gráfico la diferencia que existe entre el soporte en una compañía de software propietario y el soporte de un producto libre.

Fuente: A question of 'trust'

En los productos Open Source los desarrolladores originales del software tienden a estar mucho más disponibles para los clientes y los usuarios que en productos cerrados.

Esto es una ventaja táctica muy importante. No es tan sólo una diferencia en la estructura del producto o en la naturaleza de la oferta económica. Es una mayor implicación de los desarrolladores con los clientes.

En muchas empresas de software libre, si quieres, en 48h tienes al padre de la criatura en tu oficina con un portátil debajo del brazo. No se trata de un técnico de soporte con un master en el producto de turno a quién han barnizado de conocimientos para hacer las funciones de pitufo bombero. Se trata del creador del invento en carne y hueso, quien puede resolver más en una tarde que un batallón de especialistas en un mes entero.

A mi una de las cosas que me indigna es llegar a la oficina a última hora de la tarde y encontrar a un programador solitario intentando resolver un problema sin ayuda por sus propios medios. En una compañía con auténtico espíritu Open Source nunca se pide pizza de cena para menos de cuatro personas. Los programadores, como los coroneles israelíes, marchan al frente del despliege de las aplicaciones y no ocultos tras capas y capas de soporte de primer, segundo y tercer nivel. Nadie se queda "sólo ante el peligro", ni los clientes ni los programadores.

José Luis Marina, director de I+D de Peopleware, me ha pasado una referencia al post Job Titles vs. Job Descriptions vs. The Job del blog de Krugle en el cual John Mitchell reflexiona sobre la repercusión que el nombre de un cargo tiene sobre las funciones que se le atribuyen a posteriori.

Me ha llamado la atención porque cada vez estoy más preocupado por las palabras que empleamos y su significado. Las cosas que repetimos verbalmente una y otra vez las interiorizamos hasta el punto que pasan a formar parte de nuestro esquema de pensamiento.

He perdido la cuenta de las ocasiones en las que le he suplicado a los programadores que no digan palabrotas delante de los clientes, me refiero a cosas como "ñapa", "pete", "casque" y toda la pléyade de jerga informática para describir los inumerables errores de los programas.

Me pregunto en qué momento de la historia el Departamento de Personal se metamorfoseó en el Departamento de Recursos Humanos. Quizá intentaron enmendar la imagen de departamento que sólo se usa para pagar la nómina y despedir gente, cuando se puso de moda el coaching y la gestión por competencias. Pero a mi me gustaba más el termino "de Personal", me da la impresión de que la palabra "persona" lo hacía más humano que la palabra "recurso". Quizá por eso ahora las ETTs encubiertas de subcontratación de informáticos los tratan amenudo como recursos porcinos más que como recursos humanos.

Personalmente, hace tiempo solía tener un pequeño grupo de trabajo llamado Testeo y control de versiones. Como rara vez nos daba tiempo de probar en profundidad y había bastantes parches (±1 por semana) frecuentemente nos metíamos en problemas porque los implantadores se quejaban vehementemente de que no habiamos testeado nada. Luego le cambiamos el nombre a Control de Calidad para ver si dejaban de fastidiarnos con la monserga del testeo. Conseguimos convencer a los implantadores de que nosotros no estábamos alli para probar nada, pero el problema empeoró porque la gente empezó a quejarse de que los entregables eran de mala calidad. Cambiamos nuestro nombre de nuevo a Control de Calidad de Software para dejar claro que si el programa no hacía lo que se había pedido en las especificaciones no era nuestra responsabilidad sino la del jefe de proyecto. Al final, un tipo más listo que yo se hizo cargo del grupo y lo rebautizó como SQA (Software Quality Assurance). Lo bueno de SQA es que la gente de la calle no suele saber bien lo que significa; de modo que cuando reclaman es más fácil despacharles diciéndoles que se han equivocado de extensión. El jaleo de los sufridos usuarios continuó, por supuesto, pero desde entonces el departamento funcionó mejor y pudo ocuparse más eficientemente de sus tareas prioritarias con menos malentendidos externos.

Este fin de semana desempolvé un libro titulado The Leader of the Future lo compré en el 97 y lo he tenido tanto tiempo en la cola de ejemplares pendientes de leer que ahora puede comprarse usado en Amazon por veinte centavos de dólar (tengo overbooking literal en casa).

Al grano, Charles Handy empieza el capítulo primero con una exposición sobre los cambios en las organizaciones empresariales, que se parecen sorprendentemente a los principios que rigen las comunidades de Software Libre.

De un tiempo a esta parte se habla de cómo aplicar los conocimientos adquiridos en el Software Libre a otras áreas. Quizá dicho conocimiento ya estaba allí y lo único que ha hecho el Software Libre es demostrar que realmente constituyen un modelo organizativo viable.

La hipótesis de partida es que las organizaciones están adquiriendo configuraciones organizativas en red. El presidente de una empresa para la que trabajé hace años hablaba incluso de organizaciones fractales, aunque debo confesar que nunca entendí muy bien que quería decir cuando afirmaba que es bueno que una parte de una empresa se parezca a otra, el lo relacionaba con el caos, quizá por eso había tanto jaleo organizativo allí en aquella época.

En una organización en red los ingenieros ceden paso a los políticos, a los empleados se les llama "partners" y los jefes se convierten en "facilitadores".

El mayor peso de la política vs. los ingenieros implica que determinados conceptos de la política se vuelven más importantes en las organizaciones:

Subsidiariedad: La subsidiariedad consiste en que un estrato de nivel superior no debe asumir responsabilidades de un estrato inferior. El ejemplo, fácil de entender es porqué el estado no debe usurpar el papel de la familia. La subsidiariedad se viola sistemáticamente en las empresas por el afán desmesurado que se pone en evitar errores. Los errores son obviamente algo imprevisto que causa efectos desagradables. Pero muchas organizaciones que se sobre-burocratizan para minimizarlos acaban teniendo problemas peores que los que intentaban evitar. La subsidiariedad es una práctica habitual en los seguidores del Software Libre. La subsidiariedad es lo que ha permitido a Wikipedia existir y crecer gracias a la fe en que las personas responsables no necesitan un revisor editorial, asumiendo los problemas legales derivados de dicha falta premeditada de control.

Autoridad Ganada: En la política la autoridad es otorgada por aquellas personas sobre las que será ejercida. Los líderes necesitan espacio para crecer y ganar el respeto de sus futuros subordinados. No más superestrellas con un master MBA ni castas sociales, el liderazgo se gana demostrando ser merecedor del mismo. Estos conceptos de meritocracia y reputación adquirida forman parte de la cultura esencial del Software Libre.

Virtualización: Una organización virtual es aquella que no se ve y que, a pesar de ellos, suministra bienes tangibles o intangibles. La virtualización está emparentada con la globalización y con off-shoring de mano de obra. La vistualización ha llegado tan lejos en el Software Libre que la mayoría de los proyectos realmente interesantes son virtuales.

Para hacer frente a estos efectos organizativos y sociales, el líder del futuro debe reunir tres condiciones clave:

• Confianza en si mismo.
• Habilidad para gestionar un liderazgo distribuido.
• Pasión por su trabajo.
• Preocupación genuina por las personas a su cargo.
• Capacidad para afrontar la soledad si debe cruzar un desierto.

Post relacionado: ¿Siguen siendo necesarios los líderes? (Juan Freire)

En javaHispano he encontrado una referencia al artículo de Robert Thornton en EclipseZone Too Many Cooks Spoil the IDE en elcual argumenta que la arquitectura de Eclipse basada en plug-ins es simultáneamente una fortaleza y una debilidad.

Agregar componentes de una manera metódica, práctica y fiable es uno de los problemas abiertos más importantes de la ingeniería de software.

E incluso aunque se dé con una técnica repetible para juntar piezas a final lo que los clientes quieren son soluciones completas y no un kit de hágaselo usted mismo.

Es por esto que yo entiendo que algunas personas prefieran NetBeans, quizá con algunas funcionalidades menos pero todo "de serie" que tener que ir añadiéndole "extras" al producto base en una lenta curva de aprendizaje y estandarización.

Esther Dyson's perspective :

La debilidad de las empresas actualmente son las personas que crean ineficiencias y se benefician de ellas.

Los que han estado por Silicon Valley últimamente cuentan que Google ha dado con una nueva estrategia competitiva basada en la maquinaría de recursos humanos en vez de las técnicas habituales de marketing y finanzas.

En vez de gastar dinero en branding, comprar otras empresas, o defender nichos de mercado, Google se "compra" directamente a todas las personas que hacen que eso suceda.

Se emplean toda clase de mecanismos para atraer y reclutar materia gris, desde las técnicas clásicas de "recomienda a un amigo" o anuncios en la revista mensual de MENSA hasta cosas originales como el concurso Google Code Jam.

Las condiciones de trabajo son desde luego atractivas: buen sueldo, cuantiosos beneficios sociales, promesa de una cultura abierta, formación y crecimiento personal, un 20% de la jornada laboral libre para que el empleado trabaje en el proyecto que quiera, y, como no, la posibilidad de hacerse millonario con las stocks.

Según se rumorea, el plan de Google es duplicar su plantilla laboral a corto plazo hasta alcanzar los 10.000 empleados.

Habrá que ver si el hipercrecimiento no les acaba creando problemas. Nunca que he conocido una empresa que se lanzase a reclutar "a sako pako" y no terminase teniendo serios quebraderos de cabeza.

Hay dos grandes peligros derivados de reclutar tan rápido :

1º) cuando se abre la veda de contratar, junto con las "buenas boyas" se cuela también mucha "chusma" entre los remeros, lo cual acaba causando enfrentamientos organizativos, mala burocracia, y un ambiente social enrarecido.

2º) la frustración es una función de las expectativas creada antes que de lo que se consigue realmente; si se crean demasiadas expectativas, y luego no se cumplen, ello ocasiona protestas y rebeliones, en el caso de Google, con la acción tan sobrevalorada sea cual sea el criterio que se use, un resfriado bursátil podría originar fácilmente una crisis entre los empleados.

Ver cuestionario de selección estándar de Google: Google Labs Aptitude Test (Cruft)

Artículos relacionados:
A Case Study of Google Recruiting (John Sullivan).
Google y los procesos de selección (Enríque Dans)
Planeta Google (Patricia Fernández de Lis)

En el repositorio de documentos de la Free/Open Source research Community del MIT, puede encontrarse un interesante trabajo de Alan MacCormack, John Rusnak y Carliss Baldwin fechado el 9 de junio de 2005 y titulado Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code.

La conclusión más interesante del estudio es que la estructura organizativa empleada se refleja en la estructura del producto terminado de tal forma que el software propietario producido por un grupo limitado y cerrado de personas tiende a ser mucho menos modular y estar más estrechamente integrado que el sofwtare producido por una comunidad de individuos relativamente independientes.

Lo que es en principio una necesidad organizativa, que los módulos estén desacoplados para poder trabajar en ellos en paralelo, puede convertirse en una ventaja final del producto al ser más modular.

Por supuesto, no todos los proyectos de software libre son intrínsecamente más modulares que los propietarios, porque hay mucho software libre que no está desarrollado para nada por una comunidad. Los autores citan el ejemplo de cómo el código de Mozilla (que aunque basado en Netscape se acabó re-escribiendo entero) es más modular que el kernel de Linux, desarrollado inicialmente por Torvalds y mantenido por un número reducido de personas.

Yo añadiría un aspecto más, relevante a la hora de elegir un proyecto libre, no es lo mismo un proyecto libre desarrollado como tal desde el principio, que un software propietario liberado a posteriori. Esto es porque la filosofía de diseño era diferente en el momento en que se concibieron ambos tipos de producto. El Software Libre se escribe con la intención de que la Comunidad se lea el código, lo entienda y contribuya extensiones. El Software Propietario lo escribe un puñado de programadores con la finalidad de cobrar (y seguir cobrando) lo más posible a fin de mes. A fin de cuentas el programador asalariado no percibe ninguna plusvalía por la mayor difusión de su obra, de modo que ¿porqué habría de importarle si resulta o no fácil de usar para otros?

Que los estudios de post-grado tienen una componente docente y otra componente de networking social lo hemos sabido siempre.
Yo más bien creo que lo del networking social es un gancho para los trepas que buscan mejorar su sueldo.
Conozco alguno que consiguió un buen puesto gracias a la fortuna de compartir asiento de avión con la persona adecuada, y yo mismo he iniciado de forma fortuita un par de negocios en pleno vuelo.

Miguel Valdés publicaba hace poco en versióncerø un artículo sobre la nueva generación de comunidades y su relación con las empresas.

Pero lo que me ha llamado la atención leyendo Las Comunidades en la Era de Internet de Enrique Dans en Expansión, es que el Instituto de Empresa haya decidido incluso monetarizar el asunto mediante su Global Communities MBA donde la oferta estrella es su network global de contactos.

Parece ser que todo lo que te puedan enseñar en el máster, puedes encontrarlo online, o aprenderlo por ti mismo a base de curiosidad y experiencia. Pero lo que no puedes hacer tú solo es justamente relacionarte con los demás; y esa interacción justo y únicamente lo que compras en el máster.

Juantomás ha pasado un correo con un ensayo referenciado en su blog escrito por Yochai Benkler en 2002 y titulado Coase’s Penguin, or Linux and the Nature of the Firm. El material ya tiene cierta edad y el título no es muy afortunado, pero se trata de un texto conciso y lleno de lucidez en toda su exposición, en la cual presenta el Commons-based peer production model (traducible por algo así como Modelo de producción entre iguales basado en patrimonio común).
El modelo aparece como alternativa a la producción basada en corporaciones o en mercados.
El texto tiene muchos puntos que merece la pena comentar y que detallo a continuación.

En Open Source Software New me he encontrado un comentario titulado Microsoft rejects IBM on-demand strategy. En el cual se afirma que Microsoft continuará su política de software propietario porque considera el software libre una experiencia de desarrollador y no una experiencia de usuario. Por consiguiente, como a los usuarios les de igual si el software es libre o no, sólo es preciso abrir el software de infraestructura que afecta a la experiencia de los desarrolladores.
La verdad es que es una idea interesante que justifica en parte porqué el Software Libre penetra mejor en unas áreas que en otras. Este tipo de razonamiento lo han empleado muchas veces para justificar porqué es suficiente con dar unos APIs y no hace falta abrir los fuentes, pero sólo es como el que se tira del piso 100 de un rascacielos y cuando va por el piso 50 afirma: "bueno, por ahora todo va bien...".

Desde octubre de 2004 tenemos otro interesante directorio de aplicaciones empresariales libres: www.aplicacionesempresariales.com
Aunque se trata de un proyecto joven que todavía se está definiendo, Aplicaciones Empresariales ya ha iniciado el vuelo para hacerse su lugar mientras se finalizan otros proyectos que sus creadores están desarrollando.

Y es que este portal es la iniciativa de cuatro jóvenes emprendedores que, bajo el nombre de SmallSquid, se agruparon con el fin de lanzar proyectos web que consideraran originales, atractivos e interesantes. Durante la preparación del proyecto, buscaron y probaron aplicaciones que les facilitasen diversas tareas y que pudiesen ofecer a sus clientes, como soluciones ERP y CRM, apostando por herramientas libres.
Según me cuenta José Manuel Pérez, uno de los creadores, durante la búsqueda no dieron con ningún portal español especializado que desgranase el conjunto de soluciones existentes para las empresas y ese fue por ese motivo que empezó a madurarse la idea de aplicacionesempresariales.com.

El portal está orientado tanto a desarrolladores como a clientes finales con diversas tácticas de promoción específicas para cada uno de ambos públicos objetivo.
El futuro es conseguir una masa crítica de lectores que además de "consumir" aporten sus propias experiencias, criticando y aconsejando sobre los productos.

Otro directorio útil es OSSwin project que recopila aplicaciones libres que corren bajo Windows.

Un tema recurrente en los foros Open Source es la [falta de] participación de La Comunidad en el desarrollo de un proyecto.

Montas tu proyecto con gran ilusión (y a veces un igual grado de ingenuidad) lo haces público, y esperas a que miles de agradecidos usuarios te escriban para darte las gracias; pero ¡oh! sorpresa, te quedas más solo que Gary Cooper en el filme de Fred Zinnemann del 52.

¿Qué es lo que mueve a la gente a participar en una comunidad?
Veamos algunos trucos para incentivar que la gente contribuya.

1. La gente contribuye más cuando cree que sus aportes son únicos y especiales.
A fin de cuentas ¿para que iban a reportar un bug que ya conoce todo el mundo o repetir una receta manida?

2. La gente contribuye más cuando cree que sus aportes serán reconocidos.
La fama le gusta a casi todo el mundo.

3. La gente contribuye más cuando cree que sus aportes serán de utilidad para otros miembros de La Comunidad.
El altruismo también existe.

4. La gente contribuye más cuando cree que recibirá una recompensa.
Esta puede ser tangible o intangible, como los foros que otorgan karma a sus miembros destacados.

5. La gente contribuye más cuando existen objetivos claros.
Tanto si se trata de cerrar una build en una fecha, completar un testeo traducir la documentación, cuanto más clara la misión más fácil para la gente alinearse con ella.

5.1. Corolario: Los objetivos individuales motivan más que los objetivos de grupo.
La gente tiende a relajarse cuando la responsabilidad de un objetivo se diluye en un colectivo.

6. Si las metas fijadas no son creíbles la gente no se animará a participar.

7. La gente contribuye más cuando cree que el resultado de la cooperación colectiva será de utilidad directa para ellos mismos.

Conclusión:
Una comunidad de usuarios no se crea ni se mantiene espontáneamente. Incluso los productos que son terriblemente populares pueden tener un índice de contribución muy bajo si no se aplica una política sistemática de incentivos a la participación.
El grado de esfuerzo que un miembro pondrá es una función del beneficio que dicho esfuerzo genere para otros y para si mismo y de cuan cláramente cuantificados estén esos dos parámetros.

Acabo de terminarme el libro Code Reading: The Open Source Prespective acerca de la importancia de leerse el código fuente de una aplicación.

Creo que es difícil sobrevalorar la importancia que tiene leerse el código para depurar aplicaciones.
He estado en centenares de reuniones donde se hablaba de si se habían pasado tales o cuales pruebas o si se había verificado esto o lo otro y nunca, o casi nunca, nadie preguntaba, pero, bueno ¿alguien se ha leído el código?

En ingeniería de software se estima que corregir un bug durante la implementación de un módulo es un 70% más barato que corregirlo durante las pruebas de integración y un 90% más económico que hacerlo durante el beta testing.

El el caso de sistemas en producción los costes pueden ser aún mucho mayores. Recuerdo haber perdido semanas enteras de trabajo persiguiendo bugs muy difíciles de evitar cuya causa hubiese sido probablemente mucho más fácil de diagnosticar si hubiésemos tenido el código fuente de las aplicaciones.

Creía que éramos los únicos a quienes nos costaba Dios y Ayuda montar una comunidad de desarrollo en torno a nuestro producto de software libre.

Pero según leo en este post de SteelGryphon, uno de los seis miembros del equipo de desarrollo de Firefox afirma que en realidad el producto entero se lo pican entre dos o tres personas y los otros 25 millones de usuarios, básicamente, miran.

Siempre he pensado que las aplicaciones más elegantes son las desarrolladas en su totalidad por una sola persona (o un puñado de ellas como máximo). En cuanto se sobrepasa el umbral de 5 el código pierde uniformidad y la calidad se vuelve desigual. Estoy hablando de desarrolladores geniales, naturalmente.

Basta mirarse los fuentes de Gnome o de Debian para comprobar el procentaje brutal de ellos que sin duda fueron escritos directamente por Miguel (y conste que el de Ximian es uno de los equipos mejor cohesionados que he visto últimamente).

Personalmente he llegado a la conclusión de que el modelo de desarrollo basado comunidad sólo funciona si estás (como creador) dispuesto a peder el control sobre la evolución del producto. No quiero decir con esto que el modelo de comunidad sea de repente malo, sino que siendo muy útil para dar soporte y crear anexos a un producto, es prácticamente imposible aplicarlo para extender el núcleo base de un desarrollo de software.

Creo, además que algunos proyectos libres fracasan a mitad de camino porque en su plan de desarrollo confían, ingénuamente en que en algún momento del tiempo sea posible repartir el trabajo contemplado en el roadmap y volcar algo de su peso sobre la comunidad, lo cual rara vez sucede. Los contribuidores desarrollan exclusivamente cosas para si mismos y sólo cuando no pueden explotarlas comercialmente las liberan. Adicionalmente, estas contribuciones normalmente no están diseñadas para su redistribución como el software original haciendo parecer el resultado una especie de Frankenstein a menos que se apliquen de forma muy temprana unas normas estrictas para el desarrollo y control de calidad de las extensiones.

Artículo relacionado: Uno currando y diez mirando

La pasada semana se firmaba un acuerdo entre Hispalinux y Telefonica I+D por el cual esta última ofrecería servicios de housing para el proyecto Software Libre, a cambio de un pequeño acuerdo de publicidad.

El acuerdo ha suscitado algunas críticas entre algunos miembros de la comunidad al ver en ella el pacto con el mismo diablo.

Desde diferentes foros hemos hecho muchas veces hincapié en que el software libre y la construcción de comunidades, han dejado de ser el reducto de freakies informáticos. Que éste ha trascendido al resto de la sociedad y que este tipo de acuerdos no hacen más que ayudar a construir los objetivos de Hispalinux que no es otra cosa que la promoción y difusión del software libre. Las comunidades en torno al software libre

Telefonica I+D en febrero del año pasado hacia publicas las líneas estratégicas de los próximos años entre las que se encontraban la implantación y desarrollo de software libre en toda la organización. Escribimos un artículo del porqué este tipo de acciones se antojan como las mejores para expandir constantemente las posibilidades reales del software libre como modelo de desarrollo óptimo. Esperamos que este tipo de acuerdos sigan produciéndose. Será la mejor estrategia ante Microsoft.

Nuestro amigo Antonio J. Chinchetru, antiguo jefe de sección del periódico online Libertad Digital y hoy responsable de comunicación en otra empresa, ha escrito un excelente artículo sobre el porqué él usa navegadores alternativos a Internet Explorer.

Desde que abandoné el navegador de Microsoft tengo una relación con la Red mucho más positiva. Mis nervios han mejorado, puesto que ya no suelo desesperarme con unas descargas de páginas excesivamente lentas, la constante aparición de pop-ups y la instalación no deseada de todo tipo de software basura, desde dialers –molestos pero no peligrosos gracias a que me conecto por ADSL– hasta programas espías.