En los ultimos años el software libre ha ido ganando terreno en el mundo empresarial. Ya no es visto simplemente como un movimiento filosófico sino que aporta muchas ventajas tanto tecnológica como económicamente y las empresas no quieren perdérselas.

Poco a poco han ido apareciendo diferentes modelo de negocio alrededor del software libre y las empresas tratan de sacar partido de estos, pero no siempre es sencillo, a veces porque el modelo no está suficientemente maduro o porque las empresas no tienen el conocimiento necesario para sacar partido de un movimiento que tiene sus particularidades. Por simplificar bastante, cuando una compañía quiere hacer negocio con software libre, tiene dos aproximaciones posibles: partir de un proyecto existente, interactuar con la comunidad y ofrecer sus propios servicios basados en ese software o crear un proyecto propio. La primera aproximación la dejo para un futuro post. Sobre la segunda, me ha parecido muy interesante la visión de Ben Collins-Sussman y Brian Fitzpatrick (más conocidos por haber formado parte del equipo que desarrolló Subversion) en una charla en la OSCON, en la que hablan de las diferentes estrategias empleadas por las empresas al crear proyectos de software libre.

A la primera la denominan Fake open source, se trata de liberar el código fuente del proyecto bajo una licencia no libre. Con esto no se consigue realmente ninguno de los beneficios que el software libre puede aportar al desarrollo del proyecto y además se corre el riesgo de crear antipatías entre la comunidad.

Las dos siguientes son similares y las denominan Throw code over wall y  Develop internally, post externally. La primera consiste simplemente en liberar el código del proyecto bajo una licencia libre. De esta forma no hay posibilidad de generar una comunidad y no se genera ningún tipo de confianza en el proyecto. En el segundo caso se trata de desarrollar el proyecto dentro de la empresa, pero con un repositorio público, de forma que la comunidad pueda ver los avances. Todas las decisiones de diseño y desarrollo se toman internamente. Con esta estrategia es posible conseguir algunos seguidores interesados en el proyecto e incluso es posible que envíen algún parche, pero no es posible crear una comunidad al no permitir que desarrolladores externos se impliquen en el proyecto.

La siguiente estrategia se denomina Open monarchy, el desarrollo se lleva a cabo en un repositorio público y las discusiones sobre el proyecto se llevan también al terreno público, sin embargo los líderes del proyecto y los committers pertenecen sólo a la empresa que es quien fija las reglas y toma las decisiones finales. De esta forma se empieza a disponer de algunos de los beneficios que aporta el software libre. Las discusiones públicas generan participación de gente externa que aporta ideas lo que repercutirá positivamente en la calidad del software. Se genera confianza en el proyecto y en algunos casos incluso se permite la participación de gente externa. Pero qué pasa cuando la compañía toma una decisión que no gusta a la comunidad? o no ofrece la suficiente garantía de que el proyecto crezca a un ritmo razonable, bien porque en esos momentos la compañía tiene otras prioridades o porque no tiene suficientes recursos para mantener el proyecto? En estos casos el proyecto corre el riesgo de morir o de que aparezca un fork liderado por la comunidad.

Siguiendo esta senda de lo privado hacia lo público, llegamos a la última estrategia, denominada Consensus-Based development. Aquí todo es público, el desarrollo, las discusiones... la toma de decisiones es consensuada entre todos los committers, que ya no sólo pertenence a la empresa sino que cualquiera que se involucre en el proyecto tiene la posibilidad de llegar a serlo [meritocracia]. Con esta estrategia se obtienen todos los beneficios que aporta el software libre y hace que el proyecto sea mantenible a largo plazo ya que no sólo depende de los recursos de la empresa sino que tiene a disposición todos los recursos que la comunidad de desarrolladores  y usuarios puede ofrecerle. Se genera confianza en el proyecto lo que atraerá a más participantes a la comunidad y a otras empresas interesadas en el proyecto.