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 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 , en . 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. 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 planeando ¿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 APIs, 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 quizás 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 la primera edición de este libro viene de trabajar durante cinco años con el proyecto Subversion (subversion.tigris.org). 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 (collab.net), 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 terminé 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 también 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 involucrados en muchos otros, rápidamente 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 informante, alguien en quien confiara 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 este libro son: El proyecto GNU Emacs de la Free Software Foundation, 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 participé intermitentemente durante algunos años después. 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. El proyecto Launchpad.net en Canonical, Ltd. Code for América y O'Reilly Media, que me dio una visión interna del desarrollo de tecnología cívica de fuente abierta iniciando en 2010, y me mantuvo un poco en el circuito después de que me convertí en un consultor a tiempo completo en 2012. Las muchas herramientas de código abierto anti-vigilancia y evasión de censura soportados por el Proyecto de Herramientas Abiertas de Internet. Checkbook NYC, el software de transparencia financiera municipal publicado por la Oficina de Contraloría de la ciudad de Nueva York. El Proyecto de los Arcos, una aplicación web de código abierto para la gestión de las excavaciones arqueológicas, creado por el Instituto de Conservación Getty y el Fondo Mundial de Monumentos. OpenOffice.org / LibreOffice.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 que participan en ellos. GNU Debugger (GDB) (igual que los anteriores). Proyecto Debian (igual que los anteriores). Esta no es la lista completa, por supuesto. Como muchos de los programadores de Open Source, yo también mantengo varios frentes abiertos en diferentes proyectos de mi interés, sólo para tener una visión de su 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 íntimamente (al sugerir muchos de ellos), 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ó casi 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 también revisaban de vez en cuando el progreso y siempre se contentaban con discutir, algunas veces en profundidad, cualquier tema que intentaba cubrir esa semana. También 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 oído amigo. También tiene una fascinante vista antropológica del movimiento del Software Libre, 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 de una 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 sólo 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. Gracias a Benjamin "Mako" Hill y Seth Schoen, por varias conversaciones sobre el software libre y su política; a Zack Urlocker y Louis Suarez-Potts por tomar tiempo de sus apretadas agendas para ser entrevistados; a Shane en la lista Slashcode por permitir que su artículo pudiera ser citado; y para Haggen So por su gran ayuda en la comparación de hostings enlatados. Gracias a Alla Dekhtyar, Polina, y Sonya por su aliento incansable y paciente. Estoy muy contento de que ya no voy a tener que terminar (o más bien, tratar, sin éxito hasta el final) nuestras noches temprano para volver a casa y trabajar en "El Libro". Gracias a Jack Repenning por la amistad, la conversación, y una obstinada negativa a no aceptar jamás un análisis fácil malo cuando uno más difícil y correcto está disponible. Espero que algo de su larga experiencia tanto en el desarrollo de software como en la industria del software haya contagiado a este libro. CollabNet fue excepcionalmente generosa al permitirme un horario flexible para escribir, y no se quejó cuando llevó mucho más tiempo de lo previsto. No sé todas las complejidades de cómo llega la gestión a este tipo de decisiones, pero sospecho que Sandhya Klute, y más tarde Mahesh Murthy, tuvieron algo que ver con ello—mi agradecimiento a las dos. Todo el equipo de desarrollo de Subversion ha sido una inspiración por los últimos cinco años, y gran parte de lo que hay en este libro lo he aprendido al trabajar con ellos. No doy las gracias a todos ellos por su nombre aquí, porque son demasiados, pero yo imploro que cualquier lector que se encuentre con un committer de Subversion que le compre inmediatamente a ese committer la bebida de su elección—Yo sin duda planeo hacerlo. Muchas veces despotricaba a Rachel Scollon sobre el estado de la obra; ella siempre estaba dispuesta a escuchar, y de alguna manera se las arregló para hacer que los problemas parecieran más pequeños que antes de que habláramos. Eso ayudó mucho—gracias. Gracias (de nuevo) a Noel Taylor, que seguramente se habrá preguntado por qué quería escribir otro libro teniendo en cuenta lo mucho que me quejé la última vez, pero cuya amistad y el liderazgo de Golosá ayudó a mantener la música y el buen compañerismo en mi vida, incluso en los momentos más intensos. Gracias también a Mateo Dean y Dorothea Samtleben, amigos y sufridos compañeros musicales, que eran muy comprensivos como mis excusas para no practicar apilado. Megan Jennings era constantemente un apoyo, y se mostraba interesada en el tema a pesar de que no estaba familiarizada con él, un gran tónico para un escritor inseguro. Gracias, amigo! Yo tenía cuatro revisores expertos y diligentes para este libro: Yoav Shapira, Andrew Stellman, Davanum Srinivas, y Ben Hyde. Si yo hubiera sido capaz de incorporar la totalidad de sus excelentes sugerencias, esto sería un libro mejor. Así las cosas, la falta de tiempo me obligaron a escoger y elegir, pero las mejoras son aún significativas. Los errores que quedan son de mi entera responsabilidad. Mis padres, Frances y Henry, fueron un apoyo maravilloso, como siempre, y como este libro es menos técnico que el anterior, espero que lo encuentren un tanto más legible. Por último, me gustaría dar las gracias a los dedicados, Karen Underhill y Jim Blandy. La amistad y la comprensión de Karen han significado todo para mí, no sólo durante la escritura de este libro, sino durante los últimos siete años. Yo simplemente no habría terminado sin su ayuda. Lo mismo sucede con Jim, un verdadero amigo y pirata de un pirata informático, el primero que me enseñó sobre el software libre, tanto como un pájaro puede enseñar a un avión a volar. Los pensamientos y las opiniones expresadas en este libro son mías propias. No necesariamente representan los puntos de vista de mis clientes, empleadores pasados, la Fundación New América, o los proyectos de software libre discutidos aquí. Ellos, sin embargo, representan la opinión de Jim Blandy. En serio: él está de acuerdo con todo en este libro. Pregúntale.