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 “Committers”). 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 http://blogs.sun.com/roller/page/DaneseCooper/20040916 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 “Dictadores Benevolentes” in Capítulo 4, Infraestructura Social y Política) 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.