Desarrollo distribuido de acuerdo al software libre, con Karl Fogel

Introducción

Karl Fogel es uno de los desarrolladores fundadores del proyecto Subversion, que está patrocinado por CollabNet. Karl describe su trabajo con la empresa como relación entre CollabNet y los desarrolladores. En la entrevista siguiente, Karl habla de la creación del proyecto de software libre Subversion, de lo que ha necesitado para crear su comunidad y de lo que ha aprendido para mantenerla con éxito. Karl tiene una ventaja interesante, no sólo desde el punto de vista de la administración de dicha comunidad, sino porque el proyecto Subversion es una de las tecnologías de software necesarias para el desarrollo de software libre.

Subversion es un tipo de herramienta de gestión de la configuración de software (SCM) que se conoce como sistema de control de las versiones. Estos tipos de herramientas son importantes, ya que permiten que los desarrolladores colaboren en los proyectos de software. Subversion es parte del enfoque que tiene la comunidad tigris.org en crear herramientas de desarrollo de software en colaboración. CollabNet da a las empresas soluciones de desarrollo de software distribuido. Estas soluciones se utilizan en empresas como Sun Microsystems, HP y Barclays Global Investors para ayudar a coordinar a los equipos de desarrollo que se encuentran en distintas partes del mundo.

Tercera parte de la serie Únase a la interrupción concertada.

Empezamos Subversion hace como cinco años, y creo que es diferente a otros proyectos de software libre, porque iniciamos con el objetivo de reemplazar cierto software libre. Estábamos tratando de reemplazar CVS.

Tenían un buen punto de referencia.

Teníamos un punto de referencia maravilloso, y eso nos ahorró muchas discusiones sobre lo que debía o no contener nuestra primera versión. Podríamos decir que algo contenido en CVS tenía que estar en nuestra versión 1.0, y no incluiríamos algo que no venía con CVS. Nuestros proyectos tenían una sustancia inherente que reducía las controversias –al menos antes de 1.0. Hasta ahora estamos discutiendo sobre todo eso que dejamos de lado en un principio. Pero ya tenemos una base/relación construida con todas esas personas, y eso facilita las discusiones porque todas ellas trabajaron juntas para obtener la versión 1.0.

Acerca de cómo obtuvimos todos esos desarrolladores. Las cifras que tenemos actualmente son cerca de treinta personas comprometidas de tiempo completo –gente que se puede comprometer con cualquier parte del código fuente, personas externas-, gente que sólo hace cambios a la documentación, que repara los scripts de soporte o algo así, pero que no se compromete con el código. De esas treinta personas, diría que cerca de quince son activas diariamente. Hay otras que llegan de vez en cuando, como Han Solo, reparan un error y vuelven a desaparecer durante meses.

Realmente lo fundamos pasando la información de una persona a otra. Conocíamos bastante bien el área de CVS, empezamos a ponernos en contacto con esas personas, ellas a su vez hablaron con sus amigos y, en poco tiempo, la gente empezó a aparecer. De hecho, tuvimos reuniones de diseño abiertas al público cuando iniciamos el proyecto en San Francisco. El día de hoy, algunas de esas personas siguen trabajando en el proyecto. Pero uno de nuestros mejores recursos está en Eslovenia y no asistió a esas reuniones de diseño. De cualquier forma, no estaríamos donde estamos si no hubiera sido por su colaboración.

¿Podría aclararnos cuál es su papel en el proyecto?

Podríamos llamarlo desarrollador fundador. CollabNet sólo emplea a tres o cuatro de esas personas comprometidas. No todos trabajamos en Subversion todo el tiempo. Yo creo que son sólo tres o cuatro. Mi papel era, fundamentalmente, -tenía mucha experiencia trabajando con proyectos de software libre, y sobre todo con CVS, lo que me ayudó a involucrarme con control de versiones- algo así como definir el tono al inicio del proyecto –una relación entre CollabNet y los desarrolladores cuando fuera necesario, aunque no han habido tantos conflictos, no hemos necesitado un mediador. Mi papel también es escribir código.

Es difícil decir exactamente cuál es mi papel, pero con la cantidad de voluntarios que tenemos, el tema central es la atención. Si alguno de ellos hace algo, ¿alguien se da cuenta? Van a hacer más cosas cuando alguien esté poniendo atención. La parte principal de mi trabajo no es el código, es darme cuenta de las cosas. Cuando alguien hace un cambio, yo tengo que revisarlo, aunque no tenga nada y no tenga que hacer comentarios negativos al respecto. Estoy hablando de los mensajes de correo electrónico sobre compromisos, es decir, cuando alguien efectúa un cambio, se envía un mensaje a todos los desarrolladores para mostrarles dicho cambio. Así que normalmente, para revisarlo, respondes a ese mensaje citando las cosas positivas, diciendo por qué usaste tal código, etc., y el verdadero objetivo de esa revisión es, en parte, la calidad del código, pero también se trata un poco de dejar que la gente sepa que se está poniendo atención a lo que hacen. Estoy seguro de que si no lo hiciéramos constantemente, tendríamos menos desarrolladores y no serían tan activos.

¿Cree que eso es crítico? Otras personas han dicho que poner atención a las contribuciones que hacen los desarrolladores es, al menos, la medida principal para mantener su interés. ¿Está de acuerdo?

Completamente. Si hablas con algún desarrollador de software libre que te dice que lo único que quiere es crear un software que funcione, no le creas. La naturaleza humana es distinta. La gente que trabaja en equipos quiere contar con el reconocimiento del equipo y sobre todo, de ciertos integrantes del mismo.

¿Cuáles son algunas otras funciones como esa, que usted considere de importancia para mantener el interés de los desarrolladores?

Además del hecho de recibir atención de otras personas, y de responder, como aceptar buenas sugerencias y código y cosas así, creo que la infraestructura tiene ciertos principios. Uno de ellos es que las personas pueden tratar con una cantidad constante de molestias ligeras y de gastos generales administrativos, pero si tiene altas y bajas cuando se presentan obstáculos que deben superar, no lo hacen.

OpenOffice.org es un buen ejemplo. Quiero decir que OpenOffice.org es un software extraordinario, pero puede ser un proyecto de software libre atípico. Si Sun no le estuviera pagando a muchos de los desarrolladores, no creo que estarían logrando algo. No porque sea mal código, sino porque se necesita un doctorado en creación de software sólo para compilarlo. Un ser humano cualquiera no puede descargar OpenOffice.org y construirlo. Tienen algo así como un obstáculo enorme que siempre impedirá que la gente se conecte y corrija errores... Si quieres que la gente se una de forma comprometida, tienes que facilitarles las cosas, es decir, alguien más tiene que esforzarse para estructurar las cosas de forma que sean fáciles. Si alguien no se encarga de hacerlo fácil, no será fácil construir software desde que se compra.

Eso se aplica también a otros tipos de infraestructura, como el rastreador de errores, la lista de envío, el sitio web en general, el sistema de control de versiones. Cuanto más conocimiento de especialista tienes para usar las cosas, menor es la cantidad de desarrolladores que tienes. Esto es porque la gente encuentra un error en tu código y quieren repararlo, pero si se tardan cinco minutos en ese proceso debido a algo que parece que va a requerir una gran inversión, se dan por vencidos y pasan a otra cosa. Es más fácil vivir con el error.

¿Diría que es uno de los objetivos de desarrollo? Es decir, lo que veo en tigris.org es el énfasis en esa facilidad.

Sí, obviamente la infraestructura del proyecto no puede resolver todos los problemas. Por ejemplo, puedes operar tu proyecto en ambiente CollabNet o en ambiente tigris, pero eso no hace que sea fácil construir tu software, eso sólo tiene que ver con la forma en que estructuras el código. Se trata de cosas como el rastreador de errores y los enlaces con las mismas cuentas de usuarios que se encuentran en el sistema de control de versiones, de facilitarle a la gente esas cosas. Tienes una clave de acceso que usas en todas partes, pero si mandas un mensaje de correo electrónico puedes estar seguro de que habrá un enlace en el archivo a ese mensaje, que después podrás pegar en el rastreador de errores para que alguien pueda seguir esa conversación, etc.

Cuando habla de facilitar que alguien siga la conversación, es un ejemplo, pensaría, de cómo facilita el aspecto social de la comunidad de desarrollo. ¿En qué otras áreas cree usted que el software tiene un papel social?

Cuando habla de facilitar que alguien siga la conversación, es un ejemplo, pensaría, de cómo facilita el aspecto social de la comunidad de desarrollo. ¿En qué otras áreas cree usted que el software tiene un papel social?

No podría establecer una diferencia específica entre lo social y lo técnico. Definitivamente, algunas cosas son sociales, es decir, si dices algo en IRC y alguien se siente ofendido, es claro que no se trata de un problema técnico sino de diplomacia. Pero cosas como permitir que cada pedazo de información del proyecto tenga una referencia canónica, por ejemplo, un URL o un número de mensaje de lista de envío, o un número de problema, algo así, son en parte sociales. Quiero decir que cuando hablas, necesitas tener esas herramientas, quieres poder mencionar el problema 908 y que la gente sepa de qué estás hablando. Pero también es una cuestión técnica, ya que nadie puede tener una conversación si no tienen esas herramientas abreviadas para trabajar constantemente –son los límites del cerebro humano.

Usted habló de que, por ejemplo, una de las cosas que Subversion tenía a su favor, era que había tenido este punto de referencia a CVS. En general ¿cree que es mejor iniciar una comunidad de desarrolladores alrededor de un proyecto que tiene una referencia como esa? ¿O cree que es más fácil construir dicha comunidad con algo completamente nuevo, una idea diferente?

No lo sé. Puede ser que no sé o puede ser que sea demasiado pronto en general para que sepamos la respuesta a esa pregunta. Si me vuelves a preguntar en diez años, es posible que ya tenga una idea.

¿Demasiado pronto en el sentido de desarrollo de software libre o en general? ¿O sólo de su experiencia en este proyecto en particular?

Quise decir demasiado pronto con el software libre en general, pero si lo analizas, podría ser que la gente que ha observado tendencias más amplias puede tener una respuesta para ello. Yo creo que no es que obtengas menos o más desarrolladores para algo completamente nuevo, sino que obtienes desarrolladores de otro tipo. Nosotros obteníamos gente que conocía CVS, lo odiaba y quería resolver sus problemas. Era algo muy específico y aún ahora existe cierto conservadurismo en la lista de desarrollo de Subversion, donde, por ejemplo, propones alguna función realmente descabellada que salvaría el mundo y la gente responde “pero hemos vivido tanto tiempo sin eso, ¿realmente es parte de nuestra función principal? ¿Vale la pena? ¿Qué más se verá afectado si lo hacemos?” Mientras que si Subversion fuera realmente un diseño radical o si fuéramos un proyecto completamente distinto y nuevo, probablemente tendríamos otro tipo de desarrollador y gente que se resistiera menos a las ideas nuevas. Pero por otro lado, tomaría más tiempo hacer las cosas y dejarlas listas. No digo que los proyectos verdaderos no tengan éxito, pero para ellos, las rutas al fracaso son distintas a las nuestras.

¿Siguen teniendo reuniones físicas de desarrollo?

No, porque ahora [los desarrolladores] están dispersados por todo el mundo y las reuniones podrían hacer que alguno se sintiera relegado. Eventualmente es posible que tengamos una conferencia, pero tendríamos que alternar entre Europa y América. No podríamos tenerla en Silicon Valley cada año, porque muchos de nuestros desarrolladores se encuentran en el Reino Unido y Europa. Hasta es posible que tengamos algún desarrollador en una cabaña en una montaña en Taiwán.

¿Qué hace para que la gente mantenga su interés en lo que están haciendo para el proyecto y ya está bien establecido? ¿Cómo evita que la gente se aburra?

Parte de lo que hago es tratar de provocar a cada desarrollador. Existen personas que se enfocan en el mantenimiento y en reparar errores, y que no se interesan en desarrollar funciones nuevas. Otras personas se interesan en cualquier cosa siempre y cuando puedan ser líderes de ese esfuerzo, y no quieren involucrarse en cosas que dependen de otra persona. Hay que poner atención a los mensajes de correo electrónico de cada persona y a los tipos de cambios que realizan en el software y al tipo de iniciativas en que se involucran. Es decir, primero hay que preguntarse “¿quiero, queremos que esta persona se quede? Y de ser así, ¿qué medidas hay que tomar para evitar que se aburra o se desencante?”

Puede ser como cuando te enfrentas con un problema específico y recurres específicamente a esa persona –puedes enviar un mensaje a una lista pública, pero dirigiendo el tema de tu mensaje específicamente a esa persona, diciendo “Carlos, tengo problemas tratando de entender esto, ¿podrías decirme qué opinas al respecto?” y después haces algunas preguntas técnicas. Lo que realmente sucede es que estás pidiendo ayuda que será útil, pero estás reafirmando la idea que tiene Carlos con respecto a su papel en el proyecto como recurso para esa área. Cuando tratas a alguien así, no querrá irse a menos que realmente tenga algo mejor que hacer o una razón específica por la que está desilusionado.

Cada comunicación implica dos o tres cosas. Puede tratarse de una solicitud técnica de información, pero también es una confirmación del rol de alguien –tiene efectos sicológicos, y a veces esos son realmente el objetivo que controla la comunicación. ¿He sido demasiado maquiavélico?

¿Puede hablar más de Subversion, tigris.org y CollabNet?

Tigris es una comunidad de proyectos que, básicamente, se centra en la idea de operar proyectos o hacer que los proyectos de software funcionen mejor. Pretende ser un poco como SourceForge, pero sin los 80,000 proyectos fracasados.

Como ha tenido más experiencia con Subversion y CollabNet, ¿podría hablar más acerca de esas relaciones?

Es una situación chistosa. Quiero decir que CollabNet definitivamente inició el proyecto, y todos los desarrolladores están conscientes de ello. Si le preguntas a cualquiera de ellos quién fundó Subversion, dirán que CollabNet. Al mismo tiempo, CollabNet nunca ejerce su posesión sobre el proyecto, y no podemos decirle al grupo de desarrolladores, “está bien, vamos a lanzar la versión 1.4 el viernes 23 de septiembre de 2005, así que manos a la obra”.

CollabNet tiene un poco más de influencia que el número de desarrolladores que emplea, ya que proporciona una infraestructura de alojamiento y tiene una buena historia. Es el tipo de capital moral que se puede acabar... Los demás desarrolladores están conscientes de que CollabNet usa Subversion como parte de su propio producto y, aunque no tolerarían que hiciéramos cambios a la versión simplemente para dar soporte a ese producto (que no es software libre, así que los desarrolladores no lo pueden aprovechar), sí ven el uso que hacemos de Subversion como fuente de información sobre la forma en que la gente usa Subversion. Tenemos clientes que tienen proyectos más grandes con más usuarios, más archivos, archivos más grandes y estructuras de directorios más profundas que el usuario típico de Subversion. Con frecuencia, cuando surge un problema de capacidad de graduación, se dan cuenta primero las personas de relaciones con los clientes del propio CollabNet, después pasa a nuestra persona de compromisos y sigue por el proceso de problemas hasta nosotros. Lo llevamos a la comunidad pública para que conozcan este error que, de otro modo, no habrían conocido. Ven el valor de que CollabNet use Subversion de forma corporativa, y ahora CollabNet no es la única entidad que lo hace, aunque por mucho tiempo fuimos y creo que seguimos siendo los únicos que realmente han hecho pruebas de desempeño y capacidad de graduación. Además, hemos publicado los resultados, proporcionando buenos datos para usar en la vida real, y eso es un punto a favor de CollabNet.

La mejor fuente de pruebas es la comunidad de usuarios, ya que encuentran errores, pero en cuanto a los problemas de graduación, son los clientes de CollabNet quienes contribuyen más. Existen otras instalaciones de Subversion allá afuera, y también recibimos errores de ellas, así que ya no somos sólo nosotros. Pero la comunidad de desarrollo sabe que existe este canal de información que viene de nuestros clientes mediante el rastreador público de problemas. No mostramos el reporte de errores, que emite el cliente de forma interna, porque son datos privados, pero tomamos las partes importantes de él y lo copiamos en un documento público. Entonces, ese documento interno se refiere al público y da seguimiento al progreso de los problemas públicos.

CollabNet no tiene una práctica para sus propios clientes. ¿Cómo pueden aprovechar CollabNet, cómo les ayuda a facilitar el desarrollo en lugar de instalar Subversion ellos mismos?

Subversion por sí mismo no tiene un rastreador de problemas, ni una lista de envío, ni un sistema integrado de gestión de las cuentas de usuarios; es sólo un sistema de control de versiones. Así que lo que la gente obtiene de la serie de productos de CollabNet, ahora conocida como CollabNet Enterprise Edition, es un sistema unificado de gestión de las cuentas de usuarios y varias otras formas de integración entre el control de versiones, el rastreo de errores, la lista de envío, el área donde comparten sus documentos, etc. Y no tiene que administrarla. Pueden, por ejemplo, presionar un botón para iniciar el proyecto y llenar los campos, y queda todo preparado y CollabNet se encarga de administrarlo. De cualquier forma, existen varias situaciones en las que ellos podrían administrarlo también.

Supongamos que está iniciando una nueva empresa y quiere crear una aplicación empresarial. ¿Qué recomienda para arrancar el proyecto en cuanto a atraer esa comunidad de desarrolladores y facilitar su colaboración en el proyecto?

Creo que lo más importante es la facilidad de entrada y la apariencia de credibilidad. Es decir, la credibilidad siempre es este tipo de ciclo de retroalimentación positiva en la que sabes que tienes que parecer alguien que los demás toman en serio para que realmente te tomen en serio. Así que es importante hacer que el sitio web parezca bien organizado y profesional, tener toda la información que los desarrolladores quieren y tenerla organizada de forma que se oriente a ellos. Hay que tener los documentos de especificaciones, los requisitos y todo eso, en línea y en formatos que prefieran los desarrolladores de software libre, como texto u OpenOffice.org.

Y haz que la licencia sea clara. Comprométete a hacer que el software libre sea claro desde el principio. Si la gente percibe que la empresa titubea sobre si realmente quiere hacerlo software libre, o si la licencia permite que la empresa haga el desarrollo de forma interna después de obtener la contribución de muchas personas, entonces la gente no querrá participar. Pero si aclaras que el desarrollo se hará públicamente, la gente se siente más tranquila.

Yo diría que hay que evitar tener un obstáculo en el principio, ya sea crear la versión inicial del software o quebrarse la cabeza con los requisitos o lo que sea. Estoy tratando de acuñar una frase memorable para este principio, pero no he encontrado una. Probablemente tú puedas ayudarme. La idea es que la cantidad de información que la gente obtiene del proyecto debe ser directamente proporcional al esfuerzo que invierten en él. Así que, si pasas cinco minutos navegando por una página web, deberías obtener información equivalente a cinco minutos y debería tratarse de las diez cosas más importantes de ese proyecto. Si te gusta lo que ves y decides invertir otra media hora, entonces debes recibir una recompensa similar a cambio. No puede ser que parezca interesante durante los primeros cinco minutos y después tengas que dedicar media hora para darte cuenta de que no es fácil encontrar la información. Hay que recompensar todos los esfuerzos para hacer que la gente se quede y se involucre.

Estoy seguro de que yo no descubrí esto. Y solía pensar que era esencial que hubiera un código funcionando al inicio del proyecto para que la gente pudiera descargarlo y jugar con él, pero Subversion no empezó así y aún así obtuvimos desarrolladores inmediatamente, así que no sé, probablemente no tiene importancia. Es decir, yo creo que ayuda.

¿Cree que lo que permitió que no tuviera código funcionando desde el principio fue el hecho de que el concepto que tenía era tentador para la gente?

Sí, creo que el hecho de tenerlo tan cerca y poderlo saborear y saber exactamente qué íbamos a hacer hizo que tener el código en funcionamiento fuera menos importante. Pero si estás haciendo algo nuevo o algo que será largo y complejo y no siempre puedes estar seguro de que el lector va a conocer el alcance, entonces probablemente quieras tener algo que ellos puedan descargar y empezar a manipular inmediatamente. Yo creo que cuando alguien llega a la descarga, ya ha recorrido la mitad del camino a la contribución, y si llega a reparar un error, enviar una solución, entonces ya lograste captar su interés. Es muy probable que vuelvan a hacer otra contribución si tú aceptas la solución y mantienes tu compromiso.

Al principio habló de algunas cifras; dijo que había cerca de treinta personas comprometidas de tiempo completo y unas quince comprometidas de forma diaria, y después mencionó tres o cuatro que son empleados de CollabNet. ¿Sabe si muchos de los que no son empleados de CollabNet están contribuyendo con su tiempo y son empleados de otra empresa que esté obteniendo alguna ventaja del proyecto? ¿Es por eso que están involucrados?

La mayoría no lo están haciendo así, sino que simplemente contribuyen de forma gratuita. Recientemente, algunos de ellos han empezado a obtener trabajos por contrato, pero la mayoría de esos contratos son para instalaciones y consultoría. En algunos casos, otras empresas le han pagado a alguno de esos desarrolladores para que repare un error que estaba en nuestro rastreador de problemas. Creo que eso se está volviendo más común. La tasa de incidencia está creciendo lentamente, pero no es el suceso más importante. En la mayoría de los casos, sólo están contribuyendo con su tiempo.

¿Diría que quienes han encontrado buenos contratos de consultoría es porque tenían ese objetivo o es simplemente algo que sucedió?

Es algo que sucedió. No creo que hayan empezado esperando obtenerlos. Si fue por eso que se involucraron con Subversion, realmente invirtieron demasiado para obtener muy poco, porque no es algo que represente un sustento de tiempo completo. Podría serlo, si alguien quisiera dedicarse a ello. No creo que alguno de ellos se haya fijado ese objetivo. En sus sitios web de consultoría, incluyen a Subversion como una de sus actividades, pero no es su enfoque. La gente ha dedicado un año o más de trabajo duro a Subverison para obtener la experiencia y la credibilidad necesarias para estar en esa posición. No creo que hayan iniciado tratando de hacer precisamente eso.

Parece que, para muchos de ellos, es sólo amor al arte. En ese caso, si quiere iniciar un proyecto exitoso deberá contar con alguien que le inspire esa pasión a la gente o presentar su proyecto de forma que despierte ese sentimiento.

Yo creo que sí y pienso que quiere decir que hay proyectos cuyo arranque como proyectos de software libre es realmente difícil. Es decir, nunca vas a encontrar a alguien que quiera dedicarse a escribir algo como un servidor de licencias de software libre. Aunque hay un proyecto de esos en SourceForge, pero no creo que por el momento tenga una comunidad de desarrollo muy grande.

¿Hay algo más que quisiera agregar acerca de contar con una comunidad de desarrollo? ¿Algo más que crea que debamos tomar en cuenta y que no hemos mencionado?

Creo que hemos tocado los puntos más importantes. Diría que si estás aconsejando a alguien sobre cómo iniciar un proyecto de software libre, deberías asegurarte de que quien va a controlar ese esfuerzo tiene buen trato con la gente, sobre todo por escrito, ya que el contacto con los desarrolladores no va a ser cara a cara. Hay mucha gente que envía mensajes, sobre todo a una lista de desarrollo de software libre, y parece que están de mal humor y que están regañando a la gente, y expresan sus ideas con dureza. Con frecuencia esas personas son muy buenos programadores, pero no creo que logren reunir grupos de desarrolladores y mantener su lealtad. Son como lobos solitarios, aunque el punto parezca obvio.

Con esto termina la tercera de cuatro partes que conforman esta nota. La primera parte proporcionó los antecedentes de lo que es la comunidad de software libre y la forma para incitar su participación. La segunda parte presentó una entrevista con Jeff Bates de SourceForge.net, Slashdot y el Open Source Technology Group. La cuarta parte es una entrevista con Louis Suárez-Potts, gerente de desarrollo de la comunidad para el proyecto OpenOffice.org, y cubre la arquitectura política y social de las comunidades de software libre, así como las medidas necesarias para supervisar un proyecto de forma satisfactoria.