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.

Hispalinux ante la inminente y escasamente debatida anteproyecto para la reforma de la ley de la propiedad intelectual ha emitido un comunicado expresando su preocupación por la falta expresa de sensibilidad con la sociedad del conocimiento.

El texto integro del comunicado esta en la web de Hispalinux y lo transcribo a continuación:

Postura de Hispalinux ante el anteproyecto de reforma de la Ley de Propiedad Intelectual.

Hispalinux quiere mostrar su honda preocupación ante el anteproyecto de reforma de la Ley de Propiedad Intelectual que el Ministerio de Cultura y las Sociedades de Gestión colectiva de Derechos de Autor se proponen llevar a cabo.

Dicho anteproyecto podría suponer un serio menoscabo al avance hacia una Sociedad del Conocimiento Libre, sustituyendo la posibilidad de alcanzar una sociedad plural y rica en contenidos de calidad, por otra donde el acceso, uso y propagación de los contenidos artisticos, cientificos ,culturales, intelectuales y tecnológicos esté regido exclusivamente por meros reglas mercantilistas y sometido, mediante rígidos controles en manos de unos pocos, a exclusivos intereses comerciales.

Hispalinux muestra su preocupación ante la redacción final que podrían tener algunos de los artículos de dicha ley ya que podrían cercenar derechos elementales, como por ejemplo el 138, 139, 141, donde se especifica que "se podran adoptar medidas cautelares", consistententes en suspensión de servicio y secuestro de material, "contra los intermediarios a cuyos servicios recurra un tercero" ... "aunque los actos de dicho intermediario no constituyan en si mismo una infracción"

El Articulo 107 establece que los derechos de remuneración por comunicación pública seran establecidos, gestionados y repartidos exclusivamente por las entidades de gestión de propiedad intelectual lo que podría suponer en la práctica que el acceso al patrimonio cultural quedaran en manos de entidades privadas y que éstas se convirtieran en “monopolios de facto” que determinaran el acceso al Conocimiento cuando es precisamente el Ministerio de Cultura el responsable de garantizar a todos los ciudadanos el acceso a la cultura, como establece nuestra Carta Magna.

El articulo 160 criminaliza la investigación tecnológica bajo la premisa de que la mera posesión de tecnología "que pudiera servir para eludir medidas de protección" es constitutiva de delito y ya que cuando hablamos de tecnología digital indefectiblemente estamos hablando de Software nos preocupa en realidad se esten dando pasos para convertir la programación de ordenadores en delito.

Por otro lado esta reforma no acomete el problema del llamado "canon del CDROM" (pago compensatorio por el ejercicio del derecho de copia privada por parte de los consumidores), que podría ser ampliado a otros soportes e infraestructuras digitales como lineas ADSL, Ordenadores, DVD, TDT, etc. Hispalinux considera que dicha compensación no debe aplicarse a los recursos digitales indiscriminadamente sino que debe establecerse, si es el caso, como % del PVP de los originales distribuidos y debe percibirse directamente por el autor.

Estamos asistiendo a un cambio de era, donde el conocimiento se puede usar, copiar, modificar y redistribuir con unos costes despreciables (comparados con los de la era analógica). Ello conlleva nuevas formas de relación humana y también nuevas actividades sociales y de intercambio de información y conocimiento.

Hispalinux cree que es necesaria una profunda reformulación de la legislación para que el conocimiento y la prosperidad se democraticen y alcancen a todo el mundo.

Los programas de ordenador establecen hoy "las formulas" que rigen nuestras vida diaria y se encuentran ubicados dentro de la Ley de Propiedad Intelectual tanto en su forma de "código fuente" (ordenes inteligibles por el ser humano) como en su forma de "código objeto" (transformación de esas ordenes a lenguaje binario para que sea ejecutable por una máquina). Es paradógico que la LPI ampare articulos ininteligibles para el ser humano cuando su finalidad es precisamente estimular la creacción asegurandose de que el conococimiento queda a disposición de la sociedad.

Por ello instamos al Gobierno y a todas las fuerzas politicas a que tomen en consideración que la "propiedad intelectual" no es un fin en si mismo ni en realidad una forma de propiedad sino aquello que le es propio y consustancial al ser humano (Suidad Intelectual [*]) y que el hecho de que a lo largo de la historia no se haya podido impedir usar el conocimiento aportado por los demás, copiarlo, modificarlo y redistribuirlo ha sido precisamente lo que ha permitido el avance de la Humanidad. Esa es la esencia de la "propiedad intelectual" en la era digital, e intentar regularlo de la misma manera que se hacía en la era analógica no facilitará el reparto de riqueza, sino que podría suponer un impedimento a la creación y la innovación; y podría poner en peligro el futuro de las nuevas generaciones y nuestro propio presente.

[*] Juan de Lugo Disputatiorum de iustitia et iure (1642)

Via O'Reilly OnDotNet puede leerse una interesante entrevista a Miguel de Icaza acerca de Mono.
Mono aún debe terminar de madurar, pero cubre un hueco muy importante en el ecosistema Linux.
Cuando abandonamos VisualBASIC para programar en PHP y JSP ganamos las aplicaciones web, pero perdimos la posibilidad de desarrollar programas cliente/servidor tan fácilmente como era posible con VisualStudio.
Ningún entorno de programación basado en Java o en otro lenguaje a logrado hasta ahora ofrecer la misma potencia y usabilidad para clientes pesados que las herramientas de Microsoft. Es por eso que Mono supone una gran promesa.
http://www.ondotnet.com/pub/a/dotnet/2005/03/21/interviewmiguel.html

El 22 de marzo en su BrainShare Conference 2005 Novell anunció que está preparando un gran asalto al mercado del escritorio Microsoft.

El VP de ingeniería de escritorio y colaboración Nat Friedman declaró que "la siguiente versión del escritorio Linux estará lista para competir con Windows".

Novell incluirá el buscador de archivos y correos electrónicos Beagle y el organizador de fotos personales F-Spot.

Personalmente, no creo que la clave de la conquista del mercado del escritorio tenga nada que ver con estas pequeñas utilidades.

Novell ya mordió el polvo contra Microsoft en el mercado de sistemas operativos de red.
De aquellas batallas debería haber aprendido que el gran consumo es una guerra que se libra en el campo del marketing y las alianzas estratégicas y no de la calidad ni la funcionalidad tecnológica.

La penetración en el mercado de escritorio Microsoft debería hacerse a través de las grandes empresas y los gobiernos. Tratando de maximizar la utilidad del sistema para este tipo de usuarios, y dejando en segundo lugar el mercado de gran consumo que compra Windows únicamente a través de los OEM.

Por tal motivo no entiendo el sentido que tiene incluir más juguetes en el escritorio. Suena a la estrategia de intentar derribar un luchador de sumo empujándole: nunca funciona a menos que el contrincante lo tenga convenientemente agarrado del cinturón.

Sun acaba de publicar sus nuevas licencias Java Research License y está preparando otras dos mas: Java Internal Use License (JIUL) y Java Distribution License (JDL) que deben sustituir a la compleja SCSL.

Creo que es muy interesante estudiar las licencias de Sun porque están escritas intentando proteger los derechos del licenciatario y del licenciador y no sólo los intereses de una de las partes como sucede con las licencias EULA o la mayoría de las OSI.

En un mercado con vendedores y compradores no debe ocurrir que una de las partes imponga unilateralmente las condiciones en las que el negocio debe llevarse a cabo. Y esto es igualmente aplicable a aquellos que pretenden parar las licencias Open Source cabildeando a nivel político, como a quienes pretenden forzar a todos los fabricantes de software a que su modelo de licencia siga a pies juntillas los preceptos de la FSF.

Las licencias Open Source clásicas se han basado siempre en los famosos grados de libertad para usar, copiar, modificar y redistribuir el software en cualquier caso.
Mi argumento es que es posible conciliar los intereses de los fabricantes y los usuarios en 9 cláusulas para un nuevo tipo de licencias de software que no sean ni completamente abiertas ni completamente propietarias.

Derechos del licenciador

1. El licenciador tiene derecho a la propiedad intelectual del software que escriba.
Esto puede parece trivial, pero, de hecho en muchos proyectos a medida no se cumple: el cliente paga por el desarrollo y se queda con todos los derechos sobre el trabajo realizado. Es conveniente poner de manifiesto que esta toma de propiedad por parte del cliente es casi exclusiva de la informática y no ocurre en otras disciplinas como la arquitectura, la fotografía, o la literatura.
La propiedad intelectual también incuye la obligatoriedad de que se reconozca siempre la autoría del programa como medio de pago al creador en una economía donde la reputación profesional es importante.

2. El licenciador tiene derecho poner un precio a su propiedad intelectual.
Eventualmente cero, si lo desea. Pero la libertad de usar un software gratuitamente no es un derecho inherente del usuario.
Idealmente, el coste de licencia debería ser proporcional al beneficio económico que el usuario obtenga de ella. Por ello tiene sentido que una licencia de educación sea gratuita, pero que haya que pagar por usar el mismo programa con fines comerciales.
Dado que el coste marginal de cada nueva copia tiende a cero y que el software se amortiza rápidamente, sólo los clientes que realmente obtengan un beneficio económico muy significativo del software deberían pagar por él.
El propio mercado debería encargarse de que se liberasen la aplicaciones lo antes posible una vez recuperada la inversión inicial en I+D.

3. El licenciador tiene derecho a exigir que los desarrollos derivados sean compatibles con el producto original.
Siempre y cuando los cambios incompatibles NO sean de uso exclusivamente interno del que los realiza.

Derechos del licenciatario

4. El licenciatario tiene derecho a que la política de precios sea justa y no cambie arbitrariamente.
Dado que existe un coste importante de cambio de proveedor, el fabricante de software no puede cambiar unilateralmente su política de precios.
En caso de que el precio exigido por el fabricante sea abusivo, el licenciatario debería poder solicitar a la justicia la exención de pago de las cantidades que considerase desproporcionadas.

4. El licenciatario tiene derecho a corregir él mismo los errores que el fabricante no pueda.
Para ello necesita disponer del código fuente.

5. El licenciatario tiene derecho a que el software siga su propio calendario de negocio sin esperar a que al fabricante le convenga introducir la mejoras requeridas.
Esto implica que el licenciatario debe tener acceso al los fuentes donde realizar las modificaciones.
Además, estas mejoras no pueden ser gravadas con royalties adicionales por el licenciador.

6. El licenciatario tiene derecho a evaluar la calidad del software que utiliza.
Y para ello también es necesario que disponga del código fuente.

8. El licenciatario tiene derecho a cambiar a otro proveedor si la calidad de servicio del fabricante no le satisface.
Para que esto sea factible no sólo el software debe ser abierto sino que debe seguir algunos estándares de compatibilidad con otros programas. Es para proteger esta libertad de cambio del cliente que el fabricante tiene derecho a exigir que no se produczca variantes públicas incompatibles con el producto original.

Derechos de la sociedad

8. Cada individuo tiene derecho a hacer uso libremente del conocimiento.
Nadie puede imponer royalties sobre la innovación o sobre los avances en conocimiento científico. Con ello se retrasa el progreso y se perjudica a la sociedad en su conjunto. Es por esto que las patentes de software no deben existir.

9. El beneficio que un fabricante obtenga debe ser proporcional al esfuerzo (economico y laboral) requerido en la creación y al valor que aporte.
Es razonable imponer cotas [elevadas] al beneficio máximo de quienes ostentan la propiedad de bienes de interés general para la sociedad.

Via Reuters puede leerse que el Masschussetts Institute of Technology ha prescrito Software Libre al gobierno brasileño.
Según los expertos del MIT el SL es mucho mejor en las dimensiones de coste, potencia y calidad para el PC Conectado que pretende colocar 1 millón de PCs en familias de rentas medio-bajas de Brasil.

A medida que se extiende el uso de las telecomunicaciones e internet como una infraestructura social más, suge una pregunta importante: ¿hasta que punto debe la administración pública financiar y liberar aplicaciones?.

Condiciones para el desarrollo público de aplicaciones libres.

En general, la administración debería liberar una aplicación cuando se cumplan una de estas cuatro condiciones.

a) La aplicación ha sido íntegramente desarrollada con dinero público, y, por consiguiente debe ser un bien colectivo disponible para toda la sociedad.

b) La aplicación desarrollada es un algoritmo o un interfaz de uso muy común, no sujeto a patentes, y que es evidentemente de interés general.

c) La aplicación desarrollada es necesaria para cumplir con algún trámite electrónico obligatorio con el estado (tal como el pago de la seguridad social o la presentación de libros contables).

d) Cuando la disponibilidad de los fuentes sea necesaria para poder garantizar la seguridad y la continuidad de un servicio de misión crítica.

- Es interesante poner de manifiesto que se deben liberar no sólo las aplicaciones sino también la información obtenida con dinero público: estudios estadísticos, y demás datos de utilidad.

Restricciones a la liberación de aplicaciones.

a) La restricción más inmediata es la de aquellas aplicaciones que atañen a la seguridad del estado. En estos casos las restricciones de propiedad intelectual no son suficientes y los programas deben protegerse mediante un conjunto de leyes adicionales.

b) La siguiente restricción es la distorsión del mercado o la competencia desleal con fabricantes independientes de software. Por poner un símil, no es lo mismo construir una línea férrea que un campo de golf. El estado debe garantizar la disponibilidad de las infraestructuras básicas pero no debe entrar en la prestación de servicios finales que sean cometido del sector privado.

c) El estado no debe subvencionar desarrollos cuyo fin no es el aplicativo de software en si mismo sino la generación de un tejido industrial. O, al menos, no debe hacerlo sin el acuerdo previo con otros estados, pues ello constituiría, al menos en el marco de la UE, una financiación ilegal de las empresas por parte del estado.

Apoyo indirecto mediante la adopción de proyectos prerabricados.

El estado es libre (como cualquier otro cliente) de tomar las deciciones de compra que considere oportunas en cada momento.
Es lógico exigir que una aplicación basada en web sea compatible con Internet Explorer porque más de el 90% de los internautas usan IE.
Asimismo, también es legítimo llegar a la conclusión de que comprar software Open Source es más beneficioso en algunos casos que comprar licencias EULA y, por consiguiente, exigir en un pliego de requisitos que el software adquirido sea abierto.
El resto de las discusiones carecen de sentido; es como si la metalurgia se enzarzara en una batalla comercial con los fabricantes de cemento por dilucidar si es mejor construir puentes de hormigón o de acero.

Otro punto a considerar es que el estado debe comprar aquellos proyectos que, con las mismas prestaciones, supongan un ahorro de costes para el herario público, y, en este punto concreto, las aplicaciones libres habitualmente llevan ventaja.

Tipo de licencia.

En principio, lo más adecuado sería una licencia de tipo copyleft. Aunque no hay ningún motivo por el cual la liberación no pudiera llevarse a cabo mediante licencias estilo GPL.

Después de la declaraciones de AETIC sobre la neutralidad tecnológica y sobre como según ellos debe actual el Gobierno: Hispalinux ha emitdo un comunicado titulado: Hispalinux apoya al gobierno en la consecución de la "neutralidad tecnológica".

Lo normal es que una asociación formada por empresas de software que no han entendido el cambio de paradigma en la industria hagan declaraciones de este tipo. Lo que ya me gusta mucho menos es que presionen al gobierno creando FUD y orientando al gobierno (que son los representantes de todos los ciudadanos) a estrategias que solo favorecen a unos pocos y en muchos casos nisiquiera tributan o crean riqueza local en España. Esto me recuerda mucho cuando nuestro ex-ministro Pique soltó aquella aberración claramente inducida que el software libre era malo para las empresas y que para algunos es muy difícil saber a quien representan cuando llegan al poder.

No deja de ser paradógico que los miembros de esta asociación hayán sido los más benificiados del incumplimiento de la legalidad vigente en los últimos 10 años. Hay más de 15.000 pliegos de contratación que no son "neutros tecnológicamente" e incluyen terminos como "compatible" windows, intel o word. Por supuesto solo amenzan y crean incertidumbre ahora que los representantes de los ciudadanos simplemente cumplen con la ley y en algunos casos extraordinarios se dedican a facilitar la verdadera sociedad del conocimiento para todos o promover la difusión del conocimiento adquirido entre sus ciudadanos y empresas como es el caso de Andalucia.

Veremos hasta donde llegan los coletazos y golpes bajos de esta industria que se resiste a que nuevos modelos de desarrollo o industria les quite cualquier de sus privilegios. Como miembro de Hispalinux no voy a parar para que no prospere esta campaña de acoso al software libre.

Via AfterDawn puede leerse un interesante post sobre los conatos de conflicto legal entre la MPAA y BitTorrent.

Tras el cierre de Supranova (el mayor tracker de material ilegal distribuido via BitTorrent) sus autores han aprendido que las asociaciones de autor necesitan un blanco centralizado que atacar (estilo Napster) y por ello han empezado a trabajar en un protocolo de tracker distribuido.

¿Cómo cercenar entonces a una tecnología que:
a) El completamente abierta.
b) Es intrínsecamente distribuida.

La respuesta es que la gestión de derechos de autor basada en el control de las tecnologías digitales no es viable a largo plazo. Es por es ello que la via del canon esta siendo la elegida como frente legal contra a la piratería.

En 5 ó 10 años no será necesario pagar por los CDs de música porque ya habremos pagado los derechos de autor cuando compremos el ordenador.

Estoy de vuelta de Silicon Valley donde, entre otras cosas, tuve oportunidad de asistir a la charla de Brian Behlendorf (co-fundador de ASF) en la Evans Data Developer Relations Conference.

Según Behlendorf, "los buenos proyectos open source es más probable que surjan como resultado de organizaciones que no están dominadas por el interés de ningún grupo o persona".

Lo siento pero me he perdido algo. ¿Qué organización no está dominada por los intereses de alguien? Se refería, obviamente, a Apache, que pese a no estar "dominada" por ninguna empresa privada ha recibido importantes donaciones de las mismas.

Los patrocinios de aplicaciones liberadas son socialmente beneficiosos y producen productos de tan buena calidad, o mejores, que aquellos desarrollados al 100% en comunidad.

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.

Microsoft ha comprado Groove Networks en una maniobra para diversificar sus ingresos de la vaca lechera de Office y de cerrar huecos en el área de herramientas colaborativas.

Cada vez estoy más convencido de que la siguiente refriega por un nicho de mercado será el GroupWare. Con OpenOffice consolidado, Microsoft debe defender el uso de su ecosistema de aplicaciones frente a la aparición de tecnologías libres.

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

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

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

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

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

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

Artículo relacionado: Uno currando y diez mirando

En la bitácora de Dan Bricklin (creador de VisiCalc) puede leerse un interesante artículo sobre el papel del software libre en la explotación a largo plazo de infraestructuras de tecnología informática.

De todos los activos, los digitales son aquellos que más rápidamente se deprecian siguiendo aquella máxima de "si sabes como funciona entonces está obsoleto".

Creo que el titular de Bricklin es premeditadamente exagerado, pero lo que es cierto es que para la fabricación de software necesitamos basarnos más en infraestructuras conocidas y fiables y dejar de reinvertar ruedas.

Uno de mis dichos populares favoritos aplicables a la tecnología es "si funciona, no lo toques". Aunque por desgracia los programas informáticos los estamos tocando cada dos o tres meses y, además, con un calendario de desarrollo que muchas veces no permite diseñar, testear y documentar los programas de debidamente.

Ahora bien ¿porqué no seguimos utilizando aquellos programas COBOL para el tratamiento de archivos? Si bien, el lenguaje es verborreico y está obsoleto. ¿Realmente? ¿Qué está obsoleto, el lenguaje o la voluntad del fabricante de seguir dándole soporte?

Una buena forma de alargar la vida útil de los activos digitales es que sean de fuente abierto. Esto es algo que rara vez se considera en los estudios económicos del sofware libre vs. software propietario. Asimismo, y como apunta Bricklin, es conveniente que las actualizaciones de software se realizen cuando ello sea conveniente para la mejor explotación de la información y no de forma forzosa con el desembarco de cada nueva generación de procesadores y dispositivos de almacenamiento.

BEA Systems a anunciado su ádhesión a la Fundación Eclipse con un compromiso de aportación anual de $1,5M.
Con esta decisón sigue los pasos de IBM, Oracle, Computer Associates y muchos otros.
Es probable que Borland y Sun también hagan converger sus entornos de desarrollo hacia el uso de Eclipse como marco base.

La Junta de Andalucía acaba de liberar todo el software desarrollado por la Junta de Andalucía y sus organismos dependientes. La entrada en vigor de esta orden
que revoluciona totalmente el panorama del uso del software no ya en Andalucía, sino posiblemente en el mundo entero. En el plazo de un año, estarán habilitados los mecanismos para que el conjunto de software desarrollado por parte de funcionarios de la Junta de Andalucía o contratado para su desarrollo e implantación en la propia Junta, sea liberado como software libre.