11. Fuente

Los programadores de computadoras aman Star Wars. Por lo tanto, no
debería sorprender que prácticamente todos los miembros de la comunidad
de código libre, en un momento u otro, hayan lanzado la frase "Usa la
fuente, Luke". Hace un trabajo perfecto al capturar la fe mítica que el
mundo de la fuente libre deposita en la capacidad de acceder al código
fuente de un programa. Como todos señalan, en la versión original de
Star Wars, las tropas rebeldes usaban los planos, la Fuente, a la
Estrella de la Muerte que llevaba R2D2 para buscar debilidades.


El reino de la fuente libre ha estado impulsando los paralelos desde
hace algún tiempo. Cuando AT&T dio a conocer su logotipo redondo con un
hoyuelo desplazado, la mayoría de la gente de código libre comenzó a
reírse. La empresa que inició la revolución del software libre al
impulsar sus derechos de propiedad intelectual y molestar a Richard
Stallman había elegido un logotipo que se parecía a la Estrella de la
Muerte. Todos decían: "Las mentes imperialistas piensan igual". Algunos
incluso se preguntaban y esperaban que George Lucas demandara a AT&T por
algún tipo de infracción de marca registrada. Aquellos que usan el sable
de luz de intimidación legal deben morir por el sable de luz de
intimidación legal.


Por supuesto, la gente de código libre sabía que solo su coalición
suelta de rebeldes repartidos por la galaxia sería un rival fuerte para
el Imperio. La Fuente era información, y la información era poder. The
Source también trataba sobre la libertad, una de las mejores y más
consistentes reservas de inspiración revolucionaria que existen. Puede
que los rebeldes no tuvieran equipos de abogados en los cruceros
estelares imperiales, pero esperaban utilizar la Fuente para tejer una
resistencia fuerte, eficaz y más poderosa.


El mito del acceso abierto al código fuente gratuito es poderoso y ha
convertido a muchos en la comunidad en verdaderos creyentes. El código
fuente es una lista de instrucciones para la computadora escritas en un
lenguaje de programación comprensible para los humanos. Una vez que los
compiladores convirtieron el código fuente en la cadena de bits conocida
como código binario u objeto, solo las computadoras (y algunos humanos
muy talentosos) podían entender las instrucciones. He conocido a varias
personas que pueden leer el código binario 8080 a simple vista, pero son
un poco diferentes de la población general.


Cuando las empresas trataron de mantener en secreto su arduo trabajo e
investigación bloqueando el código fuente, construyeron una barrera
entre los usuarios y sus desarrolladores. Los programadores trabajarían
detrás de paredes secretas para escribir el código fuente. Después de
que los compiladores convirtieran la fuente en algo que las computadoras
pudieran leer, la fuente sería bloqueada nuevamente. Los compradores
solo obtendrían el código binario porque eso es todo lo que las empresas
pensaban que necesitaban los consumidores. El código fuente debía
mantenerse en secreto porque alguien podría robar las ideas del interior
y crear su propia versión.


Stallman vio este secreto como un gran crimen. Los usuarios de
computadoras deberían poder compartir el código fuente para que puedan
compartir formas de mejorarlo. Este intercambio debería conducir a más
intercambio de información en un gran circuito de retroalimentación.
Algunas personas incluso usaron la palabra "floración" para describir la
explosión de interés y la retroalimentación cruzada. Están usando la
palabra de la forma en que los biólogos la usan para describir la forma
en que las algas pueden surgir, inundando una región del océano. Ideas
inteligentes, correcciones de errores brillantes y nuevas
características maravillosas aparecen de la nada a medida que la
curiosidad humana se amplifica por la generosidad humana en una gran
explosión de sinergia intelectual. Lo único que falta en la imagen es un
grupo de ewoks peludos que bailan alrededor de una fogata.[^8]


[8]: Linux tiene muchas oportunidades de marketing. Torvalds eligió un
pingüino llamado Tux como mascota, y varias empresas fabrican y venden
pingüinos de peluche para el reino de Linux. El mundo BSD ha abrazado a
un lindo demonio, un juego de palabras visual sobre el hecho de que BSD
UNIX usa la palabra "daemon" para referirse a algunos de los programas
de fondo sin rostro en el sistema operativo.



11.1 El obispo

Eric Raymond, un hombre que es una especie de filósofo de sillón del
mundo del código abierto, hizo un gran trabajo al resumir el fenómeno y
crear este mito en su ensayo "La catedral y el bazar". Raymond es un
programador serio que pasó algún tiempo trabajando en proyectos como GNU
Emacs de Stallman. Vio las ventajas del desarrollo de código abierto
desde el principio, tal vez porque es un libertario empedernido. Las
soluciones gubernamentales son engorrosas. Empoderar a las personas sin
restringirlas es excelente. Raymond se muestra un poco más extremista
que otros libertarios, en parte porque no duda en defender la segunda
enmienda de la Constitución de los Estados Unidos tanto como la primera.
Raymond no se avergüenza de apoyar la posesión generalizada de armas
como una forma de empoderar aún más al individuo. No le gusta la
Asociación Nacional del Rifle porque están demasiado dispuestos a
renunciar a derechos que él siente que son absolutos.


A algunas personas les gusta llamarlo la Margaret Mead del mundo del
código libre porque pasó algún tiempo estudiando y caracterizando la
cultura de la misma manera que lo hizo Mead cuando escribió Coming of
Age in Samoa. Esto puede ser un golpe sutil porque Margaret Mead no es
realmente el mismo ángel intelectual que fue hace mucho tiempo. Derek
Freeman y otros antropólogos plantean serias dudas sobre la capacidad de
Mead para ver sin prejuicios. Mead era una gran fanática del amor libre,
y muchos afirman que no fue casualidad que encontrara maravillosas
historias de sexualidad sin control en Samoa. Freeman volvió a visitar
Samoa y descubrió que no era la tierra libre de culpas de los placeres
libertinos que Mead describía en su libro. Documentó muchos ejemplos de
moderación sexual y vergüenza que Mead aparentemente pasó por alto en su
búsqueda de un paraíso.


Raymond miró el desarrollo de código abierto y encontró lo que quería
encontrar: la maravillosa eficiencia de los mercados no regulados.
Claro, a algunas personas les encantaba etiquetar a Richard Stallman
como comunista, una descripción que siempre ha molestado a Stallman.
Raymond investigó un poco más a fondo y vio que la base del éxito del
movimiento del software libre era la libertad que otorgaba a cada
usuario el poder completo de cambiar y mejorar su software. Así como
Sigmund Freud encontró el sexo en la raíz de todo y Carl Jung descubrió
una batalla de animus y anima, el libertario encontró la libertad.


El ensayo de Raymond fue uno de los primeros en tratar de explicar por
qué los esfuerzos de código libre pueden tener éxito e incluso prosperar
sin los incentivos financieros de una empresa de software estándar
basada en el dinero. Una de las principales razones que citó fue que un
programador podría "rascarse una picazón" que le molestaba. Es decir, un
programador podría molestarse por una pieza de software que limitaba sus
opciones o tenía un problema técnico molesto. En lugar de maldecir la
oscuridad en la cavidad cerebral del programador corporativo que creó el
problema, el hacker de código libre pudo usar el código fuente para
tratar de encontrar el error.


Rascarse con picazón puede ser fundamental para resolver muchos
problemas. Algunos errores en el software son bastante difíciles de
identificar y duplicar. Solo ocurren en situaciones extrañas, como
cuando la impresora se queda sin papel y el módem está sobrecargado por
un archivo largo que llega a través de Internet. Entonces, y solo
entonces, los dos búferes pueden llenarse hasta el borde, chocar entre
sí y bloquear la computadora. El resto del tiempo, el programa flota
felizmente, sin encontrar problemas.


Estos tipos de errores son notoriamente difíciles de descubrir y
caracterizar para los entornos de prueba corporativos. Las empresas
intentan ser diligentes contratando a varios programadores jóvenes y
colocándolos en una habitación con una computadora. El equipo golpea el
software todo el día y desarrolla una animosidad saludable hacia el
equipo de programación que tiene que solucionar los problemas que
descubren. Pueden detectar muchos errores simples, pero ¿qué sucede si
no tienen una impresora conectada a su máquina? ¿Qué sucede si no están
imprimiendo cosas constantemente como lo hacen algunos usuarios de
oficina? El extraño error pasa desapercibido y probablemente no se
solucione.


El modelo de desarrollo corporativo trata de resolver esta limitación
enviando cientos, miles y, a menudo, cientos de miles de copias a
usuarios ambiciosos a los que llamaron "beta testers". Otros los
llamaron "tontos" o "voluntarios gratuitos" porque una vez que terminan
de ayudar a desarrollar el software, pueden pagarlo. Microsoft incluso
cobra a algunos usuarios por el placer de ser probadores beta. Muchos de
los usuarios son pragmáticos. A menudo, no tienen más remedio que
participar en el esquema porque a menudo basan sus negocios en algunos
de los programas que envían estas empresas. Si no funcionara, se
quedarían sin trabajo.


Si bien es mucho más probable que esta amplia distribución de copias
beta encuentre a alguien que esté imprimiendo y sobrecargando un módem
al mismo tiempo, no brinda al usuario las herramientas para ayudar a
encontrar el problema. Su única opción es escribir un mensaje de correo
electrónico a la empresa que diga "Estaba imprimiendo ayer y su software
falló". Eso no es muy útil para el ingeniero, y no sorprende que muchos
de estos informes se ignoren o no se resuelvan.


Raymond señaló que el mundo del código libre puede hacer un gran trabajo
con estos desagradables errores. Caracterizó esto con la frase: "Con
suficientes ojos, todos los errores son superficiales", que caracterizó
como "Ley de Linus". Es decir, eventualmente algún programador
comenzaría a imprimir y usar Internet al mismo tiempo. Después de que el
sistema fallara varias veces, algún programador se preocuparía lo
suficiente por el problema como para investigar la fuente gratuita,
hurgar y detectar el problema. Eventualmente, alguien vendría con el
tiempo, la energía y el compromiso para diagnosticar el problema.
Raymond llamó a esto "Ley de Linus" en honor a Linus Torvalds. Raymond
es un gran admirador de Torvalds y piensa que el verdadero genio de
Torvalds fue organizar un ejército para trabajar en Linux. La
codificación en sí fue un segundo distante.


Por supuesto, esperar a que un usuario encontrara los errores dependía
de que hubiera alguien con suficiente tiempo y compromiso. La mayoría de
los usuarios no son programadores talentosos y la mayoría tiene trabajos
diarios. Raymond y el resto de la comunidad de código libre reconocen
esta limitación, pero señalan que la persona adecuada a menudo aparece
si el error ocurre con la suficiente frecuencia como para convertirse en
un problema real. Si el error es lo suficientemente grave, alguien que
no sea programador puede incluso contratar a un programador para que
introduzca el código fuente.


Esperar a que el bicho y el programador se encuentren es como esperar a
que Arthur encuentre la espada en la piedra. Pero Raymond y el resto de
la comunidad de código libre incluso le han dado la vuelta a esta
limitación y la han promocionado como una ventaja. Confiar en los
usuarios para rascarse significa que los problemas solo se abordan si
tienen distritos electorales reales con una población lo suficientemente
grande como para generar el único creyente verdadero con suficiente
tiempo libre. Es una especie de mercado libre en el tiempo de las
personas para corregir errores. Si la demanda está ahí, se creará la
solución. Es la Ley de Say reformulada para el desarrollo de software:
"el suministro de errores crea el talento para las correcciones".


El desarrollo corporativo, por otro lado, ha estado obsesionado durante
mucho tiempo con agregar más y más funciones a los programas para dar a
las personas suficientes razones para comprar la actualización. Los
gerentes saben desde hace mucho tiempo que es mejor dedicar más tiempo a
agregar más trucos y widgets a un programa que corregir sus errores. Es
por eso que Microsoft Word puede hacer tantas cosas diferentes con los
encabezados y pies de página de los documentos, pero no puede detener la
reproducción de un virus Word Macro. La gente de Microsoft sabe que
cuando los gerentes corporativos se sientan a decidir si gastar los
miles de dólares para actualizar sus máquinas, necesitarán un conjunto
de nuevas características atractivas. A la gente no le gusta pagar por
la corrección de errores.


Por supuesto, las corporaciones también tienen algunas ventajas. Money
se asegura de que alguien esté tratando activamente de resolver los
errores en el programa. La misma visión de libre mercado garantiza que
las empresas que constantemente decepcionan a sus clientes se irán a la
quiebra. Este desarrollador tiene la ventaja de estudiar el mismo código
fuente día tras día. Eventualmente, aprenderá lo suficiente sobre las
entrañas de la Fuente para ser mucho más efectivo que el tipo con la
impresora y el módem atascados. Debería ser capaz de atrapar el error 10
veces más rápido que el aficionado al código libre solo porque es un
experto en el sistema.


Raymond reconoce este problema pero propone que el modelo de fuente
libre aún puede ser más efectivo a pesar de la inexperiencia de las
personas que se ven obligadas a rascarse la picazón. Una vez más, toca
el mundo de la filosofía libertaria y sugiere que el mundo del software
libre es como un bazar lleno de muchos comerciantes diferentes que
ofrecen sus productos. El desarrollo corporativo, por otro lado, está
estructurado como los sindicatos religiosos que construyeron las
catedrales medievales. Los bazares ofrecían mucha competencia pero
ningún orden. Las catedrales estaban a cargo de equipos centrales de
sacerdotes que aprovecharon la riqueza de la ciudad para construir la
visión de un arquitecto.


Las diferencias entre los dos eran bastante simples. El equipo de la
catedral podría producir una gran obra de arte si el arquitecto tuviera
talento, el equipo de financiamiento tuviera éxito y la administración
pudiera mantener a todos enfocados en hacer su trabajo. Si no, nunca
llegó tan lejos. El bazar, por otro lado, consistía en muchos pequeños
comerciantes que intentaban superarse unos a otros. Los mejores
cocineros terminaron con la mayor cantidad de clientes. Los otros pronto
cerraron.


La comparación con el software era simple. Las corporaciones reunían los
diezmos, empleaban un arquitecto central con una gran visión,
administraban el equipo de programadores y enviaban un producto de vez
en cuando. El mundo de Linux, sin embargo, permite que todos toquen la
Fuente. La gente intentaría arreglar las cosas o añadir nuevas
funciones. Las mejores soluciones serían adoptadas por otros y las
mediocres quedarían en el camino. Proliferarían muchas versiones
diferentes de Linux, pero con el tiempo el mercado de software se
fusionaría en torno a la mejor versión estándar.


"Desde el punto de vista de la programación del constructor de
catedrales, los errores y los problemas de desarrollo son fenómenos
complicados, insidiosos y profundos. Se necesitan meses de escrutinio
por parte de unos pocos dedicados para desarrollar la confianza de que
los ha eliminado todos. Por lo tanto, los largos intervalos de
publicación y la inevitable decepción cuando los lanzamientos largamente
esperados no son perfectos", dijo Raymond.


"En la vista de bazar, por otro lado, asumes que los errores son
fenómenos generalmente superficiales, o, al menos, que se vuelven
superficiales bastante rápido cuando se exponen a miles de
desarrolladores de código ansiosos que golpean cada nueva versión. En
consecuencia, usted suelte a menudo para obtener más correcciones y,
como efecto secundario beneficioso, tiene menos que perder si se produce
un error ocasional".


11.2 Flecha gigante

Este bazar puede ser una poderosa influencia para resolver problemas.
Claro, no está guiado por un arquitecto talentoso y equipos de
sacerdotes, pero es un gran juego contra todos. Es bastante improbable,
por ejemplo, que el tipo con la impresora sobrecargada y la línea de
módem también sea un programador talentoso con una gran visión para
resolver el problema. Alguien llamado Arthur solo tropieza con la piedra
correcta con la espada correcta de vez en cuando. Pero si el usuario
frustrado puede hacer un buen trabajo al caracterizarlo e informarlo,
entonces alguien más puede resolverlo.


Dave Hitz fue uno de los programadores que ayudó a Keith Bostic a
reescribir UNIX para que pudiera estar libre de los derechos de autor de
AT&T. En la actualidad, dirige Network Appliance, una empresa que crea
servidores de archivos simplificados que ejecutan BSD en su núcleo. Ha
estado escribiendo sistemas de archivos desde la universidad, y el
software gratuito fue muy útil cuando estaba comenzando su empresa.
Cuando comenzaron a construir las grandes máquinas, los ingenieros
simplemente buscaron en el grupo de código fuente gratuito para los
sistemas operativos y extrajeron gran parte del código que alimentaría
sus servidores. Modificaron mucho el código, pero el cuerpo de software
libre que ayudó a crear fue un excelente punto de partida.


Según su experiencia, muchas personas encontraban un error y lo
reparaban con una solución que fuera lo suficientemente buena para
ellos. Algunos eran solo niños en la universidad. Otros eran
programadores que no tenían ni el tiempo ni la energía para leer el
código fuente y comprender la mejor manera de solucionar el problema.
Algunos solucionaron el problema por sí mismos, pero sin darse cuenta
crearon otro problema en otro lugar. Ordenar todos estos problemas fue
difícil de hacer.


Pero Hitz dice: "Incluso si lo arreglaron completamente de manera
incorrecta, si encontraron el lugar donde desapareció el problema,
entonces pusieron una flecha gigante sobre el problema". Eventualmente,
suficientes flechas proporcionarían a alguien suficiente información
para resolver el problema correctamente. Muchas de las nuevas versiones
escritas por personas pueden perderse en el tiempo, pero eso no
significa que no hayan tenido un efecto importante en la evolución de la
Fuente. "Creo que rara vez se da el caso de que haya personas que hagan
de su vida una amplia base de código fuente", dijo. "Hay un montón de
personas que son diletantes. El mensaje es: 'No subestimes a los
diletantes'".


11.3 Bazar o Catedral

Cuando Raymond escribió el ensayo, solo estaba tratando de descubrir las
diferencias entre varios de los campos en el mundo del código libre. Se
dio cuenta de que las personas que ejecutan proyectos de código libre
tenían diferentes formas de compartir. Quería explicar qué método de
desarrollo de código libre funcionaba mejor que otros. Fue solo más
tarde que el ensayo comenzó a tomar un objetivo más serio cuando todos
comenzaron a darse cuenta de que Microsoft era quizás el equipo de
desarrollo con forma de catedral más grande que existía.


Raymond dijo: "Creo que, como todos los demás en la cultura, vagué de un
lado a otro entre los dos modos, ya que parecía apropiado porque no
tenía una teoría ni conciencia".


Vio a Richard Stallman y los primeros años de los proyectos GNU como un
ejemplo de desarrollo estilo catedral. Estos equipos solían trabajar
durante meses, si no años, antes de compartir sus herramientas con el
mundo. El propio Raymond dijo que se comportó de la misma manera con
algunas de las primeras herramientas que escribió y con las que
contribuyó al proyecto GNU.


Linus Torvalds cambió de opinión al aumentar la velocidad de compartir,
que Raymond caracterizó como la regla de "liberar temprano y con
frecuencia, delegar todo lo que pueda, estar abierto hasta el punto de
la promiscuidad". Torvalds ejecutó Linux de la manera más abierta
posible, y esto finalmente atrajo a algunos buenos colaboradores. En el
pasado, la FSF era mucho más cuidadosa con lo que adoptaba y aportaba al
proyecto GNU. Torvalds tomó muchas cosas en sus distribuciones y mutaron
tan a menudo como a diario. Ocasionalmente, salían nuevas versiones dos
veces al día.


Por supuesto, Stallman y Raymond han tenido peleas en el pasado. Raymond
tiene cuidado de elogiar al hombre y decir que valora su amistad, pero
también lo modera diciendo que es difícil trabajar con Stallman.


En el caso de Raymond, dice que una vez quiso reescribir gran parte del
código Lisp que estaba integrado en GNU Emacs. Emacs de Stallman
permitía a cualquier usuario conectar su propio software a Emacs
escribiéndolo en una versión especial de Lisp. Algunos tenían lectores
de correo escritos. Otros habían agregado un código de generación
automática de comentarios. Todo esto fue escrito en Lisp.


Raymond dice que en 1992, "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 y yo quería abordar ese proyecto".


Según Raymond, Stallman no quería que él hiciera el trabajo y se negó a
incluirlo en la distribución. Stallman pudo hacer esto porque controlaba
la Free Software Foundation y la distribución del software. Raymond
podría haber creado su propia versión, pero se negó porque era demasiado
complicada y, en última instancia, mala para todos si surgían dos
versiones.


Por su parte, Stallman explica que estaba contento de aceptar partes del
trabajo de Raymond, pero que no quería verse obligado a aceptarlas
todas. Stallman dice: "En realidad, acepté una cantidad sustancial del
trabajo que Eric había hecho. Tenía varias ideas que me gustaban, pero
también tenía algunas ideas que pensé que estaban equivocadas. Acepté
con gusto su ayuda, siempre y cuando podía juzgar sus ideas una por una,
aceptando algunas y rechazando otras.


"Pero posteriormente me pidió que hiciera un acuerdo general en el que
se haría cargo del desarrollo de una gran parte de Emacs, operando de
forma independiente. Sentí que debía seguir juzgando sus ideas
individualmente, así que dije que no".


Raymond combinó esta experiencia con el tiempo que pasó observando al
equipo de Torvalds impulsar el kernel de Linux y los usó como base para
su ensayo sobre la distribución de Source. "Principalmente, estaba
tratando de extraer algunos factores que había observado como folclore
inconsciente para que la gente pudiera sacarlos y razonar sobre ellos",
dijo. Raymond dice: "Alguien señaló que hay un paralelismo con 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".


Hay una buena razón empírica para la fe en la fuerza de la fuente libre.
Después de todo, un grupo de personas que rara vez se veían había
reunido una gran cantidad de código fuente que estaba pateando el
trasero de Microsoft en algunos rincones del mundo informático. Los
servidores Linux eran comunes en Internet y cada día eran más comunes.
El escritorio estaba esperando ser conquistado. Lo habían hecho sin
opciones sobre acciones, sin jets corporativos, sin contratos secretos y
sin alianzas potencialmente ilegales con fabricantes de computadoras. El
éxito del software del mundo GNU y Linux fue realmente impresionante.
Por supuesto, los mitos pueden llevarse demasiado lejos. Programar
computadoras es un trabajo duro y, a menudo, frustrante. Compartir el
código fuente no hace que los errores o problemas desaparezcan, solo
hace que sea un poco más fácil para otra persona profundizar en un
programa para ver qué está fallando. El código fuente puede ser
simplemente una lista de instrucciones escritas en un lenguaje de
programación que está diseñado para que los humanos puedan leerlo, pero
eso no significa que sea fácil de entender. De hecho, la mayoría de los
humanos no entenderán la mayor parte del código fuente porque los
lenguajes de programación están diseñados para ser entendidos por otros
programadores, no por la población en general.


Para empeorar las cosas, los propios programadores tienen dificultades
para comprender el código fuente. Los programas de computadora a menudo
son bastante complicados y puede tomar días, semanas e incluso meses
entender qué es lo que un extraño código fuente le dice a una
computadora que haga. Aprender lo que sucede en un programa puede ser un
trabajo complicado incluso para los mejores programadores, y no es algo
que se tome a la ligera.


Si bien muchos programadores y miembros del mundo del código abierto se
apresuran a elogiar el movimiento, también podrán citar problemas con el
mito de la Fuente. No es que la Fuente no funcione, dirán, es solo que
rara vez funciona tan bien como implica la exageración. Las floraciones
rara vez son tan vigorosas y los mercados libres de mejoras rara vez son
tan líquidos.


A Larry McVoy, un ávido programador, protoacadémico y desarrollador del
kit de herramientas BitKeeper, le gusta encontrar fallas en el modelo.
No es que no le guste compartir el código fuente, es solo que no es lo
suficientemente rico como para asumir proyectos de software libre.
"Necesitamos encontrar una manera para que la gente desarrolle software
libre y pague sus hipotecas y forme una familia", dice.


"Si miras de cerca", dice, "realmente no hay un bazar. En la parte
superior siempre es una catedral de una sola persona. Es Linus, Stallman
o alguien más". Es decir, el mito de un bazar como una competencia
abierta y libre para todos no es exactamente cierto. Claro, todos pueden
descargar el código fuente, jugar con él y hacer sugerencias, pero al
final del día importa lo que diga Torvalds, Stallman o cualquier otra
persona. Siempre hay un gran arquitecto de Chartres que se enseñorea de
su dominio.


Parte de este problema es el éxito de la metáfora de Raymond. Dijo que
solo quería darle a la comunidad algunas herramientas para comprender el
éxito de Linux y razonar al respecto. Pero sus dos visiones de una
catedral y un bazar tenían tal claridad que la gente se concentraba más
en dividir el mundo en catedrales y bazares. En realidad, hay una gran
cantidad de mezcla en el medio. Los bazares más eficientes en la
actualidad son los centros comerciales suburbanos que tienen una empresa
administradora que construye el sitio, alquila las tiendas y crea una
experiencia unificada. Las áreas comerciales del centro a menudo
fallaban porque siempre había un dueño de tienda que podía arruinar una
cuadra entera instalando una tienda que vendiera pornografía. Por otro
lado, la religión siempre ha sido una especie de bazar. Martín Lutero
dividió efectivamente el cristianismo al introducir la competencia.
Incluso dentro de las denominaciones, diferentes parroquias luchan por
los corazones y las almas de las personas.


El mismo desenfoque se aplica al mundo del software de código abierto.
El kernel de Linux, por ejemplo, contiene muchos miles de líneas de
código fuente. Algunos ponen el número en 500.000. Algunas personas
talentosas como Alan Cox o Linus Torvalds lo saben todo, pero la mayoría
solo están familiarizados con los rincones que necesitan saber. Estas
personas, que pueden ser miles, son superadas en número por los millones
que usan el sistema operativo Linux a diario.


Es interesante preguntarse si la proporción entre usuarios técnicamente
ungidos y alegres en el mundo del código libre es comparable a la
proporción en el dominio de Microsoft. Después de todo, Microsoft
compartirá su código fuente con socios cercanos después de que firmen
algunos formularios de confidencialidad.[^9] Si bien Microsoft tiene
cuidado con lo que les dice a sus socios, solo revelará información
cuando haya algo que ganar. Otras compañías ya se lanzaron y comenzaron
a ofrecer el código fuente a todos los usuarios que quieran verlo.


[9]: Al momento de escribir este artículo, Microsoft no ha publicado su
código fuente, pero se sabe que la empresa está examinando la opción
como parte de su acuerdo con el Departamento de Justicia. Responder a
esta pregunta es imposible por dos razones diferentes. Primero, nadie
sabe lo que Microsoft revela a sus socios porque mantiene toda esta
información en secreto, por reflejo. Los contratos generalmente se
negocian bajo confidencialidad, y la empresa no ha tenido reparos en
explotar el poder que proviene de la falta de información.


En segundo lugar, nadie sabe realmente quién lee el código fuente de
Linux por la razón opuesta. La fuente de GNU/Linux está ampliamente
disponible y se descarga con frecuencia, pero eso no significa que se
lea o estudie. Los CD de Red Hat vienen con un CD lleno de binarios
precompilados y el segundo lleno de código fuente. ¿Quién sabe quién
mete el segundo CDROM en su computadora? Todos son libres de hacerlo en
la privacidad de su propio cubículo, por lo que no se mantienen
registros.


Si tuviera que apostar, diría que las proporciones de cognoscenti a
usuarios desinformados en los mundos de Linux y Microsoft son bastante
similares. Leer el código fuente requiere demasiado tiempo y demasiado
esfuerzo para que muchos en el mundo de Linux aprovechen el enorme río
de información disponible para ellos.


Si esto es cierto o al menos casi cierto, entonces ¿por qué el mundo del
código libre ha podido moverse mucho más rápido que el mundo de
Microsoft? La respuesta no es que todos en el mundo de la fuente libre
estén usando la Fuente, es que todos son libres de usarla. Cuando una
persona necesita hacer una pregunta o rascarse una picazón, la Fuente
está disponible sin hacer preguntas ni consultar a ningún abogado.
Incluso a las 3:00 a.m., una persona puede leer la Fuente. En Microsoft
y otras corporaciones, a menudo necesitan esperar a que la persona que
dirige esa división o sección les dé permiso para acceder al código
fuente.


Hay otras ventajas. El mundo del código fuente gratuito dedica una gran
cantidad de tiempo a mantener el código fuente limpio y accesible. Un
programador que trata de salirse con la suya con una mano de obra
descuidada y una mala documentación pagará por ello más tarde cuando
otros lleguen y hagan miles de preguntas.


Los desarrolladores corporativos, por otro lado, tienen capas de secreto
y burocracia para aislarlos de preguntas y comentarios. A menudo es
difícil encontrar al programador adecuado en la madriguera de conejos de
los cubículos que tiene el código fuente en primer lugar. Se citó a un
programador de Microsoft diciendo: "Un desarrollador de Microsoft que
trabaja en el sistema operativo no puede rascarse la picazón que tiene
con Excel, ni el desarrollador de Excel puede rascarse la picazón con el
sistema operativo; le llevaría meses descubrir cómo para compilar,
depurar e instalar, y probablemente no pudo obtener el acceso adecuado a
la fuente de todos modos".


Este problema es endémico en las corporaciones. Los clientes están
comprando la versión binaria, no el código fuente, por lo que no hay
razón para disfrazar las alas detrás del escenario del teatro. Sin
embargo, después de un tiempo, la gente cambia de cubículo, se muda a
otras corporaciones y la información desaparece. Si bien las empresas
intentan mantener bases de datos de código fuente para sincronizar el
desarrollo, los esfuerzos a menudo fracasan. Después de que Apple
canceló el desarrollo de su dispositivo portátil Newton, muchos usuarios
de Newton estaban furiosos. Habían basado grandes proyectos en la
plataforma y no querían reiniciar su trabajo. Muchos preguntaron si
Apple podría simplemente regalar el código fuente del sistema operativo
en lugar de dejar que se pudra en algún disco duro. Apple eludió estas
solicitudes, y esto hizo que algunas personas se volvieran aún más
cínicas. Un desarrollador externo especuló: "Probablemente no sería
posible volver a crear el sistema operativo. Todos los desarrolladores
se fueron. Todos fueron a Palm, y probablemente no podrían volver a
armarlo si quisieran".


Por supuesto, las corporaciones intentan combatir esta podredumbre
haciendo que sus programadores hagan un buen trabajo al principio y
escriban mucha documentación. En la práctica, esto falla un poco porque
no es recompensado por la cultura del secreto. Conozco a un programador
que trabajó para un proyecto en el MIT. El jefe pensó que estaba siendo
inteligente al solicitar comentarios sobre cada procedimiento y, de
hecho, lo hizo cumplir con un robot de escaneo de texto automatizado que
revisaría el código fuente y contaría los comentarios. Mi amigo se dio
la vuelta y conectó una versión de los populares chatterbots de
inteligencia artificial como Eliza y canalizó las respuestas al campo de
comentarios. Entonces todos estaban felices. El chatterbot llenó el
campo de comentarios, la policía de comentarios automatizada encontró
algo vagamente inteligente y el programador pasó su tiempo libre
haciendo otras cosas. El jefe nunca descubrió el problema.


Los programadores son iguales en todo el mundo, y unirse al mundo del
código libre no los hace mejores personas ni destruye su descaro. Pero
los penaliza si otros vienen e intentan usar su código. Si es
inescrutable, descuidado o difícil de entender, los demás lo ignorarán o
los acosarán con preguntas. Eso es un fuerte incentivo para hacerlo
bien.


11.4 Código abierto y bombillas

Las limitaciones del poder del código abierto podrían resumirse en la
respuesta a la pregunta "¿Cuántos desarrolladores de código abierto se
necesitan para cambiar una bombilla?" La respuesta es: 17. Diecisiete
para discutir sobre la licencia; 17 para discutir sobre la muerte
cerebral de la arquitectura de la bombilla; 17 para discutir sobre un
nuevo modelo que abarque todos los modelos de iluminación y que facilite
el reemplazo de velas, fogatas, luces piloto y tragaluces con el mismo
mecanismo fácil de extender; 17 para especular sobre la conspiración
industrial secreta que asegura que las bombillas se quemarán con
frecuencia; 1 para finalmente cambiar la bombilla; y 16 que deciden que
esta solución es lo suficientemente buena por el momento.


El modelo de desarrollo de código abierto es una excelente manera para
que personas muy creativas produzcan software fascinante que rompa
paradigmas y establezca nuevos estándares de excelencia. Sin embargo,
puede que no sea la mejor manera de terminar trabajos aburridos como
ajustar una interfaz gráfica o asegurarse de que el software de
programación utilizado por los ejecutivos sea lo más resistente posible.


Si bien el modelo de desarrollo abierto ha abordado con éxito el
problema de la creación de excelentes herramientas, de la creación de un
sistema operativo sólido y de la creación de aplicaciones de
electrodomésticos muy flexibles, como navegadores web, está muy lejos de
ganar la batalla por el escritorio. Algunas personas de código libre
dicen que las aplicaciones de escritorio para usuarios promedio están a
la vuelta de la esquina y la siguiente parada en el Free Software
Express. Otros no están tan seguros.


David Henkel-Wallace es uno de los fundadores de la empresa de software
libre Cygnus. Esta empresa basó su éxito en el apoyo a las herramientas
de desarrollo creadas por la Free Software Foundation de Stallman.
Firmarían contratos con empresas para responder cualquier pregunta que
tuvieran sobre el uso de las herramientas de software libre. Al
principio, las empresas se negaban a pagar por el soporte hasta que se
dieron cuenta de que era más barato que contratar personal técnico
interno para hacer el trabajo. A John Gilmore, uno de los cofundadores,
le gustaba decir: "Hacemos que el software gratuito sea asequible".


La empresa creció ayudando a los fabricantes de chips a ajustar el
compilador FSF, GCC, para su chip. A menudo, esta era una tarea difícil
y ardua, pero era muy valiosa para el fabricante del chip porque los
clientes potenciales sabían que podían conseguir un buen compilador para
producir software para el chip. Si bien Intel continuó dominando el
escritorio, el mercado de chips integrados para productos como estufas,
hornos de microondas, VCR u otras cajas inteligentes creció a medida que
los fabricantes lanzaban nuevos chips para que fuera más barato y más
fácil agregar funciones inteligentes a las cajas que antes eran tontas.
. Los ingenieros de las empresas a menudo estaban encantados de
descubrir que podían seguir usando GCC para escribir software para un
nuevo chip, y esto facilitó la venta del chip.


Cygnus siempre distribuyó a la Fuente sus modificaciones a GCC como
exigía la Licencia Pública General de GNU. Esto no fue un gran problema
porque los fabricantes de chips querían que el software fuera gratuito y
fácil de usar para todos. Esto convirtió a Cygnus en uno de los centros
de intercambio de gran parte de la información sobre cómo funcionaba GCC
y cómo hacerlo más rápido.


Henkel-Wallace se apresura a elogiar el poder del código fuente
disponible públicamente para los clientes de Cygnus. Después de todo,
todos eran programadores. Si veían algo que no les gustaba con GCC,
sabían cómo hurgar en el interior y arreglarlo. Ese era su trabajo.


"[GCC] es una herramienta de compilación y fue utilizada por los
desarrolladores, por lo que fueron lo suficientemente inteligentes.
Cuando algo molestaba a alguien, lo solucionábamos. Había un
acoplamiento muy estrecho", dijo.


Sin embargo, se pregunta abiertamente si el procesador de textos
promedio o el usuario de herramientas básicas podrá hacer algo. Él dice:
"La desventaja es que es difícil transferir ese conocimiento con un
usuario que no es un desarrollador. Digamos que Quicken tiene una
característica especial para los abogados. Necesita tener un modelo más
formal porque los abogados no son desarrolladores. (Somos afortunados en
ese sentido)".


Es decir, los abogados no están lo suficientemente instruidos en las
entrañas del desarrollo informático para quejarse de la manera correcta.
Un programador podría decir: "GCC está optimizando demasiado código
muerto que en realidad no está muerto". Otras personas en la comunidad
de GCC sabrían lo que está pasando y podrían solucionarlo. Un abogado
podría simplemente decir: "Quicken arruinó mi facturación y me hizo
facturar veintiséis horas en un día". Esto no identificaría el problema
lo suficiente como para que la gente lo resuelva. El abogado no entiende
el interior del software como el programador.


En situaciones como esta, Henkel-Wallace cree que un equipo de estilo
corporativo puede ser el único que puede estudiar los problemas lo
suficientemente a fondo como para encontrar soluciones. Intuit, el
fabricante de Quicken, es bien conocido por grabar en video a muchos
usuarios estándar que usan su producto por primera vez. Esto les permite
identificar los puntos ásperos del programa e identificar los lugares
donde podría mejorarse. Este incesante alisado y pulido ha convertido al
producto en una de las herramientas más conocidas y utilizadas en los
escritorios. No está claro que los no programadores podrían haber
logrado la misma calidad trabajando junto con la Fuente a su
disposición.

11.5 La Fuente

Hay corrientes más profundas y filosóficas en el mundo del código
abierto. La industria de las computadoras personales tiene solo unas
pocas décadas. Si bien ha avanzado rápidamente y ha resuelto muchos
problemas, todavía hay muy poca comprensión del campo y de lo que se
necesita para que una computadora sea fácil de usar. Esta ha sido la
gran lucha, y el mundo del código libre puede ser una parte esencial de
este viaje.


Tim O'Reilly, el editor de muchos libros y un defensor vocal del mundo
del código abierto, dice: "Hemos pasado por este período de pensar en
los programas como artefactos. Un objeto binario es una cosa. El código
abierto es parte del pensamiento de las computadoras como un proceso".
En otras palabras, hemos hecho un buen trabajo al crear computadoras que
se pueden comprar listas para usar y software que se puede comprar en
cajas retractiladas, pero no hemos hecho un buen trabajo al hacer
posible que la gente hable con Las máquinas.


En gran medida, el proceso ha sido una búsqueda de un buen lenguaje para
comunicarse con la computadora. La mayor parte del desarrollo reciente
siguió al trabajo en Xerox PARC que creó algunas de las primeras
interfaces gráficas de usuario. Apple siguió su ejemplo y Microsoft
siguió a Apple. Todos aceptaron la idea de que crear una imagen clara
que representara los archivos en una pantalla sería una metáfora clara
que facilitaría la interacción de las personas con las computadoras.
Arrastrar un archivo a la papelera era de alguna manera más fácil para
las personas que escribir un comando críptico como "rm".


En la década de 1980, ese tipo de pensamiento gráfico se consideraba
brillante. Las imágenes eran más bonitas que las palabras, por lo que
era fácil mirar la bonita y limpia pantalla de Macintosh y pensar que
era más fácil de usar simplemente porque era más fácil de mirar.


Pero las características bonitas simplemente escondían una gran cantidad
de complejidad, y aun así era difícil trabajar con las máquinas. Don
Norman, un ingeniero de interfaz humano/computadora de Apple, escribió
una vez una discusión fascinante sobre el diseño de la compañía del
interruptor de encendido y apagado de su computadora. Señaló que el
interruptor no podía ser un simple interruptor de alimentación que
pudiera apagar y encender porque la computadora necesitaba orquestar el
procedimiento de encendido y apagado. Necesitaba cerrar archivos,
almacenar datos de forma segura y asegurarse de que todo estuviera listo
para comenzar de nuevo.


El diseño del interruptor de encendido se hizo aún más complicado por el
hecho de que se suponía que funcionaba incluso cuando la computadora
fallaba. Es decir, si una mala programación desordena la memoria y
estropea el procesador central, se supone que el interruptor de
encendido apagará la máquina. Por supuesto, la computadora ni siquiera
pudo sumar dos números después de fallar, por lo que ni siquiera pudo
comenzar a realizar todo el trabajo administrativo necesario para apagar
la máquina. El Macintosh en el que escribí este libro puede fallar tanto
que el interruptor de encendido no funciona, y solo puedo reiniciarlo
metiendo un clip en un agujero oculto.


El trabajo de Norman muestra lo difícil que puede ser idear un lenguaje
simple que permita a los humanos y las computadoras comunicarse sobre
una tarea que solía resolverse con un interruptor de luz de dos
posiciones. Este problema se puede ver en toda la industria. Un tutor de
informática me dijo: "Estoy tan cansado de decirle a la gente que apague
sus computadoras presionando el botón 'Inicio'". Microsoft Windows
coloca todas las funciones en un árbol de menús que surge de un botón
llamado "Inicio". Esta puede haber sido una excelente manera de capturar
el potencial para hacer cosas nuevas que sintieron que estaban
vendiendo, pero sigue siendo confuso para todos los nuevos usuarios de
las máquinas. ¿Por qué deberían presionar Start para detenerlo?


La búsqueda de este control a nivel de Fuente puede tomar muchos giros
extraños. A mediados de la década de 1980, los programadores de Apple se
dieron cuenta de que habían ido demasiado lejos cuando simplificaron la
interfaz de la Mac. El lenguaje visual de señalar y hacer clic en los
íconos puede haber sido excelente para los nuevos usuarios, pero estaba
empezando a frustrar a los usuarios sofisticados que querían automatizar
lo que hacían. Muchos diseñadores gráficos se encontraban haciendo
repetidamente los mismos pasos con los archivos de imagen, y era
aburrido. Se preguntaron, ¿por qué la computadora no podía simplemente
repetir todas sus instrucciones y ahorrarles todo eso de apuntar y hacer
clic? En cierto sentido, los usuarios sofisticados de Mac buscaban la
Fuente. Querían poder escribir y modificar programas simples que
controlaran su software. El problema era que la pantalla gráfica de la
Mac no era realmente adecuada para la tarea. ¿Cómo describirías mover el
mouse y hacer clic en un botón? ¿Cómo se te ocurre un lenguaje que
signifique "recorta esta muestra y pégala aquí"? Las acciones eran tan
visuales que no había palabras ni lenguaje para describirlas.


Este problema confundió a Apple durante los siguientes 10 años, y la
compañía está terminando poco a poco su solución, conocida como
AppleScript. La tarea no ha sido sencilla, pero ha sido gratificante
para muchos que utilizan sus Macintosh como cadenas importantes en las
líneas de producción de datos. Apple incluyó instrucciones para mover
íconos a ubicaciones, cargar archivos, cambiar el color de los íconos e
iniciar programas con otros.


La mejor extensión fue un truco que hizo que el AppleScript fuera
"grabable". Es decir, podría encender una grabadora antes de pasar por
los diferentes trabajos. La Mac llevaría un registro de tus acciones y
generaría un programa que te permitiría repetir lo que estabas haciendo.
Aún así, los resultados estuvieron lejos de ser simples de entender o
usar. Aquí hay un fragmento simple de código AppleScript que
seleccionará todos los archivos en un directorio con la palabra
"Speckle" en su título y los abrirá con otra aplicación:


Esta fuente se puede ejecutar una y otra vez para finalizar una tarea.
Poner esta herramienta a disposición de los usuarios ha sido un reto
para Apple porque les obliga a facilitar la programación. Muchas
personas aprenden AppleScript activando la función de grabación y
observando lo que sucede cuando hacen lo que harían normalmente. Luego,
aprenden a insertar algunos comandos más para realizar la tarea con
éxito. Al final, se convierten en programadores que manipulan la Fuente
sin darse cuenta.


O'Reilly y otros creen que el esfuerzo de código abierto es solo una
extensión de esta necesidad. A medida que las computadoras se vuelven
más y más complejas, los desarrolladores deben hacer que el
funcionamiento interno sea cada vez más abierto para los usuarios. Esta
es la única forma en que los usuarios pueden resolver sus problemas y
usar las computadoras de manera efectiva.


"La vanguardia de la industria informática está en el infoware. No hay
mucho jugo en el tipo de aplicaciones que escribimos en los años ochenta
y noventa. A medida que tengamos reconocimiento de voz, iremos aún más
en la dirección del código abierto, " él dice.


"Cada vez hay más recetas escritas. Estas van a migrar a capas cada vez
más bajas de software y la computadora tendrá un vocabulario cada vez
más grande". Es decir, cada vez más la Fuente necesitará volverse
transparente para los usuarios. No es solo una batalla política de
Microsoft contra el mundo. No es solo la lucha de un programador meter
la nariz en cada rincón de un dispositivo. Se trata de la usabilidad.
Cada vez más personas necesitan escribir programas para enseñar a las
computadoras a hacer lo que necesitan hacer. El acceso a la Fuente es la
única forma de lograrlo.


En otras palabras, las computadoras se están convirtiendo en una parte
cada vez más grande de nuestras vidas. Su lenguaje es cada vez más
comprensible para los humanos, y los humanos hablan mejor el lenguaje de
las computadoras. Estamos convergiendo. Cuanto más lo hagamos, más
importante será la Fuente. No hay nada que Microsoft o las empresas
estadounidenses puedan hacer al respecto. Van a tener que acompañarlos.
Van a tener que darnos acceso a la Fuente.