"Ya sabemos que el Open Source no depende del código; depende de la Comunidad"

Una entrevista con Wilfredo Sánchez, ex-desarrollador principal del proyecto Darwin (Macintosh OS X)

Más información: eiohel@openoffice.org | ver condiciones para su reproducción

Editor's Column

15 de febrero de 2001

En un artículo anterior, Reviewing the Others: Darwin, analicé de manera breve el ambicioso proyecto Darwin de Apple. Ese artículo fue el primero en una serie esporádica sobre proyectos de código fuente abierto grandes; se entiende que la serie debe aportar una visión completa del tema para toda la comunidad de OpenOffice.org. La entrevista reproducida abajo nos comunica la perspectiva de un desarrollador principal sobre la cuestión del Open Source.

Wilfredo Sánchez era, hasta hace poco, el desarrollador principal del proyecto Darwin, el corazón de código fuente abierto del nuevo sistema operativa OS X ("diez") de Apple. Fred mantiene todavía los lazos con Darwin, donde participa como desarrollador activo, pero ya no está con Apple. En la actualidad, como el lo dice, es "el director de programas de código fuente abierto de KnowNow, Inc", donde está "trabajando en la tecnología para permitir lo que se ha llamado el 'web de dos sentidos'." Fred, de modo muy amable, encontró tiempo en su agenda para responder a algunas preguntas que hicé por correo electrónico la semana pasada. Mis preguntas están en cursiva; sus respuestas en letra normal.

Una ojeada a tu curriculum demuestra que has participado como desarrollador y director de proyecto en casi todos los proyectos importantes de código fuente abierto de los últimos diez años. ¿Qué es lo que inicialmente te llamó la atención del Open Source? ¿Y los temas que te atrajeron al principio, todavía son vigentes?

Mi interés data de la universidad. Era un estudiante en el MIT (Instituto de Tecnología de Massachusetts) en 1990, y lo que único que sabía de los ordenadores era cómo usar unos pocos programas en clónicos IBM PC que funcionaban bajo DOS, y antes que aquello, con el Atari 800 y el TRS-80. No sabía mucho sobre la programación. Así que llegué al MIT con un montón de floppies PC (los floppies -"disquetes blandos"- de verdad), y tenían esos ordenadores extraños sin disqueteras (máquinas DEC VAX y IBM PC/RT), y estaba yo completamente perdido.

Lo que enseguida aprendí es que el software que emplea la gran mayoría de los usuarios de todo el mundo no es todo el software que hay. De hecho, en muchos aspectos, no es el mejor que hay. Y lo que aprendí mucho después es que casi todo se creaba por medio del trabajo colaborativo entre personas que mayoritariamente sólo querían ver lo que podían hacer con el software. Supongo que no era el Open Source en el sentido moderno de la frase, pero era bastante parecido, y las raices de lo que hoy en día es el Open Source vienen de aquellos proyectos.

También me encontré un par de veces (él no se acordará) con RMS (Richard Stallman) y a mucha gente que contribuía de manera habitual al proyecto GNU, que nació en MIT, así que desde entonces he tenido mucho respeto por lo que Richard y el resto de dicha comunidad han hecho para crear un conjunto de software que puede compartirse y en el cual la gente puede collaborar sin las restricciones impuestas en la comunidad Unix, donde tus amigos y tú teníais que pagar mucho dinero para poder participar.

Me gustaba mucho la idea de poder contribuir a toda esta actividad, pero dado que no programaba mucho, más que nada usaba el software y pensaba que era lo que más se llevaba. Tardé mucho en encontrar algo que podría hacer de manera útil. De hecho, no tuve ocasión de contribuir al Open Source de manera significativa hasta que llegué a Apple en 1997.

Cuando empecé en Apple, la gente de NeXT acababan de llegar al campus Apple, y estábamos trabajando sobre la versión Rhapsody Developer original. Lo primero que ví era que teníamos un verdadero cargamento de software en el sistema que me resultaba familiar, pero gran parte de todo aquello era anticuado o incompleto.

Había utilizado el NeXTStep en el Media Lab de MIT y otra vez en el Disney Online, y molaba mucho el hecho de que tenía el entorno Unix debajo, pero cada vez que querías hacer una cosa estándar de Unix, tenías que ajustarlo un poco. Así que veías excepciones de casos especiales en los scripts de autoconf para NeXTStep, donde es casi lo mismo que cualquier otro (4.3) sistema BSD, pero lo hacía un poquito diferente, o algo faltaba. Y después de cierto tiempo, estos ajustes empiezan a sumar. Habíamos heredado el software en Apple, y pensaba que podía ayudar limpiándolo algo. Así que buscaba un tar GNU más nuevo, o añadía un tcsh, porque todo buen Unix debe tener el tcsh... y después el BASH... y entonces el Perl... y no podía faltar el Apache, y seguía y seguía. Y hablé con unos amigos del MIT quienes me engancharon al NetBSD y asumí el objetivo de intentar sincronizar con la comunidad de usuarios de BSD.

Lo que me parecía obvio en ese momento era que necesitabamos mantener una relación continuada con los proveedores avanzados del software, para que pudíesemos abogar por nuestros cambios y coordinar las versiones nuevas y evitar el problema con el cual el NeXT chocó frontalmente, debido básicamente a código divergente, que hace que sea muy complicado mantenerte al día con lo que está pasando en otros sitios. Escribí un paper sobre este tema, empleando el Rhapsody como caso de estudio y lo presenté en FREENIX durante el USENIX 1999. Como resultado del trabajo que estaba haciendo, me involucré en muchos de los proyectos que aportaban el código que utilizaba. Y así es cómo me involucré con el Open Source. Tardé gran parte de los años 90 en conseguirlo.

Tu involucración te ha dado una perspectiva extraordinaria sobre el movimiento, sus jugadores principales, y la gente que de verdad lo hacen funcionar: los desarrolladores: ¿Cómo caracterizas los cambios (si ha habido) que han sucedido entre y para los desarrolladores desde tu inicio?

Pues, creo que mientras todavía estaba aprendiendo, había gente que trabajaba en lo que esencialmente era software propietario (aunque todavía abierto de manera significativa), software como el Unix BSD en Cal (la Universidad de California, Berkeley); y había gente que querían hacer que el software no sólo estuviera abierto, también libremente compartido con todos sin preocuparse de un grupo centralizado que se les podría quitarlo, como el proyecto GNU. El proyecto GNU era un esfuerzo realmente importante, porque el software libre no era la norma, y estaban trabajando muchísimo para asegurarse que habría código libre suficiente disponible para que la gente pudiera aprovecharlo en hacer trabajos de verdad y resolver problemas reales, y emplearon una licencia especial para garantizar la libertad del código. Ese software sigue siendo importante hoy en día, por supuesto, particularmente en el caso de Linux.

Pero creo que sabemos algo hoy que no necesariamente sabíamos entonces: el componente crítico del Open Source no es el código. La verdadera mágia está en la comunidad que emplea y desarrolla el software. Si coges una buena idea, y creas una buena comunidad alrededor de ella, puedes terminar teniendo un software excelente, y por lo que he podido ver, no hay persona ni empresa que sea capaz de quitártelo. La tésis del paper que escribí para FREENIX era fundamentalmente que si existe un buen proyecto Open Source, cualquier empresa que coge el código del proyecto, que lo trabaja, y que elige no formar parte de la comunidad, se quedará con un producto menos atractivo que el que la comunidad conseguirá, porque el Internet facilita comunidades muy grandes y diversas que de manera inevitable pueden trabajar más rápido que una empresa individual, por lo menos en los espacios de trabajo [problem spaces] que han sido configurados como propios por los proyectos Open Source.

La otra cara de la moneda es que los proyectos Open Source pueden beneficiarse enormemente cuando consiguen que empresas apliquen sus energias al software abierto en lugar de inventar algo en paralelo; estas empresas tienen muchos recursos que pueden dedicar a problemas de importancia. El Apache Software Foundation es un maravilloso ejemplo de esto; hemos visto esfuerzos verdaderamente magníficos por parte de empresas como IBM, Sun y Covalent que han ampliado los espacios de trabajo en los cuales nuestra comunidad se esmera y han aumentado la calidad y la utilidad del código de manera importantísima. No sólo han contribuido el software, también aportan el personal a jornada completa para nuestros proyectos, y mientras es indudable que ha habido roces por el camino, estoy convencido que todas las partes que han participado -incluyendo por supuesto todos los usuarios- están mucho mejor situados como consecuencia de esta colaboración.

Por otro lado, creo que algunos de los mejores activos del espacio Open Source -los temas GNU- todavía está con la idea de que es la licencia que protege el software. Esto no está mal en sí, pero la licencia GNU tiene en mi opinion problemas legítimos para personas o empresas que no pueden, por cualquier razón, aceptar los términos para el software que no sea aquello del código GNU original, y no creo que excluir a esas empresas sea lo mejor para una comunidad abierta. Es decir, en este contexto, la GPL (en su forma actual) llega a inhibir que se comparte el código, en lugar de facilitarlo.

De hecho, es más complicado que eso: el proyecto GNU propone sus ideas particulares de libertad en el software, y su objetivo no es exactamente garantizar que el mejor software del mundo se haga de esta manera colaborativa, que es lo que entiendo yo como el verdadero Open Source. Así que no es una casualidad que las cosas salgan de este modo; sólo que creo que es desafortunado, porque mi interés está en compartir el código y crear comunidades. También creo que muchos autores GPL no han pensado el tema hasta el final. Lo que creo percibir es una especie de "mayoría de edad", tanto para el modelo de desarrollo Open Source como -y esto es fascinante- para la industria del software y cómo puede encajarse en todo esto. Es un momento apasionante para ser un desarrollador de software.

El Open Source depende, de manera notoria, de la "comunidad." Pero no está claro quiénes son la comunidad, quiénes la componen, y cómo se constituye. ¿Puedes dar alguna pista sobre las comunidades Open Source? Es decir, ¿cómo se forma una comunidad de desarrolladores, cuáles son sus elementos clave, y cómo funciona el todo?

Como te dije antes, creo que la comunidad es un componente fundamental de un proyecto Open Source, así que esta pregunta es muy buena, aunque no muy facil de contestar. Como yo lo veo, una comunidad es un grupo de personas con algún interés en un espacio de trabajo dado y una visión para poder con él y saber qué hacer con el resultado. Suelen agruparse alrededor de un código, porque el código define unos bonitos límites a la extensión del espacio, pero puede que el código se deseche y se reescriba o se modifique de otra manera y se extienda para reflejar la visión del grupo, que evolucione en la medida que los miembros descubran nuevas ideas, o los componentes cambien.

Las comunidades con más éxito que yo conozco tienden a tener unas características comunes: tienden a tener un grupo "corazón", compuesto de los desarrolladores más activos y también de otras personas que se les conoce como entendidos del espacio de trabajo. El grupo "corazón" y el código son lo que aportan la continuidad y la dirección, y más o menos representan la visión de todo el grupo.

Hay muchos modelos organizativos diferentes de various proyectos Open Source, y realmente no soy experto en el que mejor funciona, dado que sólo he ayudado a crear uno. Para Darwin, tuvimos un grupo "corazón" bastante evidente, siendo las personas tech del equipo Core OS en Apple, ya con responsabilidad para el código; y la visión inicial se ha definido de manera contundente por el producto Mac OS: el papel primario de Darwin es apoyar el avance de Mac OS. Puede que esto parezca demasiado estrecha, pero creo que la visión es correcta; más de 100.000 personas compraron el Mac OS X Public Beta, y me imagino que la versión definitiva a punto de lanzarse tendrá una base de instalaciones importante para finales de año. Esto significa que habrá mucha gente con algún interés en ver que el sistema mejore, y no está nada mal que la gente vaya picando así.

Lo más interesante es ver si el grupo "corazón" de Darwin crecerá para incluir a gente fuera de Apple, y de esta manera permitir que la visión se extienda más allá de los límites de lo que está haciendo Apple con Mac OS. No digo los que trabajan en el código [los committers], que ya están, sino más bien si Apple será capaz de permitir que otros miembros de la comunidad fuera de la empresa tomen la iniciativa.

El mejor ejemplo de una nueva comunidad formándose que he visto es el proyecto Subversion en CollabNet. Karl Fogel y algunos gurus más del área de control de código fuente se juntaron y empezaron a diseñar algo fundamentalmente mejor que el estándar actual, el CVS (Concurrent Versions System). Y han hecho un gran trabajo. Inicialmente se mantuvo, de manera intencionada, un grupo pequeño, por medio de no hacer mucha publicidad, no con la idea de esconderse, simplemente con el objetivo de poder definir bien la visión antes de que entraran más cocineros en la cocina. Desde entonces he visto todo tipo de progresos, algunas ideas realmente maravillosas, y sinceramente creo que cuando hayan acabado, cambiaré a Subversion, y jamás volveré a CVS en la vida.

Hay un elemento de polvos mágicos en cómo se gestionó todo aquello, algo que no entiendo del todo, así que no sé si sería capaz de reproducirlo, pero era increíble verlo, y estoy a la caza de otros ejemplos para que pueda aprender de ellos.

Existe otro problema que tiene un proyecto Open Source y que es eso de conseguir nuevos miembros. ¿Cómo has podido conseguirlo? ¿Qué estrategias has empleado?

Esto nos devuelve a la economía del Open Source, y los desarrolladores son un recurso finito. Las comunidades se alimentan por necesidad. Si no puedes conseguir miembros, quizás es porque no existe una demanda. Y no creo que el crecimiento sea un requísito. No sé cuántas personas tiene el fetchmail hoy para mantenerlo, pero no creo que necesiten otros 20 desarrolladores.

Puede ser duro para nuevos proyectos, porque hay un problema de arranque: necesitas el código para que haya usuarios que dependan de él. Esto alimenta al conjunto de los desarrolladores, que escriben el código. Así que tiene que haber alguien que sea el primer desarrollador para escribir código suficiente y ayudar a que otras personas se lancen a ello. Una vez conseguido ésto último, un buen proyecto se autoalimenta.

Hay personas que creen que Open Source significa que haces un tarball y una licencia decente, lo colocas en un servidor ftp y ya lo tienes. Quizás para estar a la última moda es suficiente, pero es radicalmente falso si crees que lo importante es la comunidad. Debes limpiar el código (para lecturabilidad, documentación, el lenguaje de mal gusto inevitable, las complicaciones legales, los nombres internos de código, etc.). Debes darte a conocer. Debes fácilitar el proceso para la gente que se interesan lo suficiente para querer contribuir mejoras, para que no se te escapen.

Así que necesitas cosas como listas de correo, servidores CVS y más, pero lo que es mucho más importante, implica un compromiso continuo con la comunidad que creas para que puedas ayudarles a la gente que quiera ayudarte a ti a hacer el código mejor, y todo esto incluye el convencer a tus desarrolladores internos que deban dedicar algo de su tiempo en ayudar de vez en cuando a gente que no conocen. Puedes conseguir una infraestructura excelente en SourceForge, pero no se crea una comunidad sólo con la infraestructura.

Y ésa es la clave. No es una operación de poca monta convertir un proyecto en Open Source. Implica un trabajo real y gente real de manera continuada. La gente se pregunta por qué una empresa no se convierte un código caducado en Open Source, y aquí tenemos el porqué. Si no tienes los recursos para invertir, no siempre se puede justificar la iniciativa. De verdad, no es fácil hacerlo; he hablado con gente en otras empresas también para confirmarlo.

NOTA: Condiciones para la publicación y difusión posterior del artículo:

Desde el subproyecto native-lang/es de OpenOffice.org, agradecemos la colaboración y la generosidad del propietario del copyright.

arriba