Me he traido de Infonomía una regla del dedo gordo denominada "Ley de Rowen" que dice: "Cuando los márgenes atractivos desaparecen de una determinada fase de la cadena de valor porque el producto/servicio ha sido comoditizado, la oportunidad de conseguir unos beneficos atractivos con un producto/servicio diferenciado y descomotizado es muy probable que haya transitado a otra fase adyancente de la misma cadena de valor".

La idea está inspirada en un artículo de Clayton M. Christensen en el texto HBR Breakthrough Ideas for 2004 del Hardvard Business review.

Esto viene a colación de una nota de prensa de Hispalinux referente a unas recientes declaraciones de Eugenio Beaufrand, VP de Microsoft para Latinoamérica, afirmando que el software libre es perjudicial para el desarrollo económico.
El argumento básico de Beaufrand es que el software libre no puede ofrecer el ecosistema completo de Microsoft y, por consiguiente, los clientes deben invertir más en integración.

Christensen aporta algunos buenos argumentos de porqué es justo al contrario, por ejemplo:

"los productos son más rentables cuando no son aun 'suficientemente buenos' esto es porque para hacerlos funcionar los ingenieros deben utilizar arquitecturas propietarias que diferencian el producto de los otros de forma espontánea"

"cuando los productos maduran las innovaciones por las que pagan los clientes son rapidez en la salida al mercado y capacidad de respuesta a necesidades cambiantes"

"la 'comoditización' y modularización de los productos reduce los beneficios derivados de la diferenciación del conjunto y los traslada a la fabricación de subsistemas para ser ensamblados, debido a que entonces lo que diferencia un producto de otro es la calidad de los componentes"

Bien, aplicando esto al software libre:

¿Quién puede generar más trabajo local, una aplicación cerrada y terminada o una que no es aún 'suficientemente buena'?

¿Qué compañía lleva años sin actualizar sus productos estrella? Ni siquiera Debian, famosa por su parsimonia en el lanzamiento de versiones emula la calma de Microsoft a la hora de innovar en sus productos.

¿Quién puede fabricar subsistemas más optimos? El software cerrado desde luego no, porque no hay forma de optimizar trocitos de Windows. No es casualidad que los clusters de supercomputación (estilo Beowulf) o la emergente tecnología Grid estén basados en Linux.

Desde hace tiempo encuentro refrescante reunirme de vez en cuando con la cúpula de AI², la Asociación de Ingenieros en Informática que trabaja, entre otras cosas, por la regularización del sector informático en aras de una mayor calidad de servicio para los clientes.

Al hilo de las cosas que a veces se hablan en las tertulias de AI², leo en elmundo.es una encuesta de Europa Press en la cual el 73% de los guionistas del cine español dice que no llega a fin de mes.

Creo que existen ciertas similitudes entre el problema de los guionistas y los problemas que se encontrarán los informáticos en el futuro: en un mercado que no está regulado los beneficios se los quedan las grandes producciones y los intermediarios y lo que queda para los trabajadores es la menor parte.

Los zelotes de la libertad extrema han hecho que muchas veces la palabra "regulación" suene a conspiración contra los pobres usuarios, cuando no tiene porqué ser necesariamente así.

Tomemos, por ejemplo, el caso del taxi. Me cuentan los taxistas (al menos los de Madrid) que su problema es que hay demasiadas licencias, que hay taxis para cuando había menos Metro y menos transporte público. Las tarifas del taxis están reguladas e incluso algunos taxistas están en contra de que suban en exceso porque ello (piensan) les haría peder carreras. En este caso la regulación trabaja a favor de los usuarios: todos los taxis deben estar en buen estado, llevar aire acondicionado en verano, admitir perro y cobrar una tarifa justa por el viaje.
Este mismo tipo de regulación sería necesaria en el sector informático para mejorar la calidad de los trabajos realizados.

He de confesar que yo mismo he estado en una época en contra de la creación de colegios profesionales de informática, en la creencia de que ello sólo introduciría imperfecciones en el mercado que elevarían artificialmente los precios como ocurre en otros colectivos, pero me equivoqué.
Los informáticos hemos nacido (como colectivo) en una época en la que las asociaciones gremiales habían pasado de moda. Tal ausencia de sentido gremail, en combinación con nuestra propia arrogancia, nos ha llevado a pensar que éramos irremplazables y que no necesitábamos ninguna norma reguladora para nuestro sector.

Si no cambiamos el chip, fácilmente podemos acabar como los cineastas: con millones de usuarios quejándose [sea verdad o no] de que vivimos de la sopa boba de las subvenciones, con unos pocos productores forrándose a mansalva y nosotros, mientras tanto, buscando de dónde sacar 4 euros para comprar las habichuelas y llegar a fin de mes.

Actualización: Vivir del software ¿libre? (Joserra)

Según una encuesta recientemente realizada por la analista Laura DiDio de Yankee Group, las empresas valoran igualmente Linux y Windows en términos de calidad y rendimiento. Siendo el ROI y el TCO valorados aproximadamente igual para ambos.
Dando la encuesta por buena (la realidad es la realidad), merece la pena señalar que no son los parámetros de calidad y rendimiento los que diferencien al software libre del propietario.
No creo que nadie puede afirmar razonablemente que OpenOffice es intrínsecamente mejor que Microsoft Office desde la perspectiva del usuario final.
Es la diferencia en la licencia y la propuesta de valor general que se hace al cliente lo que marca la diferencia clave entre un tipo de software u otro.
Muchas empresas pagan por programas libres, quizá incluso pagan más de lo que les costaría la misma funcionalidad en software propietario. Pagan por la libertad y por confianza que proporciona tener los fuentes, no por la cantidad de defectos por mil líneas de código.

En el blog de Matthew Thomas puede leerse una exhaustiva y brutal evaluación titulada Mis primeras 48 horas aguantando Ubuntu 5.04.
Aunque el artículo diciendo que Ubuntu es la distro más usable de Linux, lo más sorprendente del caso es que Thomas trabaja para Canonical, la empresa que esponsoriza Ubuntu. O habrá que esperar a que lo pongan en la calle por blogger, o quizá mejor tomar nota de que las relaciones con la prensa son diferentes en el Software Libre.

A través de Infonomía puede conseguirse en PDF bajo Creative Commons el texto íntegro del libro de Jordi Mas i Hernàndez (Ximian/Softcatalà): Software Libre Técnicamente viable, económicamente sostenible y socialmente justo.
Se trata de un texto introductorio e histórico bien redactado y fácil de leer. Muy bueno para quienes deseen iniciarse en los conceptos básicos del software libre.

Via ComputerWorld puede leerse la historia de Carol Silwa sobre la migración de Continental Airlines a Linux 64 bits.
El artículo señala la falta de drivers de 64 bits y el consumo de CPU de Java en procesadores de 450Mhz como los principales escollos.

Es realmente remarcable que una línea aérea como Continental haya tenido el coraje de abandonar un tandem tan sólido como Oracle+Solaris para pasar a Open Source sus sistemas de misión crítica. Ellos mismos señalan que el soporte directo de HP, Red Hat y MySQL fue clave en la decisión. Lo cual lleva a una cuestión de fondo el Software Libre sólo se adopta en las grandes empresas si hay otra gran empresa respaldándolo detrás.

Recuerdo que hace apenas una semana tenía una enconada discusión con mi hermano y brazo derecho corporativo acerca de la conveniencia de abandonar una instalación de Oracle en favor de MySQL 3.2. El problema era que habíamos montado Oracle sobre una versión de Linux no certificada y, aunque la base de datos en si misma funcionaba bien, el SQL*Net se nos moría irremediablemente por agotamiento de conexiones y semáforos del sistema operativo perdidos. A lo largo de los años he oido (y sufrido) muchas historias de terror de Oracle sobre plataformas no certificadas: Irix, Digital, Linux, etc.
En este punto MySQL 3.2 nos aportaba una mayor fiabilidad que la base de datos irrompible (ya retiraron dicha publicidad). El hehco de que MySQL 3.2 sea tan limitado es precisamente lo que lo hace más fiable: cuando más simple el invento mayores las probabilidades de que funcione sin fallos.

Ignoro si los directivos de sistemas de información de Continental sentían la misma preocupación que yo siento a diario cuando Oracle no está perfectamenete instalado y optimizado sobre la plataforma correcta.
Pero quizá, en el fondo, sí vivían todas esas experiencias cotidianas donde se come el disco y los recursos del sistema operativo, se desconecta súbitamente, te encuentras drivers JDBC de dudosa calidad, se para, etc.

Más info: HP Serviceguard for Linux ProLiant cluster

En IT Manager's Journal puede leerse un divertido (aunque desesperanzador) post titulado The 15 most annoying IT-speak clichés, buzzwords ever used. Me quedo, desde luego, con el Top 1: "esto para hoy en la tarde".
Por cierto que quien disfrute de los baños de realidad cotidiana no debería perderse el libro Death March de Edward Yourdon.

W3 Schools acaba de publicar su último estudio de tendencias de uso de navegadores, en el cual, por cuarto mes consecutivo, IE pierde terreno frente a FireFox situándose las cuotas de abril en un 62,2% y un 23,8% respectivamente.

Creo que podemos fijar las causas del continuado dominio de IE en varios motivos:

1º) IE es básicamente un buen navegador. Es suficientemente estable, rápido, admite una programación rica y tiene muchos plug-ins. Su punto más débil es la vulnerabilidad al spyware y los troyanos (por cierto que Microsoft se compró hace poco Giant, la empresa que me suministraba el anti-spyware).

2º) Muchas páginas están optimizadas para IE, y optimizarlas también para FireFox es engorroso. Esto hace que muchos desarrolladores sigan recomendando IE (que es lo que tiene la mayoría de la base instalada) y evitando FireFox por la vagancia o la falta de tiempo de escribir el código compatible con ambos navegadores. Por otro lado, muchos plug-ins no funcionan bien (empezando por el de RealMedia).

3º) Los parámetros de seguridad de IE se pueden administrar de forma remota.
Esto es muy útil en empresas con muchos PCs.

4º) Gran parte de los usuarios no conocen FireFox, no sabén lo que puede ofrecerles, ni siquiera saben que podrían tener otro navegador.

No es que FireFox sea para nada un mal producto. De hecho es muy bueno. Sólo que IE es un contrincante muy difícil de batir.

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.

Via Forbes puede leerse un artículo sobre la lenta agonía de Lotus Notes.
Hace un par de semanas hablaba con un viejo colega quien me decía que a algunos comerciales de Lotus Notes en España habría que ponerles un monumento por su contribución al mercado de TI. ¿Alguien se acuerda de quién vendió Notes a Telefónica?
Lo cierto es que en su momento las dos únicas plataformas decentes de correo corporativo para grandes empresas eran Lotus Notes, Microsoft Exchange y Novell GroupWise. Incluso ahora que empieza a haber otras ofertas sobre Linux como Scalix es aún difícil fiarse de ellas.

Para aquellos que estén pensando en migrar su empresa a entorno Linux+OpenOffice, el libro de Maria Wislow The Practical Manager's Guide to Open Source tiene unas sencillas hojas Excel de evaluación para hacer una estimación rápida de los costes y ahorros derivados del cambio.
Es interesante leer el comentario de Don Rosenberg en LinuxWorld Magazine.

Se acaba de poner el funcionamiento el superordenador MareNostrum del Centro Nacional de SuperComputación de Barcelona.
Se trata de un cluster de 2.282 servidores BladeCenter JS20 sobre el kernel 2.6 de Linux.
Leer noticia en el navegante de elmundo.es.

La consultora Peerstone Research ha publicado en su web un interesante estudio sobre Linux y ERP de noviembre de 2004. Claro, conciso y fácil de leer.

Via Business Wire puede leerse la nota de prensa del acuerdo de colaboración entre Yahoo! y Wikipedia para mostrar enlaces relacionados de Wikipedia en las búsquedas de Yahoo!.
Vale la pena estudiar Wikipedia como uno de los casos más exitosos del mundo en desarrollo basado en comunidad. Incluso MSN Encarta ha anunciado algunas funcionalidades de estilo Wiki para su próxima versión ¿estarán intentando emularles?
http://home.businesswire.com/portal/site/google/index.jsp?ndmViewId=news_view&newsId=20050407005258&newsLang=en

Se acaba de publicar el estudio de Netcraft de abril en el cual el servidor web Apache continua ganando cuota de mercado imparablemente.

http://www.netcraft.com/survey/Reports/0404/byserver/index.html

Cuarta y última entrega de la mini serie sobre cómo crear un proyecto Open Source exitoso.

Regla Nº 22: La última milla tecnológica la recorre el canal de ventas.
Esto es especialmente cierto en España y Sudamérica, donde existe una fuerte cultura de cliente cautivo. En el software es fundamental la figura del prescriptor. Pero incluso otras empresas con fuerte énfasis en la venta directa (estilo Dell) utilizan los canales comerciales como medio de ingresos.

Regla Nº 23: Los vendedores necesitan directrices muy cláramente definidas.
No se puede coger un vendedor que lleva vendiendo cajas todas su vida y, de repente, ponerlo a vender servicios Open Source. Es preciso realizar un coaching apropiado con los vendedores y decirles cláramente qué deben vender, a quien y cuando.

Regla Nº 24: El factor clave es la cuota de mercado.
Los mercados de software se conquistan mirando los mapas de colores del geo-marketing y arañando cuota de mercado zona por zona.

Regla Nº 25: Cuidado con el empleo indiscriminado de referencias.
El mercado de la consultoría funciona por la referencia. Básicamente cuando se visita a alguien siempre se hacen las mismas preguntas por este orden: 1ª) ¿cuantos sois en la empresa? 2ª) ¿cuanto facturais? 3ª) ¿en qué año os constituísteis? y 4ª) ¿qué clientes teneis?
Es por este uso de factores prácticamente irrelevantes a la decisión de compra que la referencia comercial es tan importante cuando de inicia un proyecto y los restantes 3 parámetros son bastante pobres.
Pero ¡cuidado! a los clientes no les suele gustar para nada que se utilice su nombre sin permiso ni que se desvelen secretos estratégicos en la prensa.

Regla Nº 26: La época del año para publicar noticias importa.
La peor época del año para enviar notas de prensa es durante las ferias importantes. Porque durante esta temporada los periodistas suelen estar saturados. En los meses estivales hay un valle de noticias, pero también puede haber muchos menos lectores.

Regla Nº 27: Los periodistas odian los resúmenes ejecutivos.
No hay nada que un periodista odie más que el aburridísimo resumen ejecutivo escrito por un auténtico nerd. Los periodistas necesitan historias y novedades impactantes.

Regla Nº 28: Cada proyecto es diferente.
Como decía Einstein, la creatividad es más importante que el conocimiento :-)

Ver a tercera parte de esta serie: Trampas a evitar.

Tercera parte de la mini serie sobre cómo crear un proyecto open source exitoso.

Regla Nº 15 Confiar en que una licencia OSI salvará un producto mediocre.
Los usuarios no adptan un producto por su licencia, lo adoptan por su funcionalidad y calidad, si la licencia es compatible con sus necesidades.

Regla Nº 16 Confiar en que si se fabrica un producto superior la gente lo comprará sólo por ser técnicamente mejor.
Despreciar el marketing es muy típico de los ingenieros en general y de los informáticos en particular. Conviene no olvidar que incluso en las empresas con mayor inversión en innovación los gastos de I+D no suelen superar nunca el 10% del presupuesto.

Regla Nº 17 Confiar en que La Comunidad contribuirá significativamente al desarrollo.
La Comunidad puede contribuir a testear el producto y a internacionalizarlo, en algunos casos incluso puede añadir extensiones o nuevos módulos; pero es muy díficil (y poco recomendable) que el núcleo del producto lo toquen más de 6 ó 10 personas.

Regla Nº 18 Confiar en que los usuarios aceptarán un producto sin terminar con la promesa de mejoras futuras.
Los clientes están hastiados de vaporware. Se lo han vendido demasiadas veces. De modo que es poco probable que se sientan muy inclinados a empezar con la versión 0.5 alfa a la espera de la 1.0.

Regla Nº 19 Minusvalorar los costes ocultos de desarrollo.
El software tiene deseconomías de escala. Cuanto más crece el proyecto más costoso se vuelve añadirle cosas. Lo que empieza como un ágil felino con 3 ó 4 programadores de alta productividad puede degenerar en un mastodóntico dinosaurio que consume toneladas de hierba al día sólo para seguir con vida.

Regla Nº 20 Sacar builds inestables.
Estoy profundamente en desacuerdo con el dicho Open Source "release soon, release early". Sacar builds inestables sólo sirve para frustrar a los usuarios y llenar de flames el buzón de soporte.

Regla Nº 21 No dar soporte adecuado: gratuito y de pago.
Muchos modelos de negocio Open Source hablan de vivir del soporte y los servicios de valor añadido. Y, no obstante, mucho proyectos paradójicamente lo reducen a lo eliminan porque: a) Consume mucho tiempo y b) Es aburrido.
¿Si se pretende vivir de los servicios hay que poner toda la carne en el asador para potenciarlos?

Ver la segunda parte de esta serie: Mejores prácticas.