DINERO EN EL SOFTWARE LIBRE

EL DINERO EN LOS PROYECTOS DE SOFTWARE LIBRE

(Basado en el libro: Producing Open Source Software. Karl Fogel. 2013)

En este documento se examina la forma de llevar la financiación en un entorno de software libre. Está
dirigido no sólo a los desarrolladores que se les paga para trabajar en proyectos de software libre, sino
también a sus directivos, que tienen que entender las dinámicas sociales del entorno de desarrollo. En las
secciones que siguen, se presume que usted es un desarrollador a sueldo, o el que dirige a este tipo de
desarrolladores. El consejo a menudo será el mismo para ambos; cuando no es así, el público objetivo se
hará claro a partir del contexto.

Los fondos empresariales del desarrollo de software libre no es un fenómeno nuevo. Una gran cantidad
de desarrollo ha estado siempre subvencionada de manera informal. Por ejemplo, cuando un
administrador de sistemas escribe una herramienta de análisis de redes para ayudarse en su trabajo, y
luego lo pone en internet y obtiene correcciones de errores y las contribuciones de otros administradores
del sistema, lo que ha pasado es que se ha formado un consorcio no oficial. La financiación del consorcio
proviene de los salarios de los administradores de sistemas, y su espacio de oficinas y el ancho de banda
de la red es donado, aunque sin saberlo, por las organizaciones para las que trabajan. Esas organizaciones
se benefician de la inversión, por supuesto, aunque puede que no sean conscientes de ello
institucionalmente al principio.

La diferencia hoy es que muchos de estos esfuerzos están siendo formalizados. Las empresas han tomado
conciencia de los beneficios del software de código abierto, y han comenzado a involucrarse más
directamente en su desarrollo. Muchos desarrolladores esperan que los proyectos realmente importantes
atraerán al menos donaciones, y, posiblemente, incluso los patrocinadores a largo plazo. La presencia de
dinero no ha cambiado la dinámica básica de desarrollo de software libre, pero ha cambiado
considerablemente la escala a la que suceden las cosas, tanto en términos del número de desarrolladores
y tiempo invertido por desarrollador. También ha tenido efectos sobre la forma en que se organizan los
proyectos, y sobre cómo interactúan las partes involucradas en ellos. Los problemas no son sólo acerca
de cómo se gasta el dinero, o cómo se mide el retorno de la inversión. Son también de la gestión y del
proceso: ¿cómo pueden las estructuras de mando jerárquicas de las empresas y las comunidades de
voluntarios semi - descentralizadas de los proyectos de software libre trabajar de manera productiva unos
con otros? ¿Van siquiera ponerse de acuerdo sobre lo que significa "productivamente"?

El apoyo financiero es, en general, bien recibido por las comunidades de desarrollo de código abierto. Se
puede reducir la vulnerabilidad de un proyecto a las fuerzas del Caos, que desaparecen tantos proyectos
antes de que realmente se pongan en marcha, y puede hacer que la gente esté más dispuesta a dar al
software una oportunidad- ya que sienten que están invirtiendo su tiempo en algo productivo. Después
de todo, la credibilidad es contagiosa. Cuando, por ejemplo, IBM respalda un proyecto de código abierto,
la gente asume que el proyecto no fallará, y dedican esfuerzo para que el proyecto funcione.

Sin embargo, la financiación también trae una percepción de control. Si no se maneja con cuidado, el
dinero puede dividir a un proyecto entre desarrolladores internos y externos. Si los voluntarios no
remunerados tienen la sensación de que las decisiones de diseño o nuevas características se hacen bajo
la batuta del que más paga, y no se ve como el trabajo no remunerado en beneficio de otras personas,
ellos no se quejarán abiertamente en las listas de correo. En lugar de ello, simplemente habrá menos y

MIGUEL ORQUERA 1
 DINERO EN EL SOFTWARE LIBRE

menos ruido de fuentes externas, ya que los voluntarios sentirán que no son tomados en serio. El zumbido
de la actividad a pequeña escala continuará, en forma de informes de errores y pequeñas correcciones
ocasionales. Pero no habrá ninguna gran contribución de código o participación externa en las discusiones
de diseño. La gente percibe lo que se espera de ellos, y actúa de acuerdo a esas expectativas.

Aunque el dinero tiene que ser utilizado con cuidado, eso no significa que no se puede comprar influencia
dentro del proyecto de software libre. El truco es que no se puede comprar la influencia directa. En una
transacción comercial directa, se invierte dinero por lo que se quiere. Si usted necesita una característica
adicional, usted firma un contrato, se paga por ello, y se hace. En un proyecto de código abierto, no es tan
simple. Usted puede firmar un contrato con algunos desarrolladores, pero estarían engañándose a sí
mismos si garantizan que el trabajo que pagó sería aceptado por la comunidad de desarrollo, simplemente
porque usted pagó por ella. El trabajo sólo puede aceptarse por sus propios méritos si encaja en la visión
de la comunidad de desarrolladores. Puede que tenga algo que decir en esa visión, pero no será la única
voz.

Así que el dinero no puede comprar la influencia, pero puede comprar cosas que conducen a influir. El
ejemplo más obvio es dotar de programadores. Si se contrata a buenos programadores, y se quedan el
tiempo suficiente para tener experiencia con el software y credibilidad en la comunidad, entonces pueden
influir en el proyecto por los mismos medios que cualquier otro miembro. Ellos tendrán un voto, o si hay
muchos de ellos, van a tener un bloque de votantes. Si ellos son respetados en el proyecto, tendrán
influencia más allá de sólo sus votos. No hay necesidad de que los desarrolladores pagados disfracen sus
motivos, tampoco. Después de todo, todos los que quieren un cambio en el software lo quieren por una
razón. Las razones de su empresa no son menos legítimas que las de cualquier otro. Es sólo que el peso
dado a los objetivos de su empresa será determinado por el estado de sus representantes en el proyecto,
no por tamaño de la empresa, el presupuesto o plan de negocios.

FORMAS DE PARTICIPACION CORPORATIVA

Hay muchas razones por las que los proyectos de código abierto son financiados por empresas. Los
elementos de esta lista no se excluyen mutuamente; a menudo el respaldo financiero de un proyecto será
el resultado de varios, o incluso la totalidad, de estas motivaciones:

Compartir la carga
Organizaciones diferentes con necesidades similares en el software a menudo se encuentran duplicando
esfuerzos, ya sea al escribir código, o mediante la compra de los mismos productos de vendedores de
software privativo. Cuando se dan cuenta de lo que está pasando, las organizaciones pueden reunir sus
recursos y crear (o unirse a) un proyecto de código abierto a la medida de sus necesidades. Las ventajas
son obvias: los costes de desarrollo se dividen, pero los beneficios son para todos. Aunque este escenario
parece más apropiado para las organizaciones no lucrativas, puede tener sentido estratégico, incluso para
empresas competidoras con fines de lucro.

Ejemplos: http://www.openadapter.org/, http://www.koha.org/

MIGUEL ORQUERA 2
 DINERO EN EL SOFTWARE LIBRE

Aumentar los servicios

Cuando una empresa vende servicios que dependen o se hacen más atractivos con un programa de código
abierto, es natural que esas empresas estén interesadas en garantizar que esos programas se mantengan
activamente.

Ejemplo: CollabNet's [http://www.collab.net/] soporte de http://subversion.tigris.org/

Apoyo a las ventas de hardware

El valor de los ordenadores y los componentes del equipo está directamente relacionado con la cantidad
de software disponible para ellos. Los proveedores de hardware, no sólo los vendedores de máquinas
completas, sino también los fabricantes de dispositivos periféricos y microchips, han encontrado que
tener software libre de alta calidad para ejecutarse en su hardware es importante para los clientes.

Debilitamiento de un competidor
A veces las compañías apoyan un proyecto de código abierto en particular como medio de socavar algún
producto de la competencia, que puede o no ser en sí de código abierto. Disminuir la cuota de mercado
de un competidor por lo general no es la única razón para involucrarse con un proyecto de código abierto,
pero puede ser un factor.

Ejemplo: http://www.openoffice.org/ (no, esta no es la única razón por OpenOffice existe, pero el
software es al menos en parte, una respuesta a Microsoft Office).

Mercadeo
Tener su empresa asociada con una aplicación de código abierto muy popular puede ser una buena
gestión de la marca.

Licenciamiento Dual
Licenciamiento Dual es la práctica de ofrecer software bajo una licencia propietaria tradicional para los
clientes que quieren volver a venderlo como parte de una aplicación propietaria de su propiedad, y al
mismo tiempo bajo una licencia libre para quienes quieran utilizarlo en condiciones de código abierto. Si
la comunidad de desarrolladores de código abierto está activa, el software obtiene los beneficios de la
amplia área de depuración y de desarrollo que ofrece el software libre, sin embargo, la empresa sigue
recibiendo un flujo de regalías para apoyar a algunos programadores a tiempo completo.

Dos ejemplos bien conocidos son MySQL [http://www.mysql.com/], fabricantes del software de base de
datos del mismo nombre, y Sleepycat [http://www.sleepycat.com/], que ofrece distribuciones y apoyo
para la base de datos Berkeley. No es ninguna coincidencia que las dos sean empresas de base de datos.
El software de base de datos tiende a estar integrado en las aplicaciones más que ser comercializado
directamente a los usuarios, por lo que se adapta muy bien al modelo de doble licencia.

Donaciones
Un proyecto muy utilizado a veces puede tener importantes contribuciones, tanto personales como de
organizaciones, sólo por tener un botón de donación en línea, o a veces por la venta de mercancía de la
marca tales como recuerdos, camisetas, alfombrillas, etc. Si su proyecto acepta donaciones, planificar
MIGUEL ORQUERA 3
 DINERO EN EL SOFTWARE LIBRE

cómo se utilizará el dinero antes de que venga, y explique los planes en el sitio web del proyecto. Las
discusiones acerca de cómo asignar el dinero tienden a ir mucho más suavemente cuando se planifica
antes de que haya dinero real para gastar.

¿La empresa proveedora de fondos inicia el proyecto, o se une a un esfuerzo de desarrollo existente? En
ambos casos, el donante tendrá que ganar credibilidad. La organización debe contar con objetivos claros
con respecto al proyecto. ¿La empresa está tratando de mantener una posición de liderazgo, o
simplemente tratando de tener una voz en la comunidad, para orientar, y no necesariamente alcanzar la
dirección del proyecto? ¿O simplemente quiere tener un par de colaboradores, capaces de corregir los
errores de los usuarios y ubicar los cambios en la distribución pública sin ningún problema?

Mantenga estas preguntas en mente mientras lee las directrices que siguen. Tienen el propósito de
aplicarse a cualquier tipo de participación de la organización en un proyecto de software libre, pero cada
proyecto es un entorno humano, y por lo tanto no hay dos que sean exactamente iguales. Siguiendo estos
principios aumentará la probabilidad de que las cosas se hagan en la forma que desea.

Contratos a Largo Plazo

Si va a administrar a los programadores en un proyecto de código abierto, manténgalos allí el tiempo
suficiente para que adquieran experiencia tanto a nivel técnico como político, un par de años, como
mínimo. Por supuesto, ningún proyecto, ya sea de código abierto o cerrado, se beneficia del intercambio
de los programadores que entran y salen con mucha frecuencia. La necesidad de un recién llegado de
aprender será un impedimento en cualquier entorno. Pero el costo es más fuerte en proyectos de código
abierto, ya que los desarrolladores salientes se llevan consigo no sólo su conocimiento del código, sino
también su estatus en la comunidad y las relaciones humanas que han hecho allí. La credibilidad que un
desarrollador ha acumulado no se puede transferir. Los nuevos programadores no conocen los temas
previos de discusión y los compromisos, no conoce la mecánica de gestión de errores, ni a los
colaboradores más influyentes.

Capacitar a los recién llegados a través de un programa de participación supervisada. El nuevo

desarrollador debe estar en contacto directo con la comunidad de desarrollo desde el primer día,
comenzando con correcciones de errores y tareas de limpieza, para que pueda aprender la base de código
y adquirir una reputación en la comunidad. , Al mismo tiempo, uno o más desarrolladores experimentados
deben estar disponibles para responder preguntas de los recién llegados.

La participación en los foros es individual

Los desarrolladores deben esforzarse por aparecer en los foros públicos del proyecto como participantes
individuales, más que como una presencia corporativa monolítica. Un miembro puede tener discusiones,
enviar parches, adquirir credibilidad, liderar una idea, y así sucesivamente. Una empresa no puede.

Sea abierto acerca de sus motivaciones

Sea lo más abierto acerca de las metas de su organización, tanto como pueda sin comprometer secretos
comerciales. Si desea que el proyecto adquiera una determinada característica, ya que, por ejemplo, sus
clientes han estado clamando por ella, dígalo abiertamente en las listas de correo. Cuanto más la
comunidad de desarrollo público sabe por qué quiere lo que quiere, mejor.

MIGUEL ORQUERA 4
 DINERO EN EL SOFTWARE LIBRE

El dinero no puede comprar al amor

Si eres un desarrollador pagado en un proyecto, debes establecer pautas desde el principio acerca de lo
que el dinero puede y no puede comprar.

Un ejemplo perfecto de esto ocurrió en el proyecto Subversion. Subversion se inició en el año 2000 por la
empresa CollabNet [http://www.collab.net/], que ha sido el patrocinador principal del proyecto desde su
inicio, y paga los salarios de varios desarrolladores (el autor del libro es uno de ellos). Poco después de
que comenzara el proyecto, contratamos a otro desarrollador, Mike Pilato, a unirse al esfuerzo. Para
entonces, la codificación ya había comenzado. Aunque Subversion estaba todavía en las primeras etapas,
ya tenía una comunidad de desarrollo con un conjunto de reglas básicas.

La llegada de Mike planteó una cuestión interesante. Subversion ya tenía una política sobre cómo un
nuevo desarrollador obtiene acceso de confirmación. En primer lugar, el nuevo desarrollador envía
algunos parches a la lista de correo de desarrollo. Después que suficientes parches suyos han pasado por
la revisión de otros desarrolladores experimentados para ver si el nuevo colaborador sabe lo que está
haciendo, alguien propone que el nuevo miembro debe publicar directamente (la propuesta es en
privado). Si los administradores están de acuerdo, se le da acceso directo al repositorio del proyecto.

CollabNet había contratado a Mike específicamente para trabajar en Subversion. Entre aquellos que ya lo
conocían, no había ninguna duda acerca de sus habilidades de codificación o su disposición a trabajar en
el proyecto. Además, los desarrolladores voluntarios tenían una muy buena relación con los empleados
de CollabNet, y lo más probable es que no se hubieran opuesto si se habría dado a Mike derecho de envío
directo de parches al repositorio público del proyecto desde el día en que fue contratado. Pero sabíamos
que estaríamos sentando un precedente. Si lo hacíamos, estaríamos diciendo que CollabNet tenía el
derecho de ignorar las directrices del proyecto, simplemente porque era el principal financista. El daño
no necesariamente sería inmediatamente evidente, pero los desarrolladores no asalariados pueden
sentirse marginados. Dirían que otras personas tienen que ganarse su acceso directo al repositorio,
CollabNet sólo lo compra.

Contratación
¿Se resentirán los otros desarrolladores porque algunos son pagados por trabajar en el proyecto? En
general, no, sobre todo cuando los desarrolladores pagados son respetados miembros de la comunidad.
No se espera que todos los desarrolladores tengan contratos de trabajo. Se debe propender a las
relaciones a largo plazo en los contratos de trabajo: las incertidumbres involucradas en la contratación
son tales que una vez que se encuentre a alguien que pueda trabajar de forma fiable, no es buena idea
cambiar a una persona diferente sólo por el bien de la imparcialidad.

Revisión y aceptación de los cambios

La comunidad sigue siendo importante para el éxito del contrato de trabajo. Su participación en el proceso
de diseño y revisión de los cambios importantes no pueden ser subestimadas. Debe ser considerada como
parte del trabajo, y plenamente aceptada por la persona contratada. No se piense en el escrutinio de la
comunidad como un obstáculo que hay que superar, piense en ella como una mesa de diseño libre y como
que es el departamento de control de calidad. Es un beneficio que debe ser agresivamente perseguido,
no sólo soportado.

MIGUEL ORQUERA 5
 DINERO EN EL SOFTWARE LIBRE

CASO DE ESTUDIO: el protocolo de autenticación de contraseña-CVS

“En 1995, yo era parte de una asociación que proporciona apoyo y mejoras para el CVS (Concurrent
Versions System; ver http://www.cvshome.org/). Mi socio Jim y yo éramos, de manera informal, los
administradores de CVS por ese punto. Pero nunca habíamos pensado seriamente acerca de cómo
debemos relacionarnos con la comunidad de desarrollo CVS, en su mayoría voluntarios. Nosotros
asumimos que la comunidad nos enviaría parches, y si nos gustaban los aplicaríamos, y así fue más o
menos cómo funcionaba.

En aquel entonces, la red CVS podría trabajar sólo desde un programa de acceso remoto, como rsh. Utilizar
la misma contraseña para el acceso CVS y para el inicio de sesión era un riesgo de seguridad evidente, y
muchas organizaciones tenían recelo de hacerlo. Un importante banco de inversiones nos contrató para
añadir un nuevo mecanismo de autenticación, con el que se podría utilizar con seguridad CVS en red con
sus oficinas remotas.

Jim y yo tomamos el contrato y nos sentaron a diseñar el nuevo sistema de autenticación. Lo que ocurrió
fue bastante simple (Estados Unidos tenía controles de exportación de código criptográfico en ese
momento, por lo que el cliente sabía que no podíamos implementar una autenticación fuerte), pero como
no teníamos experiencia en el diseño de este tipo de protocolos, cometimos unas cuantas meteduras de
pata que habrían sido evidentes para un experto. Estos errores podrían haber sido fácilmente capturados
si nos hubiéramos tomado el tiempo para escribir una propuesta y poner el trabajo para su revisión por
los otros desarrolladores. Pero nunca lo hicimos, porque no se nos ocurrió pensar en la lista de
desarrolladores como un recurso a ser utilizado. El protocolo de autenticación resultante no fue muy
bueno, y por supuesto, una vez que quedó implementado, era difícil de mejorar, a causa de problemas de
compatibilidad.

La raíz del problema no era la falta de experiencia; podríamos haber aprendido fácilmente lo que
necesitábamos saber. El problema fue nuestra actitud hacia la comunidad de desarrolladores voluntarios.
Tomamos a la aceptación de los cambios por parte de la comunidad como un obstáculo a saltar, y no
como un proceso mediante el cual la calidad podría mejorarse. Ya que estábamos seguros de que casi
cualquier cosa que haríamos sería aceptada, hicimos poco esfuerzo para involucrar a otros.

Obviamente, cuando usted está eligiendo un contratista, usted quiere a alguien con los conocimientos
técnicos adecuados y experiencia para el trabajo. Pero también es importante elegir a alguien con un
historial de interacción constructiva con los demás desarrolladores de la comunidad. De esa manera usted
estará recibiendo algo más que una sola persona; estará ganando un agente capaz de disponer de una red
de expertos para asegurarse que el trabajo se realiza de una manera robusta y fácil de mantener.

MIGUEL ORQUERA 6