Cómo implementar InnerSource en tu empresa: beneficios, desafíos y mejores prácticas

Open Source es un modelo de trabajo importante en la industria del desarrollo de software hoy en día. Es muy ineficiente, si no imposible, desarrollar software sin él. Hay algunos proyectos de código abierto muy exitosos y muchas áreas tecnológicas están incluso dominadas por el código abierto, como el big data, el aprendizaje automático, Internet de las cosas. Por lo tanto, podría tener sentido analizar en más detalle la forma en que trabajan las comunidades de código abierto e intentar aprender de sus mejores prácticas. Eso es lo que hace el InnerSource.

InnerSource es la práctica de aplicar el método y las mejores prácticas de código abierto para el desarrollo de software interno. Su objetivo es mejorar los procesos de desarrollo internos basados en los aprendizajes del estilo de colaboración de código abierto.

Algunos de los beneficios de este estilo de trabajo, heredados del código abierto, son:

• Menor tiempo de llegada al mercado en características y correcciones de errores: los consumidores desempeñan un papel más activo en el desarrollo del software que se les proporciona a través de contribuciones. Con la capacidad adicional de contribuciones, las características y correcciones de errores pueden entregarse antes.


• Trazabilidad: al utilizar un seguimiento de errores y una lista de tareas públicos internos, se fomenta la comunicación escrita en estos sistemas. La comunicación escrita conduce a una documentación más rastreable sobre el diseño del software y las decisiones.


• Seguridad mediante la transparencia: el código fuente está abierto internamente para su inspección, lo que significa que las vulnerabilidades pueden ser detectadas antes por la comunidad.

En esta publicación de blog exploraremos con más detalle el modelo de trabajo de InnerSource, así como discutiremos sus desafíos y las acciones que estamos tomando para hacerlo exitoso en SAP.

Cómo funciona InnerSource

En un modelo de desarrollo tradicional, un equipo de desarrollo (llamado "Proveedor de servicios" en la imagen a continuación) desarrolla y proporciona un componente o servicio de reutilización a sus consumidores, por ejemplo, otros equipos de desarrollo que utilizan ese componente o servicio para sus proyectos.

Un equipo consumidor envía informes de errores y solicitudes de características al equipo proveedor. El equipo proveedor desarrolla correcciones de errores y características en consecuencia, que a su vez son consumidas por el equipo consumidor.

Dado que típicamente no hay solo un equipo consumidor sino muchos, el equipo proveedor recibe muchas solicitudes de características e informes de errores. Debido a sus limitaciones de recursos, las solicitudes deben priorizarse y no todas pueden entregarse a tiempo. Esto, a su vez, crea desafíos para los consumidores. Algunos de ellos podrían decidir no utilizar el componente de reutilización de los equipos proveedores, sino desarrollar una funcionalidad similar ellos mismos. Esto significa trabajo duplicado, competencia innecesaria y proyectos redundantes y, por lo tanto, es lo opuesto a la reutilización.

En un modelo de InnerSource, el equipo proveedor abriría el proyecto de reutilización para contribuciones de los equipos consumidores. Estos equipos podrían contribuir con correcciones de errores y características ellos mismos en lugar de solo informar errores y solicitar características.

En dicho modelo, no es necesario que los equipos consumidores abandonen el componente de reutilización del equipo proveedor para crear una funcionalidad similar. En cambio, podrían apoyar al equipo proveedor contribuyendo directamente a las características solicitadas, lo que sería más económico desde una perspectiva de esfuerzo para ambas partes, y haría que el componente de reutilización sea más versátil y mejor reutilizable para otros equipos también.

Para los equipos consumidores, este enfoque suele llevar a una mayor satisfacción, ya que están activamente involucrados y a una mayor motivación, ya que pueden influir en el proyecto de reutilización. También obtienen las características y correcciones de errores requeridas más rápidamente.

Beneficios de InnerSource

Básicamente, InnerSource significa desarrollar más en comunidades y de manera colaborativa que en equipos de proyectos dedicados. Si bien estos equipos también existen en un enfoque de InnerSource y, dependiendo de la gobernanza y el modelo de colaboración del proyecto, podrían seguir teniendo la responsabilidad general del proyecto, no son los únicos que contribuyen al proyecto. De hecho, hay una comunidad más amplia de ingenieros que desarrollan colaborativamente un proyecto.

Este enfoque tiene ciertos beneficios. Algunos de ellos, como un menor tiempo de llegada al mercado, una colaboración más estrecha entre proveedores y consumidores, y una mayor seguridad mediante la transparencia, ya se han mencionado, pero hay más.

La mayor colaboración es un valor importante en sí mismo. El conocimiento entre equipos y unidades de negocio (también conocidas como "silos") se distribuye y la colaboración interunidades se incrementa. Según la ley de Conway (ver [9]), esto ayuda a construir un software mejor (integrado).

Típicamente, los proyectos de InnerSource también tienen una mayor calidad. Esto se debe a que requiere una buena documentación para mantener bajos los obstáculos para los contribuyentes externos. Esto también facilita la integración de nuevos miembros en el equipo del proyecto. Además, el alto grado de automatización de pruebas que requiere InnerSource ayuda a mejorar la calidad.