Documenta tus Principios Rectores
Title
Documenta tus Principios Rectores
Patlet
La explicación habitual de InnerSource como "aplicación de mejores prácticas de open source dentro de una organización" no funciona bien con personas que carecen de experiencia en open source. Como solución, los principios más importantes de InnerSource se documentan y publican ampliamente.
Problema
La organización está intentando implementar InnerSource a gran escala. La iniciativa comenzó entre entusiastas del open source. El objetivo ahora es conseguir la aceptación de personas que carecen de experiencia en open source. Para esa audiencia, el eslogan típico de "aplicar las mejores prácticas de open source" ya no es suficiente para transmitir el mensaje de qué es InnerSource, qué problemas resuelve y qué herramientas utiliza para resolver estos problemas. Como resultado, la adopción de InnerSource en la organización se ralentiza. Los equipos desarrollan ideas divergentes sobre cuáles son los objetivos de InnerSource y cómo implementarlo mejor, lo que genera confusión cuando los contribuidores comienzan a cruzar los límites entre equipos.
Historia
Los primeros experimentos en una organización han demostrado que las mejores prácticas de colaboración en open source pueden ser beneficiosas. El siguiente paso ahora es mover la iniciativa a equipos e individuos que carecen de un profundo conocimiento en open source.
El objetivo ahora es comunicar claramente los objetivos de la iniciativa InnerSource así como un camino definido para lograr los objetivos.
Contexto
InnerSource como término está circulando entre los empleados.
La iniciativa comenzó entre entusiastas del open source.
Resistencias
Los equipos tienen problemas para comunicar exactamente cuáles son los aspectos importantes de InnerSource.
Las personas que carecen de experiencia en open source no entienden lo que significa llevar las mejores prácticas de open source a la organización.
A diario, los equipos que intentan seguir las mejores prácticas de InnerSource tienen dificultades para decidir si lo que están haciendo está en línea con los valores generales de InnerSource.
Solución
Aquellos que impulsan la iniciativa InnerSource en la organización deben ayudar a los equipos e individuos que carecen de un profundo conocimiento en open source y, por lo tanto, tienen una comprensión menos intuitiva de InnerSource.
Se debe proporcionar claridad a los equipos e individuos documentando estas dos áreas:
Propósito - ¿Por qué la organización quiere adoptar InnerSource?
Principios - ¿Qué principios de InnerSource ayudarán a abordar estos desafíos?
Las siguientes secciones proporcionan más detalles sobre ambos, destinados como posibles puntos de partida para documentarlos en su organización.
¿Por qué la organización quiere adoptar InnerSource?
En el pasado, InnerSource ha demostrado ser exitoso para resolver varios problemas comúnmente encontrados en las organizaciones.
Sin embargo, ¿qué desafíos organizacionales espera su organización mejorar utilizando InnerSource?
En lugar de optar por generalizaciones, trate de identificar exactamente las soluciones que coinciden con los desafíos de su organización, preferiblemente con aquellos afectados por el cambio que desea ver.
Algunos desafíos que otros han abordado siguiendo las mejores prácticas de InnerSource:
Reducir los silos de desarrollo causados por una cultura de propiedad excesiva.
Aumentar la velocidad de innovación al reducir el tiempo dedicado a resolver problemas similares fomentando la reutilización saludable del código.
Aumentar la velocidad de desarrollo mediante una mejor colaboración entre equipos.
Resolver dependencias de proyectos/equipos más allá de "esperar" y "crear soluciones alternativas", reduciendo así los cuellos de botella en la ingeniería.
Aumentar la calidad.
Aumentar la felicidad de los empleados.
Aumentar el éxito de las nuevas contrataciones.
Construir documentación accionable.
¿Qué principios de InnerSource ayudarán a abordar estos desafíos?
Una vez que los equipos entienden qué problemas les ayudará a abordar InnerSource, el siguiente paso es explicar qué principios ayudan a abordar estos desafíos.
Basado en principios básicos de desarrollo de open source, las siguientes pautas han demostrado ser exitosas:
(1) El código debe estar alojado de manera transparente dentro de la organización
El código fuente, la documentación y los datos relevantes para el desarrollo del proyecto deben estar disponibles y ser fáciles de encontrar para cualquier persona en la organización.
(2) Contribuciones sobre solicitudes de características
Todos los interesados en un proyecto actúan como posibles contribuidores y son tratados y apoyados como tales. Las contribuciones siguen siendo sugerencias en lugar de requisitos. La coordinación antes de una contribución ayuda a evitar esfuerzos desperdiciados. Los proyectos proporcionan pautas de contribución para evitar fricciones.
(3) Los errores son oportunidades para aprender
Con el trabajo visible en toda la organización, cualquier error es visible para todos. Como resultado, se debe establecer una cultura en la que los errores sean oportunidades para aprender en lugar de fracasos que deben evitarse a toda costa.
(4) Comunicación escrita sobre verbal
Para proyectos que abarcan múltiples equipos, potencialmente con horarios de reuniones divergentes, debe ser posible colaborar de manera asincrónica. El objetivo de los proyectos InnerSource es reclutar nuevos contribuidores. Para eso, los posibles futuros contribuidores deben poder seguir el progreso del proyecto de manera autoservicio con una barrera de entrada muy baja. Si la comunicación relevante para el proyecto ocurre a través de comunicación sincrónica, los argumentos discutidos deben hacerse transparentes en el canal escrito; las decisiones deben finalizarse solo allí. Como efecto secundario, esto lleva a una documentación base pasiva que es muy valiosa para cualquier recién llegado al proyecto.
(5) Permitir que los consejos escritos se acumulen en un archivo persistente y buscable
Toda la comunicación del proyecto, en particular las decisiones tomadas y las discusiones que llevaron a esas decisiones, deben archivarse. Debe ser posible referenciar la comunicación a través de URL estables. La comunicación anterior debe almacenarse de manera que pueda buscarse fácilmente.
Dos advertencias, sin embargo:
Esto no reemplaza la documentación estructurada. Sin embargo, puede servir como punto de partida para recopilar documentación estructurada.
Hay excepciones a la regla de que todo debe estar escrito y accesible para toda la organización: las discusiones relacionadas con personas y las discusiones relacionadas con la seguridad son sensibles y no deben realizarse en público.
(6) Recompensar el Compromiso de Confiabilidad
Todas las contribuciones (por ejemplo, código fuente, documentación, informes de errores, aportes a discusiones, soporte a usuarios, marketing) son bienvenidas y se recompensan. Aquellos que muestran apoyo al proyecto son invitados como Contribuidores de Confianza. Todos los Contribuidores de Confianza de un proyecto se publican.
Contexto Resultante
Los miembros de la organización entienden qué desafíos pueden abordar aplicando las mejores prácticas de InnerSource.
Los miembros de la organización que carecen de experiencia previa en open source entienden los valores y principios básicos de los proyectos InnerSource.
Los miembros de la organización que carecen de experiencia previa en open source pueden verificar sus actividades diarias contra un conjunto de valores comunes establecidos.
Las prácticas de desarrollo de la organización se vuelven más similares a los proyectos de open source, lo que facilita la participación de los miembros de la organización en proyectos de open source.
Instancias Conocidas
Europace AG
GitHub
Robert Bosch GmbH
Europace AG
Los principios de InnerSource enumerados en la sección de Solución anterior se basan principalmente en la experiencia de Europace. Ver detalles (en alemán).
GitHub
Propósito
A menudo en GitHub trabajamos en un modelo donde los equipos contribuyen con características a áreas fuera de su área de responsabilidad. Ejemplos comunes incluyen ingeniería de ventas que contribuye con características para desbloquear una venta, Proyectos Especiales que contribuyen con características urgentemente necesarias y de alto impacto en todo el producto, y un equipo que trabaja en múltiples áreas para entregar una característica.
Principios
En general, los principios descritos en este documento son para evitar aumentar la deuda técnica y la carga de soporte para el equipo responsable. A menudo se presta ayuda a un equipo porque están atrasados debido a los costos de soporte y mantenimiento en su área de responsabilidad y no tienen capacidad para contribuir a la característica. Cualquier nueva característica realizada por otro equipo que aumente esa carga de soporte o deuda técnica significa aún menos tiempo para que el equipo responsable trabaje en nuevas características, por lo que queremos asegurarnos de que se hagan bien.
Al mismo tiempo, nos esforzamos por ser una empresa donde los ingenieros trabajen libremente a través de los límites, y las prioridades comerciales a menudo requieren que contribuyamos a áreas fuera de nuestras áreas principales de propiedad.
Un buen resumen de los principios es dejar el área en tan buen estado o mejor que como la encontraste.
Con eso en mente, aquí están los principios en los que estamos de acuerdo:
Evitar productos mínimos viables (MVP) que acumulen deuda técnica. Está bien lanzar un MVP para obtener comentarios de los clientes, pero el equipo contribuyente debe comprometerse a terminar el conjunto de características. Ejemplos incluyen:
Compromiso de ir más allá del MVP a una solución que satisfaga a la mayoría de los clientes.
Soporte completo para la administración de nuevas características (por ejemplo, soporte en la interfaz de usuario de configuración en lugar de solo hacer una línea de comando).
Características de superficie tanto en la interfaz de usuario como en la API en lugar de solo entregar una API (o viceversa)
Asegurarse de que las características funcionen en entornos de nube y servidor local.
Soporte para el trabajo de características hasta y más allá de su implementación en producción
Coordinar el despliegue incremental
Manejar tickets de soporte
Planificar tiempo para abordar los comentarios de los clientes (características y errores)
Construir características de la manera correcta (no acumular deuda técnica)
Acordar los requisitos y la solución con los equipos de Producto e Ingeniería
Arquitectura y diseño adecuados
Asegurarse de que los datos se almacenen correctamente para evitar migraciones de datos posteriores.
Telemetría adecuada en su lugar
Cobertura de pruebas adecuada en su lugar
Soporte en entornos de producción en la nube y locales (incluida la configuración, configuración, copia de seguridad / restauración, migraciones, etc.)
Errores corregidos
Documentación actualizada
Compromiso
Usamos un modelo de compromiso porque nos gusta establecer qué pasos concretos puede tomar un equipo al contribuir con características a áreas fuera de su área de responsabilidad.
Un modelo de compromiso típico en GitHub se ve así:
Obtener la aprobación del conjunto de características y el plan de implementación del propietario del producto.
Obtener la aprobación del diseño de ingeniería, incluida la dirección de los requisitos no funcionales (telemetría, cobertura de pruebas, pruebas y soporte en múltiples entornos) del propietario de ingeniería (típicamente gerente de ingeniería y director).
Realizar revisiones de código a lo largo del camino, junto con la revisión de cualquier requisito nuevo o cambiado.
Robert Bosch GmbH
Propósito
Fomentar la colaboración, el aprendizaje y la innovación es el enfoque principal de la iniciativa InnerSource de Bosch (BIOS).
Principios
Para ello, Bosch aplicó los siguientes principios:
Apertura: Reducimos las barreras de entrada a las comunidades BIOS tanto como podemos.
Transparencia: Somos radicalmente transparentes y compartimos nuestros productos de trabajo, nuestra comunicación y nuestra toma de decisiones con todos los asociados en la empresa.
Voluntariedad: La decisión de unirse y contribuir a una comunidad BIOS se deja a cada asociado. Los asociados deben trabajar dentro de BIOS porque están intrínsecamente motivados, no porque su gerente se lo haya dicho.
Autodeterminación: Las comunidades BIOS son libres de elegir en qué trabajar, cuándo trabajar y qué herramientas y procesos utilizar para trabajar.
Meritocracia: El poder se otorga a los miembros del proyecto BIOS en función de sus méritos, es decir, en función de la calidad y cantidad de sus contribuciones.
Los principios de Apertura, Transparencia y Voluntariedad ayudaron a crecer comunidades diversas de asociados intrínsecamente motivados. La Meritocracia ha demostrado ser una motivación efectiva para hacer grandes contribuciones. La Autodeterminación permitió a las comunidades usar su tiempo limitado para contribuciones de la manera más efectiva y eficiente.
Estado
Estructurado
Autores
Isabel Drost-Fromm
Georg Grütter
Agradecimientos
Zack Koppert - por compartir el enfoque de GitHub en las Instancias Conocidas
Alias
Principios InnerSource Explícitos
Histórico de Traducciones
2025-04-03 - Traducción Oscar Lobaton S.
2025-04-03 - Traducción Roman Martin Gil
Última actualización
¿Te fue útil?
