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. En cambio, últimamente, la siguiente pregunta no siempre ha tenido que ver con el dinero. El Business Case del software Open Source Los términos "código abierto" y "libre" son sinónimos esenciales en éste contexto; son discutidos en mayor profundidad en el , en . ya no es tan misterioso, y muchos no-programadores ya entienden—o al menos no se sorprenden—que haya gente empleada en ello a tiempo completo. En su lugar, la 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. 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 ésta 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 divertido y en última instancia es esto lo que mantiene a todo el sistema funcionando. Este libro está enfocado a desarrolladores y directores que estén considerando iniciar un proyecto de software libre o que ya hayan iniciado uno y estén planeado ¿qué hacer ahora? También debería ser útil para aquellas personas que quieren participar en un proyecto Open Source y que nunca lo han hecho. El lector no necesita ser un programador, pero debe conocer conceptos básicos de ingeniería informática como código fuente, compiladores y parches. Experiencia anterior con software Open Source como usuario o desarrollador no es necesaria. Quienes hayan trabajado en proyectos de software libre con anterioridad probablemente encuentren algunas partes del libro algo obvias y quizas deseen saltar esas secciones. Dado que, potencialmente, existe una amplia audiencia experimientada, he hecho un esfuerzo para etiquetar claramente cada sección y decir cuando algo puede ser omitido por quienes ya están familiarizados en la materia. Mucha de la materia prima para este libro viene de trabajar durante cinco años con el proyecto Subversion (). Subversion es un sistema de código abierto para el control de versiones, escrito desde cero con la intención de reemplazar a CVS como el sistema de control de versiones de facto utilizado por la comunidad Open Source. El proyecto fue iniciado por la empresa en la que trabajo, CollabNet (), a principios del año 2000 y gracias a Dios, CollabNet entendió desde el inicio a llevarlo como un esfuerzo colaborativo y distribuido. Desde el principio tuvimos muchos desarrolladores voluntarios; hoy somos unos 50 en el proyecto, de los cuales sólo unos pocos son empleados de CollabNet. Subversion es de muchas maneras un clásico ejemplo de un proyecto Open Source y termine aproximándome más de lo que originalmente esperaba. Parte de esto fue una cuestión de conveniencia: cada vez que necesitaba un ejemplo de un fenómeno en particular, usualmente podía recordar alguno sobre Subversion. Pero tambien fue una cuestión de verificación. Aunque estoy inmerso en otros proyecto de software libre a diversos niveles, y que converso con amigos y conocidos envueltos en muchos otros, rapidamente me he dado cuenta que al escribir para la imprenta, todas las afirmaciones deben ser verificadas con hechos. No deseaba hacer declaraciones acerca de situaciones presentes en otros proyectos basándome sólo en lo que podía leer en las listas de correo. Si alguien intentase algo así con Subversion sé que sólo estaría en lo correcto la mitad de las veces y equivocado la otra mitad. Así que al buscar inspiración o ejemplos en proyectos con los que no tenía experiencia directa, intentaba primero hablar con algún informador, alguien en quien confiará para explicarme qué estaba sucediendo realmente Subversion ha sido mi trabajo durante los últimos cinco años pero he estado involucrado en el software libre durante otros doce. Otros proyectos que han influenciado éste libro son: El proyecto de la Free Software Foundation GNU Emacs, un editor de texto del cual mantengo algunos paquetes pequeños Sistema de versiones concurrentes, del inglés Concurrent Version System (CVS) en el que trabajé intensamente en 1994‐1995 con Jim Blandy y en el que sigo trabajando intermitentemente desde entonces. La colección de proyectos Open Source conocidos como la Fundación de Software Apache, especialmente en el Apache Portable Runtime (APR) y en el servidor Apache HTTP. OpenOffice.org, las bases de datos Berkeley de Sleepycat y MySQL; No he estado envuelto personalmente en estos proyectos, pero los he observado y, en algunos casos, hablado con personas en ellos. GNU Debugger (GDB) (igual que con los anteriores). Proyecto Debian (igual que con los anteriores). Ésta no es la lista completa, por supuesto. Como muchos de los programadores de Open Source, mantengo varios frentes abiertos en diferentes proyectos, sólo para tener una visión del estado general. No los voy a nombrar a todos aquí, pero seran mencionados a lo largo del libro cuando sea apropiado. Este libro me tomó cuatro veces el tiempo que esperaba para escribirlo, y durante mucho tiempo sentía como si un piano estuviese suspendido sobre mi cabeza a cada lugar al que iba. Sin la ayuda de mucha gente, no habría podido completarlo y seguir cuerdo. Andy Oram, mi editor en O'Reilly fue el sueño de todo escritor. Aparte de conocer el tema intimamente (él sugirió muchos de los temas), tiene el raro don de saber lo que se intenta decir y ayudar a encontrar la manera correcta de decirlo. Ha sido un honor trabajar con él. Gracias tambien a Chuck Toporek por pasarle esta propuesta a Andy Right desde el principio. Brian Fritzpatrick revisó casí todo el material mientras lo escribía, lo que no sólo hizo el libro mejor, sino que me mantuvo escribiendo cuando quería estar en cualquier lugar menos frente a un ordenador. Ben Collins-Sussman y Hike Pilato tambien revisaban de vez en cuando el progreso y siempre se contentaban con discutir, algunas veces en profundidad, cualquier tema que intentaba cubrir esa semana. Tambien se daban cuenta cuando reducía la marcha y gentilmente me regañaban cuando era necesario. Gracias tios. Biela Coleman estaba escribiendo su tesis al mismo tiempo que yo escribía este libro. Ella sabe lo que significa sentarse cada día a escribir, dándome un ejemplo de inspiración así como un oido amigo. Tambien tiene una fascinante vista antropológica del movimiento free software, dándome ideas y referencias que podría utilizar en el libro. Alex Golub—otro antropólogo con un pie en el mundo del software libre—fue un apoyo excepcional que me ayudó inmensamente. Micah Anderson de alguna manera nunca pareció oprimido por su propio trabajo de escritor, el cual me inspiraba en alguna forma enfermiza y envidiable, pero siempre estuvo listo con su amistad, conversación y (al menos en una ocasión) soporte técnico. ¡Gracias Micah! Jon Trowbridge y Sander Striker también me dieron ánimo y ayuda concreta, su amplia experiencia en Software Libre me proveyeron de material que no hubiese podido obtener por ninguna otra vía. Debo agradecer, también, a Greg Stein no solo por su amistad y disposición, sino por mostrar en el proyecto subversion cuan importante es la revisión del código en la construcción de una comunidad de programadores. Gracias también a Brian Behlendorf, quien tácticamente sembró en nuestras cabezas la importancia de las discusiones públicas; Es mi esperanza que este principio se refleje a lo largo de este libro. Thanks to Benjamin "Mako" Hill and Seth Schoen, for various conversations about free software and its politics; to Zack Urlocker and Louis Suarez-Potts for taking time out of their busy schedules to be interviewed; to Shane on the Slashcode list for allowing his post to be quoted; and to Haggen So for his enormously helpful comparison of canned hosting sites. Thanks to Alla Dekhtyar, Polina, and Sonya for their unflagging and patient encouragement. I'm very glad that I will no longer have to end (or rather, try unsuccessfully to end) our evenings early to go home and work on "The Book." Thanks to Jack Repenning for friendship, conversation, and a stubborn refusal to ever accept an easy wrong analysis when a harder right one is available. I hope that some of his long experience with both software development and the software industry rubbed off on this book. CollabNet was exceptionally generous in allowing me a flexible schedule to write, and didn't complain when it went on far longer than originally planned. I don't know all the intricacies of how management arrives at such decisions, but I suspect Sandhya Klute, and later Mahesh Murthy, had something to do with it—my thanks to them both. The entire Subversion development team has been an inspiration for the past five years, and much of what is in this book I learned from working with them. I won't thank them all by name here, because there are too many, but I implore any reader who runs into a Subversion committer to immediately buy that committer the drink of his choice—I certainly plan to. Many times I ranted to Rachel Scollon about the state of the book; she was always willing to listen, and somehow managed to make the problems seem smaller than before we talked. That helped a lot—thanks. Thanks (again) to Noel Taylor, who must surely have wondered why I wanted to write another book given how much I complained the last time, but whose friendship and leadership of Golosá helped keep music and good fellowship in my life even in the busiest times. Thanks also to Matthew Dean and Dorothea Samtleben, friends and long-suffering musical partners, who were very understanding as my excuses for not practicing piled up. Megan Jennings was constantly supportive, and genuinely interested in the topic even though it was unfamiliar to her—a great tonic for an insecure writer. Thanks, pal! I had four knowledgeable and diligent reviewers for this book: Yoav Shapira, Andrew Stellman, Davanum Srinivas, and Ben Hyde. If I had been able to incorporate all of their excellent suggestions, this would be a better book. As it was, time constraints forced me to pick and choose, but the improvements were still significant. Any errors that remain are entirely my own. My parents, Frances and Henry, were wonderfully supportive as always, and as this book is less technical than the previous one, I hope they'll find it somewhat more readable. Finally, I would like to thank the dedicatees, Karen Underhill and Jim Blandy. Karen's friendship and understanding have meant everything to me, not only during the writing of this book but for the last seven years. I simply would not have finished without her help. Likewise for Jim, a true friend and a hacker's hacker, who first taught me about free software, much as a bird might teach an airplane about flying. Los pensamientos y opiniones expresadas en este libro son propias. No representan los puntos de vista de CollabNet o del proyecto Subversion.