Cuando se maneja un proyecto libre, no se necesita hablar todos los días sobre esos enfoques filosóficos. Los programadores no pretenden que todos los integrantes del proyecto estén de acuerdo con sus puntos de vista en todos los aspectos (aquellos que insisten en hacerlo se encuentran rápidamente incapacitados para trabajar en cualquier proyecto). Pero se necesita estar advertido de que la cuestión de "libre" contra "fuente abierta" existe, en parte para evitar decir cosas que pueden enemistarlo a uno con algún otro participante, y en parte porque un entendimiento con los demás y sus motivaciones es la mejor manera, y—en cierto sentido—la única manera de llevar adelante el proyecto.
El software libre es una cultura por elección. Para trabajar con éxito en ella hay que entender por qué hay personas que la eligen en primer lugar. Las técnicas coercitivas no tienen efecto. Si hay alguien que no se siente cómodo en un proyecto, recurre a otro. El software libre se distingue incluso entre las comunidades de voluntarios por sus inversiones limitadas. Muchos de los participantes nunca se encuentran cara a cara, y simplemente hacen donación de algún tiempo cada vez que se sienten motivados. Los conductos normales que conectan a los seres humanos entre sí y se concretan en grupos duraderos se reducen a un pequeño canal: la palabra escrita, trasmitida por cables eléctricos. Por esto puede llevar mucho tiempo para formar un grupo dedicado y unido. Y a la inversa, es muy fácil que un proyecto pierda un voluntario potencial en los cinco primeros minutos de haberse encontrado. Si el proyecto no impacta con una buena impresión, los recién llegados podrían esperar mucho tiempo para darle una segunda oportunidad.
La transitoriedad real o potencial de las relaciones es quizás la tarea más desalentadora que se debe enfrentar en un nuevo proyecto. ¿Qué va a persuadir a toda esa gente a permanecer juntos el tiempo suficiente necesario para producir algo útil? La respuesta es tan compleja como para ocupar el resto de este libro, pero si se tiene que expresar en una sola frase, sería la siguiente:
Las personas deben sentir que su conexión con un proyecto, y su influencia sobre él, es directamente proporcional a sus contribuciones.
Ningún desarrollador, real o potencial, debe sentir que no es tenido en cuenta o es discriminado por razones que no sean técnicas. [11] Claramente, los proyectos con apoyo de empresas y/o desarrolladores pagos tienen que ser especialmente cuidadosos en este aspecto, como se expresa en detalle en el Capítulo 5, Dinero. Por supuesto, esto no quiere decir que si no hay apoyo de empresas no hay nada de que preocuparse. El dinero es sólo uno de los tantos factores que pueden afectar el éxito de un proyecto. Otras cuestiones son el lenguaje que se va a elegir, la licencia, cuál será el proceso de desarrollo, qué tipo de infraestructura hay que instalar, cómo promocionar efectivamente el arranque del proyecto, y muchas otras cosas más. El contenido del próximo capítulo será cómo dar el primer paso con el pie correcto al comenzar un proyecto.
[11] Puede haber casos en los que discrimines a ciertos desarrolladores debido a la conducta que, aunque no está relacionada con sus aportes técnicos, tiene el potencial de dañar el proyecto. Eso es razonable: su comportamiento es relevante porque en el largo plazo tendrá un efecto negativo en el proyecto. Debido a la variedad de las culturas humanas, no puedo dar ni una sola regla breve para cubrir todos esos casos, excepto decir que debes tratar de dar la bienvenida a todos los colaboradores potenciales y, si tienes que discriminar, hazlo sólo en base al comportamiento real, y no sobre la base del grupo de afiliación de un contribuyente o su identidad de grupo.