Tenemos que movilizarnos más. La presión de la industria propietaria en Bruselas y la falta de criterio de algunos organos de la Unión Européa están haciendo el camino muy fácil a las patentes de software. Para el día 2 de junio hay prevista una manifestación "digital".

Hay varias opciones para que se den cuenta que nos somos unos pocos "jedais" sin representación real:

1) manifestarte con tu web
2) manifestarte con tu foto
3) manifestarte con tu empresa
4) todas ;-)
Elige tu opción contra las patentes en:

En IBM developerWorks puede encontrarse un denso manual sobre cómo configurar SUSE Linux Virtual I/O Server.
El contenido es duro y espeso, pero una delicia para los techies linuxeros más profundos.

Y, bueno, ¿qué importancia tiene todo esto?
Resulta que la virtualización de almacenamiento es una tecnología clave para servicios como GMail o PhotoMail.

Actualmente, el mercado de Network attached storage se halla dominado por IBM, EMC e Hitachi. Aunque recientemente también Sun compró su propia tecnología NAS y existe, en general, mucha ebullición alrededor de estas soluciones.

La virtualización es el impulsor del crecimiento de la industria de almacenamiento en los próximos años. De ahí la importancia de que existan soluciones SUSE para OpenPower que cubran este nicho de mercado con una oferta basada en software libre.

Vía eWeek puede leerse la noticia de que Red Hat liberará como GPL Netscape Directory que compró en 2004 por $20M.

Hasta la fecha, sólo Microsoft ha intentado (sin éxito) poner en marcha la infraestructura necesaria para una gestión de identidad global en la red (ver el visionario artículo de Miguel sobre Hailstorm de 2001).

La liberación supone un envite potencial a la gestión de identidad de Novell, uno de los productos estrella de la compañía.

También es un paso para evitar la hegemonía en autentificación que Microsoft pretende alcanzar con Longhorn tras el abandono oficial de Passport.

La historia de Netscape Security Solutions es ya larga. La gama de soluciones fue comprada indirectamente por America Online en el 99 cuando AOL compró Netscape Communications.
Luego hubo una joint venture con Sun hasta el 2002 de la cual salió iPlanet, posteriormente reconvertido a SunONE tras la fusión con el código de Innosoft que Sun compró en 2001.

En cualquier caso aún hay un importante hueco por cubrir en este nicho. OpenLDAP es una pesadilla de entender y de instalar. Se requieren herramientas más fáciles y Netscape, sin ser un producto milagroso, está bien pensado, simplifica un poco la vida del administrador de sistemas y es escalable.

Leer más sobre Red Hat y Netscape Directory en Slashdot.

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

He de confesar que llevo varios años trabajando de mercenario. Ahora que está de moda Star Wars III si me adjudicasen un personaje del guión probablemente me tocaría (contra mi voluntad) Boba Fett, ese siniestro cazarrecompensas que, como su padre Jango, vive de perseguir culpables o inocentes por cuenta del patrón que mejor pague.
Sólo que en informática el argumento es ligeramente diferente, y Fett no tiene el honor de morir en combate con un héroe rebelde sino que, tras un útil servicio, es discretamente ejecutado por traición al Imperio.

Quien lleva suficiente tiempo en trabajando como programador sabe que meritocracia es [normalmente] una quimera que raramente porque en la vida real suele ser substituida por una cortina de pretendida infalibilidad.

No sé cuantas veces he llegado a un cliente y he escuchado aquello de "aquí se hace todo por escrito". Lugares donde lo más importante no son la eficiencias que se generen como fruto del trabajo, sino ser capaz de mantenerse en el puesto sin resultar jamás implicado en ningún embrollo.

Es algo similar a la política: uno puede pasar por el gobierno como de puntillas, casi sin hacer nada en 4 años, y a la postre, resultar re-elegido con holgura. Pero si te salpica un hecho fortuito, como el hundimiento de un petrolero, el accidente de un avión, la corrupción de un banquero o los chanchullos de tu hermano, entonces estás irremediablemente quemado para siempre.

Algunos de los escenarios más comunes de las trampas laborales son los siguientes:

1) Tu jefe, el cliente o un compañero, te piden que te embarques en un proyecto kamikaze para alcanzar un objetivo de negocio supuestamente crítico. Recibes la promesas explícita de que tendrás apoyo y cobertura de las altas esferas si algo sale mal, pero, cuando el proyecto fracasa, eres elegido como cabeza de turco; todos los gerentes intermedios se alejan de ti como de la peste y acabas teniendo que actualizar tu C.V. por procedimiento de urgencia.

2) Te piden por teléfono o de palabra que hagas una pequeña modificación en un programa. Cuando se produce un desagradable efecto secundario de dicho cambio te cae encima una corte marcial por negligencia.

3) Te obligan a aceptar un plazo imposible. Cuando no lo cumples, o la calidad de los entregables es mala, se cuestiona tu capacidad directiva. Si intentas alegar que el plazo era demencialmente corto, recibes la respuesta de que eso ¡deberías haberlo dicho en su momento!

4) Los recursos que tenías comprometidos en un proyecto desaparecen o nunca llegan. De repente alguien te "roba" el servidor de pruebas o se cancela la contración prevista de personal.

5) El usuario añade en la especificación del proyecto toneladas de requisitos imprecisos, inútiles y sin ningún orden de prioridades. Cuando entregas el proyecto eres fuertemente criticado porque no hace ni la mitad de las cosas qu debería hacer.

6) El propietario del proyecto se empeña en forzar la introducción de cambios críticos de un día para otro. Cuando como resultado de la inestabilidad provocada por las constantes modificaciones, el producto falla a diario, se te hace responsable de la inaceptable tasa de errores del programa.

Dejando a un lado a Dilbert, el libro más brutalmente realista que he leído sobre estos tópicos es Death March de Edward Yourdon. Me lo regalaron los empleados de KnowGate en el 2002 y contiene algunos capítulos magistrales con títulos como negotiation games.

La tesis principal de este libro de Yourdon es que es imposible convencer a un cliente empecinado sobre la infactibilidad de un proyecto al inicio del mismo. En lugar de eso hay que establecer muchos pequeños hitos de proyecto, cuantos más mejor, y reunir constantemente pruebas documentales de que no se están alcanzando.
En un proyecto de 6 meses esto se traduciría en poner el primer hito al cabo de 7 días. Es muy difícil producir ningún entregable en la primera semana de un proyecto, de modo que si la primera entrega se retrasa 3 días y se extrapola tal desviación para el proyecto completo, dentro de las primeras dos semanas ya tendremos un argumento para defender que el proyecto tardará probablemente 9 meses y no 6.

Existen decenas de estos trucos de equilibrista que los profesionales curtidos emplean en la venta y posterior ejecución de proyectos.
No obstante, iría siendo hora de que se reconozca el valor de quienes toman iniciativas, frente a quienes simplemente visten el traje gris y se cubren las espaldas o si no, como le sucede al Coronel Terry Childers en Las Reglas del Compromiso, el sistema seguirá perdiendo a las personas más valiosas por motivos puramente políticos.

Via IT Manager's Journal puede leerse un artículo de Andy Singleton comentando el declive del negocio de licencias de software propietario.

El autor ejemplifica con Siebel el tipo de software caro y complicado que tiene a los clientes astiados de pagar y pagar por programas que no alcanzan las expectativas que generan de calidad y funcionalidad.

La raiz del problema, en mi opinión, estriba en que muchos fabricantes creen que venden producto pero en realidad venden servicios sin saberlo.
La empresa arranca con un cliente estrella, por ejemplo Schwab en el caso de Siebel hallá por el año 1995.
Luego van llegando más y más clientes importantes, y cada uno de ellos exige que al producto base se le añada alguna funcionalidad crítica para su negocio pero de escaso o nulo interés para la mayoría de los otros clientes.
Para solucionar el incremento de complejidad el programa se hace "parametrizable" (todos los ERPs tienen miles de parámetros).
Conforme la complejidad sigue aumentando la parametrización alcanza niveles tales como poder retocar cualquier cosa de cualquier pantalla del producto redefinir los flujos de trabajo o hasta cambiar el modelo de datos por completo.
El resultado neto es un programa parametrizado que no se parece en nada al producto original que venía en la caja.
Para colmo de males a menudo se considera que no es imprescindible que los implantadores sean recursos de igual calidad que los programadores; a fin de cuentas sólo tienen que "parametrizar".
No importa el esfuerzo de abstracción que haya hecho el equipo de I+D porque la complejidad intrínseca de un problema sigue existiendo aunque se oculte bajo varias capas objetos.

Un ejemplo de esta situación ocurrió en España con las versiones antiguas de Meta4. Cuando salió la versión 3.0 en el 99 era tan compleja que a los clientes casi les costaba lo mismo actualizarse desde la 2.5 que tirar el proyecto entero y empezar de nuevo. En consecuencia, la empresa hizo desde entonces un esfuerzo de simplificación dando como resultado un producto técnicamente más elegante.

Siebel está en el ojo del huracán porque los nichos horizontales son las más vulnerables al envite del Software Libre. Se puede liberar una tecnología, pero no se puede liberar el conocimiento tácito de las personas, porque la propiedad intelectual de la tecnología pertenece a una entidad jurídica pero el conocimiento se halla distribuido entre los individuos cada uno con su porción particular de oro gris en la cabeza (es interesante leer a Ridderstråle sobre este tema).

Dudo que veamos a corto plazo alternativas libres en sectores verticales como la nómina de Meta4, la automoción de Kerridge o el e-Travel Planitgo, ni siquiera en contabilidad. Porque todos estas soluciones requieren de una fuerte componente de conocimiento sectorial que no se puede liberar en forma de licencia GPL.

Discrepo de A. Singleton en su teoría de que SugarCRM o aplicaciones similares suponen un peligro estratégico para fabricantes como Siebel o Salesforce. Esto es porque la plataforma LAMP carece de soporte en entornos corporativo. PHP es terriblemente popular en PYMEs, pero en grandes cuentas nadie lo apoya: ni Sun o IBM, interesados en Java; ni Microsoft o Novell interesados en C#. Y, si algo se puede dar por cierto, es que las grandes cuentas no pueden adoptar ningún tipo de software que carezca de garantía por parte de algún fabricante líder.

Otro factor social, es que las organizaciones necesitan de relacionarse con otras organizaciones isomórficas para determinadas tareas. Aunque existe una miriada de pequeño proveedores que viven alrededor de los mastodontes de energía, construcción y telecomunicaciones; cuando llega la hora de alcanzar ciertos acuerdos estratégicos la política exige que se firmen con socios cuya estructura y funcionamiento sea similar.
Por ello, es beneficioso que el software que desarrollan fundaciones o grupos reducidos de individuos esté patrocinado por gigantes como IBM, Sun o Novell.

Por último, muchos programas LAMP no están diseñados de forma que puedan escalar e interoperar fácilmente con el ecosistema de aplicaciones de una empresa.

Estos argumentos no significan para nada que las puertas del Software Libre estén cerradas en las grandes empresas, antes al contrario, son los clientes de mayor tamaño quienes más ventajas pueden obtener del software libre.
Un buen ejemplo de ello es BSD. Uno puede ir a cualquier tienda y obtener un CRM de gama baja por un puñado de dólares. Los precios de este tipo de software propietario son tan bajos que resultan asequibles hasta a las MicroPYMEs. Pero si eres el consorcio de la Estación Espacial Internacional, entonces deberas necesitas un proyecto libre como NetBSD que puedas modificar para controlar los dispositivos dedicados.
Un ejemplo cercano de esto lo tenemos en el Proyecto Morfeo de Telefónica I+D. Hace unos meses hablaba con Juan josé Hierro y me comentaba que habían decidido liberar su ORG CORBA entre otras cosas porque ningún producto en el mercado satisfacía los elevados requisitos de TID.

Existen actualmente tecnologías libres que pueden reemplazar prácticamente a cualquier tecnología propietaria. Sólo es una situación análoga a las energía renovables frente al crudo, un día de la noche a la mañana nos levantaremos y el motor de explosión habrá desaparecido con la misma naturalidad que desaparecieron las carrozas de caballos o los discos de vinilo.

En el MIT Sloan Management Review puede leerse nuevo artículo de Nicholas G. Carr, autor del archiconocido artículo Why IT doesn't matter anymore publicado en el Harvard Business Review en mayo de 2003.

Bajo el título The end of corporate computing, Carr afirma que la infraestructura informática dejará de ser un activo en las empresas para convertirse en un servicio.
Los pilares del cambio son, según él, la virtualización, el grid computing y los web services.

Es posible que estas nuevas tecnologías provoquen una transformación en la explotación de la informática. A fin de cuentas el concepto mismo de convertir los activos fijos es gastos variables es fiscalmente beneficioso para las empresas y por consiguiente ya hay un motivo para hacerlo aunque tecnológicamente no aporte nada.

Lo que no creo que suceda es el cambio abrupto que pronostica Carr. Estas tecnologías ya están disponibles en mayor o menor grado en el mercado. De hecho todo el posicionamiento "on demand" de IBM gira en torno al concepto de virtualización, el grid computing está recibiendo subvenciones de la Unión Europea y los Web Services son una tecnología perfectamente madura para uso comercial.
¿Cómo es que los clientes no se han lanzado pues en masa a adoptarlas?

Me parece que la clave puede encontrarse en el libro The Slow Pace of Fast Change de Bhaskar Chakravorti. Una nueva tecnología puede permanecer dormida durante décadas hasta que gracias a algún catalizador su uso se dispara exponencialmente.

El obstáculo para los ejes virtualización+grid+web services es que existen problemas mucho más perentorios a los que la mayoría de los informáticos deben enfrentarse antes de la virtualización y la computación distribuida. Es un poco como la Pirámide de Maslow de necesidades sociales: no se alcanza una necesidad hasta que no se han satisfecho todas las de los niveles inferiores.
Pero, por el efecto avalancha de adopción tecnológica (un cliente no adopta un producto hasta que no piensa que los demás lo están adoptando también) es difícil que se produzca a corto plazo una reacción en cadena que dispare la contratación de virtualización y grid.
Hablo, por supuesto, de las necesidades de un informático típico para quien el coste de hardware es tan barato que la infraestrutura física es el menor de sus problemas. Esto puede nos ser el caso de sistemas científicos computacionalmente muy intensivos.

Me quedo con otros tres grandes temas del millón para el progreso de la informática: Interoperabilidad, Productividad y Seguridad.

Parece que falta ya muy poco para que salga oficialmente Sarge (Debian 3.1).
Steve Langasek anunció el pasado 3 de mayo que Sarge está congelado, lo cual significa que la versión final podría estar disponible a mediados de julio.
Sarge reemplazará al Woody (Debian 3.0) la versión actual que fue congelada el 1 de julio de 2001 y finalmente liberada el 19 de julio de 2002.

El ciclo de versiones de Debian ha sido siempre un tópico controvertido. En las elecciones de 2005 Jonathan Walther proponía usar un ciclo de desarrollo de 6 meses como el de OpenBSD, GNOME y Ubuntu; con 18 meses de soporte para cada versión. Si bien este ciclo más corto beneficiaría a los usuarios, sería, por otra parte, mucho más costoso para los administradores de sistemas, como se ha demostrado con Fedora Core 1.

En cualquier caso, tras la elección de Branden Robinson como líder del proyecto el foco parece que estará en otros temas, más políticos y organizativos antes que en la aceleración de las nuevas versiones.

La clave por la que Debian puede mantener un ciclo lento es que, a fin de cuentas, hace mucho que el código [inestable] de Sarge está disponible y han ido apareciendo parches para Woody (la última el 16 de abril de 2005).

En Linux Journal puede leerse una entrevista con Jon Bosak, uno de los desarrolladores de Universal Business Language (UBL).

UBL es un estándar XML para la definición de documentos comunes de negocio: pedidos, facturas, etc. desarrollado por OASIS (los mismos chicos que estandarizaron OpenDocument format para archivos office).

Mis investigaciones sobre UBL comenzaron con una consulta a un viejo amigo que trabaja en PortIC. Necesitábamos manejar una cantidad bastante considerable de facturas para un proyecto y, antes de lanzarnos a definir un formato de almacenamiento e intercambio propietario pensamos que sería mejor adoptar alguno ya existente. En PortIC gestionan el tránsito de mercaderías en el Puerto de Barcelona, de modo que para ellos es habitual el manejo electrónico de documentos comerciales.
Mi colega me remitió al estándar UN/EDIFACT, referencia del ¿obsoleto? estándar EDI, pero aquello no era el formato XML que nosotros andábamos buscando.
Aunque nunca había investigado previamente este área de conocimiento, me sorprendió sobremanera que hasta la aparición de UBL 1.0 no existiese un estándar XML de comercio B2B.

¿Qué tiene que ver todo esto con el Software Libre? Bien, UBL supone una gran oportunidad tecnológica y de negocio para los desarrolladores de aplicaciones, y, especialmente, para los desarrolladores de aplicaciones libres. A diferencia de otras especificaciones de OASIS como BPEL, que modelizan procesos genéricos de negocio, UBL es muy concreto en cuanto a la definición de unos cuantos documentos claves de negocio.

Gracias a la solidez del consorcio OASIS, es seguro que los grandes fabricantes como Oracle, BEA, SAP, etc. no tardarán en empezar a implementar APIs propietarios sobre UBL. Como OASIS sólo facilita la estructura de los documentos XML, pero no la aplicaciones de referencia, es preciso que alquien desarrolle nuevo software capaz de hablar UBL.

Muchos estándares de este tipo han pasado casi desapercibidos en la comunidad, pero creo que este es diferente porque está orientado a resolver una necesidad común: el traspaso de pedidos y facturas entre sistemas heterogéneos.

Algunos datos de esta migración son muy interesantes e incitarán a más organizaciones, todavía indecisas, a migrar a linux. Hay previsto un informe técnico para noviembre.

El enlace del informe esta en:

Informe Migración Novell

Via CNET puede leerse la historia de los desacuerdos surgidos entre KDE y Apple durante el desarrollo de KHTML para Safari.
Vale la pena leer la carta del blog de Zack Rusin, que, en mi opinión, es lo último que hay que hacer cuando se sufre un conflicto entre grupos: se trata de una misiva al ataque donde la invitación a hablar por teléfono parece más bien un desafío de salir a pegarse a la calle. Rusin tiene razón en muchos puntos, pero quizá él y alguno de sus chicos necesitan un poquito más de habilidad emocional para lidiar con el asunto.

En el blog de Jorge Cortell pueden leerse los avatares de su abortada conferencia sobre P2P.

Según su versión, Cortell fue invitado a dimitir de su puesto como profesor extrauniversitario en la UPV tras enviar un burofax a la policía en el que les advertía que pretendía descargar música de internet durante una conferencia que fue finalmente vetada por el rectorado bajo supuesta presión de la SGAE.

Me ha resultado muy curioso que cuando recientemente tuve el privilegio de visitar el Massachusetts Institute of Technology, habían expulsado a un alumno por conducta desordenada en la vía pública. Los decanos del M.I.T. consideraron que para merecer un título académico no es suficiente con aprobar los exámenes, sino que, además, uno debe exhibir una conducta personal cívica y ordenada.
Por aquel entonces pensé cuan diferente era el sistema español donde (aparentemente) consideramos desvinculadas las opiniones personales de alumnos y profesores de su aptitud académica.
Pero creo que empezaré a cambiar de opinión. Personajes como Stallman o Chomsky que subsisten a pesar de todo en EE.UU. aquí, por lo que cuentan, no tendrían cabida.

Quizá sería bueno dialogar un poco más. La verdad es que enviar un comunicado anunciando la intención de cometer un presunto delito suena a Minority Report, y bastaría de pretexto para que a uno le expulsasen de cualquier organización de personas honorables. Pero lo que tampoco se puede hacer es prejuzgar los hechos antes de que sucedan porque ello es la antesala de la censura.