Content

La Dualidad Producto-Servicio

Una de las principales tácticas de los competidores del Software Libre, es denominarlo Software No Comercial. Esto es una burda artimaña para desconcertar a los empresarios y alejarlos del Software Libre. el Software Libre es y se creó para ser Software Comercial. Aunque puede ser un poco complicado de entender cómo negociar con algo que es, fundamentalmente gratis.

Hay varios métodos para hacer negocio con el Software Libre y cada vez se inventan métodos nuevos. Cualquiera con un poco de iniciativa puede proponer un método que sea factible basándose en la siguiente premisa:

El Software no es un producto, es un servicio.

Al menos es así para la mayoría de las empresas que requieren Software. Normalmente una empresa no desea comprar un artefacto tan complicado como el último paquete de software contable, metido en una caja y enviado por correo urgente. Si ningún empleado de la empresa conoce ese paquete, tendrá que gastar muchos recursos y dinero en implantar ese nuevo Software en la empresa. Al menos mucho más que si el creador del Software le guiara pasa a paso en el proceso de implantación del Software en su empresa.

Generalmente ninguna empresa desea comprar Software sin un servicio asociado, muchas veces se conforman con determinados productos sobre los que no se puede obtener un servicio, o éste es muy precario, pero generalmente la relación con éste tipo de software es poco satisfactoria. En estos casos se suele recurrir a compañías externas al producto que dicen conocerlo muy bien y que pueden ayudar a mantenerlo. Esto generalmente es así, pero el servicio que se puede dar sin el conocimiento que ofrece el acceso al código y las posibilidades de adaptación del mismo a la empresa, pocas veces satisface a los usuarios. Generalmente la productora de software en un arranque irracional de celos por el código prefiere perder el cliente antes que insinuar siquiera ofrecer la posibilidad de un cambio que permita a éstas empresas mejorar el servicio.

Pienso que principalmente se debe a un efecto de inercia. Probablemente en otras industrias con un modelo de negocio más sano, el hecho de que los clientes se quejen, es motivo suficiente para que se propongan cambios que permitan solucionar el problema. En Informática el pensamiento general parece ser que “es así y pasa con todas las empresas en algún momento, así que no es necesario cambiar nada”.

Está claro que la Informática actual requiere un cambio. Entre fallos de seguridad, virus, copia ilegal, etc. se ha convertido en una industria plagada de insatisfacciones.

La comparación con la industria del automóvil deja de manifiesto las grandes diferencias en términos de calidad que sufren los Sistemas de Información.

Esto es una opinión personal, que cada uno debería meditar. Pero, ¿no será una causa el hecho de no haber escogido el modelo de negocio adecuado para las características intrínsecas del Software? Está claro que, aún sin disponer de estudios más rigurosos, un vistazo rápido sobre las noticias del sector demuestran que hay un problema. Ponemos todo nuestro esfuerzo en solucionarlo, pero quizá no hayamos encontrado aún la manera más eficiente de hacerlo.

La propuesta del Software Libre, implica cambiar totalmente el modelo de negocio y ver que sucede. Todavía nos encontramos en un estadío muy temprano para hablar de una victoria o una derrota, pero parece ser que el sistema funciona, y presumiblemente de forma mucho más eficiente que los modelos antiguos.

Linux: ¿Nuevo modelo de desarrollo o nuevo sistema operativo?

Para poder entender las ventajas del Software Libre más allá de aspectos económicos o de fiabilidad. Hay que echar un vistazo al trabajo de los grandes productores de Software Libre del mundo.

Eric S. Raymond escribió un ensayo sobre el éxito de Linus en el desarrollo de su Sistema Operativo.

Raymond y la gran mayoría de los analistas de la época y actuales (1993) se maravillaban de las ventajas de los sistemas operativos UNIX, su principal característica era que todas sus herramientas se diseñaban de forma óptima, para realizar una sola tarea de la forma más simple posible. Estas utilidades se podían desarrollar con un prototipo desarrollado de manera más o menos rápida y desarrollarlo mediante programación evolutiva (procesamiento iterativo). Aunque se sabía que esto no era válido para proyectos muy complejos.

Es de conocimiento común que los usuarios odian los errores, así que parece lógico esforzarse todo lo posible en lanzar una aplicación “libre de errores”. Aunque es sabido también que ésto, generalmente es muy difícil. Generalmente se suele invertir entre 6 u 8 meses para perfilar la aplicación y conseguir que se comporte de la mejor manera posible. Para que la primera impresión de los usuarios sea buena.

Durante ese tiempo se tiene que luchar contra un efecto bastante desagradable en el desarrollo de aplicaciones, si un usuario ha estado esperando 6 meses por una aplicación y cuando la prueba no es lo que esperaba, no porque no funcione correctamente, sino simplemente porque lo esperaba de otra forma, tendremos que luchar contra un rechazo irracional del Software por parte del usuario.

El estilo de desarrollo de Linus Torvalds “Libere rápido y a menudo” nos enseñó un nuevo método de desarrollo. Mucha gente piensa que el éxito de Linus no viene por el desarrollo del sistema operativo en sí, sino por ésta nueva manera de desarrollar programas.

Linus, procuraba ser completamente cristalino en sus decisiones y en su código, delega todo el trabajo que puede en gente de confianza, escucha todas las críticas y propuestas y no se corta por liberar dos versiones del kernel el mismo día si es necesario.

Raymond se dio cuenta de que este hecho estaba dando excelentes resultados en Linux, y probablemente fue ésto y no la genial capacidad de Linus para la programación (de la cual no dudamos) el responsable del éxito de Linux. En 1996, Raymond decidió comenzar un experimento para poner en práctica los métodos de Linus de forma consciente y comprobar si era adecuado para otro tipo de proyectos. Escogió un proyecto que le resultara útil y empezó a interesarse por él y a hacer algunas correcciones al código, se trataba de un Software que le permitía acceder al correo de la oficina desde casa a través de una conexión SLIP.

Al poco tiempo se convirtió en el líder del proyecto, lo que le permitió poner en práctica las ideas que tenía sobre el éxito de Linux. No tardó en obtener ayuda y consejo de grandes programadores. Muchos de los parches que recibía superaban su propia capacidad de programación, consiguiendo un programa de mucha más calidad.

Lo más grande después de tener buenas ideas, es reconocer las de los demás.

La Catedral y el Bazar

Eric S. Raymond.

Esto, a grandes rasgos pone de manifiesto algo que ya suponíamos. Linux nunca habría visto la luz sin el modelo de desarrollo colaborativo escogido por Linus. Y ese modelo, que incluía a todos los usuarios del sistema, solo podía ser posible en un sistema de Código Libre.

Esto, en mi opinión, es una de las pruebas de que el nuevo modelo de negocio funciona, y funciona muy bien pues ha conseguido introducirse en un mercado con un monopolio del 96%. Esto de otra manera, parece prácticamente imposible.

Está claro que no todos los proyectos pueden amoldarse exactamente a éste modelo de desarrollo. Generalmente solo suele funcionar si se tiene un grupo grande de potenciales usuarios. Y sobre todo se conocen bien las reglas del juego.

Codemonkey

Es importante ofrecer algo a los programadores que se quieran asociar al nuevo proyecto. Nuestra carta de presentación será el código de la aplicación. Éste debe ser claro, de calidad y adecuado a las técnicas comúnmente aplicadas en éste tipo de aplicaciones. La típica frase “si funciona, no lo toques” probablemente nos hará fracasar en éste modelo de trabajo. Quizá sería más adecuado.

Si funciona, es el momento idóneo para mejorarlo.

Si se quiere obtener ayuda es importante ponérselo fácil a nuestros potenciales ayudantes, creando un código que puedan entender fácilmente; comentarlo; usar los lenguajes, plataformas y metodologías usadas comúnmente en éstos proyectos nos hará ganar más puntos en la Comunidad.

Esto implica que los programadores deben comprender que no basta con escribir el código. Ahora deben escribirlo de forma que funcione, que funcione de forma óptima, que sea claro, elegante. Esto obliga a prestar mucha atención a lo que se hace. No es lo mismo escribir un código que no va a ver la luz que escribirlo para que miles de personas lo critiquen. Esto, presumiblemente debería influir en una mejora de la calidad del Software.

Ampliando un poco más este concepto podríamos suponer que ésto producirá un efecto beneficioso en los programadores. En primer lugar les obligaría a refinar sus técnicas para escribir el código alcanzando sus límites.

En el caso de que éste modelo proliferara, el mejor currículum que puede ofrecer un nuevo programador a las empresas, es haber participado en proyectos de Software Libre de forma exitosa. Lo que permitiría romper el típico bucle de “para que te contraten necesitas experiencia, para obtener experiencia necesitas que te contraten.”

Con éste nuevo modelo, los estudiantes pueden hacerse un currículum participando en proyectos de Software Libre, lo que daría un aliciente extra para que los programadores independientes participen en el desarrollo de las aplicaciones Libres, creando así una relación entre empresarios y programadores independientes.

El Principio de Meritocracia

Muchas veces surgen dudas de si realmente va a beneficiarnos en algo liberar nuestro código.

Nos preguntamos qué sucederá si una empresa de la competencia lo usa para beneficio propio.

Pues bien, hay dos elementos fundamentales a tener en cuenta para evitar ésta situación:

En el Software Libre promueve que copiar el código y el conocimiento es bueno. Pero se hace con un fin: Mejorarlo y adaptarlo a sus necesidades. Si usted coge el modelo de negocio de Software Libre de una empresa, y lo intenta trasladar a la suya propia, probablemente fracase.

Deberá reunirse con sus mejores pensadores y que sobre una base de mentalidad abierta discutan distintos métodos para adentrarse en éste modelo. Decidir si es válido o no para las aplicaciones de las que ya dispone, los cambios necesarios para que éstas puedan ser de utilidad a la Comunidad, acercamiento a potenciales clientes, etc.

Una vez haya decidido que puede dar servicio con éste nuevo modelo, deberá enfrentarse al Principio de Meritocracia.

Actualmente las Productoras de Software atan a sus clientes porque es muy difícil deshacerse de un Software que se lleva usando años en una empresa. Esto no pasa con otros elementos de la Empresa, como fotocopiadoras, coches, edificios de oficinas, e incluso lo más importante: Empleados. La informática en éste sentido ha sido un caso especial, pero eso cambiaría con el Software Libre, ahora tendrá que unirse al resto del mundo y luchar por mantener su posición en el mercado ofreciendo servicios y calidad.

La empresa que usa su Software, probablemente lo necesite y si usted satisface sus necesidades no cambiarán de proveedor. Es primordial, en éste sentido, orientar los esfuerzos a mejorar los servicios, comprendiendo los requerimientos de los clientes y satisfaciéndolos al máximo posible.

Si un día echa la vista atrás después de un éxito apabullante y ve que ha tenido que compartirlo con cien empresas más, recuerde que puede que no hubiese conseguido ese éxito sin esas cien empresas.

El Fork

Este término, es usado cuando un grupo independiente coge una aplicación de Software Libre y empieza a desarrollarla por su cuenta.

Esto generalmente tiene un motivo, salvando algunas excepciones, (java) suele deberse a un fallo en la administración del Software por parte de la empresa.

Si surge algún fork en nuestro producto puede deberse a que algo estamos haciendo mal. Dado que no es necesario acaparar el Software libre. Generalmente es mas provechoso para todos participar en el mismo proyecto, dado que nunca podrán separarse mucho unos de otros y de ésta forma se aunan los esfuerzos para obtener lo que el cliente de cada empresa quiere.

En otros casos el fork no suele tener mucho éxito pues suele realizarse por gente que no entiende bien los modelos de desarrollo colaborativo, algo que es crucial para poder prosperar mediante éste nuevo paradigma.

Algunos modelos de negocio