18. Bifurcación
Una camiseta una vez ofreció esta sabiduría al mundo: "Si amas a
alguien, déjalo libre. Si regresa a ti, estaba destinado a ser. Si no
regresa, persíguelo y mátalo". " El mundo del software libre gira en
torno a dejar que tu código fuente salga al mundo. Si las cosas van
bien, a otros les encantará el código fuente, lo llenarán de
correcciones de errores y le enviarán todo este arduo trabajo. Será un
brillante ejemplo de armonía y otra razón por la cual el mundo del
software libre es grandioso. Pero si las cosas no funcionan, es posible
que alguien lo bifurque y no haya nada que pueda hacer al respecto.
"Fork" es un comando de UNIX que le permite dividir un trabajo por la
mitad. UNIX es un sistema operativo que permite que varias personas usen
la misma computadora para realizar diferentes tareas, y el sistema
operativo pretende ejecutarlas simultáneamente saltando rápidamente de
una tarea a otra. Una computadora UNIX típica tiene al menos 100 tareas
diferentes ejecutándose. Algunos vigilan la red en busca de datos
entrantes, algunos ejecutan programas para el usuario, algunos vigilan
el sistema de archivos y otros realizan muchas tareas menores.
Si "bifurca un trabajo", se las arregla para dividirlo en dos partes que
la computadora trata como dos trabajos separados. Esto puede ser
bastante útil si ambos trabajos se interrumpen con frecuencia, ya que
uno puede continuar mientras el otro se detiene. Esta solución es
excelente si dos tareas, A y B, deben realizarse de forma independiente.
Si usa una tarea y trata de lograr A primero, entonces B no comenzará
hasta que A termine. Esto puede ser bastante ineficiente si A se
detiene. Una mejor solución es bifurcar el trabajo y tratar a A y B como
dos tareas separadas.
La mayoría de los programadores no pasan mucho tiempo hablando de este
tipo de bifurcaciones. Están principalmente preocupados por las
bifurcaciones en el proceso político.
Los programadores usan "bifurcación" para describir un proceso similar
en la organización de un proyecto, pero el significado es bastante
diferente. Las bifurcaciones de un equipo significan que el grupo se
divide y va en diferentes direcciones. Una parte podría concentrarse en
agregar soporte para la palabra de moda Alpha, mientras que la otra
podría apuntar a la compatibilidad completa con la palabra de moda Beta.
En algunos casos, existen profundas divisiones detrás de la decisión de
bifurcarse. Un grupo piensa que la palabra de moda Alpha es un trabajo
chapucero y descuidado que va a estallar en unos pocos años. El otro
grupo odia la palabra de moda Beta con pasión. Disputas como esta
suceden todo el tiempo. A menudo se resuelven pacíficamente cuando a
alguien se le ocurre la palabra de moda Gamma, que los eclipsa a ambos.
Cuando no llega Gamma, la gente empieza a hablar de ir por caminos
separados y bifurcar la fuente. Si el polvo se asienta, dos versiones
diferentes comienzan a aparecer en la red compitiendo entre sí por los
corazones y las CPU de la gente que está ahí fuera. A veces las
diferencias entre las versiones son grandes ya veces son pequeñas. Pero
ahora hay una bifurcación en la evolución del código fuente y la gente
tiene que empezar a tomar decisiones.
La comunidad de software libre tiene una actitud extraña hacia las
bifurcaciones. Por un lado, la bifurcación es la única razón por la que
Stallman escribió el manifiesto del software libre. Quería el derecho y
la capacidad de jugar con el software de su computadora. Quería ser
libre para cambiarlo, modificarlo y hacerlo pedazos si alguna tarde le
apetecía hacerlo. Nadie debería ser capaz de impedir que haga eso.
Quería ser totalmente libre.
Por otro lado, la bifurcación puede dañar a la comunidad al duplicar
esfuerzos, dividir alianzas y sembrar confusión en la mente de los
usuarios. Si Bob comienza a escribir y publicar su propia versión de
Linux fuera de su casa, entonces le está quitando algo de energía a la
versión principal. La gente comienza a preguntarse si la versión que
están ejecutando es la versión del Sínodo de Missouri de Emacs o la
versión Bautista Cristiana. ¿A dónde envían correcciones de errores?
¿Quien esta a cargo? Los grupos de distribución como Debian o Red Hat
tienen que pasar unos minutos tratando de decidir si quieren incluir una
versión u otra. Si incluyen ambos, tienen que elegir uno como
predeterminado. A veces simplemente levantan las manos y se olvidan de
ambos. Es una guerra civil, y esas siempre son peores que una simple
guerra.
Algunas bifurcaciones evolucionan a partir de personalidades que
simplemente se frotan entre sí de manera incorrecta. He escuchado una y
otra vez: "Oh, tuvimos que echarlo del grupo porque estaba ofendiendo a
la gente". Muchos miembros de la comunidad consideran que este tipo de
bifurcación es malo. Usan el mismo tono de voz para describir una
bifurcación del código fuente que usan para describir la ruptura de dos
amantes. Es triste, desafortunado, desagradable y algo que realmente
nunca entenderemos porque no estuvimos allí. A veces las personas toman
partido porque tienen una fuerte opinión sobre quién tiene la razón. Por
lo general, se apagan y comienzan a contribuir a esa bifurcación de
código. En otros casos, las personas no saben cuál elegir y simplemente
cierran los ojos y se unen al que tiene el logo más lindo.
18.1 Forks y la amenaza de la desunión
Eric Raymond una vez tuvo una gran pelea con Richard Stallman sobre la
estructura de Emacs Lisp. Raymond dijo: "Las bibliotecas Lisp estaban en
mal estado de varias maneras. Estaban mal documentadas. Había mucho
trabajo que se había realizado fuera de la FSF que debería integrarse y
quería fusionarlo en el mejor trabajo desde fuera ."
El problema es que Stallman no quería formar parte del trabajo de
Raymond. “Simplemente dijo: 'No llevaré esos cambios a la distribución'.
Es su privilegio hacerlo", dijo Raymond.
Eso puso a Raymond en una posición incómoda. Podía seguir haciendo el
trabajo, crear su propia distribución de Emacs y romper públicamente con
Stallman. Si tenía razón y el código Lisp realmente necesitaba trabajo,
entonces probablemente encontraría a más de unas pocas personas que
aplaudirían su trabajo. Podrían comenzar a seguirlo descargando su
distribución y enviándole las correcciones de errores. Por supuesto, si
estaba equivocado, configuraría su propio servidor web, haría todo el
trabajo, publicaría sus correcciones de Lisp y descubriría que nadie
aparecía. Sería ignorado porque a la gente le resultaba más fácil
simplemente descargar la versión de Emacs de Stallman, que todos
pensaban que era una especie de versión oficial, si es que se podía
decir que existía. No usaban demasiado la función Lisp, así que no valía
la pena pensar en cómo un tipo en Pensilvania lo había arreglado.
Estaban obteniendo lo real del gran hombre mismo.
Por supuesto, algo intermedio probablemente sucedería. Algunas personas
a las que les importaba Lisp se asegurarían de descargar la versión de
Raymond. El resto del mundo seguiría usando la versión normal. Con el
tiempo, Stallman podría suavizar y aceptar los cambios, pero podría no
hacerlo. Tal vez alguien vendría y crearía una tercera distribución que
combinara los cambios de Raymond con los de Stallman en una versión
armoniosa. Eso sería genial, excepto que obligaría a todos a elegir
entre tres versiones diferentes.
Al final, Raymond decidió olvidarse de sus mejoras. "Emacs es demasiado
grande y demasiado complicado y la bifurcación es mala. De hecho, hubo
un grupo que se cansó tanto de trabajar con él que bifurcaron Emacs. Es
por eso que existe X Emacs. Pero las bifurcaciones importantes como esa
son eventos raros y yo no quería ser parte de perpetrar otro", dijo.
Alguien más tendría que comenzar la guerra civil disparando esos tiros
en Fort Sumter.
18.2 Jardín de senderos que se bifurcan de BSD
Algunos forks no son tan malos. A menudo llega un momento en que las
personas tienen razones legítimas para tomar caminos diferentes. Lo que
es legítimo y lo que no lo es a menudo se decide después de una gran
discusión, pero las razones estándar son las mismas que impulsan los
proyectos de programación. Una buena bifurcación debería hacer que una
computadora ejecute el software un millón de veces más rápido. O podría
hacer que el código sea mucho más fácil de portar a una nueva
plataforma. O podría hacer que el código sea más seguro. Hay mil razones
diferentes, y es imposible medir realmente cuál es la correcta. La única
medida verdadera es el número de personas que siguen cada rama de la
bifurcación. Si un proyecto tiene varios buenos discípulos y las
correcciones de errores llegan rápidamente, entonces la gente tiende a
asumir que es legítimo.
Las diversas versiones de la distribución de software BSD son algunas de
las divisiones más famosas. Todos descienden, de una forma u otra, de
las versiones originales de UNIX que surgieron de Berkeley. La mayoría
de los actuales evolucionaron a partir de la versión 4.3BSD y Network
Release 2 y algunos códigos integrados de la versión 4.4BSD después de
que se hizo libre. Todos se beneficiaron del trabajo de cientos de
personas que dedicaron su tiempo libre a clonar las funciones
controladas por AT&T. Todos ellos están controlados por la misma
licencia BSD flexible que otorga a las personas el derecho de hacer
prácticamente cualquier cosa que quieran con el código. Todos ellos
comparten el mismo demonio lindo como mascota.
Ahí es donde terminan las similitudes. El proyecto FreeBSD es
posiblemente la versión más exitosa. Tiene una distribución bastante
amplia porque sus desarrolladores tienen un buen trato con Walnut Creek
CD-ROM Distributors, una empresa que empaqueta grandes paquetes de
software gratuito y shareware en la red y luego los vende en CD-ROM. El
sistema es bien conocido y ampliamente utilizado porque el equipo de
FreeBSD se concentra en hacer que el software sea fácil de usar e
instalar en computadoras Intel. Últimamente, han creado una versión
Alpha, pero la mayoría de los usuarios ejecutan el software en chips
x86. yahoo! utiliza FreeBSD.
FreeBSD, por supuesto, comenzó como una bifurcación de un proyecto
anterior conocido como 386BSD, iniciado por Bill Jolitz. Esta versión de
BSD fue más un ejemplo académico o una prueba de concepto que un gran
proyecto de código abierto diseñado para apoderarse del mundo.
Jordan Hubbard, alguien que vendría más tarde para crear una bifurcación
de 386BSD, dijo sobre la decisión de Jolitz de crear una bifurcación de
BSD basada en 386: "La verdadera contribución de Bill fue trabajar con
el puerto 386. Era una especie de extraño. Nadie otros vieron el 386
como interesante. Berkeley tenía una actitud miope hacia las PC. Eran
solo juguetes. Nadie apoyaría a Intel. Ese era el clima en ese momento.
Nadie realmente tomaba las PC en serio. La contribución de Bill fue
darse cuenta de que las PC iban lugares."
Desde el principio, Hubbard y varios otros vieron la genialidad en la
creación de una versión 386 de BSD que se ejecutaba en el hardware más
barato disponible. Comenzaron a agregar funciones y pegar correcciones
de errores, que distribuyeron como un archivo que modificaba la
distribución principal de 386BSD de Jolitz. Esto fue práctico al
principio cuando los cambios eran pocos, pero continuó por respeto al
creador original, incluso después de que los parches se complicaran.
Finalmente, estalló una pelea en 1993. Jordan Hubbard, uno de los
forkers, escribe en su historia del proyecto:
386BSD era el sistema operativo de Bill Jolitz, que hasta ese momento
había estado sufriendo severamente por casi un año de abandono. A medida
que el kit de parches se hinchaba cada vez más incómodamente con cada
día que pasaba, estuvimos unánimemente de acuerdo en que había que hacer
algo y decidimos tratar de ayudar a Bill proporcionando esta instantánea
de "limpieza" provisional. Esos planes se detuvieron bruscamente cuando
Bill Jolitz decidió repentinamente retirar su aprobación del proyecto y
sin ninguna indicación clara de lo que se haría en su lugar.
El equipo de FreeBSD siguió adelante a pesar de la negación. Decidieron
bifurcarse. Hoy en día, 386BSD es en gran parte parte de la historia de
la informática, mientras que FreeBSD es un sistema operativo vivo y
actual, al menos en el momento en que se escribió este libro. El equipo
de FreeBSD ha hecho un buen trabajo distribuyendo versiones libres de
errores y han sido recompensados con lealtad, discípulos, dinero y
computadoras de Walnut Creek. La bifurcación a menudo puede ser buena
para la sociedad porque evita que una persona o camarilla frustre a otro
grupo. El mundo del software libre está lleno de muchas de las mismas
historias de política que flotan en los dispensadores de agua de las
corporaciones, pero las historias no tienen por qué terminar de la misma
manera. Si un jefe o grupo intenta cerrar un proyecto de software libre,
realmente no puede. El código fuente está disponible gratuitamente y la
gente es libre de continuar. El proyecto FreeBSD es un ejemplo.
Por supuesto, un buen software puede tener efectos antibifurcación.
Linus Torvalds dijo en una entrevista: "En realidad, ni siquiera he
probado 386BSD; cuando comencé con Linux no estaba disponible (aunque la
serie de Bill Jolitz sobre él en Dr. Dobbs Journal había comenzado y era
interesante), y cuando 386BSD finalmente salió, Linux ya estaba en un
estado en el que era tan utilizable que nunca pensé realmente en
cambiar. Si 386BSD hubiera estado disponible cuando comencé con Linux,
Linux probablemente nunca habría existido". Entonces, si 386BSD hubiera
sido más fácil de encontrar en la Red y hubiera tenido mejor soporte, es
posible que Linux nunca hubiera comenzado.
Una vez que alguien comienza a bifurcar BSD, una bifurcación rara vez es
suficiente. Otro grupo conocido como NetBSD también se hartó del
progreso de 386BSD en 1993. Sin embargo, este grupo quería construir una
plataforma que funcionara bien en muchas máquinas diferentes, no solo en
Intel 386. La gente de FreeBSD se concentró en hacer un buen trabajo. en
cajas Intel, mientras que NetBSD quería crear una versión que se
ejecutara en muchas máquinas diferentes. Su eslogan se convirtió en "Por
supuesto que ejecuta NetBSD".
NetBSD se ejecuta en prácticamente todas las máquinas que pueda
imaginar, incluidas las máquinas más antiguas y menos actualizadas, como
Amiga y Atari. También ha sido adoptado por compañías como NeXT, que
incluyeron partes de él en la versión del sistema operativo para
Macintosh conocida como Rhapsody. Por supuesto, los chips más comunes
como la línea Intel y Alpha también son compatibles.
La comunidad NetBSD surgió al mismo tiempo que el mundo FreeBSD. No se
dieron cuenta de que cada equipo estaba trabajando en el mismo proyecto
al mismo tiempo. Pero una vez que comenzaron a lanzar sus propias
versiones, se mantuvieron al margen.
"El grupo NetBSD siempre ha sido el más puro. Lo vieron como un vehículo
de investigación del sistema operativo. Eso era lo que estaba haciendo
CSRG. Su único mandato era hacer una investigación interesante", dijo
Hubbard. "Es un conjunto de objetivos muy diferente al que nos
concentramos para el 386. Lo importante para nosotros era pulirlo.
Pusimos todos nuestros esfuerzos en pulir, no en portar. Esto fue parte
de llevar BSD a las masas. Vamos por los números. Vamos por la
penetración masiva".
Esta orientación significó que NetBSD nunca logró realmente el mismo
dominio del mercado que FreeBSD. El grupo recientemente comenzó a
distribuir versiones de NetBSD en CD-ROM. FreeBSD, por otro lado,
siempre se ha destacado por atraer usuarios nuevos y curiosos gracias a
su relación con Walnut Creek. Muchos experimentadores y usuarios de
mente abierta tomaron uno de los discos, y algunos se emocionaron lo
suficiente como para hacer algunas contribuciones. La asociación con
Walnut Creek también ayudó al equipo de FreeBSD a entender lo que tenía
que hacer para que su distribución fuera más fácil de instalar y usar.
Ese era el negocio de Walnut Creek, después de todo.
18.3 OpenBSD
La bifurcación no se detuvo con NetBSD. Pronto, un miembro del mundo de
NetBSD, Theo de Raadt, comenzó a molestar a algunas personas. Un miembro
del equipo de OpenBSD me dijo: "La razón de la separación de NetBSD fue
que echaron a Theo. No lo entiendo completamente. Más o menos dicen que
estaba tratando mal a los usuarios de la lista de correo. para ser breve
y conciso, pero no hay nada de malo en eso. Fue uno de los miembros
fundadores de NetBSD y le pidieron que renunciara".
Ahora, cuatro años después de que comenzara la separación en 1995, de
Raadt todavía está un poco dolido por su decisión. Dice sobre su
decisión de bifurcar BSD nuevamente: "No tenía elección. Realmente me
gusta lo que hago. Realmente me gusta trabajar con una comunidad. En el
momento en que sucedió todo, yo era el segundo desarrollador más activo
en su árbol fuente. Tomaron al segundo desarrollador más activo y lo
echaron".
Bueno, no lo expulsaron por completo, pero le quitaron la capacidad de
"confirmar" cambios en el árbol de fuentes y hacerlos permanentes.
Después de la división, de Raadt tuvo que enviar sus contribuciones por
correo electrónico a un miembro del equipo para que pudiera
verificarlas. Esto no le cayó bien a de Raadt, quien lo vio como una
degradación y un impedimento real para trabajar. .
La raíz de la división es fácil de ver. De Raadt es enérgico. Piensa y
habla rápido sobre todo. Tiene una visión clara de la mayoría del
software gratuito y no tiene miedo de compartirlo. Si bien algunos
miembros de BSD son caritativos y conciliadores con Richard Stallman, de
Raadt no se molesta en ocultar su desprecio por la organización. "La
Free Software Foundation es una de las organizaciones más mal
nombradas", dice, explicando que solo los licenciatarios al estilo BSD
tienen la verdadera libertad de hacer lo que quieran con el software. La
Licencia Pública General GNU es un par de esposas para él.
De Raadt vive en Calgary y viste su página web personal con una foto de
sí mismo en la cima de una montaña con un pañuelo. Si desea enviarle una
pizza por cualquier motivo, ha publicado el número de teléfono de su
tienda local favorita (403/531-3131). Desafortunadamente, informa que ya
no aceptan números de tarjetas de crédito extranjeras.
Incluso se las arregla para tener opiniones fuertes sobre cosas simples
que aparentemente ama. El ciclismo de montaña es una gran obsesión,
pero, dice, "me gusta el barro y desprecio los 'callejones arbolados'
(lo que la mayoría de la gente llama caminos forestales)". Esa no es la
mejor manera de entablar amistad con personas menos extremas que
disfrutan de un paseo dominical por caminos forestales.
Si te gustan los gatos, no leas lo que dijo sobre sus mascotas: "Tengo
gatos. Sus nombres son Galileo y Kepler, todavía son gatitos. Kepler, la
pequeña perra, aparentemente puede teletransportarse a través de las
paredes. Galileo es un monstruo bastante genial. Cuando se conviertan en
gatos adultos, haré estofado y sopa con ellos. (Kepler solo es bueno
para la sopa)".
Comentarios desechables como este tienen efectos extraños en la red,
donde el texto es la única forma en que las personas pueden comunicarse.
No hay gestos faciales o pistas tonales para decirle a la gente que
alguien está bromeando, y algunas personas no tienen escáneres bien
desarrollados para la ironía o el sarcasmo. A algunos les encantan los
francotiradores y los hostigamientos, mientras que otros simplemente se
enojan. No pueden dejar que los comentarios sarcásticos se les escapen
de la espalda. Eventualmente, los buenos caballeros que sienten que la
amabilidad y la cortesía personal aún deben contar para algo en este
mundo se enojan y comienzan a intentar hacer algo.
Es fácil ver cómo afectó esto a la gente de NetBSD, que lleva a cabo sus
negocios de una manera mucho más adecuada. Charles Hannum, por ejemplo,
se negó a hablarme sobre el cisma a menos que le prometiera que podría
revisar las partes del libro que mencionaban NetBSD. También sugirió que
los forks no eran particularmente interesantes y que no deberían ser
parte del libro. Otros respondieron a las preguntas con cartas más
educadas diciendo que la separación ocurrió hace mucho tiempo y que ya
no valía la pena hablar de eso. Algunos señalaron que la mayoría de los
miembros del equipo actual de NetBSD ni siquiera estaban presentes
cuando ocurrió la división.
Si bien su silencio puede ser bastante prudente y una mejor manera de
pasar la vida, ciertamente no me ayudó a entender los dos lados de la
historia. Señalé que no aceptarían código en el árbol de NetBSD si el
autor exigía el derecho a revisar la distribución final. Dije que podían
emitir un comunicado o realizar la entrevista por correo electrónico.
Uno argumentó que no había mayor problema si al final había que eliminar
algunos párrafos del libro. Señalé que no podía dar a los cientos de
personas con las que hablé poder de veto sobre el manuscrito. Sería
imposible de completar. El libro no estaba siendo escrito por un comité.
Nadie en NetBSD se movió.
De Raadt, por otro lado, habló con bastante libertad sin condiciones
previas ni limitaciones. Todavía mantiene un archivo de registro con una
buena cantidad de cartas de correo electrónico intercambiadas durante la
separación y facilita su lectura en su sitio web personal. Eso es lo más
abierto que puedes conseguir. La gente de NetBSD que se negó a hablar
conmigo, por otro lado, parecía decidida a mantener el control de la
historia. Su silencio provino de un mundo diferente al del sitio web que
ofrece el número de teléfono de la pizzería local como pista. Eran
Dragnet; de Raadt era políticamente incorrecto.
Cuando la gente de NetBSD decidió hacer algo, le quitaron el acceso a de
Raadt al árbol de fuentes. No podía simplemente hurgar en el código
haciendo cambios a medida que avanzaba. Bueno, podría hurgar y hacer
cambios, pero no en el árbol oficial con la última versión. Después de
todo, el proyecto era de código abierto. Podía descargar la última
versión y empezar a juguetear, pero no podía tomar decisiones casi
oficiales sobre qué fuente formaba parte de la última versión oficial
inédita.
De Raadt pensó que esto era una verdadera barrera para trabajar. No pudo
ver la última versión del código porque se mantuvo fuera de su vista.
Estaba atascado con el último lanzamiento, que podría tener varios
meses. Eso lo puso en una desventaja extrema porque podría comenzar a
trabajar en un problema solo para descubrir que alguien lo había
solucionado o cambiado.
Chris Demetriou se encontró con la tarea de sacar a De Raadt del equipo.
Su carta, que aún se puede encontrar en el sitio de OpenBSD, decía que
el comportamiento rudo y los mensajes abusivos de de Raadt habían
alejado a las personas que podrían haber contribuido al proyecto.
Demetriou también se negó a hablar sobre NetBSD a menos que pudiera
revisar las secciones del libro que contenían sus comentarios. También
amenazó con tomar todas las medidas posibles contra cualquiera que
incluso citara sus cartas en un libro comercial sin su permiso.
De Raadt recopiló esta nota de Demetriou y la tormenta de fuego que
siguió en un archivo de 300k que guarda en su sitio web. El núcleo de
NetBSD trató de ser cortés y firme, pero el asunto pronto degeneró en
una guerra de llamas que duró siete meses. Después de un tiempo, la
gente comenzó a tener meta-argumentos, debatiendo si el verdadero
argumento era más o menos como las disputas de un marido y una mujer que
trabajan en la misma empresa. Los esposos y las esposas deben mantener
sus peleas personales fuera del lugar de trabajo, argumentaron. Y
entonces discutieron sobre si los desagradables gramas de De Raadt eran
parte de su "trabajo" o solo parte de su tiempo social.
A pesar de todo, de Raadt trató de recuperar su acceso al árbol fuente
de NetBSD y el grupo trató de proponer todo tipo de mecanismos para
asegurarse de que estaba haciendo una contribución "positiva" y se
llevaba bien con todos. En un momento, le ofrecieron una carta para que
la firmara. Estas negociaciones no llegaron a ninguna parte, ya que de
Raadt se opuso a verse obligado a hacer promesas que otros
contribuyentes no tenían que hacer.
De Raadt escribió software libre porque quería ser libre para hacer
cambios o escribir código de la forma en que quería hacerlo. Si hubiera
querido tener la cara feliz de un colaborador positivo, podría haber
conseguido un trabajo en una corporación. Renunciar al derecho de
participar en guerras de llamas y hablar a voluntad puede no ser una
gran compensación para las personas normales con trabajos de tiempo
completo. La gente normal se traga su orgullo a diario. La gente normal
no bromea sobre convertir a sus gatos en sopa. Pero de Raadt pensó que
era como perder un poco de su humanidad y aceptar voluntariamente un par
de esposas. Simplemente no era habitable.
La discusión duró meses. De Raadt sintió que intentó y trató de
reincorporarse al proyecto sin renunciar a su honor. El equipo central
de NetBSD argumentó que solo querían asegurarse de que fuera positivo.
Querían asegurarse de que no alejaría a los colaboradores perfectamente
buenos con payasadas descaradas. Nadie ganó terreno en las negociaciones
y, al final, De Raadt se fue.
La buena noticia es que la bifurcación no terminó mal. De Raadt decidió
que no aceptaría la degradación. Simplemente no podría hacer un buen
trabajo si tuviera que ejecutar todos sus cambios por parte del equipo
que lo expulsó del proyecto. Me tomó mucho tiempo preguntar "Madre,
¿puedo?" para arreglar cada pequeño error. Si iba a tener que ejecutar
su propio árbol, también podría hacer todo lo posible y comenzar su
propia versión de BSD. Lo llamó OpenBSD. Iba a estar completamente
abierto. Iba a haber relativamente pocos controles sobre los miembros.
Si el núcleo de NetBSD manejaba su mundo como los aldeanos puritanos en
una historia de Nathaniel Hawthorne, entonces de Raadt manejaría el suyo
como Club Med.
OpenBSD luchó durante varios meses mientras de Raadt intentaba atraer a
más diseñadores y programadores a su proyecto. Fue una batalla por la
popularidad en muchos sentidos, no muy diferente de la escuela
secundaria. Cuando las camarillas se dividieron, todos tuvieron que
escoger y elegir. De Raadt tenía que conseguir algunas personas en su
campamento si iba a hacer limonada.
La inspiración llegó a de Raadt un día cuando descubrió que al archivo
de guerra de llamas en su página web le faltaban algunas letras. Dice
que alguien irrumpió en su máquina e hizo algunas eliminaciones sutiles.
Alguien que tenía un conocimiento íntimo del sistema NetBSD. Alguien a
quien le importaba la imagen que retrataban las emociones crudas en las
cartas supuestamente privadas.
Aclara sus comentarios para dejar claro que no está seguro de que haya
sido alguien del núcleo de NetBSD. "Nunca lo perseguí. Si sucede, es tu
culpa. No es culpa de ellos", dijo. Por supuesto, la gente de NetBSD se
negó a discutir este asunto oa responder preguntas a menos que pudieran
revisar el capítulo.
Este robo le dio un enfoque. De Raadt miró a NetBSD y decidió que era
demasiado inseguro. Reunió a un grupo de personas de ideas afines y
comenzó a peinar el código en busca de posibles inseguridades.
"Más o menos al mismo tiempo, me involucré con una empresa que escribía
un escáner de seguridad de red. Tres de las personas de allí comenzaron
a jugar con el árbol de código fuente y a buscar agujeros de seguridad.
Empezamos a encontrar problemas por todas partes, así que comenzamos un
auditoría integral de seguridad. Comenzamos desde el principio. Nuestra
carga de tareas aumentó enormemente. En un momento, tenía cinco hojas de
papel en mi escritorio llenas de cosas que buscar ", dijo.
Los agujeros de seguridad en los sistemas operativos son bestias
extrañas que suelen aparecer por error cuando el programador hace una
suposición infundada. Uno de los agujeros más conocidos es el
desbordamiento del búfer, que se hizo famoso en 1988 después de que
Robert Morris, entonces estudiante de posgrado en Cornell, lanzara un
programa que usaba el agujero para hacer que varias partes importantes
de Internet se ralentizaran.
En este caso, el programador crea un búfer para contener toda la
información que alguien en la red podría enviar. Los navegadores web,
por ejemplo, envían solicitudes como "GET
http://www.nytimes.com" para
solicitar la página de inicio del sitio web del New York Times. El
programador debe reservar una parte de la memoria para contener esta
solicitud, generalmente un bloque que tiene una longitud de
aproximadamente 512 bytes. El programador elige una cantidad que debería
ser más que suficiente para todas las solicitudes, incluidas las más
extrañas y complicadas.
Antes de que el ataque se hiciera conocido, los programadores a menudo
ignoraban la longitud de la solicitud y asumían que 512 bytes eran más
que suficientes para cualquier cosa. ¿Quién escribiría una URL tan
larga?
¿Quién tenía una dirección de correo electrónico tan larga? Los
atacantes pronto descubrieron que podían enviar más de 512 bytes y
comenzaron a escribir sobre el resto de la memoria de la computadora. El
programa tomaría diligentemente 100.000 bytes y seguiría escribiéndolos
en la memoria. Un atacante podría descargar cualquier software y
comenzar a ejecutarlo. Y los atacantes hicieron esto.
De Raadt y muchos otros comenzaron a peinar el código en busca de
lagunas. Se aseguraron de que cada programa que usaba un búfer incluyera
un fragmento de código que verificaría para garantizar que ningún hacker
intentara infiltrarse más de lo que el búfer podía contener. Revisaron
miles de otras posibilidades. Se revisó cada línea y se hicieron
cambios, incluso si no había una forma práctica de que alguien llegara
al agujero potencial. Muchos búferes, por ejemplo, solo aceptan
información de la persona que está sentada en la terminal. La gente de
OpenBSD también los cambió.
Esta auditoría comenzó poco después de la bifurcación en 1995 y continúa
hasta el día de hoy. La mayor parte del trabajo principal ya está hecho
y al grupo le gusta jactarse de que no han tenido un agujero que pueda
explotarse de forma remota para obtener acceso a la raíz en más de dos
años. El último logotipo cuenta con el lema "Enviando niños a /dev/null
desde 1995". Es decir, cualquier atacante no llegará a ninguna parte con
OpenBSD porque toda la información adicional de los ataques se enrutaría
a /dev/null, una presunción de UNIX para ser borrada, ignorada y
olvidada.
La bifurcación de OpenBSD es un buen ejemplo de cómo las malas batallas
políticas pueden terminar resolviendo algunos problemas técnicos
importantes. Todos se inquietaron y preocuparon cuando de Raadt anunció
que estaba bifurcando el mundo BSD una vez más. Esto diluiría aún más
los recursos y sembraría confusión entre los usuarios. Sin embargo, la
concentración en la seguridad le dio a OpenBSD una identidad de marca, y
las otras distribuciones de BSD mantienen al menos un ojo en las
correcciones de errores distribuidas por el equipo de OpenBSD. Estos a
menudo conducen a arreglos subrepticios en su propia distribución.
El enfoque también lo ayudó a atraer nuevos programadores interesados en
la seguridad. "Algunos de ellos solían ser crackers y eran personas
realmente geniales. Cuando cumplen dieciocho años, se convierte en un
delito federal, ya sabes", dice de Raadt.
Esta bifurcación puede haber fortalecido a la comunidad BSD porque elevó
efectivamente el enfoque en la seguridad y la criptografía al más alto
nivel. En el mundo corporativo, es como tomar al líder del equipo de
desarrollo responsable de la seguridad y ascenderlo de gerente senior a
vicepresidente ejecutivo senior de una división separada. La autonomía
también le dio al equipo de OpenBSD la capacidad de tomar decisiones
técnicas audaces por sus propios motivos. Si veían un posible problema
de seguridad que pudiera perjudicar la usabilidad o la portabilidad, el
equipo de OpenBSD podía realizar el cambio sin preocuparse de que otros
miembros del equipo se quejaran. OpenBSD se trataba de seguridad. Si
quería trabajar en la portabilidad, vaya a NetBSD. Si le preocupaba la
facilidad de uso en cajas Intel, vaya a FreeBSD. La creación de un mundo
OpenBSD separado hizo posible darle un fuerte enfoque a la seguridad.
18.4 Bifurcaciones Temporales
Es un error ver estas bifurcaciones como divisiones absolutas que nunca
se vuelven a mezclar. Mientras que NetBSD y OpenBSD continúan
fulminándose entre sí a través del éter de Internet, los grupos
comparten código con frecuencia porque las licencias evitan que un grupo
congele a otro.
Jason Wright, uno de los desarrolladores de OpenBSD, dice: "Vigilamos
los árboles de código fuente de los demás. Una de las cosas que hago
para divertirme es sacar controladores de FreeBSD y trasladarlos a
OpenBSD. Entonces tenemos soporte para una nueva pieza de hardware. ."
Dice que a menudo busca controladores escritos por Bill Paul, porque "Me
he acostumbrado a su estilo. Así que sé qué cambiar cuando recibo su
código. Puedo hacerlo en unas cinco o seis horas. Es decir, en menos un
puerto aproximado para probar si funciona".
Aún así, el trabajo no siempre es sencillo. Dice que algunos
controladores de dispositivos son mucho más difíciles de manejar porque
ambos grupos han abordado el problema de manera diferente. "Los
controladores SCSI son más difíciles", dice. "Ha habido cierta
divergencia en las capas para SCSI. Están usando algo llamado CAM.
Tenemos una implementación más antigua a la que nos hemos adherido". Es
decir, FreeBSD ha reelaborado la estructura de la forma en que la
información SCSI se envía a las partes del sistema que solicitan
información. OpenBSD no ha adoptado sus cambios, quizás por cuestiones
de seguridad o quizás por inercia o quizás porque nadie se ha puesto a
pensar en ello. La mezcla no es perfecta.
Tanto NetBSD como FreeBSD también funcionan en la seguridad. También
observan los registros de cambios de OpenBSD y notan cuándo se
solucionan los agujeros de seguridad. También descubren sus propios
agujeros y OpenBSD puede usarlos como inspiración para tapar su propio
código. Los descubrimientos y complementos van en ambos sentidos a
medida que los grupos compiten para crear un sistema operativo perfecto.
Kirk McKusick dice: "NetBSD y OpenBSD tienen personalidades
extremadamente fuertes. Cada uno está absolutamente aterrorizado de que
el otro gane una pulgada".
Si bien las tres bifurcaciones de BSD pueden cooperar más de lo que
compiten, al mundo de Linux todavía le gusta mirar al mundo de BSD con
un poco de desprecio. Todas las bifurcaciones se ven un tanto
desordenadas, incluso si tener la libertad de bifurcar es lo que
aparentemente Stallman y GNU están luchando por lograr. Los entusiastas
de Linux parecen pensar: "Tenemos nuestros patos en una sola fila. ¿Cuál
es tu problema?" Es algo así como la mentalidad del ejército. Si es
verde, uniforme e igual en todas partes, entonces debe ser bueno.
El BSD carece de la cohesión monomaníaca de Linux, y esto parece dañar
su imagen. La comunidad de BSD siempre ha sentido que Linux está
acaparando el protagonismo que debería compartirse al menos por igual
entre los grupos. Linux realmente está construido alrededor de un culto
a Linus Torvalds, y eso hace que la prensa sea muy buena. Es muy fácil
para la prensa tomar fotos de un hombre y ponerlo en la portada de una
revista. Es simple, limpio, ordenado y perfectamente compatible con un
fragmento de sonido de 30 segundos. Explicar que hay FreeBSD, NetBSD,
OpenBSD y quién sabe qué versiones más pequeñas esperando entre
bastidores no es tan manejable.
Eric Raymond, un verdadero discípulo de Linus Torvalds y Linux, lo ve en
términos técnicos. La comunidad de BSD se enorgullece del hecho de que
cada distribución se construye a partir de un gran árbol fuente.
Obtienen todo el código fuente de todas las partes del núcleo, las
utilidades, los editores y demás en un solo lugar. Luego presionan el
botón de compilación y dejan que la gente trabaje. Este es un enfoque
nítido, efectivo y bien administrado para el proyecto.
Los grupos de Linux, sin embargo, no están tan coordinados. Torvalds
solo se preocupa realmente por el núcleo, que es su bebé. Alguien más se
preocupa por GCC. Todos crean sus propios árboles de origen para las
partes. Las empresas de distribución como Red Hat se preocupan por unir
el desorden. No es inusual encontrar la versión 2.0 del kernel en una
distribución mientras que otra tiene la versión 2.2.
"En BSD, puedes hacer una marca unificada. Están bastante orgullosos de
eso", dice Raymond. "Pero esto crea rigideces que le dan a la gente
incentivos para bifurcarse. Las cosas de BSD que se construyen de esa
manera desarrollan nuevos grupos derivados cada semana, mientras que
Linux, que tiene un acoplamiento más flexible, no se bifurca".
Él elabora: "Alguien señaló que hay un paralelo de la política. Las
instituciones políticas y sociales rígidas tienden a cambiar
violentamente si cambian, mientras que las que tienen más juego tienden
a cambiar pacíficamente".
Pero esta distinción puede ser semántica. La bifurcación ocurre en el
ámbito de Linux, pero ocurre como pequeñas distracciones que se explican
con otras palabras. Red Hat puede elegir usar GNOME, mientras que otra
distribución como SuSE puede elegir KDE. Los usuarios verán una gran
diferencia porque ambas herramientas crean entornos de escritorio
virtual. No te los puedes perder. Pero la gente no etiquetará esto como
un fork. Ambas distribuciones usan el mismo kernel de Linux y nadie ha
dicho: "Al diablo con Linus, voy a construir mi propia versión de
Linux". Técnicamente, todos todavía se llaman a sí mismos Linux, incluso
si están construyendo algo que se ve bastante diferente en la
superficie.
Jason Wright, uno de los desarrolladores del equipo de OpenBSD, ve la
organización como algo bueno. "Lo único que tienen todos los BSD sobre
Linux es un árbol de código fuente unificado. No tenemos el árbol de Joe
Blow o el árbol de Bob", dice. En otras palabras, cuando se bifurcan, lo
hacen oficialmente, con gran ceremonia, y se aseguran de que el mundo
sepa de sus creaciones por separado. Hacen una ruptura clara, y esto
facilita las cosas a los desarrolladores.
Wright dice que este árbol fuente único les facilitó mucho convertir
OpenBSD en un sistema operativo muy seguro. "Tenemos la seguridad sobre
Linux. Recientemente han estado realizando una auditoría de seguridad
para Linux, pero van a tienen muchos más problemas. No hay un lugar
donde ir para el código fuente".
Para extender esto a términos políticos, el mundo de Linux es como la
década de 1980 cuando Ronald Reagan dirigía el partido republicano con
la máxima de que nadie debería criticar a otro republicano. Claro, la
gente discutió internamente sobre impuestos, aborto, crimen y las
controversias habituales, pero mostró una rara cohesión pública. Nadie
critica a Torvalds, y todos tienen cuidado de hablar de la importancia
de la cohesión de Linux incluso cuando esencialmente se bifurcan al
elegir diferentes paquetes.
El mundo BSD, por otro lado, es como el reino bíblico en la película de
Monty Python La vida de Brian. En él, un personaje enumera los diversos
grupos disidentes que se oponen a la ocupación de los romanos. Está el
Frente Popular de Judea, el Frente Popular de Judea, el Frente Popular
de Judea y varios otros. Todos buscan lo mismo y todos están
manifiestamente separados. El mundo BSD puede compartir una buena
cantidad de código; puede compartir los mismos objetivos, pero
simplemente lo presenta como proveniente de tres campos diferentes.
John Gilmore, uno de los fundadores de la compañía de software libre
Cygnus y un firme creyente en las ventajas de la Licencia Pública
General GNU, dice: "En Linux, cada paquete tiene un mantenedor, y los
parches de todas las distribuciones pasan por ese mantenedor. Hay una
sensación de cohesión. Las personas en cada distribución trabajan para
reducir sus diferencias con respecto a la versión lanzada por el
mantenedor. En el mundo de BSD, cada árbol cree que es el propietario de
cada programa; no envían los cambios a un lugar central porque eso viola
el modelo del ego".
Jordan Hubbard, el líder de FreeBSD, es crítico con la caracterización
de Raymond del mundo BSD. "Siempre he tenido un lugar especial en mi
corazón para ese periódico porque pintó posiciones que no existían",
dijo Hubbard sobre la pieza de Raymond "La catedral y el bazar". "Podría
apuntar solo a la comunidad de Linux y decidir qué parte estaba
orientada a la catedral y qué parte estaba orientada al bazar.
"Cada sistema operativo tiene partes de catedral y partes de bazar. Hay
algunos aspectos del desarrollo que usted deja deliberadamente fuera de
foco y deja que las personas contribuyan a su propio ritmo. Es una
especie de modelo emergente y esa es la parte del bazar. Luego tienes la
parte organizativa de cada proyecto. Esa es la parte de la catedral. Son
los guardianes y los que establecen los estándares. También son
necesarios”, dijo. Cuando se trata de eso, incluso hay muchas
bifurcaciones sobre la definición de una bifurcación. Cuando algunos
miembros del equipo de Linux apuntan al mundo BSD y comienzan a burlarse
de las bifurcaciones, el equipo BSD se pone a la defensiva. Los
muchachos de BSD siempre se ponen a la defensiva porque su fundador no
está en la portada de todas las revistas. El equipo de Linux insinúa que
tal vez, si no estuvieran bifurcando, también tendrían a alguien con un
nombre en las luces.
Hubbard tiene razón. Linux se bifurca tanto, simplemente lo llaman una
distribución o un kernel experimental o un kit de parches. Nadie tiene
el descaro de escindir su propia organización política rival. Nadie
tiene la influencia política.
18.5 Una bifurcación, una división y una reunión
Ahora, después de todas las historias desagradables de puñaladas por la
espalda y disputas, es importante darse cuenta de que en realidad hay
algunas historias felices de bifurcaciones que se fusionan nuevamente.
Una de las mejores historias proviene de los pasillos de una empresa de
seguridad de Internet, C2Net, que se ocupó de una bifurcación de una
manera muy pacífica.
C2Net es una empresa con sede en Berkeley dirigida por algunos
defensores incondicionales de la privacidad y el anonimato en línea. La
compañía comenzó ofreciendo un servicio de reenvío que permitía a las
personas enviarse correos electrónicos anónimos entre sí. Su sitio
eliminaría la dirección del remitente y se la pasaría al destinatario
sin dejar rastro de quién la envió. Su objetivo era satisfacer la
necesidad de personas como denunciantes, filtradores y otras personas en
posiciones de debilidad que querían usar el anonimato para evitar
represalias.
La compañía pronto asumió un objetivo mayor cuando decidió modificar el
popular servidor web Apache agregando un cifrado fuerte para que las
personas pudieran procesar tarjetas de crédito a través de la web. La
tecnología, conocida como SSL por "capa de conexión segura", dispuso
automáticamente que todo el tráfico entre un servidor web remoto y el
usuario se codificara para que nadie pudiera espiar. SSL es una
tecnología muy popular en la web hoy en día porque muchas empresas la
utilizan para codificar números de tarjetas de crédito para derrotar a
los intrusos.
C2Net llamó mucho la atención cuando uno de sus fundadores, Sameer
Parekh, apareció en la portada de la revista Forbes con un titular que
decía que quería "derrocar al gobierno". En realidad, C2Net quería
trasladar las operaciones de desarrollo al exterior, donde no había
regulaciones sobre la creación de software criptográficamente seguro.
C2Net fue donde el talento estaba disponible y tenía el precio justo.
En este caso, C2Net eligió una versión gratuita de SSL escrita por Eric
Young conocida como SSLeay. El trabajo de Young es otro de los casos de
éxito del código abierto. Escribió la versión original como pasatiempo y
la lanzó con una licencia similar a BSD. A todos les gustó su código, lo
descargaron, experimentaron con él y lo usaron para explorar los límites
del protocolo. Young simplemente estaba intercambiando código con la red
y pasándoselo bien.
Parekh y C2Net vieron una oportunidad. Fusionarían dos productos
gratuitos, el servidor web Apache y SSLeay de Young, y crearían una
versión segura para que la gente pudiera configurar fácilmente sitios de
comercio seguro para Internet. Llamaron a este producto Stronghold y lo
pusieron en el mercado comercialmente.
La decisión de C2Net de cobrar por el software molestó a algunas
personas. Tomaron dos paquetes de software gratuitos y los convirtieron
en algo comercial. Esto no fue solo un fork, a algunos les pareció un
robo. Por supuesto, estas quejas no eran realmente justas. Ambas
colecciones de código surgieron con una licencia de estilo BSD que
otorgaba a todos el derecho a crear y vender adiciones comerciales al
producto. No había ningún requisito similar a la GPL que devolvieran a
la comunidad. Si nadie quería una versión comercial, no deberían haber
lanzado el código con una licencia muy abierta en primer lugar.
Parekh entiende estas objeciones y dice que ha soportado muchas críticas
en las listas de correo internas. Aún así, siente que el producto
Stronghold contribuyó en gran medida a la fortaleza de Apache al
legitimarlo.
"No me siento culpable por eso. No creo que hayamos contribuido con
mucho código fuente, que es una de las métricas clave que usa la gente
del grupo Apache. En mi perspectiva, la mayor contribución que hemos
logrado es la aceptación del mercado", dijo.
Parekh no quiere decir que tuvo que generar aceptación en el mercado
entre los desarrolladores web. El grupo Apache estaba haciendo un buen
trabajo al lograr eso a través de sus tácticas de guerrilla, excelente
producto y precio gratuito. Pero nadie enviaba un mensaje a los niveles
más altos de la industria informática, donde se hacían planes a largo
plazo y se cerraban tratos corporativos. Parekh siente que construyó una
respetabilidad de primera clase para el nombre de Apache al crear y
respaldar un producto de primera clase que las grandes corporaciones
podrían usar con éxito. Se aseguró de que todos supieran que Apache
estaba en el centro de Stronghold, y la gente se dio cuenta.
El primer trabajo de Parekh fue obtener una licencia de patente de RSA
Data Security. El software seguro como SSL se basa en el algoritmo RSA,
una idea que fue patentada por tres profesores del MIT en la década de
1970. Esta patente está controlada por RSA Data Security. Si bien la
empresa publicitó algunos de los términos de su licencia y se esforzó
por comercializar la tecnología, negociar una licencia no fue un detalle
trivial que pudiera ser manejado por algún equipo de software libre.
¿Quién va a pagar la licencia? ¿Quién va a calcular qué porcentaje de
libre es? ¿Quién va a subir con el dinero? Estas preguntas son mucho más
fáciles de responder si usted es una corporación que cobra a los
clientes por comprar un producto. C2Net estaba haciendo eso. Las
personas que compraron Stronghold obtuvieron una licencia de RSA que
garantizaba que podían usar el método sin ser demandados.
La patente fue sólo el primer obstáculo. SSL es una tecnología que
intenta brindar cierta seguridad a las conexiones web mediante el
cifrado de las conexiones entre el navegador y el servidor. Netscape
agregó una función que permite establecer una conexión solo si el
servidor tiene un certificado digital que lo identifica. Estos
certificados solo se emiten a una empresa después de pagar una tarifa a
un agente de certificados registrado como Verisign.
Al principio, los agentes de certificados como Verisign emitían
certificados solo para servidores creados por grandes empresas como
Netscape o Microsoft. Apache era solo un grupo amorfo en la red.
Verisign y las demás autoridades no le estaban prestando atención.
Parekh se acercó a ellos y los convenció de que comenzaran a emitir los
certificados para poder comenzar a vender Stronghold.
"Nos convertimos en el número tres, justo detrás de Microsoft y
Netscape. Luego vieron cuánto dinero ganaban con nosotros, así que
comenzaron a firmar certificados para todos", dijo. Otros proyectos de
Apache que usaban SSL encontraron la vida mucho más fácil una vez que
Parekh le mostró a Verisign que se podía ganar mucho dinero con personas
que usaban software libre.
Parekh no niega que C2Net no haya hecho muchas contribuciones al código
base de Apache, pero no cree que esta sea la mejor medida. El trabajo
político y de marketing de establecer a Apache como una herramienta
valiosa es algo que, en su opinión, puede haber sido más crucial para su
salud a largo plazo. Cuando empezó a poner dinero en manos de Verisign,
consiguió que esa gente se diera cuenta de que Apache tenía una cuota de
mercado real. Ese efectivo habló.
El fork Stronghold, sin embargo, no hizo felices a todos. SSL es una
herramienta importante y alguien iba a empezar a crear otra versión
gratuita. C2Net contrató a Eric Young y su colaborador Tim Hudson y les
pagó para que hicieran un trabajo para Stronghold. La versión principal
del SSLeay original de Young permaneció abierta, y ambos continuaron
agregando correcciones de errores y otras mejoras con el tiempo. Parekh
se sintió cómodo con esta relación. Aunque Stronghold pagaba los
salarios de Young y Hudson, también dedicaban parte de su tiempo libre a
mantener actualizado su conjunto de herramientas SSLeay.
Aún así, la idea de una versión gratuita de SSL era un proyecto tentador
para que alguien lo emprendiera. Mucha gente lo quería. El comercio
digital seguro lo exigía. Hubo muchos incentivos económicos que
empujaron para que sucediera. Eventualmente, un alemán llamado Ralf S.
Engelschall dio un paso al frente y escribió una nueva versión que llamó
modSSL. Engelschall es un contribuyente respetado del esfuerzo de
Apache, y ha escrito o contribuido a varios módulos diferentes que
podrían agregarse a Apache. Él llama a uno el "módulo modrewrite que
baila y canta" para manejar URL fácilmente.
De repente, la nueva versión de Engelschall significó que había forks de
duelo. Una versión salió de Australia, donde los creadores trabajaban
para una empresa que vendía una versión patentada del código. C2Net
distribuyó la versión australiana y se concentró en hacer que su
producto fuera fácil de instalar. El otro salió de Europa, distribuido
gratis por alguien comprometido con una licencia de código abierto. La
interfaz puede haber sido un poco más tosca, pero no costó dinero y
venía con el código fuente. El potencial de batalla entre SSLeay y
modSSL podría haber sido grandioso.
Las dos partes revisaron sus opciones. Parekh debe haberse sentido un
poco frustrado y en desventaja. Tenía una empresa que estaba haciendo un
buen producto con compradores habituales. Entonces apareció una solución
de código abierto. Stronghold de C2Net cuesta dinero y no viene con
código fuente, mientras que modSSL de Engelschall no cuesta nada y viene
con código. Esos eran aspectos negativos importantes que solo podía
combatir aumentando el servicio. Cuando se le preguntó a Engelschall si
su versión gratuita promocionaba C2Net, respondió el correo electrónico
con el mensaje escrito "[sonrisa]".
En esencia, C2Net se enfrentó a la misma situación que muchas empresas
importantes como Microsoft y Apple en la actualidad. Los clientes ahora
tenían una solución viable de código abierto para sus problemas. Nadie
tuvo que pagar a C2Net por el software. Los usuarios de los Estados
Unidos necesitaban una licencia de patente, pero expiraría a finales de
2000. Afortunadamente, Parekh es un verdadero devoto del mundo del
código abierto, aunque ha estado dirigiendo una empresa de código
propietario durante los últimos años. Observó el problema y decidió que
la única forma de mantenerse con vida era unir fuerzas y reparar el
fork.
Para empeorar las cosas, Hudson y Young dejaron C2Net para trabajar en
RSA Data Security. Parekh perdió a dos miembros importantes de su equipo
y enfrentó una competencia intensa. Afortunadamente, su devoción por el
código abierto vino al rescate. Hudson y Young no pudieron retractarse
del trabajo que hicieron en SSLeay. Era de código abierto y estaba
disponible para todos.
Parekh, Engelschall, varios empleados de C2Net y varios otros se
sentaron (por correo electrónico) y crearon un nuevo proyecto al que
llamaron OpenSSL. Este grupo llevaría la antorcha de SSLeay y la
mantendría actualizada. Young y Hudson dejaron de contribuir y dedicaron
su tiempo a crear una versión comercial de RSA Data Security.
Parekh dice de la época: "Aunque fue un serio revés para C2Net que RSA
pirateara a nuestra gente, fue bueno para el público. El desarrollo
realmente se aceleró cuando comenzamos con OpenSSL. Se involucró más
gente y el control se volvió menos centralizado. Se volvió más como el
grupo Apache. Es mucho más grande de lo que era antes y es mucho más
fácil para cualquiera contribuir".
Parekh también trabajó en la reparación de vallas con Engelschall. C2Net
comenzó a adoptar parte del código modSSL y lo combinó en su última
versión de Stronghold. Para facilitar esta combinación, C2Net comenzó a
enviar parte de su código anteriormente propietario a Engelschall para
que pudiera mezclarlo con modSSL y lanzarlo como código abierto. En
esencia, C2Net estaba evitando una competencia desastrosa al ser amable
y compartir con este competidor. Es un movimiento sorprendente que
podría no suceder en los negocios habituales.
La decisión de Parekh parece abierta y benéfica, pero tiene una cierta
cantidad de interés propio detrás. Él explica: "Simplemente decidimos
contribuir con todas las características que teníamos en modSSL para
poder comenzar a usar modSSL internamente, porque hace que nuestro
mantenimiento sea más fácil. No tenemos que mantener nuestra propia
versión patentada de modSSL. Concedido, hemos mejorado la versión
pública, pero esas características no eran significativas".
Esta mezcla no fue particularmente complicada, la mayor parte se centró
en la estructura de las partes del código fuente que manejan la
interfaz. Los programadores los llaman los "ganchos" o la "API". Si
Stronghold y modSSL usan la misma estructura de enlace, entonces
conectarlos es pan comido. Si Engelschall hubiera cambiado la estructura
de enlace de modSSL, entonces C2Net habría tenido que hacer más trabajo.
La decisión de contribuir con el código impidió que Engelschall hiciera
el trabajo él mismo de una manera que podría haber causado más dolor a
C2Net. "De hecho, estaba planeando implementarlos él mismo, por lo que
sería mejor que contribuyéramos con los nuestros para evitar problemas
de compatibilidad", dice Parekh. Es decir, a Parekh le preocupaba que
Engelschall fuera a implementar todas las funciones que usaba C2Net, y
había un peligro muy real de que Engelschall las implementara de una
manera que Parekh no pudiera utilizar. Luego habría una bifurcación más
seria que dividiría aún más a los dos grupos. C2Net no podría tomar
prestado el código de la versión gratuita de OpenSSL muy fácilmente. Así
que decidió contribuir con su propio código. Fue más fácil dar su código
y garantizar que OpenSSL encajaba perfectamente en Stronghold. En
esencia, C2Net optó por ceder un poco para poder seguir obteniendo todas
las mejoras futuras.
No es muy diferente de la industria del automóvil. No hay nada
intrínsecamente mejor o peor en los autos que tienen el volante en el
lado derecho. Son mucho más fáciles de usar en Inglaterra. Pero si
surgiera algún equipo de desarrollo de ingeniería de automóviles
gratuito en Inglaterra, podría tener sentido que una empresa de EE. UU.
donara el trabajo temprano para garantizar que el producto final pueda
tener el volante a ambos lados del automóvil sin un rediseño extenso. Si
Ford simplemente se sentara y esperara obtener el producto final
gratuito, podría descubrir que los ingenieros británicos diseñaron
felizmente para las únicas carreteras que conocían.
Engelschall está feliz con este cambio. Escribió en un mensaje de correo
electrónico: "Hacen el único enfoque razonable: basan su servidor en
modSSL porque saben que no pueden sobrevivir contra la solución de
código abierto con su antiguo código propietario. Y al contribuir con
cosas a modSSL implícitamente hacen su mejor su propio producto. De esta
manera ambas partes se benefician".
Parekh y C2Net ahora tienen un desafío. Deben continuar haciendo que el
paquete Stronghold sea mejor que la versión gratuita para justificar el
costo que la gente está pagando.
No todas las bifurcaciones terminan con una historia tan alegre de
cooperación mutua. Tampoco todas las historias en el mundo del software
libre terminan con la corporación lucrativa dando la vuelta y
devolviendo su código propietario al esfuerzo general. Pero el caso de
C2Net/OpenSSL ilustra cómo la naturaleza del desarrollo de software
alienta a las empresas y personas a dar y cooperar para satisfacer sus
propias necesidades egoístas. El software puede hacer una variedad de
cosas maravillosas, pero la estructura a menudo determina qué tan fácil
es para algunos de nosotros usarlo. Tiene sentido dedicar más tiempo y
hacer donaciones a un proyecto de software libre si quiere asegurarse de
que el producto final se ajuste a sus especificaciones.
La buena noticia es que la mayoría de la gente no tiene muchos
incentivos para romper y bifurcar su propio proyecto. Si permanece en el
mismo equipo, puede usar fácilmente todos los resultados producidos por
los otros miembros. Cooperar es mucho más fácil que luchar porque las
personas tienen un gran incentivo para permanecer juntas. Si no fuera
tan egoísta, sería conmovedor.
