Alcanzando las plataformas internas a través de InnerSource

Autor: Arthur Fücher

En el ámbito del desarrollo en grandes organizaciones, un desafío se destaca: los equipos que trabajan de forma aislada, duplicando esfuerzos y perdiendo oportunidades de innovación colaborativa.

En su investigación sobre las empresas tecnológicas de alto rendimiento, McKinsey enfatiza la necesidad de eliminar los silos en el modelo operativo. Descubrieron que las compañías líderes tienen más del doble de probabilidades de organizar sus equipos de ingeniería en modelos centrados en productos o plataformas. Este enfoque reduce el tiempo de comercialización, disminuye los costos de las soluciones tecnológicas y fortalece la responsabilidad entre los equipos de negocio y tecnología.

Este desafío se intensifica con la creación de plataformas y frameworks internos, como fue el caso de nuestro Backend Driven Content (BDC) —nuestra plataforma, sobre la cual tenemos otra publicación en el blog que discute más a fondo—, donde todo el desarrollo móvil dependía de esta plataforma.

¿Qué es InnerSource?

El término fue creado por Tim O’Reilly, quien lo definió como “el uso de técnicas de desarrollo de código abierto (‘open source’) dentro de una corporación, o con un grupo de clientes clave — incluso si aún no están listos para liberar su software como un proyecto público de código abierto”.

Años después, en 2015, se fundó la InnerSource Commons Foundation (ISC), dedicada a crear y compartir conocimiento sobre InnerSource: el uso de las mejores prácticas de código abierto para el desarrollo de software dentro de los límites de una organización. En su sitio web, la definición de InnerSource es:

InnerSource aplica las lecciones aprendidas del desarrollo de software de código abierto a la forma en que las empresas desarrollan software internamente.

Veamos un ejemplo concreto: imaginemos que necesitamos desarrollar una nueva pantalla de onboarding que requiere un componente que aún no ha sido implementado en el framework interno de la empresa. En el modelo tradicional, se pediría al equipo responsable del framework que priorice ese ítem en el backlog y se esperaría hasta que lo terminen.

Con InnerSource, el proceso se transforma:

• El equipo responsable define el proceso de contribución.
• Desarrolladores de otros equipos pueden proponer soluciones e implementaciones.
• Las revisiones de código involucran múltiples perspectivas, mejorando la calidad.
• Los componentes creados quedan disponibles para su reutilización en otros proyectos.

¿Por qué InnerSource?

La InnerSource Commons Foundation (ISC) realiza una encuesta anual para entender el «Estado de InnerSource«. En 2024, se aplicó un cuestionario a través de Qualtrics y estuvo disponible durante aproximadamente 12 semanas, de noviembre de 2023 a enero de 2024.

Según el informe «State of InnerSource 2024», alrededor del 68% de las organizaciones participan en InnerSource motivadas por:

• Crear software reutilizable.
• Eliminar silos y cuellos de botella.
• Compartir conocimiento.

Por otro lado, para los individuos, el valor está en:

• Compartir conocimiento (66% de los encuestados).
• Conocer a más personas dentro de la organización (62%).
• Mejorar la calidad del software en el que yo (o mi equipo) trabajo (54%).

Cómo Estructuramos Nuestro Enfoque

Al construir la plataforma, tuvimos en mente uno de los valores fundamentales de Nubank: queremos que nuestros clientes nos amen de forma fanática. En este caso, nuestros «clientes» son los desarrolladores internos. Esta distinción es importante, ya que, si bien no impactamos directamente a los usuarios finales de Nubank, la experiencia que brindamos a los desarrolladores les permite, en última instancia, entregar más rápido, construir mejores soluciones y crear experiencias maravillosas para nuestros clientes.

Desde el principio, construimos esta plataforma en estrecha colaboración con nuestros equipos internos. Al tratarlos como verdaderos socios —escuchando sus comentarios y aprendiendo de sus experiencias—, fomentamos un sentido de comunidad y cocreación que dio forma a la solución juntos.

• Procesos de contribución claros:

Creamos flujos estandarizados para que cualquier persona pudiera proponer mejoras —incluyendo en la documentación—, sin importar a qué equipo perteneciera. Esto reduce la fricción entre una idea y su implementación.Por ejemplo, para migrar un componente Flutter a BDC:

1. El contribuidor necesita verificar si el componente realmente no existe.
2. Proporcionamos una herramienta de línea de comandos (CLI) para crear la mayor parte del código base (boilerplate).
3. La persona realiza las personalizaciones finales.
4. Abre un Pull Request (PR) llenando la plantilla.
5. Luego, abre un ticket con los enlaces de los PRs.

Todos estos pasos se describen en la Guía de Contribución de la documentación oficial de la plataforma BDC.

• Sentido de comunidad: Queremos que las personas se sientan cómodas compartiendo sus ideas y comentarios, ayudándose mutuamente y contribuyendo a la plataforma.
• Documentación mejorada: Las personas necesitan poder aprender a su propio ritmo y tener autonomía para profundizar. No pueden depender siempre del equipo principal del proyecto, ya que esto no es escalable.
• Roles dedicados: El equipo, además de los roles normales (SWE, TM, PM), estuvo compuesto por un Redactor Técnico y un Developer Advocate. Tener estos roles dedicados ayudó a enfocarse en diferentes áreas de manera especializada, como la promoción de la cultura de InnerSource.

Resultados

Nuestra comunidad interna de BDC ya reúne a alrededor de 1,000 desarrolladores, con más del 85% participando activamente en las discusiones. Más allá de la actividad en el canal, el impacto real se evidencia en cómo los equipos interactúan con la plataforma.

Hemos visto más de un 90% de adopción orgánica en todos los equipos, lo que se traduce directamente en más contribuciones y una colaboración más sólida entre ellos. Como resultado, los tiempos de entrega han mejorado, ya que los desarrolladores no necesitan esperar a la priorización del equipo principal para avanzar.

Lo más importante es que los datos de los tickets destacan este cambio: mientras el número de contribuciones ha aumentado de manera constante, los tickets enviados al equipo principal relacionados con bugs, fallos o preguntas han disminuido consistentemente con el tiempo. Esta tendencia refuerza cómo el InnerSource está reduciendo los cuellos de botella e impulsando la autonomía.

Lo que se avecina

InnerSource ha demostrado su valor, entregando los resultados que esperábamos y estableciéndose como un estándar sólido para los proyectos internos.

Hoy en día, nuestra Plataforma de Experimentación también está aprovechando InnerSource para desbloquear proyectos y funciones, y varias bibliotecas y proyectos internos han comenzado a adoptar el mismo enfoque.

De cara al futuro, seguimos perfeccionando nuestros procesos, invirtiendo en herramientas que faciliten la colaboración y, lo más importante, fomentando una cultura en la que el intercambio de conocimientos sea natural y valorado.

Uno de los próximos desafíos es gestionar el creciente número de contribuciones. Un posible siguiente paso será adoptar el modelo de «Trusted Committer», empoderando a contribuidores seleccionados fuera del equipo principal con la responsabilidad de aprobar o rechazar contribuciones.