Imagina que eres el mantenedor de un proyecto de código abierto ampliamente utilizado por desarrolladores de todo el mundo. Ser mantenedor significa que puedes decidir qué contribuciones de colaboradores externos se aceptan. Ahora, hay dos contribuciones: una de un colaborador individual y otra de una persona que sabes que trabaja para una empresa. Sabes que el colaborador individual ha trabajado en el código que aporta en su tiempo libre y te gusta mucho la calidad de su trabajo. La otra contribución también es de alta calidad. ¿Tratarías estas contribuciones de forma diferente? ¿Deberías?
Técnicamente, ambos son simplemente personas que contribuyen con código. Pero ¿se puede realmente ignorar que un colaborador pertenece a una empresa, o incluso atribuir su contribución principalmente a ella? Una encuesta reciente de la Fundación Linux reveló que las organizaciones contribuyen con 7.700 millones de dólares anuales a proyectos de código abierto, y que el 86 % de esa cantidad proviene del trabajo de individuos. Me interesa el papel que desempeñan las identidades individuales y empresariales en las contribuciones al código abierto.
Para explorar el tema, primero presentaré los antecedentes del software de código abierto y una visión general de la teoría de la identidad, tanto a nivel individual como colaborativo. A continuación, analizaré la naturaleza de las contribuciones individuales al software de código abierto, sus motivaciones y el papel de la comunidad y la meritocracia. En contraste, exploraré cómo y por qué las empresas contribuyen al software de código abierto y compararé esto con las contribuciones individuales y comunitarias. Al compararlas, identificaré los principales desafíos y tensiones entre los contribuyentes individuales y las empresas. Utilizando la teoría de la identidad organizacional previamente presentada, se pueden obtener algunas perspectivas interesantes. A continuación, presentaré algunos ejemplos prácticos que observé trabajando en ROS.
Contexto: Software de código abierto, teoría de la identidad
El código abierto, en su forma básica, significa que el código fuente de un software está disponible gratuitamente para que cualquiera lo analice, modifique o comparta. En la práctica, existen diferentes licencias que se publican con el código fuente, cada una con derechos y obligaciones ligeramente diferentes. Pero no es de esto de lo que hablaré hoy. Lo que hace al código abierto tan poderoso es que este libre acceso al código fuente permite una colaboración verdaderamente abierta. Eric S. Raymond describió esto en dos modelos contrastantes de desarrollo de software: el "Bazar" y la "Catedral". En este caso, el "Bazar" se refiere a la forma en que se desarrolla el software en proyectos de código abierto: de forma abierta y colaborativa, con numerosos colaboradores. El modelo "Catedral", por otro lado, simboliza el desarrollo de software clásico: encerrado en proyectos comerciales de desarrollo por unos pocos expertos. Raymond argumenta que el modelo "Bazar" es más eficaz para crear software robusto e innovador.
Por razones de transparencia, quiero declarar que mi análisis de estos temas se basa principalmente en mi experiencia personal en un proyecto de código abierto: ROS (Robot Operating System). Es un framework increíble para construir robots, pero sus detalles técnicos no serán relevantes para este artículo.
Antes de profundizar en los proyectos de código abierto, quisiera presentar la herramienta para esta exploración: la identidad . En términos generales, la identidad es la relación que una entidad tiene consigo misma . Locke dejó claro que es fundamentalmente la conciencia lo que permite la identidad personal . Esta conciencia puede extenderse retrospectivamente a acciones o pensamientos pasados. Si bien este es un elemento fundamental para la identidad, por sí solo no explica mi interés.
Una interpretación más moderna es la identidad social . Se trata de la percepción que una persona tiene de sí misma en función de su pertenencia a un grupo o grupos. Conocer esto puede brindar a las personas un sentido de pertenencia, propósito, autoestima y , fundamentalmente, identidad. En la práctica, estos grupos pueden definirse por cualquier factor, desde la etnia o la religión hasta la afiliación profesional o la preferencia musical. Esto también puede explicar aspectos de cómo la identidad de las personas se basa en su condición de empleadas por una empresa. Sin embargo, tengo una última sección dedicada específicamente a las corporaciones.
Cuando las empresas se refieren a sí mismas, se denomina identidad organizacional . En primer lugar, las organizaciones son más que un conjunto de identidades individuales. French argumenta que las organizaciones, en su conjunto, tienen moralidad. Básicamente, porque tienen intencionalidad y responsabilidad 9. Al pensar en una empresa, es su capacidad para tomar decisiones lo que conduce a esa intencionalidad. Una organización necesita una identidad para tomar estas decisiones. Y, de forma similar a lo que vimos con Locke anteriormente, esto se basa en su propia historia, pero también en referencia a un tipo de organización autoasignado. Creo que esto es muy interesante y puede utilizarse para explicar muchos fenómenos que se perciben al trabajar en empresas. Pero por ahora, basta de contexto, y a continuación quiero analizar la naturaleza de las contribuciones de código abierto con más detalle.
Contribuciones individuales en OSS
¿Por qué contribuyen las personas al código abierto? Creo que las motivaciones principales son intrínsecas. No debe subestimarse la pasión inherente por la programación y el desarrollo. Sin embargo, estos proyectos de código abierto también son comunidades, y participar en ellas puede ser muy motivador. Como aprendimos de la identidad social, pertenecer a un grupo es un componente de la propia identidad.
Además, las motivaciones extrínsecas también influyen. Esto incluye el propio desarrollo profesional, ya que la contribución al código abierto da visibilidad al individuo y puede crear una reputación útil al buscar empleo. El reconocimiento externo también puede servir como un factor de motivación más general. Sentirse reconocido como un contribuyente valioso aumenta la autoestima.
Creo que esta cita lo resume bien.
[Las motivaciones incluyen] tanto extrínsecas, mejorar la reputación y desarrollar el capital humano y las redes sociales; como intrínsecas, satisfacer necesidades psicológicas, placer y un sentido de pertenencia social.
Si bien hablé del reconocimiento como una fuente de motivación, el reconocimiento también cumple una función diferente en los proyectos de código abierto: el poder. Los proyectos de código abierto suelen describirse como meritocracias. Curiosamente, el término se popularizó gracias a un libro distópico titulado "El auge de la meritocracia", de Michael Young. En él, la sociedad futura imaginada, basada en la meritocracia, presenta numerosos problemas, siendo quizás el mayor la falta de movilidad social. Un análisis minucioso puede refutar los efectos negativos de la meritocracia que Young imaginó en 1958. Por ello, hoy en día, la meritocracia se considera generalmente un sistema político deseable.
Los sistemas políticos analizan cómo se distribuye el poder, y en la meritocracia la idea es que el poder se otorga en función del mérito. Es ese mérito que los desarrolladores individuales acumulan al contribuir a proyectos de código abierto. Con ello, ganarán influencia en la jerarquía del proyecto. Esto generalmente permite tomar decisiones con mayor fundamento técnico, suponiendo que quienes contribuyeron significativamente a un proyecto también tienen una idea clara de su funcionamiento interno. Existe un contraste evidente con la organización del poder en las empresas, donde las decisiones generalmente recaen en quienes tienen la autoridad jerárquica para tomarlas, pero que no necesariamente poseen los conocimientos técnicos necesarios. Esto no significa que en las empresas no se tomen decisiones con fundamento técnico, sino que el rol y la influencia potencial de los ingenieros individuales son diferentes a los de los proyectos de código abierto. En mi opinión y experiencia, esta es también una razón por la que la gente contribuye a proyectos de código abierto.
Cabe señalar que se puede argumentar que las estructuras jerárquicas en la gobernanza de muchos proyectos de código abierto (OSS) también pueden asemejarlos a las estructuras rígidas de las empresas. Sin embargo, esto no coincide con mi experiencia personal trabajando en ROS. Si bien esto puede variar según el proyecto, el tema, por supuesto, no suele ser una diferencia binaria precisa. A pesar de las diferencias en la toma de decisiones, las empresas también tienen muchas razones para involucrarse en el código abierto, y esto es lo que quiero analizar a continuación.
Contribuciones de la empresa al OSS
¿Por qué les interesa a las empresas el código abierto? A primera vista, puede parecer contradictorio que una empresa, generalmente interesada en el éxito financiero, no se interese en mejorar un software que, en última instancia, debe ser y seguir siendo gratuito, y que además se comparte con todos sus competidores directos. Sin embargo, muchos han observado que, si bien históricamente eran los individuos quienes contribuían principalmente al código abierto, ahora son las empresas. ¿A qué se debe esto?
Una primera motivación es la calidad . Eric S. Raymond introdujo la ley de Linus: «Con suficientes ojos, todos los errores son superficiales», llamada así por Linus Torvalds. 3 Esto tiene sentido: cuanto más personas revisen un código, mejor será su calidad. Diría que esto también se puede atribuir al funcionamiento de las comunidades de código abierto. Como sabe cualquiera que haya trabajado en grandes proyectos de desarrollo, tener demasiados ingenieros no produce automáticamente software de calidad. Sin embargo, sostengo que la organización de un grupo diverso de ingenieros intrínsecamente motivados en estructuras meritocráticas también es lo que conduce a la mejora constante de la calidad del software. Sin embargo, la promesa de calidad no puede ser la única motivación para que las empresas inviertan 7700 millones de dólares anuales en proyectos de código abierto.
La innovación se vuelve realmente interesante. Históricamente, se consideraba una tarea inherente a una empresa crear innovación por sí misma. Sin embargo, el avance constante del estado del arte técnico puede dificultar mantenerse al día, y mucho menos extenderlo mediante la innovación. El OSS contribuye en este sentido, nivelando las condiciones. Cuando el estado del arte está disponible para todos, no es necesario reinventar la rueda. Cada empresa puede centrar sus equipos de desarrollo en invertir en lo que considera innovador. Esto también hace que estos proyectos sean sumamente interesantes para las empresas más pequeñas, ya que los efectos descritos son aún más pronunciados en ellas.
Si las empresas basan su innovabilidad, y por lo tanto a veces todo su modelo de negocio, en software de código abierto, es natural que tengan un interés en el bienestar del proyecto OSS asociado. Es por eso que muchas empresas apoyan dichos proyectos monetariamente. Sin embargo, esta dependencia también motiva el deseo de influencia. La influencia estratégica a largo plazo a menudo es otorgada por el proyecto OSS a cambio del apoyo financiero. Para la influencia técnica a corto plazo, a menudo también es en el interés de las empresas pagar a sus desarrolladores para que contribuyan activamente al software. Esta influencia también puede ser más específica, pero a menudo requiere la construcción de contribuyentes con la influencia necesaria a largo plazo 16 . Un punto muy interesante en la encuesta de la Fundación Linux fue que muchos encuestados estaban relativamente más informados sobre el tamaño de sus contribuciones financieras que sobre la contribución a través del trabajo.
Desafíos y tensiones
A primera vista, esta parece una relación mutuamente beneficiosa: los ingenieros quieren contribuir, las empresas les permiten hacerlo y ganar influencia. Sin embargo, esto también conlleva desafíos. Por ejemplo, no es fácil para las empresas saber qué influencia desean o necesitan a largo plazo. También puede ser difícil para un ingeniero que ve la necesidad de dicha influencia convencer a su empleador para que realice las inversiones necesarias. En este caso, es interesante pensar a qué identidad se vinculará este mérito: ¿a la de la empresa o a la del ingeniero individual? En mi experiencia, a menudo es la individual, hasta el punto de que estas personas conservan su mérito al cambiar de trabajo. Obviamente, esto no beneficia a las empresas que han invertido específicamente en esa persona y proyecto. Sin embargo, mediante un cuidadoso trabajo de estrategia de OSS a largo plazo, también es muy factible que las empresas acumulen mérito y no lo pierdan con los cambios de personal.
Otro desafío muy real para los colaboradores y mantenedores individuales, destacado por Nadia Eghbal y otros, es el agotamiento. Este fenómeno puede ser inherente a una gobernanza insuficiente en la gestión de proyectos de OSS. Los mantenedores que ocupan puestos muy específicos para su persona o sus habilidades corren un riesgo especial de agotamiento. Una gobernanza eficaz definiría procesos para distribuir su carga de trabajo entre más personas o encontrar a alguien que las sustituya en caso de que necesiten un descanso o atender sus obligaciones personales. A menudo, también es improbable que alguien más ocupe el puesto de esa persona. Si hace un buen trabajo, nadie cuestionará su puesto, y si su carga de trabajo se percibe como algo más que un trabajo a tiempo completo, esto se vuelve aún menos probable. La relación con la identidad empresarial es más débil en este caso: el fenómeno descrito suele aplicarse a personas cuya identidad es mucho más relevante para su éxito que la de su empresa, si es que esta llega a ser relevante. Sin embargo, la trágica realidad es que muchas otras empresas dependen del trabajo de esa persona sin poder garantizar sus condiciones laborales adecuadas. Ahora, creo que podemos analizar estos desafíos más de cerca con algo más de teoría de la identidad.
Teoría de la identidad organizacional aplicada al OSS
Un aspecto interesante del artículo de Whetten es que las identidades organizacionales son más fluidas que las personales. Eso es al menos lo que yo entiendo, y tiene sentido, ya que, como persona, dependo mucho más de esa identidad, la cual puede causar una crisis grave si se cuestiona o cambia demasiado. Sin embargo, las identidades de las empresas se cuestionan con mayor frecuencia y, a menudo, solo se definen correctamente en situaciones de cambio o crisis. Esto explica cómo el mérito en OSS se atribuye con mayor fuerza a las identidades individuales si son más constantes. No obstante, también es evidente que una condición necesaria para la asignación de mérito a las corporaciones requiere una identidad organizacional sólida. Esto, por supuesto, también se ve influenciado por las identidades individuales de los ingenieros afiliados a dichas corporaciones en contextos públicos como los proyectos de OSS.
Otro vínculo interesante se puede extraer del argumento de French sobre la moralidad de las corporaciones 9 . Si alguien afirma que las compañías que usan software de código abierto deben devolver contribuciones a cambio, eso es una declaración moral. Esto ganaría o perdería validez según la atribución de moralidad a las compañías. Antes de leer el artículo de French, personalmente no habría asumido que las compañías fueran morales. Además, tampoco pensaba que la moralidad fuera muy relevante en el contexto de las compañías que contribuyen (o no) al código abierto. Sin embargo, creo que podemos aprender algo al aplicar el argumento de French al código abierto: el argumento se basa en la intencionalidad y la responsabilidad. Esto tiene sentido intuitivo para mí, que solo puedo ser moralmente responsable de las acciones que hice intencionalmente y de las que soy responsable. Cuando aplicamos esto a una compañía que pretende usar software de código abierto y es responsable de ese uso, solo entonces estaría moralmente obligada a contribuir. Lo que ocurre sin intencionalidad es interesante: si la organización no tenía intención de usar ese código fuente abierto, por ejemplo, porque un empleado decidió usarlo sin obtener la aprobación correspondiente, esto no implica necesariamente la necesidad moral de una decisión a nivel de empresa para contribuir. En cuanto a la responsabilidad, podríamos considerar el ejemplo de una empresa que no es responsable del uso de un software de código abierto, quizás porque otro socio comercial la obliga a usarlo; entonces también puedo seguir el argumento de que no estaría moralmente obligada a contribuir. Me resulta fascinante la claridad con la que atributos como la moralidad, bien comprendidos por los agentes individuales, pueden aplicarse a las organizaciones. En este caso, el código abierto es un excelente ejemplo que ayuda a aclarar estas ideas.
Estudios de casos y ejemplos
Para que estos puntos sean aún más comprensibles, me gustaría añadir algunos ejemplos prácticos que observé en ROS. Un aspecto que no sé cuán único es en comparación con otros proyectos es la prevalencia de pequeñas empresas o colaboradores que tienen su propio negocio freelance. Esto, por un lado, sirve como una perspectiva interesante sobre la moralidad de las empresas, que es aún más fácil de creer cuanto más cercana está una empresa a un solo individuo. Por otro lado, también resalta la importancia de los colaboradores individuales en el OSS. Muchas de estas empresas no solo son pequeñas, sino que también están en constante cambio, lo que hace que las personas sean un aspecto más constante de la comunidad que sus propias empresas. Aquí, tengo una observación que discreparía con Schrape, quien escribe que «las empresas y otras organizaciones pueden aportar sus recursos de forma más continua y consistente que los colaboradores individuales». En ROS, y en particular en Nav2, hemos visto a bastantes empresas interrumpir sus contribuciones, mientras que la participación de los individuos relevantes parece mucho más estable y constante.
Sobre la relevancia e importancia de las identidades para el trabajo en código abierto, me encontré con una discusión en Stack Overflow donde alguien pregunta si sería factible contribuir con todo lo que hace su empresa desde una sola cuenta de GitHub. El consenso general es que esto es una mala idea por varias razones, una de ellas la importancia fundamental de la comunicación personal en las comunidades de código abierto. También hay una interesante entrada de blog de Jono Bacon sobre si las contribuciones anónimas en código abierto son una buena idea, llegando a la conclusión de que las identidades en código abierto son importantes por razones de meritocracia, responsabilidad y apertura. Estos son puntos válidos sobre la relevancia de las identidades individuales en código abierto desde perspectivas muy prácticas.
Sin embargo, también existe un ejemplo interesante de identidades organizacionales a un nivel que no habíamos considerado hasta ahora. Curiosamente, ese ejemplo es la propia comunidad ROS. Podemos aplicar lo aprendido sobre la necesidad de debatir sobre una identidad organizacional y el potencial para impulsar dicho debate mediante grandes cambios y la amenaza de pérdida de identidad. El ejemplo es, por supuesto, la adquisición de gran parte de Open Robotics por Intrinsic en 2022. Esto dio lugar a numerosos debates en la comunidad ROS y, en última instancia, a la fundación de su nueva organización de gobernanza, Open Source Robotics Alliance OSRA. Por lo tanto, interpreto esto como un ejemplo de ROS como organización que pierde su identidad tras la adquisición de Intrinsic y la posterior redefinición de su propia identidad, que dio lugar a una identidad más clara y comprensible que la anterior. Y solo esta nueva identidad pudo haber llevado a la sólida posición que OSRA tiene hoy.
Conclusión
Las conclusiones clave que podrían resultar útiles de este artículo son:
- Tensión entre el mérito individual y el organizacional : Las contribuciones en proyectos de código abierto suelen estar vinculadas a las identidades individuales, más que a las empresas a las que representan. Para aprovechar esto como empresa, se necesita una sólida estrategia de código abierto.
- Meritocracia vs. Jerarquía : Los proyectos de código abierto suelen operar como meritocracias, donde la influencia se gana mediante contribuciones. Sin embargo, la gobernanza del proyecto también contiene elementos de las jerarquías clásicas. Este equilibrio es crucial.
- Motivación dual para las contribuciones : Las personas se ven impulsadas tanto por factores intrínsecos, como la pasión por el desarrollo y la pertenencia a la comunidad, como por factores extrínsecos, como el desarrollo profesional y la reputación. Las empresas, en cambio, se ven motivadas por objetivos como la mejora de la calidad, la innovación y la influencia a largo plazo en proyectos de código abierto.
- El papel de la identidad organizacional : las empresas pueden establecer su identidad dentro de la comunidad de código abierto a través de contribuciones consistentes e intencionales, lo que ayuda a generar confianza e influencia a lo largo del tiempo.
- Desafíos de gobernanza en código abierto : el agotamiento entre los mantenedores resalta la necesidad de mejores estructuras de gobernanza en proyectos de código abierto, como procesos para distribuir cargas de trabajo y garantizar la continuidad, que pueden diferir significativamente de las prácticas de gestión de proyectos corporativos.
Muchas gracias a Maximilian Roßmann y Sebastian Castro por refinar tanto el contenido como el lenguaje. ¡No podría haberlo hecho sin ustedes!
Boysel, Sam, Frank Nagle, Hilary Carter, Anna Hermansen, Kevin Crosby, Jeff Luszcz, Stephanie Lincoln, Daniel Yue, Manuel Hoffmann y Alexander Staub. 2024. “Informe de financiación de software de código abierto 2024”. https://opensourcefundingsurvey2024.com/ .
Raymond, Eric S. 2001. La Catedral y el Bazar: Reflexiones sobre Linux y código abierto de un revolucionario accidental . 1.ª edición. Oxford, Reino Unido: O'Reilly Media.
Noonan, Harold y Ben Curtis. 2022. “Identidad”. En The Stanford Encyclopedia of Philosophy , editado por Edward N. Zalta y Uri Nodelman, otoño de 2022. Laboratorio de Investigación en Metafísica, Universidad de Stanford.
Locke, John. 1694. “Un ensayo sobre el entendimiento humano”.
Gordon-Roth, Jessica. 2020. “Locke y la identidad personal”. En Stanford Encyclopedia of Philosophy , primavera de 2020.
Turner, JC, RJ Brown y H. Tajfel. 1979. “Comparación social e interés grupal en el favoritismo endogrupal”. Revista Europea de Psicología Social 9 (2): 187–204. https://doi.org/10.1002/ejsp.2420090207 .
“Teoría de la identidad social en psicología (Tajfel y Turner, 1979)”. 2023. https://www.simplypsychology.org/social-identity-theory.html .
French, Peter A. 1979. “La corporación como persona moral”. AMERICAN PHILOSOPHICAL QUARTERLY 16 (3): 5–13. https://www.jstor.org/stable/20009760 .
Whetten, David A. 2006. “Albert y Whetten revisitados: Fortaleciendo el concepto de identidad organizacional”. Journal of Management Inquiry 15 (3): 219–34. https://doi.org/10.1177/1056492606291200 .
Benkler, Yochai. 2004. “Estrategias basadas en los bienes comunes y los problemas de las patentes”. Science 305 (5687): 1110–11. https://doi.org/10.1126/science.1100526 .
Young, Michael. 1958. El ascenso de la meritocracia .
Allen, Ansgar. 2011. “ El ascenso de la meritocracia de Michael Young: una crítica filosófica”. British Journal of Educational Studies 59 (4): 367–82. https://doi.org/10.1080/00071005.2011.582852 .
Schrape, Jan-Felix. 2018. “Comunidades de código abierto: La institucionalización sociotécnica de la invención colectiva”. En Colectividad y poder en internet , 57–83. Cham: Springer International Publishing. https://doi.org/10.1007/978-3-319-78414-4\4 .
“La evolución de los colaboradores de código abierto: de aficionados a profesionales”. Consultado el 1 de enero de 2025.https://www.redhat.com/en/blog/evolution-open-source-contributors-hobbyists-professionals .
“Participar en comunidades de código abierto”. Consultado el 1 de enero de 2025. https://www.linuxfoundation.org/resources/open-source-guides/participating-in-open-source-communities .
Nadia Eghbal. 2020. Trabajo en público: La creación y el mantenimiento de software de código abierto . San Francisco: Stripe Press.
“Por qué contribuir al código abierto da miedo y cómo contribuir de todos modos Authentik”. Consultado el 1 de enero de 2025. https://goauthentik.io/blog/2024-03-07-why-contributing-to-open-source-is-scary/ .
Cambios en el grupo de trabajo de Navigation2 y se necesita ayuda: ROS de próxima generación. 2021. Discurso de ROS . https://discourse.ros.org/t/navigation2-wg-changes-and-help-wanted/12348 .
“[Nav2] Un tiempo para el cambio - General”. 2021. Discurso ROS . https://discourse.ros.org/t/nav2-un-tiempo-para-el-cambio/30525 .
“Colaborador - Contribuir como empresa - Open Source Stack Exchange”. Consultado el 1 de enero de 2025. https://opensource.stackexchange.com/questions/9763/contributing-as-a-company .
“Proyectos anónimos de código abierto - Jono Bacon”. 2017. https://www.jonobacon.com/2017/04/28/anonymous-open-source-projects/ .
“Intrinsic de Alphabet adquiere la mayoría de Open Robotics - IEEE Spectrum”. Consultado el 24 de enero de 2025. https://spectrum.ieee.org/alphabet-intrinsic-open-robotics-acquisition .
“Preguntas sobre la adquisición intrínseca de OSRC”. ª ROS Discourse . Consultado el 24 de enero de 2025. https://discourse.ros.org/t/questions-about-the-intrinsic-acquisition-of-osrc/28763 .
“Anuncio de la Alianza de Robótica de Código Abierto”. nd Open Robotics . Consultado el 24 de enero de 2025. https://www.openrobotics.org/blog/2024/3/18/announcing-the-open-source-robotics-alliance-osra .
