Ian Skerrett publica en su blog los resultados de una encuesta con desarrolladores de Eclipse de la cual se deducen (entre otras) la siguientes tendencias.

1. Los desarrolladores están pasando su desktop a Linux.
2. JQuery lleva la delantera en toolkits RIA con un 27% de cuota.
3. Se está migrando de CVS a DCVS.
4. No hay una metodología dominante, la que más, Scrum, tiene un 15% de cuota.
5. Han disminuido las contribuciones de software a La Comunidad.

Sorprendentes hallazgos sociológicos los mostrados en este video adaptado de la charla de Dan Pink en la RSA.

• Para tareas mecánicas el que obtiene mejor recompensa económica produce mejores resultados, pero en tareas que requieren inteligencia sucede exactamente al contrario: a mayor paga peores resultados.

• Lo que motiva a la gente en las tareas de alto nivel es: a) la automonía para hacer cosas, b) la sensación de estar adquiriendo maestría en la tarea, y c) el sentido de que la tarea sirve a un gran propósito.

Traduzco a continuación una parte de un comentario de Mark Shuttleworth sobre el proceso de desarrollo de Ubuntu.

Se supone que somos una Comunidad. Todos usamos Ubuntu y contribuimos a él, y merecemos algún respeto con respecto a las decisiones que se toman. Todos hacemos Ubuntu juntos ¿o es eso una gran mentira?

Todos hacemos Ubuntu, pero no todos hacemos todas las partes del mismo. En otrs palabras, delegamos. Tenemos un equipo para el kernel, y ellos toman las decisiones que afectan al kernel. No se permite tomar decisiones sobre el kernel si no perteneces al equipo del kernel. Puedes reportar bugs, y hacer comentarios, pero no puedes influenciar en las decisiones. Tenemos un equipo de seguridad, quienes toman las decisiones acerca de la seguridad, pero no sabrás mucho acerca de ellos a menos que estés en dicho equipo. Tenemos procesos para ayudar a asegurarnos de que estamos haciendo un buen trabajo al delegar, pero ser una comunidad abierta no es lo mismo que decir que todo el mundo tiene voz y voto en todo.

Esta es la diferencia entre Ubuntu y otras distros basadas en comunidad. Puede que sea algo menos democrático, pero es más meritocrático y, lo más importante: a) deberíamos tener a las personas más capacitadas para tomar cada decisión particular, y b) vale la pena invertir tu tiempo en llegar a ser la persona reconocidamente más capacitada para tomar una decisión."

Según él mismo cuenta en un lacónico post en su blog, el "padre de Java" abandona Sun (ahora Oracle) por motivos que parecen más que obvios leyendo alguno de sus otros posts.

Nicholas Carr publica en su blog una breve tipología de muchedumbres en la cual distingue seis clases:

Muchedumbre de producción social: La típica Comunidad Open Source como Wikipedia o Debian.

Muchedumbre para obtener medias: Los típicos grupos usados en las encuestas de los períódicos.

Muchedumbre de mineria de datos: Cuando se descubren patrones de comportamiento de un grupo sin la participación activa y explícita de los miembros en el proceso de recopilar e interpretar la información. Como el sistema de recomendaciones de Amazon.

Muchedumbre en red: Como Facebook o Twitter.

Muchedumbre transaccional: Como la de eBay o Match.com

Muchedumbre evento: La que se organiza alrededor de un evento concreto.

Red Hat ha publicado bajo licencia Creative Commons Attribution–Share Alike 3 la versión preliminar del libro The Open Source Way acerca de las mejores prácticas para crear y mantener un Comunidad Open Source. Un detalle destacable es que se trata de un libro sobre comunidades escrito de forma colaborativa por una comunidad.

Muy inspirada la presentación de Josh Berkus en Java One titulada Ten ways to destroy your Community (PDF). Los diez puntos en los que se resume son:

1. Herramientas difíciles


2. Fomentar a personas venenosas


3. No documentar nada


4. Hacer reuniones a puerta cerrada


5. Montones de burocracia legal


6. Deficiente vinculación


7. Ofuscación con la gobernanza


8. Enredar con las licencias


9. Excluir a contribuidores externos


10. Permanecer en silencio

Leo con asombro en El Periódico de Catalunya que Barajas tuvo que cerrar una pista por ausencia de un controlador el pasado lunes. Es de traca. Comprensiblemente con un sueldo medio anual de 300.000€ y un coste por hora de 184€, no es como para tener controladores ociosos por si acaso alguno causa baja forzosa porque se haya roto la muñeca. Sobre todo porque los elevados gastos en controladores aéreos, hasta el 80% de los gastos totales según AENA, encarecen las tasas aeroportuarias de un aeropuerto que pierde 300 millones al año, mal asunto cuando Barajas aspira a convertirse en hub de vuelos europeos transoceánicos.

Es un hecho bien conocido que prácticamente todos los negocios que se montan en el mundo desarrollado tienen como una de sus principales prioridades operativas la reducción del personal necesario, incluso aquella mano de obra que es imprescindible se intenta que no esté contratada en plantilla sino en la medida de lo posible subcontratada por obra o servicio a otra empresa.

Lo cierto es que debido a los elevados salarios y cargas sociales en Europa, en muchos trabajos la productividad del empleado no alcanza el coste de empresa por hora trabajada a menos que el producto final se venda a precios exhorbitántemente caros.

El colectivo de controladores es especial por muchos motivos, pero, en general, si no se reforma el mercado de trabajo éste simplemente desaparecerá tal y como lo conocemos. ¿Exagero? No, no lo creo para nada. Ya pasó algo parecido en 1994. Como no se llegó a un acuerdo de reformas en la crisis del 92, se legalizaron las Empresas de Trabajo temporal (ETT) de las cuales ahora hay más de 400 en España como una forma de esquivar las modalidades de contrato vigentes. Es decir, "si no querías caldo, pues toma dos tazas".

Lo que sucederá ahora es que a medida que se vayan agotando las prestaciones de desempleo las personas se verán forzadas por los contratistas a crear empresas unipersonales o hacerse autónomos, y empezar a trabajar con contratos mercantiles en vez de laborales. Es decir, será el fin del contrato de trabajo. Esta es la peor situación imaginable para un trabajador: se cobra por destajo, a 90 días en vez de a fin de mes, no se pagan las vacaciones, la relación mercantil se puede terminar súbitamente en cualquier momento sin derecho a indemnización y no se cobra prestación por desempleo.

Esto que estoy planteando no me parece ninguna exageración. En un mercado puede dominar la oferta o la demanda. Y cuando hay mucha más oferta que demanda (como sucede actualmente en el mercado de trabajo) es el contratista quien fija los precios y las condiciones del acuerdo.

¿Qué pasará con los controladores? ¿Habrá una negociación colectiva para reducir sus salarios? Probablemente no. Eso parece imposible. Además ya se ha intentado. Lo más probable es que los vayan prejubilando a los 55 años (52 en algunos casos) con el 100% del salario base hasta los 65, no se contrate directamente a ninguno más, y se busquen empresas que presten el servicio de control aéreo bajo un acuerdo de nivel de servicio que especifique que en ningún caso una pista podrá dejar de funcionar por falta de controladores y unas penalizaciones económicas durísimas en el contrato mercantil en caso de que eso ocurra. Probablemente la empresa podrá pagarle 70.000€ anuales al controlador, repercutirle 150.000€ a AENA y aún con tan pingüe beneficio reducir el coste de la masa salarial a la mitad.

Se han realizado grandes inversiones (como la farónica Terminal 4 de Barajas) perdiendo de vista que la construcción de infraestructuras es sólo una fracción del coste total de propiedad del servicio. Y que el auténtico peligro es que por cada nueva infraestructura que se construye hay que dotarla de carísimos operarios que añaden un coste fijo perpétuo a las arcas del Estado.

Post relacionado: La gran vaca lechera empresarial

Una serie de videos internos de Sun que, a mi juicio, muestran con sorna porqué la empresa acabó siendo comprada por Oracle.

Vía: Los Cuentos del Abuelo (Justo Hidalgo)

Muy buena la idea de ADempiere Bug Day como forma de dinamizar La Comunidad.

En muchas ocasiones los usuarios encuentran un bug y se callan. Por raro que parezca ni siquiera se molestan en reportarlo.

Reporta al fabricante todos los bugs que encuentres en un producto Open Source. Los suelen arreglar, y muchas veces antes de lo que uno esperaría que lo hicieran.

Cada vez son más las personas que me comentan que la gestión del e-mail se está convirtiendo en un infierno cuyo último estadío será, probablemente, el correo móvil.

Si bien es cierto que el e-mail a reducido drásticamente los costes de cada transacción de comunicación interpersonal, de un tiempo a esta parte, su uso, y abuso, lo está conduciendo a una situación en la cual cada vez tiene más sentido reemplazarlo por otra cosa.

El e-mail empezó siendo una herramienta de comunicación asíncrona, pero con la emergencia del correo móvil, cada vez más se utilizará como algo síncrono. De hecho en cuanto la mayoría de los teléfonos tengan líneas de datos asociadas, los SMS desaparecerán paulatinamente y la gente enviará e-mails en su lugar.

A pesar de intentar poner en práctica una política de "Inbox Zero" (cero mensajes pendientes al final del día) lo cierto es que mi Bandeja de Entrada contiene actualmente 407 mensajes de los cuales hay 185 pendientes de leer que, probablemente, no llegaré a leer nunca (muchos van de la bandeja de entrada directamente al archivo directamente sin pasar por mis ojos).

Una prueba de la saturación del e-mail es la forma en la que las personas están empezando a utilizar los servicios de mensajería interna de Facebook en lugar de enviar correos, mayormente debido a que como el volumen de mensajes recibidos en Facebook es menor, la probabilidad de que el mensaje sea leído y respondido rápidamente por el destinatario aumenta.

Si a lo anterior sumamos la creciente, y al parecer imparable, tendencia del spam a aumentar, se puede intuir que probablemente una de las siguientes killer applications en la red será un substitutivo del e-mail.

¿Qué aspecto podría tener este Correo 3.0?

• Categorización automática de mensajes: personales, laborales, publicitarios, informativos, etc.

• Mejor asignación de prioridades: si el e-mail requiere respuesta o no y en qué plazo de tiempo.

• Capacidad para archivar automáticamente los mensajes según un conjunto de criterios.

• Capacidad para vincular los mensajes a un sistema de gestión de proyectos, tareas e incidencias de manera que deje de usarse de facto el e-mail como sistema de ticketing.

• Reorganización automática de la bandeja de entrada para mostrar primero aquellos mensajes que requieren atención perentoria porque son especialmente críticos o porque su plazo está a punto de vencer.

• Visibilidad externa de la cola de mensajes previos en espera, cuántos mensajes tiene el receptor por delante del propio pendientes de procesar.

• Posibilidad de rechazar todos los mensajes de remitentes no autorizados previamente con envío de una notificación de rechazo al emisor.

Ya he expresado en el pasado mi desagrado por la atmósfera que se respira en el campus de Google. En su post titulado nada menos que La República Popular de Google Bob Cringely apunta que el elemento organizativo clave de Google es el peer review, es decir, que cualquier cosa que haya hecho una persona sea sistemáticamente revisada por otras antes de ser aprobada. Ciertamente, como dice Cringely, una de las mejores formas de limpiar el código es repasarlo meticulosamente entre varias personas, y probablemente la misma metodología se pueda extrapolar exitósamente desde la programación a la gestión de un negocio en general. Bob tambien cuenta que los ex-empleados de Google dicen que no saben muy bien a qué se dedicaban sus jefes, a mi también me dió esa impresión, la de que hay gente en Google que vive en una torre de marfil aislada del mundo y que muchos productos están 100% definidos por ingeniería sin que el departamento de marketing pinte absolutamente nada (como pasaba antaño en Apple y hasta hace muy poco en Sun).

Lo he dicho y me reafirmo: Google se sostiene sólo con dos productos vaca porque el volúmen global de búsquedas en Internet crece a un ritmo del 40% interanual, cuando ese crecimiento se estanque, las acciones se estabilicen, y algún competidor empiece a apretar, Google se tambaleará mucho más rápido de lo que la mayoría de la gente piensa.

Hace un par de años, una mujer bastante vinculada a la blogosfera me confesó que ella jamás saldría con un blogger. "Todos ellos son personas con un ego insoportablemente hiperdesarrollado", me dijo.

En el ámbito literario, cuando Isaac Asimov quiso crear un arquetipo de sociedad cerrada al progreso mandó a los enciclopedistas de la Fundación al remoto mundo de Terminus.

Esto no pasarían de ser opiniones discutibles sobre la personalidad del webactor típico, de no ser por estudios como el de los israelíes Amichai-Hamburger, Lamdan, Madiel y Hayat sobre las características de personalidad de los miembros de Wikipedia del cual se hace eco Peter Aldhous en su artículo Wikipedians grumpy and closed-minded.

Lejos de la idea del contribuidor altruista, el estudio presenta al wikipedista típico como un misántropo, egoista, gruñón y cerrado a nuevas ideas. Incluso contiene regalitos especiales para las mujeres wikipedistas, calificándolas de ser, en general, un grupo de introvertidas que usan la red para expresar aquello que no pueden expresar en el mundo real.

El perfil de personalidad, más o menos encaja con el de otro estudio realizado en HP por Huberman, Romero y Wu titulado Crowdsourcing, Attention and Productivity referenciado por Nicholas Carr en su post the sour wikipedian, en el cual se muestra que la gente sube videos a YouTube no para crear un procomún digital sino simplemente para captar la atención de otros usuarios, y, si no lo consiguen, rápidamente dejan de contribuir.

Totalmente lamentable la impresión de la visita a Google en Mountain View.
El campus (porque realmente parece un campus universitario) carece totalmente de estilo, y a ratos resulta hasta ridículo.
La gente trabaja en tristísimos cubículos dilberdianos dentro de lo que parece una nave industrial reciclada en oficina.
La jornada de negocio se ha centrado en ver las cafeterías y los gimnasios empotrados en las oficinas, que simplemente son una forma de que los empleados estén más horas trabajando.
La empresa es ferozmente privativa y propietaria.
El responsable de desarrollo de negocio va tan sobrado que ni siquiera usa tarjetas de visita ni da su e-mail.
Tras verlo in situ, opino el tinglado se aguanta solamente porque la empresa va como un tiro, y cuando hay pa$ta gan$a todo el mundo es feliz. El día que los ingresos flaqueen y las acciones bajen, se irá todo al carajo de la noche a la mañana.
A mi, personalmente, se me ha caído un mito, en organización empresarial y relaciones públicas.

Posts relacionados: A Visit to Microsoft and Google (Joel Spolsky)
Working at Google - the first six months (Don Dodge)

Hoy estuvimos en la sede de Sun en Menlo Park desayunando con Scott McNealy. Lo más sorprendente del encuentro ha sido constatar hasta qué punto en Sun han llevado la filosofía de abrir el código e invertir en I+D hasta sus últimas consecuencias, tanto, que han acabado comprados por Oracle.

He sido crítico con la estrategia de Sun en el pasado, y lo sigo siendo, la compañía hace demasiadas cosas (no rentables) y de un tiempo a esta parte, los clientes y los partners están confusos y no saben bien cual es el segmento de mercado que Sun pretende liderar.

No obstante, tras hablar con Scott he comprendido que su estrategia no es la de liderar uno o varios nichos de mercado al estilo clásico, sino poner en práctica una manera de hacer las cosas cuyo efecto secundario es la obtención de beneficios.

Del resto de la conversación, parafraseo algunas partes tal como las recuerdo:

Tres millones de descargas de Open Office a la semana, le hacen a Microsoft dejar de ganar 5.000 millones de dólares en cash cada año.

Si Oracle decide no seguir contribuyendo a MySQL, este reaparecerá en otro lugar, fuera del control del Sun.

La mejor forma de promocionar una Comunidad es siendo transparente y dando el máximo de soporte a los desarrolladores.

Si pudiera hacer alguna cosa diferente en mi vida, no hubiera sacado Sun a bolsa, es una complicación excesiva ser una empresa pública.

Una de las historias más sorprendentes, es la de que la filosofía de SunOS fue siempre la de ser un sistema operativo abierto, pero, debido a la presión de la OSF (según Scott las siglas de Opose Sun Forever) Sun se vió obligada a fusionar SunOS con el System V de AT&T para dar lugar a Solaris. Según contaba Scott, dicha fusión efectivamente debilitó a OSF pero el precio a pagar fue que SunOS perdió la posibilidad de ser un sistema operativo abierto hasta que Ray Noorda justo una semana antes de jubilarse firmó un acuerdo por el cual Sun obtenía las licencias necesarias para liberar Solaris a cambio de noventa millones de dólares.

Por último, escalofriante la razón última que esgrimía Scott para adoptar Solaris en vez de Linux es que Sun tiene un pacto de no agresión mutua por diez años con Microsoft que impide que los usuarios de Solaris sean demandados por infracción de propiedad intelectual igual que lo fue Tom Tom.

Fuente: Menéame tiene ToS (J.R. Mora)

Vaya follón se ha liado en menéame con lo de banear al superusuario MMPET de Menéame no acepta críticas, seamos sinceros.

Lo comenta Ramón Ramón diciendo que las Redes Sociales se autoregulan o Javier Castilla afirmando que él ya decía hace tiempo que abría una rebelión en menéame o Juan Vega que califica a menéame como una dictadura “políticamente correcta”, y una máquina de crear opinión “asépticamente progresista”.

También hay análisis interesantes como el de Jose Perea diciendo en Abadía Digital que los usuarios son quienes mandan y el de la bitácora de VortixTM en Barrapunto sobre la caída de meneame.net.

Yo opino que con la discusión algunos han sacado la planta del tiesto. Más que nada porque si no te gusta menéame pues no lo leas. A nadie le obligan a leerlo. Si crees que te margina una élite de ególatras autoproclamados como el sheriff del pueblo. Pues te vas a otro pueblo. Total, eso es lo bueno de Internet, que siempre tienes otro pueblo al que irte.

Lo que me parece instructivo de todo el tomate que se ha liado es sacar conclusiones sobre los efectos que produce el sistema del karma. El comentario de Faryshta en Barrapunto da en la diana:

El sistema de karma lejos de favorecer la meritocracia favorece el elitismo y la actitud de borrego. El sistema de votación de noticias y comentarios es autoritario donde ciertas personas valen más que otras en base a 'méritos' aunque con la forma que meneame.net interpreta 'mérito' es mejor dicho borreguismo.”

Es decir, menéame se basa en un método por el cual los yonkis del karma adquiren rango como lo hace un sargento chusquero que asciende desde soldado raso hasta suboficial a base de reengancharse sin pasar por la academia militar.

Y luego está el problema de las guerras de flames que se montan por tocar temás tabú. Basta escribir algo como la palabra "gitano" o alusiones estilo "aquellas personas determinada étnia" para que se monte inmediatamente un circo colosal en los comentarios y contra-comentarios con dos bandos que no se respetan entre si.

Lo que está claro al menos es que fue una mala idea banear a MMPET y a sus seguidores. Sea lo que fuere que se prentendiese conseguir censurándole, los efectos parecen haber sido justo los contrarios. Para neutralizarlo hubiera sido mejor dejarle hablar y simplemente ignorarle. A los voceras normalmente no se les hace mucho caso. Winston Churchill se pasó mucho tiempo previo a la guerra diciendo que había que eliminar a Hitler, y durante esos años los pacifistas simplemente le tildaron de ser un viejo gruñón belicista y borrachuzo, hasta que fue demasiado tarde.

Tener un producto Long Tail es uno de los factores críticos de los negocios actuales.

El Long Tail es la razón por la cual Google Adwords genera ingresos a raudales mientras que Facebook aún sigue luchando por que entre suficiente publicidad.

Aunque dicen que en Adwords más de la mitad de publicidad entra por los anunciantes de viajes (lógico si se tiene en cuenta de que la mitad de todo el volumen de e-commerce son viajes) en realidad la clave de AdWords es la forma en la que permite anunciar cualquier producto por raro que sea a un público minoritario.

La base de datos de usuarios de Facebook, en teoría, es mejor que la de Google, a fin de cuentas Facebook sabe quién eres, dónde vives, cuántos años tienes, si eres hombre o mujer, y hasta la lista de las causas que admiras. ¿Cual es el problema de Facebook entonces? Pues que su oferta publicitaria compite con los mass-media clásicos, mientras que Google es el realidad una alternativa para productos que no pueden anunciarse en la televisión.

Una historia similar es la que han contado los directivos de Openbravo a sus partners congregados en la conferencia de Barcelona: que la diferencia de Openbravo con SAP o Dynamics será su marketing de cola larga basado en la indispensable colaboración de los partners.

Ciertamente es imposible en la práctica fabricar un ERP global que funcione auténticamente bien en todos los paises. Las diferencias en la fiscalidad y en muchos otros factores externos simplemente son demasiado grandes como para que un único producto, por muy parametrizable que sea, cubra todas las necesidades.

La idea de un ERP base de fuente abierta extensible y modular, está muy bien. En realidad la próxima herramienta dominante en la arena de los ERP será algo parecido a Eclipse, un framework sobre el que desarrollar extensiones para cubrir necesidades concretas de cada cliente. Tendrá algunas características de un diseñador de flujos de proceso de negocio, combinadas con un editor WYSIWYG para crear formularios visualmente y generadores de informes; pero, además, este nuevo ERP incorporará librerías de objetos estándar para representar clientes, productos, pedidos, etc. No se tratará de un kit de hágaselo usted mismo, como los BPM actuales, que sirven para todo y no sirven para nada a menos que trabajes sobre ellos. Sino de un aplicativo que será 100% operativo "tal cual" pero a la vez plenamente extensible.

Estamos, no obstante, aún lejos de esta nueva generación de herramientas de desarrollo para aplicaciones de gestión superpotenciadas, que ofrezcan lo mismo que los verticales de SAP pero bajo licencia Open Source y programables modularmente mediante estándares abiertos.

No sólo la tecnología necesaria ya es bastante complicada por si misma, sino que, además, modelizar un ERP modular es extremadamente complicado y, lo más difícil de todo, organizar una Comunidad que realmente coopere requiere una multitud de ajustes sutiles en las relaciones entre las partes.

Matt Assay ponía a Mozilla como ejemplo de un producto que consiguió hacer frente a Internet Explorer gracias a la extensa cantidad de contribuciones de La Comunidad (más de 6.000 plug-ins). En realidad, yo opino que el éxito de Mozilla no tiene nada que ver con los plug-ins. Me pregunto cuantos de los usuarios de Mozilla lo son porque les gustó algún plug-in que encontraron para el navegador. Mozilla se abrió paso simplemente porque es un navegador mejor que Internet Explorer y los usuarios, tras probarlo, repiten y recomiendan su uso. Además, Mozilla no tiene un modelo de negocio basado en La Comunidad, sino que el grueso de sus ingresos provienen de lo que pagan los buscadores como Google por que Mozilla potencie su uso.

Yo estoy 100% convencido de que el futuro es un ERP modular de cola larga. Sobre lo que tengo mis dudas es acerca de si una Comunidad puede crear un ecosistema de componentes que realmente sean monetizables tanto por el fabricante del producto base como por los partners. Desde luego sería algo absolutamente pionero, puesto que las comunidades actuales, bien están férreamente subvencionadas y controladas por su sponsor principal, bien resultan imposibles de gobernar de una forma en la que se pueda sacar dinero de ellas.

Muy agudo el post de Borja sobre la Resistencia Viscosa.

Interesante el post de Emilio Márquez comentando la huelga en Tuenti por el desacuerdo de al menos 100.000 usuarios con la cláusula que cede los derechos en exclusiva a la web.

4. PROPIEDAD INTELECTUAL E INDUSTRIAL. TUENTI, como autor de la obracolectiva en que consiste el Sitio Web, es el titular de todos losderechos de propiedad industrial e intelectual sobre la misma.
[...]
El Usuario no podrá en ningún caso explotar o servirsecomercialmente, de forma directa o indirecta, total o parcial, ningunode los contenidos (imágenes, textos, diseño, índices, formas, etc.) queconformen el Sitio Web sin la autorización previa y por escrito deTUENTI.
[...]
El Usuario cede en exclusiva a TUENTI y para todo el mundo losderechos de reproducción, distribución y comunicación pública sobre loscontenidos que suministre a través del Sitio Web, así como el demodificación para adaptarlos a las necesidades editoriales de TUENTI, ygarantiza además la legítima titularidad o facultad de disposiciónsobre dichos derechos.”

Aitor Riveiro dice en El Pais que se presagia un fracaso de la huelga porque la mayoría de los comentarios que se han escrito en la página de la huelga van del "no entiendo nada" al "esto es una tontería" o "no haber aceptado las condiciones".

Aitor también dice que la huelga es asimismo contra otra cláusula que permite a Tuenti enviar a tus contactos información sobre eventos, aunque yo personalmente no he encontrado dicha cláusula en los términos de uso de Tuenti en los que figura:

5. Los usuarios registrados pueden invitar a amigos para que se unan alservicio mediante un correo electrónico de invitación a través denuestro sistema de invitación automático.
[...]
Los datos que los Usuarios introduzcan en dichas invitaciones noserán en ningún caso tratados por TUENTI.”

En cualquier caso dos cosas están claras:

1ª) Los usuarios no se preocupan suficientemente de las políticas de privacidad.

2ª) La puesta en práctica de la democracia directa mediante redes dará muchos quebraderos de cabeza a algunos en el futuro. Lo del Tuenti es anecdótico. Pero ya veremos qué pasa cuando se monte el primer motín popular a lo bestia contra alguna decisión política.

El pasado día 26 se celebró en Madrid la asamblea anual de la Comunidad Morfeo.

Morfeo es probablemente la mejor oportunidad que tenemos en España de crear una Comunidad de Software Libre que propicie el crecimiento de un ecosistema local de producción de software.

Es absolutamente pionero que una empresa como Telefónica se ponga a fomentar el desarrollo de una Comunidad. Las empresas de ese calibre no suelen ir por ahí organizando reuniones para ver cómo pueden ayudar a las PyMEs de base tecnológica.

Además, Morfeo ya tiene lazos tendidos con las universidades y puntos de salida hacia Latinoamérica a través de sus oficinas en Brasil y el Cono Sur.

¿Qué más falta? Desde mi punto de vista, principalmente dos cosas :

1ª) Que las empresas de la Comunidad se impliquen más. Durante la ronda final de la Asamblea para la asignación de tareas, costó mucho encontrar voluntarios para algunas áreas. Una Comunidad no puede ser una iniciativa unilateral de una entidad tractora. Es cierto que el Modelo del Bazar de Raymond es en parte un mito (muy pocos productos se desarrollan realmente en Comunidad) pero es factible que la Comunidad sea un monólogo unidireccional desde el promotor hacia el resto de los participantes.

La solución: repartir microtareas entre los miembros. Las microtareas son trabajos que requieren entre 4 y 8 horas que deben ser llevados a cabo en un plazo máximo de 15 días. El problema de las microtareas es que, debido a su fina granularidad, son costosas de gestionar.

2ª) Incorporación de clientes a la Comunidad. En Morfeo hay empresas proveedoras, universidades y entidades públicas como Cenatic. Pero, no hay clientes. Y sin clientes ningún producto de software va a ninguna parte.

P.D. Comentarios por mail a sergiom arroba knowgate punto com

Íñigo de Gracia, ha enviado hoy a la lista de Tibi una referencia a la traducción del artículo Building an innovation nation de André Andonian, Christoph Loos, y Luiz Pires en el sitio What Matters de McKinsey & Co.

El artículo incluye un mapa de los principales clusters, aunque los miden por el número de patentes obtenidas cada año, lo cual lo convierte prácticamente en irrelevante en términos reales para el software.

Posts relacionados:
Las ciudades innovadoras, segun McKinsey. ¿Dónde quedamos? (Justo Hidalgo)
SYSTEM@TIC Paris-Region
Silici Vall

Alfredo publica un post sobre el corralito del Santander y cómo, si los bancos no recuperan su normalidad, empezarán a aparecer métodos alternativos para realizar préstamos.

Como bien explica Alfredo, reemplazar a los bancos es algo muy complejo. Dado que hay que regular estrictamente una serie de factores relacionados con la confianza, la capacidad de pago, el fin de la operación, las grantías y las condiciones. El Peer-To-Peer Lending es difícil, pero no imposible.

En el Reino Unido (pais profundamente afectado por la recesión mundial) la National Endowment for Science, Technology and the Arts (NESTA) organizó el pasado día 21 de enero el evento weB@nk con el objetivo de explorar nuevas posibilidades de funcionamiento para el sistema financiero.

En la presentación se habla de Zopa, "el eBay del dinero"; Midpoint & Transfer, una plataforma para desintermediar a los que envían divisas de un pais a otro; y ROSCA, un sistema de micro-créditos personales similar a las cooperativas de crédito.

Está claro que algo va a cambiar después de lo que ha sucedido. En el mundo financiero existe una imperfección de mercado muy grande: por una parte hay personas e instituciones con bolsas gigantes de liquidez, y por otra personas ávidas de ese dinero para invertirlo. La solución de las subprime en EE.UU. surgió porque de alguna forma había que seguir moviendo el dinero y los bancos sólo sabían hacer bien una cosa: dar hipotecas. Necesitamos nuevos sistemas y mecanismos para destinar el capital a fines que realmente produzcan crecimiento económico y social. Soluciones que conecten la oferta con la demanda de capital de una manera eficiente. E Internet ha demostrado ya sobradamente su capacidad para orquestar ese tipo de procesos.

Artículo relacionado: Wonga Is On Its Way After A $22M Funding (Basheera Khan)

Thomas Lord critica en su blog a Wikipedia como un anti-ejemplo de lo que debería ser el gobierno de un proyecto libre desarrollado en comunidad.

Arguye que es una estructura piramidal, donde una cúpula elitista fija las políticas, y los artículos controvertidos se agrupan en reinos de taifas controlados por un okupa que se dedica a monitorizar en tiempo real cualquier cambio relevante que no sea de su agrado para censurarlo.

La solución que propone es que se permitan crear diferentes versiones del mismo artículo, con diferentes puntos de vista que den cabida a la pluralidad de opiniones.

Artñiculo relacionado: Llaman a combatir la censura en Wikipedia (Marcos Guglielmetti)

Ayer estuve en un evento de difusión de Morfeo Project en Valladolid donde Andrés Leonardo (miembro del board de Morfeo) presentó el proyecto como la nueva Comunidad Hispana de proyectos libres "pata negra".
Telefónica pretende aprovechar su efecto tractor como gran empresa y utilizar el Software Libre como herramienta estratégica para crear un ecosistema de proyectos abiertos interoperables.
45 empresas, 10 universidades, 9 centros tecnológicos, y 9 comunidades autónomas se han adherido hasta la fecha a La Comunidad.
Telefónica tiene sus luces y sus sombras, por sus reinos de taifas burocráticos, sus tejemanejes con la CMT y su tamaño mastodóntico que hacen que a veces maniobre como un trasatlántico. Pero lo mismo que necesitamos PyMEs también necesitamos grandes campeones nacionales. Y si alguna empresa tiene la oportunidad de convertirse en el Google Español, esa es Telefónica.
Yo espero y confío en que, como grupo de empresas, Telefónica haya superado el infortunado caso de Terra, que tanto daño hizo a la credibilidad de las TIC en España. Y que ahora sí sepan cómo orquestar un ecosistema de proyectos innovadores. Al menos, cuando hablas cara a cara con los que llevan el timón e influyen en el proyecto, parece que esta vez sí tienen bastante claro porqué apostar estratégicamente por el Software Libre y cómo organizar La Comunidad. Yo cruzo los dedos y les deseo suerte, porque, por mucho que en España esté bien visto socialmente demonizar a las grandes empresas, necesitamos que haya algunos proyectos suficientemente grandes y relevantes para que el Software Libre Español se posicione como un referente en calidad, funcionalidad e innovación reconocido internacionalmente.

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)
Management 2.0: 20 tesis (Fernando Polo)

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)
CrowdSourcing the DELL Way (Lionel)

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.

Post relacionado: Cómo colaborar con el Software Libre

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.

Vía La Flecha nos encontramos con un enlace a una historia de IInternet News sobre los puntos de vista de diferentes personalidades del software libre norteamericano que comentaron en la Open Source Conference celebrada en Toronto el pasado fin de semana.

El artículo habla sobre cómo el paradigma de desarrollo del software libre ha validado las teorías de Adan Smith.

"La visión del mundo de Adan Smith era que el conjunto de los seres humanos se centran en ellos mismos y que trabajando para sus propios intereses, hacen del mundo un mejor lugar más rápidamente que el más benévolo de los reyes"

Debido a que cada uno de los desarrolladores del mundo trabajan en su propio beneficio, todos y cada uno de ellos son capaces de construir algo imposible para entes centralizadas (el más benévolo de los reyes lo que permite que el conjunto de la comunidad, trabajando autónomamente, consiga su objetivo propio.

Open Source Development Labs ha anunciado que Linus Torvald y el equipo de desarrollo del kernel de LInux han adoptado un nuevo sistema de contribución de código para que cada uno de los desarrolladores puedan tener el crédito correspondiente a la hora de donar codigo. Bajo este nuevo sistema, todos los contribuidores firmarán digitalmente un certificado que permitirá ofrecer el crédito necesario en las contribuciones originales, así como cualquier trabajo derivativo que de las mismas surjan.

Joachim Henkel y Mark Tins han publicado un informe sobre cómo se desarrolla los empotrados bajo Linux: Munich/MIT Survey: The Development of Embedded Linux. El estudio es bastante interesante ya que cubre aspectos que se han estudiado en profundidad para otras comunidades, pero no para el sector de los empotrados, tal y como recoge el excelente resumen que ha realizado Linux Devices sobre el informe.

Tres preguntas son las que buscan los autores responder con este estudio: ¿Por qué contribuyen las empresas al desarrollo de Linux empotrado?; ¿Se guardan las empresas que desarrollan Linux empotrado el código desarrollado o bien lo liberan?; ¿quién decide la política a seguir en las empresas de Linux empotrado? ¿Es una cuestión de política de empresa o es el desarrollador que pica código el que lo libera?

El estudio es revelador de que las empresas que desarrollan código en empotrados comparten su código cuando lo desarrollan,a pesar de que éste en muchas ocasiones es sólo susceptible de ser usado en el hardware en cuestión. El estudio revela como alrededor del 60% del código desarrollado en proyectos de LInux empotrado es revelado al resto de la comunidad. Lógicamente el % de código es mayor cuando éste proviene de voluntarios o de universidades, rondando el 90%, mientras que baja para empresas que desarrollan código profesionalmente: fabricantes de aparatos (42%), fabricantes de componentes (59%) o empresas de desarrollo software (58%)

La tendencia es interesante cuando consideramos, que desde el año 2000, las empresas vienen liberando más código que hacían anteriormente. Ésto parece confirmar como el paradigma continúa su avance en el sector de los empotrados.

En cuanto a las motivaciones del porqué las empresas liberan el código desarrolladas, se hace notar que la mayor razón por la cual las empresas lo liberan es porque la licencia GPL lo requiere. las siguiente razones las hemos de encontrar en razones de reciprocidad otros liberan parches, o de beneficio directo reduce nuestros costes de mantenimiento al convertirse el código en parte de nuestra código fuente, etc.

Acaba de de concederse unos premios en EE.UU relativos al mejor artículo de tecnología escrito durante el año pasado. El ganador es Shared values, make open source work, un artículo escrito sobre el funcionamiento de las comunidades de software libre, concretamente en Linux y de cómo cualquiera puede contribuir en el proceso.

Steven Weber es el autor del nuevo libro The Success of Open Source que trata sobre cuáles son los puntos principales que han hecho el modelo de desarrollo del software libre tan exitoso.

En esta entrevista, el autor repasa algunos de los puntos que su libro cubre. La entrevista no tiene desperdicio ya que se repasan los motivos por los cuales la comunidad crea código, cómo se organiza, y dónde están sus fortalezas y debilidades. La entrevista termina con una interesante reflexión sobre cómo las empresas farmaceúticas podrían adoptar el modelo seguido en las comunidades de software libre.

I think in five years most of us will look at the idea of a proprietary operating system as a quaint old-fashioned notion. There are fewer and fewer things that you can do on an expensive Sun box running Solaris that you can't do on a very cheap Intel box running Linux. It's hard for me to see what in the long-run saves the notion of proprietary operating systems except in some few, small mid-segments of the market other than the installed base. And the installed base deteriorates over time.

Hoy Barrapunto trae un interesante debate sobre el nombre a usar correctamente cuando nos referimos al sistema operativa: GNU/Linux o Linux. Yonderboy, editor de Barrapunto, tiene un excelente comentario sobre cuál es el origen del debate, y del porqué de su inutilidad. Si quieres saber más sobre los entresijos de la comunidad y debates que sólo nos interesan a los freakies, echale un vistazo al comentario que merece la pena.

eWeekv mantiene un artículo donde se analiza el soporte que se ofrece en el área del software libre comparándolo con cómo se realiza éste en software propietario. En este, el autor nos ofrece cuáles son algunas de las ventajas que el soporte libre ofrece sobre el propietario y cómo las empresas lo adoptan.

En Velocidad de Escape el autor ha ha traducido al castellano el artículo del cual nos hacíamos eco la pasada semana sobre las 5 debilidades en los modelos de desarrollo del software libre. Mil Gracias por el enlace!

First Monday, repositorio de artículos, ensayos e informes sobre el mundo en Internet, tiene un informe sobre las cinco debilidades que el software libre tiene en cuanto al modelo de desarrollo. Para el autor, las cinco grandes debilidades sobre el diseño de la interfaz de usuario, la documentación, el desarrollo basado en las features, la programación para uno mismo asi como la "ceguera religiosa".

Slashdot publicaba ayer la noticia cosechando más de 800 comentarios, en caso de que estés interesado en ahondar sobre el tema.

Excelente artículo en Linux Journal sobre cómo los métodos utilizados por parte del software libre pueden mejorar las técnicas de Extreme Programming y viceversa. En este queda claro que lo que no tiene nada de futuro son los actuales ciclos de desarrollo empleados por parte del software propietario:

Most conventional software development methodologies work on a single release schedule. The development life cycle spans years and essentially is a black box from the point-of-view of the customer, who has to step out of the way and await the day the developers transform his requirements into usable software. This approach offers no scope for change, for feedback from the customer on what is being churned out in the development process or for a cut-and-run.

Juantomas nos escribe en su weblog sobre la iniciativa Software-Libre que se ha lanzado como agrupación de los diferentes proyectos de software libre.

Este proyecto de HL es otro paso adelante absolutamente necesario. Ya se que existe sf.net pero la gente de gforce ha dado un paso adelante. Lo más importante de los proyectos de software libre es que se comuniquen y las herramientas cada día sean más eficaces.

Ahora el siguiente paso es obvio aprovechemos este proyecto. Hay cientos de proyectos dispersos muy interesantes. La clave del éxito es sin duda la comunicación, la cooperación y la coordinación. software-libre.org es la herramienta así que os animo a usarla sin límites.

Magnífico reportaje de la revista CIO sobre seis diferentes mitos que normalmente se tienen sobre el software libre con ejemplos de todo el mundo de cómo las diferentes aplicaciones libres están poblando las instituciones y empresas de todo el mundo:

- Lo atractivo es el precio
- Los ahorros no son reales
- No existe soporte
- Es un campo de minas legal
- El Software Libre no está preparado para aplicaciones críticas
- El Software Libre no está preparado para el Escritorio

El portal de la BBC tiene un artículo sobre la "guerra" que se está disputando entre los modelos de negocio que trae el software libre frente a los obsoletos del software propietario. Para el articulista, esta batalla parece ser que será ganada por los partidarios del software libre, no por razones ideológicas, sino por razones de necesidad: La sociedad en red necesitará de interconexiones ricas y programas que sean interoperables, y éstas sólo pueden ser escritas si el código fuente y las interfaces son completamente abiertas

....el que tenga ojos, que lea, y el que tenga cerebro, que discurra

Si hace unos días recogíamos las declaraciones de empresarios y técnicos de la comunidad del software libre sobre la decadencia del modelo empresarial actual que tienen las empresas de software propietario, hoy son los propios directores de las empresas de software propietario los que comentan el porqué la industria tiene que cambiar radicalmente.

Christopher Lochhead, Director de Marketing de Mercury Software, empresa de software propietario de publicación, criticaba duramente a la industria por los modelos de negocio que dan a las empresas de software pocos incentivos para la innovación para asegurar la satisfacción del cliente. Lochhead también comentaba cuál es el problema de la industria:

"En opinión de Lochhead, el problema con la industria del software es que está dominada por unas pocas empresas de software muy poderosas que dictan los términos a sus clientes. Una de esas condiciones impuestas es el modelo de licencias perpetuas"

Buen artículo de Cnet que nos ofrece una perspectiva de la situación actual en los modelos de negocio de las empresas de software propietario en EE.UU

Esto es lo que va a ocurrir y lo que venimos defendiendo vehementemente. La única salida que tienen las empresas de software propietario es abrazar los modelos de software libre. No hay otra alternativa.Según nos cuenta Linux World ésta es también la opinión de diferentes panelistas que se han dado cita en la Conferencia EDGE 2004 que se celebra en EE.UU.

"The Open Source Debate" ha sido el título en las que entre otros Miguel de Icaza ha intervenido y comentado el cómo Novell está abrazando internamente el modelo de desarrollo del software libre. Esto viene a confirmar lo que Telefonica I+D ha entendido: la clave es la estandarización y para ésta sólo hay una posibilidad: el software libre.

Así de simple, así de claro. Ningún tipo de software que no sea libre, podrá estandarizarse sin las consecuencias nefastas que hoy en día traen los propietarios, tanto en términos de interoperabilidad como de independencia.

Wired recoge un artículo donde habla de los peligros que una monocultura tecnológica representa para todo el planeta. Mediante un curioso símil de las especies predominantes endogámicas y la penetración tecnológica de Microsoft de más de un 95% del total de ordenadores instalados en el planeta, explica del peligro que una tecnología presente en casi cada ordenador de los existentes en el planeta.

En biología, las especies con pocas variaciones genéticas -o monoculturas- son las más vulnerables a las epidemias catastróficas. Las especies que compartan un simple fallo mortal pueden ser aniquiladas por un virus que explote ese fallo. La diversidad genética incrementa las posibilidaes de que al menos algunas de las superficies sobreviva a cada ataque

Aunque podemos tener algunas dudas sobre la comparación entre un ser vivo y un ordenador, lo que está claro es que la cultura predominante monoplataforma, tiene un gran peligro sobre la infraestructura básica de cualquier organización. Esperemos que ésto poco a poco vaya llegando a cada uno de los responsables públicos, y al menos nuestros sistemas, no se vean infectados por cualqueir virus.

Fernando Acero, analista de seguridad y conocido impulsor del software libre en todos los ámbitos y uno de los coordinadores del proyecto de e-learning Miguel , acaba de publicar una carta abierta en la que expone sus reflexiones sobre la reciente noticia publicada en la cual el CNI se habría sumado al programa Source Shared de Microsoft.

Extracto de la conferencia del CTO de Nokia en la Emerging Technology Conference 2004 que se celebra en USA:

¿Cómo podemos fabricar aparatos para que puedan ser "hackeados" por parte de los usuarios sin perder la estabilidad y fiabilidad? Este es el mensaje más importante que tengo hoy. Estándares abiertos es el ADN de Nokia. La apertura de estándares conduce a más aparatos, más desarrolladores, mejores productos, mayor innovación y mejor interface. Los estándares y APIs abiertos así como la interoperabilidad son claves para el ecosistema de usuarios que también crean aplicaciones. Queremos construir el puente que una las islas del mundo móvil y el mundo de Internet"

"A buen entendedor, pocas palabras bastan"

Evans Data es una consultora especializada en realizar informes sobre organizaciones IT, acaba de presentar un estudio en el cual informa que existen alrededor de 1.1 millones de desarrolladores de software libre en Norte América.

Según el estudio el número actual refleja los desarrolladores profesionales de software que pasan tiempo trabajando en diferentes arquitecturas, tecnologías, lenguas y herramientas de desarrollo. noticia de Business Wire, éstas son algunas de las conclusiones del estudio:

- Más de 500.000 mil desarrolladores de Norte América está invirtiendo tiempo en el desarrollo bajor architectura de 64 bits.
- Casi un cuarto de millon de desarrolladores está trabajando en proyectos de grid computing.
- Desarrolladores de Clusters se sitúan en torno a medio millón en total y son un 17% del total de la población en Norte América.

Como podemos ver, el número de desarrolladores trabajando en tecnologías libres sigue creciendo exponencialmente ¿Hasta dónde seremos capaces de llegar?

Parece que la conferencia de Telefónica en Málaga va a dar que hablar...y no lo decimos nosotros. Un tal Samuel A. acaba de escribir un artículo que ha salido en portada de Iblnews sobre el cambio en la estrategia de desarrollo de Telefonica I+D. Aunque fuimos nosotros los primeros que informamos ;-) el artículo de Samuel recoge perfectamente lo que se intuye en la nota de prensa....No lo podríamos haber hecho mejor. Habrá que estar atentos a la conferencia del día 19 de Málaga

OPINIÓN.- Crece la expectación entre los profesionales de las tecnologías de la información sobre la Conferencia que Antonio Castillo, Director de Desarrollo de Negocio de Telefoncia I+D pronunciará el próximo día 19 de febrero en la I Conferencia Mundial del Software Libre. Parece anticiparse que Telefónica I+D basará parte de su estrategia de negocio de los próximos tres años (2004-2007) en asumir las bondades del software libre.

Telefonica I+D, filial de Telefonica y una de las empresas líderes en investigación y desarrollo, basará parte de su estrategia de negocio de los próximos tres años en el modelo de desarrollo de Software Libre. Así por lo menos puede desprenderse del título de la Conferencia "Estrategias de Software Libre en Telefónica I+D" que Antonio Castillo,Director de Desarrollo del Negocio, ofrecerá en la I Conferencia Mundial del Software Libre que se realizará en Málaga los días 18, 19 y 20 de febrero.

Telefonica I+D centra sus esfuerzos en el desarrollo de los tradicionales servicios telefónicos y de telefonía pública, así como servicios móviles avanzados que persiguen ofrecer cobertura a todos sus clientes en cualquier ubicación. Parece intuirse que los modelos de desasrrollo de software libre jugarán un papel importante en la estrategia de desarrollo de la empresa española.....el paradigma cambia, y Telefonica I+D es simplemente es otro exponente más de cómo las grandes empresas comienzan a descubrir las bondades del software libre.

The United Nations Conference on Trade and Development acaba de presentar la edición de su Informe E-Commerce and Development Report 2003 , donde se recoge que los procesos envueltos en el software libre produce mejor software que los relacionados con el software propietario. Las razones principales de este informe indican cuatro razones para declarar la superioridad del software libre sobre el software propietario:

* En un ambiente de software libre más desarrolladores encuentran mayores defectos y los arreglan.
* Sin presiones comerciales, los desarrolladores liberan más arreglos y mejoras, de una manera más continuada
* El Software propietario no garantiza la calidad para evitar problemas legales
* La disponibilidad del código fuente permite a los usuarios arreglar, personalizar o mejorar el software basado en su experiencia

Aquí tienes el capítulo 4 del informe donde se detalla el concepto del software libre, algunas de las experiencias en países en vías de desarrollo (Tailandia, China, Malasia, Brasil, etc.), así como cuadros y detalles interesantes del mundo del software propietairo frente al software libre. Como siempre y cuando se trata de análisis rigurosos, no se puede comparar el modelo de desarrollo de uno frente a otro...simplemente no hay color!

La I Conferencia Mundial del Software Libre que se celebrará en Málaga acogerá desarrolladores de todo el mundo que contarán el porqué de las ventajas del software libre sobre el software propietario...¿has reservado tu plaza?

Uno de los aspectos que más intriga a las personas ajenas a la Comunidad del Software libre, son las motivaciones que existen tras los miembros de la comunidad que contribuyen. En nuestro libro explicábamos que las principales motivaciones están referidas al área de habilidades (aprendizaje, compartir conocimiento), Beneficio Directo (resolución de problemas, mejora de oportunidades laborales, soporte técnico), e incluso ideológicas (participar en la comunidad del software libre, creencia de que el software no tiene que ser propietario), desde el punto de vista genérico de los desarrolladores. Pero dos profesores italianos han ido un paso más allá, realizando una encuentra entre 146 emrpesas para encontrar sus motivaciones para la contribución con la comunidad. Los resultados no sorprenden, pero sí llaman la atención.

Andrea Bonaccorsi y Cristina Rossi publicaban el pasado mes de diciembre en First Monday, Altruistic individuals, selfish firms? The structure of motivation in Open Source software (Individuos altruistas, empresas egoístas? La estructura de motivación en el software libre), un excelente informe sobre las motivaciones de las pequeñas empresas que contribuyen con la comunidad del software libre italiana, que nos ofrece pistas para conocer, las razones de estos agentes cada vez más numerosos en la comunidad

Según anunciaba The Inquirer, Microsoft ha extendido el soporte sobre las ediciones de Windows98 y Windows Me durante dos años más. Gracias al empuje del software libre y concretamente de GNU/Linux, Microsoft ha hecho pública su extensión de soporte durante dos años más, siguiendo la nueva política de GNU/Linux. Otro logro más del Software Libre que supone el ahorro de miles de millones de euros de los clientes .... y..., ¿éste era el cáncer?...y que demuestra cómo el paradigma tecnológico ha cambiado para no cambiar...

En una excelente entrevista de Always On Network a Chris Stone (VP de Novell), Migue de Icaza y Nat Friedman (fundadores de Ximian y actuales responsables de Ximian-Novell) , éstos repasan los puntos principales de la comunidad del software libre: Adquisición de Ximian por Novell y cómo ésta está transformando su cultura (Parte I); Sobre como Novell competirá con Sun (Parte II); y sobre la comoditización del sistema operativo y de cómo los servicios de Novell bajo Linux prometen ser una excelente vía de entrada de Linux en las empresas (Parte III)

En una de las preguntas, Nat Friedman explica cómo Novell está cambiando su mentalidad y procesos de trabajo, es decir, la cultura de una empresa para migrar hacia procesos más eficientes que las comunidades de software libre, llevan experimentando durante años:

Una de las cosas que es realmente importante para nosotros [Miguel de Icaza, Nat y el resto de la comunidad de software libre] es que Novell se de cuenta de que la comunidad del software libre es una fábrica social de inidividuos organizados en base a una meritocracia; ésto no es un consorio o estándares. Si eres una empresa que quiere ser creíble y tienes un interés estratégico en el mundo Linux - el mundo del software libre -, tienes que tener individuos claves tejiendo en esa fábrica que es parte de tu empresa. Tienes que tener a los mayores contribuidores quienes son los mantenedores, gente que conduzca la estrategia de la comunidad. Así es como funciona. Y esto no es una decisión de alto nivel de poner dinero en Linux; ésto es sobre tener a gente en el equipo

No se puede decir más claro ni de una forma más precisa. Los compañeros de Hispasec lo dejan bién claro. La industria más representativa del software propietario no da su brazo a tocer y sigue cometiendo los mismos errores históricos. A esto nos referimos cuando con toda determinación afirmarmos que esta industria es una de las más nefastas.

No es normal que se venga denunciando que esta no es la manera más óptima de actuar y pese a todo sigan defendiendola a capa y espada. El año que viene seguiremos viendo como cada vez tenemos más problemas de seguridad y se pierden muchas más horas de trabajo. Eso sí lo beneficios de unas pocas compañias seguirán aumentando. Y por supuesto no cambiarán de política.

Enhorabuena por el trabajo de los chicos de Hispasec, como en otras ocasiones, de 10.

En nuestro capítulo Iniciativas que cambiarán el Mundo, hablamos sobre diferentes iniciativas de colaboración que prometen cambiar las maneras en las cuales las empresas se relacionan. En el blog de Alfredo, hace poco hablábamos de una iniciativa conocida como Innocentive. Pero esta semana nos hemos encontrado con dos iniciativas más que nos llaman poderosamente la atención. Es al fin y al cabo una forma de la meritocracia que trae la red.

Recientemente la Fundación Gnome anunciaba la creación de los GNOME bounties . En aras de mejorar el nivel de integración entre los mayores componentes de Gnome Desktop para lograr mayores experiencias de colaboración entre los usuarios, la Fundación Gnome ofrece "recompensas" sobre cada una de las tareas a realizar, variando entre los variando entre los ?100 y ?2.500 dependiendo de las tareas a realizar.

Por otra parte, vía Slashdot, el multimillonario sudafricano que pagó su viaje al espacio, el sudáfricano , está subvencionando proyectos destinados a la mejora de proyectos de software libre a través de su Fundación. Para el año 2004 Mark Shuttleworth destinará ?100.000 a la mejora de proyectos como Mozilla o Python entre otros.

Por último, vía el Blog de Simsom Garfinkel de Techcnology Review, me encuentro con un link a un artículo de Fast Company de junio de 2002, en el que explica la historia de un emprendedor que, gracias al descubrimiento de Linux y cómo gracias a las formas de colaboración, una mina de Ontario podría ser rentable.

Goldcorp, empresa propietaria de la mina, organizó en el año 2001 el Goldcorp Challenge. El desafío consistía en analizar todos los datos geológicos que se tenían sobre la mina, y en base a éste poder elaborar las áreas que más posibilidades tenían de contener oro. El total de la bolsa de recompensas fue un total de $575.000 con $105.000 para el primer premio que fue otorgado a dos equipos de ingenieros australianos. Según el articulo de Fast Company, la mina Red Lake producía 53.000 onzas con un coste de $360. En el año 2001, justamente después del concurso, la mina producía diez veces más onzas de oro co un coste de $59/onza.

El mundo está cambiando y estas nuevas formas de relación nos ofrecen grandes oportunidades de innovar y avanzar hacia modelos empresariales mucho más eficientes, que al fin y al cabo, es lo que trae los modelos de desarrollo del software libre.

En nuestro capítulo Iniciativas que cambiarán el Mundo, hablamos sobre diferentes iniciativas de colaboración que prometen cambiar las maneras en las cuales las empresas se relacionan. En el blog de Alfredo, hace poco hablábamos de una iniciativa conocida como Innocentive. Pero esta semana nos hemos encontrado con dos iniciativas más que nos llaman poderosamente la atención. Es al fin y al cabo una forma de la meritocracia que trae la red.

Recientemente la Fundación Gnome anunciaba la creación de los GNOME bounties . En aras de mejorar el nivel de integración entre los mayores componentes de Gnome Desktop para lograr mayores experiencias de colaboración entre los usuarios, la Fundación Gnome ofrece "recompensas" sobre cada una de las tareas a realizar, variando entre los variando entre los ?100 y ?2.500 dependiendo de las tareas a realizar.

Por otra parte, vía Slashdot, el multimillonario sudafricano que pagó su viaje al espacio, el sudáfricano , está subvencionando proyectos destinados a la mejora de proyectos de software libre a través de su Fundación. Para el año 2004 Mark Shuttleworth destinará ?100.000 a la mejora de proyectos como Mozilla o Python entre otros.

Por último, vía el Blog de Simsom Garfinkel de Techcnology Review, me encuentro con un link a un artículo de Fast Company de junio de 2002, en el que explica la historia de un emprendedor que, gracias al descubrimiento de Linux y cómo gracias a las formas de colaboración, una mina de Ontario podría ser rentable.

Goldcorp, empresa propietaria de la mina, organizó en el año 2001 el Goldcorp Challenge. El desafío consistía en analizar todos los datos geológicos que se tenían sobre la mina, y en base a éste poder elaborar las áreas que más posibilidades tenían de contener oro. El total de la bolsa de recompensas fue un total de $575.000 con $105.000 para el primer premio que fue otorgado a dos equipos de ingenieros australianos. Según el articulo de Fast Company, la mina Red Lake producía 53.000 onzas con un coste de $360. En el año 2001, justamente después del concurso, la mina producía diez veces más onzas de oro co un coste de $59/onza.

El mundo está cambiando y estas nuevas formas de relación nos ofrecen grandes oportunidades de innovar y avanzar hacia modelos empresariales mucho más eficientes, que al fin y al cabo, es lo que trae los modelos de desarrollo del software libre.

Según nos cuentan en Barrapunto, un grupo de desarrolladores está construyendo lo que pretende ser un futuro sistema de administración y control para cybercafes para lo cual está solicitando ayuda.

javiers nos cuenta: «Junto con un grupo de amigos hemos comenzado, hace ya unos días, a desarrollar un sistema de administración y control de cybercafés llamado CybOrg. Después de buscar durante mucho tiempo algún sistema libre, que corriese en GNU/Linux (con clientes Windows), y de encontrarnos con proyectos difuntos como Gcafé y Zeiberbude, nos lanzamos a desarrollar uno desde cero (por el momento hemos tomado el cliente de este último, ya que ninguno es experto en programación bajo Win32).

Se trata de un sistema con interfaz web, desarrollado en Perl (usando Template Toolkit) y que
utiliza un DBMS (por ahora PostgreSQL, pero debería ser fácil adaptarlo a otro...). Estamos buscando beta-testers y desarrolladores que nos ayuden a llevar este proyecto adelante. Parece una buena idea, ya que todos los sistemas "robustos" que existen en la actualidad son propietarios y requieren del uso de un servidor Windows.»

Miquel Vidal de Sin Dominio ha traducido uno de los famosos ensayos de Eric Raymond sobre Cómo Convertirse en Hacker. Estupendo documento que nos ayuda a entender mejor el qué hay detrás de un verdadero hacker.

Iblnews nos informa sobre cómo se ha detectado el intento de implantar una puerta trasera en el kernel Linux (2.6 test) mediante un análisis rutinario automático del código fuente.