055.3 Lección 1

El principal resultado de la mayoría de los proyectos de código abierto es el software, por lo que, como mínimo, dichos proyectos requieren programadores, diseñadores o arquitectos de software, evaluadores, administradores de versiones y otros expertos en desarrollo de código. La documentación también suele formar parte de estos proyectos, por lo que la comunidad también necesita autores, editores y revisores.

Es posible que otros proyectos no produzcan código, sino otros “entregables”, como un libro, un proyecto de arte o música, o un informe de políticas. Wikipedia es un ejemplo bien conocido de colaboración en un proyecto de código abierto que se centra en documentos y medios de texto. Estos proyectos necesitan expertos en el diseño, producción y entrega del entregable.

Las comunidades también se benefician de muchas otras habilidades generales, como marketing y evangelización, administración, asesoramiento legal, talento artístico para producir logotipos o diagramas en la documentación y habilidades para mantener el sitio web del proyecto y otras herramientas de comunicación. Los proyectos de código abierto pueden organizar reuniones físicas e incluso conferencias, en cuyo caso necesitan organizadores que den vida a esos eventos.

Los párrafos siguientes le dan una idea de los tipos de habilidades que busca una comunidad. Estos roles generales se pueden subdividir en varias tareas enfocadas. Un ejemplo sencillo de tal tarea es que algunos escritores editen el trabajo de otros escritores.

Entre los programadores existe una variedad de experiencias. Un proyecto saludable siempre necesita algunos programadores veteranos (o programadores senior) que conozcan bien su código y sus estándares de codificación, junto con novatos que proporcionen nuevas ideas y ayuda sencilla, como corrección de errores. Es de esperar que algunos novatos se conviertan en la próxima generación de veteranos.

La calidad del código requiere un control cuidadoso sobre lo que ingresa al repositorio central compartido con los usuarios. Por lo tanto, algunos veteranos obtienen el estatus de committer. Son responsables de verificar la calidad, utilidad y conformidad de las contribuciones con los estándares de codificación. Tienen los privilegios de aceptar el código propuesto en el repositorio confiable. Otros contribuyentes envían código a los confirmadores (committers) para su revisión.

Muchos confirmadores y otros veteranos también asesoran a nuevos contribuyentes para enseñarles los estándares y prácticas necesarios para que su código sea aceptado.

Algunos contribuyentes no aprecian el trabajo que ofrece un colaborador. Si la contribución no cumple con los estándares de calidad o codificación, el autor podría simplemente rechazarla. Pero el rechazo desanima al posible contribuyente y elimina una valiosa oportunidad educativa. Recuerde que los buenos confirmadores también son mentores. Por lo tanto, le dan al colaborador sugerencias sobre cómo llevar el código a los estándares y trabajar con el colaborador a lo largo del tiempo. Si la contribución es realmente inutilizable, al menos se debe agradecer al contribuyente y alentarlo a trabajar en otra cosa para el proyecto. Es importante ayudar a las personas a descubrir y perfeccionar sus habilidades.

Cuando una empresa inicia un proyecto de código abierto, a veces nombra responsables de su propio personal para garantizar que pueda controlar la dirección y la calidad del proyecto. Pero a menudo, las empresas permiten que personas que no son empleados y que demuestran habilidad y dedicación, se comprometan.

Los líderes de proyectos toman decisiones críticas, como qué nuevas funciones admitir. Estos líderes de proyecto a menudo también tienen que tomar decisiones no relacionadas con la codificación, como cómo promover el proyecto, resolver desacuerdos importantes y obtener financiación. Los líderes de proyecto y los encargados de confirmar trabajan en estrecha colaboración con los gerentes de lanzamiento para decidir cuándo una base de código es estable y está lista para compartir con los usuarios.

Algunos proyectos tienen un único líder, a menudo denominado “dictador benévolente”. Suele ser una persona que inició el proyecto (Linus Torvalds es un ejemplo muy conocido en el caso de Linux) y que tiene una gran autoridad e incluso carisma. Sin embargo, la mayoría de los proyectos prefieren establecer un pequeño comité de líderes de proyecto en lugar de un único dictador benévolente. Incluso el proyecto Linux ha pasado a adoptar un enfoque de comité.

Los proyectos también pueden solicitar a contribuyentes particulares que brinden soporte a los usuarios en los foros del proyecto. Pero los proyectos saludables deberían tener muchos usuarios informados que se apoyen entre sí.

Terminaremos esta sección con un rol muy importante: el community manager. Es alguien responsable de mantener una comunicación abierta y constructiva y de asegurarse de que la comunidad avance hacia su objetivo. El administrador de la comunidad sabe cómo incorporar y motivar a los contribuyentes, resolver discusiones, proteger a los miembros de la comunidad contra el abuso y realizar otras tareas para mantener la salud de la comunidad.

En muchos sentidos, los proyectos de código abierto implican las mismas tareas que los proyectos tradicionales llevados a cabo dentro de una única organización. Por ejemplo, todo el código requiere pruebas. Pero en algunos aspectos, los proyectos de código abierto difieren de los propietarios, donde sólo un grupo limitado de personas pueden cambiar el código y donde dicha fuente a menudo está oculto al público.

Por ejemplo, las corporaciones suelen asignar personal capacitado en control de calidad (QA) para probar el código. Pero muchos proyectos de código abierto simplemente piden a sus usuarios que prueben cada versión. (Los proyectos propietarios también involucran a sus usuarios en pruebas, además del control de calidad).

Otro ejemplo de diferencias: un proyecto propietario generalmente asigna pagos a los desarrolladores por tareas específicas y les dice cuánto tiempo cada semana dedicar a esas tareas. Algunos proyectos de código abierto se benefician de contribuyentes pagados por sus empleadores, o en ocasiones incluso empleados por el proyecto mismo, y a quienes se les asignan tareas de la misma manera que los desarrolladores propietarios. Pero en la mayoría de los proyectos saludables, muchas contribuciones provienen de voluntarios que simplemente realizan las tareas cuando el tiempo lo permite. Debido a que el proyecto no depende de que todos los voluntarios completen sus proyectos a tiempo, un lanzamiento de código abierto podría retrasarse hasta que los desarrolladores sientan que las funciones están listas, o podría publicarse en momentos fijos con las funciones que estén listas.

Las comunicaciones son fundamentales tanto para proyectos propietarios como para proyectos de código abierto, pero a menudo se llevan a cabo de manera diferente. Los proyectos propietarios a menudo reúnen a un equipo en una oficina y celebran reuniones periódicas programadas bajo una metodología de desarrollo como SCRUM. Debido a que los proyectos de código abierto están distribuidos geográficamente, este tipo de metodologías son raras. En cambio, la comunicación se produce en línea y de forma asincrónica.

En resumen, los proyectos de software libre y de código abierto a menudo logran los mismos objetivos que los proyectos propietarios, pero de diferentes maneras.

La notificación de errores es una parte fundamental del desarrollo de software que da lugar a su propio conjunto de funciones. Alguien tiene que monitorear la base de datos de errores y asignar prioridades. Si un error es crítico (y particularmente si puede debilitar la seguridad del software), se debe asignar a un mantenedor competente para que lo solucione.

Los líderes de proyecto y los administradores comunitarios deben revisar la participación en el proyecto y ver dónde hay brechas. ¿Hay muy pocas personas dispuestas a probar el código? ¿Falta documentación? ¿Se retiran demasiados veteranos o miembros de alto nivel del proyecto sin ser reemplazados? Los líderes de proyecto y los administradores de la comunidad pueden concentrarse en reclutar personas para desempeñar los roles necesarios.

Los líderes de proyecto y los administradores de la comunidad en proyectos grandes a menudo también recopilan métricas para aprender cosas importantes, como si los errores importantes se están solucionando de manera oportuna.

Como se explicó en una sección anterior, las personas que colocan código, documentación u otros elementos en el repositorio central se denominan contribuidores. Los miembros del proyecto que aprueban las contribuciones y las aceptan en el repositorio se denominan contribuyentes. Algunos miembros asumen otras funciones comunes para el desarrollo de software.

Aunque el término contribuidor generalmente está reservado para alguien que desarrolla código u otra parte de la oferta oficial del proyecto, cualquiera que participe en el éxito del proyecto está contribuyendo de alguna manera y se le debe agradecer por hacerlo. Estas contribuciones más informales incluyen informar un error, responder una pregunta en un foro, donar o recaudar fondos y promover el proyecto entre personas externas.

Los proyectos de código abierto, como los propietarios, preguntan a los usuarios qué quieren en términos de características, mejoras de rendimiento u otros cambios en el proyecto. Estos usuarios están haciendo contribuciones importantes al expresar sus opiniones.

Aunque muchos proyectos de código abierto son creados por personas entusiastas o pequeños grupos de voluntarios, normalmente buscan apoyo organizacional cuando los proyectos crecen. El apoyo organizacional puede tomar muchas formas. En general, las organizaciones hacen estas contribuciones porque un proyecto de código abierto puede satisfacer sus necesidades comerciales de manera más económica y confiable que reinventar las mismas características en código propietario. Muchas organizaciones valoran las garantías que ofrece una licencia libre o de código abierto.

Algunos idealistas desconfían de las corporaciones u otras grandes organizaciones y preferirían mantener los proyectos de código abierto completamente libres de su influencia. Con el paso de los años, esta actitud bastante simplista se ha vuelto menos común. La mayoría de los defensores del código abierto creen que las corporaciones y otras organizaciones pueden proporcionar bases cruciales para los proyectos de código abierto.

Muchos proyectos de código abierto comienzan dentro de una organización e incluso pueden basarse en código propietario que la empresa decide abrir. Para ganar dinero, la empresa puede decidir mantener un control firme sobre el proyecto y dividirlo en partes abiertas y propietarias: esto se denomina modelo de núcleo abierto. Muchos fundadores de proyectos comienzan como código abierto pero forman una empresa a su alrededor, que puede o no utilizar el modelo de núcleo abierto.

Otros proyectos intentan garantizar que ninguna empresa controle su dirección. Mantener la independencia generalmente requiere reclutar a varias organizaciones que la apoyen, de modo que ninguna sea lo suficientemente fuerte como para tomar una decisión dictatorial.

¿Cómo apoyan las organizaciones el código abierto? Como se mencionó anteriormente, muchos asignan personal remunerado a los proyectos. Además, podrían contratar personas altamente productivas que hayan contribuido al proyecto como voluntarios y hayan desarrollado experiencia en el proyecto. Este camino hacia el empleo es una forma valiosa para que los estudiantes y otros contribuyentes voluntarios avancen en sus carreras.

Las empresas que deseen extensiones que no interesen a otros usuarios no deberían presionar al proyecto de código abierto para que agregue características adicionales, sino que deberían pagar a su personal para que escriba las características sin contribuir con ellas al proyecto.

Un ejemplo interesante de la posible tensión creada por las necesidades corporativas lo muestra el famoso sistema operativo Android, basado en Linux y desarrollado por Google para impulsar sus dispositivos móviles. Algunos cambios en Linux realizados por Google se aportan a la comunidad de Linux, mientras que otros cambios aparecen sólo en Android. Los desarrolladores de Linux a veces rechazan los cambios que les envía Google, del mismo modo que todos los proyectos eligen qué contribuciones incorporar.

Hay muchas razones para que una empresa o un grupo de desarrolladores creen una versión separada de su código. Idealmente, pueden satisfacer sus necesidades agregando una biblioteca opcional o una secuencia de código que pueda excluirse durante la compilación. Pero a veces un grupo siente una necesidad importante que es incompatible con la dirección elegida por los líderes del proyecto. Cuando se crea una versión separada, se llama fork.

Las bifurcaciones solían considerarse fracasos de colaboración, pero hoy en día son mucho más aceptadas. Por lo general, las personas que crean una bifurcación, configuran un nuevo repositorio y comienzan un nuevo proyecto. Algunas personas trabajan tanto en el proyecto original como en el fork.

(Tenga en cuenta que GitHub usa la palabra “fork” para un fenómeno muy diferente: hacer un clon o una copia del código del proyecto para trabajar por separado).

Además del código, muchas empresas contribuyen económicamente. Pueden financiar esfuerzos como marketing y conferencias. Pueden unirse a la junta y ofrecer asesoramiento experto sobre la dirección y estrategia del proyecto.

Un ejemplo de la importancia de este “soporte suave” (soft support) proviene del histórico servidor web Apache. El proyecto dio un gran paso adelante al principio de su existencia cuando IBM mostró interés. Los abogados de IBM mostraron al proyecto cómo crear salvaguardias legales, y una reunión pagada por IBM ayudó a los líderes de Apache a crear una organización sólida.

Para mantener la independencia, muchos proyectos de código abierto forman una fundación sin fines de lucro o se unen a una fundación existente. Ejemplos famosos de fundaciones que guían proyectos de código abierto incluyen la Fundación Linux, la Fundación Apache y la Fundación Eclipse.

El apoyo de una fundación es valioso porque puede proporcionar la logística con la que la mayoría de los desarrolladores de software no quieren lidiar: apoyo legal como marcas registradas, indemnización y licencias, ayuda para recaudar dinero, infraestructura como bases de datos de errores y sitios web, etc.

Al igual que ocurre con los libros, la música y otros esfuerzos creativos, el software implica una relación complicada entre los desarrolladores, las organizaciones que distribuyen sus contribuciones y el público en general. Esencialmente, los contribuyentes deben tomar medidas para formalizar el derecho de un proyecto de código abierto a utilizar y distribuir su código.

Por lo tanto, muchas organizaciones de código abierto solicitan a sus contribuyentes que firmen un acuerdo de licencia de colaborador (CLA). A veces, el colaborador simplemente proporciona el código del proyecto. El proyecto es propietario del código y de todos los derechos sobre él, del mismo modo que una empresa propietaria es propietaria del código cuyo desarrollo pagó a su personal.

Otros CLA dejan algunos derechos en manos de los contribuyentes individuales. A los contribuyentes les puede gustar esta flexibilidad porque pueden contribuir con el mismo código a otro proyecto o construir su propio negocio en torno a él.

Para armonizar las diferentes contribuciones de diferentes personas, la licencia asignada al código es crucial. El kernel de Linux es uno de los proyectos que deja la propiedad en manos de los contribuyentes, de modo que ahora miles de personas poseen los derechos sobre el código de Linux. Pero todos los contribuyentes al código central lo colocaron bajo la Licencia Pública General GNU (versión 2). Por lo tanto, Linux es libre para que todos lo usen, modifiquen y redistribuyan.

Usar una licencia única para todo el código de un proyecto es la forma más sencilla de garantizar que no haya obstáculos que impidan la distribución y el uso del código. Pero a veces un proyecto permite que se contribuyan diferentes partes de código bajo diferentes licencias, generalmente porque el proyecto quiere aprovechar algún código preexistente que ya está publicado bajo una licencia diferente. Los expertos en licencias deben asegurarse de que las estas sean compatibles.

Muchas comunidades en línea tienen fama de expresarse sin restricciones (una idea arrogante de que “todo vale”) que conduce a abusos verbales y disputas. Hoy en día, la mayoría de las comunidades de código abierto están luchando contra esa tendencia, que se apodera de la gente con demasiada facilidad. Por el contrario, las comunidades modernas quieren que las personas sean constructivas, cívicas, respetuosas e inclusivas con todos: géneros, grupos étnicos, tipos de personalidad, etc.

Las expectativas de los miembros del grupo suelen especificarse explícitamente en un código de conducta que explica cómo interactuar con otras personas en el proyecto, tanto en línea como en persona. Para que sea eficaz, este código de conducta debe ser aplicado por el administrador de la comunidad y los líderes del proyecto.

En ocasiones, una persona que se burla o denigra flagrantemente a un compañero de la comunidad es expulsada de forma permanente o temporal. En otras ocasiones, el administrador de la comunidad o un colega simplemente anuncia públicamente que el comportamiento viola el código de conducta y podría hablar con el infractor fuera del foro. A menudo, el agresor previamente sintió frustración, falta de atención o agotamiento, y los miembros de la comunidad pueden ayudarlo a encontrar mejores maneras de expresarse.

Además del comportamiento social, las comunidades establecen estándares de calidad. Las más formales consisten en pautas de codificación, que intentan garantizar que todo el código sea similar. Las pautas pueden recordar a los desarrolladores buenas prácticas como el uso de corchetes alrededor de bloques de código, o pueden especificar detalles como cómo nombrar las variables y qué tipo de sangría usar.

Las comunidades de código abierto también tienen reglas sobre la publicación de código u otros entregables. Algunos proyectos establecen tiempos fijos para las liberaciones; por ejemplo, Ubuntu promete una nueva versión de soporte a largo plazo (LTS) cada dos años junto con lanzamientos provisionales con mayor frecuencia. Otros proyectos mantienen una lista de nuevas funciones y correcciones de errores que desean en la próxima versión y aprueban la versión cuando todo está marcado en la lista. Pero a diferencia de la mayoría de las empresas, las comunidades de código abierto no suelen establecer plazos para los participantes, porque no se puede pedir demasiado a los voluntarios.

Además del acuerdo de licencia de contribuyente mencionado anteriormente, algunos proyectos solicitan a los contribuyentes que firmen un certificado de origen de desarrollador (DCO). En el DCO, el contribuyente promete que tiene el derecho legal de donar el código.

¿Por qué es importante el DCO? Imagine este escenario: si un programador toma código de un producto propietario producido por su empleador y lo aporta a un proyecto de código abierto, el programador viola la licencia del empleador y pone el proyecto de código abierto en riesgo legal.

Se supone que el DCO debe garantizar que el contribuyente realmente haya escrito el código o lo haya obtenido legalmente. El proyecto de código abierto depende de la honestidad del colaborador que completa el certificado.

Los científicos sociales afirman que los proyectos y las empresas se benefician al tener muchas personas con diferentes géneros, razas, orígenes económicos, nacionalidades y habilidades. Todas las organizaciones tienen una tendencia humana natural a vincularse con otras personas como sus miembros actuales, por lo que una comunidad que valora la diversidad y la equidad tiene que capacitar conscientemente a sus miembros para que sean más abiertos a las personas que no son como ellos. El movimiento para llevar a cabo este ideal se llama diversidad, equidad e inclusión (DEI).

El código de conducta es el punto de partida de DEI. Debería dar la bienvenida explícitamente a personas de diferentes géneros, razas, etc. Cada violación del código de conducta debe abordarse con prontitud y con una desaprobación inequívoca. Esto se debe a que algunas minorías han sufrido exclusión y comentarios negativos toda su vida, y una sola mala interacción en su foro podría hacerles decidir que ya no tienen motivos para participar. Una respuesta rápida a las agresiones puede asegurarles que la comunidad los respalda.

Pero DEI va mucho más allá. La comunidad debería acercarse a los grupos que necesitan más representación. Por ejemplo, si está desarrollando una aplicación de búsqueda de empleo, debe asegurarse de que muestre trabajos para personas de bajos ingresos, así como para personas de clase alta y media. También debes promocionar la aplicación entre las comunidades de bajos ingresos y reclutar miembros de esas comunidades para que la prueben.

Su comunidad podría beneficiarse al encontrar organizaciones que capaciten a personas de comunidades marginadas y de las cuales pueda reclutar nuevos miembros para su equipo. Muchas de estas organizaciones están establecidas en áreas locales y no son muy conocidas a nivel nacional o internacional.

Comprender las necesidades de las comunidades marginadas es clave. ¿Su sitio web es accesible para personas con discapacidad visual? ¿Traduce su documentación a idiomas con los que la comunidad de destino está familiarizada? Quizás deberías crear foros específicos en otros idiomas.

La mayor parte de la comunicación en las comunidades de código abierto es asincrónica y en línea. Pero si tiene reuniones o sesiones de chat sincrónicas, piense dónde están geográficamente las personas y encuentre formas de incluirlos a todos. Por ejemplo, cuando personas de muchos países y regiones se comunican en inglés, trate de mantener el vocabulario y la gramática simples.

Finalmente, si tienes miembros de alguna minoría en tu equipo, asegúrate de escucharlos. Un síntoma bien conocido de exclusión es descartar lo que dicen las minorías o simplemente subestimar su importancia.

Por otro lado, no cargue a los miembros de las minorías con explicar las necesidades de sus comunidades: todos deberían tener la tarea de esa investigación. Los miembros de la minoría podrían hacer una valiosa labor de divulgación para usted, pero no los presione para que lo hagan. Cada persona debe tener las mismas oportunidades de participar como quiera, sin tener que ser una minoría simbólica.