Tabla de contenidos
Este capítulo examina como conseguir fondos en un entorno de software libre. Está dirigido no sólo a los desarrolladores que se les paga por trabajar en proyectos de software libre, sino también a los directores, quienes necesitan comprender la dinámica social del entorno de desarrollo. En las secciones que siguen, el destinatario ("tú") significa tanto un desarrollador que cobra como a aquel que coordina a tales desarrolladores. El consejo a menudo será el mismo para ambos; cuando no sea así, la audiencia pretendida quedará clara con el contexto.
Los fondos corporativos de un desarrollo de software libre no son un nuevo fenómeno. Muchos de los desarrollos han estado siempre informalmente subvencionados. Cuando un administrador de sistemas escribe una herramienta de análisis de sistemas para ayudarle en su trabajo, entonces la pone online y consigue corregir bugs y contribuciones con nuevas características de otros administradores de sistemas, lo que ha ocurrido es que se ha creado un consorcio no oficial. Los fondos del consorcio provienen de los sueldos de los sysadmins, y su espacio de oficina y ancho de banda son donados, aunque desconociéndolo la organización para la que ellos trabajan. Aquellas organizaciones se benefician de la inversión aunque ellas, institucionalmente no son conscientes de ello al principio.
Hoy la diferencia, es que muchos de estos esfuerzos están siendo formalizados. Las corporaciones están tomando consciencia de los beneficios del software open source, y por ello empiezan a involucrarse, ellas mismas, en su desarrollo. Los desarrolladores también llegan a esperar que los proyectos importantes atraigan al menos donaciones, y posiblemente incluso patrocinantes de gran duración. Mientras que la presencia del dinero no ha cambiado, la dinámica básica del desarrollo del software libre, ha cambiado mucho la escala a la cual ocurren las cosas, ambas en términos de número de desarrolladores y tiempo por desarrollador. También ha tenido efecto en como son organizados los proyectos, y en como las partes envueltas en ellos interactuan. La cuestión no es meramente sobre cómo se gasta el dinero, o en medir cómo se devuelven las inversiones, sino también en las administraciones y procesos: ¿cómo pueden las estructuras de mando jerárquico de las corporaciones y las comunidades de voluntarios semi-descentralizados de proyectos de software libre trabajar productivamente unos con otros? ¿Tendrán ellos que acordar incluso el significado de "productivo"?
El patrocinio financiero es, en general, bienvenido por las comunidades de desarrollo de open source. Puede reducir la vulnerabilidad de un proyecto a las fuerzas del Caos, el cual arrebata tantos proyectos antes de que ellos salgan a la tierra, y de ahí puede hacer a la gente más dispuesta a darle al software una oportunidad; ellos sienten que están invirtiendo su tiempo en algo que todavía les llevará seis meses desde ahora. Después de todo, la credibilidad es contagiosa, hasta cierto punto. Cuando se dice, IBM apoya un proyecto Open Source, la gente más o menos asume que al proyecto no se le permitirá fallar, y su buena voluntad resultante dedicará los esfuerzos a ello para que pueda hacerse como una profecía que se cumple por su propia naturaleza.
Sin embargo, los fondos también traen una percepción de control. Si no se manejan cuidadosamente, el dinero puede dividir un proyecto en grupos incluyentes y grupos excluyentes de desarrolladores. Si los voluntarios no remunerados tienen el sentimiento que las decisiones de diseño o adición de características están simplemente disponibles para el mejor postor, se marcharán a un proyecto que se parezca más a una meritocracia y menos a un trabajo sin pagar para el beneficio de alguien. Puede que ellos nunca se quejen patentemente en las listas de correo. En vez de eso, simplemente habrá menos y menos ruido de fuentes externas, como los voluntarios gradualmente pararán de intentar ser tomados seriamente. El rumor de la actividad a pequeña escala continuará, en la forma de informes de fallos y ocasionalmente pequeños arreglos. Pero no habrá ninguna contribución con gran código o participación externa en discusiones de diseño. La gente siente que es lo que se espera de ellos, y viven (o se deprimen) en esas esperanzas.
Aunque el dinero necesita ser usado cuidadosamente, esto no significa que no se pueda comprar influencia. Desde luego puede. El truco es que no puede comprar la influencia directamente. En una transación comercial sencilla, cambias dinero por lo que quieras. Si necesitas añadir una característica, firmas un contrato, pagas por ello, y lo tienes hecho. En un proyecto Open Source no es tan simple. Tú puedes firmar un contrato con algunos desarrolladores, pero ellos serían idiotas consigo mismos, y tú, si ellos garantizan que el trabajo por el que tú has pagado será aceptado por la comunidad de desarrollo simplemente porque tú pagaste por él. El trabajo únicamente puede ser aceptado por sus propios méritos, y es como encaja en la visión de la comunidad por el software. Puede que tengas algo que decir en esta visión, pero no serás la única voz.
Por lo tanto, el dinero no puede comprar influencia, pero puede comprar cosas que llevan a la influencia. El ejemplo más obvio son los programadores. Si los buenos programadores son contratados, y aguantan bastante como para conseguir experiencia con el software y credibilidad en la comunidad, entonces ellos pueden influenciar en el proyecto de la misma manera que cualquier otro miembro. Tendrán voto o si hay muchos de ellos, tendrán un bloque de votaciones. Si ellos son respetados en el proyecto, tendrán influencia más allá de sus votos. No hay necesidad de que los desarrolladores con sueldo disimulen sus motivos, tampoco. Después de todo, todo el mundo que quiere que se haga un cambio en el software lo quiere por alguna razón. Las razones de tu compañía no son menos legítimas que las de cualquiera. Es simplemente que el peso dado a los objetivos de tu compañia será determinado por el estatus de sus representantes en el proyecto, no por el tamaño de la compañía, presupuesto o plan de negocios.
Existen múltiples razones diferentes por las cuales los proyectos open source consiguen fondos. Los elementos de esta lista no se excluyen mutuamente; a menudo, el financiamiento de un proyecto será el resultado de muchos, o incluso todas de estas motivaciones:
Distintas organizaciones con necesidades de software similares, a menudo se encuentran a sí mismas duplicando esfuerzos, tanto escribiendo código interno similar, o comprando productos similares de vendedores propietarios. Cuando se dan cuenta de lo que ocurre, las organizaciones pueden reunir sus recursos y crear (o entrar) en un proyecto Open Source adaptado a sus necesidades. Las ventajas son obvias: el costo de desarrollo se divide pero los beneficios se acumulan entre todos. Aunque este escenario parezca más intuitivo para no lucrarse, puede crear un sentido estratégico incluso para los competidores que quieren sacar beneficio.
Ejemplos: http://www.openadapter.org/, http://www.koha.org/
Cuando una compañía vende servicios de los cuales depende, o se hacen más atractivos por, programas open source particulares, naturalmente en los intereses de esta compañía está asegurar que esos programas sean activamente mantenidos.
Ejemplo: CollabNet's soporte de http://subversion.tigris.org/ (descargo: este es mi trabajo diario, pero es también un ejemplo perfecto de este modelo).
El valor de los ordenadores y sus componentes está directamente relacionado con la cantidad de software disponible para ellos. Los vendedores de hardware no sólo venden máquinas completas, los creadores de dispositivos periféricos y microchips también han descubierto que teniendo software libre de gran calidad para ejecutarse en su hardware es igualmente una parte importante para los clientes.
Algunas empresas patrocinan ciertos proyectos OSS como una manera de socavar los productos de la competencia, que puede que sean o no OSS. Quitar cuotas de mercado de la competencia no es por lo general la única razón para involucrarse en un proyecto, pero sí puede ser un factor importante.
Ejemplo: http://www.openoffice.org/ (no, esta no es la única razón por la cual OpenOffice existe, pero el software en sí es parcialmente una respuesta a Microsoft Office).
Ser asociado con un proyecto OSS popular puede que genere muy buena publicidad.
Licenciamiento Dual es una práctica bajo la cual se ofrece el software utilizando una licencia propietaria tradicional para clientes quienes deseen revenderlo como parte de otra aplicación propietaria, y simultaneamente bajo una licencia libre para aquellos quienes pretenden utilizarlo bajo los términos del software libre (más en “Concesión de licencias dual” en Capítulo 9, Licencias, Copyrights y Patentes). Si la comunidad de desarrolladores de software libre es activa, el programa recibe los beneficios del desarrollo y búsqueda de fallos de amplio espectro mientras la compañia sigue obteniendo beneficios por las regalías para mantener algunos desarrolladores a tiempo completo.
Dos ejemplos muy conocidos son MySQL, creadores de la base de datos con el mismo nombre y Sleepycat, que distribuye y brinda soporte para la base de datos Berkeley. No es ninguna coincidencia que las dos sean empresas de bases de datos. Las bases de datos suelen ser integradas dentro de otras aplicaciones en lugar de ser vendidas directamente a los usuarios, por lo que son perfectas para el modelo de licencia dual.
Un proyecto popular puede a veces obtener contribuciones significativas, tanto de individuos como de organizaciones, sólo con colocar un botón de donaciones en línea o a veces vendiendo productos promocionales del proyecto como tazas de cáfe, camisetas, alfombrillas, etc. Pero precaución, si el proyecto ha de aceptar donaciones hay que planear como será utilizado ese dinero antes de que llegue y publicar esto en la página web del proyecto. Las discusiones acerca de hacia donde debe ser dirigido el dinero tienden a ser más distendidas antes de que este se tenga; de todas formas, si existen importantes desacuerdos, es mejor averiguarlo mientras se sigue siendo algo académico.
El modelo de negocio del beneficiario no es el único factor en como éste se relaciona con la comunidad open source. La relación histórica entre los dos es tambien importante: ¿Inició la empresa el proyecto o se ha unido luego? En cualquiera de los dos casos, el beneficiario deberá ganar credibilidad, pero, no sorprendentemente, será necesario un mayor esfuerzo en el segundo caso. La organización debe tener claros objetivos con respecto al proyecto. ¿Intenta la empresa mantener una posición de liderazgo o simplemente intenta ser una voz dentro de la comunidad para guiar sin gobernar la dirección del proyecto? ¿O sólo desea tener un par de colaboradores que sean capaces de resolver los problemas de los usuarios e incluir sus cambios en la distribución pública sin mucho jaleo?
Manten estas preguntas en mente mientras continuas leyendo las siguientes directrices. Están pensadas para ser aplicadas a cualquier tipo de participación empresarial dentro de un proyecto open source, pero teniendo en cuenta que todo proyecto es un entorno humano, por lo cual, ninguno es igual. Hasta cierto grado, habrá que seguir nuestro instinto, pero seguir estos principios aumentarán las posibilidades de que las cosas funcionen como queremos.