Dinero
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.
Tipos de participación
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:
Compartiendo la carga
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: ,
Aumentando servicios
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
(descargo: este es mi
trabajo diario, pero es también un ejemplo perfecto de este modelo).
Apoyando las ventas de hardware
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.
Socavando a la competencia
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: (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).
Marketing
Ser asociado con un proyecto OSS popular puede que genere
muy buena publicidad.
Licencias Duales
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
en ). 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.
Donaciones
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.
Contratos Indefinidos
Si está dirigiendo un equipo de desarrolladores en un proyecto
de software libre, intente mantenerlos el tiempo suficiente para que
adquieran experiencia técnica y política—un par de años como mínimo.
Por supuesto que ningún proyecto, sea de código abierto o cerrado, se
beneficia del intercambio incesante de programadores. La necesidad de que
un recien llegado deba aprender todo de nuevo cada vez puede crear un
ambiente disuasorio. Pero el castigo puede ser mayor para un proyecto
de código abierto porque quienes abandonan el proyecto no sólo lo hacen
con el conocimiento del código, también se llevan un status en la comunidad
y las relaciones que hayan hecho.
La credibilidad acumulada por un desarrollador no puede ser
transferida. El ejemplo más obvio es que un desarrollador recien
incorporado no puede heredar los mismo accesos al código de quien
se va (más en ), así que si el nuevo
desarrollador no tiene permisos para realizar cambios, deberá enviar
parches hasta que tenga estos permisos. Pero este nivel de acceso
es sólo una manifestación cuantitativa de la perdida de influencia.
Un desarrollador veterano tambien conoce los viejos temas que han sido
tratados una y otra vez en las listas de discusión. Uno nuevo, sin
tener conocimiento de estas conversaciones quizás intente sacar a flote
de nuevo estos temas, llevando a una perdida de credibilidad; otros
pueden que piensen: "¿Acaso esta gente no puede recordar nada?". Una nueva
persona tampoco tendrá ninguna sensación política hacia las personalidades
del proyecto, y no podrá influenciar la dirección del desarrollo tan rápida
o sin problemas como alguien que lleva largo tiempo en el proyecto.
Hacer uso de un programa supervisado de mentoraje a los nuevos voluntarios.
El nuevo desarrollador estará contacto directo con la comunidad pública
de desarrollo desde el primer díam comenzando con el arreglo de errores y tareas de
limpieza, para que puedan aprender la base de código y adquirir una reputación
en la comunidad, sin ser un gran compromiso y discusión de diseño. Esto
mientras tanto un desarrollador más experimentado puede estar disponible
para asesorias, y puede supervisar cada comunicado que el novato haga a la
lista de desarrollo, aun cuando esten en hilos en las cuales los desarrolladores
experimentados no presenten mucha atención normalmente. Esto permitirá al
grupo prevenir posibles piedras antes que el novato choque con estas. Motivación
privada y ufera de las listas tambien puede ayudar mucho, especificamente si
el novato no esta acostumbrado a revisiones masivas de pares en su código.
Cuando CollabNet contrata a un nuevo desarrollador para trabajar en
Subversion, nos sentamos y escogemos algunos de los errores que la nueva
persona pueda probarse a si mismo. Discutiremos los lineamientos
técnicos de la soluciones, y despues asignar por lo menos un desarrollador
experimentado para (publicamente) revise los parches que el nuevo
desarrollador públique. Nostros típicamente no vemos el parche hasta
que la lista de desarrollo principal lo identifica, aunque podríamos
si hubiera alguna razón especial. Lo importante es que el desarrollador
novato pase por el proceso de revisión pública, aprenda el código base
mientras que simultaneamente se acostumbre a recibir críticas de
completos extraños. Sin embargo intentamos coordinar los tiempos
para que nuestras revisiones llegen inmediatamente despues que se
publico el parche. De esa manera la primera revisión que la lista
observe será la nuestra y ayude a marcar el tono de la conversación
a otras revisiones. Tambien contribuye a la idea que esta persona se
deberá tratar con seriedad: si los demas ven que que estamos poniendo
de nuestro tiempo para ofrecer revisiones detalladas, con amplias
explicaciones y referencias en los archivos apropiados, apreciarán que
la persona esta siendo parte de algun tipo de entrenamiento, y que probablemente
signifique que será una inversión a largo plazo. Esto puede hacerlos
mas positivamente dispuestos en referendcia a ese desarrollador, por lo menos
al grado de invertir mas tiempo explicandoles sus preguntas y revisando
sus parches.
Aparentar como muchos, no como uno
Sus desarrolladores deberán intentar aparecer en el foro del proyecto
público como un participante individual, en vez de una presencia
corporativa y monolítica. Esto no es por que exista una connotación
negativa dentro de una presencia corporativa (bueno, quizas lo haya,
pero este libro no trata de eso). Si no por que los individuos son
la única fuente de entidad en los proyectos de código abierto y están
estructuralmente equipados para tratar con estos. Un contribuidor
individual puede tener discusiones, corregir errores, promover parches
y crear una credibilidad, votar y así. Una compañia no lo puede hacer.
Al comportarse de una forma descentralizada, evitas simular
una centralización ante la oposición. Permite que tus desarrolladores
no esten de acuerdo entre ellos en la lista de correo. Les permita
revisar cada uno del código de forma pública como lo haría otro miembro.
Preven la votación en grupo, por que se sentirá por otros que debe
haber un principio generalizado y un esfuerzo en monitorearlos.
Hay una diferencia entre ser descentralizado y simplemente aparentar
serlo. Bajo ciertas circumstancias, tener a tus desarrolladores coordinados
tiene su utilidad, y ellos deberán estar preparados para coordinarse
cuando sea necesario. Por ejemplo, cuando se haga una propuesta, habiendo
muchas personas para aceptar en el inicio puede ayudar mucho, al dar
la impresión de un consenso creciente. Otros sentirán que la propuesta
tiene su momento, y que si alguien fuera a objetar, frenaría ese momento.
Aunque, la gente objetará si tiene suficiente razón para hacerlo. No hay
nada de malo en orquestrar un consenso de esta manera, mientras las
objeciones se tomen seriamente. Las manifestaciones públicas de
acuerdos privados no son menos sinceras por haber sido coordinadas
previamente, y no son dañinas mientras no se usen para ignorar argumentos
contrarios. Su proposito es unicamente para inhibir el tipo de personas
que quieren objetar solo para participar; ver
en
para mayor información.
Se abierto sobre tus motivos
Se tan abierto sobre los objetivos de tu organización como puedas
sin comprometer tus secretos industriales. Si quieres que el proyecto
adopte cierta funcionalidad por que, digamos, tus clientes lo han
solicitado, simplemente manifiestalo en la lista de correo. Si los
clientes prefieren permanecerr anónimos, como es en algunos casos,
entonces por lo menos pregúntale si pueden proveer casos anónimos
como ejemplo. Entre más sepa la comunidad de desarrollo por qué
quieres lo que quieres, más tolerante será de lo que propongas.
Al contrario del instinto—tan fácil de adquirir, tan
difícil de de soltar—la información es poder, y entre
más otras personas sepan de tus metas, más control tendrán sobre ti.
Sin embargo, esa creencia es erronea aquí. Al públicamente
solicitar una funcionalidad ( o arreglo del bug, o lo que sea),
ya has puesto tus cartas sobre la mesa. La única
pregunta ahora es si tendrá éxito guiando a la comunidad a compartir
tus metas. Si solo quieres decir lo que quieres, pero no puedes proveer
un ejemplo concreto del por que, tu argumento será débil y las personas
comenzarán a sospechar de una agenda oculta. Pero si das algunos
escenarios concretos mostrando porque la funcionalidad es importante,
se puede alcanzar un efecto dramático en el debate.
Para ver por que esto es así, considera las alternativas. Muy frecuentemente,
debates sobre nuevas funcionalidades o nuevas direcciones son largos
y tediosos. Los argumentos que la gente proclama, usualmente, se reducen a
"Yo quiero X", o el muy popular "En mis años de experiencia como
diseñador de software, X es extremadamente importante a los usuarios /
es algo inútil que no convencerá a nadie." La predictabilidad, de
ausencia de datos del mundo real afecta estos debates, pero
en vez de permitir que se aparten más y más de cualquier vínculo
debe realizarse con usuarios de verdad. Sin ninguna fuerza de contrapeso, el resultado
final probablemente no será determinado por quien sea más articulado, o
persistente o el que tenga más antiguedad.
Como una organización con datos disponibles de muchos clientes,
tienes la oportunidad de proveer solo como una fuerza de contrapeso. Puede
ser un conducto para información que puede de otra manera no tener medios
de alcanzar a la comunidad de desarrollo. El hecho es que la información
le dará soporte a tus deseos y no hay que sentir verguenza por esto. Muchos
desarrolladores no cuentan con mucha experiencia individual sobre como
su software es usado. Cada desarrollador usa el software en su propia
idiosincracia; tanto como sus patrones de uso vayan, ellos se apoyan
en la intuición y adivinanza, y muy en el fondo están concientes de esto. Al
proveer con datos factibles sobre una cantidad amplia de usuarios, está
dando a la comunidad de desarrollo algo que ellos necesitan como el oxígeno.
Mientrás sea presentado de la forma correcta, ellos permitirán de forma
entusiasta, y empujarán en el camino al que quieras ir.
La clave, desde luego, es presentarlo correctamente. Nunca ayudará
insistir que simplemente porque tratas con una gran cantidad de usuarios,
y porque ellos necesitan (o piensas que necesitan) cierta funcionalidad,
por eso tu solución deberá ser implementada. Al contrario, deberás enfocar
tus publicaciones iniciales en el problema, en vez de una solución
particular. Describe en gran detalle la experiencia que tus clientes están
encontrando, ofrece todos los análisis que tengas, y todas aquellas soluciones razonables
que se te puedan ocurrir. Cuando las personas comiencen a especular
sobre la eficiencia de diversas soluciones, puedes continuar indicando con
tus datos como apoyar o rechazar lo que se comente. Podrás tener una solución
particular en mente desde el inicio, pero no la aisles como si se debiera
dar consideración especial. Esto no es manipulación, simplemente comportamiento
de "corredor honesto". Después de todo, tu verdadera meta es resolver el
problema; una solucion es solamente los méritos a un fin. Si la solución
que prefieras realmente es superior, otros desarrolladores reconocerán que
en su propia eventualidad—y lo apoyarán en propio convencimiento, de
que es mejor que forzar a que todos implementen tu solución. (También está
la posibilidad que ellos piensen en una mejor solución.)
Esto no significa que nunca podrás salir en defensa de una solución
específica. Pero deberás tener la paciencia para ver que el análisis que
has hecho internamente se repetirá en las listas de desarrollo público.
No envies mensajes diciendo "Sí, eso ya lo probamos, pero no funciona por que
A, B, y C. Al final, la única forma de resolverlo es ..." El problema
no es tanto que suene arrogante sino que da la impresión de que
ya se ha dedicado algún tiempo a lo desconocido pero,
la gente pensará que una gran cantidad de recursos analíticos al problema, fue
realizado a puertas cerradas. Esto hace que parezca que el esfuerzo
ya se hizo y la decisión fue tomada, que el público no es digno de
saberlo y esto puede dar un sentido de resentimiento.
Naturalmente, usted sabrá que tanto esfuerzo
habrá dedicado al problema internamente, y que el saberlo es, en
cierta forma una desventaja. Esto pone a sus dearrolladores en un
pensamiento diferente al de los demás en la lista de correo, reduciendo
sus habilidades para darse cuenta de otros puntos de vista que no han
tenido tiempo de reflexionar sobre el problema. Entre más rápido pueda usted
ponerse a pensar de la misma manera, menor será la variación de efectos
que tendrá. Esta lógica aplica no solo a las situaciones técnicas
individuales, pero también al mandato tan claras como sea posible.
Lo desconocido es siempre más desestabilizador que lo conocido. Si la
gente entiende el por que lo desea, se sentirán mas comodos hablando
con usted aun cuando no esten de acuerdo. Si no pueden entender
lo que lo motiva, ellos asumiran lo peor en ciertos momentos por lo
menos.
Probabemente no podrá publicar todo, desde luego, y las personas
no esperan que lo haga. Todas las organizaciones tienen secretos; quizas
las de lucro tengan más, pero las sin fines de lucro, tambien las
tienen. Si debes promover un cierto curso, pero no puede revelar
sus razones, entonces simplemente ofrezca los mejores argumentos
bajo esta desventaja, y acepte el hecho que quizás no tenga tanta
influencia como penso que tenía en la discusión. Esto es uno de los
compromisos que tendrá que hacer por haber desarrollado una comunidad
fuera de su lista de empleados.
El dinero no te podrá comprar el amor
Si eres un desarrollador pagado en un proyecto, entonces fija las guías
temprano en como manejar lo que el dinero puede o no comprar. Esto no significa
qu significa que necesites postear dos veces al día en la lista de correo
reiterando tu nomble e incorrompible naturaleza. Solo significa que
deberás estar en el avistamiento de oportunidades para difuminar la
tensión que podría crearse por dinero. Si no necesitas
comenzar asumiendo que existe una tensión; deberás necesitar demostrar
una conciencia que tienen el potencial de surgir.
Un ejemplo perfecto es por ejemplo si esto llegará en el proyecto de
Subversion fue iniciado en el 2000 por CollabNet, el cual ha sido el
fundador principal principal desde su inicio, pagando los salarios de
diferentes desarrolladores (advertencia: soy uno de estos). Inmediatamente
despues que el proyecto comenzara, contratamos a otro desarrollador, Mike
Pilato, para unirse al esfuerzo. La programación, ya habia iniciado para
entonces. Aunque subversion aún estaba en las etapas iniciales, tenía
una comunidad de desarrollo que pondría las reglas bases.
La llegada de Mike puso un cuestionamiento interesante. Subversion
ya tenía una política sobre como un programador novato obtendría acceso
a contribuir código. Primero, el deberá meter algunos parches
y reportarlos a la lista de desarrollo. Despues que suficientes parches
han sido públicados para que los otros contribuidores vean que el
contribuyente novato sabe lo que está haciendo, algien propondrá que
haga sus contribuciones directamente (está propuesta es privada,
como se describe en ). Asumiendo que
el contribuyente está de acuerdo, uno de los correos del nuevo
desarrollador y se le ofrece acceso directo a contruir en el repositorio
del proyecto.
CollabNet ha contratado a Mike especificamente para trabajar en
Subversion. Entre los que ya conocian a Mike, no habia duda sobre sus
habilidades de programación o su competencia para trabajar en el
proyecto. Mas aun, los voluntarios desarrolladores tienen una muy
buena relación con los empleados de CollabNet, y muy probablemente
no hubieran objetado el darle acceso a contribuir el dia que fue
contratado. Pero sabiamos que dejariamos un precedente. Si le dieramos
acceso de contrubución instantaneamente, estariamos enviando el
mensaje que CollabNet tiene el derecho de ignorar sus propios lineamientos
de proyectos, simplemente por que es el fundador principal. Aunque los
daños no serían aparentes inmediatamente, esto gradualmente resultará
en desarrolladores independientes un tanto excluidos. Otras personas
deberán ganarse los derechos de contribución—mientras CollabNet
solo compra los derechos.
Así que Mike acepto empezar su empleo en CollabNet como cualquier
otro voluntario desarrollador, sin derecho a contribuir. El envio
los parches a la lista pública de la lista de correo, donde pudiese
ser revisado por todos. Tambien dijimos en la lista que estabamos
haciendo estas cosas deliberadamente, para que no hubiera malentendidos.
Despues de un par de semanas de actividad solida por parte de Mike,
alguien () le propuso permisos de contribución y el acepto, como
el supo que sería.
That kind of consistency gets you a credibility that money could
never buy. And credibility is a valuable currency to have in
technical discussions: it's immunization against having one's motives
questioned later. In the heat of argument, people will sometimes look
for non-technical ways to win the battle. The project's primary
funder, because of its deep involvement and obvious concern over the
directions the project takes, presents a wider target than most. By
being scrupulous to observe all project guidelines right from the
start, the funder makes itself the same size as everyone else.
(See also Danese Cooper's blog at
for a similar story about commit access. Cooper was then Sun
Microsystem's "Open Source Diva"—I believe that was her official
title—and in the blog entry, she describes how the Tomcat
development community got Sun to hold its own developers to the same
commit-access standards as the non-Sun developers.)
The need for the funders to play by the same rules as everyone
else means that the Benevolent Dictatorship governance model (see
in ) is slightly
harder to pull
off in the presence of funding, particularly if the dictator works for
the primary funder. Since a dictatorship has few rules, it is hard
for the funder to prove that it's abiding by community standards, even
when it is. It's certainly not impossible; it just requires a project
leader who is able to see things from the point of view of the outside
developers, as well as that of the funder, and act accordingly. Even
then, it's probably a good idea to have a proposal for non-dictatorial
governance sitting in your back pocket, ready to be brought out the
moment there are any indications of widespread dissatisfaction in the
community.
Contrataciones
Contracted work needs to be handled carefully in free software
projects. Ideally, you want a contractor's work to be accepted by the
community and folded into the public distribution. In theory, it
wouldn't matter who the contractor is, as long as his work is good and
meets the project's guidelines. Theory and practice can sometimes
match, too: a complete stranger who shows up with a good patch
will generally be able to get it into the
software. The trouble is, it's very hard to produce a good patch for
a non-trivial enhancement or new feature while truly being a complete
stranger; one must first discuss it with the rest of the project. The
duration of that discussion cannot be precisely predicted. If the
contractor is paid by the hour, you may end up paying more than you
expected; if he is paid a flat sum, he may end up doing more work
than he can afford.
There are two ways around this. The preferred way is to make an
educated guess about the length of the discussion process, based on
past experience, add in some padding for error, and base the contract
on that. It also helps to divide the problem into as many small,
independent chunks as possible, to increase the predictability of each
chunk. The other way is to contract solely for delivery of a patch,
and treat the patch's acceptance into the public project as a separate
matter. Then it becomes much easier to write the contract, but you're
stuck with the burden of maintaining a private patch for as long as
you depend on the software, or at least for as long as it takes you to
get that patch or equivalent functionality into the mainline. Of
course, even with the preferred way, the contract itself cannot
require that the patch be accepted into the code, because that would
involve selling something that's not for sale. (What if the rest of
the project unexpectedly decides not to support the feature?)
However, the contract can require a bona
fide effort to get the change accepted by the
community, and that it be committed to the repository if the community
agrees with it. For example, if the project has written standards
regarding code changes, the contract can reference those standards and
specify that the work must meet them. In practice, this usually works
out the way everyone hopes.
The best tactic for successful contracting is to hire one of the
project's developers—preferably a committer—as the
contractor. This may seem like a form of purchasing influence, and,
well, it is. But it's not as corrupt as it might seem. A developer's
influence in the project is due mainly to the quality of his code and
to his interactions with other developers. The fact that he has a
contract to get certain things done doesn't raise his status in any
way, and doesn't lower it either, though it may make people scrutinize
him more carefully. Most developers would not risk their long-term
position in the project by backing an inappropriate or widely disliked
new feature. In fact, part of what you get, or should get, when you
hire such a contractor is advice about what sorts of changes are
likely to be accepted by the community. You also get a slight shift
in the project's priorities. Because prioritization is just a matter
of who has time to work on what, when you pay for someone's time, you
cause their work to move up in the priority queue a bit. This is a
well-understood fact of life among experienced open source developers,
and at least some of them will devote attention to the contractor's
work simply because it looks like it's going to get
done, so they want to help it get done right. Perhaps they
won't write any of the code, but they'll still discuss the design and
review the code, both of which can be very useful. For all these
reasons, the contractor is best drawn from the ranks of those already
involved with the project.
This immediately raises two questions: Should contracts ever be
private? And when they're not, should you worry about creating
tensions in the community by the fact that you've contracted with some
developers and not others?
It's best to be open about contracts, when you can. Otherwise,
the contractor's behavior may seem strange to others in the
community—perhaps he's suddenly giving inexplicably high
priority to features he's never shown interest in in the past. When
people ask him why he wants them now, how can he answer convincingly
if he can't talk about the fact that he's been contracted to write
them?
At the same time, neither you nor the contractor should act as
though others should treat your arrangement as a big deal. Too often
I've seen contractors waltz onto a development list with the attitude
that their posts should be taken more seriously simply because they're
being paid. That kind of attitude signals to the rest of the project
that the contractor regards the fact of the contract—as opposed
to the code resulting from the contract—to
be the important thing. But from the other developers' point of view,
only the code matters. At all times, the focus of attention should be
kept on technical issues, not on the details of who is paying whom.
For example, one of the developers in the Subversion community handles
contracting in a particularly graceful way. While discussing his code
changes in IRC, he'll mention as an aside (often in a private remark,
an IRC privmsg, to one of the other committers)
that he's being paid for his work on this particular bug or feature.
But he also consistently gives the impression that he'd want to be
working on that change anyway, and that he's happy the money is making
it possible for him to do that. He may or may not reveal his
customer's identity, but in any case he doesn't dwell on the contract.
His remarks about it are just an ornament to an otherwise technical
discussion about how to get something done.
That example shows another reason why it's good to be open about
contracts. There may be multiple organizations sponsoring contracts
on a given open source project, and if each knows what the others are
trying to do, they may be able to pool their resources. In the above
case, the project's largest funder (CollabNet) is not involved in any
way with these piecework contracts, but knowing that someone else is
sponsoring certain bug fixes allows CollabNet to redirect its
resources to other bugs, resulting in greater efficiency for the
project as a whole.
Will other developers resent that some are paid for working on
the project? In general, no, particularly when those who are paid are
established, well-respected members of the community anyway. No one
expects contract work to be distributed equally among all the
committers. People understand the importance of long-term
relationships: the uncertainties involved in contracting are such that
once you find someone you can work reliably with, you would be
reluctant to switch to a different person just for the sake of
evenhandedness. Think of it this way: the first time you hire, there
will be no complaints, because clearly you had to pick
someone—it's not your fault you can't hire
everyone. Later, when you hire the same person a second time, that's
just common sense: you already know him, the last time was
successful, so why take unnecessary risks? Thus, it's perfectly
natural to have one or two go-to people in the community, instead of
spreading the work around evenly.
Financiando actividades fuera de programación
Programming is only part of the work that goes on in an open
source project. From the point of view of the project's volunteers,
it's the most visible and glamorous part. This unfortunately means
that other activities, such as documentation, formal testing, etc., can
sometimes be neglected, at least compared to the amount of attention
they often receive in proprietary software. Corporate organizations
are sometimes able to make up for this, by devoting some of their
internal software development infrastructure to open source
projects.
The key to doing this successfully is to translate between the
company's internal processes and those of the public development
community. Such translation is not effortless: often the two are not
a close match, and the differences can only be bridged via human
intervention. For example, the company may use a different bug
tracker than the public project. Even if they use the same tracking
software, the data stored in it will be very different, because the
bug-tracking needs of a company are very different from those of a
free software community. A piece of information that starts in one
tracker may need to be reflected in the other, with confidential
portions removed or, in the other direction, added.
The sections that follow are about how to build and maintain
such bridges. The end result should be that the open source project
runs more smoothly, the community recognizes the company's investment
of resources, and yet does not feel that the company is
inappropriately steering things toward its own goals.
Control de calidad (i.e., Examinación profesional)
In proprietary software development, it is normal to have teams
of people dedicated solely to quality assurance: bug hunting,
performance and scalability testing, interface and documentation
checking, etc. As a rule, these activities are not pursued as
vigorously by the volunteer community on a free software project.
This is partly because it's hard to get volunteer labor for
unglamorous work like testing, partly because people tend to assume
that having a large user community gives the project good testing
coverage, and, in the case of performance and scalability testing,
partly because volunteers often don't have access to the necessary
hardware resources anyway.
The assumption that having many users is equivalent to having
many testers is not entirely baseless. Certainly there's little point
assigning testers for basic functionality in common environments: bugs
there will quickly be found by users in the natural course of things.
But because users are just trying to get work done, they do not
consciously set out to explore uncharted edge cases in the program's
functionality, and are likely to leave certain classes of bugs
unfound. Furthermore, when they discover a bug with an easy
workaround, they often silently implement the workaround without
bothering to report the bug. Most insidiously, the usage patterns of
your customers (the people who drive your
interest in the software) may differ in statistically significant ways
from the usage patterns of the Average User In The Street.
A professional testing team can uncover these sorts of bugs, and
can do so as easily with free software as with proprietary software.
The challenge is to convey the testing team's results back to the
public in a useful form. In-house testing departments usually have
their own way of reporting test results, involving company-specific
jargon, or specialized knowledge about particular customers and their
data sets. Such reports would be inappropriate for the public bug
tracker, both because of their form and because of confidentiality
concerns. Even if your company's internal bug tracking software
were the same as that used by the public project, management might
need to make company-specific comments and metadata changes to the
issues (for example, to raise an issue's internal priority, or
schedule its resolution for a particular customer). Usually such
notes are confidential—sometimes they're not even shown to the
customer. But even when they're not confidential, they're of no
concern to the public project, and therefore the public should not be
distracted with them.
Yet the core bug report itself is important
to the public. In fact, a bug report from your testing department is
in some ways more valuable than one received from users at large,
since the testing department probes for things that other users won't.
Given that you're unlikely to get that particular bug report from any
other source, you definitely want to preserve it and make it
available to the public project.
To do this, either the QA department can file issues directly in
the public issue tracker, if they're comfortable with that, or an
intermediary (usually one of the developers) can "translate" the
testing department's internal reports into new issues in the public
tracker. Translation simply means describing the bug in a way that
makes no reference to customer-specific information (the reproduction
recipe may use customer data, assuming the customer approves it, of
course).
It is somewhat preferable to have the QA department filing
issues in the public tracker directly. That gives the public a more
direct appreciation of your company's involvement with the project:
useful bug reports add to your organization's credibility just as any
technical contribution would. It also gives developers a direct line
of communication to the testing team. For example, if the internal QA
team is monitoring the public issue tracker, a developer can commit a
fix for a scalability bug (which the developer may not have the
resources to test herself), and then add a note to the issue asking
the QA team to see if the fix had the desired effect. Expect a bit of
resistance from some of the developers; programmers have a tendency to
regard QA as, at best, a necessary evil. The QA team can easily
overcome this by finding significant bugs and filing comprehensible
reports; on the other hand, if their reports are not at least as good
as those coming from the regular user community, then there's no point
having them interact directly with the development team.
Either way, once a public issue exists, the original internal
issue should simply reference the public issue for technical content.
Management and paid developers may continue to annotate the internal
issue with company-specific comments as necessary, but use the public
issue for information that should be available to everyone.
You should go into this process expecting extra overhead.
Maintaining two issues for one bug is, naturally, more work than
maintaining one issue. The benefit is that many more coders will see
the report and be able to contribute to a solution.
Aviso legal y protecciones
Corporaciones, con y sin fines de lucro, son las únicas entidades
que ponen atención de problemas legales complejos en el software libre.
Desarrolladores individuales usualmente entienden las molestias de
diferentes licencias abiertas, pero generalmente no tienen el tiempo o
recursos de seguir los derechos de autor, trademark, y leyes de
patentes en detalles. Si su compañia tiene un departamento legal, puede
ayudar al proyecto vetando el estatus de copyright del códgio, y
ayudar a desarrolladores entender posibles patentes y problemas de
trademark. Las formas exactas que esta ayuda puede tomar es discutidas
en . Lo más importante es asegurarse que la
comunicación entre el departamente legal y la comunidad de desarrollo,
si pasan del todo, aparece con apreciación mutua de diferentes
universos de donde vienen las partes. En ocaciones, estos dos grupos
hablan de más, cada parte asumen saber más sobre partes especificas
más que el otro y que el otro carece. Una buena estrategia es de tener
un moderador (usualmente un desarrollador, o un abogado con expertise
técnico) que se plante en medio y tradusca lo que sea necesario.
Documentación y Usabilidad
Documentation and usability are both famous weak spots in open
source projects, although I think, at least in the case of
documentation, that the difference between free and proprietary
software is frequently exaggerated. Nevertheless, it is empirically
true that much open source software lacks first-class documentation
and usability research.
If your organization wants to help fill these gaps for a
project, probably the best thing it can do is hire people who
are not regular developers on the project, but
who will be able to interact productively with the developers.
Not hiring regular developers is good for two reasons: one, that way
you don't take development time away from the project; two, those
closest to the software are usually the wrong people to write
documentation or investigate usability anyway, because they have
trouble seeing the software from an outsider's point of view.
However, it will still be necessary for whoever works on these
problems to communicate with the developers. Find people who are
technical enough to talk to the coding team, but not so expert in the
software that they can't empathize with regular users anymore.
A medium-level user is probably the right person to write good
documentation. In fact, after the first edition of this book was
published, I received the following email from an open source
developer named Dirk Reiners:
One comment on Money::Documentation and Usability: when we had some
money to spend and decided that a beginner's tutorial was the most
critical piece that we needed we hired a medium-level user to write it.
He had gone through the induction to the system recently enough to
remember the problems, but he had gotten past them so he knew how to
describe them. That allowed him to write something that needed only
minor fixes by the core developers for the things that he hadn't gotten
right, but still covering the 'obvious' stuff devs would have missed.
His case was even better, as it had been his job to introduce a bunch of
other people (students) to the system, so he combined the experience of
many people, which is something that was just a lucky occurrence and is
probably hard to get in most cases.
Proveyendo Alojamiento/Ancho de banda
For a project that's not using one of the free canned hosting
sites (see
in
), providing a
server and network connection—and most importantly, system
administration help—can be of significant assistance. Even if
this is all your organization does for the project, it can be a
moderately effective way to obtain good public relations karma, though
it will not bring any influence over the direction of the
project.
You can probably expect a banner ad or an acknowledgment on the
project's home page, thanking your company for providing hosting. If
you set up the hosting so that the project's web address is under your
company's domain name, then you will get some additional association
just through the URL. This will cause most users to think of the
software as having something to do with your
company, even if you don't contribute to development at all. The
problem is, the developers are aware of this associative tendency too,
and may not be very comfortable with having the project in your domain
unless you're contributing more resources than just bandwidth. After
all, there are a lot of places to host these days. The community may
eventually feel that the implied misallocation of credit is not worth
the convenience brought by hosting, and take the project elsewhere.
So if you want to provide hosting, do so—but either plan to get
even more involved soon, or be circumspect about how much involvement
you claim.
Marketing
Aunque muchos desarrolladores de código abierto probablemente odien
admitirlo, el marketing funciona. Una buena campaña de marketing
puede crear ruido a un producto de código abierto.
Aun hasta el punto donde el programador más conservador se encuentra
con sentimientos positivos sobre el software por razones que no puede
señalar precisamente. No es mi lugar aquí el disectar la dinamica del
efecto del marketing en general. Cualquier corporación involucrada en
software libre se encontrará eventualmente considerando como presentarse
y promoverse, el software, o las relaciones con el software. El consejo
a continuacion es para saber como evitar posibles errores en este esfuerzo;
ver tambien
en
.
Recuerda que estas siendo observado
For the sake of keeping the volunteer developer community on
your side, it is very important not to say
anything that isn't demonstrably true. Audit all claims carefully
before making them, and give the public the means to check your claims
on their own. Independent fact checking is a major part of open
source, and it applies to more than just the code.
Naturally no one would advise companies to make unverifiable
claims anyway. But with open source activities, there is an unusually
high quantity of people with the expertise to verify
claims—people who are also likely to have high-bandwidth
Internet access and the right social contacts to publicize their
findings in a damaging way, should they choose to. When Global
Megacorp Chemical Industries pollutes a stream, that's verifiable, but
only by trained scientists, who can then be refuted by Global
Megacorp's scientists, leaving the public scratching their heads and
wondering what to think. On the other hand, your behavior in the open
source world is not only visible and recorded; it is also easy for many
people to check it independently, come to their own conclusions, and
spread those conclusions by word of mouth. These communications
networks are already in place; they are the essence of how open source
operates, and they can be used to transmit any sort of information.
Refutation is usually difficult, if not impossible, especially when
what people are saying is true.
For example, it's okay to refer to your organization as having
"founded project X" if you really did. But don't refer to yourself as
the "makers of X" if most of the code was written by outsiders.
Conversely, don't claim to have a deeply involved volunteer developer
community if anyone can look at your repository and see that there are
few or no code changes coming from outside your organization.
Not too long ago, I saw an announcement by a very well-known
computer company, stating that they were releasing an important
software package under an open source license. When the initial
announcement came out, I took a look at their now-public version
control repository and saw that it contained only three revisions. In
other words, they had done an initial import of the source code, but
hardly anything had happened since then. That in itself was not
worrying—they'd just made the announcement, after all. There
was no reason to expect a lot of development activity right
away.
Some time later, they made another announcement. Here is what
it said, with the name and release number replaced by pseudonyms:
We are pleased to announce that following
rigorous testing by the Singer Community, Singer 5 for Linux
and Windows are now ready for production use.
Curious to know what the community had uncovered in "rigorous
testing," I went back to the repository to look at its recent change
history. The project was still on revision 3. Apparently, they
hadn't found a single bug worth fixing before the
release! Thinking that the results of the community testing must have
been recorded elsewhere, I next examined the bug tracker. There were
exactly six open issues, four of which had been open for several months
already.
This beggars belief, of course. When testers pound on a large
and complex piece of software for any length of time, they will find
bugs. Even if the fixes for those bugs don't make it into the
upcoming release, one would still expect some version control activity
as a result of the testing process, or at least some new issues. Yet
to all appearances, nothing had happened between the announcement of
the open source license and the first open source release.
The point is not that the company was lying about the community
testing. I have no idea if they were or not. But they were oblivious
to how much it looked like they were lying.
Since neither the version control repository nor the issue tracker
gave any indication that the alleged rigorous testing had occurred,
the company should either not have made the claim in the first place,
or provided a clear link to some tangible result of that testing ("We
found 278 bugs; click here for details"). The latter would have
allowed anyone to get a handle on the level of community activity very
quickly. As it was, it only took me a few minutes to determine that
whatever this community testing was, it had not left traces in any of
the usual places. That's not a lot of effort, and I'm sure I'm not
the only one who took the trouble.
Transparencia y verificabilidad son tambien importante parte de
la acreditación acertada, desde luego. Ver
en
para más del tema.
No ataques proyectos de código abierto que compitan on el suyo
Abstente de dar opiniones negativas a otros proyectos libres
que compitan con el tuyo. Es perfectamente bien mostrar
hechos—negativos que son, acerciones
faciles de confirmar del tipo visto en muchas tablas comparativas.
Sin embargo, la caracterización negativa es menos rigurosa en
naturaleza y es mjeor ser evitada, por dos razones. Primera, es
que eres responzable de comenzar una guerra de discusión que pueda
distraer de una discusión productiva. Segundo, y más importante,
algunos de los desarrolladores voluntarios en tu
proyecto pueden estar involucrados en estos proyectos
que compitan con el tuyo también. Esto puede ser más probable de
lo que originalmente aparente: el proyecto esta ya en el mismo
dominio (por eso estan compitiendo), y los desarrolladores con
esa experiencia en este dominio puede hacer contribuciones en
donde la misma sea aplicable. Aún cuando no sean desarrolladores
tán involucrados al mismo grado, es probable que por lo menos existan
desarrolladores que esten observando tu proyecto. La habilidad de
mantener vínculos constructivos personales pueden ser dañados
por mensajes de marketing demasiado negativos.
Hablando mal de productos de código cerrado parece ser más ampliamente
aceptado en el mundo del software libre, especialmente cuando estos
productos son hechos por Microsoft. Personalmente, yo deploro esta
tendencia (aunque al miso tiempo, no hay nada malo en comparaciones
factuales), no solo por que es mala educación, pero también por que
es peligroso por que un proyecto puede empezar a creerse esta fama
e ignorar areas donde el otro proyecto sea en realidad superior.
En general, estate atento del efecto que las declaraciones de marketing
pueden tener en tu propia comunidad de desarrollo. Las personas pueden
estar tan emocionadas de ser respaldadas por algunos dolares de
marketing que pierdan la objetvidiad sobre las verdaderas fuerzas y
debilidades. Es normal, y aun esperados, para una empresa de desarrolladores
el exhibir cierto repudio a las declaraciones de marketing, aun en foros
públicos. Claramente, ellos no deberán contradecir el mensaje de marketing
directamente (a menos que sean erroneos, aunque uno espera que estas cosas
sean detectados más temprano). Pero quizas se mofen de esto de vez en
cuando, como una forma de traer el resto de la comunidad de desarrollo
de vuelta a la realidad.