## 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:

1. **Propósito** - ¿Por qué la organización quiere adoptar InnerSource?
2. **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:

1. Esto no reemplaza la documentación estructurada. Sin embargo, puede servir como punto de partida para recopilar documentación estructurada.
2. 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](../../../patterns/2-structured/trusted-committer.md).
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](https://tech.europace.de/post/europace-inner-source-prinzipien/) (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.

![Principios BIOS](../../../assets/img/bios-principles.png)

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.](https://github.com/ovas04)
- **2025-04-03** - Traducción [Roman Martin Gil](https://github.com/rmarting)
