Introducción a InnerSource

La adopción de este enfoque moderno en el desarrollo de software puede ser transformador: permite la colaboración y fomenta la creación de código de alta calidad. Pero comprender los principios y los posibles desafíos es fundamental para lograr el éxito.

Muchas empresas utilizan el término “InnerSource” para describir la forma en la que los equipos de ingeniería trabajan en un código de manera conjunta. El InnerSource (código interno) es una metodología de desarrollo con la cual los ingenieros diseñan sistemas de software propietario utilizando las prácticas recomendadas de los proyectos de código abierto a gran escala, como Kubernetes o Visual Studio Code de Microsoft.

Los proyectos de código abierto a gran escala requieren coordinación y trabajo en equipo por parte de miles de colaboradores. Los más exitosos están motivados por una visión hacia el futuro, además de las necesidades diarias de los usuarios: velocidad, confiabilidad y funcionalidad. La escala en la cual funcionan puede enseñarnos algunas lecciones y ayudar a tu empresa a desarrollar mejor software de manera más rápida usando la InnerSource.

En este artículo, presentaremos los puntos básicos sobre la forma en que los equipos usan la InnerSource en sus flujos de trabajo diarios y aplican las prácticas del código abierto para trabajar de forma colaborativa y eficiente.

¿Qué hace que un proyecto sea de código abierto?

GitHub es el hogar de la comunidad de código abierto más grande del mundo. Lo que desarrolla nuestra comunidad abarca los intereses y los conjuntos de habilidades de millones de colaboradores. que trabajan juntos en lenguajes de programación, como Swift de Apple, y en estructuras, como React.js de Facebook. Y no solo escriben código, también se pueden escribir conjuntos de datos, documentación legal y mucho más de esta forma conjunta de código abierto.

Cualquier persona puede usar el software de código abierto. También puede visualizar, modificar y distribuir un proyecto con cualquier objetivo, como lo establecen las licencias del código abierto. De igual modo, cualquier persona puede ayudar a desarrollar el software de código abierto. En general, el desarrollo de los proyectos está a cargo de una comunidad de colaboradores distribuidos que comparten código, comentarios, informes de errores y más.

Las prácticas recomendadas para este tipo de colaboración abierta son fundamentales para la InnerSource. Dedicaremos el resto del artículo para revisar algunos aprendizajes, herramientas y términos clave.

Para obtener más información sobre la forma en que las personas comienzan los proyectos de código abierto y colaboran en su desarrollo, consulta nuestras guías.

Lecciones aprendidas de la comunidad de código abierto

Si tu equipo desarrolla software, es probable que ya esté desarrollando de forma conjunta un proyecto de código abierto o colaborando con el proyecto alguien más. La comunidad ofrece muchas lecciones sobre cómo colaborar en diferentes zonas horarias, reunir a los colaboradores y administrar proyectos grandes y complejos. Aquí se presentan algunas para tener en cuenta a la hora de establecer una práctica de InnerSource:

La colaboración abierta incentiva más contribuciones

Más contribuciones implican más oportunidades. Los proyectos de código abierto pueden aceptar cambios por parte de cualquier persona del mundo. Eso es mucha capacidad intelectual dedicada a hacer progresar un proyecto, satisfacer las necesidades de los usuarios y encontrar y corregir los errores.

De igual manera, la InnerSource aporta más ideas. Los equipos pueden generar innovaciones con mayor facilidad y, al haber más personas que inspeccionan el código en búsqueda de errores e inconsistencias, se puede desarrollar software más seguro y confiable. Los problemas se encuentran y corrigen antes de que la persona equivocada los descubra.

Los desarrolladores no siempre tienen que empezar de cero

Cualquier persona puede descubrir proyectos de código abierto y reutilizarlos para prácticamente cualquier objetivo. Las personas incluso pueden usarlos para desarrollar otros proyectos o modificarlos para que se adapten a sus necesidades específicas.

De igual forma, el InnerSource ayuda al equipo a encontrar, personalizar y reutilizar proyectos internos existentes. Además, se puede establecer un conjunto compartido de procesos documentados y desarrollar proyectos a partir de ellos para optimizar la forma en que tu empresa hace deploys y utiliza el software. Esto puede dar lugar a la reducción de los costos, el aumento de la flexibilidad y el fin de la dependencia de los proveedores.

La toma de decisiones transparente genera procesos, confianza y alineación

Los mantenedores del código abierto exitoso documentan sus decisiones de manera predeterminada. Dado que cada conversación tiene su propia URL y un historial de comentarios como contexto, las zonas horarias no importan mucho y los desarrolladores pueden trabajar de forma asincrónica sin perder el ritmo.

Abrir los proyectos trae un nuevo nivel de transparencia a tu organización. No solo se visibiliza el código, sino también el proceso y la toma de decisiones detrás de él. Las conversaciones bien documentadas ayudan a los desarrolladores de equipos distribuidos a ponerse al día y empezar las actividades de desarrollo. Y como el trabajo se produce de manera abierta, las contribuciones también pueden incluir a gerentes de producto, diseñadores, equipos de seguridad y más.

La participación es fundamental

El éxito de cualquier proyecto de código abierto depende de la participación. Hay muchas razones integradas para contribuir: mejorar las habilidades, encontrar un mentor o generar una reputación, por ejemplo, pero los mantenedores de los proyectos también deben crear una cultura comunitaria que favorezca e incentive la participación.

Dentro de una empresa, los desarrolladores individuales pueden perseguir sus propios intereses, compartir ideas en igualdad de condiciones y aprender de sus colegas con mayor facilidad. Sin embargo, la InnerSource también requiere un cambio cultural. La cultura de tu equipo deberá incentivar que los miembros compartan el conocimiento y favorecer las contribuciones desde todos los sectores de tu organización.

Los equipos centrales de desarrollo fortalecen el proceso de los proyectos

Los proyectos de código abierto pueden tener miles de colaboradores y miembros de la comunidad, pero por lo general, un equipo mucho más pequeño es el responsable de la dirección general del proyecto. Esto acelera el proceso de toma de decisiones y garantiza que alguien siempre sea el responsable.

Para los proyectos de InnerSource, la distribución del control entre un grupo más pequeño de participantes a menudo hace que las aprobaciones y las revisiones sean más eficaces. Crear un equipo pequeño y multifuncional de personas a cargo de la toma de decisiones también puede ayudar a los equipos a cumplir con las normas de calidad y a lograr el apoyo de los ejecutivos.

Una comunidad de código abierto detrás de tu firewall

El término InnerSource se describe de diversas maneras, y es posible que los desarrolladores de las organizaciones que ya participan en las comunidades de código abierto grandes no lo utilicen para nada. Por el contrario, ven este enfoque simplemente como una forma de aplicar las metodologías del código abierto en el desarrollo del software de su firewall.

La InnerDource no implica menor seguridad ni privacidad. No es necesario compartir el software propietario de manera pública ni invitar a las personas externas a que vean el código fuente o accedan a los proyectos de InnerSource. Las empresas pueden quedarse tranquilas porque el código no público permanecerá seguro dentro de su entorno, y solo los desarrolladores con los permisos correspondientes podrán efectuar contribuciones.

La adopción de esta práctica es similar a crear una comunidad dentro de la organización. Con el código abierto, la colaboración transparente moviliza las habilidades y el conocimiento colectivos para crear un software mejor. En cambio, una comunidad de InnerSource contiene las herramientas, el conocimiento, las habilidades y las capacidades de las personas dentro de una sola empresa.

¿Por qué la adoptan las empresas?

A medida que las empresas evolucionan y diferencian sus productos y servicios con software y datos (o reconocen que el software y los datos son su producto o servicio), se dan cuenta rápidamente de que los métodos y las herramientas de desarrollo tradicionales no funcionan del todo. La lenta práctica sistemática de reunir requisitos, llevar a cabo reuniones y realizar las actividades de desarrollo en silos no sigue el ritmo de la tecnología en la actualidad, ni siquiera el ritmo de las demandas de los consumidores. Entonces, ¿cómo pueden las empresas mantener el ritmo?

La InnerSource ayuda a los equipos a desarrollar software más rápido y a trabajar mejor de forma conjunta, lo que resulta en un desarrollo de mejor calidad y una mejor documentación. También puede ayudar a las empresas a volverse más eficientes al:

• Facilitar la detección y la reutilización de código en una escala amplia, lo que permite evitar el derroche de recursos y la duplicación

• Impulsar el desarrollo rápido, independientemente del tamaño de la empresa

• Reducir la cantidad de silos y simplificar la colaboración en toda la empresa, tanto entre los equipos y las funciones como al interior de estos, además de en todas las áreas y líneas de negocio.

• Aumentar la claridad entre los ingenieros y la administración, así como con cualquier persona que esté interesada.

• Crear una cultura de apertura, precursora de la participación en el código abierto.

• Reforzar el orgullo, el crecimiento y la satisfacción por el trabajo por parte de los miembros del equipo que contribuyen donde sea que haya una necesidad.

Empresas líderes como PayPal, Bloomberg y Walmart usan la InnerSource para desarrollar software para sus equipos y clientes. Les proporciona una ventaja competitiva única y los ayuda a mantenerse vigentes al adoptar prácticas recomendadas reconocidas.

La anatomía de un proyecto de InnerSource

La combinación adecuada de personas, equipos y recursos puede garantizar el éxito de un proyecto. Muchos proyectos de código abierto siguen una estructura organizativa similar, una que puedes querer considerar a la hora de organizar equipos multifuncionales para que se encarguen de los proyectos de InnerSource de tu empresa. Un proyecto de código abierto típico tiene los siguientes tipos de personas:

• Mantenedores: colaboradores que son responsables de impulsar la visión y administrar los aspectos organizativos del proyecto. No son necesariamente los dueños o autores originales del código.

• Colaboradores: todas las personas que hicieron alguna contribución al proyecto.

• Miembros de la comunidad: personas que utilizan el proyecto. Pueden ser activas en las conversaciones o expresar sus opiniones sobre la dirección del proyecto.

Los proyectos más grandes también pueden tener subcomisiones o grupos de trabajo dedicados a diferentes tareas, como la organización de herramientas, la clasificación de errores y la moderación de las conversaciones de la comunidad.

Es probable que los proyectos de InnerSource sigan una estructura similar. Muchas organizaciones de ingeniería distribuyen a los desarrolladores en equipos, como los de ingeniería de aplicaciones, ingeniería de plataformas y desarrollo web. Estructurar las organizaciones de este modo puede dejar puntos ciegos que excluyan a personas calificadas. Organizar un grupo central de toma de decisiones que tenga el respaldo de los equipos de toda tu empresa puede ayudar a reunir la experiencia necesaria para resolver una incidencia determinada más rápido.

Dentro de una empresa, los “colaboradores” son los desarrolladores de todos sus sectores, mientras que los “mantenedores” son los líderes y los encargados de la toma de decisiones clave de un proyecto.

• Mantenedores: desarrolladores, gerentes de productos y otros encargados clave de la toma de decisiones dentro de la empresa que tienen la responsabilidad de impulsar la visión de un proyecto y de gestionar las contribuciones día tras día.

• Colaboradores: desarrolladores, analistas de datos, gerentes de productos, vendedores y otras funciones dentro de la empresa que ayudan a impulsar el software. No es necesario que los colaboradores formen parte del equipo directo del proyecto, pero ayudan a desarrollar el software contribuyendo con código, enviando correcciones de errores y más.

Herramientas del oficio

Aquí presentamos algunas herramientas que impulsan el desarrollo de código abierto en GitHub. También son piezas clave de cualquier proyecto de InnerSource.

• Issues: el espacio donde los desarrolladores plantean temas y empiezan conversaciones. Si alguien encuentra un error o tiene una idea para una nueva característica, una incidencia es una excelente forma de comenzar, y cualquiera con acceso a él puede unirse al debate. Obtén más información sobre las incidencias.

• Pull requests: son conversaciones vivas sobre los cambios que les gustaría hacer a los desarrolladores en un proyecto. Es donde las personas empiezan a trabajar en las soluciones y revisan los cambios que están en proceso. Obtén más información sobre las pull requests.

• Canales de chat sincrónicos: a veces los equipos deben tomar decisiones rápidas. Los canales de chat sincrónicos, como Slack, complementan los debates y los comentarios en GitHub y son muy útiles para hablar sobre los problemas en tiempo real.

Hay cientos de herramientas disponibles para usar con GitHub que pueden ayudar a tu equipo a trabajar mejor, desde la administración de los proyectos hasta los servicios de continuous integration y deployment. Consulta cuáles son todas ellas.

¿Es adecuada para tu empresa?

La InnerSource es tanto un cambio cultural como uno tecnológico, y resulta importante no subestimar el desafío que esto puede suponer para algunas empresas. Como sus equivalentes de código abierto, los proyectos de InnerSource se desarrollan en lugares donde los esfuerzos se inclinan naturalmente hacia el descubrimiento y la reutilización. También ayuda tener comunidades pequeñas y multifuncionales de la empresa que compartan experiencia e intereses similares.

En general, hay pocos factores que buscar que puedan ayudarte a decidir si incorporar el enfoque de la InnerSource a tu trabajo e iniciar el proceso de planificación:

• Tu empresa tiene una visión de los proyectos que es realista y que todos los equipos comparten. Los proyectos deben tener claramente definidos los problemas y las oportunidades que se van a abordar.

• Los participantes clave (iniciadores, intermediarios y evangelistas tecnológicos) de los proyectos que planeas gestionar según el enfoque de InnerSource tienen experiencia en el trabajo colaborativo.

• Cuentas con un plan para preparar a nuevos “colaboradores” y otros participantes e incorporarlos en el proceso.

• Tu equipo dispone de las herramientas y los procesos necesarios para comunicarse abiertamente y compilar de forma coherente.

• Puedes empezar con un grupo de personas pertenecientes a la empresa que tengan objetivos compartidos definidos.

El enfoque de InnerSource puede cambiar la forma en que las personas se ven a sí mismos y sus responsabilidades, lo que hace importante tener en cuenta la estructura de la empresa. Un proceso eficaz de InnerSource debe ser informal, autoselectivo, contar con mentores y brindar apoyo a sus participantes.

Para adoptar las prácticas de la InnerSource de manera eficaz, los colaboradores deben poder trabajar fácilmente en los silos y otras divisiones organizativas. El grado en que una empresa apoya las iniciativas que promueven compartir los conocimientos puede ser un buen indicador de qué tan bien se podrá adaptar.

Para conocer ejemplos reales, consulta Creating an innersource culture at Booz Allen Hamilton (Creación de una cultura de InnerSource en Booz Allen Hamilton).

Estas son solo algunas preguntas que pueden ayudarte a evaluar qué tan listo está tu equipo. Si tu respuesta a muchas de ellas es “sí”, es posible que estés listo para comenzar un programa de InnerSource en tu empresa.

• ¿Nuestra empresa tiene una cultura abierta y transparente?

• ¿Desarrollamos software en una única plataforma abierta?

• ¿Nuestras iniciativas de ingeniería cuentan con los recursos adecuados y con el apoyo de los equipos de liderazgo?

• ¿Los desarrolladores de nuestra empresa tienen suficiente autonomía para colaborar en proyectos externos a sus equipos inmediatos?

• ¿Nuestra empresa participa en la comunidad de código abierto?

• ¿Nuestro equipo de ingeniería usa herramientas de integración continua?

• ¿Existen comunidades preexistentes e interdisciplinares que trabajen en los distintos equipos de nuestra empresa?

• Si es así, ¿estas comunidades cuentan con líderes integrados?

Cada empresa es diferente, y ninguna de estas preguntas debería considerarse un requisito previo para que una organización pueda adoptar el enfoque de la InnerSource. En general, deberías empezar a aplicar las prácticas de InnerSource cuando sientas que hay confianza suficiente entre los equipos de toda la empresa para considerar la visión de los demás, contribuir a su trabajo y comentar sobre él. Muchas empresas eligen empezar por un programa piloto y, luego, deciden lo que les resulta mejor.

¿Todo listo para comenzar?

Las empresas por lo general inician sus programas de InnerSource comenzando de a poco. Los proyectos piloto pueden ayudar a los equipos a experimentar con más procesos abiertos, democratizar el acceso al código y documentar las prácticas recomendadas antes de aplicar la InnerSource a mayor escala. Los pequeños éxitos pueden ayudar a demostrar a la comunidad interna de desarrolladores cómo aprovechar al máximo el código y producir mejores sistemas de software con mayor rapidez.

La manera en que se desarrolla el software es en esencia diferente a como era hace una década. La InnerSource es un enfoque que permite modernizar los procesos, acelerar el desarrollo, superar los obstáculos organizativos y mejorar la calidad de los sistemas de software. Al ser la comunidad de código abierto más grande del mundo, GitHub es el lugar donde surgen las prácticas recomendadas de dicho enfoque. Juntos, podemos cambiar la forma en que los miembros de tu equipo llevan a cabo el desarrollo de software.