Los proyectos en corporaciones tienen gerentes que reportan a otros
gerentes que reportan al CEO que reporta a la junta. Todo es muy simple
en teoría, aunque en realidad nunca funciona de esa manera en la
práctica. Las líneas de control se cruzan cuando las personas forman
alianzas y luchan por mantener contentos a sus jefes.
Los proyectos en el mundo del software de código abierto, por otro lado,
les dan a todos una copia del código fuente y les permiten ser los
maestros del código que se ejecuta en su máquina. Todos pueden ser la
Junta Directiva, el CEO y los siervos del cubículo, todo en uno. Si a un
usuario de software libre no le gusta algo, entonces tiene el poder de
cambiarlo. ¿No te gusta ese icono? Bum, se ha ido. ¿No quieres KDE en tu
escritorio? Whoosh, está fuera de allí. Ningún vicepresidente a cargo
del marketing de MSN en Redmond lo obligará a tener un ícono para una
fácil conexión a Microsoft Network en su escritorio. Ningún diseñador
gráfico en Apple lo obligará a mirar ese logotipo de MacOS de dos caras
al estilo de Picasso todas las mañanas de su vida solo porque sus
estudios de marketing muestran que necesitan construir una identidad de
marca sólida. Eres el capitán de tu barco de software libre y decides el
menú, el rumbo, la disposición de las tumbonas, la ubicación de los
miradores desde los que observar los icebergs, el tipo de jabón y el
número de palillos por pasajero para orden. En teoría, usted es el Lord
High Master y el Más Exaltado Gobernante de todo el software, grande y
pequeño, salvaje y maravilloso, e interpretado y compilado en su
máquina.
En la práctica, nadie tiene tiempo para usar todo ese poder. Es
francamente aburrido preocuparse por el jabón y los palillos de dientes.
Es agotador reconstruir sistemas de ventanas cuando no cumplen con sus
gustos de software de grado caviar.
Nadie tiene el espacio en disco para mantener una colección de
protectores de pantalla, administradores de ventanas, motores de diseño
y juegos para su computadora al estilo de Imelda Marcos. Así que
empiezas a salir con algunos amigos que quieren cosas similares y lo
siguiente que sabes es que tienes un grupo. Un grupo necesita liderazgo,
por lo que surge el perro alfa. Muy pronto, todo comienza a parecerse a
un equipo de desarrollo corporativo. Bueno, algo así.
Muchos neófitos en el mundo del software libre a menudo se sorprenden al
descubrir que la mayor parte del mejor código fuente gratuito que existe
proviene de equipos que se parecen sorprendentemente a grupos de
desarrollo corporativos. Mientras que las licencias y la retórica
prometen la libertad de seguir tu propio camino, los grupos se unen por
muchas de las mismas razones por las que surgen las caravanas y los
convoyes. Hay poder en los números. A veces estos grupos incluso se
ponen tan serios que se incorporan. El grupo Apache formó recientemente
la Fundación Apache, que tiene el trabajo de guiar y apoyar el
desarrollo del servidor web Apache. Todo tiene un aspecto muy oficial.
Por lo que sabemos, ahora mismo están poniendo cubículos en las oficinas
de la fundación.
Este instinto de trabajar juntos es una fuerza tan poderosa en el mundo
del software libre como el instinto de tomar tanta libertad como sea
posible y usarla todos los días. En todo caso, es sólo una
característica esencial de la vida humana. Los fundadores de los Estados
Unidos de América crearon una constitución completa sin mencionar los
partidos políticos, pero una vez que presionaron el botón de inicio, los
partidos aparecieron de la nada.
Estas partes también surgieron en el mundo del software libre. Cuando
los proyectos crecieron más de lo que una persona podía manejar con
seguridad, por lo general se convirtieron en equipos de desarrollo. El
camino de cada grupo es algo diferente, y cada uno desarrolla su propio
estilo particular. La solidez de esta organización suele ser el
determinante más importante de la solidez del software, porque si las
personas pueden trabajar bien juntas, los problemas del software se
resolverán correctamente.
La forma de gobierno más prevalente en estas comunidades es la dictadura
benigna. Richard Stallman escribió algunos de los códigos más
importantes en el panteón de GNU, y continúa escribiendo código nuevo y
ayudando a mantener el software anterior. El mundo del kernel de Linux
está dominado por Linus Torvalds. Los fundadores originales siempre
parecen tener una fuerte influencia sobre el grupo. La mayor parte del
código en el kernel de Linux está escrito por otros y verificado por un
estrecho círculo de amigos, pero Torvalds aún tiene la última palabra
sobre muchos cambios.
Los dos son, por supuesto, dictadores benignos, y los dos realmente no
tienen otra opción. Ambos tienen una cantidad aparentemente absoluta de
poder, pero este poder se basa en una mezcla de afecto personal y
respeto técnico. No hay límites legales que mantengan a todos los
desarrolladores en línea. No hay reglas sobre propiedad intelectual o no
divulgación. Cualquiera puede obtener todo el kernel de Linux o el
código fuente de GNU, ejecutarlo y comenzar a realizar los cambios que
desee. Podrían cambiarle el nombre a FU, Bobux, Fredux o Meganux y nadie
podría detenerlos. Las viejas amenazas de abogados, armas y dinero no se
ven por ninguna parte.
19.1 Equipo central de Debian
El grupo Debian tiene un pedigrí maravilloso y muchos lo elogian como la
versión más pura de Linux que existe, pero comenzó como un grupo de
forajidos que se amotinaron y arrojaron a Richard Stallman por la borda.
Bueno, en realidad no fue tan dramático. De hecho, "motín" no es
realmente la palabra correcta cuando todos son libres de usar el código
fuente como quieran.
Bruce Perens recuerda que la división ocurrió menos de un año después de
que comenzara el proyecto y dice: "Debian ya había comenzado. La FSF
había estado financiando a Ian Murdock durante unos meses. Richard en
ese momento quería que hiciéramos todos los ejecutables sin desmontar".
Cuando los programadores compilan software y lo convierten de un código
fuente legible por humanos a un código binario legible por máquina, a
menudo dejan información legible por humanos para ayudar a depurar el
programa. Otra forma de decir esto es que los programadores no eliminan
las etiquetas de depuración del código. Estas etiquetas son solo los
nombres de las variables utilizadas en el software, y un programador
puede usarlas para analizar qué contenía cada variable cuando el
software comenzó a volverse loco.
Perens continuó: "Su idea era que, si había un problema, alguien podía
enviar un stacktrace sin tener que volver a compilar un programa y luego
hacer que fallara de nuevo. El problema con esto era que la distribución
de los ejecutables sin eliminar los hacía cuatro veces más grandes. Era
un muchos gastos adicionales y problemas. Y nuestro software no volcó el
núcleo de todos modos. Ese fue realmente el resultado final. Ese tipo de
error no apareció tan a menudo como para que tuviéramos que distribuir
las cosas de esa manera de todos modos".
Aun así, Stallman insistió en que era una buena idea. Debian se resistió
y dijo que ocupaba demasiado espacio y aumentaba los costos de
duplicación. Eventualmente, el debate terminó cuando el grupo Debian
siguió su propio camino. Aunque Stallman le pagó a Murdock y escribió
gran parte del código GNU en el disco, la GPL le impidió hacer mucho. El
proyecto continuó. El código fuente sobrevivió. Y los discos de Debian
siguieron enviándose. Stallman ya no era el líder titular de Debian.
La brecha entre el grupo se ha curado en gran medida. Perens ahora
elogia a Stallman y dice que los dos todavía están muy cerca
filosóficamente en los temas más importantes en el mundo del software
libre. Stallman, por su parte, usa Debian en sus máquinas porque siente
la afinidad más cercana con él.
Perens dice: "Richard en realidad ha crecido mucho en los últimos años.
Ha aprendido mucho más sobre qué hacer con un voluntario porque,
obviamente, somos libres de marcharnos en cualquier momento".
El propio Stallman recuerda el argumento con bastante elocuencia: "El
hecho es que quería influir en ellos, pero no quería forzarlos.
Forzarlos iría en contra de mis creencias morales. Creo que las personas
tienen derecho a la libertad en estos asuntos, lo cual significa que no
puedo decirles qué hacer", me dijo. "Escribí la GPL para liberar a todos
de la dominación de los autores de software, y eso me incluye a mí en
ambos lados".
Hay mucho debate sobre la mejor manera de ser un dictador benigno. Eric
Raymond y muchos otros sienten que el mayor reclamo de éxito de Torvalds
fue crear un buen modelo de desarrollo. Torvalds lanzó nuevas versiones
de su kernel con frecuencia y trató de compartir las noticias sobre el
desarrollo de la manera más abierta posible. La mayor parte de estas
noticias viajan a través de una lista de correo abierta a todos y
archivada en un sitio web. La lista de correo es una especie de congreso
perpetuo donde la gente debate los problemas técnicos detrás de los
últimos cambios en el núcleo. A menudo es mucho mejor que el verdadero
Congreso de los Estados Unidos porque el foro de debate está abierto a
todos y no hay intereses especiales evidentes que intenten dirigir el
debate en su dirección. Después de un período de debate, finalmente
Torvalds toma una decisión y esta se convierte en definitiva. Por lo
general, no necesita hacer nada. La respuesta es bastante obvia para
todos los que han seguido la discusión.
Este ejército es un grupo diverso. En una reciente conferencia sobre
Linux, Jeff Bates, uno de los editores del influyente sitio web Slashdot
(www.slashdot.org), me indicó el stand de Debian, que estaba al lado del
suyo. "Si miras en el stand, puedes ver ese mapa. Pusieron una chincheta
en el tablero para cada desarrollador y líder de proyecto que tienen en
todo el mundo. China, Países Bajos, Somalia, hay gente que viene de
todas partes".
James Lewis-Moss es uno de los miembros, que casualmente se encontraba
en el puesto de Debian de al lado. Vive en Asheville, Carolina del
Norte, que está a cuatro horas al oeste del Centro de Convenciones en el
centro de Raleigh. El grupo Debian normalmente depende de voluntarios
locales para atender el stand, responder preguntas, distribuir CD-ROM y
mantener a la gente interesada en el proyecto.
Lewis-Moss está oficialmente a cargo del mantenimiento de varios
paquetes, incluido X Emacs, un programa que se usa para editar archivos
de texto, leer correos electrónicos y noticias, y realizar otras tareas.
Un paquete es el nombre oficial de un conjunto de programas, archivos,
datos y documentación más pequeños. Estas partes normalmente se instalan
juntas porque el software no funcionará sin todos sus componentes.
El trabajo del empaquetador es descargar el software más reciente del
programador y asegurarse de que funcione bien con la última versión del
otro software para la distribución de Debian. Esta tarea crucial es la
razón por la que grupos como Debian son tan necesarios. Si Lewis-Moss
hace bien su trabajo, alguien que instale Debian en su computadora no
tendrá problemas para usar X Emacs.
El trabajo de Lewis-Moss no es exactamente programar, pero está cerca.
Tiene que descargar el código fuente, compilar el programa, ejecutarlo y
asegurarse de que la última versión del código fuente funcione
correctamente con la última versión del kernel de Linux y las demás
partes del sistema operativo que mantienen el sistema en funcionamiento.
El empaquetador también debe asegurarse de que el programa funcione bien
con las herramientas específicas de Debian que facilitan la instalación.
Si hay errores obvios, él mismo los arreglará. De lo contrario,
trabajará con el autor para localizar y solucionar los problemas.
Es bastante modesto acerca de este esfuerzo y dice: "La mayoría de los
desarrolladores de Debian no escriben mucho código para Debian. Solo
probamos las cosas para asegurarnos de que funcionen bien juntas. Sería
ofensivo para algunos de los programadores escuchar eso". algunas
personas de Debian están escribiendo los programas cuando en realidad no
lo hacen".
Agregó que muchos de los empaquetadores también son programadores en
otros proyectos. En su caso, escribe programas Java durante el día para
una empresa que fabrica terminales de punto de venta para tiendas.
Lewis-Moss terminó con este trabajo en la tradicional tradición de los
comités y organizaciones de voluntarios en todas partes. “Informé un
error en X Emacs a Debian. El tipo que tenía el paquete en ese momento
dijo: 'Ya no quiero esto. ¿Lo quieres?' Supongo que fue al azar. Fue una
especie de accidente. No tenía la intención de involucrarme en eso, pero
era algo que me interesaba. Pensé: 'Diablos, también podría'".
El esfuerzo de desarrollo de Linux avanza lentamente con miles de
historias como la de Lewis-Moss. La gente viene, revisa el código y
agrega algunas contribuciones que lo hacen un poco mejor para ellos. La
lista de correo debate algunos de los cambios si son controvertidos o si
afectarán a muchas personas. Es un sistema muy eficiente en muchos
sentidos, si puedes soportar el calor de los debates.
La mayoría de los estadounidenses están bastante alejados de las
acaloradas discusiones que hierven en los pasillos de Washington. La
vista del piso de la Cámara y el Senado es en gran medida solo para
mostrar porque la mayoría de los miembros no asisten a los debates. Las
verdaderas decisiones se toman en cuartos traseros.
Las listas de correo que forman el núcleo de los diferentes proyectos de
software libre toman todo este debate y lo transmiten directamente a los
miembros. Si bien algunas discusiones ocurren en cartas privadas e
incluso en llamadas telefónicas ocasionales, gran parte del problema y
la controversia se diseccionan para que todos los lean. Esto es crucial
porque la mayoría de las decisiones se toman en gran medida por
consenso.
“La mayoría de las decisiones son técnicas y la mayoría de ellas tendrán
la respuesta correcta o la mejor posible en ese momento”, dice
Lewis-Moss. "A menudo, las cosas se reducen a quién está dispuesto a
hacer el trabajo. Si estás dispuesto a hacer el trabajo y la persona del
otro lado no lo está, entonces la tuya es la correcta por definición".
Si bien la lista de correo parece una noción idealizada de un congreso
para el desarrollo del kernel de Linux, no es tan perfecta como parece.
No todos los comentarios son tomados por igual porque las amistades y
alianzas políticas han evolucionado a través del tiempo. El grupo de
Debian eligió a un presidente para tomar decisiones cruciales que no
pueden tomarse mediante argumentos profundos y consenso. El presidente
no tiene muchos otros poderes en otros casos.
Mientras que los mundos de Linux y GNU están dominados por su gran Rey
Sol, muchos otros proyectos de código abierto han adoptado una
estructura de gobierno más moderna que se parece más a Debian. Los
grupos siguen siendo bastante ad hoc y no oficiales, pero son más
democráticos. Hay menos idolatría y menos dependencia de una sola
persona.
El grupo Debian es un buen ejemplo de una estructura muy suelta con
menos dependencia del líder central. Al principio, Ian Murdock inició la
distribución e hizo gran parte de la coordinación. Con el tiempo, la
lista de correo creció y atrajo a otros desarrolladores como Bruce
Perens. A medida que Murdock se volvió más ocupado, comenzó a entregar
trabajo a otros. Eventualmente, entregó el control central a Perens,
quien poco a poco delegó más control hasta que no quedó ningún
mantenedor clave. Si alguien muere en un accidente de autobús, el grupo
seguirá vivo.
Ahora un gran grupo de personas actúan como mantenedores de los
diferentes paquetes. Cualquiera que quiera trabajar en el proyecto puede
asumir la responsabilidad de un paquete en particular. Esta podría ser
una herramienta pequeña como un juego o una herramienta más grande como
el compilador de C. En la mayoría de los casos, el mantenedor no es el
autor del software ni siquiera un programador empedernido. El trabajo
del mantenedor es asegurarse de que el paquete en particular continúe
funcionando con el resto. En muchos casos, este es un trabajo bastante
fácil. La mayoría de los cambios en el sistema no afectan a los
programas simples. Pero en algunos casos es un verdadero desafío y el
mantenedor debe actuar como enlace entre Debian y el programador
original. A veces, los mantenedores corrigen los errores ellos mismos. A
veces simplemente los denuncian. Pero en cualquier caso, el mantenedor
debe asegurarse de que el código funcione.
De vez en cuando, Debian toma el núcleo estable más reciente del equipo
de Torvalds y lo mezcla con todos los demás paquetes. Los mantenedores
revisan sus paquetes y cuando todo funciona bien, Debian presiona otro
CD-ROM y coloca la pila de código en la red. Este es un "congelamiento"
estable que hace el grupo Debian para asegurarse de tener una plataforma
estable a la que la gente siempre pueda recurrir.
"Crear un sistema operativo completo con solo un grupo de voluntarios y
sin dinero es un gran logro. Nunca se puede descartar eso. Red Hat lo
tiene fácil. Todos reciben un pago. El hecho es que Debian es un buen
sistema y aún continúa haciéndolo. No creo que haya habido tantos
proyectos colaborativos no remunerados tan complejos antes", dice
Perens.
Cuando Perens se hizo cargo de Debian, provocó dos cambios importantes.
El primero fue crear una corporación sin fines de lucro llamada Software
in the Public Interest y hacer arreglos para que el IRS la reconociera
como una organización benéfica de buena fe. Las personas y empresas que
donen dinero y equipos pueden descontarlos de sus impuestos.
Perens dice que el presupuesto del grupo es de unos 10.000 dólares al
año. "A veces pagamos por el hardware. Aunque gran parte de nuestro
hardware es donado. Llevamos a la gente a conferencias para que puedan
promocionar Debian. Tenemos un puesto en la feria comercial. En general,
obtenemos el espacio de la feria comercial gratis o con grandes
descuentos . También tenemos los apartados postales convencionales, la
contabilidad, las llamadas telefónicas. El proyecto no tiene mucho
dinero, pero tampoco gasta mucho".
El grupo Debian también escribió las primeras pautas para el software de
código abierto aceptable durante el tiempo que Perens estuvo a cargo.
Estos finalmente mutaron para convertirse en la definición respaldada
por la Iniciativa de código abierto. Esto no es demasiado sorprendente,
ya que Perens fue uno de los fundadores de la Iniciativa de código
abierto.
El éxito de Debian ha inspirado a muchos otros. Red Hat, por ejemplo,
tomó prestada una cantidad significativa del trabajo realizado por
Debian cuando armaron su distribución, y Debian toma prestadas algunas
de las herramientas de Red Hat. Cuando Red Hat salió a bolsa, hizo
arreglos para que los miembros de Debian tuvieran la oportunidad de
comprar algunas de las acciones de la compañía reservadas para amigos y
familiares. Reconocieron que el equipo de mantenedores de paquetes de
Debian ayudó a realizar su trabajo.
La constitución de Debian y su sólida estructura política también han
inspirado a Sun, que está tratando de unir a sus clientes de Java y Jini
en una comunidad. La compañía enmarca sus esfuerzos para apoyar a los
clientes como la creación de una comunidad protegida por una
constitución. El antiguo paradigma de atención al cliente está siendo
reemplazado por un mundo más activo de participación y representación
del cliente.
Por supuesto, Sun se mantiene al tanto de todos estos cambios. Protegen
su código fuente con una Licencia de fuente comunitaria que impone
restricciones cruciales a la capacidad de desviarse de estos miembros de
la comunidad. No hay libertad real para bifurcar. Sun no está dispuesto
a aceptar el liderazgo de Debian en ese punto, en parte porque dicen que
temen que Microsoft use esa libertad para hundir a Java.
19.2 Núcleo corporativo de Apache
El grupo Apache es uno de los equipos de desarrollo más profesionales en
el mundo del código libre. Surgió a mediados de la década de 1990,
cuando la World Wide Web apenas estaba floreciendo. En los primeros
años, muchos sitios dependían de servidores web como la versión gratuita
que venía de la NCSA, el centro de supercomputación de la Universidad de
Illinois que ayudó a desencadenar la revolución web al escribir un
servidor y un navegador. Este código fue excelente, pero rara vez
cumplió con todos los propósitos de los nuevos webmasters que iniciaban
nuevos sitios y creaban nuevas herramientas tan rápido como podían.
Brian Behlendorf, uno de los fundadores del grupo Apache, recuerda la
época. "No era solo una especie de aficionado. Necesitábamos un software
de calidad comercial y esto fue antes de que Netscape lanzara su
software. Habíamos desarrollado nuestro propio conjunto de parches que
intercambiamos como cromos de béisbol. Finalmente dijimos: 'Nosotros
tenía tantos caminos que se superponen. ¿Por qué no creamos nuestra
propia versión y continuamos por nuestra cuenta?
Estos desarrolladores luego se fusionaron en un grupo central y
establecieron una estructura para el código. Eligieron la licencia
básica de estilo BSD para su software, que permitía a cualquiera usar el
código para cualquier propósito sin distribuir el código fuente a ningún
cambio. Muchos miembros del grupo vivían en Berkeley entonces y todavía
viven en el área hoy. Por supuesto, la licencia de estilo BSD también
tenía sentido para muchos de los desarrolladores que estaban
involucrados en los negocios y que a menudo no querían saltar al mundo
del código abierto con lo que vieron como el fervor absolutista de
Stallman. Las empresas podrían adoptar el código Apache sin temor a que
alguna licencia les obligara a revelar su código fuente más adelante. El
único inconveniente era que no podían llamar al producto Apache a menos
que fuera una copia sin modificar de algo aprobado por el grupo Apache.
Varios miembros del grupo se fueron y formaron sus propias empresas y
utilizaron el código como base para sus productos. Sameer Parekh basó el
producto del servidor Stronghold en Apache después de que su empresa
agregara las herramientas de cifrado utilizadas para proteger la
información de la tarjeta de crédito. Otros simplemente usaron versiones
de Apache para servir sitios web y facturaron a otros por el costo del
desarrollo.
En 1999, el grupo decidió formalizar su membresía y crear una
corporación sin fines de lucro dedicada a promover el código fuente del
servidor Apache y el mundo del código abierto en general. Los nuevos
miembros pueden solicitar unirse a la corporación y deben ser aprobados
por la mayoría de los miembros actuales. Esta membresía se reúne y vota
en una junta directiva que toma las decisiones sustantivas sobre el
grupo.
Este mundo no es muy diferente del mundo anterior a la corporación. Una
lista de correo todavía lleva debate y actúa como el pegamento social
para el grupo. Pero ahora el proceso de toma de decisiones está
formalizado. Antes, los miembros del grupo central asignaban la
responsabilidad a diferentes personas, pero las decisiones solo podían
tomarse por consenso aproximado. Este mecanismo podría ser doloroso y
conflictivo si el consenso no fuera fácil. Esto obligó a la junta a
trabajar arduamente para desarrollar compromisos potenciales, pero los
empujó a evitar decisiones más difíciles. Ahora la junta puede votar y
una mayoría pura puede ganar.
Esta seriedad y corporativización son probablemente los únicos pasos
posibles que podría tomar el grupo Apache. Siempre se han dedicado a
promover los intereses de los miembros. Muchos de los otros proyectos de
código abierto como Linux fueron pasatiempos que se volvieron serios. El
proyecto Apache siempre estuvo lleno de personas que estaban en el
negocio de construir la web. Si bien algunos pueden extrañar la
sensación de pueblo pequeño de los primeros años, la estructura
corporativa está aportando más certeza y previsibilidad al ámbito. La
gente no tiene que usar traje ahora que es una corporación. Simplemente
asegura que las decisiones difíciles se tomarán a un ritmo predecible.
Aún así, el formalismo agrega mucha rigidez a la estructura. Un recién
llegado emocionado puede unirse a las listas de correo, escribir un
montón de código y mover montañas para el grupo Apache, pero no será un
miembro de pleno derecho antes de ser votado. En el pasado, un forastero
enérgico podría convertir fácilmente el trabajo duro en influencia
política en la organización. Ahora, la mayoría de los miembros actuales
podrían mantener a los intrusos fuera del círculo interno. Esta
burocracia no tiene por qué ser un problema, pero tiene el potencial de
fragmentar la comunidad al crear una institución donde algunas personas
son más iguales que otras. Mantener la organización abierta en la
práctica será un verdadero desafío para la nueva corporación.
