Código abierto: comunidad / empresa, respeto por los roles

La identidad es importante en el código abierto, pero no de la forma en que podría pensar. Por ejemplo, Lili Cosic trabaja para Red Hat, y también es responsable del mantenimiento dentro de la comunidad de Kubernetes y responsable de las métricas de kube-state. Si bien Red Hat anima a Lili Cosic en el trabajo que realiza para Kubernetes, la empresa no tiene en cuenta su participación. El código abierto es un área separada y personal. O, como explicó la Sra. Cosic en una entrevista, en código abierto, "siempre usa el sombrero de la empresa y también usa el sombrero de gerente de mantenimiento, pero siempre se asegura de mantener las líneas separadas. Dos roles".

Lili Cosic coloca esta primera conexión especial con el código abierto cuando tenía 13 años, el día en que su madre le compró una computadora. Aquí es donde se propuso desarrollar "pequeñas cosas como scripts o páginas web o cosas por el estilo". Pero su exploración de la codificación no terminó ahí, y es útil comprender el proceso mediante el cual se convirtió en mantenedora de Kubernetes y cómo se relaciona con su trabajo en Red Hat.

Un error tipográfico y un trabajo consistente

La primera contribución de Lili Cosic no fue particularmente prometedora. Según ella, su camino hacia el código abierto comenzó con un error tipográfico: “Creo que la mayoría de los desarrolladores viven la experiencia del error tipográfico. Ella fue quien me impulsó a abrir una solicitud de extracción en el documento Léame de Docker. "Animada por su capacidad para participar y mejorar un proyecto, Lili Cosic se involucró un poco más. Y cada vez más ... Sus contribuciones no conciernen a las características más destacables de Kubernetes u otros proyectos. Y eso no fue así, según ella , la mejor manera de contribuir al proyecto. "La consistencia es la clave. No importa si estás contribuyendo con grandes o pequeños fragmentos de código. Lo principal es contribuir de manera consistente durante un período de tiempo .

En general, esta contribución debe ser constante durante al menos unos meses, lo que incluye revisar solicitudes de extracción y responder preguntas sobre problemas de GitHub o en listas de correo o en Slack o algo así ”. Como explica además, "En realidad, es mejor contribuir con piezas más pequeñas para conocer todo el código base. Si solo contribuye con una característica importante, nunca conocerá el código base completo. Por supuesto, puede convertirse en responsable de esta funcionalidad, pero no de todo el proyecto ”.

Pero fue el enfoque comunitario de Kubernetes lo que más alimentó su interés en contribuir.

Lo que entendió la comunidad de Kubernetes

Según muchas versiones, Kubernetes es diferente. Si bien Linux tiene la reputación de ser una comunidad a veces cáustica, la comunidad de Kubernetes es acogedora. Lili Cosic también dijo: "No todo es perfecto, pero la comunidad de Kubernetes es una de las comunidades de código abierto más acogedoras que he visto". Y fácilmente atribuye esta diferencia a la naturaleza del grupo de colaboradores de Google: “Creo que está muy relacionado con el hecho de que muchos de los aprendices de Google Summer of Code (GSoC) eran mujeres. Entre ellos, encontramos por ejemplo a Nikhita Raghunath, miembro de GSoC en 2017, que ahora forma parte del Comité Directivo de Kubernetes. En términos porcentuales, las mujeres siguen siendo minoría, pero es más alentador ”.

“Otra ventaja de la comunidad de Kubernetes es que le permite comenzar un proyecto desde cero y no necesariamente involucrarse en un proyecto bien establecido. Además, la comunidad de Kubernetes es intencionalmente inclusiva ”, agregó. “En Cloud Native Computing Foundation (CNCF), todo un equipo está dedicado a mejorar la experiencia de contribución, lo que ayuda mucho. Hacen todo lo posible para dar la bienvenida a los recién llegados ”. Emocionalmente, podría parecer deseable experimentar el "síndrome del impostor" hasta cierto punto, pero en el ámbito tecnológico, para los grupos subrepresentados, puede ser más difícil de superar. “A largo plazo, este ambiente acogedor puede fomentar una mayor diversidad entre los contribuyentes”. Lo que, a su vez, puede mejorar la calidad del software.

Comunidad / Empresa: respeto por los roles

Pero esta diversidad no se relaciona realmente con las empresas que pagan los salarios de los desarrolladores. Son los propios desarrolladores los que se reconocen dentro de un proyecto. Es conveniente asumir que un ingeniero que trabaja para IBM, por ejemplo, está contribuyendo con código a un proyecto corporativo en particular. Este puede ser el caso de proyectos en los que IBM es el contribuyente dominante (o el único contribuyente), pero esto no es lo que sucede en el código abierto en general. La Apache Software Foundation es muy explícita en este punto: “Creemos firmemente en respetar los roles. Su papel dentro de la ASF se le asigna personalmente y sus compañeros se lo confían. No está relacionado con su trabajo actual, empleador o negocio ”.

Lili Cosic fue igualmente clara cuando se le preguntó qué impacto podría tener su puesto en Red Hat OpenShift en su trabajo para Kubernetes: “Siempre tienes dos sombreros. Siempre usamos el sombrero corporativo, pero también somos responsables del mantenimiento y siempre nos aseguramos de mantener los dos separados. Siempre queremos asegurarnos de esta distinción por el bien del proyecto ". Pero, uno siempre puede preguntarse si su trabajo en kube-state-metrics no la coloca en una posición para dirigir el proyecto en beneficio de Red Hat. "Los gerentes de mantenimiento no necesariamente trabajan en las funciones. Están ahí para asegurarse de que el proyecto esté en buen estado ... Siempre que tomo una decisión sobre las funciones, nunca pienso en ello desde la perspectiva de Red Hat. Me pregunto si encaja ¿Cuál es el propósito del proyecto? Ella respondió. "Recientemente, alguien de Red Hat abrió una función. Sin embargo, esto no está en el ámbito de kube-state-metrics. Así que lo rechazamos. Tenemos que ceñirnos a esos estándares. no es un proyecto de Red Hat. Es un proyecto para la comunidad. Mi trabajo en Red Hat no necesariamente tiene un impacto en los proyectos que mantengo. La empresa decide solo sobre la distribución de mi tiempo de trabajo. En cualquier momento, alguien de Red Hat dice: "Quiero esta funcionalidad en kube-state-metrics", siempre actuaré como gerente de mantenimiento. más que un empleado de Red Hat. "

Entonces, cuando Lili Cosic se encuentra (virtualmente, en estos tiempos de pandemia) con los otros dos mantenedores de kube-state-metrics, no hablan de lo que este o aquel proveedor quiere en la próxima versión 2.0. Simplemente están discutiendo lo que se necesita para hacer avanzar el proyecto desde un punto de vista de mantenibilidad, así como eliminar la deuda técnica y determinar qué tipos de datos recopilar. Así es como se supone que funciona el código abierto: individuos, trabajando juntos en una comunidad, para crear un gran software. Para Lili Cosic y la comunidad de Kubernetes, parece que el código abierto funciona como se supone.