Aspectos sociales y técnicos de la colaboración, con Louis Suárez-Potts

Introducción

Louis Suárez-Potts es el presidente y secretario del Consejo de la comunidad de OpenOffice.org. Actúa como gerente de la comunidad para el proyecto OpenOffice.org, transmitiendo los asuntos importantes entre Sun MicroSystems, CollabNet y la comunidad de OpenOffice.org. La información que puede aportar sobre cómo mantener la colaboración entre las distintas entidades dentro de un proyecto de software libre a gran escala, va desde la arquitectura política y social hasta la técnica, y va más allá de las complicaciones de la mercadotecnia.

OpenOffice.org es, probablemente, la serie de productividad de oficina de software libre más popular. Funciona en varios sistemas operativos y soporta una gran cantidad de requisitos de traducción a idiomas locales. Contiene las aplicaciones de procesador de texto, hoja de cálculo, presentaciones, [bases de datos,] etc. y es compatible con aplicaciones similares como Microsoft Office Suite. El proyecto recibe patrocinio de Sun Microsystems y está alojado en CollabNet .

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

Me gustaría saber más acerca de lo que usted cree que promueve una comunidad alrededor de una aplicación de software libre. ¿Cuáles son algunas de las medidas que le permiten participar con los demás desarrolladores?

Mi papel en OpenOffice.org ha cambiado mucho desde que me uní al proyecto OpenOffice.org en sus inicios, en octubre de 2000. Empecé como gerente de contenido, y dejé de dedicarme a ello para enfocarme en la gestión, en hacer mucha gestión de proyectos y estrategia y tratar de cambiar la arquitectura del sitio para que pudiera admitir a todos los usuarios nuevos.

Una de las primeras cosas que Sun perdió de vista [aparentemente] al crear OpenOffice.org es que tendría tanto éxito. [Creo que] debió suponer que todas las personas que querían OpenOffice.org recurrirían a StarOffice para comprarlo, enriqueciendo a Sun porque, según ellos, StarOffice era mucho mejor que OpenOffice.org. De hecho, la gente estaba muy contenta con la aplicación gratuita. Es más, OpenOffice.org era mucho más popular fuera de los Estados Unidos. Nos dimos cuenta de esto y buscamos desarrollar ese interés enfocándonos más en los mercados fuera de los Estados Unidos y promoviendo el desarrollo de proyectos para usuarios que no hablaran inglés- Guy Capra, de Francia, nos ayudó a iniciar la categoría, y después yo trabajé con él para desarrollarla -enfocándonos en otros idiomas o en aquéllos que ya estaban localizados y que podíamos soportar. Ahora tenemos cerca de 45 que son realmente populares, de hecho, la mayoría de nuestros usuarios nuevos y colaboradores los buscan.

Parece que, como gerente de la comunidad, tiene muchísimos roles.

Así es, es decir, no tengo un solo rol. Una forma de verlo es que necesitas a alguien que pueda tomar decisiones desagradables, y generalmente yo soy esa persona. Puede tratarse de una decisión como decir que no a un proyecto porque ya tenemos a alguien que esté trabajando en ello. O, de la misma forma, debe haber alguien que represente los intereses de la comunidad ante la empresa patrocinadora, y viceversa. O, de forma general, para coordinar todos los intereses que conforman la comunidad general. Pero este rol no es el de un "dictador benévolo", como sucede con Linus [Torvalds] u otros. No decido nada más sobre asuntos técnicos. Me enfoco en la comunidad como una entidad y en la totalidad del proyecto. Y es un enfoque interesante, porque OpenOffice.org ha cambiado la forma en que se desarrolla el software libre, y CollabNet está siendo el líder en ese cambio.

El cambio puede ser temporal, una etapa o permanente. Pero también tiene que ver con que OpenOffice.org está patrocinado por una empresa y trabaja en el código que dicha empresa usa para efectos comerciales. Para darte los antecedentes: el primer software libre se desarrolló internamente gracias a empresas como Perl, donde había varias personas que se reunían y decían "esto parece interesante, trabajemos en ello y formemos un proyecto a su alrededor". Una comunidad constaba de los desarrolladores más involucrados y era o sigue siendo contemporánea al código mismo. Sin embargo, con OpenOffice.org y otras colaboraciones entre Sun y CollabNet, tenemos una nueva comunidad de software libre, en donde la empresa patrocinadora forma la comunidad participante después del hecho. Desde luego que en el caso de OpenOffice.org, todavía participan muchos ingenieros de Star Division, y forman parte de la comunidad de OpenOffice.org [Sun compró Star Division, que creó Star Office en 1999 -Ed.]. Pero la comunidad que no pertenece a Sun empezó a formarse después de que se creó el proyecto OpenOffice.org y empezó a funcionar después de que se lanzó el código, en octubre de 2000. Aquí surge la pregunta: ¿Cómo se forma una comunidad así? ¿Cómo asegurarse de que realmente funciona? ¿De que las cosas se harán? ¿De que no crece de forma caótica? Aquí entro yo y, más generalmente, CollabNet -y porque creo que nosotros, OpenOffice.org y CollabNet, hemos cambiado la lógica del desarrollo de software libre, de hecho, volviendo profesional el proceso sin sacrificar la energía productiva de los proyectos de software libre orgánicos, yo creo.

Antes de empezar la entrevista, estábamos hablando de la idea de que el software libre realmente tiene antecedentes históricos, filosóficos y sociales. Esta evolución hace que la historia del software libre sea un poco más interesante, porque no existe un antecedente claro en donde las empresas hayan dicho "pongamos esto al alcance del público" y lo hayan hecho funcionar para todos. Así, que la historia se está escribiendo ahora.

¿Usted se encarga de hacérselo saber a las empresas que trabajan con, digamos, CollabNet?

¿Quieres decir esta evolución en el desarrollo de software libre? Te voy a responder con lo que hago con respecto a Sun y la comunidad. Con OpenOffice.org, Sun es el patrocinador, y yo soy la persona responsable, al menos soy el conducto entre la comunidad y Sun, aunque no soy el único. También tenemos un consejo que representa a la comunidad ante sí misma y ante los demás y que articula un conjunto de políticas que pretenden garantizar la satisfacción de las necesidades de la comunidad. En parte, esta estructura es necesaria porque OpenOffice.org incluye a tantas personas que no son desarrolladores -colaboradores, eso sí, pero no necesariamente trabajan con el código; pueden ser gente de soporte, ilustradores o redactores de documentación.

Como mencioné, mi papel aquí es tratar de sintetizar todos los intereses del proyecto y presentarlos a las personas interesadas, tanto Sun como los demás.

Así que actúa también como intermediario; no sólo administra el proyecto para la comunidad, sino que va y viene entre ellos y Sun.

Sí, pero no sólo con Sun; existen otras partes interesadas en la creación de OpenOffice.org. Pero tomemos a Sun como el ejemplo principal. Si Sun quiere un proceso nuevo, digamos un cambio a una licencia o un cambio arquitectural importante o un cambio de relación, puedo tratar de representarlo ante la comunidad, aunque está claro que sólo representaré aquellas cosas con las que esté de acuerdo: no soy ni lacayo ni señuelo de Sun. De la misma forma, si la comunidad ha expresado un fuerte deseo por algo, o está teniendo problemas con un proceso, y el consejo de la comunidad no es el lugar ideal, yo presentaré dichos puntos a Sun, siempre y cuando Sun sea la persona interesada, claro.

¿Podría decirme qué cosas que generan interés por parte de los desarrolladores y los hacen participar en la comunidad?

He pensado mucho en eso, siempre lo hacemos. Si vas a un proyecto de software libre, es lo primero que la gente que hace lo mismo que yo empieza a tratar: cómo traer más desarrolladores. De cualquier forma, estaba tratando de pensar cómo podríamos aclarar el proceso. La representación general del software libre es que tiene cuatro libertades principales, que son verdaderas, pero creo que hay otra que es esencial y que supusieron Raymond y Perens cuando crearon estas definiciones. Es que las decisiones clave deben tomarse de forma pública y transparente para que realmente haya un ambiente eficiente de software libre.

En OpenOffice.org, los lugares que tienen mayor actividad, donde más trabajo hacen las personas que están fuera de la comunidad corporativa, son las áreas que son un tanto marginales, donde los grupos más o menos independientes tienen la mayor influencia en la forma que se dará al producto. Se trata de áreas como localización y puertos. Al mismo tiempo, debo hacer énfasis en que esas son las áreas que los grupos y las personas independientes pueden manejar con mayor facilidad. El hecho de que el código de OpenOffice.org sea difícil de crear y relativamente monolítico es un obstáculo bien conocido que creo que debemos solucionar.

Hay dos puntos, pero voy a tratar el segundo en un momento. El problema con las áreas principales es que la comunidad tiene menos que decir sobre la forma en que resultará el código, sobre todo porque Sun, más o menos por defecto y no por que sea su intención, crea casi todo el código ahí y define de forma implícita la dirección del mismo. Naturalmente, piensa en sus propios intereses; quiere que StarOffice tome una dirección y, como StarOffice tiene base en el código de OpenOffice.org, afecta a este último. Ahora, la comunidad puede participar, y Sun trata de incluirla en esas conversaciones, y al final, la mayoría de las personas están de acuerdo con los planes propuestos. (Ahora, estamos tratando de mejorar el proceso de planificación, para que la comunidad aporte más información). Nuestros demás colaboradores empresariales, como Novell, Red Hat, Debian, generalmente están de acuerdo con este proceso y buscan pulir el derivado que quieren distribuir.

Pero este proceso actual dificulta el que los desarrolladores que no vienen de un ambiente corporativo participen, porque no es simplemente una cuestión de tener un problema que solucionar -soluciones, código, extensiones o lo que sea-, sino de querer ser eficiente y hacer que tu código se acepte. Antes, la situación era peor, y las contribuciones de los desarrolladores a áreas distintas a las que cubría el plan parecían desaparecer en un agujero negro. Y nadie quiere contribuir si no se va a dar importancia a su colaboración, o si no será relevante, o si siente que no tiene acceso real al proceso principal, si ni siquiera saben cómo se toman las decisiones con respecto a su código y al proyecto en general (grande y chico).

Mencionó este problema del "agujero negro" con respecto al trabajo de los desarrolladores. También existe la idea de que cuando no se aprecia la relevancia de la colaboración de los desarrolladores, estos no quieren contribuir más. ¿Qué se puede hacer para evitarlo?

Creo que hay un malentendido. Nosotros apreciamos las contribuciones de los desarrolladores y queremos que sigan colaborando, y también queremos mejorar el proceso para promover esa colaboración. El problema del agujero negro era en realidad algo que afectaba el desarrollo en años anteriores. Ahora hemos mejorado el proceso. De cualquier forma, los problemas básicos estructurales siguen estando -es difícil construir y aprender OpenOffice.org y no es muy modular, además de que las contribuciones, sobre todo las importantes, deben ser examinadas cuidadosamente- nuestros estándares de control de calidad son muy altos. Pero lo más importante es que el plan, los elementos del código que preferimos, siguen estando determinados en gran parte por la empresa patrocinadora y sus propios objetivos, y esto significa que no favorecemos el código que se desvía de ese plan. No es que despreciemos el código "externo", porque puede ser muy bueno y aceptamos gran parte de él, pero queremos enfatizar que la mayoría del desarrollo principal se hace con el fin de satisfacer las necesidades de StarOffice.

Para mejorar esto, hemos buscado -y seguimos haciéndolo- proporcionar más herramientas, información y soporte a los desarrolladores que vienen de fuera del proyecto. Así, cuando los desarrolladores vienen a OpenOffice.org, se les da la bienvenida inmediatamente y se tratan sus contribuciones, se les da reconocimiento; me estoy enfocando exclusivamente en los desarrolladores de código, no en los colaboradores generales de documentación o soporte o algo así, para quienes existe un proceso similar, aunque no completamente igual. Pero lo digo de otra forma, reconocemos todas las contribuciones a OpenOffice.org. Sólo depende de que tengamos personas disponibles para reconocerlas. Además, este reconocimiento no necesariamente quiere decir que aceptaremos el código o la contribución. ¡Ningún proyecto de software libre funciona ni debería funcionar así!

Pero volviendo al problema que describí, cuando tienes una empresa patrocinadora que determina, aunque sea la única que hace la mayoría del trabajo, el plan o la arquitectura y las características del código, entonces se vuelve difícil obtener desarrolladores comprometidos, porque no tienen ninguna opinión sobre la planificación. No es una trampa, porque podemos cambiar el proceso para poder escuchar mejor otras voces, sino que siempre estamos tratando de encontrar un equilibrio para que los desarrolladores puedan opinar, para que se comprometan y el proyecto pueda avanzar de acuerdo a su plan. Desde luego que no todos quedan completamente contentos cuando se logra cualquier compromiso, y esto sólo significa que tenemos que mejorar más las cosas. Pero tu pregunta fue más amplia: ¿Qué procesos seguimos o cómo creemos que los desarrolladores se comprometerán en el proyecto? En general, diría que la forma más eficiente es hacer que el código sea el proceso, el proceso de toma de decisiones, más transparente, y es lo que espero lograr el año próximo.

No sólo con un enfoque en OpenOffice.org o cualquier otro proyecto, pero en general, si quieres un proyecto realmente exitoso, debes hacer que las decisiones clave sean transparentes para que los desarrolladores puedan participar en ellas de forma pública. Probablemente esto sería en primer lugar, entonces se agregarían, para los proyectos generales de software libre, todas las demás definiciones de software libre, hacer que el código esté disponible, etc. Asimismo, tener una tecnología que la gente conozca y un ambiente que soporte sus esfuerzos, que no deje de funcionar y sea confiable, que proporcione las herramientas que permitan una gran cantidad de colaboración; esos son los requisitos relativamente esenciales. Pero tener el aparato político, es decir, la transparencia, es extremadamente importante. De lo contrario, los desarrolladores quedarán insatisfechos o frustrados.

La mayoría de la gente no está consciente de esto y cree que necesita tener un código excitante o sexy para obtener desarrolladores. Pero creo que es menos importante. Por ejemplo, cuando iniciamos OpenOffice.org, la gente creía que era demasiado aburrido, y la serie de oficina no es tan excitante como un navegador web, como Mozilla -ese ha sido siempre nuestro modelo. Pero, resulta que estábamos equivocados; hemos adquirido mucha popularidad entre los colaboradores y los usuarios finales en todo el mundo, sobre todo en áreas como localización y puertos, documentación y soporte. Cada vez obtenemos más. Los usuarios finales adoran el producto.

La cuestión es que podrías tener un paquete de contabilidad, que, sin ofender a los paquetes de contabilidad actuales, supuestamente es "aburrido" y que podría volverse excitante si los desarrolladores lo representaran bien e hicieran de él un proyecto que inspirara desarrollo. Esto me lleva al segundo punto. El código mismo no es lo único que atraerá a la gente, sino la forma en que se representa ante el mundo y la estructura del proyecto. Comercializar un producto y un proyecto, especialmente frente a los usuarios finales, es una cosa -fue lo que hicimos con OpenOffice.org-, pero es igual de importante estructurarlo para que el desarrollo sea gratuito y transparente. Un proyecto se vuelve excitante a medida que los demás -la comunidad- se comprometen con él y se forma una comunidad cuando los miembros reclaman un terreno común cuya amplitud es clara. Envuelve los procesos en misterio y te arriesgas a perderlo todo.

Ahora, en cuanto a OpenOffice.org, al ir de un sistema patentado a un sistema de software libre, lo posicionamos esencialmente como el fulcro sobre el cual girará el mundo del software. OpenOffice.org es una aplicación necesaria para el escritorio de software libre. Pero sólo pudimos hacerlo así porque el código era tan bueno y satisfacía las necesidades de tantos usuarios finales.

Cuando dice que lo posicionaron así, ¿quiere decir posicionarlo frente a los desarrolladores?

Frente a los usuarios y los desarrolladores. Hay que reconocer que el producto tiene tanto éxito como quieran los usuarios, hasta cierto punto. Los desarrolladores que están trabajando en OpenOffice.org siguen teniendo dificultades, porque aunque nos seguimos aventurando con proyectos, y aunque tenemos mucha documentación, y aunque tenemos mucha gente que ayuda a quienes acaban de llegar al proyecto, sigue siendo una tarea enorme. Pero ahora también es una tarea política, cultural e intelectualmente, porque hemos posicionado OpenOffice.org para que sea ese fulcro.

¿Qué puede hacer el software, es decir, el sistema CollabNet, para facilitar el aparato político que mencionó además del posicionamiento?

OpenOffice.org nació usando una de las primeras versiones de CollabNet Enterprise Edition. La aplicación de la infraestructura ha evolucionado mucho, y hemos aprovechado los cambios, pero la arquitectura básica de OpenOffice.org no ha cambiado durante los últimos cinco años. Tratamos de establecer la diferencia entre la arquitectura política y funcional de OpenOffice.org y la arquitectura de la aplicación de CollabNEt, pero generalmente hay una combinación o una mezcla.

Pero, para responder a tu pregunta de forma más general, sí, es importante tener una infraestructura integrada que permita que los usuarios, los desarrolladores y otros colaboradores existan en el mismo universo y tengan acceso a los mismos elementos en común. OpenOffice.org nos da eso. La forma en que hemos organizado OpenOffice.org permite que quien se tome el tiempo para registrarse -y es un trámite trivial-, pueda presentar un reporte de problemas o errores y hacer algo al respecto. Nosotros damos instrucciones sobre como hacerlo, y nuestras listas son bastante útiles. En segundo lugar, la aplicación de CollabNet permite que la gente que contribuye de forma más desarrollada, digamos que trabaja en documentación, use exactamente las mismas herramientas que les interesan a los desarrolladores más avanzados, por ejemplo, para los códigos; y que los desarrolladores experimentados que estén interesados en escribir código usen herramientas que les son familiares, como CVS y una versión de BugZilla.

¿Qué me dice de sus competidores? Estoy cambiando un poco de tema, pero no creo haber visto, o probablemente no me he dado cuenta, distribuciones distintas en OpenOffice.org, como lo he visto con, digamos, Linux. ¿Cómo abordaría esto como comunidad?

¿Te refieres a una variedad de marcas de OpenOffice.org? Me encantaría, siempre y cuando se mantuviera la identidad del código fuente. De hecho, una pregunta filosófica interesante sería ¿OpenOffice.org es un producto o un proyecto fuente? Sí, distribuimos binarios y tratamos de hacerlo bien, pero ¿eso califica como mercancía? En el sentido de algo que, de acuerdo a la definición clásica de mercancía, tiene valor comercial y de intercambio por sí mismo, ¿o trasciende (así como otros productos de software libre) a la idea que los consumidores tienen de mercancía? Prefiero pensar que somos más un proyecto fuente que distribuye binarios y no una empresa que distribuye una mercancía que también distribuye fuente. Los binarios pueden ser muy buenos y pueden estar empacados de forma atractiva para los consumidores -digamos, envueltos en plástico-, pero preferiría pensar que somos un proyecto fuente.

La diferencia es que si existieran muchas personas distribuyendo versiones derivadas de OpenOffice.org, me daría mucho gusto porque, en algún momento, la arquitectura de OpenOffice.org es adecuada y las licencias son buenas, entonces tendrías a las personas que colaboran con sus innovaciones al proyecto fuente. Y ese es el objetivo principal de tener un proyecto de software libre. No sólo proporciona valor, sino que lo genera. Ahora ¿qué opina Sun sobre esto?

Es a lo que quería llegar.

Bien, pues no lo sé. No soy empleado de Sun. Sin embargo, Sun vende StarOffice, su derivado que está envuelto en plástico. Yo pensaría que Sun se basa en la forma en que los demás venden sus versiones derivadas, y no me refiero a Novell con su NLD, o a Fedora de Red Hat, o Linspire o cualquiera de esos, sino a empresas más pequeñas que venden productos patentados (porque usamos SISSL, que es como BSD [Nota: estas son licencias -Sun Industry Standards Source License], que venden alguna versión derivada de OpenOffice.org por cierta cantidad -probablemente existan unas diez empresas así, que van desde SOT Office hasta Magyar Office, hasta cosas nunca antes vistas. Ahora, no le gustan mucho esas cosas, no le gusta que IBM esté usando OpenOffice.org en su WorkPlace de forma poco clara, y probablemente le gustaría limitar todo eso; yo lo haría también, por las mismas razones. Me gustaría que quienes se están beneficiando con OpenOffice.org contribuyeran a él. Para unir las contribuciones, o aún las publicaciones de las soluciones, creo que tendríamos que cambiar las licencias. Me he dado cuenta de que, aunque SISSL expande el mercado, su uso no hace que la gente contribuya con el proyecto, y ese no es su objetivo.

Hay que deshacerse de la licencia SISSL. Creo que podríamos cambiar OpenOffice.org al GPL, junto con una licencia comercial, o simplemente el LGPL. Para repetir, el punto es promover el desarrollo de la fuente uniendo las colaboraciones mediante la licencia correcta, y permitir que se pueda comercializar. Pero si quieres comercializar u obtener alguna ventaja del trabajo que realiza la comunidad, entonces debes pagarle, no explotarla.

Desde su punto de vista, obviamente es bueno tener estas otras comunidades, pero sigue contando con el soporte de... bueno, Sun es en definitiva la empresa grande, pero ¿qué sucede si Sun decide que no vale la pena? Seguramente, el proyecto puede seguir, como lo hemos visto con otros proyectos de software libre, pero ¿es posible mantener cosas como el posicionamiento o la accesibilidad que tiene para los desarrolladores, en el mismo nivel?

Hace como un mes alguien me preguntó "¿qué pasa si se cae el cielo?". Nuestra reacción normal es que es en el mejor interés de Sun continuar con OpenOffice.org como proyecto fuerte de software libre, y pensar en formas para monetizar, no tanto las contribuciones que hace la comunidad de software libre, sino las derivaciones, las adiciones, los servicios: las formas en que puede agregar valor a OpenOffice.org para vender ese valor agregado a los clientes.

Por ejemplo, StarOffice pule bastante el código de OpenOffice.org; estoy seguro de que podrían crear una versión más sofisticada, que se adapte mejor a las empresas y los gobiernos. Creo que el único factor limitante es la imaginación y la voluntad para pensar en OpenOffice.org como producto inicial, no final. Seguramente encontrarán formas para agregar valor. Así que, para tomar tus puntos, si Sun dejara de dar soporte al proyecto, que sería una situación hipotética, ¿qué sucedería? Bien, en primer lugar, el riesgo sería para el proyecto: ¿se fragmentaría el proyecto OpenOffice.org? Probablemente sufriría daños graves, ya que gran parte de nuestro desarrollo principal depende de Sun, pero ¿encontraría otro hogar? Probablemente. Pero creo que una situación más probable sería que seguiría como fundación independiente, soportada por un consorcio de empresas y gobiernos. La fundación es atractiva simplemente porque OpenOffice.org no dependería de una sola empresa patrocinadora, sino que lo haría de un consorcio y de contribuciones anónimas, etc. Estoy seguro de que es atractivo para Sun, también que no tendría que asumir todos los costos de desarrollo. Los demás también participarían. El problema es la propiedad intelectual, es decir, la de OpenOffice.org. Actualmente, Sun tiene los derechos y los colaboradores firman un contrato de derechos conjuntos que asigna dichos derechos a Sun. Sin embargo, para que una fundación funcione, debería mantenerlos. En cualquier caso, voy a abrir el tema de una fundación en la conferencia de OpenOffice.org de este año, OOoCon.

Pero volviendo a tu pregunta, no creo que, sin el soporte de Sun, desaparezca el proyecto real o pierda su identidad. Y eso se debe en parte al tamaño actual. Tenemos más de 200,000 miembros registrados, pero supongamos que 100,000 de ellos son falsos -duplicados, errores, etc. Eso nos deja con 100,000 personas. Tenemos miles de colaboradores en todos los idiomas y de todo el mundo. Tenemos mucho interés por parte del gobierno, y algo de interés por parte de las empresas; las empresas, la gente y los gobiernos se interesan por las razones que mencioné antes, porque OpenOffice.org es un buen software y además es libre. También es gratuito.

¿Quién cree que sea la persona que decide si se iniciará un proyecto nuevo, digamos CRM, y si se toma la ruta del software libre para desarrollarlo? ¿Qué tipo de consejos le daría para iniciarlo? Porque me parece que una de las grandes ventajas de OpenOffice.org es su inmenso alcance. Que aunque Sun desaparezca, hay mucha gente involucrada en él, ahora que esa comunidad masiva es como su quid. ¿Cómo empieza desde cero?

De hecho, acabo de hacer un par de presentaciones sobre este mismo tema. Desde luego que le interesa a la gente. Recuerda que OpenOffice.org de Sun es un proyecto patrocinado, así que desde el inicio somos más grandes que lo que sería un proyecto de software libre. Para alguien que acaba de empezar con algo pequeño, digamos CRM, como sugieres, la situación probable es que estén iniciando con otros dos o tres, máximo, que todos han contribuido para crear una aplicación inteligente que tiene licencia de software libre, y que decidan iniciar un proyecto en SourceForge y esperen que la gente venga a contribuir. Probablemente estén muy contentos aunque nadie venga, y si alguien viene, se registra en las listas y contribuye con soluciones, estarán encantados. Tal vez estén contentos aunque nadie venga porque el hecho de tener un proyecto con dos o tres personas es un tamaño normal para muchos proyectos de software libre. NeoOffice/J, que es el derivado Mac OS X de OpenOffice.org, que funciona perfectamente con el sistema Apple, inició con un desarrollador independiente que empezó a colaborar con varios otros desarrolladores de OpenOffice.org para Mac OS X, y así creció el equipo principal, pero ahora son tal vez tres o cuatro personas que lo están haciendo muy bien. Asimismo, aún el puerto Mac OS X (X11) de OpenOffice.org empezó con sólo dos personas que trabajaban básicamente juntas en su tiempo libre y se comunicaban mucho por IM.

Para muchos proyectos de software libre no es necesario tener muchas personas. ¿Qué hay que hacer si se quiere contar con más personas? y ¿cómo promover el producto para que la gente lo conozca?

Bien, pues promocionarlo en SourceForge tiene sus problemas. Primero, existen muchos miles de proyectos, así que el tuyo puede pasar desapercibido. No hay distinciones. Sí, es gratuito y eso es maravilloso, y hacen muchas cosas por ti, y eso es bueno para los proyectos pequeños, pero los simples números hacen que sea difícil distinguir tu proyecto de los demás. Segundo, y este problema es tanto de mercadotecnia como de gerencia, ¿qué sucede si estás haciendo lo mismo que alguien más, sólo con algunas diferencias? Desde el principio tendrás un problema, ya que la gente estará dividiendo sus intereses y no podrá evaluar una tecnología con respecto a otra. Tercero, ¿cómo atraes a los desarrolladores si eres algo distinto y tu tecnología es interesante pero no tienes un mensaje claro o algo así?

Tendrías que hacer algo de mercadotecnia. No me refiero a adornar mucho tu proyecto o a ser falso. Me refiero a esforzarte por presentar ante las demás personas -y, de ser relevante, a los posibles usuarios finales- lo que estás haciendo. Pero también me refiero a usar los aparatos de noticias existentes. Es decir, escribir comunicados de prensa, dar entrevistas, presentaciones, etc. Trata también de distinguir tu presencia para que tengas un espacio web que contenga las herramientas que necesitas pero que no se perderá entre una gran cantidad de proyectos similares. SourceForge no tiene nada de malo, sólo que es muy difícil distinguir tu proyecto de los demás. Pero eso no quiere decir que no puedas aplicar algo de mercadotecnia.

Te voy a dar algunos ejemplos concretos. Plone es un ejemplo de buena mercadotecnia y posicionamiento en el mercado. Básicamente, empezaron con algunas personas que trabajaban en Noruega y en otras partes. Es decir, una persona estaba en Arizona, creo, otra en Noruega y las demás en otras partes del mundo. Su tecnología ha ido ganando más y más desarrolladores y más usuarios finales. eZ Publish hace algo similar a Plone, pero actualmente -y creo que eso cambiará dentro de poco- Plone está más presente entre la gente, tal vez porque han hecho un poco más de mercadotecnia. Fueron a las conferencias, conocieron a la gente adecuada, hicieron todo lo que hay que hacer si quieres que la gente conozca tu proyecto. Es mercadotecnia pura.

Es muy interesante oírlo hablar de mercadotecnia. Creo que es la única persona con quien he hablado que realmente cree que la mercadotecnia es útil para la comunidad de software libre.

Creamos un proyecto de mercadotecnia para OpenOffice.org. Creo que fuimos el primero proyecto de todo el software libre que tuvo un grupo de mercadotecnia.

Lo que dice tiene mucho sentido, pero la comunidad de software libre no siempre lo ve con buenos ojos. Sin embargo, parece que fue algo esencial para el desarrollo de su comunidad.

Así es, y puedes usar las palabras crecimiento o alcance en lugar de mercadotecnia. No importa cómo lo llames, se trata de presentar lo que estás haciendo a otras personas, de forma que estimule su interés. Eso es lo que es.

Lo que pasa con los desarrolladores es que creen que son los únicos que trabajan con valor puro, por decirlo de alguna forma, no con precios, sino con valor. En otras palabras, los precios se relacionan con el valor del mercado, no con el valor de uso. Tradicionalmente, en la mente de las personas, la mercadotecnia ignora el valor porque sólo quiere asignarle un precio a algo, y los desarrolladores y los que trabajan con código sólo trabajan con valor, no con precio; por lo tanto, si estás trabajando con valor y no con precio, la mercadotecnia ya no es necesaria, porque sólo buscaría asignar un precio falso a un valor real.

El proyecto de mercadotecnia de OpenOffice.org, a cargo de Jacqueline McNally y John McCreesh, ha representado una gran diferencia. Básicamente, lo que hacemos en este proyecto son las cosas esenciales. Vamos a conferencias, redactamos comunicados de prensa, damos entrevistas, nos aseguramos de que las cosas estén bien presentadas a los usuarios y los desarrolladores, todo para poder presentarnos ante los demás de una forma que estimule su interés.

Por lo que se refiere a los problemas de software con CollabNet, usted mencionó a SourceForge varias veces. El que SourceForge.net sea tan grande y tenga tantos desarrolladores puede ser un punto fuerte para iniciar un proyecto nuevo. Usted parece pensar que, aunque es bueno, los proyectos pueden perderse entre tantos otros. Me pregunto si CollabNet puede usarse, o las herramientas detrás de él, para llegar al mismo punto de colaboración que obtiene de SourceForge, sin perderse.

Creo que cualquier conjunto de herramientas puede usarse de esa forma, no estoy seguro que las herramientas mismas sean el factor limitante, sino el ambiente básico. Pero para ser claro, mi punto era simplemente que SourceForge es tan amplio, porque si inicias tu proyecto nuevo ahí, no tendrás garantía de que la gente vendrá a trabajar en él. Mientras que si lo haces en CollabNet, nos aseguraríamos desde el principio de que otros desarrolladores estén conscientes del punto de este proyecto, que se posicione correctamente y que tenga el aparato, con los elementos políticos e intelectuales, para tener éxito. Uno de los problemas del software libre es que la gente se fija en las licencias e ignora la administración. Pero como OpenOffice.org ha demostrado, la licencia sólo es una parte de la historia, y en CollabNet, trataríamos de asegurarnos de que el proyecto aproveche el interés de los desarrolladores, incluyendo a los que tienen proyectos en SourceForge (¿por qué no?). Tenemos menos proyectos que, digamos, SourceForge, pero no nos interesa. Lo que nos interesa no es tener la mayor cantidad de proyectos por kilómetro cuadrado, sino tener los proyectos más eficaces y que funcionan mejor. Y creo que lo hemos logrado hasta ahora.

¿Hay algo más que quisiera agregar?

Creo que sólo me gustaría reiterar que OpenOffice.org está abierto para todos los colaboradores y los desarrolladores, así como para los usuarios. Puedes hacer la diferencia.

Con esto termina la cuarta 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 incitarla a que participe. La segunda parte presentó una entrevista con Jeff Bates de SourceForge.net, Slashdot y el Open Source Technology Group. La tercera parte presentó una entrevista con Karl Fogel de CollabNet, uno de los desarrolladores fundadores del proyecto Subversion.