¿Cómo funciona InnerSource?

Pongamos como ejemplo la situación donde un equipo A usa el software que produce un equipo B. El equipo A tiene una petición para una nueva funcionalidad y se la envía al equipo B, pero el equipo B no llega a tiempo de implementar dicha mejora para el equipo A. En un entorno de InnerSource, si al equipo A no le facilitan dicha funcionalidad entonces habría enviado un pull request en su lugar. Esto significa que el equipo A implementa la funcionalidad directamente en el software del equipo B y envía un pull request para que sea revisado con los cambios pertinentes. El equipo B es entonces el encargado de revisar dicho código y aceptarlo cuando esté listo.

En este ejemplo, el equipo A es el Invitado y el equipo B es el equipo Anfitrión. Los términos de Invitado y Anfitrión se usan para referirse a una situación análoga a la de tener una visita en casa. En esta situación, la mayor parte de las personas quieren ser un buen anfitrión y para ello hay que asegurar que la casa está ordenada y las cosas guardadas en su sitio como anticipo a la visita de nuestros invitados. Los visitantes serán entonces bienvenidos en la puerta e invitados a pasar y podrán usar las diferentes herramientas e instalaciones que sean públicas. Hay, por supuesto, una serie de reglas en la casa que se pide a los invitados que sigan. De igual manera, los invitados quieren ser educados y mostrar respeto por la casa y por los anfitriones. Tienen cuidado con las cosas de la casa y siguen las reglas durante su estancia. Además esperan que quizá vuelvan a ser invitados de nuevo siempre y cuando hayan sido educados y corteses. Estos conceptos acerca de una visita en una casa son una metáfora de la actitud y comportamientos que los equipos deben tener cuando actúan como anfitriones o como invitados a la hora de contribuir al código fuente de nuestro producto.

Echemos un vistazo más en detalle del proceso de InnerSource. Para ilustrar esta explicación usaremos unos pocos roles que son clave en los equipos que actúan como invitados y anfitriones. En primer lugar, el Product Owner determina qué funcionalidad puede ser aceptada por el equipo anfitrion como una contribución. El Contribuidor es la persona en el equipo invitado que envía la contribución de código para ser revisada por el equipo anfitrión. El Trusted Committer representa al equipo anfitrión al ofrecer en cualquier momento soporte y consejo acerca de las necesidades que tiene que cubrir el contribuidor cuando envíe su parche de código o pull request. En equipos pequeños, a veces ocurre que la misma persona desempeña ambos puestos, el product owner y el trusted committer.

Una vez entendidas estas definiciones, a continuación vemos el resumen de una contribución de InnerSource.

Estos pasos no asumen ningún tipo de organización de los diferentes equipos o sus prioridades. InnerSource asume que los diferentes equipos tienen ya una manera concretra de organizarse y ofrece un paraguas para poder trabajar juntos donde hay un equipo invitado que quiere contribuir código a otro equipo que actuará de anfitrión.

Esta opción funciona para el equipo invitado porque consiguen la funcionalidad requerida cuando la necesitaban sin tener que hacerse cargo del proceso de mantenimiento de la misma en el medio o largo plazo. Funciona para el equipo anfitrión porque son capaces de acomodar y gestionar más trabajo a la vez que siguen sirviendo a sus consumidores. Además funciona para la compañía en su totalidad porque las soluciones a problemas compartidos terminan en lugares por todos conocidos, compartido y mantenido de forma centralizada que cualquiera puede usar. Finalmente, se invierte más tiempo de ingeniería en producir código que resuelve problemas de la compañía en lugar de estar enfocado en problemas políticos, jerárquicos y de negociaciones entre equipos.