Este año la proliferación de socavones en la calzada a causa del frio será un grave problema para los ayuntamientos.

Philip Ashlock defiende en el blog Open311 que el servicio de atención a la ciudadanía 311 (lo que en España es el 010) de las ciudades norteamericanas (y de todo el mundo) debería contar con un API abierto para el que hacen una propuesta.

Fred Wilson expone la idea de que, en lugar de llamar al 010, los problemas no urgentes como los socavones, pudieran reportarse usando por ejemplo Twitter y Flickr. Ello ahorraría llamadas al call-center y permitiría adjuntar fotos que facilitasen evaluar cuales son los hoyos más peligrosos que requieren atención perentoria.

La historia De brokers a parias de Antonio Estévez contada por Isabel Velloso en El Mundo.es | Economía es como para reflexionar porqué el coste del fracaso frena letalmente el emprendizaje en España.

Tras leer cómo quebró su empresa (y él mismo de rebote) ciertamente se puede argüir que el bueno de Antonio ignoró aquel sabio refrán “la avaricia rompe el saco” y, en su inexperiencia como empresario, avaló personalmente una deuda de la empresa que no podría pagar en el caso de que las cosas se torciesen (algo que por aquel entonces parecía tan impensable como el hundimiento del Titanic).

En la vorágine de una burbuja económica, no es fácil que los árboles le dejen a uno ver el bosque, y, amenudo, la única opción sensata para sobrevivir parece ser hacer que la empresa crezca a ritmo de vértigo a base de deuda. Entonces, en lugar de emplear las épocas de bonanza para ahorrar y prepararse para la vacas flacas, se emplean para endeudarse hasta las cejas (esto es básicamente lo que le ha pasado a Grecia, por cierto).

Además, cuando el ostiazo se lo da una gran empresa, pues sale a bolsa y el rejón lo acaban pagando lo pequeños inversores ¿Alguien se acuerda del IBEX Nuevo Mercado? Pero en el caso de una PyME quien paga los platos rotos es irremediablemente el emprendedor.

Claro que no es lo mismo emprender en Silicon Valley, donde el 90% de las start-ups fracasan, hay dinero de sobra disponible a raudales (incluso ahora), y la bancarrota se percibe no sólo como un fracaso estrepitoso y una mancha imborrable sino también como una oportunidad para haber aprendido algo. Que emprender en España, donde sólo es fácil obtener dinero prestado avalándolo con garantías reales y el capital-riesgo es más bien capital-sin-riesgo. Aparte de que como quiebres te conviertes con una altísima probabilidad en un apestado de por vida.

La última vez que estuve en EE.UU. tomé esta foto con el móvil a un anuncio callejero. “¡Madre Mia!” me dije a mi mismo... “Aquí quebrar es algo tan normal que hasta tienen un procedimiento abreviado para hacerlo”.

Y es que hay una regla de oro que ningún emprendedor debería olvidar: corre riesgos sólo con el dinero de otro, nunca con el tuyo propio. Y recuerda todos los negocios son un RIESGO hasta el negocio más aparentemente cantado y seguro es un gran riesgo, sobre todo cuando se depende de un banco, que, como dice Ángel Medinilla, es ese socio que te pone un paraguas cuando hace sol y se apresura a quitártelo cuando llueve.

El artículo de Isabel Velloso termina afirmando que si Bil gates o Larry Page fuesen españoles, ni Microsoft ni Google existirían. Lo cual no es ninguna conjetura, sino una evidencia innegable, habida cuenta de que no hay ningún Microsoft ni ningún Google de origen español.

dm Server es el servidor de aplicaciones Java basado en OSGi de la división SpringSource de VMWare.

Matthew Aslett comenta en 451 CAOS Theory el cambio de licencia de dm Server de GPL a EPL que se convertirá con ello en el Proyecto Virgo de la Eclipse Foundation.

Adam Fitzgerald, community manager de SpringSource, anunció que desaparecerá la versión comercial de dm Server y VMWare venderá en su lugar suscripciones de soporte para Virgo.

Según los analistas de 451 CAOS Theory, este cambio es sólo un caso particular de una tendencia hacia la revitalización de los proyectos basados en Comunidad frente a aquellos controlados por un único fabricante y plantean 4 opciones de futuro para el Open Core Licensing.

Yo mismo he sido crítico en el pasado con Open-Core Licensing y Open Source Comercial. Algunos modelos me parecen algo así como regalarte el coche y luego tratar de cobrarte 30.000€ por la llave de contacto, el aire acondicionado y algunos otros accesorios. Además, considero que el Open Core crea confusión respecto de lo que es, o no, Open Source. No es el modelo me parezca intrínsecamente malo, sino simplemente que considero que contribuye a la peor amenaza al Software Libre: el miedo, las dudas y las incertidumbres (FUDs).

Por otra parte, considero que existe tensión debido a que algunas de las empresas con modelos Open Core no están alcanzando los resultados financieros esperados. Posiblemente esto ni siquiera es un defecto del modelo de negocio en absoluto, ya que en medio de la que está cayendo no alcanzar la cifra de negocio prevista es lo más normal del mundo. Pero lo que si parece que se va haciendo evidente es que los exits de las empresas Open Source casi nunca son los pelotazos a los que nos tenían acostumbrados las empresas de software privativo que se vendía bien y los portales de web de éxito.

Post relacionado: Open core transparency test.

En el blog Gestión Documental y Open Source!! de Antonio de las Nieves hay una traducción del artículo How JBoss did it de David Skok. Imprescindible como caso de estudio sobre la puesta en práctica operativa de un modelo de negocio Open Source.

Hace unos días se me ocurrió organizar un pequeño brainstorming con la gente de Tibi acerca de las ideas de negocio que han funcionado y jamás (casi con certeza) hubieran recibido una ayuda pública. He aquí algunos ejemplos:

Título del proyecto: Teléfono móvil sin botones (vulgarmente conocido por "plancheta").
Razón de la denegación: Ausencia de necesidad de mercado. Ausencia de plan de negocio viable.
Producto: iPhone

Título del proyecto: Sistema de rotación acelerada de stocks textiles.
Razón de la denegación: Falta de innovación. Insuficiente justificación económica del proyecto.
Producto: Zara

Título del proyecto: Conglomerado de software Linux.
Razón de la denegación: Falta de innovación. Insuficiente viabilidad del
plan de explotación de resultados.
Producto: Red Hat

Título del proyecto: Base de datos libre para websites.
Razón de la denegación: Falta de innovación. Insuficiente viabilidad del
plan de explotación de resultados.
Producto: MySQL

Título del proyecto: Destockaje textil por Iinternet.
Razón de la denegación: Falta de innovación.
Producto: Privalia

Título del proyecto: Factura sencilla por Internet.
Razón de la denegación: Falta de innovación.
Producto: FACTURAgem

Título del proyecto: Sistema de voz, chat y videoconferencia IP.
Razón de la denegación: Inadecuación a las líneas estratégicas de plan de subvenciones.
Producto: Skype

Título del proyecto: Mensajería instantánea y compartida en Internet pero con 140 caracteres.
Razón de la denegación: ¿140 caracteres? ¿Estamos locos o qué?
Producto: Twitter

* Nota: Luego intentamos encontrar un nombre para un proyecto que fuese subvencionable con un 100% de probabilidad, y llegamos a poner en común lo siguiente: “Proyecto de I+D del Instituto de Convergencia Europea para la creación de una Red Social 2.0 para la e-Factura mediante DNI electrónico en PyMEs sostenibles dirigidas por mujeres”. (Y con todo mi respeto debido para Europa, las redes sociales, el DNI electrónico, la PyME y la mujer).

¿Qué conclusiones podríamos sacar? Para mi, la primera, es que lo más importante para conquistar un mercado no es que un producto sea innovador sino que sea disruptivo. Los productos innovadores pueden ser disruptivos y viceversa, pero ambas cosas no son necesariamente lo mismo.

Una disrupción se produce normalmente cuando las empresas poderosas en un mercado se quedan temporalmente fuera de juego debido a una nueva remezcla ingeniosa de elementos previamente existentes.

Debido a que vamos rezagados en I+D respecto de otros paises, es dudoso que en España podamos inventar de repente la ginebra o la Coca-Cola, pero, con un poco de suerte, quizá encontremos la forma óptima de combinarlos en un vaso con hielo y descubrir el Cubalibre.

El problema es que eso no se considera innovación y, por consiguiente, nadie ayuda al que inventa el cubata.

Artículo relacionado: Anti-portfolio de Bessemer.

Post relacionado: Guitar Wars

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)

Juantomás en la fiesta del 10º aniversario de Last Thursday:

Wave no es [por ahora] una herramienta colaborativa. Qué clase de herramienta colaborativa es esa en la cual no puedes invitar a tus colaboradores a colaborar contigo?”

Zack Urlocker se hace eco en InfoWorld del artículo de Robert Capps en Wired titulado The Good Enough Revolution cuya idea central es que no es imprescindible tener un producto mejor, ni siquiera innovador para crear una disrupción en un mercado. Pone como ejemplo la videocámara Flip Ultra que la empresa Pure Digital lanzó en 2007. Un modelo que capturaba en 640×480 pixels frente a los 1080 de Sony pero por un precio de 150$ en lugar de 800$ Dado que los videos en YouTube no podían cargarse en alta resolución, la cámara resultó una herramienta ideal para publicadores amateur y la Flip Ultra se vendió como pan caliente hasta alcanzar un 17% de cuota de mercado en EE.UU. siendo finalmente Pure Digital adquirida por Cisco.

Alberto Barrionuevo comentó en la lista de ASOLIF la noticia de Axel Postinett en Handelsblatt acerca de que 360.000 empleados de IBM han recibido el mandato de cesar el uso de Microsoft Office en 10 dias y utilizar exclusivamente Lotus Symphony. En la actualidad, IBM ya tenía 330.000 puestos con Symphony y seguir utilizando Microsoft Office requerirá una autorización especial. Según las fuentes de Handelsblatt la migración no se ordenó por cuestión de ahorro de licencias, sino como un claro gesto de apoyo inequívoco a los estándares abiertos.

Dave Rosenberg (MuleSource)
Javier Soltero (Hyperic)
Mårten Mickos (MySQL)
Mårten Mickos II (MySQL)
John Powell (Alfresco)
Fabrizio Capobianco (Funambol)
Boris Kraft (Magnolia)
Kelly Herrell (Vyatta)
Satish Dharmaraj (Zimbra)
Ranga Rangachari (Groundwork)
John Roberts (SugarCRM)
Toby Oliver (Path Intelligence)
Danny Windham (Digium)
Bill Karpovich (Zenoss)
Mark Brewer (Covalent)
Gianugo Rabellino (Sourcesense)
Bob Walters (Untangle)
Paul Doscher (JasperSoft)
Brian Gentile (Jaspersoft)
Pete Childers (Zmanda)
Rod Johnson (Interface 21)
Harold Goldberg (Zend Technologies)
Eero Teerikorpi (Continuent)

Interesantes las entrevistas de Bambi Francisco a Chris Boone y Chris Shipley en VatorNews acerca de ciertas cosas que debe tener en cuenta un emprendedor. Traduzco aquí solamente un par de frases escogidas de cada una.

Primero y principal tienes que solucionar un enorme problema existente en el mercado, la necesidad es la madre de las invenciones [...] hemos visto a ciertos tipos en visión computerizada qie tenían una tecnología increíble que el mercado simplemente no necesitaba o no sabía como apreciar" (Boone)

Debes tener cuidado con las cosas doradas y brillantes [...] Cada compañía empieza con una visión. Creen que van a ser X y acaban siendo Y. Esa es la naturaleza del descubrimiento de un nuevo negocio". (Shipley)

Optaros ha lanzado recientemente un nuevo directorio de Software Libre empresarial llamado EOS Directory. Probándolo un poco, da la impresión de que pretenden basar su punto fuerte en crear conversaciones alrededor de los productos: foros, ratings, etc.

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.

Post relacionado: A Visit to Microsoft and Google (Joel Spolsky)

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.

MG Siegler publica en TechCrunch un gráfico sobre el único día en que Bing superó a Yahoo! como segundo buscador más usado.

Los usuarios le dan una oportunidad a todo nuevo producto, pero sólo UNA.

Captar la atención de la gente por un instante es relativamente fácil, mantenerla en el instante siguiente, prácticamente imposible.

Artículos relacionados:
Bing Continues to Show Growreth in Search Activity (comScore)
Bing Is Growing Faster Than Ever, Keeps Gaining Search Market Share (Erick Schonfeld)

La web de OSOR recopila una buena cantidad de casos de estudio de uso de Software Libre en la administración pública.

¿De dónde surge la idea de Feevy?

La idea inicial fue de David de Ugarte de la Sociedad de las Indias. Surgió de la necesidad de tener una heramienta que fuera más allá de un simple blogroll. Lo ideal era que en tu blog de una manera sencilla se pudiera actulizar automáticamente la información de los blogs que seguías o de cualquier feed RSS (flickr, youtube o twitter).

Como no podía ser de otra manera, desde el primer día se decidio que fuera un servicio gratuito y el software se publico como Software Libre.

¿Porqué la apoya el BBVA?

Los responsables de Innovación del BBVA están muy sensibilizados con el conocimiento que existe en internet, con las herramientas facilitadoras y con promover nuevas vías para mejorar el acceso y organización de la información.

¿Cuales son los objetivos del servicio?

Feevy es una herramienta perfecta para dar este tipo de servicio. De hecho el plan a corto plazo del Banco es por supuesto seguir manteniendolo como Software Libre, crear una Comunidad de desarrolladores y crear un entorno de desarrollo e innovación que permita evolucionar y experimentar con nuevas ideas a partir del Feevy actual. El Software Libre es el modelo ideal para aglutinar este talento.

¿Quién de los programadores murió misteriosamente durante el testeo de la beta?

Hay dos respuestas:

a) ningún programador que participó en todo el proceso sufrió daños más allá de los habituales.

b) ninguno, pero podía haber sucedido perfectamente.

¿Cómo piensan ganar dinero con eso (si es que piensan ganarlo)?

Hay muchos factores que benefician a BBVA y no se monetizan directamente:

• Imagen: es un proyecto que da visibilidad a las iniciativas de innovación del grupo BBVA.

• Visibilidad: Todos los días se visualizan unos 200K feevies en páginas de usuarios.

• Talento: Feevy históricamente ha atraído desarrolladores, buenas ideas y esto es algo muy apreciado por el BBVA.

• Innovación: Usando una estrategia de usar software libre y crear y promocionar un ecosistema en que pueda surgir innovación.

Una de las cosas que sorprende al televidente español la primera vez que se pone a ver el telediario en Estados Unidos es que se tiene la impresión de estar viendo las noticias del Canal Geriátrico. En EE.UU. no es raro encontrar a un vetusto señor de pelo blanco comentando las novedades del día.

Aquí, en España, José María Carrascal fue la excepción, y ni aún así, porque en Antena 3 se negaron sistemáticamente a pasarle del late night a prime time a pesar de que era líder en audiencia.

Aquí lo que se lleva es la novedad, una cara mona, como la de Leticia en su época, o, en todo caso, un hombre que no incomode al gobierno, como Urdaci. Ahora mismo el mejor pagado en la tele es Javier Sardá, con ese pedazo de programa de La Noria en Telecinco.

La tele quema, y si difícil es llegar, más difícil es mantenerse, al menos mantenerse más de una legislatura. Hasta a German Yanke se lo cepilló la Espe tras aquella polémica entrevista que le hizo en 2006, y mira que el suyo no era un telediario al que sólo le faltaba la sintonía del No-Do como cabecera.

Aquí se muere uno de madurez con mucha facilidad, excepto que acepte irse a las tertulias de la mañana con María Teresa Campos, y no meta allí mucho follón.

Yo siempre he pensado que sesenta años es una edad razonable para dirigir un gobierno, pero aquí pasando de los cincuenta cualquier candidato presidenciable es ya un prejubilado.

Pero si hay un sector donde la madurez afecta injustamente de forma devastadora, ese es el software.

¿Alguien se acuerda de cuando Oracle compró Sleepycat en 2006 o de cuándo IBM donó UIMA a Apache en 2007?

Los usuarios, y en especial los desarrolladores, son devoradores voraces de novedades. Cuando no las tienen se aburren, y se ponen a mirar otro proyecto. No importa que el proyecto que tienen sea robusto y fiable. Su madurez lo hace aburrido. No importa si el nuevo producto es un poco mierdoso (crapy como dicen los angloparlantes). Si tiene iconos chulos ¡a instalárselo!
¡Ay! A cuántos usuarios les he advertido que no se instalen Windows Vista. Y no me han hecho caso. Y luego me han venido llorando. Les he dicho: "quedaros con XP que es de lo mejorcito que ha hecho Microsoft en toda su historia". Pero no, XP es maduro, es decir, sinónimo de obsoleto.

En un proyecto, cuando dejas de publicar novedades, los usuarios, simplemente, se van. No importa que el software siga siendo plenamente operativo y que, en realidad, no haga falta actualizarlo, porque está tan estable y bien terminado que es difícil añadirle nada más sin complicarlo y empeorarlo. Ese es el gran drama de la madurez: que las canas no son sexys en el software.

Supongo que alguien pensará que así es como se innova: tirando todo lo anterior a la basura y volviendo a empezar. Pero es que en ese proceso cíclico en software hemos reinventado la rueda como diez veces en los últimos cincuenta años, poniendo nombres nuevos a ideas viejas. Llamándolo primero RPC, luego ORB, seguidamente EJB y, últimamente SOA/WS, para arebozar como novedoso algo que sigue siendo más o menos lo mismo.

Y si es dura la forma en la que uno tiene que sacar novedades de una chistera cada seis meses para mantener distraído de la madurez al personal, mucho peor es lo que cuesta mantener una reputación merecidamente adquirida. Porque la condena del software es que no existe el concepto de "casi bien". 99,9% fiable no es fiable. Y basta, por ejemplo, un agujero de seguridad, sólo uno, para que tu software sea etiquetado como "no seguro". Aunque los mismos tontos que le han colgado ese San Benito se muden a usar otro software nuevo que ni ha sido probado ni se sabe cuantas decenas de agujeros iguales o peores puede tener.

En conclusión, si tienes un proyecto de software, cada seis meses dale bótox y cámbiale el vestido, como a la Barbie, así seguirás vendiendo la misma muñeca todos los años, sólo tienes que acordate de que lo fundamental es cambiarle el traje amenudo para no pasar nunca de moda.

Post relacionado: El curso más difícil de mi carrera como profesor (Martin Varsavsky)

Hoy estuve en el chat con un amigo a quien llamaré el Capitán del Proyecto para preservar su anonimato. El Capitán me contaba lo que estaba pasando en su proyecto, que no es nada nuevo, ni nada sorprendente, pero no por ello menos impactante. En particular, la auto-imagen de ser un puto boina verde todo el día expuesto a peligros e incertidumbres es como para echarse a temblar. El texto completo de la Conversación con el Capitán del Proyecto lo reproduzco en VersiónCerø.

Esto lo he tomado hoy de las noticias de SourceForge. Y me ha recordado los problemas horrorosos que hemos tenido intentando reutilizar código de terceros.
La conclusión a la que yo personalmente he llegado, es que, a menos que sea una librería muy específica (no más de 1.000 o 2.000 líneas de código) nunca hay que intentar integrar ningún software que no sea una solución completa 100% madura y testeada.
En concreto JPodLib no lo he evaluado, lo que me ha llamado la atención de la noticia es la frase "¡hey! y no existe documentación". Mal comienzo. Le hace a uno preguntarse si el desarrollador sabrá siquiera lo que es el Desarrollo guiado por pruebas.
Y peor, una gran cantidad de las piezas de Software Libre que hay por ahí son como el bicho de Alien: que se mete en tu nave y empieza a morir gente misteriosamente.
Esto es porque escribir software es intrínsecamente mucho más divertido que probarlo o documentarlo, y por ello mucha gente lo escribe pero nunca hace el resto de los deberes.
Y a los de SourceForge ya les vale llevar esa noticia portada ¿no son conscientes de que esas cosas son las que explotan los del lado oscuro para sembrar FUDs y crearnos mala reputación?

Pienso que lo primero que tiene que hacer un software es satisfacer una necesidad. Hecho ésto, puedo debatir si debe o no ser libre, eliminado el demoledor argumento de "Pero si eso no sirve ni pa .............".

Ya nos contaba Sergio en "Código cerrado indirectamente" ciertos problemas que ahí están respecto a determinados productos libres.

Siempre está el argumento de "Pues arréglatelos, es software libre, y así además aportas a la comunidad". Si, si, pero no todo el mundo puede arregárselas sólo (no digo que tú no,Sergio J), y esa barrera hace perder muchos usuarios.

Por otro lado está la calidad del código que provoca el conocido efecto jeroglífico: El código es tan rebuscado e ilegible, la documentación es tan "que no existe" que no hay quien le meta mano. Me podías haber entregado el código máquina y me quedo igual.

Creo que son cosas a tener en cuenta y que junto a otras, pueden ayudar a difundir el Software Libre.

En esta línea, desde la Free Software Foundation han iniciado una campaña para que quienes quieran aportar al conocimiento libre en el mundo del software sepan que es quizás en estos proyectos donde su granito de arena tenga mayor densidad.

Dentro de los más importantes estarían los proyectos de reemplazo. Estos proyectos serían importantes porque compiten en áreas en las que tradicionalmente los usuarios no pueden elegir una alternativa libre lo suficientemente decente.

La lista de proyectos que nos propone la FSF es:

• Gnash - Reproductor de Flash Libre


• Coreboot - Free BIOS


• Reemplazo libre a Skype


• Sistemas de contactos y transacciones de donación


• Software de edición libre de vídeo


• Reemplazar GoogleEarth


• gNewSense - GNU/Linux completamente libre


• GNU Octave - Remplazo al conocido MatLab


• Reemplazo libre a las librerías OpenDWG


• Depuración reversible en GDB


• Controladores Libres para enrutadores de red

Más en | High Priority Free Software Projects en la FSF
Via | Picando Código

Voy a contar una historia que ilustra cómo cerrar código publicando sus fuentes.

Hace un par de semanas iniciamos una integración de una herramienta de reporting en hipergate para un proyecto.
Emilio Arias de Stratebi tuvo la amabilidad de pasarme un informe que ellos habían hecho comparando varias herramientas, Pentaho entre ellas, como la plataforma de referencia en Stratebi.
Poco después, José Luis Ramírez de i2e me comentó que ellos usaban BIRT.

Me puse a evaluar ambas opciones pues, y ahí empezó el calvario. En 12 días de intentos he sido incapaz de diseñar y sacar un informe por pantalla. Con BIRT porque la instalación sobre My Eclipse 6 (que es lo que yo uso) empieza a decir que no le gustan las librerías base, y falla el diseñador. Y en Pentaho porque el runtime de JFreeReports 0.9 parece que no reconoce bien los informes del Report Designer. En fin, un desastre.

Como parte del proceso de googlear en busca de soluciones a mis penurias, encontré este post de SZ Quadri sobre BIRT, JasperReports y JFreeReports en el cual aboga por BIRT frente a Jasper y Pentaho por lo siguientes motivos:

1. BIRT es un proyecto Eclipse: Esto asegura que seguirá vivo y evolucionando (como proyecto libre). Estamos seguros de que nadie va a cerrar el código directa o indirectamente (por ejemplo vendiendo la documentación).

5. BIRT tiene documentación de calidad: Una base de datos e informes de ejemplo. Todo ello para reducir la curva de aprendizaje.

Es decir, que BIRT sería la panacea si consiguiese hacerlo funcionar.

Y ahora voy a relatar la típica historia con el típico Software Libre de segunda división y cuando digo "segunda división" me refiero a todo lo que no sea Linux, Apache Web Server, Tomcat, MySQL, PostgreSQL, PHP y Java:

1. Buscas por la red y descubres que, al parecer, existe un producto libre que cubre todas tus necesidades.

2. Lleno de excitación te descargas el producto.

3. Al descomprimir el ZIP te percatas de que el documento de instalación consiste en una pegatina de Anís del Mono.

4. Tras luchar a brazo partido durante dos días con setup por fin consigues que arranque.

5. Al hacer click en cualquier opción de menú no trivial, peta algo.

6. Te pones a buscar qué has hecho mal. Entonces descubres que: a) el fabricante sólo te ayuda si le pagas primero, b) la documentación previa sobre errores reconocidos es una mierda como una casa de doce pisos.

7. Tratas de bucear tu mismo en el código a ver si encuentras la fuente del error. Proceso durante el cual te percatas de que careces de todos los fuentes y de que, además, el control de versiones publicadas es un carajal.

8. Tras unas cuantas ñapas y algún que otro milagro, consigues echar a andar el programa. Momento en el cual te das cuenta de que hace alguna burrada, del estilo de cargar un millón de registros en memoria si tiene una tabla algo grande.

9. Para entonces tienes un Alien metido en tu programa. Has perdido dos o tres semanas de proyecto superando la curva de aprendizaje y ahora resulta que te topas con un muro.

10. Desesperado, llamas al fabricante para pagarle un contrato de soporte. Pero, como estás en zona EMEA, te asignan a un becario al cual le acabas haciendo el trabajo de explicarle dónde están los bugs para que haga de correveidile al equipo de desarrollo.

No sé si me dejo algo en el tintero, pero la moraleja es que existen muchos productos cuyo código es abierto y ello no supone ninguna diferencia respecto del software comercial. Es así porque los fabricantes han hallado la manera de subvertir el espíritu del Software Libre, abriendo el código pero haciéndolo inútil a casi todos los efectos a menos que le pagues al fabricante.

Y conste que estoy 100% de acuerdo en que las empresas desarrolladoras de Software Libre busquen fórmulas para financiarse y cobrar legítimamente a los clientes. Lo que no es éticamente correcto es que distribuyan productos que no funcionan bien y luego cobren por arreglarlos.

Por último, bueno, sí, será que me siento cansado y frustrado de pelear a brazo partido con JARs y ficheros . properties o que soy un melón con patas como programador y no me entero de nada. Pero vale ya de webs bonitas y productos asquerosos, GÑE >:-\

Post relacionado: Terapia Hacker: intenta compilar OpenOffice.org (Juantomás)

Salvador Pérez Crespo comenta en el Boletín de la Sociedad de la Información de Telefónica la cantidad inusual de Wikis para empresas que se presentaron durante la celebración de la Web 2.0 Expo en San Francisco: Atlassian Software Systems, Awareness, eTouch, GoLightly, Igloo, MindTouch, Socialtext, TamTamy, Zoho.

En informática las soluciones más simples a los problemas cotidianos son las primeras que triunfan. Y en todas las empresas existe un problema muy serio con la proliferación de documentos Word. Incluso con un sistema de control de versiones, el modelo de documento gestionado por un cliente pesado como Microsoft Word y OpenOffice adolece de dos graves inconvenientes intrínsecos: 1º) el documento sólo puede ser editar por una persona al mismo tiempo, y 2º) el documento debe tener un tamaño máximo de varias decenas de megas para que el programa lo pueda manejar razonablemente rápido.

La solución será que la gente se acostumbre a escribir usando wikis online en lugar de un procesador de textos. Me llama la atención que, hasta ahora, he visto más esfuerzos orientados a vender periódicos online y blogs corporativos a las empresas que wikis, cuando en realidad el wiki tiene un alcance mucho mayor en cuanto a número de usuarios potenciales.

Está el tema de la curva de aprendizaje y el cambio de costumbres, por supuesto, pero una vez que te acostumbras a la sencillez, rapidez y potencia de un buen wiki encuentras un fastidio usar un procesador de textos.

Como efecto lateral, la proliferación de wikis y herramientas de edición online hará mucho menos relevante la importancia de los formatos, aunque por supuesto seguirán siendo una piedra de toque porque, al final, muchas cosas precisan ser almacenadas electrónicamente como un documento autocontenido.

La cuota de mercado de Safari 3.1 ha subido un 300% respecto de la de su predecesor Safari 3.0 hasta alcanzar un 0,21% del mercado total de navegadores debido a la práctica de Apple de ofrecer Safari como nuevo software en el Apple Software Update de iTunes (inicialmente empezaron camuflándolo como una acualización de iTunes).

Estoy trabajando en un proyecto de modernización y optimización de un ERP corporativo. En un traslado han aparecido estos manuales sobre las herramientas base utilizadas.

Es por esto que es tan difícil desplazar a Microsoft: Access y Crystal Reports están más enganchados a la solución que una garrapata. Y el entorno de virtualización del cliente es intrínsecamente Microsoft, tanto por el hardware de 64 bits que usan como por el software de infraestructura.

La única diferencia con el COBOL es que Microsoft va a retirar este verano el soporte a VisualBASIC 6 y no quedará más remedio que migrar a .NET

Ya vamos para 9 años con KnowGate, de modo que hay algunas cosas que puedo contar sobre lo que es tener una empresa de tecnología.

En la red hay una carpeta llamada \\Jupiter\Clientes\Ofertas\ que contiene cerca de 600 ofertas y más de 11.000 ficheros. En media, hemos presentado una oferta económica a un cliente por semana durante casi 10 años.

Dicho así no suenan a muchas ofertas, pero teniendo en cuenta que la empresa es una PyME y que cada proyecto dura entre 2 meses y 2 años son realmente montón de propuestas.

El caso es que somos málisimos presentando propuestas de servicios profesionales. De hecho, estadísticamente perdemos nueve de cada diez ofertas que presentamos. Somos tan malos que últimamente casi hemos dejado de presentar propuestas y, o vamos a tiro hecho de antemano, o no nos molestamos en escribir papelitos.

Explicaré a continuación las razones por las cuales tenemos un ratio tan pobre de éxito comercial. Empezando por una DECLARACIÓN DE PARTIDA:

En circunstancias normales ningún cliente compra tecnología a una PyME
¿Qué quiero decir con circunstancias "normales"? Pues si el cliente tiene presupuesto y plazo suficientes y un objetivo bien definido, y patrocinio de la alta dirección, normalmente se deja seducir por el branding de una gran consultora y le da el proyecto al proveedor más gordo de todos que le entra con el rollo del proveedor integral de servicios plenos.

Entonces ¿que puede hacer un PyME para vender? ¿cómo se las apañan para sobrevivir? Ahí es donde entran en juego las tácticas guerrilleras.

1º) El adjudicatario tiene que subcontratar a alguien competente a fin de cuentas
De vez en cuando trabajamos (por necesidad) con una empresa donde son malos de verdad, en serio, todo el mundo que los prueba dice que son malísimos. Pero tienen unas oficinas deslumbrantes y el respaldo de "un gran grupo". Y venden un montón. Lo cual nos viene fenomenal para ir de comparsita. El único problema es el margen de intermediario. Algunos son decentes y cobran un 15 o un 20%, lo cual es razonable, pero hay intermediarios que cargan más del 100% de sobreprecio a cambio básicamente de nada.

2º) Los clientes compran cuando no encuentran nada que les sirva
Existen clientes con requisitos técnicos y funcionales lo bastante especiales como para que casi ningún proveedor pueda hacer una propuesta decente. En el año 1999 vendíamos proyectos basados en XML, ahora XML lo sabe todo el mundo y no supone ninguna ventaja competitiva, pero por aquel entonces saber XML bien marcaba una diferencia. Lo mismo puede suceder con el conocimiento de un sector vertical concreto como la logística, la automoción, el turismo o la trazabilidad alimentaria. Un producto yankee, por bueno y mastodóntico que sea (tipo SAP) no tiene nada que hacer en nichos concretos donde el software estándar no sirva.

3º) Los clientes compran después de que les haya explotado algo en las narices
Es típico licitar los grandes proyectos informáticos por debajo de lo razonable. Después de un ostiazo mayúsculo de la superconsultora de turno, el cliente se queda demasiado tocado presupuesariamente como para empezar de nuevo con una gran consultora, entonces baja su presupuesto desde los millones o los centenares de miles hasta las decenas de miles, una banda de presupuesto en la que las grandes no pueden o no quieren entrar.
Lo bueno de estos proyecto de limpieza de material radiactivo es que, si salen bien abren la puerta de un cliente al que de otro modo no se podría acceder. Es el caso de las grandes empresas con procesos muy complicados (y hasta humillantes) de certificación de proveedores que sólo es posible saltarse cuando están muy desesperados.

4º) Los clientes compran cuando están asustados y tienen prisa
Casi todos los años hay cosas que deberían estar listas el 1 de septiembre pero cuya ejecución ni siquiera se ha comenzado el 15 de julio. Esto sucede porque los clientes empiezan a planificar el cierre de proyectos en mayo para que en ningún caso un proyecto retrasado les fastidie las vacaciones, pero casi siempre hay alguna campaña anual que se queda descolgada. Una gran consultora no es lo bastante ágil para coger este tipo de proyectos (el día 20 de julio el comercial de grandes cuentas lo más seguro es que esté en la playa de vacaciones). Los proyectos que se planifican para septiembre suelen retrasarse y estar listos (más o menos) para la campaña de navidad, pero para cuando llega el comercial de la gran megaconsultora ya estás más enganchado en el proyecto que una garrapata y no hay forma de quitarte.

5º) Los clientes compran cuando no tienen dinero para algo más caro
Dado que el presupuesto disponible para software en las empresas (incluso las grandes) es bastante bajo, cuanto menores sean los costes de estructura del proveedor, mayor es la probabilidad de poder bajar lo suficiente el precio.
Lo malo de este escenario es que hay muchas PyMEs que no pueden crecer (incluído el caso de la línea de servicios de KnowGate) porque crecer implica mayores costes, pero mayores costes implican mayores precios y eso provoca irremediablemente quedarse fuera de los proyectos, a menos, claro está que la estrategia sea específicamente el body shop barato por volumen lo cual no es factible en una PyME.

6º) Los clientes compran cuando tienen cerca al proveedor
Hay lugares donde el mercado es demasiado pequeño como para que a las grandes empresas les compense mantener una delegación comercial. En tales casos la cercanía al cliente, y la capacidad para reaccionar yéndole rápidamente a ver cuando lo necesita, bien pueden cerrar el paso a alguien de fuera. El problema de esta ventaja es el mismo que el punto anterior: la geografía actua como una barrera para entrar, pero también para salir impidiendo a la empresa crecer más hallá de algún límite geográfico natural.

7º) Los clientes compran cuando confían
Es posible ganarse la confianza de un cliente a base de hacer las cosas bien y, de esa forma, dejar fuera de juego a cualquier competidor grande o pequeño. El problema de esta situación es que resulta imposible de sostener a largo plazo ¿Porqué? Pues porque cuanto más confía el cliente en el proveedor más cosa le encarga, es más, como confía, le encarga los trabajos más difíciles y comprometidos, y todo va bien, en principio, hasta que un día sucede una desgracia... El ejercicio de poder desgasta, tanto que en algunos paises la presidencia se limita, por ley a dos mandatos. Tarde o temprano se cae un avión militar o se hunde un petrolero, o se quema un bosque, o sucede cualquier otra desgracia fortuita y sobrevenida. Y entonces alguien aparece pidiendo la dimisión del "responsable" en la creencia de que si algo salió mal alguien tiene que ser necesariamente el responsable de ello, y, como el cliente no va a dimitir de su cargo (obvio) el que carga con el muerto es siempre el proveedor.

En conclusión, la guerrilla es eficaz pero es dura en la medida en que para resultar exitosa debe obtener mejores resultados que el oponente con menos recursos. Y eso es precisamente lo que suele suceder en una PyME.

Me imagino lo que algúno puede estar pensando: "¡Un momento! ¡Pero yo tengo una buena idea!" Si crees en una buena idea, quédate en tu casa: vivirás con un bonito sueño. Si piensas en montar una empresa excelente ¡suicídate! hazme caso, sufrirás menos ¿sabes lo que cuesta ser excelente todos los días? ¿sabes lo que cuesta pilotar como Fernando Alonso en cada carrera o chutar como Raúl en cada partido? ¿sabes lo que cuesta tener una empresa donde todos están permanentemente a ese nivel?

La habilidad necesaria en los negocios no aquella derivada de tener brillantez para una idea o capacidad de sacrificio, sino inteligencia para saber explotar los recursos naturales que ofrece el entorno.

Cómprate la saga de Rambo en DVD, por mala que sea, en ella descubrirás que para sobrevivir a la intemperie no hace falta saber coser ropa, ni tener una resistencia sobrehumana al frio. Lo que hace falta saber es cómo fabricarse un abrigo con un saco y una piel de cabra para no morir de hipotermia. Eso es guerrilla.

Artículo relacionado: La esperanza no es una estrategia (Antonio Matarranz)

Según el evangelio de Juan, el primer milagro de Jesús consistió en convertir el agua en vino durante la boda en Caná. Y no fue poca cantidad, seis tinajas de piedra nada menos (se conoce que por aquel entonces aún no operaban en Galilea los controles de la Dirección General de Tráfico).

Resulta significativo que el primer acto divino de Jesús tenga que ver con la multiplicación de un recurso escaso.

Hace un par de semanas estaba tomando un café en Sevilla con un emprendedor que explicaba con magnífica lucidez el problema de los recursos en los proyectos informáticos.

El problema es que un programador experto quiere ganar más de 40.000€ al año" (decía) "Lo cual en coste de empresa supone alrededor de 55.000€" Sin embargo, el precio de mercado está a 6.000€ por mes/persona, con un máximo de 10 meses facturables al año entre vacaciones y bajas por diversos motivos.
Entonces, el margen bruto para la empresa son 5.000€ al año por programador. Lo cual es inadmisible puesto que la más mínima parada en el taxímetro de la facturación mete a la empresa en pérdidas.
¿Cómo se soluciona el problema anterior? Pues muy fácil: subcontratando dos veces el mismo programador a dos clientes diferentes, obteniendo así 100.000€ de facturación al año por el recurso humano, lo cual ya es algo mucho más razonable."

Las consecuencias de este escenario son bastante fáciles de preveer:

a) El programador se pasa todo el día más quemado que la pipa de un indio diciendo que no le da tiempo de hacer todo lo que le han mandado.

b) El cliente se queja de que por lo que paga, el programador nunca está cuando se le necesita.

c) Los plazos se alargan y el proyecto se tuerce.

Y que nadie se llame a engaño, las grandes empresas hacen esto exactamente lo mismo que las pequeñas. A veces incluso de forma mucho peor. Porque en una PyME compacta de 10 a 50 personas no hay mucho espacio para la mediocridad pero en un grupo de 500 a 1.000 hay fauna de todo tipo.

Una solución es lo que yo llamo "el pool de administradores certificados de Oracle" una presunta horda de expertos que el proveedor ofrece al cliente 24×7 para solucionar en 90 minutos cualquier problema. Este pool consiste en realidad en un par de administradores experimentados, que dirigen a una pandilla de chavales junior mal pagados que trabajan en remoto con un portátil. Los junior filtran las peticiones y mantienen al cliente distraido mientras los senior obran el milagro de la conversión del agua en vino. El plazo de resolución de incidencias es igual de largo que si los junior no existiesen, pero el cliente tiene la sensación de que alguien se está ocupando de sus problemas, y los senior no están bombardeados a llamadas telefónicas, lo cual no es una mala solución para nada.

La sobreasignación favorece en cualquier caso a las empresas grandes, porque estadísticamente es más fácil rotar gente cuando tienes 1.000 que cuando tienes sólo 10.

Otra vía de escape es la contratación off-shore cuyo problema actual, en base a mi experiencia personal, es que es 3 ó 4 veces más barata que la mano de obra española, pero también de 3 a 6 veces menos productiva. Con lo cual lo que al principio puede parece muy barato en coste por hora puede en realidad salir muy caro en coste, tiempo y calidad. Aunque el tema del off-shore merecería otro largo y tendido post en si mismo.

Se podría argüir que el problema son los elevados salarios de los programadores. Pero no es cierto, porque los programadores cobran en media menos que los ingenieros de otras disciplinas con titulación y experiencia profesional equivalente.

Es necesario acabar con la percepción de que el software es algo barato. No lo es. Y de que uno puede llegar a una boda con los bolsillos vacíos y comprar seis tinajas de agua para luego encargar al sumiller que las convierta en vino antes de que lleguen los invitados.

Eduardo Manchón publica en alzado.org una entrevista a Ricardo Galli con detalles interesantes sobre Menéame.

Una vez perdí una apuesta con un cliente: me desafió a presentarle un sistema informatizado de facturación que fuese más eficiente que el que tenía. La prueba de fuego consistiría en medir cuanto se tardaba en modificar una factura errónea, y en ella mi sistema informático perdió estrepitosamente contra un bote de Typex y un apunte a boli.

Eso es porque las cosas más práctica amenudo son también algo chapuceras.

En el viejo HTML 3.2 para meter una negrita simplemente escribías:

<b>negrita</b>
luego se inventó
<strong>negrita</strong>
que ya era 10 letras más largo,
y en sistaxis moderna habría que escribir en otro fichero algo como
<style>.negrita { font-weight:bold;} </style>
y luego
<span class="negrita">negrita</span>

Y todo ello por el muy loable propósito de separar el contenido de la presentación. Pero ¿hasta qué punto una negrita es digna de tanta complicación?

Algo similar pasa con muchas facetas organizativas: cuanto más estructurado, y pensado y repensado está el ERP de turno, más engorroso e impráctico resulta de utilizar. Los ERPs substituyen el clásico mail de: "Pedro, manda un camión mediano como todos los viernes a recoger la mercancía de Áridos Llanera S.L." por un complejo formulario donde figura: dirección de recogida (con 10 campos), datos facturación, tipo de transporte, descripción de la mercancía, peso, nº de bultos, etc.

El gran triunfo de los algoritmos como Google o JPEG es que aceptando un pequeña pérdidas de información se pueden obtener grandiosas ganancias en eficiencia de proceso de la misma.

Eso es justamente lo que los directivos de nueva generación debe aprender a explotar. En lugar de obsesionarse con metrizar, medir y optimizar todos y cada uno de los procesos, deben permitir que la información fluya sin trabas ni excesiva burocracia, y al mismo tiempo, diseñar procesos que sean capaces de encontrar y extraer lo que se necesita en cada momento del torrente de datos de la empresa.

La táctica clásica para combatir la descoordinación, la desinformación y el desorden ha sido la burocratización. En forma de normas que prohibían poner tags <b> en los archivos y establecían una política de uso obligatorio de un repositorio de estilos corporativos mantenido por un amo del calabozo. Pero la burocratización es una táctica claramente obsoleta e inferior ahora que simplemente podemos seguir usando esos prácticos <b> y, caso de llegar a ser necesario, buscarlos y reemplazarlos por fuerza bruta por otra cosa rápidamente

Una cosa al menos he aprendido en los últimos 8 años como empresario por cuenta propia: jamás, en la medida de lo posible hay que tener una empresa de servicios. Quiero decir, empresas donde lo que compra el cliente son horas de mano de obra más o menos especializada.

De hecho, el problema de muchas compañías de software es que piensan que operan con una oferta de manufactura cuando realmente son empresas de servicios. Esto hace que se organice la empresa alrededor de la venta de un producto manufacturado. Cuando en realidad los ingresos acaban entrando por desarrollos y adaptaciones del software estándar que a posteriori hay que mantener totalmente a medida sin ninguna economía de escala.

Cuando oigo a los gurús del Software Libre decir: "¡Hey! Nosotros vamos a hacer dinero con los servicios". Pienso: "¡Locos!" ¿Acaso no se acuerdan de la gran colección de fracasos sonados de empresas de soporte de Linux en los 90? (VA Linux, TurboLinux, Linuxcare, etc.) Prácticamente sólo RedHat y Suse quedaron en pie, excepto Mandriva gracias al chauvinismo francés y Ubuntu por el empeño personal del multimillonario Mark Shuttleworth.

Salvo contadísimas excepciones, la norma es que las empresas de servicios sólo funcionan bien cuando el fundador o fundadores cobran unos tarifas exorbitantes posibles sólo gracias a una excelente reputación profesional y aún así suelen degenerar.

Sinceramente ¿alguien conoce un taller donde realmente se pueda confiar al 100% en los mecánicos? ¿o un restaurante donde los camareros siempre estén atentos y el cocinero nunca queme la comida? Incluso en la gama alta de la cualificación profesional, los arquitectos, por ejemplo, empiezan ganando fama con edificios singulares, y continúan su carrera profesional con proyectos fast track sin propósito urbanístico ni estético claro y encargados sólo para que alguien se forre/se ponga medallas (me refiero a cosas como la Torre Agbar o el Complejo Madrid Arena).

Los problemas de fondo no son muy difíciles de escudriñar:

1º) Aproximadamente la mitad de los trabajadores son vagos y negligentes.
Si. Y me da igual lo que digan los defensores de la motivación laboral y los presutos expertos en recursos humanos. Los sufridos funcionarios llevan la fama, pero no nos engañemos, en el sector privado tampoco es todo el monte orégano. La cantidad de problemas que tienes en una empresa no depende de la carga de trabajo, sino de la cantidad de gente que tienes a tu cargo capaz de pifiarla.

2º) En Europa los salarios son exorbitantemente altos comparados con la productividad.
No es sólo un problema español, y no me lo estoy inventando. Aunque las economías crecen (más o menos) el PIB per cápita cada año va a menos, porque cada individuo genera un aumento mayor de gasto que lo produce.

3º) Los clientes son fastidiosamente roñosos a la hora de pagar por mano de obra.
Si se trata de venderles una casa, o un coche, o cualquier cosa tangible, entonces es más fácil que paguen. Pero cobrar por valor añadido intangible es dificilísimo. Tengo una amiga que trabaja como asesora de exportación. Quien pidió a una empresa de muebles 150€ al día por acompañarles 20 días de gira por China a buscar proveedores. O sea, una ganga. Cuando les pidió, además, un 4% de comisión sobre los acuerdos que pudieren alcanzarse, la empresa le preguntó si pretendía robarles y cancelaron el acuerdo.

4º) La masa salarial es un coste fijo imposible de reducir.
Debido a la rigidez del mercado de trabajo, si viene una época de vacas flacas, aunque sólo sean unos meses, y tienes demasiada mano de obra, lo puedes pasar realmente muy mal.

5º) Gestionar mano de obra es inherentemente complicado.
Yo diría que una empresa es algo muy parecido a una guardería. Que si "fulanito no me ha entregado a tiempo el informe que necesito", que si "menganito le ha dicho al cliente pichiiflú y la ha liado", "que si zutanito se ha cogido el sitio de la ventana sin avisar", que si "perentanito se pasa el día en la sala de café". De verdad que son como niños.

6º) Los clientes no tienen cultura de gestión.
Una de las razones principales por las que se subcontratan proyectos tecnológicos no es porque el cliente no pueda hacerlos él mismo. Sino porque no desea enfrentarse al marrón de la gestión de recursos humanos. Muchas consultoras de tecnología son en realidad ETTs encubiertas que funcionan como pistoleros haciendo el trabajo sucio de contratar y despedir gente que el cliente no quiere hacer actuando en realidad como vías de escape para eludir las regulaciones laborales. La mayoría de los clientes no son conscientes de que detrás de un proveedor de software hay necesariamente personas con nombre y apellidos, y en lugar de ello se comportan como si la empresa proveedora fuese una máquina cibernética impersonal de producción de bytes.

¿Exagero? Quizá. Pero véanse las empresas más exitosas en todos los sectores: IKEA, Zara, McDonald's, Telefónica, Google, etc. Es fácil comprobar que en ellas se ha hecho lo posible por eliminar el factor humano de la ecuación. Ese es el gran logro de empresas como Oracle o Microsoft: que da igual a quién pongan de director de la filial española, porque seguirán vendiendo igual gracias al poder apisonador de su maquinaria de marketing.

Recordar: servicios no, porque a más gente, más problemas.

Esta semana hablámos en Cáceres sobre el papel de lo público en el desarrollo de un tejido productivo de software nacional.
Se notaba cierta decepción acerca de que la apuesta inequívoca que ha hecho la Junta de Extremadura por el Software Libre (casi rozando en lo Talibán en algunos casos) no se ha traducido en la proliferación de nuevas empresas de software. Y se ha quedado, si acaso, en el establecimiento de factorías de software como la que creó Indra en Badajoz en 2004 (ahora con alrededor de 200 empleados) o la de IBM en Cáceres de 2006 (actualmente con 150 y planes de llegar a 500). Cuya misión principal es aprovechar que los salarios en Extremadura son más bajos, y así obtener mejores margenes en las ventas de proyectos a medida para sus grandes cuentas corporativas de toda la vida.

En mi opinión no es que la existencia de dichas factorías de programadores al peso sea en si misma mala, a fin de cuentas es mejor que haya algo (lo que sea) antes que no haya nada de nada. Y el hecho de que algunas personas puedan trabajar como programadores en su tierra natal en lugar de verse forzados a emigrar a Madrid ya es algo positivo.

Lo que sucede es que la idea original no era trabajar reventando precios como los chinos. Sino teóricamente generar puestos de trabajo de alta cualificación y alta renumeración.

Claro que quizá antes de aprender a correr nos toque aprender a andar. Y nuestra travesía por el desierto se la misma de aquellos países, como Japón, que empezaron fabricando clones baratos de productos norteamericanos hasta que desarrollaron el know-how suficiente como para sacar al mercado su propia oferta diferenciada.

No creo que sea competencia de un gobierno regional ocupar el lugar que corresponde a los inversores y empresas privados. Pero si creo que pueden y deben hacer cosas para contribuir al desarrollo de un mercado de Software Libre.

A mi juicio hay un precedente muy bien ilustrado en IDABC:
Building a market for FLOSS: The OSOSS project in the Netherlands

Un proyecto en el cual el gobierno holandés ayuda a dar a conocer las ventajas del Software Libre en ayuntamientos y empresas privadas.

Veamos el siguiente gráfico del II Informe andago sobre el uso de Linux y Software Libre en el entorno corporativo español:

Es decir, la administración pública conoce mucho mejor y tiene más intención de uso de Software Libre que el sector privado.
Entonces ¿porqué no trasladar estas experiencias a las empresas para que aprovechen el conocimento adquirido en la migración a Software Libre dentro de la administración pública?

Esto es más o menos lo que pretende el proyecto OSOSS de los holandeses. Y, de hecho, ya existen iniciativas similares, como el Proyecto Guarà sponsorizado por el Ayuntamiento de Lérida y cuya misión es crear una red de intercambio de experiencias con fuentes abiertas entre municipalidades.

El problema de fondo sigue siendo, sin embargo, la falta de demanda. Indra puede contratar personal en Badajoz porque de todas formas lo necesita para sus clientes como el Sabadell, Aena o el Puerto de Barcelona. Pero es un mercado dominado por las ventas corporativas de gran empresa a gran empresa y vetado a las pequeñas empresas de nueva creación, excepto en los casos en que con gran agilidad e ingenio alguna de ellas consigue meterse en los resquicios de alguna subcontratación y desde ahí crecer un poco.

Es necesario que haya renovación en las empresas.
Veamos esta tabla de la evolución del top 20 del Fortune 500 estadounidense 1987-2007 donde he marcado las que han prevalecido:

Top 20 1987	Top 20 2007
General Motors	Wal-Mart Stores
Exxon Mobil	Exxon Mobil
Ford Motor	General Motors
IBM	Chevron
Mobil	ConocoPhillips
General Electric	General Electric
AT&T	Ford Motor
Texaco	Citigroup
DuPont	Bank of America Corp.
Chevron	American Intl. Group
Chrysler	J.P. Morgan Chase & Co.
Altria Group	Berkshire Hathaway
Amoco	Verizon Communications
Nabisco Group Holdings	Hewlett-Packard
Shell Oil	IBM
Boeing	Valero Energy
United Technologies	Home Depot
Procter & Gamble	McKesson
Occidental Petroleum	Cardinal Health
Atlantic Richfield	Morgan Stanley

De modo que el 70% de las empresas de cabeza americanas pierden su liderazgo en un plazo de 20 años.

¿Y qué sucede en España? Pues que excepciones aparte tipo Inditex, los rankings están copados sempiternamente por los mismos: los bancos, BSCH, BBVA, La Caixa, y las empresas de suministros básicos, Telefónica, Endesa, Repsol, Iberdrola, Gas Natural... Los ciclos económicos hacen cada cierto tiempo multimillonarios a los constructores. Pero a la postre siempre son prácticamente los mismos. No hay renovación ni presión competitiva. Las grandes empresas españolas viven cómodamente instaladas en oligopolios cobradores de recibos mensuales y les importa un bledo innovar porque con lo que se forran es con las plusvalías de la compra y venta de otras empresas.

La administración puede jugar la baza de fomentar que quien tenga una idea y esté dispuesto a luchar por ella tenga una oportunidad real de crecer hasta alcanzar la masa crítica de una gran empresa generadora de empleo y riqueza. Cosa que actualmente, poceros aparte, la mayoría de las veces, no pasa.

Hace tiempo que creo que el gusto por las tendencias zen en el diseño moderno se debe a la necesidad de compensar en lo estético la complejidad creciente del mundo actual.
Lo mismo que las épocas de escasez favorecieron el gusto por las formas voluptuosas y barrocas, en nuestro tiempo buscamos en la apariencia de las cosas algo que nos proporcione la ilusión de que podemos aún aprehender la esencia de las cosas sin morir ahogados en una miriada de inter-relaciones y detalles.

De entre las lecturas de este verano, he decidido traerme al blog en primer lugar Las leyes de la simplicidad de Jhon Maeda. Un profesor del M.I.T. que nos ofrece en un libro breve y conciso (gracias Jhon) unas pocas gotas destiladas sobre qué hace a las cosas aparentemente simples.

Una de los conceptos del libro que me ha llamado la antención es que, si bien la gente tiene tendencia a preferir los diseños simples sobre los complejos, una vez que el diseño se ha simplificado hasta el máximo, entonces los propios usuarios lo complican para añadirle una carga emocional. Es el caso de los accesorios y complementos que se venden para personalizar gadgets como el iPod o los teléfonos móviles.

Siempre me ha molestado un poco la tendencia excesiva de Microsoft a implementar a pies juntillas los preceptos de las leyes de la simplicidad. Por ejemplo, una ley conocida desde hace mucho dice que cuantas menos opciones tenga a su disposición, menos confuso se sentirá el usuario. En los mandos a distancia, por ejemplo, dicha ley se aplica introduciendo tapas que ocultan los botones menos usados. El problema de Microsoft es que tiene la sana costumbre de esconderte las opciones de menú, los iconos y, en general, todo aquello que está en el producto porque tiene que haber de todo pero que ellos piensan que no vas a realmente a utilizar.

Me pregunto si en parte ha pasado lo mismo con Linux, que los usuarios han vestido la simplicidad del producto de una carga emocional que ninguna empresa puede añadir.

Me quito el sombrero por las ideas de Apple, quienes, tras lograr un diseño de iPod casi transparente, añadiron la opción de que le agregases tus emociones grabando una frase en el reverso del aparato.

Está claro ya desde hace tiempo que la siguiente gran era del marketing no será ganar la cabeza de las personas sino ganar sus corazones. Y en ese terreno los partidarios del Software Libre, no perderemos nunca batalla alguna.

Comentario de Xabi del Rey:

Me ha encantado Las leyes de la simplicidad. Siempre he tenido tendencia a la simplificación y me ha parecido que en general en occidente tenemos esa mala costumbre de complicarnos la vida. En agosto he viajado a Japón, donde he podido conocer una cultura totalmente diferente. Bueno, el caso es que afectado probablemente por las ideas que me he encontrado allí, el zen, por ejemplo, he retomado esa predilección por la simplicidad. encontré el libro en una librería por casualidad y fue una necesidad comprarlo :P

El libro es un primer intento, a mi entender, de poner unas pautas al proceso de simplificación y a la simplicidad en sí misma, sin embargo, y es la crítica que quería hacer del libro en el blog a modo de comentario, he visto la necesidad de leer el libro en inglés debido a la traducción al español... supongo que habrás visitado lawsofsimplicity.com, y te habrás dado cuenta de que merecerá la pena leer a John Maeda en inglés.

xabierdelrey.wordpress.com

Fuente: Jay Garmon, Geekend

Joris Evers informa en c|net que el Departamento de Transporte (DOT) y el Instituto Nacional de Estándares y Tecnología (NIST) estadounidenses mencionan el miedo a los problemas de compatibilidad como una de sus razones para no migrar a sus decenas de miles de empleados de Windows XP a Vista.

Según el memorándum presentado por el DOT el pasado 19 de enero:

No parece haber ninguna razón razón técnica o de negocio para actualizarse a estos nuevos productos de Microsoft.

Creo que muchas veces el desarrollo de un software nace desde la incompresión. Estás en tu empresa llena de burocraria y meritócratas poco eficaces, ves como se pierde el tiempo - sobretodo el tuyo - y en esta espiral estás cuando dices:

"Estoy harto. Voy a hacer este software de una vez bien, aunque sea para darme el gusto".... "Y además va a ser software libre para que se j...."

No tengo datos estadísticos sobre cuántos nacen así, ni cuán pocos de los que nacen llegan a algo, pero sospecho que algo de peso si tiene.

El hecho de que las grandes corporaciones sigan sin pillarle el tranquillo a desarrollar software como quien produce prendas o tuercas, unido a una torpeza empresarial que no tiene como objetivo número uno incentivar a los artesanos del software, genera frustraciones para una creatividad que finalmente vierte en movimientos con el del Software Libre.

De hecho, Windows Vista puede ser una razón decisiva para pasarse a usar Ubuntu y la colección de software libre que lo acompaña (OpenOffice, etc). Que Ubuntu y otros Linux puedan ser usados en "el hogar" y se instale y use de forma cada vez más fácil ayuda mucho, y que las requisitos de Vista estén forzando a la gente a comprarse un nuevo PC o portátil, ayuda más.

¿Nos enfrentamos a una explosión de Linux es los Desktops que realimentará y dará solidez a la entrada en más áreas del Software Libre?

Efectivamente señoras y señores. Cuando no hay manera de encontrar los "drivers" para ese dispositivo en nuestro linux, hasta ahora la solución era: "Haztelos tú mismo". Ahora hay otra opción.

Claro, ese háztelo, suponía bucear largos ratos entre los ejemplos del Linux Device Driver Kit, o entre el árbol de fuentes del kernel, buscando el ejemplo más similar al tuyo.

A partir de ya, la Comunidad del Kernel del Linux, ofrece a todas las empresas desarrollarles los drivers para sus dispositivos de forma gratuita. Esto es lo que anuncia Greg Kroah-Hartman en su blog.

Lo único que se pide es el contacto de un ingeniero para poder responder a las preguntas de los desarrolladores de la comunidad que se encargen de tu controlador.

Citando de dicha entrada:

A cambio recibirás un controlador integrado con el kernel de Linux. Se distribuirá con el kernel y seguirá funcionando con los cambios que se hagan al API, y se ejecutará correctamente en las diferentes CPUs en las que funciona actualmente Linux, que es el sistema operativo que corre en más procesadores de la historia de la computación.

Respecto al soporte, habrá soporte directo a través del correo electrónico de los desarrolladores que lo han hecho.

Así tus programadores podrán dedicar más tiempo a desarrollar "drivers" para los demás sistemas operativos, y podrás poner en tu producto "Soportado en Linux".

Así se las ponían a Felipe II. A veces aplica más dar peces que enseñar a pescar...

Vía: Linux-Watch: Device Drivers for Free

Novell anunció la salida de SuSe Linux Enterprise Desktop 10 como un sistema operativo orientado al usuario poco técnico. Un sistema operativo robusto y además bonito y fácil de instalar y utilizar.

Ahora Novell lo está promocionando como la alternativa lógica y convincente a Windows Vista.

Cito de su web:

Cuando lo que necesitas es una alternativa a MS Windows, preparada para el mundo empresarial y con unos costes asumibles, considera Suse Linux...
Menores costes: Recibirás más del 90% de la funcionalidad de Vista y MS-Office por menos del 10% del coste.
Seguridad Reforzada: Usa la plataforma más segura del mercado [aquí no hacen todo el daño que podrían ;) ]....

Mucho han dado que hablar los últimos acuerdos entre Novell y Microsoft.

Una de las diferencias entre el mundo académico y el laboral es que en las universidades (al menos las españolas) existe un re-gusto casi mórbido por lo complejo. Mientras que en el trabajo cotidiano sucede justo lo contrario: las cosas están pensadas para ser fáciles, de otro modo, y teniendo en cuenta el porcentaje de gente lerda que existe, no se podrían desempeñar las adecuadamente tareas diarias.

¿A alguien le suena la regla del 3-4-5? La usan los obreros para hacer ángulos rectos. 3²+4²=5² y así pueden evitar usar el teorema de Pitágoras directamente.

Por desgracia, cuando algunas cosas se vuelven demasiado fáciles, surgen problemas. Ejemplos de cosas demasiado fáciles hay muchos:

• Endeudarse
• Comprar tabaco
• Ir al médico
• Presentarse como candidato político
• Llamar a un teléfono móvil
• Escribir un e-mail
• Abrir un blog
• Hacer un cambio en un programa
• etc. etc.

¿Qué tiene de malo que escribir un e-mail sea demasiado fácil? Pues sencillamente que la gente abusa de correo electrónico (y no sólo con SPAM) lo mismo que del teléfono móvil, que es la herramienta más perversa de robo de tiempo ajeno que ha inventado la humanidad.

Algo similar pasa con los blogs, se están creando a un ritmo de 100.000 al día. Lo cual degrada la calidad media de la blogosfera. Hasta hace poco tener un blog era lo más supercool y supermoderno, incluso se siguen haciendo rankings de "blogs influyentes", dentro de poco el blog será la bitácora del vulgo más contaminada y tergiversada que informativa.

Y por último, por la parte que me toca, odio los lenguajes de scripting y todas las herramientas de desarrollo rápido que sólo nos han traído la filosofía de "Paco esto tenlo listo para mañana". Programar en ensamblador con 16Kb y programas re-entrantes era igual de divertido que hacerlo en Rails o en lo que toque ahora, y, al menos, los clientes no asumían que el software es algo así como las setas, que crece en el servidor por la noche y está listo para hacer un guiso en la mañana.

• Si fuese ilegal dar créditos a más de 15 años la gente no estaría tan endeudada.
• Si fuese estuviese prohibido vender tabaco fuera de los estancos la gente fumaría menos.
• Si hubiese que pagar una franquicia de 1€ por cada visita al médico, las urgencias no estarían colapsadas.
• Si hubiese que aprobar oposiciones a político la mayoría de los actuales estarían en la cola del paro.
• Si escribir un e-mail costase un céntimo no habría spam.
• Si hubiese que documentar por anticipado cada cambio que se hace en un programa y pasar la documentación por un registro, la gente se tomaría la informática mucho más en serio.

La simplicidad consiste en conseguir el máximo efecto con el mínimo de medios
Koichi Kawana

Garr Reynolds, publica en Presentation Zen (mi sitio favorito de consejos sobre presentaciones en público) una comparativa de los estilos visuales de Steve Jobs y Bill Gates.

Reynolds argumenta que el "estilo Microsoft" de presentaciones, usado por otros directivos de Microsoft aparte de Gates, tiene tendencia a sobrecargar las presentaciones con elementos innecesarios.

Bill Gates representa en sus PowerPoints la quintaesencia de la filosofía occidental de tener muchas cosas. Steve Jobs, que pasó un tiempo en su adolescencia imbuyéndose en la culturas hindú y budista hasta el punto de practicar la mendicidad, tiene un "estilo zen" muy diferente al de Gates, que se fundamenta en:

• Simplicidad
• Sutileza
• Elegancia
• Sugestivo antes que descriptivo u obvio
• Espacio vacio (o espacio negativo)
• Sosiego, tranquilidad.
• Eliminación de lo no-esencial.

Por cierto que en el mismo blog se puede encontrar otro post comentando cómo sería una presentación PowerPoint de Darth Vader.

Una línea estética que asocio, no sé porqué, con la que ha empleado Microsoft este año en el pabellón 2 de SIMO TCI 2006, con pantallas retroiluminadas y menos luz que los otros pabellones.

Fuente: Luther Blissett Flickr

Parece ser que lo más simple es más efectivo. O, como dicen en jerga zen, el aspecto de "desnudez visual".

La excelencia empresarial es factible en cualquier circunstancia. No es imprescindible ser una multinacional, ni andar con estándares estilo ISO 9000 o Seis Sigma para hacer las cosas bien.

La excelencia empieza por el ambiente en el que viven inmersos los asalariados. Siempre he sido contrario a permitir que los empleados vayan desaliñados a la oficina, en la creencia de que la misma desidia vital acaba afectando a la forma en la que hacen su trabajo.

En una ocasión oí a Silvio Berlusconi decirle a uno de sus asesores de imagen que estaba muy molesto por un pequeño detalle. El motivo, le explicó, es que el 90% de lo que hacía el asesor podía hacerlo igualmente bien CUALQUIER otro asesor. El bueno de Silvio le explicó sucintamente que no le estaba pagando una cantidad obscena de dinero por el 90% sino precisamente por el otro 10%.

En una era donde los programadores viven diariamente presionados para cumplir "el 80% de los requisitos con un 20% del esfuerzo" el resultado es amenudo productos a caballo entre un mierda y una mierda como una casa de doce pisos.

Para muestra de lo anterior, vale la pena ver estas sorprendentes (aunque no deberían serlo tanto) fotografías de una fábrica de Mercedes Benz en Alemania.

Fábrica de Mercedes (PowerPoint)

Fábrica de Mercedes (OpenDocument)

Comentario de Ismael Olea: No son realmente de una fábrica de Mercedes, sino de McLaren (participada a su vez por la Daimler-Chrysler, claro). http://images.google.com/images?q=mclaren factory&ie=UTF-8&oe=UTF-8&sa=N&tab=wi

Jay Lyman publica en el artículo Putting Open Source Development Under the Scope los consejos de Josh Berkus, miembro del equipo core de PostgreSQL entre los cuales cuenta que la forma más eficaz de aumentar la productividad de los programadores es reducir el número de reuniones necesarias.

En un entorno grande de desarrollo de software propietario, los ingenieros pasan de 4 a 9 horas a la semana en reuniones, donde sus jefes se les asignan tareas y se espera que trabajen en ellas durante la próxima semana. Las responsabilidades de cada uno se delimitan cuidadosamente y se establecen controles de calidad y procesos obligatorios de revisión. El resultado de todo esto es que se marca a los desarrolladores el ritmo de paso lento de los gerentes de manera que estos últimos puedan mantener el control del proyecto en todo momento.

Yo he estado en reuniones de nunca acabar donde había 6 ó 7 consultores cobrando cada uno 75€ la hora. Los clientes a veces discuten el coste del desarrollo externalizado sin darse cuenta de la enorme cantidad de tiempo que se pierde en consultoría reuniéndose y haciendo informes.

En general, la cantidad de gente que asiste a una reunión es inversamente proporcional a la efectividad de la misma. Las mas improductivas son las reuniones donde todo el mundo opina pero no se decide nunca nada, y al final, son puramente informativas.

Javier Benjumea, presidente de Abengoa, comentaba esta mañana en en-code que en su empresa creen que la investigación y la ciencia son cosas más bien del sector público, y que a ellos lo que les interesa realmente es la innovación, en cuanto a puesta en práctica de una idea que sea monetarizable.

Javier contaba que la clave son los "proyectos demo" en los cuales se puede comprobar empíricamente si una idea teórica funciona en la práctica. Indirectamente aludía a los adoptadores tempranos de los que Goeffrey A. Moore habla en su libro Crossing the Chasm, un texto que ningún emprendedor tecnológico debería dejar de leer.

La dificultad principal para el emprendedor estriba en ganar credibilidad ni tan siquiera para que le den oportunidad para una demo. Según cuenta Benjumea, Abengoa ha realizado un proyecto piloto en Nebraska para la conversión de biomasa en energía ¿Porqué en Nebraska y no en Andalucía? En mi opinión, sencillamente porque en EE.UU. están más dispuestos a correr riesgos que en España.

Minutos más tarde, hablaba con un responsable de compras públicas quien me comentaba que habían solicitado siete (7) prototipos para un proyecto software. "¡Hombre!", me decía, "esto no se ha hecho nunca antes, y no podemos correr riesgos, o bien nos traen referencias de algún sitio donde se ha puesto en práctica antes, o bien nos demuestran al 100% que funciona antes de comprarlo". Lo cual implica que seis de los siete ofertantes del proyecto van de convidados de piedra. Esto tiene un coste brutal para los proveedores.

No hay que perder de vista que en Extremadura y Andalucía el Software Libre fue una apuesta, y una apuesta valiente, que está demostrando sus frutos.

Antonio Luque, director del Instituto de Energía Solar de la UPM y fundador, entre otros, de Isofotón, me contaba durante la comida que la ventaja actual de los proveedores de energía solar es que son empresas innovadoras, si, pero en realidad, lo que sucede es que la demanda excede la oferta, y eso hace que sea fácil vender, incluso teniendo en cuenta que la energía solar es varias veces más cara (por ahora) que la basada en combustibles fósiles.

Dicen que donde las personas ven problemas, los emprendedores ven oportunidades. Cualquier cambio supone un riesgo, o una oportunidad, según se mire. Poniendo como prioritario el objetivo de minimizar el riesgo no se progresa, sólo se perpuetua el dicho aquel de "más vale malo conocido que bueno por conocer".

Inspirado el post Discovery de Seth Godin que parafraseo a continuación:

Cada persona que se topa con tu organización por primera vez viene con la mente en blanco. No sabe nada de tu pasado, ni de cuán duro tuviste que trabajar, ni cuanto dinero te costó financiarte. Dicha persona sólo está aquí ahora.

He oído centenares de ingenieros hablar de lo que puede hacer su software. Pero a muy pocos de ellos hablar de la impresión que causa. Los proyectos exitosos están basados en primeras impresiones. Como SugarCRM y Alfresco y muchos otros que tienen muy buena pinta, y luego no son para tanto.

Se me olvidaba la respuesta obvia de Bill al requerimiento de Guy J Kewney.

Estimado Sr. Kewney:

He recibido su solicitud de 1.200 libras esterlinas en concepto de gastos administrativos y de consultoría imputables a Microsoft. Lamento las inconveniencias que nuestro software haya podido causarle. No obstante, le recuedo que la licencia de uso, de la cual usted tiene una copia, establece cláramente que bajo ninguna circunstancia Microsoft será responsable por una cantidad mayor a la que usted pago por su sistema operativo, en su caso un máximo de 59,99 dólares.

Buenísimo el post Dear Sir Bill Gates; invoice enclosed. Prompt payment is expected... de Guy J Kewney en el blog de newswireless.net.

No me gusta mucho dedicarme al copy/paste avanzado ni a re-freir noticias (para eso están los feeds) pero este creo que vale la pena traducirlo.

Actualización: se me olvidaba la respuesta obvia de Microsoft a esta carta.

Vale la pena leer la historia de Joel Spolsky sobre su primera reunión con Bill Gates para decidir sobre la introducción de VisualBASIC en Excel.

Me trae a la cabeza ciertas ideas :

• Una de las claves de la genialidad estriba en percatarse de cómo lo macroscópico se relaciona con lo microscópico.

• No es la visión, sino el trabajo concienzudo a nivel de detalle, lo que le ha traido a Bill Gates su fortuna.

• Si tienes que lidiar con un programador (o quien sea) que se cree un sabiondo, hazle preguntas hasta agotarle. Prepara la ofensiva, y pregúntale sin tregua ni descanso, eventualmente llegará a un punto en el que tendrá que reconocer que hay algo importante que no sabe.

• Sea cual sea la jerarquía de tu empresa, nunca pierdas el contacto directo con el nivel operativo.

• Los Masters MBA, NBA y Del Universo están bien. Pero al final del día mejor si sabes realmente de qué va lo que tienes entre manos.

José Luis Marina, director de I+D de Peopleware me ha pasado una referencia al post del blog de Bernard Golden en CIO Open Source at the Heart of the Enterprise en el cual comenta la perspectiva de Adam Joffe sobre el uso de Software Libre en EverQuest de Sony Online Entertainment.

Mi amigo Andreu Ibáñez de Internet Web Serveis me recomendó la comedia The IT Crowd del Channel 4. Es toda una experiencia freakie y una buena oportunidad para desternillarse de la risa practicando inglés británico que se entiende bastante bien. Impresionantes las camisetas, los ordenatas de los 80 y los gizmos que hay en el sótano de los nerds informáticos.

Hay previews en YouTube, y se pueden descargar los capítulos fácilmente con eMule.

ringsakira envía a menéame unos pantallazos de la instalación de Ubuntu Dapper Drake β desde el Live CD.

No sé si realmente Ubuntu será más fácil de instalar que Windows.

Pero desde luego la instalación de la nueva beta de Ubuntu tiene pinta de ser muy muy fácil.

Joel Spolsky se queja en su post Too Many Ajax Calendars de que a pesar de la proliferación de nuevos calendarios fashion basados en AJAX, no encuentra ninguno que cubra bien sus necesidades.

A decir verdad son unos requisitos bastante particulares para vuelos aéreos.

Pero creo que es un ejemplo de una célebre frase relacionada con el Software Libre muy poco afortunada: release often, release soon

Estamos saturados de software a medio terminar. Y esto no hace ningún bien a la reputación del Software Libre.

Tenemos que aplicarnos la regla: release on time, release stable

Que es lo que quieren los usuarios: que se cumplan los plazos y que sean satisfechas sus expectativas sobre la calidad del producto recibido.

Creo que esta historía es un buen ejemplo de las consecuencias que acarrean las tácticas basadas en los preceptos obsoletos de la ocultación de los fuentes y la protección anti-copia a ultranza.

La firma Sony BMG Music Entertainment anunció el martes pasado que retiraría del mercado 4,7 millones de rootkit CDs (de los que ya se habían vendido 2,1 millones) afectados por un serio agujero de seguridad en el software anti-copia XCP grave hasta el punto de que el equipo anti-virus de Microsoft decidió detectarlo y eliminarlo mediante sus actualizaciones de seguridad.

Como puede leerse en ZDNet, el componente rootkit del software XCP, desarrollado por la empresa británica First4Internet para Sony BMG para restringir la copia y el intercambio de música, ya era muy controvertido por actuar como potencial puerta de atrás para virus maliciosos.

Por otra parte, el hacker noruego Jon Lech Johansen afirma en su blog So Sue Me que Sony también ha tomado prestado ilícitamente código de FairPlay.

XCP se auto instala en los ordenadores basados en Windows cada vez que el usuario reproduce uno de los 49 CDs protegidos de Sony BMG. El programa fuerza al usuario a usar el reproductor que viene el el CD para escuchar la música.

Según indican las auditorías, el reproductor de First4Internet contiene al menos cinco funcionalidades tomadas de LAME pero sin hacer referencia al origen como exige la licencia LGPL lo cual podría acarrearles un litigio por violación del copyright.

Leer artículos relacionados :
Sony's Copyright Overreach (BusinessWeek online).
El rootkit del DRM de Sony: la verdadera historia (Kriptópolis).
Scotch Tape Stymies Sony Copy Protection (InformationWeek).
Patentar la corrupción de datos (Ricardo Galli).
Todo sobre los rootkits (Fernando de la Cuadra, Baquía).

Via Computer Business Review puede leerse la noticia de que el gobierno del Reino Unido financiará un nuevo laboratorio de Software Libre en Manchester como parte del programa Open Source Academy. Open Source Academy es un paraguas bajo el cual se engloban diversos proyectos de fomento del Software Libre en la administración local.

En la oficina de innovación del primer ministro britanico lo tienen claro: el software libre es mejor para la administración pública. Y han decidido apostar activamente por ello.

La decisión tampoco sale de la nada, ya que el año pasado el gobierno británico comprometió medio millón de libras esterlinas en estudiar la viabilidad del Software Libre para las administraciones locales.

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.

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

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.

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

Regla Nº8 Si lo vas a vender, el producto debe ser una solución completa
Para los usuarios es muy difícil coger un poquito de aquí y otro poquito de hallá y montar su infraestructura tecnológica como si fuese un kit de hágaselo usted mismo. ¿Porqué fueron un éxito de ventas Lotus Notes o Exchange? Pensándolo bien ¿Que alternativas factibles tenían las grandes empresas en su momento para montar GroupWare y Workflow? Sendmail y un puñado de programas pegados no, desde luego.
Si la solución no es completa puede que llegue a hacerse popular, pero será muy difícil ganar dinero con ella. Ese es el caso de JUnit, por ejemplo.

Regla Nº9 Debe percibirse una propuesta de valor tangible para el cliente final.
No sé cuantas veces he oído a un informático que este programa optimiza tal o cual proceso. Pero ¿cual es el valor económico para el cliente? Hay que tener en cuenta que (en general) los clientes están más interesados en conquistar mercados que en reduir costes.

Regla Nº10 Debe haber un modelo de negocio para los intermediarios.
Es prácticamente imposible llevar a buen término ninguna misión sin la ayuda de otros. En el caso de Open Source uno de los problemas abiertos es el modelo de negocio para los resellers. Cuando se vendían cajas era muy fácil, porque bastaba con ofrecer una comisión sobre ventas al minorista, pero ¿qué sucede cuando el producto es gratuito? Recientemente el incremento de la demanda de Open Source por parte de las administraciones públicas ha despertado el interés de las consultoras por este tipo de soluciones, que, hasta la fecha, había sido más bien escaso ante la (aparente) ausencia de ingresos sustanciosos.

Regla Nº11 Debe ser más barato de adoptar que de fabricar.
Si el producto es demasiado pequeño o demasiado difícil puede que al cliente le compense más hacérselo él mismo que superar la curva de aprendizaje.

Regla Nº12 Debe dirigirse al nicho de mercado adecuado.
No todos los sectores se adaptan igualmente bien a Open Source. Y, de los que se adaptan, algunos pueden estar demasiado copados como para que resulte interesante entrar.
Preferentemente debe ser un nicho lo más horizontal posible, porque en los nichos verticales las soluciones tienden a tener que adaptarse en exceso a las necesidades de cada cliente dificultando enormemente la reutilización de código.
Una trampa habitual es empezar pensando que se fabrica un producto y terminar con 6 ó 7 ramas de código diferentes e incompatibles a la medida de cada cliente vaca.

Regla Nº13 Debe contar con el respaldo de otros fabricantes.
El respaldo de los OEM y de las grandes empresas importa. Es por ello que es mejor desarrollar en Java o Mono que en otros lenguajes, se puede contar con (al menos) la simpatía de Sun, IBM o Novell. Excepción hecha de PHP que es por si mismo terriblemente popular.

Regla Nº14 El ámbito de alcance debe ser lo más global posible.
Salvo que vivas en EE.UU. tu mercado local es probablemente demasiado pequeño para soportar los costes de I+D.

Ver la primera parte de esta serie: Fundamentos.

¿Has pensado alguna vez en iniciar tu propio proyecto Open Source?
¿Lo empezaste pero consigió ganar la masa crítica que esperabas?
Una de las críticas frecuentes que se hacen a Open Source es que existen demasiados proyectos. Quizá es excesivamente fácil empezar un programa sin tener ningún plan claro acerca de su viabilidad.
En esta mini serie doy algunas claves acerca de cómo diseñar, implementar y promocionar un proyecto open source para que sea popular y rentable.

He dividido los contenidos en 4 artículos:
- Fundamentos
- Mejores prácticas
- Trampas a evitar
- Publicidad, promoción y ventas

Regla Nº1: Los buenos programas empiezan por resolver una necesidad de la persona que los creó.
Pregúntate a ti mismo ¿mi propio software en realmente útil para mi mismo? Si la respuesta es afirmativa has empezado por el buen camino. Si ni tú mismo usas tu propio software, es probable que tampoco le interese a nadie más.

Regla Nº2: Los programas populares resuelven los problemas de mucha gente.
Aunque el programa sea realmente bueno, si sólo resuelve los problemas de una minoría de personas, es probable que nunca adquiera una gran notoriedad. Es la diferencia entre fabricar un compilador y fabricar un compresor estilo WinZIP. Hay una cantidad razonable de gente que necesita compilar pero hay una cantidad mucho mayor que necesita comprimir algo para poder enviarlo.
Dsde luego inventar un algoritmo para la nueva generación de internet semántica puede ser muy divertido (y si te lo compra Google también muy rentable) pero es más probable que el publico en general se interese por algo estilo eMule. Por eso los proyectos como GNOME son tan populares, porque todo el mundo necesita un escritorio.

Regla Nº3: Es igualmente importante el tamaño del mercado que cuanta competencia está entrando.
Es por ello que quizá no es tan buena idea fabricar en solitario otra distro de Linux u otro compresor.
Cuanto mayor sea el target el producto, mayor la probabilidad de que una gran empresa ponga su ojo sobre dicho trozo de la tarta. Como las batallas por los reproductores multimedia.

Regla Nº4: El factor de innovación es relevante.
Los usuarios no cambian de una tecnología a otra sólo porque aporte pequeñas mejoras. Debe haber un salto cualitativo real para que se produzca una migración de una aplicación a otra. Un ejemplo es el tabbed browsing de Mozilla, es una mejora de usabilidad bastante útil, pero, en si misma no justificaría la existencia de un nuevo navegador. Es por este motivo que Opera languidece, el navegador es bueno, pero, a la postre no hay tanta casi diferencia con Internet Explorer.

Regla Nº5: Se escriben progamas para un mercado, no para un concurso.
Sólo hay básicamente 3 plataformas para desarrollar un proyecto orientado a consumo masivo: PHP, .NET (Mono) o Java.
Si escribes tu programa en algo más exótico que eso tienes un 99% de probabilidades de que no progrese mucho.
Programar para el mercado también implica a veces hacer algunos sacrificios en el purismo del diseño.
El noventa y pico por ciento de los usuario [aún] tienen Internet Explorer, de modo que desarrollar sólo teniendo en cuenta los navegadores libres no es una muy buena idea.

Regla Nº6: Todos los grandes programas nacen de otro pequeño.
Los usuarios buscan killer applications, programas que hacen una única cosa muy bien: ya sea comprimir, mandar mail o bloggear.
Poner toneladas y toneladas de funcionalidades mediocres extra no mejora el producto, sólo lo complica y lo hace más difícil de mantener.

Regla Nº7: Hay que desarrollar para la economía globalizada.
Es más probable captar el primer cliente en Marruecos que en EE.UU.
Si, ya se, EE.UU. es la meca del software y África es el tercer mundo.
Pero es poco probable que te inviten a entrar por la puerta grande en Boeing o en McDonnell-Douglas. En cambio es posible que encuentres un mercado desabastecido en el sur, siempre y cuando diseñases tu software para soportar Unicode y escritura de derecha a izquierda, claro.

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

Según declaraciones de Debra Anderson (CIO) a ComputerWire, Novell planea tener el 100% de sus PCs con arranque dual Linux/Windows y el 80% sólo con Linux para finales de este año.

El plan implica la migración de 6.000 puestos de trabajo. Con un ahorra, según Anderson, de 900.000 dólares, o $150 por puesto, que es más o menos lo que les cuestan las licencias de Microsoft.

Es interesante la parte del artículo donde la directora de informática de Novell da a entender que la migración es más una maniobra destinada a obtener experiencia sobre el proceso de migración que una táctica para reducir costes y aumentar la productividad.
Así no llegamos a ninguna parte. Si resulta que los procesos de migración se justifican como quien hace experimentos con la gaseosa, no va a ser posible convencer a ningún cliente conservador de que migren sus escritorios Microsoft.

Hace un par de meses comentamos sobre los ahorros que había supuesto para un centro médico estadounidense la implantación de Thin Clients. Con ocasión de una reciente presentación de su caso práctico en Canadá, los doctores encargardos del centro médico han publicado sus experiencias prácticas, con un detallado análisis financiero de la implantación, así como de las lecciones aprendidas, entre ellas un ahorro de un 37% en los primeros ocho años. Buen informe para conocer más de los costes de implantacion de los thin clients., como esta
experiencia hindú sobre otra implantación de thin clients.

Excelente post post de Juantomas sobre cómo abrir el ordenador con un sistema de PXs en menos de siete segundos.

Mi secretaria cuando tiene que abrir un documento OO tarda 7 seg en hacer el login , cargar gnome y abrir el OO por supuesto incluyendo el tiempo que necesita para meter su usuario y su password. Su ordenador es un pentium II a 266 Mhz con una tarjeta de video cutre y una conexión de red a 10Mb. En total tiene 64Mb de memoria.

Como parece ciencia ficción he grabado un video absolutamente vietnamita para dar envidia a todos los que siguen sufriendo esperando a que se inicie su ordenador, se habra su procesador de textos y puedan empezar a escribir. La tecnología está disponible y madura hace mucho tiempo pero ya se sabe es cuestión de escoger adecuadamente el color de la pastilla. Enviado por aromeo a las 05:17 PM | Comentarios (0) | Permalink

Para el día 30 de junio esta previsto que todos los puestos de trabajo de Novell en todo el mundo estén migrados a software libre. Esta es una de las muestras que Novell apuesta por el software libre de verdad y una prueba más de que es absolutamente viable migrar a linux en el desktop.

En la pastilla roja estamos haciendo una recopilación de información sobre migraciones a software libre. Queremos hacer un informe sobre como se realizan las migraciones, como se solucionan los problemas y sobre todo tener información sobre los costes y el grado de satisfacción de los usuarios. Nos interesan todo tipo de migraciones: pequeñas/grandes, mixtas/100% software libre.

Informe de Alfredo Romeo sobre las características que tendrán las comunidades de software libre en el futuro a corto-medio plazo, tras la expansión del conocimiento del software libre a todos los estratos de la sociedad. Septiembre 2003.

Descargar documento en pdf.

Extenso informe del International Institute of Infonomics sobre el software libre cubriendo las principales áreas de interés: uso, motivaciones, tecnologías, modelos de negocio, etc. Junio 2002.

Descargar documento en pdf.

Acabamos de inagurar la sección de casos práticos sobre implantaciones de tecnologías libres en el mundo así como informes que merezca la pena mantener. Desde Informes de implantación, pasando a informes de penetración de mercado, mantendremos aqui un repositorio de los mismos. Esperemos que los disfruteis