Prefacio

Tabla de contenidos

¿Por qué escribir este libro?
¿Quién debería leer este libro?
Fuentes
Reconocimientos
Disclaimer

¿Por qué escribir este libro?

Ahora cuando estoy en una fiesta, la gente no se queda con la mirada en blanco cuando les digo que escribo software libre. "Oh sí, código abierto ¿cómo Linux?" me dicen mientras asiento con aprobación. "¡Sí, exactamente! Eso es lo que hago." Es agradable no sentirse completamente aislado. Antes, la siguiente pregunta era predecible: "¿Cómo ganas dinero haciendo eso?" Para responder, resumiría así la economía del código abierto: existen organizaciones interesadas en que cierta clase de software exista, pero que no necesitan vender copias, sólo quieren asegurarse de que esté disponible y mantenido, como una herramienta en lugar de como un servicio.

La siguiente pregunta no siempre ha tenido que ver con el dinero, sin embargo. El Business Case del software Open Source [1] ya no es tan misterioso, e incluso no-programadores ya entienden—o al menos no se sorprenden—que haya gente empleada en ello a tiempo completo. En su lugar, la siguiente pregunta que voy escuchando cada vez más es "¿Cómo funciona todo esto?"

No tenía una respuesta satisfactoria lista y cuan más duro intentaba pensar en una, más me daba cuenta de cuan complejo realmente es el tema. Llevar un proyecto de software libre no es exactamente como dirigir un negocio (imaginemos tener que negociar constantemente la naturaleza de nuestro producto con un grupo de voluntarios, muchos de los cuales ¡ni siquiera conocemos!). Tampoco es, por varias razones, como llevar una organización sin ánimo de lucro tradicional o un gobierno. Es similar a todas ellas, pero poco a poco he llegado a la conclusión de que el software libre es sui generis. Existen muchas cosas con las que puede ser comparado por su utilidad, pero con ninguna puede ser igualado. En realidad, asumir que el software libre puede ser dirigido es iluso. Un proyecto de software libre puede ser iniciado y puede ser influenciado, fuertemente, por algunas partes interesadas. Pero sus activos no pueden ser hechos propiedad de un sólo dueño, así que mientras haya gente en alguna parte—cualquier parte— interesada en continuar con el proyecto, no puede ser cancelado unilateralmente. Todos tienen poder infinito; nadie tiene poder. Una dinámica muy interesante.

Es por esto que quería escribir este libro en primer lugar, y siete años despues he querido actualizarlo. Los proyectos de software libre han permitido a una nueva cultura evolucionar, un ethos en el cual la libertad de hacer que el software haga cualquier cosa que deseamos sea el eje central, sin embargo, el resultado de esta libertad no es la dispersión de los individuos, cada uno trabajando por su cuenta en el código, sino la colaboración entusiasta. De hecho, ser un cooperador competente es en sí, una de las cualidades más valoradas en el software libre. Dirigir uno de estos proyectos es abordar un tipo de cooperación hipertrofiada, donde la habilidad no es sólo trabajar con otros sino ingeniar nuevas maneras de trabajar en conjunto que pueden producir beneficios tangibles para el desarrollo. Este libro intenta describir las técnicas con las que esto se puede lograr. No es de ninguna manera completo, pero al menos es un inicio.

El buen software libre es ya en sí mismo un objetivo y espero que aquellos lectores que vengan buscando como lograrlo estén satisfechos con lo que van a encontrar aquí. Pero más allá de esto, espero transmitir algo del doloroso placer de trabajar con un equipo motivado de desarrolladores de código abierto y de la interacción con los usuarios en la maravillosa manera directa que el Open Source anima. Participar en un proyecto de software libre exitoso es un profundo placer, y en última instancia es esto lo que mantiene a todo el sistema funcionando.



[1] Los términos "software de código abierto" y "software libre" son sinónimos esenciales en éste contexto; son discutidos en mayor profundidad en el “"Libre" vs "Abierto"”, en Capítulo 1, Introducción.