InnerSource es una Mentira - Una Respuesta a Conceptos Erróneos Comunes
Cuando buscas “InnerSource” en YouTube, uno de los primeros resultados que probablemente encuentres es un video que afirma que “InnerSource es una mentira.”
(enlace: https://youtube.com/shorts/53jEP3mPP3E)
Este punto de vista representa una trampa típica en la que muchas personas caen cuando aprenden por primera vez sobre InnerSource.
Quiero usar este video como un estudio de caso para explicar qué tipo de conclusiones engañosas promueve. Este es un error que he cometido en el pasado también, y es una trampa en la que muchas personas que no han explorado profundamente este campo pueden caer fácilmente. Por eso quiero examinar esto con autorreflexión y ayudar a otros a encontrar el camino correcto desenredando estas trampas.
El Primer Concepto Erróneo: “Usa React Para Que Otros Puedan Contribuir” #
Permíteme primero desentrañar el argumento en este caso. El video sugiere usar React para aplicaciones internas “Usa React porque otras personas pueden contribuir a él.” Este tipo de razonamiento rara vez se escucha en discusiones reales de InnerSource.
should you use react HTMX or solid or something for your company’s internal application now a lot of people what you’re going to hear is use react so other people can contribute to this
Este argumento puede diseccionarse en tres problemas clave:
- Malentendido fundamental de lo que InnerSource realmente significa
- Elegir el dominio equivocado para la aplicación de InnerSource
- Confundir perspectivas individuales versus de equipo
Lo Que InnerSource Realmente Significa #
InnerSource se trata de practicar principios de código abierto dentro de una empresa. No se trata solo de “contribuir” o “recibir contribuciones.”
La mayoría de las personas que interactúan con código abierto son simplemente “usuarios.” Algunos son solo consumidores, otros reportan errores, y solo una pequeña fracción realmente envía pull requests. InnerSource aplica los aprendizajes del código abierto internamente para crear organizaciones que sean abiertas, ampliamente accesibles, con toma de decisiones transparente, y relaciones de equipo construidas sobre confianza a través de propiedad y mentoría. Esto crea una cultura de transparencia y colaboración.
Esto es lo que significa “practicar código abierto internamente” - no se trata solo de “recibir pull requests.” Los pull requests son meramente un resultado de esta cultura, no el objetivo principal.
Un Dominio Menos Óptimo para la Aplicación de InnerSource #
El segundo problema es que este argumento se desarrolla en un dominio donde InnerSource y el código abierto enfrentan desafíos particulares.
Si quieres “recibir pull requests” o “hacer que muchas personas usen tu código para mejorar la calidad,” eso podría estar limitado por la naturaleza de tu producto. Es claro que compartir “componentes de alta dependencia” o herramientas a nivel de plataforma crearía más valor que aplicaciones de usuario final. Aunque los equipos alineados con flujos aún deberían adoptar prácticas de código abierto cuando sea beneficioso, las dinámicas de colaboración difieren significativamente.
En mi experiencia trabajando con empresas corporativas, usar InnerSource para iniciativas a nivel de proyecto donde los usuarios finales son “no ingenieros” presenta desafíos únicos. ¿Por qué? Porque en última instancia, estos productos necesitan servir las necesidades de “usuarios finales” o “usuarios de negocio” que pueden carecer de habilidades de desarrollo y canales de comunicación directa con equipos de desarrollo. Esto crea requisitos complejos e individualizados y tiempos de comunicación más largos.
Las implementaciones de InnerSource tienden a funcionar relativamente bien cuando se aplican a bibliotecas compartidas, componentes de plataforma, herramientas de desarrollo y código de infraestructura—áreas donde los “usuarios” son principalmente otros desarrolladores que pueden contribuir significativamente y beneficiarse de prácticas de desarrollo colaborativo.
Aunque aplicar prácticas de InnerSource a aplicaciones orientadas al usuario puede traer beneficios valiosos como transparencia y mejor seguimiento de problemas (lo cual por sí solo lo hace valioso).
Perspectiva Individual vs. de Equipo #
El tercer problema se refiere a si “tú” se refiere a un individuo o a un equipo.
Es importante notar que InnerSource no se trata necesariamente de esperar a que alguien contribuya a “tu proyecto personal” dentro de una empresa. Cuando se aplica InnerSource, podría haber casos donde las personas contribuyan a proyectos desarrollados durante el 20% del tiempo, como las grandes empresas tecnológicas, pero ese no es necesariamente el enfoque principal.
InnerSource se introduce y mantiene principalmente porque genera ROI a través de reducción de costos, evitando reinventar la rueda, creando sinergias, aseguramiento de calidad, y removiendo sobrecarga de comunicación de la toma de decisiones jerárquica. Esto típicamente involucra bibliotecas internas compartidas, componentes de ventaja competitiva propietaria, o cosas con altas dependencias que son nicho dentro de la empresa. Y estos “beneficios de negocio” típicamente fluyen de vuelta a “operaciones de equipo” en la mayoría de los casos. En última instancia, todo se trata del ROI para equipos y organizaciones. Si no pensamos en equipos, alguien te impedirá contribuir a proyectos. Necesitas justificar tu ROI ya sea a corto o largo plazo.
Lo que es único sobre InnerSource es que fundamentalmente se trata de colaboración equipo a equipo. Aquí es donde la mayoría de las implementaciones terminan finalmente. No se trata necesariamente de individuos contribuyendo aleatoriamente a proyectos personales convenientes. Típicamente se implementa a través de relaciones de equipo anfitrión y equipo invitado, donde los equipos invitados acompañan con partes mantenidas por equipos anfitriones. La mayoría de las empresas tienen empleados con roles y responsabilidades definidos, y la colaboración tiende a suceder dentro de estas estructuras.
Por lo tanto, InnerSource es particularmente efectivo cuando se establecen relaciones entre equipos de plataforma y equipos alineados con flujos (equipos invitados y equipos anfitriones). La co-creación activa entre equipos alineados con flujos o individuos es más incierta para tener éxito naturalmente.
Criticar todo InnerSource basándose en escenarios que es improbable que funcionen no tiene sentido lógico.
El Segundo Concepto Erróneo: “Nunca Sucede en Empresas Reales” #
because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source
En realidad, esto está sucediendo. Los estudios de caso lo prueban. Punto.
El Tercer Concepto Erróneo: “99.69% de los Proyectos InnerSource Fallarán” #
99.69% a lie you’re going to build the entire project by yourself when it goes down people are going to look to you
Esto podría ser correcto dependiendo de cómo definas “InnerSource.” Como se mencionó anteriormente, InnerSource no se trata de “recibir contribuciones de PR.”
Sin embargo, hay tres puntos importantes a considerar:
- InnerSource especialmente se aplica a componentes estratégicos - no es requerido para todos los componentes
- Los beneficios se extienden más allá de contribuciones activas
- El código abierto tiene el mismo problema de “tasa de falla”
InnerSource es una Estrategia Corporativa #
Cuando las personas piensan en InnerSource, a veces imaginan ideas radicales como “compartir todo el código dentro de la empresa” o “todos contribuyendo a todo.” Podrían visualizar cientos de repositorios compartidos dentro de una empresa con todos intercambiando activamente contribuciones. Como el código abierto siendo una estrategia para empresas, InnerSource también es una estrategia corporativa con prioridades. Las empresas comparten “lo que vale la pena compartir” primero.
Por lo tanto, el número real de bases de código donde el código fluye activamente entre equipos y ocurre colaboración vibrante entre equipos es relativamente pequeño. Esto podría ser de hecho porcentajes de un solo dígito. Sin embargo, incluso sin colaboración activa entre equipos, muchos proyectos pueden beneficiarse de ser abiertos y transparentes. En este sentido de InnerSource, las empresas a menudo pueden compartir valor a través de muchos más casos.
Aunque InnerSource incluye contribuciones individuales, se enfoca principalmente en colaboración equipo a equipo. Por lo tanto, lo que se comparte a través de InnerSource tiende a ser relativamente nicho dentro de las empresas, o elementos específicos de propósito como distribuciones Linux bifurcadas para necesidades particulares. O podría ser simplemente cultura de desarrollo similar al código abierto, como cuando GitHub comparte código Ruby on Rails a través de todos los empleados.
Cuando condicionamos esta discusión de porcentajes en InnerSource que colabora activamente y se mantiene como requisitos comunes, el porcentaje puede ser de hecho relativamente bajo. Sin embargo, pequeñas colaboraciones como pull requests de documentación o cambios menores de configuración (enviando parches pequeños) entre equipos invitados y equipos de plataforma/anfitriones suceden relativamente frecuentemente. Cuando incluyes estas micro-colaboraciones y beneficios de transparencia que previenen esfuerzos duplicados, estos números aumentan significativamente.
El Código Abierto Tiene el Mismo “Problema” #
Por otro lado, si lo definimos de esa manera, el código abierto también sería una “mentira.” Porque “99.69% de los proyectos de código abierto fallarán.” La mayoría del código publicado como código abierto no recibe contribuciones. Pero nadie dice que “el código abierto es una mentira” por eso. Las personas persiguen el código abierto porque hay beneficios más allá de recibir contribuciones.
De nuevo, “recibir contribuciones” no es el único valor de InnerSource. Y lo mismo se aplica al valor del código abierto también.
Los Beneficios Reales de la Transparencia #
Mantener el código interno abierto en lugar de oculto - en GitHub, arquitectos o ingenieros de soluciones en el equipo de ingresos podrían ser capaces de examinar código fuente para encontrar información relevante, potencialmente encontrando detalles muy cercanos a solicitudes de clientes, facilitando conversaciones de soporte más fluidas, y extrayendo información más precisa de problemas. Vivo en Tokio, y a veces es más rápido simplemente mirar el código Ruby para verificar la implementación, o ir a problemas para verificar el trasfondo de los cambios, en lugar de esperar a que el equipo de producto basado en SF despierte para preguntar sobre implementación de los cambios y su trasfondo.
Usando el comando git blame, puedes identificar a los “verdaderos” interesados del código y hacer preguntas sobre el trasfondo de las decisiones.
No hace falta decir que lo mismo se aplica a otros equipos de desarrollo. Tener información fácilmente disponible sobre componentes que podrían crear dependencias claramente reduce la sobrecarga de comunicación.
InnerSource se trata de practicar principios de código abierto internamente. InnerSource no se trata solo de enviar pull requests de ida y vuelta - se trata de asegurar transparencia y obtener beneficios a través de colaboración estilo código abierto. Estos beneficios se extienden mucho más allá del pequeño porcentaje de repositorios mantenidos activamente a beneficios de implementación cultural más amplios.
El Cuarto Concepto Erróneo: “Te Llamarán de Vuelta Cuando Te Vayas” #
“when you leave the company they’re going to send you a message 6 months later asking you questions or seeing if you would like to contract with them to upgrade your application there is no such thing as innersourcing”
Los recursos a veces quedan sin mantenimiento, pero esta no es una crítica apropiada de InnerSource en sí - es crítica de fallar en implementar InnerSource apropiadamente. Esta no es crítica de InnerSource, sino crítica de carecer de cultura de mantenimiento donde nadie mantiene el código. Esto resulta de fallar en implementar InnerSource apropiadamente o no considerarlo en absoluto - el resultado de carecer de propiedad.
La Analogía de DevOps #
Esta es crítica de fallar en hacer InnerSource, no crítica de InnerSource en sí. A veces esto confunde la lógica. Para poner esto en términos de DevOps: es como decir “las empresas terminan adoptando ciclos de revisión lentos de varios meses o auditorías, o agregando procesos para decisiones de lanzamiento, así que los lanzamientos se vuelven trimestrales o solo dos veces al año. Por lo tanto DevOps, que afirma permitir lanzamientos rápidos, no es bueno.” Eso no es porque la metodología DevOps sea mala, sino simplemente porque “hubo casos donde DevOps no pudo ser implementado.”
Romper procesos de negocio es extremadamente difícil, y muchas empresas dijeron que DevOps era imposible. Pero incluso cuando las personas pensaban que era imposible, hubo pioneros valientes que trabajaron duro para cambiar la cultura y lograron DevOps. Lo mismo puede suceder con InnerSource.
El Quinto Concepto Erróneo: “Debes Poseer Todo al 100%” #
you own it 100% (which implies: InnerSource where you don’t own 100% is impossible)
“InnerSource significa abandonar la propiedad del código” está mal. InnerSource en realidad requiere que los equipos posean código. Este es un error común. Esto es como personas que quieren abandonar la responsabilidad de mantenimiento y dicen “hagámoslo código abierto.” Eso no funciona.
Propiedad Individual vs. de Equipo - ¿Es InnerSource Propiedad Fuerte de Código? #
Primero, ¿este “Tú” es individual o plural? Aunque los individuos podrían estar listados como archivo CODEOWNERS en organizaciones, los equipos en última instancia tienen responsabilidad por el código. Contextualmente, es probable que esté hablando de Propiedad Fuerte de Código. Pero esto no es bueno cuando se considera el mantenimiento organizacional. Porque los empleados podrían renunciar.
InnerSource no es Propiedad Fuerte de Código. Como mínimo, múltiples personas necesitan compartir responsabilidad. Habiendo dicho eso, reconozco que la Propiedad Fuerte de Código puede emerger a corto plazo, y en las etapas tempranas de un proyecto, la voluntad individual fuerte podría naturalmente llevar a tales arreglos, pero si quieres lograr éxito a largo plazo, es necesario delegar autoridad para que la organización pueda manejar el mantenimiento colectivamente.
Tipos de Propiedad de Equipo - ¿Es InnerSource Propiedad Colectiva de Código? #
Este tipo de argumento podría a veces referirse a Propiedad Colectiva. En este caso, el argumento también parece sugerir que InnerSource significa propiedad colectiva, pero eso es en realidad diferente. InnerSource no es Propiedad Colectiva de Código InnerSource involucra equipos anfitriones manejando finalmente el mantenimiento. InnerSource es Propiedad Débil de Código. Así que mientras la responsabilidad de mantenimiento es 100% correcta, decir “debes poseer 100% e InnerSource es diferente” es completamente ilógico. Esta es en realidad una opinión incorrecta.
Como Martin Fowler famosamente argumentó sobre la propiedad de código, hacer que todos posean código 100% (propiedad colectiva) a veces crea situaciones donde nadie toma responsabilidad. Eso es muy problemático - la responsabilidad se vuelve poco clara y los proyectos finalmente fallan.
Modelo de Propiedad Débil de Código #
En Propiedad Débil de Código, los mantenedores existen, los equipos anfitriones mantienen proyectos, y partes específicas podrían traer committers/mantenedores confiables de otros equipos. Alguien podría contribuir, alguien podría mantener, pero no 100% por “ti” o “tu equipo” - podría ser bastante diferente. Por ejemplo, 98% del código podría ser poseído por tu equipo, mientras que 2% podría ser poseído por otros equipos.
En este caso, recuerda que incluso si los individuos son asignados como propietarios de código en organizaciones, los equipos en última instancia tienen responsabilidad por el código. Los equipos deberían poseerlo, y no olvides este punto importante.
El Sexto Concepto Erróneo: “Alguien Te Dejará Caer 7000 Líneas” #
Every now and then there will be a sufficiently motivated coworker who’s really great and do like a 7,000 line update no explanation but don’t ever fall into this idea that choosing anything for an internal app that you are going to be working on
Tener pull requests de 7000 líneas apareciendo repentinamente es en sí mismo una falla en introducir cultura InnerSource - no es algo que sucede por hacer InnerSource. Este caso podría preocuparse de que introducir InnerSource haga que tal colaboración suceda, pero eso está completamente mal.
El Problema Real #
Este argumento representa fallar en implementar cultura InnerSource y prácticas colaborativas, no InnerSource en sí. Las implementaciones de 7000 líneas son casos muy limitados. Esto representa falla de cultura de colaboración donde 7000 líneas se envían como pull requests repentinamente sin ninguna notificación - la organización debería arreglar este problema de cultura fundamental, que es pre-InnerSource.
Si quieres prevenir esto, hay una solución. ¡Fomenta la cultura InnerSource dentro de tu organización :)
La Realidad: Lo Que InnerSource Realmente Es #
InnerSource es implementación cultural - usar prácticas de colaboración de código abierto para disfrutar varios beneficios que el código abierto recibe a través de colaboración. El propósito final de InnerSource no es solo recibir contribuciones (pull requests), sino que incluye solicitudes de características a través de problemas, coordinación de soporte, y varios otros beneficios, más transparencia en toma de decisiones y promoción cultural práctica.
Por lo tanto, rechazo definitivamente la afirmación de que “implementar mejores prácticas de InnerSource para obtener pull requests es una mentira.”
Entendiendo la Realidad de Contribución #
“Nobody ever is going to contribute”
En colaboración de código abierto, los contribuyentes son de hecho una fracción diminuta. De 1000 usuarios, tal vez la gran mayoría son solo usuarios, 20 podrían enviar problemas o solicitudes de características, 5 podrían enviar pull requests, y tal vez solo uno se convierte en mantenedor.
De nuevo, las mejores prácticas de InnerSource no harán que todas las 1000 personas contribuyan. InnerSource ayuda a inducir tal colaboración, pero finalmente apunta a romper silos empresariales, mejorar colaboración que está obstaculizada por restricciones organizacionales tradicionales, reducir tiempos de espera de silos de información, y optimizar asignación de recursos organizacionales usando prácticas de código abierto.
Conclusión #
Aunque los argumentos en este caso tocan algunos desafíos reales, están basados en malentendidos comunes que muchas personas encuentran cuando aprenden por primera vez sobre InnerSource. Estas son trampas bien conocidas en la comunidad, y es comprensible cómo alguien podría llegar a estas conclusiones sin exploración más profunda del campo.
La perspicacia clave es que InnerSource no se trata de forzar prácticas de código abierto en un marco rígido. En cambio, se trata de regresar a la pregunta fundamental: ¿qué podemos aprender del código abierto? Al examinar el código abierto a través de una lente más amplia, podemos adaptar mejor estos principios internamente.
Puedes unirte a esta conversación y traer perspectivas frescas. Ya sea que quieras construir sobre esta discusión, explorar detalles de implementación más específicos, o incluso desafiar estos argumentos completamente - todos los enfoques son bienvenidos. Lo que más importa es mantener esa perspectiva amplia sobre los aprendizajes de código abierto y cómo se traducen a contextos organizacionales internos.
Para información comprensiva sobre InnerSource, recomiendo revisar la Fundación InnerSource Commons. Dan la bienvenida a puntos de vista diversos y diálogo continuo sobre cómo los principios de código abierto pueden crear valor dentro de las organizaciones.
