¿Quieres mejorar este libro? ¡Eso es increíble!

El libro de InnerSource Patterns en sí es un proyecto de código abierto, y da la bienvenida a cualquier forma de contribución. ¡Nada es demasiado pequeño!

No importa si deseas ayudarnos a corregir la gramática/ortografía, mejorar el diseño o contribuir con patrones completamente nuevos basados en las experiencias de InnerSource que has tenido en tu lugar de trabajo. ¡Nos encanta todo eso! :)

Si nunca has hecho una contribución a un proyecto de código abierto antes, debes saber que la comunidad de InnerSource Patterns es un grupo de personas amigables y, con eso, un lugar seguro para intentarlo.

Antes de comenzar

Las fuentes de los InnerSource Patterns y este libro se mantienen en un repositorio en GitHub. Por lo tanto, necesitarás una cuenta de usuario de GitHub para hacer ediciones y sugerencias a este libro. Si aún no tienes una, dirígete a github.com y crea una cuenta de forma gratuita.

Diferentes formas de contribuir

Aquí hay algunas formas en las que puedes contribuir:

1. corregir errores ortográficos, de formato u otros fallos que notes en este libro

2. mejorar el contenido de un patrón existente (por ejemplo, agregando una breve descripción de cómo estás utilizando un patrón como una Instancia Conocida)

3. contribuir con un nuevo patrón, describiendo cómo has superado desafíos relacionados con InnerSource en tu organización

Para los puntos (1) y (2), simplemente puedes hacer clic en el enlace Edit on GitHub que ves en la parte superior de cada página de este libro. Esto te llevará directamente al archivo respectivo en nuestro repositorio de GitHub, donde puedes sugerir tus cambios.

Para el punto (3) necesitas clonar el repositorio de InnerSourcePatterns, y agregar un nuevo archivo con tu patrón sugerido. Al hacer contribuciones más grandes a este libro, por favor revisa nuestro CONTRIBUTING.md y también nuestro Manual del Contribuidor.

Licencia de Contribuciones

El contenido de este repositorio está licenciado bajo CC-BY-SA-4.0. Al contribuir a este repositorio, nos otorgas (y a todos los demás, para el caso) el derecho de usar tu contribución de acuerdo con esa licencia.

Title

Casos de uso del Gestor de Tareas (Issue Tracker)

Patlet

El equipo anfitrión de InnerSource no logra hacer transparentes no solo los planes y el progreso sino también el contexto de los cambios. Esto se resuelve aumentando los casos de uso del gestor de tareas del proyecto para también servir como herramienta de lluvia de ideas, discusión de implementación y diseño de funcionalidades.

Problema

Un equipo desarrolla un componente del que dependen muchos equipos en la organización. Utiliza un gestor de tareas (issue tracker) estándar para rastrear errores abiertos y solicitudes de características. Sin embargo, el contexto en cada entrada es muy limitado. Como resultado, los posibles contribuyentes no tienen forma de saber de qué cambio exactamente está hablando cada issue.

Contexto

El tooling del proyecto InnerSource está todo configurado. Sin embargo, el gestor de tareas del proyecto se utiliza principalmente para compartir el progreso. En los proyectos de InnerSource hay muchos más casos de uso que un gestor de tareas puede utilizar para facilitar la comunicación remota y asincrónica.

Resistencias

• A los contribuyentes les gustaría entender si la característica que les falta ya está en la hoja de ruta. Sin embargo, con mucho contexto faltante en los problemas, es imposible decidir si los problemas existentes coinciden con las necesidades del equipo contribuyente.

• Como resultado, se abren muchos problemas duplicados que el equipo anfitrión tiene que manejar.

• Debido a la falta de contexto en los issues abiertos, los contribuyentes no pueden ayudar al equipo anfitrión a implementar tareas más sencillas ya disponibles. Como resultado, mucho trabajo permanece en manos del equipo anfitrión.

• Con un fuerte enfoque en la comunicación verbal, es imposible discernir después de un par de meses o años por qué se eligió implementar una característica en particular. Como resultado, las refactorizaciones, en particular la simplificación del componente, se convierten en un ejercicio de arqueología de proyectos y de recoger ideas de personas que recuerdan lo que se discutió.

Solución

Adopte la filosofía de 'priorizar lo escrito sobre lo verbal' no solo en el desarrollo de software, sino también durante la fase de planificación de nuevas características:

• Para errores, características planificadas e ideas de características, cree problemas separados. En cada uno de ellos, incluya tanta información como sea posible para que los posibles contribuyentes externos puedan entender el contexto. Idealmente, en particular para cambios más fáciles, incluya suficiente información para que los contribuyentes externos apoyen al equipo anfitrión implementando la funcionalidad en cuestión.

• Potencialmente use el gestor de tareas como un canal para hacer preguntas. Esto es particularmente útil si carece de otras fuentes de comunicación para abordar las preguntas de los usuarios.

• Haga uso de etiquetas y categorías para distinguir problemas utilizados para diferentes propósitos.

• Para iniciar una sesión de lluvia de ideas de manera asincrónica, abra un issue para recopilar ideas. Cuando la discusión comience a calmarse, resuma los puntos identificados en este issue en un documento separado. Publíquelo para revisión como un pull request para profundizar en los puntos individuales que aún necesitan aclaración. El documento resultante se puede utilizar para publicar los resultados en otros canales apropiados, así como para referencia futura.

• La mayoría de las implementaciones de gestor de tareas permiten plantillas de problemas. Utilice estas no solo para recopilar información comúnmente necesaria para informes de errores, sino también incluya pistas sobre qué tipo de información se necesita para los otros tipos de uso.

Contexto Resultante

• Hacer más uso del gestor de tareas del proyecto para la comunicación permite a los contribuyentes externos seguir y tomar mejores decisiones sobre qué contribuir.

• Un enfoque en la comunicación escrita estructurada permite a los miembros del equipo anfitrión participar de forma remota.

• Comunicarse de manera consistente por escrito significa que la documentación pasiva sobre decisiones del proyecto se acumula como un subproducto en lugar de necesitar atención adicional.

• Utilizar consistentemente canales de comunicación públicos lleva a que más personas sigan una discusión. Esto significa que hay más personas conocedoras que pueden responder preguntas, opinar sobre problemas abiertos o señalar fallos en características planificadas que de otro modo se encontrarían mucho más tarde.

• Mover las discusiones a un medio de discusión público crea una oportunidad para que los posibles futuros contribuyentes observen, sigan, se sientan cómodos y aprendan las formas del proyecto mucho antes de que tengan la primera necesidad de involucrarse.

Instancias Conocidas

• Europace AG - Ver publicación en el blog Casos de Uso del Gestor de tareas

Autores

Isabel Drost-Fromm

Estado

Estructurado

Histórico de Traducciones

• 2025-04-03 - Traducción Oscar Lobaton S.

• 2025-04-03 - Traducción Roman Martin Gil

• Introducción

• Tabla de Contenidos

• Explorar Patrones

• Contribuir a este libro

Patrones

• Casos de uso del Gestor de Tareas (Issue Tracker) - El equipo anfitrión de InnerSource no logra hacer transparentes no solo los planes y el progreso sino también el contexto de los cambios. Esto se resuelve aumentando los casos de uso del gestor de tareas del proyecto para también servir como herramienta de lluvia de ideas, discusión de implementación y diseño de funcionalidades.

• Colaborador Contratado - Los colaboradores que desean contribuir a InnerSource son desalentados por su gerencia directa. La solución se proporciona mediante contratos y acuerdos formales.

• Comenzar como Experimento - Inicia tu iniciativa InnerSource como un experimento con tiempo limitado para facilitar que los gerentes no familiarizados con InnerSource respalden y apoyen la iniciativa.

• Comité de Revisión - El modelo de trabajo InnerSource es un cambio radical respecto a los enfoques más tradicionales, tanto para desarrolladores como para gerentes. Al establecer un comité de revisión como puente entre la iniciativa InnerSource y todos los gerentes senior de las unidades de negocio participantes, es más probable que estos últimos se familiaricen con la iniciativa y la apoyen, ya que les proporciona cierto nivel de supervisión y control sin fomentar la microgestión.

• Documenta tus Principios Rectores - 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.

• Documentación Base Estándar - Los nuevos contribuidores a un proyecto InnerSource tienen dificultades para identificar quién mantiene el proyecto, en qué trabajar y cómo contribuir. Proporcionar documentación en archivos estándar como README.md/CONTRIBUTING.md/COMMUNICATION.md permite un proceso de autoservicio para nuevos contribuidores, permitiéndoles encontrar respuestas a las preguntas más comunes por sí mismos.

• Equipo Central (Core Team) - Incluso cuando un proyecto InnerSource es ampliamente necesario, las contribuciones y el uso pueden verse obstaculizados porque el proyecto es difícil de manejar. Establece un equipo central dedicado a ocuparse de los elementos fundamentales del proyecto. Su trabajo permite que los contribuyentes agreguen y utilicen las funciones que aportan valor a sus escenarios.

• Extensiones para un Crecimiento Sostenible - Un proyecto InnerSource está recibiendo demasiadas contribuciones, haciendo difícil su mantenimiento. Al ofrecer un mecanismo de extensiones fuera del proyecto principal, los mantenedores permiten escalar las capacidades del proyecto con un costo y mantenimiento mínimos.

• Garantía de 30 Días - Al aceptar contribuciones externas, es natural que un equipo tenga cierta aversión a asumir la responsabilidad de código escrito por otros. A través de la Garantía de 30 Días, el equipo contribuyente se compromete a proporcionar correcciones de errores al equipo receptor, lo que aumentará el nivel de confianza entre ambos equipos y hace más probable que se acepten las contribuciones.

• Grupo de Soporte - ¿Qué sucede si un equipo o individuo deja de mantener un proyecto InnerSource? Mantén el proyecto activo formando un grupo de personas interesadas.

• Herramientas de Comunicación - Los usuarios de un proyecto InnerSource tienen dificultades para obtener ayuda y contactar con el equipo anfitrión. Mediante el uso consistente de herramientas de comunicación asincrónica, el proyecto hace que las discusiones sean visibles, archivadas y buscables, lo que conduce a un mejor nivel de soporte para los usuarios.

• Licencia InnerSource - Dos entidades legales que pertenecen a la misma organización quieren compartir código fuente entre sí pero están preocupadas por las implicaciones en términos de responsabilidades legales o contabilidad entre empresas. Una Licencia InnerSource proporciona un marco legal reutilizable para compartir código fuente dentro de la organización. Esto abre nuevas opciones de colaboración y hace explícitos los derechos y obligaciones de las entidades legales involucradas.

• Líder de Comunidad Dedicado - Selecciona personas con habilidades tanto de comunicación como técnicas para liderar las comunidades y asegurar el éxito al iniciar una iniciativa InnerSource.

• Mercado de Gigs - Establece un mercado creando un sitio web interno donde se publiquen necesidades específicas de proyectos InnerSource como "Gigs" con requisitos explícitos de tiempo y habilidades. Esto permitirá a los gerentes comprender mejor el compromiso de tiempo de sus empleados y los beneficios profesionales, aumentando así la probabilidad de obtener aprobación para realizar contribuciones InnerSource.

• Modelo de Madurez - Los equipos han comenzado a adoptar InnerSource. La práctica se está expandiendo a múltiples departamentos. Sin embargo, la comprensión de lo que constituye un proyecto InnerSource varía. La solución es proporcionar un modelo de madurez que permita a los equipos realizar una autoevaluación y descubrir patrones y prácticas que aún no conocen.

• Portal InnerSource - Los contribuidores potenciales no pueden descubrir fácilmente proyectos InnerSource que les interesen. Al crear un sitio web en la intranet que indexe toda la información disponible de proyectos InnerSource, permitirás que los contribuidores aprendan sobre proyectos que podrían interesarles y que los propietarios de proyectos InnerSource atraigan una audiencia externa.

• Proceso Estándar de Publicación - Los equipos pueden dudar en adoptar un proyecto InnerSource si no están seguros de su madurez. Para abordar esto, las notas de versión consistentes y los artefactos publicados son cruciales. Estas prácticas demuestran una fuerte dedicación al proyecto, generando confianza y asegurando a los usuarios un compromiso continuo con un software sostenible y bien gestionado.

• Puntuación de Actividad del Repositorio - Los contribuidores potenciales quieren encontrar proyectos InnerSource activos que necesiten su ayuda. Al calcular una puntuación de actividad del repositorio para cada proyecto, se puede crear una lista clasificada de proyectos (por ejemplo, en el Portal InnerSource), para que los contribuidores potenciales puedan determinar más fácilmente a qué proyecto quieren contribuir.

• Reconocimiento a los Participantes - Cuando recibes una contribución InnerSource, es importante agradecer al contribuidor por su tiempo y esfuerzo. Expresar tu gratitud no solo reconoce efectivamente la contribución sino que también genera mayor compromiso del contribuidor y otros. Reconocer las contribuciones positivas de los contribuidores a tu proyecto InnerSource motiva a estos contribuidores (y sus gerentes) a continuar invirtiendo en el esfuerzo.

• Requerimientos Comunes - El código común en un repositorio compartido no satisface las necesidades de todos los equipos de proyecto que desean utilizarlo; esto se resuelve mediante la alineación de requerimientos y la refactorización.

• Servicio vs Librería - Los equipos en un entorno DevOps pueden mostrarse reacios a trabajar a través de los límites del equipo en bases de código comunes debido a la ambigüedad sobre quién será responsable de responder ante la interrupción del servicio. La solución es entender que, en muchos casos, se puede desplegar el mismo servicio en entornos independientes con rutas de escalamiento separadas para manejar interrupciones del servicio, o bien extraer gran parte del código compartido en una librería y colaborar en ella.

• Toma de Decisiones Transparente Entre Equipos usando RFCs - Los proyectos InnerSource que buscan alcanzar altas tasas de participación y tomar las mejores decisiones posibles para todos los involucrados. Por ello necesitan encontrar formas de crear sistemas participativos a lo largo de todo el ciclo de vida del software. La publicación de documentos internos de Solicitud de Comentarios (RFC-Request for Comments) permite discusiones desde el inicio del proceso de diseño y aumenta las probabilidades de construir soluciones con un alto grado de compromiso de todas las partes involucradas.

• Trusted Committer - Muchos proyectos InnerSource se encontrarán en una situación donde reciben constantemente retroalimentación, funcionalidades y correcciones de errores de los contribuidores. En estas situaciones, los mantenedores del proyecto buscan formas de reconocer y recompensar el trabajo del contribuidor más allá de las contribuciones individuales.

• Valoración de Proyectos Transversales - Es difícil demostrar el valor de los proyectos InnerSource cross-team que no proporcionan un impacto directo en los ingresos de la empresa. Aquí hay una forma basada en datos para representar tu proyecto que articula y amplifica su valor.

Apéndice

• Plantilla de Patrones

• Glosario

• Extras

  • Plantilla de README

  • Plantilla de CONTRIBUTING

  • Plantilla de COMMUNICATION

  • Plantilla de RFC

Recursos

• Este libro en GitHub

• InnerSource Commons

Title

Colaborador Contratado

Patlet

Los colaboradores que desean contribuir a InnerSource son desalentados por su gerencia directa. La solución se proporciona mediante contratos y acuerdos formales.

Problema

Contexto

Una gran corporación ha iniciado una iniciativa InnerSource. Los objetivos principales de la iniciativa son aumentar la eficiencia del desarrollo de software distribuido y fomentar la innovación permitiendo que cada colaborador contribuya voluntariamente a proyectos InnerSource, independientemente del tema y la unidad de negocio.

Sin embargo, la alta dirección aún no ha empoderado ni incentivado a los gerentes de nivel medio para permitir o incluso motivar a sus empleados a participar en actividades de InnerSource interdivisionales. Además de eso, la capacidad de cada colaborador generalmente se asigna a proyectos que no son de InnerSource para el 100 % de su tiempo de trabajo. La colaboración interorganizacional aún no es la norma y los gerentes de línea generalmente no tienen objetivos fuera de su propia organización. Se espera que las contribuciones a los proyectos de InnerSource se realicen durante el horario laboral, no durante el tiempo libre.

Resistencias

• Los gerentes son responsables de los resultados de sus unidades de negocio. Permitir que su personal participe en actividades de InnerSource, lo que podría hacer que dediquen tiempo a contribuciones fuera de su unidad de negocio, reduce efectivamente la capacidad de su unidad. Esto probablemente dificultará que los gerentes alcancen o superen sus objetivos.

• Los gerentes de línea y HR, por defecto, juzgarán el desempeño de sus subordinados en función de los objetivos de sus unidades de negocio, que pueden no estar alineados con los objetivos de la comunidad InnerSource.

• Cuanto menos apoyo ejecutivo perciba un gerente de línea que tiene, menos probable es que permita que su personal participe en actividades de InnerSource que contribuyan a otra unidad de negocio.

• Cuanta menos transparencia y control tenga un gerente de línea sobre el trabajo realizado por uno de sus subordinados, menos probable es que le permita contribuir.

• Cuanto menos formalmente se gestione y organice el trabajo en InnerSource, menos probable es que un gerente de línea acostumbrado a procesos formales apruebe que uno de sus empleados contribuya a InnerSource.

• Cuanto más tiempo dedique un colaborador a contribuciones a un proyecto de InnerSource que no beneficie su trabajo diario, más aumentará la carga de trabajo para sus compañeros de equipo en su unidad de negocio.

• Los colaboradores individuales probablemente considerarán participar en InnerSource como una oportunidad para mejorar su red profesional dentro de la empresa y para adquirir conocimientos y experiencia en el área técnica de sus contribuciones.

Solución

Establecer un contrato formal entre el colaborador, su gerente de línea y una oficina de gobernanza InnerSource (ISGO) financiada y dirigida centralmente. Hacer que la ISGO reembolse a las unidades de negocio que contrataron colaboradores por el tiempo contratado.

• El contrato especifica un porcentaje máximo del tiempo de trabajo del colaborador en InnerSource.

• El contrato establece claramente que el trabajo en la unidad de negocio del colaborador tiene prioridad sobre el trabajo en InnerSource.

• El contrato establece que no es obligatorio trabajar en InnerSource durante el porcentaje máximo especificado en el contrato.

• La oficina de gobernanza ofrece mediar entre el colaborador y su gerente de línea en caso de conflicto respecto al tiempo para contribuciones.

Contexto Resultante

Un contrato formal y reembolsos financiados centralmente comunican de manera convincente el apoyo de la organización a la iniciativa InnerSource, empoderando así a la gerencia media para aprobarla:

• La asignación de fondos corporativos a las unidades de negocio para el reembolso de la capacidad de desarrollo señala a los gerentes de línea que InnerSource es considerado valioso por la organización, que tiene apoyo ejecutivo y que se espera que ellos también lo apoyen.

• Un contrato formal señala que el trabajo en InnerSource se gestiona profesionalmente e inspira confianza.

• Un contrato formal aumenta la transparencia y proporciona una mejor visión general sobre la capacidad disponible del colaborador para su unidad de negocio y proyectos InnerSource, reduciendo así el riesgo de "capacidad sobrecargada/planificada".

Un contrato formal también es beneficioso para los colaboradores y las comunidades:

• Un contrato formal proporciona una base para resolver conflictos relacionados con la participación en actividades de InnerSource. Tenga en cuenta que la mediación probablemente tendrá éxito solo en unas pocas empresas con una cultura propicia para ello.

Instancias Conocidas

• BIOS en Robert Bosch GmbH

Estado

• Estructurado

Autor

• Georg Grütter (Robert Bosch GmbH)

Agradecimientos

• Diogo Fregonese (Robert Bosch GmbH)

• Robert Hansel (Robert Bosch GmbH)

• Jim Jagielski

• Tim Yao

• Cedric Williams

• Klaas-Jan Stol

• Padma Sudarsan

• Nick Stahl

• Ofer Hermoni

• Robert C. Hanmer

Registro de Cambios

• 2016-10-25 - primera revisión

• 2017-05-09 - reestructuración

• 2017-09-08 - segunda revisión, reestructuración final y fusión

• 2021-02-27 - corrección de problemas con la visualización del patrón en el libro

Histórico de Traducciones

Bienvenido al Libro de InnerSource Patterns.

Este libro recopila las mejores prácticas de InnerSource en un formato específico para que sea fácil de entender, evaluar y aplicar en tu contexto. Llamamos a este formato un patrón.

¿Qué es InnerSource?

Definimos InnerSource como:

El uso de principios y prácticas de código abierto para el desarrollo de software dentro de los confines de una organización.

InnerSource toma las lecciones aprendidas del desarrollo de software de código abierto y las aplica a la forma en que las empresas desarrollan software internamente. A medida que los desarrolladores se han acostumbrado a trabajar en software de código abierto de clase mundial, existe un fuerte deseo de llevar esas prácticas de vuelta dentro del firewall y aplicarlas al software que las empresas pueden ser reacias a publicar.

Para las empresas que construyen principalmente software de código cerrado, InnerSource puede ser una gran herramienta para ayudar a romper los silos, fomentar y escalar la colaboración interna, acelerar la incorporación de nuevos ingenieros e identificar oportunidades para contribuir con software al mundo del código abierto.

¿Qué son los InnerSource Patterns?

Los patrones son una forma de describir una solución repetible y probada a un problema dentro de un contexto. Los patrones siguen una forma simple que te ayuda durante la implementación de una solución a entender las restricciones del problema, comprender las resistencias que necesitas equilibrar y el contexto resultante: la situación creada al aplicar la solución.

Los patrones pueden proporcionar una forma para que los participantes de InnerSource Commons compartan información de manera concisa, mejorando la práctica de InnerSource. Los patrones se dividen en Título, Declaración del Problema, Contexto, Resistencias y Soluciones como sus secciones principales.

¿Cómo puedes usar los InnerSource Patterns?

Los patrones deben usarse con cuidado. No se pueden aplicar indiscriminadamente. En la mayoría de los casos, necesitarás adaptar la solución dada a tu situación; pero la información proporcionada en el patrón, que define el contexto (restricciones inamovibles) y las resistencias (restricciones que se pueden cambiar y equilibrar entre sí), debería ayudarte a hacerlo. Ten en cuenta que también necesitarás determinar si hay restricciones adicionales (contexto de la empresa y resistencias de la empresa) que se aplican a tu empresa/organización en particular y que deben agregarse al patrón (como una especie de filtro). Estas restricciones adicionales pueden requerir pasos adicionales de solución para ser aplicados.

La forma del patrón es útil para describir soluciones probadas, pero también puede usarse para brainstorming de nuevas soluciones donde los patrones aún no están establecidos. Esto se debe a que la anatomía de un patrón proporciona un marco para pensar en un problema de manera estructurada. También podrías crear un patrón de donut (rellenando los campos de problema, contexto, resistencias y contexto resultante pero dejando la solución en blanco) como una forma de pedir ayuda a la comunidad de InnerSource Commons (para encontrar una solución probada o para generar ideas sobre cosas para probar).

¿Cómo Contribuir?

Créditos

Queremos mencionar específicamente al Grupo de Trabajo de InnerSource Patterns. Han fomentado la calidad de los InnerSource Patterns y han ayudado a otros a contribuir. Por último, también compilaron una selección de patrones disponibles en este libro.

¡Gracias a todos los contribuyentes! Y feliz Día de InnerSource :)

Licencia

Title

Grupo de Soporte

Patlet

¿Qué sucede si un equipo o individuo deja de mantener un proyecto InnerSource? Mantén el proyecto activo formando un grupo de personas interesadas.

Problema

• Un proyecto InnerSource popular queda huérfano.

• No tiene un equipo claro que lo adopte.

Historia

Una librería de widgets de UI es utilizada por más de 50 proyectos en toda la empresa. El financiamiento para el equipo propietario de la librería se agota y el equipo se disuelve. Al principio, nadie lo nota, pero después de un tiempo cuando alguien pregunta "¿quién es el propietario?" no hay respuesta. ¿Qué sucederá después? ¿Los nuevos equipos evitarán usarlo? ¿El proyecto se estancará y persistirá hasta que sus usuarios eventualmente se vean forzados a migrar a otra solución? ¡Qué lástima sería si esto le sucediera a un proyecto perfectamente bueno y útil!

Contexto

• Proyecto InnerSource popular.

• Consumido como una dependencia en tiempo de compilación (por ejemplo, módulo de código).

• Nadie lo está manteniendo activamente.

• La empresa no puede asignar un equipo para mantenerlo.

Resistencias

• Nadie está asignado por su trabajo diario para trabajar en ello.

• Todos están ocupados.

• Alto costo para migrar fuera del proyecto.

Soluciones

Llama a voluntarios interesados de cualquier parte de la empresa para formar un grupo de Trusted Committers para mantener el proyecto. Es posible que necesites contactar a individuos específicos basándote en el historial de commits o de uso. Es importante que haya suficientes personas para que la carga sobre cada uno sea razonablemente pequeña.

Al formarse, este grupo debe identificar o crear Documentación Base Estándar y Herramientas de Comunicación.

El grupo debe hacer su mejor esfuerzo para gestionar estos aspectos del proyecto:

• Mantenimiento. Si el proyecto está completamente roto para el caso de uso estándar, entonces arréglalo. Mantén el proyecto actualizado a medida que las dependencias y los frameworks que utiliza continúan evolucionando.

• Incorporación. Si alguien tiene una pregunta sobre cómo usar el proyecto, asegúrate de que obtenga una respuesta razonable.

• Actualizaciones. Si alguien quiere agregar una nueva funcionalidad al proyecto, dale el soporte de diseño y técnico necesario para que lo construya de manera que funcione para ellos y sea una buena adición al proyecto. Revisa las pull requests entrantes de manera oportuna.

Dado que este grupo está compuesto por voluntarios, es importante comunicar que el soporte es solo "mejor esfuerzo". En consecuencia, este modelo de soporte no es adecuado para proyectos críticos en tiempo de ejecución, como APIs en vivo. Es más adecuado para proyectos que se consumen en tiempo de compilación, como librerías/paquetes/módulos. No se espera que el grupo implemente ninguna funcionalidad nueva para otros.

Contexto Resultante

• Hay algún soporte frágil para el proyecto InnerSource.

• A largo plazo, es probable que el grupo de soporte se disuelva nuevamente en algún momento. Si el proyecto continúa a largo plazo, utiliza este período de grupo de soporte estable para encontrar una forma de mantenerlo a largo plazo (por ejemplo, Equipo Central).

Razonamiento

La gente generalmente quiere ayudar. Si hay un alcance personal para que alguien se una como Trusted Committer, generalmente hay varias personas que dirán "sí". Sentirse parte de un grupo y recibir algo de estructura y responsabilidad generalmente motiva a las personas a hacer su mejor esfuerzo, lo cual muchas veces resulta ser suficiente.

Instancias Conocidas

• WellSky

Estado

Estructurado

Autor

Russell R. Rutledge

Histórico de Traducciones

• 2025-04-03 - Traducción Oscar Lobaton S.

• 2025-04-03 - Traducción Roman Martin Gil

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. 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

Title

Equipo Central (Core Team)

Patlet

Incluso cuando un proyecto InnerSource es ampliamente necesario, las contribuciones y el uso pueden verse obstaculizados porque el proyecto es difícil de manejar. Establece un equipo central dedicado a ocuparse de los elementos fundamentales del proyecto. Su trabajo permite que los contribuyentes agreguen y utilicen las funciones que aportan valor a sus escenarios.

Problema

• Es difícil contribuir al proyecto. Esto puede deberse a aspectos como:

  • No se puede ejecutar el proyecto localmente.

  • Documentación deficiente.

  • Código complejo.

  • Pruebas inadecuadas.

• Es difícil usar el proyecto. Algunas posibles causas:

  • Documentación deficiente (de nuevo).

  • Errores frecuentes.

  • Configuración no intuitiva.

Historia

Hay un proyecto central del que todos dependen. ¡Qué gran candidato para InnerSource! Desafortunadamente, el proyecto ha crecido orgánicamente, con varias contribuciones y adiciones hechas de manera desordenada. Ahora es un lío espeso de código que nadie entiende y todos temen tocar. Claramente necesita una revisión (por ejemplo, refactorización, pruebas, documentación, etc.), pero, aunque todos lo consideran necesario, nadie se toma el tiempo para hacerlo.

Contexto

• Muchos equipos necesitan el proyecto.

• El proyecto tiene una deuda técnica significativa.

• Adopción e iteración lenta en el proyecto.

• No hay un propietario o mantenedor que se responsabilice del proyecto y del ecosistema de contribución en su conjunto.

Resistencias

• Cada equipo contribuyente está ocupado y, por lo tanto, prioriza el trabajo que resulta en un beneficio inmediato para ellos.

• A medida que el proyecto crece, la tendencia natural es que se vuelva más difícil de usar y modificar.

Solución

Forma un equipo central cuyo trabajo sea mantener este proyecto en un estado que permita a otros integrarse y contribuir fácilmente. Este equipo se encarga de garantizar un ecosistema saludable para el uso y la contribución. Este trabajo crítico tiende a no ser priorizado como una contribución. Las principales áreas de enfoque incluyen comunicación, entorno local e infraestructura de DevOps.

Aquí hay algunos ejemplos específicos:

• Errores de producción

• Documentación

• Tutoriales y ejemplos de incorporación

• Pruebas automatizadas

• CI/CD

• Entorno local

• Modularización

• Versionado

• Monitoreo

• Pioneros en nuevas clases/categorías de funciones

Cada uno de estos elementos es muy importante para un ecosistema de producto saludable, pero es poco probable que se prioricen como una contribución.

El equipo central puede estar compuesto por un pequeño número de personas a tiempo completo o parcial. La elección depende de la cantidad de trabajo necesario, la disponibilidad de recursos y la cultura de la organización. La consideración más importante es formar el equipo de una manera que permita a la organización empoderarlos y responsabilizarlos de la misma manera que a cualquier otro equipo.

Debido a su papel central, los miembros del equipo central casi siempre deben desempeñar el papel de Trusted Committers también (para más información sobre ese concepto, ver Ruta de Aprendizaje y Patrón). Mientras que el rol de Trusted Committer se centra principalmente en facilitar la contribución y el uso del proyecto por parte de otros, un miembro del equipo central contribuye regularmente al proyecto también. El equipo central no tiene su propia agenda comercial que determine sus contribuciones. Deciden en qué trabajar en función de lo que más ayudará a otros a usar y contribuir al proyecto.

Una buena manera de recordar continuamente al equipo central este objetivo es hacer que informen regularmente sobre:

• número de equipos activos que usan el proyecto

• número de contribuciones fuera del equipo al proyecto.

El enfoque continuo en estas métricas naturalmente llevará al equipo central a priorizar generalmente el trabajo correcto para crear un ecosistema InnerSource próspero alrededor del proyecto.

Contexto Resultante

• Es fácil usar y contribuir al proyecto.

• Muchos equipos usan y contribuyen al proyecto.

• El éxito del equipo central se define en términos de la interacción y respuesta de otros a su proyecto.

Racional

Separar un equipo central y asignarles esta tarea ayuda a llenar los vacíos que un proyecto exitoso necesita, pero que son dejados por los contribuyentes que solo persiguen su propia agenda. El equipo central llena esos vacíos y engrasa las ruedas para que el ecosistema de contribución se mantenga saludable.

Instancias Conocidas

• Nike implementó este patrón para gestionar su iniciativa InnerSource en torno a sus pipelines reutilizables de CI/CD.

• WellSky estableció un Equipo Central para un proyecto clave. Esto les permitió escalar significativamente sus contribuciones InnerSource a ese proyecto - ver Wide-Scaled InnerSource with a Core Team.

• BBVA AI Factory implementó este patrón como parte de una estrategia InnerSource para fomentar la contribución y reutilización del código de ciencia de datos - ver Mercury: Scaling Data Science reusability at BBVA.

Estado

Estructurado

Autor

Russell R. Rutledge

Histórico de Traducciones

• 2025-04-03 - Traducción Oscar Lobaton S.

• 2025-04-03 - Traducción Roman Martin Gil

Title

Comité de Revisión

Patlet

El modelo de trabajo InnerSource es un cambio radical respecto a los enfoques más tradicionales, tanto para desarrolladores como para gerentes. Al establecer un comité de revisión como puente entre la iniciativa InnerSource y todos los gerentes senior de las unidades de negocio participantes, es más probable que estos últimos se familiaricen con la iniciativa y la apoyen, ya que les proporciona cierto nivel de supervisión y control sin fomentar la microgestión.

Problema

Los gerentes percibirán el modelo de trabajo InnerSource como un cambio radical respecto a los modelos de trabajo a los que están acostumbrados y con los que tienen experiencia. Como consecuencia, es probable que rechacen o microgestionen la iniciativa InnerSource para tratar de minimizar el riesgo percibido de este cambio. En ambos casos, los beneficios de InnerSource no se pueden materializar. Como resultado, InnerSource se desacredita posteriormente.

Contexto

La empresa A quiere introducir su primera iniciativa InnerSource. La mayoría de los gerentes de la empresa A no están familiarizados con el modelo de trabajo de código abierto y, en cambio, están acostumbrados a la gestión jerárquica y centralizada.

Resistencias

• Cuanto más control percibido tenga un gerente sobre el trabajo en la iniciativa InnerSource, más probable es que apoye la iniciativa sin experiencia previa.

• Cuanta menos experiencia tenga un gerente con el modelo de trabajo de código abierto, más probable es que quiera controlar el riesgo de la iniciativa.

• Cuanto más pesadas y microgerenciales sean las iniciativas InnerSource, menos probable es que el modelo de trabajo de código abierto se pueda adoptar en la medida necesaria. Como resultado, no se realizarán los beneficios de InnerSource.

Solución

• Establecer un comité de revisión compuesto por gerentes senior de todas las unidades de negocio que participan en la iniciativa InnerSource.

• Los miembros del comité de revisión tienen la autoridad para decidir en grupo qué proyectos InnerSource recibirán apoyo en general y financiación en particular.

• Los miembros del comité pueden seleccionar a solicitantes antes de las reuniones para que presenten su proyecto InnerSource durante las sesiones del comité.

• Los líderes de los proyectos InnerSource actualmente financiados por el comité de revisión están obligados a informar sobre el estado de su proyecto durante cada reunión del comité de revisión.

• Los miembros del comité de revisión están obligados a proporcionar comentarios constructivos tanto a los nuevos solicitantes como a los líderes de proyectos actuales durante las reuniones del comité de revisión.

• A cada proyecto InnerSource se le debe dar la oportunidad de reaccionar a los comentarios recibidos en una sesión del comité de revisión hasta la siguiente sesión para evitar cerrar el proyecto prematuramente.

• Un líder de proyecto InnerSource también puede presentar la moción de ser cerrado por su propia iniciativa en un comité de revisión. El comité de revisión debe decidir si las unidades de negocio que utilizan el software necesitan tiempo para implementar medidas que aseguren que el desarrollo y/o mantenimiento del código continúe hasta que se encuentre una solución alternativa al desarrollo por la comunidad InnerSource (si es relevante para el negocio o crítico para la misión).

• El comité de revisión debe reunirse regularmente. Una cadencia de dos reuniones por año ha demostrado ser exitosa.

• El comité de revisión puede volverse opcional si InnerSource ha sido ampliamente adoptado y comprendido por la organización.

Contexto Resultante

• Los gerentes aplican una herramienta con la que se sienten cómodos a InnerSource para obtener la cantidad necesaria de información y control sobre el funcionamiento interno de la iniciativa InnerSource. Esta familiaridad hará que sea más probable que aprueben la iniciativa InnerSource y otorguen el grado de libertad requerido para los proyectos InnerSource.

• Los desarrolladores aún pueden autoorganizarse en un grado suficiente. La microgestión no ocurre porque el comité de revisión se reúne con poca frecuencia.

Instancias Conocidas

• BIOS en Robert Bosch GmbH (en las primeras etapas de adopción, solo - 2009-2012)

Estado

• Estructurado

• Finalizado y Revisado a partir del 31/08/17.

Autores

• Georg Grütter, Robert Bosch GmbH

• Diogo Fregonese, Robert Bosch GmbH

Alias

Cheese Interface

Histórico de Traducciones

• 2025-04-03 - Traducción Oscar Lobaton S.

• 2025-04-03 - Traducción Roman Martin Gil

¡Cada vez más patrones son contribuidos a este libro por la comunidad de InnerSource Commons! ¡Eso es increíble!

¿Ahora cómo hacer que sea fácil para los lectores descubrir los patrones que pueden ayudarlos en su situación particular?

Para este propósito proporcionamos este mapa mental. Categoriza los patrones en función de las diferentes fases de un Programa InnerSource, y los desafíos que pueden aparecer en las respectivas fases.

Mejorar este Mapa Mental

Si notas algo en este mapa mental que parece incorrecto, por favor abre un issue, describiendo el problema y la solución que debería hacerse.

Además, si tienes otras ideas para mejorar la capacidad de descubrimiento de estos patrones, o quieres mejorar este mapa mental, revisa la documentación de nuestro enfoque de Categorización de Patrones, y también consulta cómo contribuir a este libro.

Referencias

La idea de categorizar patrones de esta manera se basa libremente en una descripción en Pensamientos sobre un Lenguaje de Patrones InnerSource por Tim Yao, Bob Hanmer y Padma Sudarsan (2018). Para detalles específicos, vea la diapositiva 15 en ese conjunto de diapositivas.

Title

Garantía de 30 Días

Patlet

Al aceptar contribuciones externas, es natural que un equipo tenga cierta aversión a asumir la responsabilidad de código escrito por otros. A través de la Garantía de 30 Días, el equipo contribuyente se compromete a proporcionar correcciones de errores al equipo receptor, lo que aumentará el nivel de confianza entre ambos equipos y hace más probable que se acepten las contribuciones.

Problema

Un equipo desarrolla un componente que se utiliza en toda una organización. Este equipo se resiste a aceptar o directamente rechaza contribuciones (solicitudes de funcionalidades). Este comportamiento bloquea el progreso y conduce a interrupciones frecuentes por escalamientos.

Contexto

• Los equipos dependen de que otro equipo acepte sus contribuciones para que un componente producido por el equipo receptor pueda ser utilizado por el equipo contribuyente.

• El equipo receptor no tiene los recursos, conocimientos, permisos y/o inclinación para escribir el componente/funcionalidad contribuido por sí mismos.

Resistencias

• Existe desconfianza hacia las contribuciones debido a un historial de engaños: los equipos enviaron contribuciones a medio terminar y posteriormente presentaron solicitudes de correcciones para hacerlas listas para su uso en producción.

• Si el código es contribuido desde fuera del equipo, se tiene la sospecha natural de que el otro equipo no sabe cómo escribir código que cumpla con las expectativas del equipo receptor.

• Cada equipo busca primero ayudar a sus propios líderes a alcanzar sus objetivos. Esta dirección de lealtad puede complicar la resolución de este problema.

• Existe una aversión natural a asumir la responsabilidad del código no escrito por uno mismo.

• El código contribuido necesita ser reescrito considerablemente antes de ser aceptado en el código fuente.

• Existe el temor de que los contribuyentes no estén disponibles para el soporte en la corrección de errores después del momento de la contribución.

• Los equipos temen que el código contribuido lleve a costos de mantenimiento más altos pero no saben cómo controlarlo.

• Los equipos receptores pueden temer que enseñar a otros cómo contribuir código expondrá deuda técnica en su sistema y que esa visibilidad pueda ser dañina.

• Los equipos receptores pueden no creer que recibirán código aceptable sin importar cuánta tutoría proporcionen.

• Cualquiera de los equipos puede no sentirse seguro al medir riesgos o certificar que están mitigados en una contribución; el sistema en sí es algo frágil (puede no haber formas de probar completamente y detectar todos los problemas).

Solución

Aborda los temores de ambos equipos, tanto el receptor como el contribuyente, estableciendo un período de garantía de 30 días que comienza cuando el código contribuido entra en producción. Durante este período de garantía, el equipo contribuyente acepta proporcionar correcciones de errores al equipo receptor.

El período de garantía puede extenderse a 45, 60 o incluso 100 días, según las necesidades del proyecto. La duración puede variar según las restricciones del proyecto, el ciclo de vida del software del proyecto, los compromisos con los clientes y otros factores.

Además, ayuda proporcionar directrices de contribución claras, detallando las expectativas tanto del equipo receptor como del equipo contribuyente.

Contexto Resultante

• El equipo receptor está dispuesto a aceptar contribuciones y puede compartir la carga de trabajo de adaptaciones/correcciones iniciales.

• Mayor transparencia y equidad.

• Evita que los escalamientos se vuelvan demasiado pesados.

Instancias Conocidas

• Esto fue probado y demostrado exitoso en PayPal.

• GitHub internamente usa este patrón con un período de garantía modificado de 6 semanas.

• Microsoft recomienda este patrón como principio - los equipos establecen su propio objetivo de tiempo específico que coincida con sus necesidades y confianza.

• SAP aprovecha este patrón en su proyecto Everest basado en InnerSource para transformar la colaboración, asegurando que las contribuciones no solo sean aceptadas sino también apoyadas, mejorando la confianza e impulsando la cultura de responsabilidad compartida e innovación. Ver: InnerSource: Primera Contribución Explorada

Autores

• Cedric Williams

Agradecimientos

• Dirk-Willem van Gulik

• Padma Sudarsan

• Klaas-Jan Stol

• Georg Grütter

Estado

• Estructurado

• Redactado en la Cumbre InnerSource de Primavera 2017; revisado el 18 de julio de 2017.

Variantes

• Asegurar la cooperación de equipos dependientes convirtiéndolos en una comunidad al tener más de un "Trusted Committer" (TC) designado meritocráticamente que asuma la responsabilidad.

Histórico de Traducciones

• 2025-04-03 - Traducción Oscar Lobaton S.

• 2025-04-03 - Traducción Roman Martin Gil

Title

Extensiones para un Crecimiento Sostenible

Patlet

Un proyecto InnerSource está recibiendo demasiadas contribuciones, haciendo difícil su mantenimiento. Al ofrecer un mecanismo de extensiones fuera del proyecto principal, los mantenedores permiten escalar las capacidades del proyecto con un costo y mantenimiento mínimos.

Problema

A medida que aumenta rápidamente el número de contribuciones a un repositorio InnerSource maduro, se añade más carga al proceso de revisión de código y mantenimiento. Esto resulta en una gran acumulación de revisiones pendientes o el rechazo prematuro de nuevas contribuciones de funcionalidades.

¿Cómo puede el equipo anfitrión permitir una publicación más rápida de nuevas funcionalidades, fomentando la innovación y experimentación, mientras mantiene el repositorio en buen estado?

Historia

Hay un proyecto estratégico que tiene como objetivo recopilar las mejores innovaciones dentro de un espacio de dominio en una pila común, permitiendo la reutilización de una infraestructura común y proporcionando una experiencia de usuario estándar. A través de InnerSource, varios equipos de la organización que trabajan dentro del espacio de dominio tienen la oportunidad de colaborar y contribuir con sus innovaciones a el código fuente común.

Sin embargo, un gran número de contribuciones en paralelo de varios desarrolladores está dificultando el mantenimiento de el código fuente. Esto está añadiendo una gran carga a los mantenedores del proyecto que asumen la responsabilidad de los estándares de calidad del código y habilitan a la comunidad a través de varias formas de comunicación.

Los mantenedores del proyecto están en riesgo de agotamiento debido a:

• Acumulación interminable de pull requests de los contribuyentes que necesitan ser revisadas.

• Insatisfacción laboral: La mayoría del tiempo de los mantenedores se dedica al soporte de la comunidad, dejando poco espacio para la innovación.

• Percepción de falta de logro: No todas las funcionalidades contribuidas tienen una demanda de usuario adecuada y resultan en una adopción consecuente.

• Liberaciones que consumen mucho tiempo: Más funcionalidades en el código fuente resultan en pruebas de larga duración.

• Aumento de las actividades de mantenimiento: Se reportan más errores a medida que se añaden nuevas capacidades.

Se dedica mucho tiempo a madurar cada nueva contribución de funcionalidad, antes de que los usuarios potenciales tengan la oportunidad de explorar la funcionalidad para sus casos de uso. Si resulta que la nueva funcionalidad no cumple con el caso de uso, entonces todo ese tiempo dedicado a lograr los estándares de calidad del código deseados es un desperdicio.

Contexto

• Una código fuente InnerSource estratégica está escalando rápidamente con nuevas contribuciones de funcionalidades de varios empleados.

• La proporción de revisores a contribuciones resulta en una creciente acumulación de pull requests. Esto está ralentizando la publicación de nuevas funcionalidades a la comunidad.

• La calidad de el código fuente está degradándose y la experiencia del usuario se ve afectada negativamente.

• Los mantenedores de el código fuente están sobrecargados y no pueden mantenerse al día con la afluencia de contribuciones y el aumento del soporte comunitario.

• Algunas de las funcionalidades contribuidas no están ganando adopción por parte de los usuarios, e incluso pueden volverse completamente inactivas. Sin embargo, aunque no se utilicen, estas funcionalidades siguen añadiendo a la carga de mantenimiento.

• La organización está invirtiendo fuertemente en el endurecimiento de las nuevas contribuciones de funcionalidades para mantener los estándares de calidad antes de que las ideas sean exploradas por la comunidad.

• El patrón se aplica en cualquiera de los siguientes escenarios:

  • Los mantenedores se encuentran rechazando nuevas ideas de funcionalidades para reducir el alcance del proyecto. Esto está obstaculizando la innovación en la comunidad y restringiendo la expansión.

  • Para reducir la acumulación, se están liberando nuevas funcionalidades sin una documentación, endurecimiento las pruebas y creando una mala experiencia de usuario. Esto también está inflando el tamaño de el código fuente, añadiendo un gran gráfico de dependencias y dificultando su mantenimiento.

Resistencias

• Los mantenedores y propietarios del producto quieren permitir la expansión, fomentar la innovación y la experimentación sin ser demasiado restrictivos con las contribuciones, mientras mantienen buenos estándares de código y calidad para la experiencia del usuario.

• Se dedica una gran cantidad de tiempo a endurecer y probar exhaustivamente las funcionalidades para cumplir con los estándares del producto, pero los propietarios del producto pueden querer permitir una publicación más rápida de nuevas innovaciones para que los productos adoptantes las exploren antes de invertir tiempo en madurar las capacidades.

• Los mantenedores quieren fomentar que la comunidad comparta innovaciones que combinen las capacidades del producto con otros casos de uso sin añadir más dependencias al repositorio principal.

Soluciones

Permitir extensiones/plugins a bases de código InnerSource de alta escala puede aliviar la carga de mantenimiento de los mantenedores del repositorio y permitir una publicación más rápida de nuevas funcionalidades para que los productos adoptantes las exploren. Esto desplaza el mantenimiento de las capacidades a los propietarios de las extensiones y permite que el repositorio principal soporte capacidades que han sido adoptadas más ampliamente y son más estratégicas.

Las extensiones proporcionan un filtro para nuevas capacidades que eventualmente pueden moverse al núcleo del proyecto. Las extensiones también actúan como un entorno de incubación y endurecimiento comunitario, permitiendo que gran parte de ese endurecimiento ocurra de manera orgánica en lugar de en un costoso proceso de revisión.

Para que el modelo de extensiones tenga éxito, hay algunas consideraciones arquitectónicas a tener en cuenta:

1. Fácil de crear: Para obtener la participación de la comunidad, las extensiones deben ser fáciles de crear.

   • Crear una plantilla de repositorio que las extensiones deben usar como punto de partida. Esto permite que las extensiones añadan sus nuevas funcionalidades en nuevos repositorios, separados del proyecto principal. La plantilla debe proporcionar la misma estructura modular que el repositorio principal e incluir el marco para empaquetar y publicar extensiones.

     • Asegurarse de que a medida que el repositorio principal cambie, las plantillas se mantengan bien. Los mantenedores del repositorio principal son responsables de actualizar las plantillas para asegurarse de que sean compatibles con el proyecto principal. Seguir buenas convenciones de versionado, por ejemplo, semver, facilita esto.

     • Se recomienda además que los mantenedores del repositorio principal proporcionen orientación sobre cómo actualizar las extensiones basadas en versiones anteriores de la plantilla a medida que se liberen nuevas versiones.

   • Añadir ejemplos de extensiones desarrolladas a partir de la plantilla, que los desarrolladores del proyecto puedan referenciar para entender cómo escribir una extensión bien estructurada.

   • Relajar los requisitos para que los contribuyentes creen extensiones omitiendo revisiones para permitir una publicación más rápida o experimentación.

2. Acoplamiento suelto: Tener componentes modulares que contengan funcionalidad puede permitir un acoplamiento suelto, donde los cambios en las extensiones no impacten la calidad de el código fuente principal u otras extensiones.

3. Gestión de dependencias: Cada extensión debe tener cuidado de fijar el rango de versiones del repositorio principal contra el que se construye (de la misma manera que lo haría con cualquier otra dependencia) y debe tener cuidado en su uso de otras dependencias que oculten dependencias del repositorio principal, de modo que las versiones que elija para esas dependencias sean compatibles con las versiones seleccionadas por el repositorio principal. Cualquier conflicto con el repositorio principal se detectará en el marco de pruebas de la extensión.

4. Estrategia de pruebas: ¿Cómo probar las extensiones tanto individualmente como en combinación?

   • Pruebas de extensión individualmente: La plantilla de extensiones proporcionará un marco de pruebas que los desarrolladores de extensiones deben usar para probar la capacidad añadida. Esto puede incluir un marco para pruebas unitarias, pruebas de rendimiento en tiempo de ejecución y pruebas de calidad.

   • Pruebas de extensión en combinación con el repositorio principal: Los desarrolladores de extensiones tienen un método bien estructurado para probar su extensión contra versiones específicas del repositorio principal sin la participación de los mantenedores del repositorio principal.

   • Pruebas de extensión en combinación con otras extensiones: Proporcionar un marco de pruebas para este escenario podría resultar excesivo, especialmente si hay un gran número de extensiones que aún están siendo exploradas por los usuarios y es poco probable que se utilicen todas en combinación. Si un usuario encuentra conflictos al usar extensiones en combinación (lo cual debería ser poco probable con un acoplamiento suficientemente suelto), el usuario puede plantear un problema a los respectivos propietarios de las extensiones, quienes lo resolverán. A medida que una extensión alcanza fases posteriores del ciclo de vida y se fusiona en el repositorio principal, se probará en combinación con el resto de la librería y cualquier conflicto de dependencias deberá resolverse en ese momento.

5. Descubribilidad y Usabilidad:

   • Hacer que las extensiones sean fácilmente descubribles con una página de publicación que muestre las extensiones que los usuarios han creado y desean compartir para el uso del producto.

   • Permitir el registro de extensiones con el proyecto principal para que los usuarios aprovechen las extensiones junto con el proyecto original, manteniendo así la misma experiencia de usuario.

6. Ciclo de vida de las extensiones y mantenibilidad: Establecer el ciclo de vida de las extensiones desde la creación hasta la portación a el código fuente principal, junto con directrices claras de propiedad.

   • Los creadores de extensiones continúan manteniendo la extensión, proporcionando cualquier soporte y corrigiendo defectos. Cualquier extensión que quede sin mantenimiento será deslistada de la página de publicación.

   • Crear criterios para cuando una extensión puede ser portada al repositorio principal, como la adopción de la extensión por productos internos y la demanda de la funcionalidad.

   • El proceso de portación de la extensión al repositorio principal seguirá directrices de revisión de código más estrictas establecidas por los mantenedores de la librería.

Seguir estos principios asegura que:

• Los desarrolladores pueden añadir nuevas funcionalidades al ecosistema de un proyecto sin requerir que escriban grandes cantidades de código boilerplate.

• Las extensiones son descubribles de manera repetible por todos los usuarios del proyecto principal; el hecho de que el código no viva en el repositorio principal aún no significa que no sea valioso.

• La carga del mantenedor se reduce hasta que una extensión ha demostrado que llena un vacío importante en el proyecto principal.

• El código común del proyecto principal (por ejemplo, clases base y funciones utilitarias) puede ser un punto de partida para el nuevo desarrollo que extiende el dominio del proyecto. Esto evita la necesidad de portar el trabajo innovador después de los hechos, reduciendo así la carga general de desarrollar nuevas funcionalidades para el proyecto.

• Los desarrolladores tienen más probabilidades de contribuir y mantenerse involucrados en el mantenimiento y la construcción de comunidades para su código fuente, lo cual también es bueno para la salud del ecosistema general del proyecto.

Contexto Resultante

• El proyecto puede escalar con la adición de nuevas funcionalidades, sin añadir carga de mantenimiento al repositorio principal del proyecto.

• Publicación más rápida de nuevas funcionalidades para que la comunidad las explore, fomentando la innovación y la experimentación.

• Reducción del costoso proceso de revisión de código y endurecimiento de funcionalidades hasta que la funcionalidad pueda demostrar su utilidad. Esto tiene beneficios de ahorro de costos para la organización.

• Un problema posterior que puede introducirse: ¿qué pasa si una extensión no puede completar todo el ciclo de vida?

  • Si una extensión no es adoptada durante un período de tiempo y no puede construir una comunidad a su alrededor para apoyar el mantenimiento, dependerá del propietario de la extensión continuar manteniéndola durante el tiempo que desee. Si una extensión queda sin mantenimiento, se despublicará.

  • Si un desarrollador de extensiones no puede seguir manteniendo su proyecto, y otros desarrolladores de la comunidad quieren continuar apoyándolo, pueden mantener la extensión en adelante.

Instancias Conocidas

• IBM Corporation ha adoptado esta solución para escalar librerías de IA InnerSource. Usando extensiones, los desarrolladores pueden extender las libreríass de IA con más algoritmos y compartir sus innovaciones con la comunidad interna de la empresa. Las librerías principales solo contienen algoritmos estratégicos que han sido adoptados y validados, manteniéndolos más fáciles de mantener a medida que escalamos las contribuciones.

Alias

Extensiones para Gestionar Contribuciones a Escala

Estado

Estructurado

Autor(es)

• Sukriti Sharma, IBM

• Alexander Brooks, IBM

• Gabe Goodhart, IBM

Histórico de Traducciones

• 2025-04-03 - Traducción Oscar Lobaton S.

• 2025-04-03 - Traducción Roman Martin Gil

Title

Documentación Base Estándar

Patlet

Los nuevos contribuidores a un proyecto InnerSource tienen dificultades para identificar quién mantiene el proyecto, en qué trabajar y cómo contribuir. Proporcionar documentación en archivos estándar como README.md/CONTRIBUTING.md/COMMUNICATION.md permite un proceso de autoservicio para nuevos contribuidores, permitiéndoles encontrar respuestas a las preguntas más comunes por sí mismos.

Problema

Un equipo desea compartir un proyecto, ya sea nuevo o existente, con la organización y recibir contribuciones. Los potenciales contribuidores frecuentemente se sienten perdidos: No logran identificar los canales de comunicación preferidos del equipo. Tienen dificultades para determinar rápidamente si una nueva funcionalidad tiene sentido o no. Les cuesta entender exactamente quiénes son los colegas que actualmente mantienen el proyecto.

Contexto

Un proyecto se compartirá con otros como proyecto InnerSource. Para que otros puedan entender de qué trata el proyecto y cómo contribuir, el proyecto necesita proporcionar documentación básica. Hasta ahora, el proyecto carece de toda la documentación o algunos aspectos necesarios para que los usuarios lo prueben de manera autónoma y para que los contribuidores puedan ponerse al día rápidamente.

Resistencias

• El proyecto se convirtió en un proyecto InnerSource recientemente. Antes, los usuarios eran internos o recibían capacitación presencial. De igual manera, las personas que trabajaban en el proyecto pasaban por sesiones de incorporación presencial que no son escalables con el crecimiento de contribuidores o contribuidores remotos. Como resultado, falta documentación de autoservicio.

• El proyecto fue creado como un proyecto InnerSource, pero el equipo anfitrión carece de experiencia con InnerSource. Como resultado, necesitan orientación sobre qué información incluir en su documentación, dónde ubicarla para que otros la encuentren y qué tipos de lectores considerar.

• El proyecto se convirtió en un proyecto InnerSource recientemente, y el equipo anfitrión tiene experiencia limitada con InnerSource. Como resultado, la documentación existente aborda aspectos técnicos pero no cubre comunicación, coordinación e información necesaria para facilitar la planificación transparente.

• El proyecto se convirtió en un proyecto InnerSource recientemente. Como resultado, mucho conocimiento implícito del equipo no está documentado ni es obvio para los contribuidores.

• La falta de documentación hace que los potenciales contribuidores tarden mucho en configurar y comenzar. Producir documentación (y mantenerla actualizada) requiere inversión de tiempo. Incluso si el equipo anfitrión cuenta con contribuidores para ayudar con la documentación faltante, esas contribuciones necesitan tiempo de revisión.

• Los miembros del proyecto dedican mucho tiempo a responder preguntas iniciales. Mantener una base de datos completa de preguntas de soporte requiere mucho tiempo y esfuerzo.

• Diferentes equipos dentro de la organización tienen estándares divergentes sobre cómo formatear código y qué patrones de software usar. Como resultado, las contribuciones a menudo terminan siendo reescritas en gran parte o completamente. Estandarizar todo esto requeriría mucho tiempo y trabajo.

• El trabajo adicional por explicaciones repetidas y reescrituras disminuye la utilidad del enfoque InnerSource.

• Las escalaciones frecuentes debido al trabajo extra y los retrasos por reescrituras llevan a una situación de cuello de botella.

Solución

Abordar la necesidad de una documentación más clara para nuevos contribuidores. El objetivo al crear esta documentación debe ser hacer que el proceso de inicio sea lo más autoservicio posible, con preguntas frecuentes respondidas en un formato de documentación estándar.

README.md

Si tu proyecto aún no tiene un README.md, créalo e incluye lo siguiente:

• La misión del proyecto en un formato lo más conciso posible. Debe responder cuál es el propósito del proyecto y permitir a los contribuidores hacer una buena suposición inicial sobre si una funcionalidad sugerida probablemente estará dentro del alcance del proyecto o no.

• Una sección de "Primeros pasos" para los usuarios del proyecto. Debe explicar cómo configurar/integrar los artefactos del proyecto, así como una explicación de algunos de los primeros pasos típicos para los usuarios primerizos.

• Documentación más profunda para los usuarios del proyecto, o un enlace a ella.

• Documentación necesaria para hacer modificaciones al proyecto, o un enlace a ella.

• Documentación sobre cómo contribuir al proyecto, o un enlace a ella.

• Una sección de "Participar" que explique qué canales de comunicación públicos, archivados y enlazables utiliza el proyecto. Esto debe incluir un enlace al gestor de tareas (issue tracker) del proyecto, pero también a cualquier otro medio de discusión utilizado.

• Una sección de "Quiénes somos" que explique quiénes son los Trusted Committers detrás del proyecto, con una explicación de que en lugar de contactar a estas personas en privado, se deben utilizar los canales de comunicación públicos mencionados anteriormente.

• Una explicación de cuáles son los criterios para que el proyecto convierta a los contribuidores en Trusted Committers, si ese camino existe.

CONTRIBUTING.md

Si la explicación de los pasos para hacer una contribución es demasiado detallada, crea un documento CONTRIBUTING.md separado. Este documento debe responder preguntas frecuentes que los contribuidores hayan hecho en el pasado. No es necesario proporcionar un libro completo desde el principio. Más bien, comparte información que haya demostrado ser necesaria para los contribuidores. Probablemente tocará uno o más de los siguientes temas:

• Cómo obtener el código fuente del proyecto desde el control de versiones.

• Cómo hacer modificaciones al proyecto (potencialmente incluyendo información sobre las pautas de codificación).

• Cómo construir el proyecto.

• Cómo ejecutar pruebas para asegurarse de que las modificaciones anteriores no introduzcan nuevos errores.

• Cómo enviar tus modificaciones de vuelta al proyecto.

• Alguna información sobre el tiempo de respuesta esperado para las modificaciones realizadas.

COMMUNICATION.md

Crea un documento COMMUNICATION.md separado. Enlaza este documento a tu README.md para que se pueda proporcionar información de contacto completa sin ocupar espacio adicional en tu README. Este documento debe responder preguntas frecuentes sobre cómo comunicarse con tu equipo que los contribuidores necesitan saber. El objetivo es agilizar las comunicaciones para que los usuarios y contribuidores se comuniquen con la persona correcta a través de un solo canal. Esto reduce distracciones innecesarias para los miembros del equipo y organiza las comunicaciones para que no se pierdan.

Las secciones en el COMMUNICATION.md incluyen puntos de contacto para comunicaciones entrantes e información sobre comunicaciones salientes del equipo de propiedad del proyecto. A continuación, algunos ejemplos.

Puntos de contacto para la comunicación entrante y cómo contactar a esos usuarios:

• Reportar un error

• Dar seguimiento a un PR

• Solicitudes de funcionalidades

• Preguntas sobre documentación

• Escalaciones

Cómo y cuándo el equipo se comunica con los usuarios y cómo ser agregado a esas comunicaciones:

• Interrupciones planificadas y no planificadas

• Lanzamientos de funcionalidades

• Congelaciones de código

• Cambios importantes

Hay muchos buenos ejemplos de cómo escribir un README.md y qué tipo de información incluir en un archivo CONTRIBUTING.md en varios proyectos de código abierto. Páginas como cómo escribir un readme que destaque, Guía de Código Abierto de GitHub así como el libro Producing Open Source tienen información valiosa sobre qué tipo de información proporcionar. Aunque Producing Open Source no tiene un capítulo sobre cómo escribir un buen README per se, el capítulo de Primeros Pasos proporciona una lista bastante extensa de cosas que los miembros del equipo anfitrión, usuarios y contribuidores necesitarán. Los proyectos InnerSource probablemente no cubrirán todos esos aspectos desde el principio, pero la lista en sí es útil para inspiración sobre qué se podría cubrir.

Además de eso, este patrón viene con tres plantillas muy básicas para que puedas comenzar de inmediato: README-template.md, CONTRIBUTING-template.md y COMMUNICATION-template.md.

Contexto Resultante

• El tiempo para que los contribuidores se pongan al día se reduce significativamente.

• El tiempo dedicado a responder preguntas iniciales para los Trusted Committers se reduce significativamente, dejándoles más tiempo para trabajar en otras tareas.

• Las escalaciones debido a malentendidos y desalineaciones se reducen significativamente.

Instancias Conocidas

• Europace AG - Ver publicación en el blog InnerSource: Adding base documentation

• Paypal Inc.

• Mercado Libre - crear un sitio de documentación que contenga cómo comenzar con InnerSource y también definir los artefactos básicos que un repositorio debe tener para ser InnerSource (README, CONTRIBUTING, CODING_GUIDELINES, etc).

• Analog Devices Inc.

• Airbus

Autores

• Isabel Drost-Fromm

• Katie Schueths - agregó el concepto de COMMUNICATION.md

Alias

Proporcionar documentación base estándar a través de un README

Estado

• Estructurado

• Borrador en diciembre de 2019.

Referencias

• README-template.md

• CONTRIBUTING-template.md

• COMMUNICATION-template.md

Créditos

Ilustraciones de Web y People por Storyset

Histórico de Traducciones

• 2025-04-03 - Traducción Oscar Lobaton S.

• 2025-04-03 - Traducción Roman Martin Gil

Title

Proceso Estándar de Publicación

Patlet

Los equipos pueden dudar en adoptar un proyecto InnerSource si no están seguros de su madurez. Para abordar esto, las notas de versión consistentes y los artefactos publicados son cruciales. Estas prácticas demuestran una fuerte dedicación al proyecto, generando confianza y asegurando a los usuarios un compromiso continuo con un software sostenible y bien gestionado.

Problema

Cuando un equipo está decidiendo si usar un proyecto InnerSource, una de sus consideraciones es si pueden confiar en el proyecto dado por un período prolongado. Cambiar las herramientas/proyectos que están utilizando tiene un costo, por lo que solo quieren hacer esas inversiones cuando sea necesario y tenga beneficios tangibles.

Es una práctica común para los proyectos de código abierto tener versiones versionadas, con notas que documentan cambios importantes y nuevas características junto con un binario publicado o un enlace a una imagen de Docker. Esta práctica puede no ser tan transparente o bien documentada/visible para los proyectos InnerSource, módulos, etc.

Los proyectos InnerSource que no tienen un artefacto publicado o un proceso de publicación reducen la confianza. Los equipos no sabrán cuándo pueden esperar la próxima versión, cuándo se introducen cambios importantes, etc.

Contexto

Las grandes organizaciones producen mucho software interno, gran parte del cual podría ser reutilizado por equipos en toda la empresa. Herramientas operativas, librerías de software y módulos de infraestructura como código (IaC) son ejemplos comunes de este tipo de software. Sin embargo, la mayoría de las grandes organizaciones no publican software interno para ser consumido por otros equipos en la empresa. Esto puede ocurrir porque están demasiado ocupados para proporcionar documentación o no se dan cuenta del valor del proyecto para otros.

Debe estar disponible un repositorio de código fuente interno o público donde se almacene el código fuente, pero los equipos carecen de un proceso para hacer que el software sea consumible por equipos externos.

A medida que una organización crece y se escribe más software interno, el valor de este patrón crece.

Resistencias

Difícil para organizaciones que no tienen un sistema CI/CD central

Para las organizaciones que no proporcionan a los ingenieros un sistema CI/CD centralizado, automatizar un proceso de construcción y publicación puede ser un desafío. El equipo puede necesitar implementar su propia herramienta (Jenkins, Drone, etc). Sin un sistema CI/CD, las construcciones y las notas de versión aún se pueden producir, sin embargo, puede requerir una construcción local del software y una carga manual a la herramienta que esté alojando los artefactos de construcción.

Carga adicional de publicar notas de versión

Además de construir su código fuente, escribir notas de versión puede ser tedioso sin la capacidad de autogenerar una lista de commits de git. Esto quedaría para que alguien lo haga manualmente, además de escribir detalles más generales sobre una versión.

Mayor dificultad sin una ubicación para alojar artefactos

Si una empresa no proporciona una ubicación centralizada para almacenar artefactos de construcción (jars, módulos npm, etc.) e imágenes de Docker, los ingenieros pueden quedar decidiendo por sí mismos dónde es apropiado almacenar el software versionado. Herramientas como GitHub proporcionan esto para ti, sin embargo, si una empresa no está utilizando una de estas herramientas populares, esto podría suponer una carga.

Solución

Al proporcionar notas de versión claras y un artefacto publicado, aumentas la confianza de las personas en que estás publicando un producto de calidad en el que puede confiar.

Los siguientes son elementos clave para lograr esto:

• Los artefactos de construcción son generados por el sistema CI/CD (binario, imagen de Docker, jar, etc)

• Las versiones incluyen notas sobre Nuevas Características, Corrección de Errores y cualquier "Cambio Importante"

Contexto Resultante

Los equipos que encuentren tu proyecto verán notas de versión publicadas y ganarán confianza en tu herramienta. Los artefactos publicados también facilitan y aceleran el uso de tu producto. Tener procesos bien definidos y visibles como estos también ayuda con la colaboración entre equipos y nuevos contribuyentes. Las personas pueden estar seguras de que sus contribuciones están disponibles y distribuidas en un tiempo razonable con una ruta de uso clara.

Instancias Conocidas

• Comcast (múltiples proyectos)

• GitHub (múltiples proyectos)

Autores

David Grizzanti

Estado

Estructurado

Histórico de Traducciones

Title

Modelo de Madurez

Patlet

Los equipos han comenzado a adoptar InnerSource. La práctica se está expandiendo a múltiples departamentos. Sin embargo, la comprensión de lo que constituye un proyecto InnerSource varía. La solución es proporcionar un modelo de madurez que permita a los equipos realizar una autoevaluación y descubrir patrones y prácticas que aún no conocen.

Problema

Cuando la adopción de InnerSource en una empresa comienza a aumentar, la tutoría individual de cada proyecto a través de un evangelista se vuelve inviable. Además, cada vez más personas están adquiriendo al menos una comprensión básica de lo que significa trabajar en un proyecto InnerSource. Sin embargo, al observar todos los proyectos InnerSource, la profundidad de la comprensión del concepto diverge. Los equipos pueden no estar al tanto de patrones probados que les ayudarían a pasar al siguiente nivel y resolver problemas y puntos de dolor con los que están lidiando.

Contexto

Varios equipos han comenzado a adoptar prácticas de InnerSource. El nivel exacto de comprensión de la práctica diverge entre los equipos. Los problemas exactos que enfrentan los equipos divergen según el contexto y el entorno de trabajo de cada equipo. Como resultado, la definición de cuáles son las mejores prácticas importantes en un proyecto InnerSource difiere según cada equipo.

Resistencias

Los equipos que comparten aprendizajes de InnerSource se encuentran con malentendidos, ya que no son conscientes de su respectivo nivel de adopción de InnerSource.

Los equipos no están al tanto de las mejores prácticas que les ayudarían a resolver problemas que enfrentan en su trabajo diario.

Solución

Pida a los equipos que se autoevalúen con el modelo de madurez propuesto.

Transparencia

Planes y Productos

Los proyectos InnerSource se benefician de la planificación transparente en toda la organización al permitir que las partes interesadas comprendan mejor las decisiones y las influyan de una manera que pueda ser seguida por otros.

• PP-0: Los individuos y equipos no divulgan regularmente sus planes o productos a múltiples partes interesadas. No existen acciones formales en la organización.

• PP-1: Los individuos y equipos dan visibilidad a sus planes o productos a múltiples partes interesadas, antes de que comiencen. Hoja de ruta compartida.

• PP-2: Ya existen hojas de ruta compartidas con pautas claras y reglas de contribución donde las partes interesadas pueden proporcionar comentarios. Sin embargo, esto no está estandarizado en toda la organización y no todos los proyectos proporcionan esta información.

• PP-3: Las hojas de ruta se comparten por defecto y hay un proceso estándar y homogéneo para hacerlo en toda la organización a nivel de cada proyecto InnerSource. Esto contiene reglas claras para contribuir e influir en la hoja de ruta.

Proceso de Desarrollo y Herramientas

Los proyectos InnerSource prosperan cuando los contribuyentes se vuelven activos y participan. Como resultado, hacer que la contribución sea más fácil debe equilibrarse con objetivos puramente técnicos.

• DP-0: Cada equipo sigue su propio proceso de desarrollo y herramientas. No están definidos para compartir conocimientos y artefactos fuera del equipo de desarrollo. Equipos de desarrollo en silos.

• DP-1: Los equipos de desarrollo utilizan repositorios de código compartidos, internamente. Algunos equipos desarrollan su propio proceso de CI, utilizando herramientas de CI no corporativas o estándar. No hay un proceso de revisión de código definido, aunque algunos equipos de proyectos lo hacen internamente.

• DP-2: La organización patrocina y promueve un repositorio compartido para el conocimiento colectivo. Algunos equipos desarrollan su propio proceso de CI, utilizando herramientas de CI corporativas. Hay entornos de CI. Proceso de revisión de código definido y utilizado por algunos proyectos. A veces, la revisión de código es realizada por miembros de equipos externos.

• DP-3: La mayoría de los equipos desarrollan su propio proceso de CI, utilizando herramientas de CI corporativas. Hay entornos de CI. Proceso de revisión de código definido y utilizado. La revisión de código es realizada tanto por miembros internos como externos del equipo.

Decisiones

Para motivar a los colegas a contribuir con trabajo fuera de su equipo central, necesitan visibilidad en el proceso de toma de decisiones del proyecto anfitrión, pero también sentir que sus voces son escuchadas y valoradas.

• DC-0: Los responsables de la toma de decisiones a menudo retienen intencional o accidentalmente datos y recursos relacionados con las decisiones del proyecto.

• DC-1: Los materiales que forman parte de las prácticas de toma de decisiones se ponen a disposición para su revisión después de que se finalizan las decisiones.

• DC-2: Las personas sienten que conocen y están ayudando a dar forma a la mayoría (pero no a todas) de las decisiones importantes a medida que se desarrollan. Los materiales que forman parte de las prácticas de toma de decisiones están disponibles en hitos definidos del proyecto.

• DC-3: Las personas sienten que forman parte de un proceso compartido y estándar para la toma de decisiones colectivas que la organización respalda. Los materiales que forman parte de las prácticas de toma de decisiones son continuamente accesibles durante los procesos de trabajo.

Recursos Útiles

Para atraer a los contribuyentes, el material de apoyo útil debe ser fácilmente accesible.

• RS-0: Los individuos y equipos no contribuyen ni recurren a un repositorio compartido de conocimientos.

• RS-1: Los individuos y equipos liberan materiales del proyecto para su revisión interna, después de haber terminado su trabajo. Los individuos y equipos comparten recursos, pero en sistemas o repositorios desconectados, fragmentados o individualizados/en silos. Los individuos y equipos comparten recursos, pero no hay una comprensión comúnmente expresada o compartida de los criterios utilizados para determinar si la información es sensible o no. No "comparten pensamientos con otros".

• RS-2: Los individuos y equipos hacen que los materiales relacionados con el proyecto sean accesibles para algunos miembros de los equipos del proyecto de acuerdo con formatos y/o protocolos claramente definidos y compartidos. Los individuos y equipos retienen datos y recursos sensibles, proporcionando detalles, contexto y alcance limitados.

• RS-3: Los individuos y equipos hacen que los materiales relacionados con el proyecto sean ampliamente accesibles para la organización, y posiblemente fuera de la organización también, de acuerdo con formatos y/o protocolos claramente definidos y compartidos. Los individuos y equipos que deben retener datos y recursos sensibles son claros sobre lo que no están compartiendo, y otros entienden por qué esos materiales no están disponibles para ellos.

Historias

Cuando se trabaja en equipos anfitriones, los errores serán automáticamente visibles. Para mantener altos niveles de contribución, la cultura corporativa debe celebrar el fracaso como una oportunidad para el crecimiento y el aprendizaje.

• ST-0: Los individuos y equipos no comparten éxitos ni fracasos para que otros aprendan.

• ST-1: Los individuos y equipos se sienten cómodos compartiendo historias sobre éxitos, pero no sobre fracasos.

• ST-2: Los individuos y equipos se sienten cómodos compartiendo historias de éxitos y fracasos durante retrospectivas y revisiones.

• ST-3: Los individuos y equipos se sienten cómodos compartiendo historias de éxitos y fracasos, y aprenden de los fracasos según protocolos formales.

Colaboración

Canales para Proporcionar Retroalimentación

Para que los silos se reduzcan, los colegas deben sentirse cómodos compartiendo retroalimentación abiertamente. Una forma fácil de apoyar eso es usar los mismos principios de comunicación a través de las jerarquías.

Idealmente, se establecerán canales de comunicación adecuados que sean conocidos por todos en la organización, con canales enfocados en diferentes objetivos (anuncios, soporte al usuario, canales de desarrollo, discusiones de infraestructura, etc.). Algunas de las mejores prácticas que establecerás a medida que tus proyectos InnerSource maduren: Adopción de pautas de netiqueta, apertura de un conjunto probado de canales estándar (que se archivan, son de acceso público, se pueden buscar) para cada nuevo proyecto InnerSource.

• CF-0: No hay procesos ni canales establecidos. Algunos miembros de la organización comparten materiales a través de canales o discusiones privadas.

• CF-1: La organización está en proceso de establecer pautas y canales internos para fomentar diversos puntos de vista sobre decisiones de la empresa/departamento, para que cualquier persona que pertenezca a la organización pueda usarlos. Algunos miembros de la organización comparten materiales de toma de decisiones de manera informal utilizando plataformas no oficiales. Los líderes mantienen al menos un canal claro y directo para que los miembros de la organización compartan opiniones constructivamente sobre algunos asuntos relevantes para su trabajo.

• CF-2: La organización ha establecido pautas y canales internos, y proporciona recursos específicos (programas de capacitación, acceso a contenido, etc.) para fomentar y solicitar diversos puntos de vista sobre decisiones de equipo o de la organización.

• CF-3: Los miembros de la organización comparten materiales de toma de decisiones en plataformas oficialmente sancionadas. Los miembros de la organización comparten materiales abiertamente a través de múltiples canales y métodos para recibir retroalimentación. Los líderes también utilizan esos canales, alientan abiertamente a otros a usarlos y mantienen registros orientados al equipo o al público de la retroalimentación que han recibido y/o las acciones que han tomado para abordar esta retroalimentación.

Liderazgo

Los proyectos InnerSource alientan a los empleados a contribuir a proyectos fuera de la influencia directa de su gerente de línea directa. Esto necesita una cultura de confianza.

• LS-0: Cultura de mando y control, dentro de una organización altamente jerárquica.

• LS-1: Algunos líderes están abiertos a recibir retroalimentación y crear un entorno donde las personas se sientan seguras al proporcionarla.

• LS-2: La mayoría de los líderes en la organización están abiertos a recibir retroalimentación y crear un entorno donde las personas se sientan seguras al proporcionarla. Los líderes muestran pasividad al comprender si todos los miembros se sienten empoderados y habilitados para compartir. La organización alienta a los líderes a buscar activamente voces no presentes en el diálogo para su inclusión.

• LS-3: Los miembros se sienten empoderados y habilitados para compartir opiniones constructivamente sobre cualquier asunto relevante para su trabajo o sobre el cual se sientan apasionados.

Estructura Organizacional y Funcional

Cuando InnerSource deja el nivel puramente de codificación y entra en el nivel de comunidad y grupos de trabajo, hay potencial para reducir los silos incluso donde la colaboración directa en el código no es posible.

• OF-0: Los grupos de trabajo tienden a ser estáticos en términos de membresía y conjuntos de habilidades.

• OF-1: Existen equipos multifuncionales, pero los roles del equipo a menudo no están claros y las estructuras de gobernanza son vagas.

• OF-2: Los equipos multifuncionales son comunes y los equipos publican sus roles y objetivos públicamente.

• OF-3: Los equipos multifuncionales son comunes y hacen que sus actividades sean conocidas ampliamente en la organización; a su vez, la organización promueve las mejores prácticas para trabajar juntos.

Contribución

El objetivo al diseñar patrones de contribución debe ser mantener la colaboración en mente si se quiere reducir los silos.

• CB-0: Completamente en silos, sin colaboración fuera de los equipos. Solo algunas colaboraciones debido a equipos multifuncionales.

• CB-1: Los miembros de la organización y los equipos colaboran, pero con frecuencia dicen que es "demasiado difícil". Los equipos rara vez revisan los resultados de sus colaboraciones.

• CB-2: Los miembros de la organización y los equipos buscan activamente oportunidades para colaborar. Los equipos discuten, revisan y debaten rutinariamente los resultados de sus esfuerzos colaborativos, y hacen que estos resultados estén disponibles por defecto.

• CB-3: Los miembros de la organización colaboran tanto interna como externamente de maneras que benefician a todos los involucrados. Los equipos discuten, revisan y debaten rutinariamente los resultados de sus esfuerzos colaborativos, y comparten sus aprendizajes fuera de la organización, y hacen que estos resultados estén disponibles externamente por defecto.

Comunidad

Políticas de Compartir

Tener una base de valores compartidos facilita el trabajo a través de los límites del equipo. Cruzar límites se vuelve más fácil si un conjunto limitado de reglas y pautas básicas se aplica en todas partes y se puede referenciar fácilmente.

• SP-0: No hay cultura de compartir ni políticas escritas.

• SP-1: Algunos miembros de la organización se unen para definir valores y principios, pero no están claramente apoyados cuando lo hacen.

• SP-2: Los miembros de la organización documentan colectivamente visiones y acuerdos compartidos como declaraciones de misión y códigos de conducta, los hacen fácilmente accesibles y los mencionan con frecuencia. Los materiales de incorporación y los rituales de orientación proporcionan un contexto adecuado para ayudar a los nuevos miembros a comprender cómo la organización se beneficiará de sus contribuciones.

• SP-3: Los valores y principios compartidos informan los procesos de toma de decisiones, resolución de conflictos y evaluación entre los miembros de la organización, que mencionan estos valores y principios de manera consistente tanto en formatos verbales como escritos.

Sentirse parte de la Organización

Una de las posibles razones para introducir InnerSource en las organizaciones puede ser aumentar el compromiso. Este punto rastrea cómo está cambiando el compromiso mientras se adopta InnerSource.

• PA-0: Bajo compromiso, sin colaboración y las personas no se sienten cómodas compartiendo con otros.

• PA-1: Los miembros de la organización se sienten cómodos compartiendo sus pensamientos y opiniones sin temor a represalias, pero solo en dominios familiares. Las personas entienden que las mejores ideas ganan y las responsabilidades de liderazgo recaen en personas con historias de contribución y compromiso.

• PA-2: Los miembros de la organización se sienten cómodos compartiendo sus pensamientos y opiniones sin temor a represalias. Los líderes demuestran dedicación a los valores compartidos de la organización.

• PA-3: La organización es proactiva al decir a los miembros que se beneficia de sus contribuciones; como tal, los miembros demuestran conciencia compartida y ejecución empoderada, y sienten un sentido de responsabilidad hacia la comunidad. Los líderes entienden que crecen ayudando a otros a crecer y mentorean a los miembros junior de la organización.

Gobernanza

Recompensas

Para impulsar la adopción, se pueden utilizar motivadores extrínsecos para aumentar la colaboración entre equipos.

• RW-0: Sin recompensas.

• RW-1: Se alienta a los líderes a recompensar colaboraciones excepcionales, pero no hay políticas ni procesos establecidos.

• RW-2: Se establecen procesos estándar para recompensar colaboraciones fuera de los equipos de desarrolladores. Los líderes de equipo o juntas deciden quién debe ser recompensado.

• RW-3: Las recompensas no solo son propuestas por la organización, sino que las comunidades pueden definir sus recompensas más valiosas. La comunidad es responsable de decidir quién debe ser recompensado.

Políticas de Monitoreo

Los proyectos InnerSource necesitan un medio para la autoevaluación. Las métricas pueden ser un aspecto para facilitar esta evaluación. Además, en organizaciones con un nivel de adopción de InnerSource maduro, esperamos que la adopción del método se rastree en función de métricas claras y acordadas.

• MP-0: No existen políticas de monitoreo en ningún nivel de la organización.

• MP-1: Las métricas son importantes para ciertos equipos y comienzan a usarlas de manera aislada.

• MP-2: Existe una estrategia a nivel organizacional con respecto a las métricas que ayudan a validar políticas específicas en toda la organización. Esta política de monitoreo existe a nivel de algunos proyectos InnerSource.

• MP-3: Existen pautas claras, recomendaciones y capacitaciones sobre el uso de métricas con cierta infraestructura proporcionada por la organización. Esto funciona en ambos niveles: programa InnerSource para comprender la adopción general de InnerSource dentro de la organización y a nivel de proyectos InnerSource.

Soporte y Mantenimiento

No solo el desarrollo de características debe ser propiedad de los equipos InnerSource, el soporte y mantenimiento también es parte de las tareas principales de los equipos.

• SM-0: Soporte dado por el equipo de desarrollo o soporte principal. Un contrato comercial garantiza el soporte. No hay conocimiento sobre el producto fuera del equipo.

• SM-1: Existen reglas y regulaciones para formalizar el soporte en el producto, dado por un equipo de soporte dedicado.

• SM-3: Existen reglas y regulaciones para formalizar el soporte en el producto, dado por una comunidad madura.

Cultura

Hay múltiples niveles que avanzan hacia una cultura colaborativa.

• CL-0: Silos: los equipos trabajan de manera independiente pero también en aislamiento.

• CL-1: Reactivo: los equipos trabajan de manera independiente, pero saben cómo reaccionar ante fallas en las dependencias.

• CL-2: Contributivo: los equipos ayudan activamente a mejorar sus dependencias contribuyendo.

• CL-3: Activista: los equipos buscan activamente ayuda, mentorean y reclutan nuevos contribuyentes.

Roles de InnerSource

InnerSource viene con roles explícitos. Si bien en las primeras etapas algunos patrones pueden ser utilizables sin adoptar esos roles, comunicarse dentro de los proyectos utilizando títulos de roles explícitos se vuelve más fácil.

• RO-0: No existen roles específicos que ayuden a la adopción de InnerSource. Solo están presentes roles comunes de desarrollo: desarrollador, analista, probador, etc.

• RO-1: Ocasionalmente, algunos individuos y equipos contribuyen a otros proyectos. Estas son contribuciones técnicas, donde se ve el rol de usuario/contribuyente. Para algunos equipos, se puede identificar al menos un miembro que sea una referencia técnica, que explique el proceso de desarrollo a otros miembros del equipo de desarrollo. Él/ella podría ser un candidato para cubrir el rol de trusted committer.

• RO-2: Un rol de Oficial de InnerSource está a cargo de la gobernanza y el soporte, incluidos los procesos, etc. Identifica las necesidades de educación y asegura que se proporcione a la organización. Lidera y mentorea a la organización en el compromiso con los proyectos de IS. Es el primer paso formal en el camino, definiendo la visión y la hoja de ruta de IS. La organización ha definido un rol de trusted committer, siendo un punto de contacto/referencia no solo para los miembros del equipo de desarrollo, sino también para los contribuyentes externos. Existe un proceso estándar que describe cómo contribuir a la comunidad, el rol de contribuyente está presente. El rol de Científico de Datos está a cargo de gestionar las huellas de actividad dejadas por la iniciativa de InnerSource, necesarias para medir la evolución de IS. El rol de trusted committer evolucionará a un perfil más técnico, y un gerente de comunidad estará a cargo de "energizar" la comunidad, siendo su principal responsabilidad atraer y retener nuevos desarrolladores/usuarios (contribuyentes/miembros de la comunidad).

• RO-3: Los evangelistas se mueven dentro de la organización, para que otros conozcan el trabajo actual, lo que hace InnerSource y cómo hacerlo, y ayuden a otros a comprender y formar parte de la iniciativa. Aparecen contribuyentes no técnicos.

Contexto Resultante

Todos los equipos están al tanto de las mejores prácticas disponibles.

Los equipos entienden su nivel de adopción de InnerSource.

Antes de adoptar InnerSource como modelo de trabajo, los equipos son conscientes de las prácticas que se esperan de ellos, tanto a corto como a largo plazo.

Instancias Conocidas

• Entelgy

• Zylk

• Bitergia

• Airbus

Autores

• Daniel Izquierdo Cortazar

• Isabel Drost-Fromm

• Jorge

• Nerea

Agradecimientos

• Alexander Andrade (agradecimiento especial por las correcciones ortográficas)

Alias

Modelo de madurez: Aprender sobre las mejores prácticas de InnerSource

Estado

• Estructurado

• Redactado en septiembre de 2019

Histórico de Traducciones

Title

Comenzar como Experimento

Patlet

Inicia tu iniciativa InnerSource como un experimento con tiempo limitado para facilitar que los gerentes no familiarizados con InnerSource respalden y apoyen la iniciativa.

Problema

Se considera una iniciativa InnerSource pero no se inicia porque la gerencia tiene dudas sobre su resultado y, en consecuencia, no está dispuesta a comprometerse con una inversión.

Contexto

La empresa está considerando InnerSource para aumentar la eficiencia de la colaboración en proyectos de software. Sin embargo, la mayoría de los gerentes no están familiarizados con el modelo de trabajo de Open Source y, en cambio, están acostumbrados a un estilo de gestión jerárquico y de control de arriba hacia abajo. La idea de InnerSource es muy popular entre los desarrolladores de software de la empresa, porque muchos desarrolladores usan o están desarrollando activamente software de Open Source.

Resistencias

• Los gerentes querrán validar las afirmaciones de mejora de la colaboración a través de InnerSource antes de hacer una inversión a largo plazo. Esto generalmente implica medir las mejoras.

• Si la iniciativa InnerSource probablemente tendrá una gran aceptación entre los desarrolladores y si muchos proyectos dependerán de ella, una decisión de cerrarla será muy impopular y, por lo tanto, difícil de tomar. La pérdida de control percibida podría disuadir a algunos gerentes de siquiera comenzar con InnerSource.

• Implementar modelos de trabajo al estilo InnerSource a menudo es un cambio radical con respecto a los modelos de trabajo practicados anteriormente. Por lo tanto, es probable que los procesos obligatorios existentes ya no sean aplicables y que falten los procesos de gobierno apropiados. Esto podría llevar a operar en un vacío regulatorio, e incluso legal. Ejemplos son las regulaciones relacionadas con impuestos y control de exportaciones en grandes corporaciones con múltiples entidades legales en múltiples países.

Solución

Declara la iniciativa InnerSource como un experimento con tiempo limitado. Define y comunica los criterios para que los proyectos se unan al experimento InnerSource. Elige criterios que maximicen las posibilidades de construir una comunidad saludable. Un conjunto de criterios es bueno si los conocimientos generados a partir de él en el contexto del experimento pueden aplicarse intuitivamente a contextos que involucren otros posibles proyectos InnerSource.

Ejemplos de tales criterios son:

• Suficiente distribución geográfica de desarrolladores

• Suficiente mezcla departamental de desarrolladores

• Apertura de comunicación dentro de la comunidad

• Trayectoria profesional basada en el mérito dentro de la comunidad

• Toma de decisiones democrática dentro de la comunidad

Contexto Resultante

Los gerentes pueden iniciar InnerSource por las siguientes razones:

• La configuración experimental reduce la necesidad de que los gerentes examinen los indicadores del programa InnerSource de la misma manera que lo harían con los proyectos típicos.

• La posibilidad de fracaso del experimento se entiende y se acepta. El riesgo personal para los gerentes que apoyan se minimiza.

• Incluso en caso de fracaso, la configuración asegura que la empresa aprenderá del experimento.

• En caso de éxito, los datos recopilados durante el experimento permitirán a los gerentes comprometerse a largo plazo con InnerSource.

Los participantes en el experimento InnerSource ahora son conscientes de que deben demostrar a la gerencia que InnerSource ofrece los beneficios prometidos. Por lo tanto, ayudará a enfocar el trabajo en aquellas actividades que proporcionen el valor más demostrable, aumentando así las posibilidades de éxito.

Finalmente, comenzar como un experimento facilita mucho eludir las regulaciones y resistencias como las políticas de herramientas y procesos que podrían disminuir las posibilidades de éxito.

Patrones Relacionados

Instancias Conocidas

• Robert Bosch GmbH (desarrollo de software distribuido globalmente)

• Airbus: la comunidad de ciencia de datos colaboró en librerías compartidas de Python que eventualmente llevaron a un esquema InnerSource en todo el grupo para cualquier software.

Estado

• Estructurado

Autor

• Georg Grütter (Robert Bosch GmbH)

Agradecimientos

• Jason Zink (Robert Bosch GmbH)

• Diogo Fregonese (Robert Bosch GmbH)

• Robert Hansel (Robert Bosch GmbH)

• Hans Malte Kern (Robert Bosch GmbH)

• Russ Rutledge (Nike)

• Tim Yao (Nokia)

• Clint Cain (Optum)

Histórico de Traducciones

Title

Líder de Comunidad Dedicado

Patlet

Selecciona personas con habilidades tanto de comunicación como técnicas para liderar las comunidades y asegurar el éxito al iniciar una iniciativa InnerSource.

Problema

¿Cómo asegurar que una nueva iniciativa InnerSource tenga el líder de comunidad adecuado para hacer crecer su impacto?

Seleccionar a las personas equivocadas y/o no proporcionarles suficiente capacidad pone en riesgo el esfuerzo y, en última instancia, el fracaso de una nueva iniciativa InnerSource.

Historia

Considera la siguiente historia. Una empresa quiere iniciar una iniciativa InnerSource para fomentar la colaboración a través de los límites organizacionales. Han decidido comenzar con una fase experimental de alcance limitado. La gerencia ha seleccionado un tema piloto adecuado para la primera comunidad InnerSource y espera contribuciones de muchas unidades de negocio en toda la organización. La empresa ha nominado a un nuevo empleado para liderar la comunidad durante el 50 % de su tiempo de trabajo, porque aún no estaba planificado al 100 %. Después de 6 meses, la comunidad ha recibido solo unas pocas contribuciones, la mayoría de una sola unidad de negocio. La empresa reemplaza al líder de la comunidad con alguien que tiene una historia más larga en la empresa, esta vez solo por el 30 % de su tiempo. Después de otros 6 meses, el número de contribuciones ha aumentado solo marginalmente. La empresa ya no está convencida de que InnerSource ayude a lograr su objetivo de aumentar la colaboración entre divisiones y abandona InnerSource.

Contexto

• La empresa es grande y antigua. No tiene experiencia previa en Open Source u otros modelos de trabajo basados en la comunidad. La cultura de la empresa se caracteriza mejor como un estilo de gestión clásico de arriba hacia abajo: generalmente está en desacuerdo con la cultura comunitaria.

• Aunque hay partidarios y un patrocinador en la alta dirección, la gerencia media de la empresa aún no está convencida de InnerSource.

• La gerencia no estaba convencida de proporcionar más que un presupuesto limitado para financiar solo a un líder de comunidad a tiempo parcial.

• El líder de la comunidad inicialmente seleccionado tiene poca o ninguna experiencia previa con el modelo de trabajo Open Source.

• El líder de la comunidad de desarrolladores inicialmente seleccionado no tiene una red extensa dentro de la empresa.

Resistencias

Si una empresa no invierte significativamente en la comunidad InnerSource inicial en términos de presupuesto y capacidad para InnerSource, la credibilidad de su compromiso con InnerSource podría percibirse como cuestionable. Un impulso común de una empresa con una cultura de gestión tradicional ante un proyecto o iniciativa que no rinde como se esperaba será reemplazar a su líder. Hacerlo sin involucrar a la comunidad y seguir principios meritocráticos socavará aún más el compromiso de la empresa con InnerSource al resaltar la fricción entre la cultura actual de la empresa y la cultura objetivo: una cultura comunitaria.

La contribución de valor de los proyectos InnerSource no será obvia para muchos gerentes que están inmersos en métodos tradicionales de gestión de proyectos. Esos gerentes son menos propensos a asignar a una de sus mejores personas, que generalmente están en alta demanda por proyectos no InnerSource, a un proyecto InnerSource por un porcentaje significativo de su tiempo de trabajo.

La comunicación ocupa un porcentaje significativo del trabajo diario de un líder de comunidad. Al mismo tiempo, él o ella probablemente también tendrá que liderar el desarrollo inicial. Ante la capacidad limitada, los líderes inexpertos tenderán a centrarse en el desarrollo y descuidar la comunicación. La barrera para que los posibles contribuyentes hagan su primera contribución y se comprometan con la comunidad será mucho mayor si el líder de la comunidad es difícil de alcanzar o es lento para responder a los comentarios y preguntas por falta de tiempo. Además, los líderes técnicamente inexpertos probablemente tendrán más dificultades para atraer y retener a contribuyentes altamente experimentados que un alto rendimiento con un alto grado de visibilidad dentro de una empresa.

Si una comunidad no puede crecer lo suficientemente rápido y ganar suficiente velocidad, es probable que no puedan demostrar de manera convincente el potencial de InnerSource.

Si la empresa selecciona a un gerente de proyecto o de línea con experiencia en métodos tradicionales de gestión para ser el líder de la comunidad, es probable que se centre en temas tradicionales de gestión como la asignación de recursos, la provisión de estructura y canales de informes en lugar de liderar con el ejemplo a través de principios meritocráticos. Esto socavará la credibilidad de la iniciativa InnerSource a los ojos de los desarrolladores.

Solución

Selecciona un líder de comunidad que:

• tenga experiencia en el modelo de trabajo Open Source o modelos de trabajo basados en la comunidad similares,

• tenga las habilidades blandas necesarias para actuar como un líder natural,

• lidere con el ejemplo y, por lo tanto, justifique su posición en la meritocracia de la comunidad,

• sea un excelente networker,

• inspire a los miembros de la comunidad,

• pueda comunicarse eficazmente tanto con la alta dirección como con los desarrolladores y

• sea capaz de manejar los aspectos gerenciales del trabajo comunitario.

Empodera al líder de la comunidad para que dedique el 100 % de su tiempo al trabajo comunitario, incluida la comunicación y el desarrollo. Informa a la gerencia sobre la necesidad de ser sensible a las opiniones de la comunidad al generar un cambio en la gestión de la comunidad. Idealmente, empodera a la comunidad para que nomine a un líder de comunidad por sí misma.

Contexto Resultante

Un líder de comunidad con las propiedades descritas anteriormente dará una cara y encarnará el compromiso de la empresa con InnerSource. Hará más probable que otros asociados en su red sigan su ejemplo y contribuyan a InnerSource. Con el tiempo, él o ella podrá construir un equipo central estable de desarrolladores y, por lo tanto, aumentar las posibilidades de éxito del proyecto InnerSource. Al convencer a una audiencia lo suficientemente grande dentro de su empresa del potencial de InnerSource, él o ella hará una contribución importante para cambiar la cultura de la empresa hacia una cultura comunitaria.

Tener líderes de comunidad excelentes y dedicados es una condición previa para el éxito de InnerSource. Sin embargo, no es una solución mágica. Hay muchos desafíos de InnerSource que están más allá de lo que un líder de comunidad puede abordar, como desafíos presupuestarios, legales, fiscales u otros desafíos organizacionales.

Instancias Conocidas

• BIOS en Robert Bosch GmbH. Ten en cuenta que InnerSource en Bosch, en su mayoría, estaba destinado a aumentar la innovación y en gran medida se ocupaba de productos internos. Este patrón actualmente no se usa en Bosch por falta de financiamiento.

• Airbus. Un científico de datos quería mejorar la colaboración con sus compañeros en el grupo y encontró: i) muchos desarrolladores (más allá de la ciencia de datos) también querían eso y estaban felices de que alguien se ocupara del problema, y ii) apoyo del gerente de línea y la gerencia media para eventualmente actuar como el líder de comunidad de facto, además de su línea de trabajo regular.

Alias

Gerente de Comunidad Dedicado

Estado

• Estructurado

Autores

• Georg Grütter (Robert Bosch GmbH)

• Diogo Fregonese (Robert Bosch GmbH)

Agradecimientos

• Tim Yao

• Padma Sudarsan

• Nigel Green

• Nick Yeates

• Erin Bank

• Daniel Izquierdo

Registro de Cambios

• 2016-11-06 - 1ª revisión

• 2017-04-06 - 2ª revisión

Histórico de Traducciones

Title

Herramientas de Comunicación

Patlet

Los usuarios de un proyecto InnerSource tienen dificultades para obtener ayuda y contactar con el equipo anfitrión. Mediante el uso consistente de herramientas de comunicación asincrónica, el proyecto hace que las discusiones sean visibles, archivadas y buscables, lo que conduce a un mejor nivel de soporte para los usuarios.

Problema

Un equipo está abierto a recibir contribuciones de los usuarios posteriores de su componente. Sin embargo, la coordinación y comunicación ocurre de manera improvisada, lo que lleva a compartir información incoherente, retrasos en las respuestas recibidas, y contribuyentes contactando a múltiples miembros del equipo anfitrión antes de recibir una respuesta definitiva.

Contexto

• Un equipo depende del componente de otro equipo.

• Le gustaría hacer contribuciones a ese componente.

• Incluso cuando ocurre por escrito, la comunicación sucede de manera individual.

Resistencias

• El equipo anfitrión está interesado en recibir contribuciones y dispuesto a guiar a los contribuyentes.

• Los equipos tienen una fuerte cultura de comunicación verbal y poca experiencia en establecer canales de comunicación asincrónica específicos para proyectos.

• Los canales de comunicación pueden estar alineados con grupos específicos que deben ser alcanzados pero no por propósito de comunicación.

Solución

El equipo anfitrión debe proporcionar canales de comunicación públicos dentro de la empresa, archivados, buscables y enlazables a los que cualquier persona en la empresa pueda suscribirse, ya que hay beneficios medibles al mantener canales de comunicación escritos y abiertos.

El objetivo al optimizar los canales de comunicación para proyectos InnerSource debe ser alinear la comunicación en torno a temas, no en torno a ciertos grupos de personas.

Un proyecto debe establecer las siguientes herramientas de comunicación:

2. Canales de discusión públicos que tienen una estructura menos rígida. Típicamente, serán listas de correo, foros en línea, sistemas de preguntas y respuestas o incluso canales de chat archivados. Usualmente es suficiente comenzar con solo un canal para el proyecto. Si el tráfico aumenta demasiado, es útil separar las discusiones sobre el uso del proyecto de las discusiones sobre el desarrollo del proyecto.

Aunque la comunicación puede ocurrir fuera de estos canales escritos, se debe traer la mayor cantidad de información posible a los canales asincrónicos.

Los miembros del equipo anfitrión deben esforzarse por dirigir las preguntas que reciben personalmente (por ejemplo, por correo electrónico o mensajes privados) hacia los canales de comunicación oficiales.

Contexto Resultante

Con la comunicación ocurriendo abiertamente, otros pueden seguir fácilmente el progreso del proyecto y participar activamente contribuyendo. Otros observando y leyendo reduce la barrera para involucrarse, aumentando la probabilidad de recibir contribuciones.

Con las preguntas siendo respondidas en público, más personas pueden agregar su perspectiva llevando a una imagen completa - esto incluye no solo a los miembros del equipo anfitrión, sino también a los usuarios del proyecto.

Mantener la comunicación en canales asincrónicos permite que los participantes con diferentes horarios - ya sea debido a diferentes zonas horarias o debido a diferentes rutinas, horarios de reuniones, rutinas de equipo - contribuyan significativamente al proyecto.

Responder preguntas en estos canales significa que no solo otros miembros del equipo pueden escuchar y proporcionar información adicional, sino que también que otros usuarios con la misma pregunta ven (o encuentran más tarde) la respuesta anterior, lo que lleva a una menor necesidad de repetir explicaciones.

Instancias Conocidas

• Europace AG

• Paypal Inc.

• Mercado Libre

Autores

Isabel Drost-Fromm

Agradecimientos

Sebastian Spier (por el visual)

Estado

• Estructurado

• Redactado en Diciembre 2019

Créditos

Histórico de Traducciones

Title

Licencia InnerSource

Patlet

Dos entidades legales que pertenecen a la misma organización quieren compartir código fuente entre sí pero están preocupadas por las implicaciones en términos de responsabilidades legales o contabilidad entre empresas. Una Licencia InnerSource proporciona un marco legal reutilizable para compartir código fuente dentro de la organización. Esto abre nuevas opciones de colaboración y hace explícitos los derechos y obligaciones de las entidades legales involucradas.

Problema

Cuando dos o más entidades legales dentro de una organización quieren compartir código entre sí, necesitan un acuerdo sobre los términos y, a menudo, un contrato legal. Crear tales acuerdos en base a cada proyecto requiere esfuerzo y crea una barrera para compartir. Es decir, un equipo dentro de una entidad legal podría decidir no compartir su código fuente con otra entidad legal en la organización porque parece complicado.

Las barreras para compartir pueden llevar a silos y duplicación de esfuerzos en la reconstrucción de soluciones similares en múltiples partes de la organización.

En el momento de compartir el código fuente, no se puede predecir de manera confiable cuál será el valor de compartir. Si la actividad de compartir requiere un esfuerzo significativo (es decir, negociar términos para el uso), las entidades legales son menos propensas a hacerlo, ya que están preocupadas por el retorno de la inversión.

Contexto

• Una organización grande con muchas entidades legales (subsidiarias) que quieren compartir código. Cuando la organización se hace más grande, el valor de este patrón aumenta.

• Según la definición, las entidades legales tienen sus propios derechos y obligaciones legales.

• Varias de estas entidades legales están desarrollando software y están utilizando servicios de otras entidades legales. Tienen una motivación para contribuir al código fuente de los demás.

• Una complejidad suficiente de la organización y su estructura organizativa.

Resistencias

• Nivel de esfuerzo requerido para redactar acuerdos formales, especialmente si necesitan tener en cuenta perspectivas técnicas, legales y comerciales.

• Una organización grande (compuesta por muchas entidades legales) tiene muchas regulaciones internas. Cualquier nuevo acuerdo que se haga debe cumplir con estas regulaciones, por ejemplo, seguridad, privacidad, procesos de adquisición, etc. El volumen de regulaciones puede dificultar la evaluación de si compartir software entre dos entidades legales es conforme con estas regulaciones, especialmente cuando no hay un procedimiento estándar.

• Si alguna de las entidades legales en la organización tiene un modelo de negocio que depende del código propietario y la contabilidad de las tarifas de licencia dentro de la organización.

• Cultura de la empresa que no está acostumbrada a la colaboración y el intercambio de código InnerSource. Esto resulta en incertidumbre sobre los derechos y obligaciones al usar código compartido.

• La libertad sobre el uso del software lleva a la competencia y a la dispersión de la propiedad.

• Existen contratos legales que cubren el intercambio de código fuente. Estos contratos no están estandarizados, por lo que crean un esfuerzo adicional en la negociación y comprensión para cada proyecto. Los contratos existentes también pueden no permitir compartir código fuente de manera lo suficientemente abierta como para apoyar un verdadero enfoque InnerSource.

• Alternativamente, no hay contratos legales en vigor, pero el código fuente se comparte de manera informal. Eso podría crear incertidumbre en casos donde se necesita claridad sobre la propiedad y los derechos y obligaciones.

• Elegir una licencia restrictiva y/o copyleft puede constituir una barrera para la adopción de InnerSource. Específicamente, limitar la publicación a la organización podría requerir un procedimiento de relicenciamiento costoso antes de la transición a Open Source.

Soluciones

Crear una Licencia InnerSource personalizada a las necesidades de la organización en cuestión (y sus entidades legales). Esta licencia debe ser lo suficientemente genérica como para aplicarse a las relaciones interempresariales más importantes.

Es importante redactar la Licencia InnerSource de manera que realmente permita una colaboración al estilo de código abierto a través de las fronteras de las entidades legales involucradas. Por lo tanto, las 4 libertades del software libre deben integrarse en la licencia.

La Licencia se redacta como un documento legal formal y puede usarse como parte de los contratos entre las entidades legales para regular los acuerdos de intercambio de código.

Contexto Resultante

Con la Licencia InnerSource, tenemos una herramienta para compartir código entre entidades legales dentro de nuestra organización.

La licencia simplifica las conversaciones dentro de nuestra organización sobre el intercambio de código fuente y motiva a las primeras entidades legales a hacerlo.

Nota: El experimento descrito en Instancias Conocidas está en una fase temprana. Por lo tanto, aún no se ha formado un Contexto Resultante firme. En un par de meses, los efectos de la Licencia InnerSource en este espacio de problemas serán más claros y esta sección se podrá actualizar.

Instancias Conocidas

• DB Systel

• Robert Bosch GmbH

• Airbus

• GovTech (Gobierno de Singapur)

DB Systel

Las primeras entidades legales (empresas) dentro de DB AG están utilizando su Licencia InnerSource.

Un efecto positivo que ya se está mostrando es que simplifica la conversación, especialmente si algunas de las partes involucradas no conocen bien el concepto de InnerSource. Las licencias son un concepto bien conocido, por lo que tener una Licencia InnerSource es un excelente punto de partida para la discusión.

Los experimentos también están descubriendo que hay desafíos adicionales de colaboración que deben resolverse para llevar a un verdadero modelo de contribución y colaboración InnerSource.

Los desafíos de colaboración mencionados incluyen:

• hacer que los proyectos con licencia InnerSource sean descubribles

• construir comunidades para la colaboración en proyectos, al igual que en el código abierto

Vale la pena mencionar que hasta ahora el software compartido bajo esta licencia InnerSource es principalmente herramientas, infraestructura y herramientas en niveles inferiores de la pila.

Airbus

Airbus creó licencias InnerSource ad hoc para habilitar la forma de trabajo InnerSource dentro de una gran parte del grupo.

GovTech (Gobierno de Singapur)

GovTech es responsable de la entrega de los servicios digitales del gobierno de Singapur al público. Crearon la Licencia del Sector Público de GovTech (GPSL) como una licencia permisiva para garantizar que el código pueda ser compartido entre entidades legales a través del gobierno. La GPSL cubre tanto el uso del código por parte de los licenciatarios (agencias y sus proveedores) como las contribuciones de vuelta a GovTech. Siguiendo las prácticas de código abierto, el archivo LICENSE de GPSL se incluye en cada repositorio que se pone a disposición como InnerSource.

Estado

• Estructurado

• El experimento listado en Instancias Conocidas está en funcionamiento desde 02/2020. La experiencia inicial muestra primeros efectos positivos, pero se necesita más experiencia para evaluar completamente el patrón.

Autor(es)

• Cornelius Schumacher (DB Systel GmbH)

• Schlomo Schapiro (DB Systel GmbH)

• Sebastian Spier

Referencias

Glosario

• organización - Un paraguas para múltiples entidades legales. (sinónimos: grupo, empresa) (por ejemplo, Lufthansa)

• entidad legal - Una entidad que tiene sus propios derechos y obligaciones legales (sinónimos: empresa, subsidiaria) (por ejemplo, Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH, ...)

Histórico de Traducciones

Title

Portal InnerSource

Patlet

Los contribuidores potenciales no pueden descubrir fácilmente proyectos InnerSource que les interesen. Al crear un sitio web en la intranet que indexe toda la información disponible de proyectos InnerSource, permitirás que los contribuidores aprendan sobre proyectos que podrían interesarles y que los propietarios de proyectos InnerSource atraigan una audiencia externa.

Problema

Los equipos de proyectos InnerSource tienen dificultades para atraer contribuciones externas.

Los proyectos InnerSource en tu organización están aumentando pero los contribuidores potenciales no tienen una forma fácil de descubrirlos.

Historia

Estás intentando establecer una práctica de InnerSource dentro de tu organización. Eres consciente de algunos proyectos que se están ejecutando utilizando un modelo de InnerSource, pero su existencia solo se comunica de boca en boca, por correo electrónico o en conversaciones informales con otros empleados. Como resultado, los propietarios de proyectos InnerSource tienen dificultades para atraer contribuidores.

No existe un recurso único y compartido para que los empleados de toda la organización accedan y descubran fácilmente todos los proyectos InnerSource en curso. Esto está limitando severamente el potencial de crecimiento de cada proyecto InnerSource.

¿Qué se puede hacer para ayudar a todos los proyectos InnerSource a aumentar su visibilidad a la mayor audiencia posible y atraer contribuidores en toda la organización?

Contexto

• Tu organización está interesada en adoptar un estilo de trabajo InnerSource.

• Los propietarios de proyectos InnerSource buscan una manera de atraer audiencias a sus proyectos. Sin embargo, están limitados por los canales de comunicación disponibles a través de los cuales podrían publicitarse a los contribuidores potenciales.

• Los proyectos InnerSource en tu organización están aumentando.

• Agravando este problema está el hecho de que la aplicación de gestión de control de código compartido en uso tiene capacidades de búsqueda tan limitadas que incluso los desarrolladores que buscan proyectos InnerSource encuentran frustrante localizarlos.

Prerrequisitos

• Los gerentes han dado aceptación tácita de que sus empleados participen en proyectos InnerSource.

• Se está utilizando un sistema de gestión de control de código compartido que proporciona acceso programático al contenido de los repositorios que aloja.

• Hay un departamento dentro de tu organización con la responsabilidad de promover la colaboración InnerSource.

Resistencias

• No se está aprovechando completamente el potencial de colaboración entre equipos de ingeniería.

• Es difícil para los individuos descubrir qué proyectos InnerSource existen.

• Es difícil para los propietarios de proyectos InnerSource atraer una audiencia de contribuidores externos.

Soluciones

Crea un sitio web de intranet del Portal InnerSource donde los propietarios de proyectos InnerSource puedan publicitar fácilmente la disponibilidad de sus proyectos.

Las propiedades clave del portal son:

• Los visitantes del Portal InnerSource deberían poder ver todos los proyectos disponibles, así como buscar proyectos específicos basados en varios criterios, como el nombre del proyecto, tecnologías en uso, nombres de contribuidores, unidad de negocio patrocinadora, etc.

• La información mostrada a través del Portal InnerSource debe estar bajo el control total de los propietarios de proyectos InnerSource en todo momento. Preferiblemente, obteniendo esta información directamente de un archivo de datos específico o metadatos almacenados en el propio repositorio del proyecto.

• Los propietarios de proyectos deben incluir toda la información relevante sobre sus proyectos dentro de esos archivos de datos, incluyendo el nombre del proyecto, nombres de contribuidores de confianza, una breve descripción y enlaces al repositorio de código o cualquier documentación de apoyo.

• (opcional) Mientras que la mayoría de las organizaciones optarán por hacer que su portal esté disponible solo en su intranet, algunas organizaciones han optado por hacer que su portal esté disponible en Internet pública. Esto puede ser interesante para organizaciones que desean mostrar información adicional sobre su enfoque InnerSource en su portal, por ejemplo, para fines de marca y reclutamiento.

Al lanzar el portal, se debe considerar una campaña de comunicación que promueva la adición de archivos de datos InnerSource o metadatos a los repositorios de código, para aumentar el número de proyectos mostrados en el portal.

Implementaciones

SAP Project Portal

Wiki

Como una forma simple de comenzar, puedes reservar una página en un wiki interno para listar los proyectos disponibles. Una forma fácil de mostrar esta información es en una tabla con columnas que den un poco de información adicional sobre los proyectos. Intenta tener solo las columnas necesarias para que los espectadores puedan determinar si quieren aprender más sobre el proyecto, pero no más. Demasiada información hará que la página sea abrumadora y difícil de usar. Los individuos y equipos pueden auto-agregar sus proyectos a la página.

Aquí hay un conjunto de columnas de muestra:

• Nombre. Nombre del proyecto (opcionalmente vinculado a su página principal).

• Breve Descripción. Explicando el propósito del proyecto (¿qué problema resuelve?).

• Requisitos Tecnológicos. Debes usar estas tecnologías para incorporarte al proyecto.

• Comenzando. Enlace a instrucciones sobre cómo empezar a usar el proyecto.

• Chat. Enlace a un canal de chat para hacer preguntas sobre el proyecto.

• Equipo Anfitrión. Ver si un equipo está detrás del proyecto puede ayudar a otros a tener la confianza para usarlo.

• En Producción Desde. ¿Cuánto tiempo ha estado el proyecto en un entorno de producción? Ver esta información es un proxy aproximado de su madurez.

• Contribución. Enlace a instrucciones sobre cómo contribuir al proyecto.

Esta solución no permite una visualización elegante, es solo una tabla wiki. Si es importante para ti tener una interfaz de usuario llamativa, entonces esta idea no funcionará para ti. Además, si terminas con muchos proyectos (por ejemplo, cerca de 100), esta solución no escalará para permitir la búsqueda y filtrado o la actualización automática de las entradas de proyectos que probablemente necesitarás. Es una buena solución para un portal con unas pocas docenas de proyectos, sin embargo.

Contexto Resultante

• El Portal InnerSource ha permitido a los propietarios de proyectos InnerSource publicitar sus proyectos a una audiencia a nivel de toda la organización. Debido a esta mayor visibilidad, están atrayendo comunidades de contribuidores mucho más grandes que nunca antes.

• Para aquellos que buscan involucrarse en proyectos InnerSource, el Portal InnerSource les ha permitido descubrir exactamente el tipo de oportunidades que les interesan al buscar en todos los proyectos InnerSource disponibles simultáneamente según sus criterios específicos.

• Satisfacer las necesidades de ambas audiencias ha ayudado a establecer InnerSource como una opción viable y atractiva para todas las áreas de la organización para lograr cosas juntos que no podrían haber logrado por separado.

Instancias Conocidas

• Una gran organización de servicios financieros ha utilizado la creación de un Portal InnerSource para proporcionar un mecanismo de publicidad y descubrimiento de proyectos InnerSource en existencia en diferentes unidades de negocio.

• Elbit Systems ha utilizado este patrón y ha añadido gamificación encima.
• Banco Santander ha creado un portal público llamado "Santander ONE Europe InnerSource Community" para apoyar e incrementar la adopción de InnerSource. Además del catálogo de proyectos, el portal incluye contenido relevante como documentación, forma de trabajo, noticias y eventos.

• WellSky tiene una simple página de Confluence Wiki donde se enumeran los proyectos InnerSource y reutilizables.

Referencias

Estado

• Estructurado

Autor(es)

• Stephen McCall

Agradecimientos

• Shelly Nizri

• Melinda Malmgren

• Michael Graf

• Jesús Alonso Gutierrez

Histórico de Traducciones

Title

Mercado de Gigs

Patlet

Establece un mercado creando un sitio web interno donde se publiquen necesidades específicas de proyectos InnerSource como "Gigs" con requisitos explícitos de tiempo y habilidades. Esto permitirá a los gerentes comprender mejor el compromiso de tiempo de sus empleados y los beneficios profesionales, aumentando así la probabilidad de obtener aprobación para realizar contribuciones InnerSource.

Problema

Ni los gerentes ni los empleados comprenden cómo podrían beneficiarse al involucrarse en un proyecto InnerSource.

Es difícil para los empleados comunicar a sus gerentes el compromiso de tiempo que necesitarán dedicar a un proyecto InnerSource.

Los gerentes no tienen una forma uniforme de dar seguimiento o recompensar la participación de sus empleados en proyectos InnerSource.

Historia

Has creado exitosamente un programa InnerSource en tu empresa y cuentas con el respaldo de la alta dirección, mandos medios y desarrolladores. Sin embargo, después de casi un año, ha habido pocas contribuciones reales a proyectos InnerSource fuera de los equipos que los crearon originalmente. Después de entrevistar a todas las partes involucradas, el principal punto de fricción parece ser que es difícil conocer el compromiso de tiempo que se pedirá a los desarrolladores si deciden involucrarse en un proyecto InnerSource y cómo se beneficiarán personalmente. También hay una falta de una forma uniforme de anunciar qué oportunidades para contribuyentes existen, qué se les pedirá que hagan y aproximadamente cuánto tiempo podría tomar. Los gerentes son solidarios y quieren que sus empleados participen, pero hasta ahora han carecido de una forma de contabilizar o recompensar las actividades de sus empleados dentro de los proyectos InnerSource. ¿Qué se puede hacer para mejorar esta situación para todas las partes involucradas (propietarios de proyectos InnerSource, posibles contribuyentes y gerentes de desarrollo)?

Contexto

Los empleados desearían poder conocer las actividades que se llevan a cabo en otras áreas de la empresa sin tener que dejar sus puestos actuales. Existen proyectos InnerSource que podrían proporcionar estas experiencias, pero hay dos factores principales que impiden que los empleados participen. Primero, la incapacidad de descubrir fácilmente qué oportunidades de contribución existen dentro de los proyectos InnerSource en curso y comunicarlas a sus gerentes. Segundo, la incapacidad de los gerentes para planificar y contabilizar los compromisos de tiempo de sus empleados en estas tareas de proyectos InnerSource. Como resultado, los propietarios de proyectos InnerSource encuentran difícil construir comunidades de tamaño suficiente para cumplir con sus objetivos declarados.

Resistencias

• Los empleados no tienen una forma fácil de descubrir qué oportunidades InnerSource existen

• Los empleados no entienden cómo contribuir podría beneficiarlos profesionalmente

• Los gerentes no comprenden los requisitos de tiempo/esfuerzo asociados con las tareas relacionadas con proyectos InnerSource

Prerrequisitos

• Los empleados han recibido tiempo de sus gerentes para involucrarse en proyectos InnerSource

• Los gerentes requieren una forma de cuantificar, rastrear y registrar las contribuciones InnerSource para que puedan ser contabilizadas y recompensadas

Soluciones

Crea un sitio interno basado en “Gigs” donde las personas puedan anunciar sus habilidades y áreas de interés y los propietarios de proyectos InnerSource puedan anunciar oportunidades de colaboración.

Los empleados deberían poder crear un perfil dentro de la aplicación en el que puedan listar sus habilidades y áreas de interés. El sistema debería aprovechar esta información informando proactivamente a las personas (por correo electrónico u otro medio) cuando se publique un Gig que coincida con uno o más de esos criterios.

Cada Gig publicado por un propietario de proyecto InnerSource debería incluir los requisitos estimados de habilidades y tiempo para que puedan ser fácilmente emparejados con un empleado disponible y comunicados claramente a su gerencia directa. La descripción también debería incluir una justificación de cómo beneficiará a la persona que asuma la tarea para hacerla lo más atractiva posible.

Se podría crear un sistema basado en puntos para recompensar y rastrear la participación de un empleado en un Gig. Por ejemplo, 10 puntos otorgados al propietario del Gig por publicar un Gig una vez que se complete y 100 puntos para un desarrollador que complete un Gig. Los puntos acumulados al completar Gigs podrían usarse como un mecanismo de gamificación y como criterio de gestión del rendimiento para obtener información sobre las áreas de especialización que existen dentro de una organización.

Aquellos que deseen aceptar un Gig primero deberían ser evaluados por el propietario del Gig para determinar que el empleado tiene las habilidades y el tiempo asignado por su gerente para completar el Gig.

La transparencia de las contribuciones realizadas a través de Gigs puede ayudar a un contribuyente a construir (o perjudicar) su reputación, creando así una mayor probabilidad de que la calidad de la contribución sea alta. La finalización de Gigs también puede actuar como prueba de experiencia en un área particular.

La naturaleza de los Gigs publicados en el mercado puede incluir tanto habilidades duras como blandas, como organizar un evento grupal, escribir un informe o solicitudes de mentoría, etc.

La creación del Mercado de Gigs debería ser idealmente asumida por un equipo dentro de una organización con la responsabilidad de proporcionar infraestructura y capacidades a nivel de toda la empresa.

Contexto Resultante

El Mercado de Gigs InnerSource ha aumentado enormemente el número de proyectos InnerSource, así como el número de empleados involucrados en ellos. La naturaleza autodirigida del Mercado de Gigs ha mejorado la satisfacción laboral de los empleados al permitirles un nivel de elección en el trabajo que realizan y con quién pueden asociarse en toda la empresa. Los empleados entienden exactamente a qué se están inscribiendo y qué pueden esperar de la experiencia. Los gerentes pueden estimar y rastrear mejor los compromisos de tiempo de sus empleados con respecto a los proyectos InnerSource, reconocer sus esfuerzos individuales y usar la finalización de Gigs como una forma de validar sus habilidades específicas. Los gerentes también pueden aprovechar cualquier tiempo de inactividad que sus empleados puedan estar experimentando permitiéndoles pivotar al trabajo disponible en el Mercado de Gigs. Los datos generados por las interacciones dentro del Mercado de Gigs también están ayudando a impulsar decisiones de contratación y capacitación en todos los departamentos.

Cuando se usa en combinación con el patrón del Portal InnerSource, el Mercado de Gigs proporciona un nivel más fino de contexto y detalle además de los enlaces a los repositorios de código y la documentación del proyecto al que se relaciona el Gig.

Instancias Conocidas

• Una gran organización de servicios financieros ha utilizado la creación de un sitio web del Mercado de Gigs InnerSource para fomentar su programa InnerSource.

• SAP implementó el patrón del Mercado de Gigs: se agregó un nuevo programa InnerSource a la plataforma de trabajo interna donde se pueden publicar posiciones y ofertas similares.

Estado

• Estructurado

Autor(es)

• Stephen McCall

• Shreyans Dugar

Histórico de Traducciones

Title

Reconocimiento a los Participantes

Patlet

Cuando recibes una contribución InnerSource, es importante agradecer al contribuidor por su tiempo y esfuerzo. Expresar tu gratitud no solo reconoce efectivamente la contribución sino que también genera mayor compromiso del contribuidor y otros. Reconocer las contribuciones positivas de los contribuidores a tu proyecto InnerSource motiva a estos contribuidores (y sus gerentes) a continuar invirtiendo en el esfuerzo.

Problema

¿Cómo podemos expresar adecuadamente nuestra gratitud a un contribuidor por su contribución a un proyecto InnerSource? Puede que no sepamos exactamente qué palabras o canales de comunicación usar para expresarnos sinceramente. Pero reconocer y agradecer a los contribuidores es fundamental para mantener a esos contribuidores (y sus gerentes) comprometidos con el trabajo. Afortunadamente, el reconocimiento efectivo de los participantes sigue un patrón, y seguirlo ayuda a garantizar que nuestros mensajes de agradecimiento se transmitan de manera clara y amable. También nos hace menos propensos a olvidar agradecer a nuestros contribuidores, lo cual es desafortunadamente demasiado fácil de hacer.

Contexto

• Eres el Trusted Committer o mantenedor de un proyecto InnerSource.

• Valoras la comunidad de contribuidores y quieres mantenerla y hacerla crecer.

Resistencias

• Estás ocupado, lo que hace que sea más fácil olvidar algunos toques cualitativos (como el reconocimiento y el agradecimiento).

• Puede que no seas alguien que se sienta cómodo en situaciones sociales o que sea bueno con las palabras.

• El reconocimiento de los compañeros es muy importante para la satisfacción laboral y el desarrollo profesional.

Soluciones

Ser reconocido por otros se siente bien. Y en un entorno profesional, el reconocimiento de los compañeros también puede aumentar tu influencia organizacional y tu crecimiento profesional. Cada vez que alguien contribuya a tu proyecto InnerSource, reconócelos con un "gracias" auténtico y sincero. Asegúrate de resaltar ejemplos específicos de cómo estas contribuciones han impactado positivamente el proyecto.

Para contribuciones no triviales (todas las contribuciones de código y contribuciones de tiempo significativas), di "gracias" a través de los siguientes mecanismos:

(1) Menciona a la persona por su nombre en cualquier lugar de chat (por ejemplo, Slack) donde organizes la actividad de tu proyecto. Haz saber a todos lo que hicieron y agradéceles públicamente.

Ejemplo:

Todos @aquí denle un aplauso a @andrew.clegg por actualizar el rcs-viewer a la última versión del hebo-client (https://github.com/rcs/rcs-viewer/pull/81). ¡Gracias por ayudar a mantener esta librería actualizada, Andy!

(2) Envíales un correo electrónico a ellos y a su gerente (con copia) en privado, agradeciéndoles por la contribución. Para contribuciones de código, considera reenviar el correo de notificación de la fusión.

Ejemplo:

Hola, Andy, quiero agradecerte nuevamente por hacer esta actualización. Puede que haya sido una pequeña cantidad de tiempo, pero es la atención como esta de cada persona lo que hace que el proyecto RCS funcione para todos nosotros. Gracias por resolver tu propio problema de una manera que también mejora el rcs-viewer para todos.

Contexto Resultante

Comentarios como este dejan al contribuidor con una sensación fantástica y listo para volver a participar en el proyecto. Combinar ambas formas de agradecimiento les da reconocimiento frente a sus compañeros (amplitud) y frente a su gerente directo (profundidad). Hay un sutil estímulo para que esos compañeros en el chat consideren contribuir ellos mismos y para que ese gerente busque circunstancias apropiadas para alentar a sus otros subordinados directos a hacer lo mismo. Además, la conciencia del proyecto InnerSource se extiende al gerente, quien puede no haber conocido previamente el uso y la participación del equipo en él.

Una advertencia: manténlo real. Asegúrate de que tus palabras provengan del sincero agradecimiento que sientes por lo que han hecho. Mantén el nivel y la verbosidad del reconocimiento apropiados a su nivel de participación. Exagerar puede parecer insincero y mecánico y frustrar tu propósito al comunicarte.

Patrones Relacionados

• Just Say Thanks (del libro Fearless Change)

Instancias Conocidas

• Nike (múltiples proyectos)

• SAP - Las iniciativas InnerSource como los proyectos Dojo y Everest se elevan por el patrón 'Reconocimiento a los Participantes', donde el programa SAP Appreciate juega un papel clave en fomentar una cultura de gratitud y reconocimiento, llevando la innovación y la colaboración a nuevas alturas. Ver: InnerSource: First Contribution Explored

Estado

• Estructurado

Autor(es)

• Russ Rutledge

Agradecimientos

• Todd Lisonbee por alentar a "mantenerlo real."

• Isabel Drost-Fromm por esta explicación adicional de la importancia de proporcionar ejemplos específicos de cómo la contribución ha impactado positivamente el proyecto.

Histórico de Traducciones

• 2025-04-03 - Traducción Oscar Lobaton S.

• 2025-04-03 - Traducción Roman Martin Gil

Title

Servicio vs Librería

Patlet

Los equipos en un entorno DevOps pueden mostrarse reacios a trabajar a través de los límites del equipo en bases de código comunes debido a la ambigüedad sobre quién será responsable de responder ante la interrupción del servicio. La solución es entender que, en muchos casos, se puede desplegar el mismo servicio en entornos independientes con rutas de escalamiento separadas para manejar interrupciones del servicio, o bien extraer gran parte del código compartido en una librería y colaborar en ella.

Problema

Cuando los equipos trabajan en un entorno DevOps, los desarrolladores son responsables de una característica de principio a fin: desde el cliente hasta el despliegue, mantenimiento y soporte. Esto plantea un desafío al trabajar a través de los límites del equipo: las cadenas de escalamiento pueden no ser las mismas para los errores que ocurren en cualquiera de los equipos. Acoplar el código fuente y el despliegue deja a los equipos con la pregunta de quién es responsable del soporte en caso de errores. Como resultado, los equipos son reacios a unir fuerzas incluso si hay una superposición significativa en los requisitos.

Contexto

• Los equipos están trabajando en un entorno de microservicios.

• Están organizados en equipos DevOps completamente funcionales: cada equipo es responsable de sus contribuciones de principio a fin, incluyendo mantenimiento, soporte y atención al cliente.

• Un equipo tiene la tarea de proporcionar un servicio a sus clientes downstream que es bastante similar a un servicio existente construido por otro equipo.

Resistencias

• Las rutas de escalamiento organizacional pueden ser diferentes para cada uno de los equipos.

• Los miembros de cada equipo pueden no estar dispuestos a responder al soporte en caso de errores que no afectan a sus propios clientes downstream.

• Los niveles de severidad para los mismos tipos de errores pueden ser diferentes a través de los límites del equipo debido a diferentes definiciones de SLA por equipo/relación con el cliente.

• Los equipos pueden tener diferentes restricciones de seguridad o regulatorias que gobiernan sus despliegues.

Soluciones

Desacoplar la responsabilidad del código fuente del despliegue: ambos equipos trabajan para identificar exactamente dónde hay superposición y sinergias.

Solo el código fuente compartido se mantiene como parte del proyecto InnerSource con responsabilidad compartida. El código compartido debe ser coherente en que incluye todo el código de prueba (incluyendo pruebas de integración si están disponibles) y tanto de la tubería de CI como sea posible para facilitar la validación de contribuciones.

Desacoplar las configuraciones de despliegue y las tuberías de CI del negocio real. Establecer un segundo despliegue del servicio para el segundo equipo.

Tratar la base común como una librería que es utilizada por ambos equipos con propiedad compartida del código.

Las configuraciones de despliegue pueden incluirse como proyectos separados en su portafolio de InnerSource para permitir a los equipos discutir/colaborar o a un nuevo equipo copiarlas.

Contexto Resultante

Los equipos están dispuestos a colaborar, beneficiándose de compartir el trabajo de implementar la lógica de negocio.

Un servicio que originalmente fue construido específicamente para funcionar en un entorno se convierte en una solución más general basada en un requisito de negocio específico.

Ambos equipos llegan a conocer su respectiva política de escalamiento y configuración de despliegue, identificando potencialmente mejoras para su propia configuración.

La probabilidad de que se necesiten y realicen cambios en el código fuente compartido aumenta, lo que lleva a más oportunidades frecuentes para refinar, mejorar y optimizar la implementación.

Fomenta la estandarización operativa incremental en el empaquetado de lanzamientos, telemetría, puntos de salud/preparación, etc., a medida que los equipos se dan cuenta de que pueden mantener esto de manera más eficiente en el código compartido si acuerdan convenciones estándar.

Ver también

Relacionado con este patrón está el patrón Garantía de 30 Días que toma un enfoque diferente para resolver las resistencias descritas anteriormente.

Instancias Conocidas

• Europace AG

• Flutter Entertainment: Una aplicación InnerSource de Flutter tiene un repositorio de "servicio" de código compartido con contribución entre equipos y una tubería de CI para construir y publicar un artefacto de lanzamiento compartido. Cada equipo adoptante tiene un repositorio de "configuración de despliegue" que define su propio despliegue. Esto es impulsado por diferentes requisitos regulatorios, prácticas de gestión de servicios e incidentes y conjuntos de habilidades de infraestructura en diferentes áreas del negocio.

• WellSky (ver InnerSource Continuo en Producción - 5 Veces)

Estado

• Estructurado

Autor(es)

• Isabel Drost-Fromm

• Rob Tuley

Agradecimientos

Gracias a Tobias Gesellchen por la revisión interna en Europace AG.

Alias

Servicio vs. librería: Es InnerSource, no despliegue interno

Histórico de Traducciones

• 2025-04-03 - Traducción Oscar Lobaton S.

• 2025-04-03 - Traducción Roman Martin Gil

Misión

Esta sección debe contener una breve descripción (3-5 oraciones) de la misión de su proyecto. El objetivo es indicar en qué planea trabajar y ayudar a los contribuyentes externos a comprender aproximadamente qué tipos de funcionalidades serán probablemente bienvenidas para este proyecto.

Consulte también el capítulo de declaración de misión en Producing Open Source Software.

Primeros Pasos

Esta sección debe contener documentación breve escrita para usuarios principiantes sobre cómo comenzar a usar el proyecto. Se puede vincular a documentación más detallada desde aquí.

Información Adicional

Esta sección puede enumerar cualquiera o todos los siguientes elementos:

• Lista de funcionalidades, casos de uso que el software aborda.

• Información sobre principios de diseño utilizados para resolver compensaciones

• Enlaces a documentación adicional a nivel de usuario

• Respuestas a preguntas frecuentes (FAQ), preferiblemente en un formato que permita vincular preguntas específicas y sus respuestas para una referencia más fácil.

Obtener ayuda

Esta sección debe contener documentación breve sobre cómo obtener ayuda para el proyecto como usuario. Esto podría ser tan simple como dirigir a los usuarios al gestor de tareas si así es como su proyecto desea responder preguntas. También podría apuntar a un canal de chat archivado y consultable, alguna lista de correo archivada consultable, o algún foro de usuarios en línea.

Involucrarse

Esta sección debe incluir información sobre cómo ponerse en contacto con el proyecto:Típicamente contendrá enlaces a canales de comunicación archivados, consultables y vinculables.

Quiénes somos

Este es un buen lugar para dar crédito a los Trusted Committers del proyecto.

También es un buen lugar para incluir información sobre lo que significa ser un Trusted Committer para este proyecto - aunque idealmente todos los proyectos en una organización utilizan la misma definición que solo se vincula desde aquí. La razón para mantener el enlace aquí es para colegas que tienen poca o ninguna experiencia trabajando y contribuyendo a proyectos InnerSource para tener un enlace directo a la información de toda la empresa desde los proyectos tecnológicos que necesitan para su trabajo diario.

Contribuir

Esta sección debe documentar (o vincular a documentación) sobre todo lo que un contribuyente principiante necesita saber para comenzar. Típicamente no se cubrirán todos los temas a continuación. Concéntrese en lo que difiere en su proyecto de la configuración estándar y lo que los contribuyentes anteriores encontraron difícil de entender.

• Encontrar el código fuente.

• Encontrar una lista de issues que su proyecto necesita ayuda - estos pueden ser tanto técnicos como no técnicos. Típicamente los mantendrá en un gestor de tareas accesible para los contribuyentes.

• Enlaces a documentación adicional, por ejemplo, sobre la arquitectura del proyecto, convenciones de codificación generales, convenciones de prueba...

• Para contribuciones técnicas: Realizar cambios, construir el proyecto y probar sus cambios.

• Enviar sus cambios de vuelta al proyecto.

Idealmente también incluye información sobre cómo es el proceso preferido de cambios para el proyecto: ¿Deberían los contribuyentes primero abrir un issue y enviar una propuesta, o son bienvenidos a enviar cambios de inmediato? ¿Qué es importante para usted al revisar contribuciones?

Además, debe describir cualquier valor de diseño que desee seguir en el proyecto. Hacer estos explícitos a menudo ayuda a resolver compensaciones más rápida y fácilmente. Además, ayuda a hacer transparentes los cambios en suposiciones que de otro modo serían implícitas.

Con el tiempo notará que esta sección crece sustancialmente. En ese caso, piense en mover la información a archivos separados, por ejemplo, CONTRIBUTING.md y TESTING.md.

Tipos de contribuciones

Proporcione información aquí sobre qué tipos de contribuciones busca su proyecto. Por ejemplo, pueden ser reportes de errores (bug reports), ayuda para responder preguntas de usuarios, mejoras en la documentación, corrección de errores y también implementación de nuevas funcionalidades.

Por favor, sigue estos pasos para contribuir a este proyecto:

Reportes de errores

Agregue aquí información sobre cómo enviar reportes de errores. Esto debe incluir sugerencias sobre el tipo de información que el proyecto necesitará para reproducir y corregir problemas. También puede incluir información sobre configuraciones incorrectas comunes que parecen errores.

También incluya información sobre qué pueden esperar los contribuyentes en términos de tiempo de primera respuesta y proceso posterior.

• Si tienes preguntas, abre un problema en el gestor de tareas (issue tracker).

Solicitudes de funcionalidades

Agregue aquí información sobre cómo enviar solicitudes de funcionalidades. También incluya información sobre qué pueden esperar los contribuyentes en términos de tiempo de primera respuesta y proceso posterior.

Contribuir documentación

Incluya información sobre las mejores prácticas de documentación que sigue su proyecto, así como cómo construir la documentación, las verificaciones que debe ejecutar y cómo enviar los cambios realizados al proyecto.

Contribuir código fuente

Esta sección debe contener información sobre:

• Cómo acceder al código fuente del proyecto,

• Estructura general del proyecto,

• Requisitos para el entorno de desarrollo,

• Pautas de formato de código,

• Cómo ejecutar el conjunto de pruebas.

Cómo convertirse en Trusted Committer

Esta sección debe hacer explícito el proceso para convertirse en Trusted Committer si esa ruta está abierta a los contribuyentes.

Cómo nominar Trusted Committers

Esta sección sirve como recordatorio para los existentes y explicación para nuevos Trusted Committers detallando cómo agregar otros al equipo central. Idealmente, esta información es idéntica para todos los proyectos en la organización, por lo que se puede vincular a la información central desde aquí.

Title

Valoración de Proyectos Transversales

Patlet

Es difícil demostrar el valor de los proyectos InnerSource cross-team que no proporcionan un impacto directo en los ingresos de la empresa. Aquí hay una forma basada en datos para representar tu proyecto que articula y amplifica su valor.

Contexto

• Eres responsable de un equipo cross-team que sirve como plataforma para otros en la empresa.

• El proyecto cross-team no genera ningún valor directo para los ingresos de la empresa.

Problema

Los proyectos cross-team pueden tener potencialmente un gran impacto en la empresa, pero son difíciles de representar de manera basada en datos. Como resultado, es fácil y común perseguir proyectos que no proporcionan valor real o subfinanciar lo que de otro modo produciría gran valor.

Resistencias

• Los proyectos necesitan mostrar valor (objetivo o subjetivo) al liderazgo de la empresa para ser financiados.

• El valor del proyecto cross-team está disperso a través de múltiples unidades de negocio finales.

• Debido a esta dispersión, el valor del proyecto cross-team es difícil de medir directamente.

Solución

Establece un patrón y modelo sobre cómo valorar proyectos cross-team. Estos modelos nos proporcionan las herramientas necesarias para enfocar y amplificar la colaboración de alto valor para la empresa.

El núcleo de todo el valor del proyecto cross-team es la idea de que podemos hacer más juntos que separados. Asignar valor a un esfuerzo cross-team es un ejercicio de cuantificar cuánto más se está logrando juntos. El delta exacto en productividad variará según el dominio y el proyecto. Hay un proceso común, mediante el cual puedes crear un modelo para calcularlo.

Explicación

Reúne un pequeño equipo de expertos en tu dominio. Usando ese equipo de expertos, estima 4 cosas sobre cada consumidor de la salida de tu proyecto:

• ¿Cuánto tiempo les lleva consumir el output de tu proyecto?

• ¿Cuánto tiempo les llevaría de otra manera crear por sí mismos el valor de la salida de tu proyecto?

• ¿Qué porcentaje de la salida de tu proyecto es realmente útil para ellos?

• ¿Cuánto tiempo de manera continua (idealmente por uso) gastarían de otra manera manteniendo su solución propia?

Al hacer estas estimaciones, es imposible saber con alta precisión exactamente cuánto tiempo toman las actividades. Ese no es tu objetivo. En lugar de exactitud, debes esforzarte por establecer un límite de peor caso en estas estimaciones. La idea es que el grupo de expertos pueda decirse entre sí, "No sabemos exactamente cuánto tiempo tomaría, pero todos podemos estar de acuerdo en que es al menos esto." Específicamente, debes estimar un tiempo razonable máximo para consumir la salida de tu proyecto y tiempos razonables mínimos para que los consumidores creen, usen y mantengan sus propias soluciones.

Una nota sobre el costo de "crear tu propia solución" (home-roll). El costo de crear una solución propia NO es necesariamente (de hecho, es muy poco probable) el mismo que el costo de hacer una solución compartida. A menudo, para la misma funcionalidad, la modularidad y calidad involucradas en la construcción de una solución compartida entre equipos hace que sea una inversión notablemente mayor que una implementación rápida y codificada utilizada solo una vez.

Fórmula

Una vez que tengas tus límites de peor caso, puedes valorar la salida de tu proyecto cross-team durante un período de tiempo dado mediante la fórmula simple:

[Tiempo Ahorrado] - [Tiempo Invertido]

([Cantidad de Nuevas Incorporaciones] * [Costo de Crear Propia Solución] * [Porcentaje de Funcionalidad Útil] + [Cantidad de Usos] * [Costo de Mantenimiento por Uso]) - ([Cantidad de Nuevas Incorporaciones] * [Costo de Incorporación])

[Cantidad de Nuevas Incorporaciones] * ([Costo de Crear Propia Solución] * [Porcentaje de Funcionalidad Útil] - [Costo de Incorporación]) + [Cantidad de Usos] * [Costo de Mantenimiento por Uso]

Comentario

A pesar de las apariencias de rigor, este proceso no produce una forma exacta de medir la salida del proyecto cross-team. En la práctica, sin embargo, proporciona un marco mediante el cual puedes tomar una decisión fundamentada sobre cómo financiar este trabajo. Después de tener datos buenos y razonables según la explicación anterior, debes financiar horas de desarrollo dedicadas a ejecutar el proyecto hasta al menos uno de los siguientes tres niveles:

1. Las horas brutas ahorradas por la fórmula anterior. Dado que todos estamos seguros de que la fórmula producirá un número que está por debajo del verdadero número de horas ahorradas, puedes tener la confianza de que financiar el proyecto hasta ese punto es una victoria segura para ti.

2. La cantidad de tiempo que lleva apoyar las contribuciones internas a los proyectos cross-team. Dado que el contribuyente probablemente habría hecho el trabajo de todos modos de manera única, vale la pena financiar el tiempo que lleva facilitar que su trabajo se incluya en una ubicación compartida.

3. Lo que te parezca bien. Un efecto secundario intencional de tener una fórmula de valoración es que naturalmente fuerza la medición de los puntos clave de uso que proporcionan valor a los consumidores.

Esas mediciones pueden ser entendidas y consumidas en su forma bruta para proporcionarte una idea intuitiva de cuán valioso es el proyecto.

Algunos pueden estar preocupados por la falta de precisión en este enfoque de valoración. Está bien que este proceso no proporcione una medición exacta. Solo necesita ser lo suficientemente preciso para cumplir 2 propósitos:

1. Proporcionar un medio para representar el valor de lo que está sucediendo a aquellos que están organizando y financiando esfuerzos cross-team.

2. Ayudar a los involucrados a saber qué áreas del esfuerzo cross-team son de mayor prioridad para perseguir según su valor.

En la práctica, siempre que estas valoraciones estén dentro de un orden de magnitud de la realidad y entre sí, son lo suficientemente precisas para cumplir estos propósitos. Proporcionarán una mejora notable en los resultados sobre el terreno en comparación con las valoraciones ad hoc (y los efectos resultantes) descritos en la sección Problem al comienzo de este documento.

Contexto Resultante

• Medios basados en datos para discutir el valor y financiamiento del proyecto cross-team con el liderazgo.

• Métricas clave alrededor del proyecto cross-team instrumentadas en forma bruta.

• Definir cómo el proyecto cross-team proporciona valor tiende a llevarlo a producir realmente mayor valor para la empresa.

• Proyecto generalmente exitoso y "buzz" a su alrededor.

Instancias Conocidas

• Nike

Estado

• Estructurado

• Probado en múltiples dominios.

Autores

• Russ Rutledge

Reconocimientos

• Jeremiah Wright por enseñarme a pensar en los proyectos cross-team como un negocio interno que opera en la moneda del tiempo del desarrollador.

Histórico de Traducciones

• 2025-04-03 - Traducción Oscar Lobaton S.

• 2025-04-03 - Traducción Roman Martin Gil

Coloque un archivo COMMUNICATION.md adaptado al proyecto en cada repositorio. Si la propiedad del repositorio del proyecto se transfiere a un equipo diferente en el futuro, necesitarán poder acceder y editar la documentación relacionada con el proyecto. Esto incluye la documentación que describe los procesos de comunicación que los usuarios deben usar para contactar al equipo.

Elimine el párrafo superior cuando esta sección esté completa.

Comunicación del Equipo

Canal de Slack del equipo:

Canales especiales de Slack: (temas específicos y accesibles para cualquier contribuyente externo)

Correo del equipo:

Cómo Contactarnos

Los siguientes tipos de acciones pueden moverse a la sección apropiada y se pueden agregar más.

Roles y Responsabilidades

Gerentes o roles y situaciones específicas por las que deben ser contactados fuera del canal del equipo.

(está configurado de esta manera para que el documento pueda cambiarse fácilmente si hay nuevos miembros en el equipo)

Comunicación Externa

Contactos de Documentación

Explique cómo encontrar al propietario, parte responsable o grupo al que las personas deben contactar si tienen preguntas sobre la documentación en el repositorio.

Describa este proceso de comunicación.

Por ejemplo:

• Si tiene preguntas sobre una pieza específica de documentación, puede encontrar al miembro del equipo responsable de la información aquí:

• Puede contactar a la parte responsable enviando un mensaje en el canal xyz, enviándoles un mensaje directo en chat, correo electrónico, etc. La persona que certificó la documentación por última vez es la parte responsable.

This glossary defines essential terms that are commonly used when writing new patterns. It focuses on key terms and resolves ambiguities where necessary.

Through this the glossary helps members of the Patterns Working Group to use consistent language when writing and reviewing patterns.

• legal entity - An entity that has its own legal rights and obligations (synonyms: company, subsidiary) (e.g. Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH, ...)

• organization - An umbrella for multiple legal entities. (synonyms: group, enterprise) (e.g. Lufthansa)

• project - Projects serve as a planning and tracking tool that can integrate with the issues and pull requests within one or more repositories. In GitHub documentation, projects are described as an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests to help you plan and track your work effectively. A single project can include items (e.g. issues and pull requests) from multiple repositories.

• repository - A repository is a central location for source code, files, where each file's revision history is stored and managed. It enables version control and collaboration among multiple contributors. Repositories are designed to facilitate collaboration, discussion, and management of work through features like issues, pull requests, and project boards. A single repository can be associated with multiple projects.

Note that his glossary is far from complete. If you see terms that are used frequently in our patterns and should be defined in this glossary, please add them.

Title

Short Title Here

Patlet

Concise 1-2 sentence description of the problem and solution. Readers may quickly review dozens of these patlets to discover and browse the larger library of patterns. From http://wiki.c2.com/?PatLet

Problem

What is the problem - crisp definition of the problem. Short description, usually not more than a couple sentences, that describes what the issues and challenges are. Be careful not to morph into information found in other sections below.

Story (optional)

Sometimes there is a story that helps people understand the pattern better.

Context

Where does the problem exist? What are the pre-conditions? Unchangeable before the solution goes into place. The content here is often tied to the applicability of the pattern for other readers: "Do I have this same particular situation?"

Forces

What makes the problem difficult? What are the trade-offs? These are constraints that can be changed at a cost. The solution might change one or more of these forces in order to solve the problem, while also in-turn changing the context.

Sketch (optional)

visual illustration

Solutions

Verified resolutions and possible resolutions to the problem.

Resulting Context

What is the situation after the problem has been solved? The original context is changed indirectly by way of the solution. Often this section can include discussion of the next possible Patterns/problems introduced. This section can be short in content - the solution may not introduce new problems or change much context.

Rationale (optional)

Explains why this is the right solution; using totally different words WHY this solution balances these forces and this context to solve this problem. Can expand on what-if's or theories.

Known Instances (optional)

Where has this been seen before? Helps to reinforce that this is a REAL pattern and that you match the context.

May mention:

• A particular business

• Anonymized instances ex: "3 companies have proven that this is a good solution" or "A large financial services org...".

Status (optional until merging)

General pattern status is stored in GitHub's Label tagging - see any pull request. Note that this GitHub label tagging becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful.

You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs John's expertise before it can go further."

Author(s) (optional)

Often, this is yourself. If you need to, find someone in the InnerSource Commons to be the nominal author (As Told To). Could also be no-one if you do not want to take on authorship (common with a donut looking for a solution).

Acknowledgments (optional)

Include those who assisted in helping with this pattern - both for attribution and for possible future follow up. Though optional, most patterns should list who helped in their creation.

Alias (optional)

If this pattern is also known under a different name than what is listed unter Title, please list those alternative titles here. e.g. if the pattern is named after the problem it solves, a helpful alias might be one that describes the solution that is applied.

• Nombre de la Funcionalidad: (rellénalo con un identificador único, mi_funcionalidad_asombrosa)

• Fecha de Inicio: (rellénalo con la fecha de hoy, YYYY-MM-DD)

• Propietarios nominados: (Representantes de las áreas técnicas afectadas por el RFC. A menudo serán líderes técnicos, pero pueden delegar. Los RFC no pueden ser aceptados hasta que todos los propietarios nominados hayan dado su aprobación.)

Resumen

Explicación en un párrafo de la funcionalidad.

Retrospectiva

Esta sección es esencial para permitirnos aprender de las cosas que estamos implementando.

¿Cuándo es la retrospectiva?

[ ] ¿Retro completada?

(¿dónde/cómo se llevará a cabo, cómo pueden las personas involucrarse, dónde están los resultados?)

Motivación

¿Por qué estamos haciendo esto? ¿Qué casos de uso soporta? ¿Cuál es el resultado esperado?

Explicación a nivel de guía

Explica la propuesta como si ya existiera y la estuvieras enseñando a otro ingeniero. Eso generalmente significa:

• Introducir nuevos conceptos nombrados.

• Explicar la funcionalidad en gran medida en términos de ejemplos.

• Explicar cómo los ingenieros deben pensar sobre la funcionalidad. Debe explicar el impacto lo más concretamente posible.

• Si aplica (por ejemplo, propuesta de código/arquitectura), proporcionar mensajes de error de muestra, advertencias de desaprobación o guía de migración.

• Si aplica, describir las diferencias entre enseñar esto a ingenieros existentes y nuevos ingenieros.

Para los RFC orientados a la implementación, esta sección debe centrarse en cómo los contribuyentes deben pensar sobre el cambio y dar ejemplos de su impacto concreto. Para los RFC de políticas/procesos, esta sección debe proporcionar una introducción basada en ejemplos a la política/proceso y explicar su impacto en términos concretos.

Explicación a nivel de referencia

Esta es la parte técnica del RFC. Explica el diseño con suficiente detalle para que:

• Su interacción con otras funcionalidades sea clara.

• Sea razonablemente claro cómo se implementaría la funcionalidad.

• Los casos extremos sean disecados por ejemplo.

La sección debe volver a los ejemplos dados en la sección anterior y explicar más completamente cómo la propuesta detallada hace que esos ejemplos funcionen.

Inconvenientes

¿Por qué no deberíamos hacer esto?

Razonamiento y alternativas

• ¿Por qué este diseño es el mejor en el espacio de posibles diseños?

• ¿Qué otros diseños se han considerado y cuál es la razón para no elegirlos?

• ¿Cuál es el impacto de no hacer esto?

Arte previo

Discute el arte previo, tanto lo bueno como lo malo, en relación con esta propuesta. Algunos ejemplos de lo que esto puede incluir son:

• Para lenguaje, librería, herramientas, etc.: ¿Existe esta funcionalidad en otros lugares y qué experiencia ha tenido su comunidad?

• Para propuestas comunitarias: ¿Esto lo hace alguna otra comunidad y cuáles fueron sus experiencias con ello?

• Para otros equipos: ¿Qué lecciones podemos aprender de lo que otras comunidades han hecho aquí?

• Artículos: ¿Hay algún artículo publicado o publicaciones destacadas que discutan esto? Si tienes algunos artículos relevantes a los que referirte, esto puede servir como un trasfondo teórico más detallado.

Esta sección está destinada a alentarte como autor a pensar en las lecciones de otros lugares, proporcionar a los lectores de tu RFC una imagen más completa. Si no hay arte previo, está bien - tus ideas nos interesan ya sean completamente nuevas o una adaptación de otros lugares.

Preguntas sin resolver

• ¿Qué partes del diseño esperas resolver a través del proceso de RFC antes de que esto se fusione?

• ¿Qué partes del diseño esperas resolver a través de la implementación de esta funcionalidad antes de la estabilización?

• ¿Qué problemas relacionados consideras fuera del alcance de este RFC que podrían abordarse en el futuro independientemente de la solución que surja de este RFC?

Posibilidades futuras

Piensa en cuál sería la extensión y evolución natural de tu propuesta y cómo afectaría a los equipos y proyectos en su conjunto de manera holística. Trata de usar esta sección como una herramienta para considerar más plenamente todas las posibles interacciones con el proyecto y los equipos en tu propuesta. También considera cómo encaja todo esto en la hoja de ruta del proyecto y del sub-equipo relevante. Esta también es un buen lugar para "volcar ideas", si están fuera del alcance del RFC que estás escribiendo pero de otro modo relacionadas. Si has intentado y no puedes pensar en ninguna posibilidad futura, simplemente puedes decir que no puedes pensar en nada. Ten en cuenta que tener algo escrito en la sección de posibilidades futuras no es una razón para aceptar el RFC actual o futuro; tales notas deben estar en la sección de motivación o razonamiento en este o en RFCs posteriores. La sección simplemente proporciona información adicional.

Title

Toma de Decisiones Transparente Entre Equipos usando RFCs

Patlet

Los proyectos InnerSource que buscan alcanzar altas tasas de participación y tomar las mejores decisiones posibles para todos los involucrados. Por ello necesitan encontrar formas de crear sistemas participativos a lo largo de todo el ciclo de vida del software. La publicación de documentos internos de Solicitud de Comentarios (RFC-Request for Comments) permite discusiones desde el inicio del proceso de diseño y aumenta las probabilidades de construir soluciones con un alto grado de compromiso de todas las partes involucradas.

Problema

Para que un proyecto InnerSource prospere, necesita una cantidad sustancial de contribuyentes. Estos contribuyentes (o equipos) pueden tener diferentes requisitos para el proyecto dado. Por ejemplo, pueden querer agregar características al proyecto que no sean compatibles entre sí o que conduzcan a una sobrecarga no saludable en la arquitectura.

Descubrir tales desacuerdos o malentendidos tarde en el proceso, por ejemplo, una vez que el software ya ha sido construido, es muy costoso. Estos desacuerdos pueden llevar a frustraciones por parte de todos los involucrados e incluso pueden ser perjudiciales para la salud de la cultura de colaboración en el proyecto. Una situación común donde surge tal desacuerdo es una solicitud de cambio (pull request) que está abierta durante mucho tiempo porque el autor de la solicitud de cambio y los mantenedores del proyecto esencialmente no están de acuerdo en que el cambio propuesto deba realizarse.

Para un proyecto InnerSource, esta situación ocurre con más frecuencia cuando el proyecto es mantenido por múltiples equipos en la empresa, es decir, propiedad compartida.

Historia

Un proyecto, o aplicación compuesta por múltiples proyectos, es mantenido por varios equipos diferentes, con cada equipo siendo dueño de diferentes áreas del proyecto o aplicación. Estos equipos hacen contribuciones InnerSource a las áreas de los demás, pero los cambios más grandes y transversales solo son impulsados por los líderes técnicos de los equipos trabajando juntos, o no ocurren en absoluto. Esto resulta en que la mayoría de los ingenieros no pueden efectuar cambios a gran escala y transversales, reduciendo la innovación y las oportunidades de colaboración.

Al implementar un proceso y una plantilla para RFCs, los equipos e individuos están empoderados para proponer cambios grandes y transversales a través de un proceso de toma de decisiones transparente, con consultas entre equipos realizadas de manera asincrónica. Esto resulta en una mayor innovación, una colaboración más estrecha y una mayor difusión del conocimiento. Esto depende del compromiso de todas las disciplinas en todos los niveles y de un entorno de seguridad psicológica para que las personas puedan proponer y debatir ideas abiertamente.

Como con cualquier proceso, este debe mejorarse continuamente. Puede ser necesario realizar cambios en la plantilla o el proceso de RFC para garantizar que sea inclusivo, colaborativo y efectivo.

Contexto

• propiedad compartida por muchos equipos de un proyecto InnerSource

• las decisiones de diseño generales no pueden ser tomadas por un cuerpo central todo el tiempo (por ejemplo, un grupo de arquitectos) ya que no tienen suficiente tiempo ni conocimiento específico del dominio para tomar buenas decisiones en todos los casos

• varios tipos de usuarios tienen aportes sobre la dirección que está tomando un proyecto determinado. Dichos usuarios pueden ser: Desarrolladores, Propietarios de Producto, Gerentes de Producto, etc.

• las decisiones deben tomarse de manera asincrónica, al menos en parte, ya que no es factible convocar reuniones sincrónicas frecuentes con todos los participantes

• hay un deseo de documentar las decisiones tomadas, es decir, asegurarse de que se hagan por escrito, en lugar de solo verbalmente

Resistencias

• la mayoría de las veces, las partes involucradas quieren tomar una decisión bastante rápido (por ejemplo, el tiempo de diseño inicial es bastante limitado)

• escribir las cosas (sin ya implementarlas) a menudo es una habilidad nueva para muchas de las personas involucradas

Esquema

Soluciones

Elegimos un proceso similar a RFC para aumentar la transparencia de nuestro proceso de toma de decisiones entre equipos (ver también las Solicitudes de Comentarios de IETF).

Elementos importantes de la solución son:

• Una descripción de cuándo publicar un RFC (y cuándo no)

• Una plantilla para documentos RFC

  • Debe provocar que el autor del RFC considere su propuesta desde múltiples ángulos

  • Debe solicitar tanto una visión general accesible de alto nivel como una explicación detallada en profundidad

• Un proceso ligero y bien conocido que rodea a los RFCs, por ejemplo

  • Cómo publicar un RFC y compartirlo con todos los interesados (por ejemplo, Slack, lista de correo)

  • Cómo recopilar comentarios para el RFC

  • Cómo trabajar en los comentarios

  • Cómo llevar el RFC hacia una conclusión o decisión (por ejemplo, mantenedores nominados relevantes para aprobar)

  • Herramientas apropiadas elegidas (por ejemplo, los no ingenieros pueden no tener acceso a herramientas de control de versiones)

• Un compromiso para iterar en la plantilla y el proceso de RFC

Ejemplos/Plantillas

• Rust es un buen ejemplo de código abierto de plantilla y proceso de RFC, y ha sido la base para muchos otros procesos de RFC.

• Plantilla generalizada de RFC de BBC iPlayer & Sounds, originalmente basada en la plantilla de Rust

• jakobo/rfc describe cómo configurar un proceso de RFC interno de la empresa. Contiene una explicación detallada de por qué los RFCs son importantes y una plantilla de RFC para ayudarte a escribir tu primer RFC. Contiene información como motivación/razón, guía de implementación, una implementación de referencia, desventajas, así como alternativas al enfoque de RFC. Bonus: La descripción en sí misma es un RFC, por lo que mientras la lees ya estás obteniendo una idea de cómo funciona un RFC.

Contexto Resultante

Implementar un proceso similar a RFC ha demostrado ser valioso, ya que hace que el proceso de toma de decisiones entre equipos sea más transparente para todos, permitiendo que todas las voces sean escuchadas.

Efectos positivos observables:

• democratización del proceso de toma de decisiones para decisiones que impactan a muchos equipos (también descargando a los líderes de equipo de esa carga)

• un método de comunicación asincrónica abierta que funciona bien entre múltiples equipos y geografías

• empodera a individuos y equipos para efectuar cambios a gran escala

• registro de decisiones tomadas para que las personas puedan consultarlas para obtener contexto

• aumenta el impacto de los ingenieros experimentados ya que pueden contribuir a soluciones de manera asincrónica y remota, en lugar de necesitar estar presentes en una reunión

• alineación de terminología por ejemplo, al explicar nuestra terminología de pruebas como "¿qué es una prueba de sistema?"

• alineación de procesos por ejemplo, al explicar el proceso de soporte fuera de horario

• mayor claridad de pensamiento, ya que escribir un RFC hace que el autor se desafíe a sí mismo más de lo que normalmente lo haría

El enfoque de RFC también tiene riesgos que queremos señalar:

• ¡No siempre funciona! por ejemplo, algunas personas pueden seguir argumentando en contra de una decisión que ya se tomó a través de un RFC. Sin embargo, tener el proceso de toma de decisiones por escrito sigue siendo beneficioso en estos escenarios, ya que puedes señalar cuándo y por qué se tomó una decisión determinada.

• Escribir propuestas de diseño (arquitectura, protocolos, etc.) por adelantado tiene un elemento de diseño en cascada que no se ajusta al enfoque de desarrollo iterativo que muchos equipos de desarrollo prefieren. Recuerda: "Software funcionando sobre documentación exhaustiva" (Manifiesto Ágil). El proceso de RFC debe ser lo más ligero posible.

• Un RFC puede volverse grande y demasiado complicado. Esto a menudo se muestra en largos hilos de comentarios y discusiones que lo rodean. En esas situaciones, podemos decidir complementar el RFC con comunicación sincrónica, como un grupo de trabajo y reuniones en persona. Pero aún se ahorra tiempo, ya que las personas pueden leer el RFC antes de la reunión en lugar de tener toda la información compartida durante la reunión.

Justificación

Los RFCs se han demostrado a sí mismos en el mundo del código abierto durante muchos años. Esto es cierto tanto para Internet en su conjunto, donde los RFCs han sido fundamentales en el desarrollo de estándares (ver 30 Años de RFCs), como para otros proyectos de código abierto que han adaptado este método para promover la toma de decisiones transparente en su comunidad (por ejemplo, RUST, ZeroMQ).

En el contexto de InnerSource, otras empresas también han compartido sus experiencias con enfoques similares a RFC, como Uber y Europace.

También para la toma de decisiones fuera de las decisiones de diseño de software puro, los modelos de toma de decisiones transparentes pueden ser efectivos, por ejemplo, al trabajar hacia una Organización Abierta. Para un ejemplo, vea el Marco de Decisión Abierta de Red Hat (lanzado públicamente el 7 de junio de 2016).

Instancias Conocidas

• BBC iPlayer & Sounds - Como se presentó en el ISC Fall Summit 2020 Usando RFCs Internos para Mejorar la Colaboración.

• Europace - Como se describe en Open Organization: Estableciendo estándares y mejores prácticas entre equipos de manera abierta.

• Uber - Según esta publicación de blog de Gergely Orosz: Escalando Equipos de Ingeniería a través de RFCs: Escribiendo las Cosas.

• Google Design Docs - Como se describe en esta publicación de blog de Malte Ubl Documentos de Diseño en Google

• DAZN (10/2021) - Una forma en que DAZN toma decisiones técnicas es a través de RFCs. Los RFCs se utilizan para decisiones que se aplican solo a procesos de ingeniería a nivel general. Los RFCs viven en un repositorio de GitHub, y los estándares técnicos se adoptan gradualmente dentro de sus herramientas y por sus ingenieros. Cualquier ingeniero puede presentar un RFC y todos los ingenieros pueden votar. Si los votos a favor superan a los votos en contra, el RFC se adopta. Vale la pena señalar que el proceso de votación de RFC aún no ha sido "probado bajo estrés" por decisiones controvertidas. - Como se describe en esta publicación de blog de Lou Bichard: Construyendo un Equipo de DX: Lecciones Aprendidas

• SAP (03/2024) - SAP tiene un proceso maduro asistido por herramientas para la revisión de documentos entre equipos. Se utiliza principalmente para la revisión de Registros de Decisiones de Arquitectura (ADR) que se originan en el trabajo entre equipos realizado en el modelo de colaboración de Arquitectura de Producto Cruzado. Algunas diferencias de implementación notables de este patrón: El proceso de revisión no está fácilmente disponible para decisiones en proyectos pequeños. Además, los documentos no están restringidos solo a proyectos InnerSource. - Como se describe en la publicación de blog Arquitectura de Producto Cruzado: Abrazando la Ley de Conway para una Mejor Arquitectura de Software.

Estado

Estructurado

Autor(es)

• Tom Sadler

• Sebastian Spier

Aliases

• Documentos de Diseño

• Registro de Decisiones de Arquitectura (ADRs) - No necesariamente un alias directo, ya que a veces pueden usarse de manera muy diferente, por ejemplo, RFCs para buscar aportes y construir consenso, ADRs para registrar decisiones y detalles de implementación

Histórico de Traducciones

• 2025-04-03 - Traducción Oscar Lobaton S.

• 2025-04-03 - Traducción Roman Martin Gil

Title

Requerimientos Comunes

Patlet

El código común en un repositorio compartido no satisface las necesidades de todos los equipos de proyecto que desean utilizarlo; esto se resuelve mediante la alineación de requerimientos y la refactorización.

Problema

El código común en el repositorio compartido no satisface las necesidades de todos los proyectos que desean utilizarlo.

Contexto

• Muchos proyectos intentan utilizar código común. Existe un repositorio compartido al que todos los proyectos tienen acceso.

• Alguien (o algún proyecto) escribió el código inicialmente y lo contribuyó al repositorio.

• El código común representa un pequeño porcentaje del entregable total de cualquiera de los proyectos.

• Cada proyecto tiene su propio calendario de entrega, conjunto de entregables y clientes.

• Este patrón aplica en cualquiera de estas situaciones:

  • existe un Strong Code Owner, es decir, todos los cambios al repositorio compartido deben ser aprobados por el propietario del repositorio

  • existe un Weak Code Owner, es decir, nadie realmente es dueño del código

  • no existe un Benevolent Sponsor, es decir, ninguna organización o ejecutivo proporciona recursos para organizar el código común de manera InnerSource

Resistencias

El proyecto que hizo disponible el código tiene un conjunto de necesidades. Sus necesidades son similares a lo que algunas organizaciones receptoras desean, pero no exactamente iguales. Los requerimientos del código deben derivarse de necesidades reales del cliente.

Las necesidades de diferentes clientes son generalmente bastante similares; sin embargo, pueden expresarse de manera diferente o tener diferentes prioridades entre clientes. Un ejemplo podría ser cómo algunos clientes desean que algún resultado se presente de una manera mientras que otros lo quieren en orden inverso. Es simple hacer la traducción entre ellos, pero requiere codificación adicional para uno de los casos y como resultado el módulo que calcula el resultado no puede ser reutilizado por ambos clientes.

Muchos clientes desean que el proveedor les ayude a identificar sus necesidades. La empresa tiene muchos "Ingenieros de Sistemas" escribiendo requerimientos para los productos. Estos requerimientos deben ser una destilación de las necesidades del cliente para guiar el desarrollo del producto. Reutilizar código es un objetivo importante para ahorrar tiempo y dinero a la empresa.

Solución

Hay dos aspectos para resolver este problema que deben realizarse en paralelo:

1. Alinear los requerimientos de los proyectos para que el código que cumple los requerimientos de un proyecto también satisfaga las necesidades de los otros proyectos.

2. Refactorizar el código en piezas más pequeñas para las cuales los múltiples proyectos que lo utilizan puedan acordar requerimientos.

Adicionalmente, aprovechar que los clientes esperan que el proveedor ayude a comprender los requerimientos. Lograr la alineación de requerimientos durante las negociaciones con el cliente e influir en los requerimientos del cliente en lugar de cambiar el componente.

En el ejemplo presentado anteriormente, el proveedor ayuda a ambos clientes a darse cuenta de que quieren lo mismo, y ahorrará esfuerzo (y dinero) a todos si acuerdan aceptar el resultado en el mismo formato.

Contexto Resultante

Esto podría requerir negociar cambios en los requerimientos con el cliente. Los cambios también podrían requerir la participación de los equipos de ventas y gestores de producto para lograr la alineación en los requerimientos. El cliente podría necesitar incentivos, como descuentos, para aceptar los cambios.

Un desafío relacionado (y posible nuevo patrón) es un ejercicio circular de escritura de historias reportado en una empresa que emplea InnerSource. En resumen:

• Los desarrolladores escriben una historia para resolver un problema de una manera.

• Los gestores del programa reescriben la historia para expresar mejor sus necesidades, manteniendo la esencia igual. Sin embargo, cuando vuelve a los desarrolladores, no la reconocen como lo que querían hacer en primer lugar y por lo tanto se resisten a implementarla.

• La solución a este patrón es tener más asientos alrededor de la mesa de planificación para que las modificaciones de la historia se entiendan en todo el proyecto, no solo en los campos de desarrolladores o gestores de programa.

Instancias Conocidas

• Gran proveedor de telecomunicaciones

Estado

• Estructurado

Autor

Robert Hanmer

Reconocimientos

• Manrique Lopez

• Daniel Izquierdo

• Tim Yao

• Sebastian Spier

Histórico de Traducciones

• 2025-04-03 - Traducción Oscar Lobaton S.

• 2025-04-03 - Traducción Roman Martin Gil

Title

Puntuación de Actividad del Repositorio

Patlet

Los contribuidores potenciales quieren encontrar proyectos InnerSource activos que necesiten su ayuda. Al calcular una puntuación de actividad del repositorio para cada proyecto, se puede crear una lista clasificada de proyectos (por ejemplo, en el Portal InnerSource), para que los contribuidores potenciales puedan determinar más fácilmente a qué proyecto quieren contribuir.

Problema

¿En qué orden se deben presentar los proyectos InnerSource? Los KPIs típicos de clasificación como GitHub Stars, Número de Forks, Número de Commits, Líneas de Código, Última Actualización no son suficientes para indicar de manera concisa la actividad de un proyecto.

Los proyectos activos con mucha tracción, pero también los proyectos nuevos y entusiastas que necesitan nuevos contribuidores, deben clasificarse más alto que los proyectos maduros con poca actividad o en modo de mantenimiento.

Se necesita una nueva métrica derivada de varios KPIs para definir una puntuación confiable y versátil del nivel de actividad de un proyecto. Puede usarse para ordenar los proyectos según su nivel de actividad.

Historia

Cuando InnerSource se practica durante mucho tiempo o se escala más allá de un cierto número de proyectos (digamos 50 para dar un umbral significativo), es difícil encontrar los proyectos InnerSource más populares y activos en ese momento. Los proyectos que existen desde hace mucho tiempo son bien conocidos, pero pueden no ser muy activos. Por otro lado, los proyectos nuevos no tienen una reputación o una comunidad activa todavía.

Una lista de proyectos InnerSource no debe considerarse un recurso estático, sino un lugar emocionante para descubrir y explorar nuevos proyectos activos, al igual que una página de noticias que enumera los temas más interesantes del día primero. Por lo tanto, es beneficioso cuando el orden de los proyectos se actualiza regularmente y cambia según la popularidad y actividad del proyecto.

Estas consideraciones llevaron a un primer prototipo para calcular una puntuación de actividad del repositorio, que funcionó sorprendentemente bien y determina un orden siempre cambiante de proyectos según su actividad.

Contexto

Descubrir proyectos InnerSource puede facilitarse con el Portal InnerSource y el patrón Gig Marketplace, o promoviendo proyectos en otros canales de comunicación y plataformas. La puntuación de actividad define un orden predeterminado en el que se presentan los proyectos a la comunidad.

Resistencias

Los KPIs automatizados que se pueden obtener consultando la API de GitHub son solo una parte de la verdad. ¿Qué pasa con la calidad del código, la disponibilidad de buena documentación o una comunidad activa y servicial que hace que el proyecto sea un lugar divertido para contribuir?

Tales KPIs "suaves" tendrían que agregarse manual o semiautomáticamente al cálculo y la puntuación resultante. Si existen herramientas que proporcionan más contexto para el repositorio, como un informe de cobertura de código, se pueden integrar fácilmente.

Esquema

Un enfoque centralizado para calcular y aplicar la puntuación de actividad del repositorio. Para más detalles, ver Contexto Resultante

Soluciones

La puntuación de actividad del repositorio es un valor numérico que representa la actividad (GitHub) de un proyecto InnerSource. Se deriva automáticamente de estadísticas del repositorio como estrellas de GitHub, observadores y forks, y puede enriquecerse con KPIs de otras herramientas o evaluaciones manuales.

Además, considera parámetros de actividad como la última actualización y la fecha de creación del repositorio para dar un impulso a los proyectos jóvenes con mucha tracción. Los proyectos con directrices de contribución, estadísticas de participación activa y problemas (backlog público) también reciben una clasificación más alta.

Todo esto se puede obtener y calcular automáticamente utilizando el conjunto de resultados de la API de búsqueda de GitHub y la API de estadísticas de GitHub. Otros sistemas de control de versiones de código como Bitbucket, GitLab, Gerrit también se pueden integrar si hay una API similar disponible.

El código a continuación asume que la variable repo contiene una entidad obtenida de la API de búsqueda de GitHub y el objeto participation contiene una entidad de la API de stats/participation de GitHub.

Se pueden hacer ajustes manuales según los KPIs cualitativos (ver Resistencias) si es necesario.

// calcular una puntuación virtual de InnerSource a partir de estrellas, observadores, commits y problemas
function calculateScore(repo) {
    // la puntuación inicial es 50 para dar a los repositorios activos con bajos KPIs de GitHub (forks, observadores, estrellas) un mejor punto de partida
    let iScore = 50;
    // ponderación: los forks y observadores cuentan más, luego las estrellas, agregar una pequeña puntuación para problemas abiertos también
    iScore += repo.forks_count * 5;
    iScore += (repo.subscribers_count ? repo.subscribers_count : 0);
    iScore += repo.stargazers_count / 3;
    iScore += repo.open_issues_count / 5;

    // actualizado en los últimos 3 meses: agrega un multiplicador de bonificación entre 0..1 a la puntuación general (1 = actualizado hoy, 0 = actualizado hace más de 100 días)
    let iDaysSinceLastUpdate = (new Date().getTime() - new Date(repo.updated_at).getTime()) / 1000 / 86400;
    iScore = iScore * ((1 + (100 - Math.min(iDaysSinceLastUpdate, 100))) / 100);

    // evaluar estadísticas de participación para los últimos 3 meses
    repo._InnerSourceMetadata = repo._InnerSourceMetadata || {};
    if (repo._InnerSourceMetadata.participation) {
        // commits promedio: agrega un multiplicador de bonificación entre 0..1 a la puntuación general (1 = >10 commits por semana, 0 = menos de 3 commits por semana)
        let iAverageCommitsPerWeek = repo._InnerSourceMetadata.participation.slice(-13).reduce((a, b) => a + b) / 13;
        iScore = iScore * ((1 + (Math.min(Math.max(iAverageCommitsPerWeek - 3, 0), 7))) / 7);
    }

    // cálculo de impulso:
    // todos los repositorios actualizados en el último año recibirán un impulso máximo de 1000 que disminuye según los días desde la última actualización
    let iBoost = (1000 - Math.min(iDaysSinceLastUpdate, 365) * 2.74);
    // reducir gradualmente el impulso según la fecha de creación del repositorio para mezclar con estadísticas de "compromiso real"
    let iDaysSinceCreation = (new Date().getTime() - new Date(repo.created_at).getTime()) / 1000 / 86400;
    iBoost *= (365 - Math.min(iDaysSinceCreation, 365)) / 365;
    // agregar impulso a la puntuación
    iScore += iBoost;
    // dar a los proyectos con una descripción significativa un impulso estático de 50
    iScore += (repo.description?.length > 30 || repo._InnerSourceMetadata.motivation?.length > 30 ? 50 : 0);
    // dar a los proyectos con directrices de contribución (archivo CONTRIBUTING.md) un impulso estático de 100
    iScore += (repo._InnerSourceMetadata.guidelines ? 100 : 0);
    // construir una escala logarítmica para proyectos muy activos (sin límite pero estabilizándose alrededor de 5000)
    if (iScore > 3000) {
        iScore = 3000 + Math.log(iScore) * 100;
    }
    // la puntuación final es un valor redondeado que comienza desde 0 (restar el valor inicial)
    iScore = Math.round(iScore - 50);
    // agregar puntuación a los metadatos sobre la marcha
    repo._InnerSourceMetadata.score = iScore;

    return iScore;
}

Contexto Resultante

Los contribuidores son libres de dedicar parte de su tiempo a proyectos InnerSource. Pueden elegir contribuir a un proyecto del que dependen para el trabajo en su equipo regular de todos modos. Sin embargo, también pueden optar por contribuir a algo completamente diferente, basado en sus intereses y objetivos de desarrollo personal.

Los proyectos pueden ordenarse y presentarse por puntuación de actividad del repositorio para establecer un orden relevante en un portal que presenta proyectos a nuevos contribuidores potenciales. La puntuación se puede calcular sobre la marcha o en un trabajo en segundo plano que evalúa todos los proyectos regularmente y almacena una lista de resultados.

Un rastreador que busca regularmente todos los repositorios InnerSource (por ejemplo, etiquetados con un cierto tema en GitHub) también puede ser una adición útil. Proporciona una lista clasificada de proyectos que se puede usar como entrada para herramientas como el Portal InnerSource, un motor de búsqueda o un chatbot interactivo.

Razonamiento

La puntuación de actividad del repositorio es un cálculo simple basado en la API de GitHub. Puede ser completamente automatizado y fácilmente adaptado a nuevos requisitos.

Instancias Conocidas

• Utilizado en el portal de proyectos InnerSource de SAP para definir el orden predeterminado de los proyectos InnerSource. Fue creado por primera vez en julio de 2020 y se ajusta y actualiza con frecuencia desde entonces. Cuando se propuso a InnerSource Commons en julio de 2020, surgió este patrón. También ver Michael Graf & Harish B (SAP) en ISC.S11 - El Camino Inesperado de Aplicar Patrones InnerSource.

• Airbus se inspiró mucho en este patrón para crear una "puntuación InnerSource" que combina la puntuación de actividad junto con verificaciones de la Documentación Base Estándar y la Licencia InnerSource.

Estado

• Estructurado