[22/11/2021] Originalmente acuñado por Tim O'Reilly, la fuente interna es un principio de ingeniería que tiene como objetivo llevar los métodos de código abierto dentro de las cuatro paredes de una organización para construir software propietario. La apertura en cuestión se extiende a todos los equipos dentro de una organización, en lugar de abarcar múltiples colaboradores de diferentes organizaciones.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Esto trae consigo un conjunto de técnicas y herramientas comunes, utilizadas en comunidades de código abierto que permiten que grandes grupos de contribuyentes trabajen juntos en un código que no es necesariamente su responsabilidad principal. Por lo general, esto incluye el uso de repositorios de código compartido, solicitudes de extracción, comentarios y extensa documentación.
Es una metodología que está comenzando a ser cada vez más popular entre las empresas más tradicionales que buscan modernizar sus prácticas de desarrollo de software y comenzar a ver su código como activos colaborativos y reutilizables, en lugar de como propiedad intelectual que el equipo responsable de ella debe mantener bajo llave. El enfoque de fuente interna también elimina los bloqueadores ascendentes, al permitirles a los desarrolladores realizar cambios ellos mismos a través de solicitudes de extracción, de una manera segura y transparente.
La adopción de la fuente interna requerirá un cambio cultural significativo para ciertas organizaciones, pero puede ayudar a mejorar la calidad, confiabilidad y seguridad de su código, al mismo tiempo que fomenta una mayor colaboración y velocidad del desarrollador, al romper los silos de larga data -algo que adquirió incluso más relevancia durante la pandemia.
"Si hay algo que la fuente interna ha demostrado, es que la colaboración muy extendida, basada en pares, entre equipos asincrónicos puede ser tan efectiva como los equipos controlados estrictamente en la misma sala y zona horaria”, comentó Danese Cooper, fundador de InnerSource Commons Foundation. Esos mismos atributos fueron clave para hacerse camino en el trabajo durante la pandemia de COVID-19, lo que ayudó a demostrar la efectividad y alentó la adopción del enfoque de fuente interna.
InfoWorld habló con tres empresas que adoptan métodos de fuente interna para ver por qué la fuente interna les conviene, y qué logros les ha ayudado a sus desarrolladores a alcanzar.
Bloomberg: Empoderar a los ingenieros para que sean el cambio que quieren ver
Una industria donde la fuente interna ha echado raíces es la de servicios financieros, donde los silos organizacionales y el enfoque -a menudo reservado y conservador- de no compartir el código ha sido la norma durante mucho tiempo.
"Para las organizaciones más tradicionales, la fuente interna es un cambio del viejo mundo donde uno nadaba en su propio carril”, afirmó Gil Yehuda, director de código abierto de US Bank, durante el Open Source Strategy Forum de Londres, en octubre del 2021. "La noción de proteger el código al no compartirlo es una fina capa, debido a las profundas dependencias en las que todos confiamos. Es más saludable verlos como un conjunto común de activos de los que todos podemos beneficiarnos”.
En el mismo panel ese día estaba Arthur Maltson, un distinguido ingeniero de Capital One, quien afirmó que "hoy hay mucho código compartido y contribuciones cruzadas de negocios a las plataformas de Capital One. A medida que los ingenieros maduran, el código se convierte en un medio para resolver un problema comercial, y eso se logra mejor siendo una fuente interna y siendo más abierto. Los problemas se resuelven mejor con más personas. Tenemos que dejar de tener una excesiva cultura de la propiedad entre los ingenieros”.
En Bloomberg, la fuente interna se ha convertido lentamente en la norma durante los últimos 10 años, extendiéndose desde sus raíces en el equipo de herramientas de desarrollo interno, hasta convertirse en una forma aceptada de trabajar para el comercio de activos cruzados y otras aplicaciones clave.
"Ahora más que nunca, los ingenieros de toda la empresa están capacitados para ser el cambio que desean ver en la base de código de otro equipo, ya sea una simple corrección de errores que haga feliz a un cliente, o una característica importante que mejore la productividad en un gran grupo de ingenieros”, afirmó Joe Patrao, líder del equipo de Bloomberg, durante una presentación a principios de este año.
En la actualidad, todos los ingenieros de Bloomberg utilizan GitHub Enterprise para ver y colaborar en el código con sus colegas, lo que incluye una contribución clara y pautas de prueba. "Usamos solicitudes de extracción y revisiones de código para realizar cambios, y el estándar de lo que uno espera de una [solicitud de extracción] varía de un equipo a otro”, señala Becky Plummer, líder del equipo de ingeniería de software de Bloomberg. El umbral para realizar una solicitud de extracción para una herramienta interna puede ser más bajo que para una aplicación comercial muy regulada, por ejemplo.
Antes de que estos métodos de fuente interna se incorporaran a Bloomberg, un ingeniero habría tenido que ponerse en contacto con el gerente de producto correspondiente para solicitar una función o integración, lo que ralentizó la velocidad del desarrollador y obstaculizó la colaboración entre equipos. "A lo largo de los años, hemos aprendido que es una experiencia de aprendizaje fenomenal y que también proporciona valor y acelera la entrega de productos”, agrega Plummer.
BBC: Reutilización de código para acelerar la entrega de funciones
La British Broadcasting Corporation, emisora nacional del Reino Unido, ha desarrollado orgánicamente una cultura de fuente interna durante los últimos cuatro años. Ha acercado a los equipos internos, ha permitido una mejor colaboración entre los departamentos, y ha impulsado ciclos de desarrollo de software más eficientes.
En el equipo de aplicaciones de TV específicamente, que se centra en las aplicaciones iPlayer y Sounds, que son muy populares, el código abierto ya se entendía bien, porque ese equipo ya había abierto su propia capa de aplicación de TV en el 2012. Pero la práctica fue menos común en el resto de la organización.
"Ya éramos grandes consumidores de código abierto, y cuando abrimos nuestro propio software, como TV Application Layer, eso realmente impulsó una cultura de fuente interna”, comenta Tom Sadler, líder del equipo de ingeniería de software para las aplicaciones iPlayer y Sounds de la BBC. "Nació por necesidad en 10 equipos que trabajaban en el desarrollo de aplicaciones de TV, donde poder colaborar entre esos equipos era realmente importante”.
Por ejemplo, el lanzamiento de Sounds on TV -una aplicación de radio para televisores inteligentes lanzada por la BBC en marzo del 2020- pudo llegar al mercado más rápido de lo previsto gracias a la cultura de fuente interna en esos equipos al reutilizar el código de la aplicación iPlayer TV, lanzado previamente, en lugar de empezar desde cero.
Mediante el uso de procesos de entrega continua y de solicitud de extracción consistente en todos los equipos, ese enfoque de fuente interna para el desarrollo de software comenzó a extenderse. "En lugar de necesitar un equipo para hacer algo por nosotros, pasamos a trabajar con ellos”, afirmó Sadler.
En términos de cómo se procesan y aprueban los cambios en la BBC, se trata de un juicio interno sobre lo que constituye un cambio mayor o menor. Para cambios menores, hay un elemento de confianza organizacional que se activa. Para cambios más significativos, la BBC sigue un proceso de solicitud de cambio similar a los grandes proyectos de código abierto como el lenguaje de programación Rust, donde cualquier persona, directamente afectada por ese cambio, tiene la oportunidad de comentar y sugerir alternativas antes de que se fusione el cambio.
Esta cultura realmente pagó dividendos durante la pandemia, donde la colaboración asincrónica fue vital cuando los equipos de desarrollo se volvieron remotos. "Tener una mentalidad de solicitud de extracción, conversaciones vía Slack y Teams, e instalar mecanismos para tomar decisiones entre equipos, definitivamente nos ayudó durante la pandemia”, afirma Sadler.
Asos: No debería haber sorpresas en un PR
El minorista de ropa en línea Asos tenía la ventaja de tener muy poco legado cuando se trataba de establecer una fuente interna en sus aproximadamente 70 equipos de ingenieros hace cuatro años. "Esos equipos son DevOps, ágiles y poseen sus propias aplicaciones con un buen nivel de autonomía, por lo que vimos una oportunidad para acelerar la entrega entre equipos”, comenta Dave Green, director de Arquitectura e Ingeniería de Asos.
Al acelerar esa mentalidad de fuente interna en todos los equipos, Asos pudo romper algunos silos organizacionales, alentar la reutilización del código, y poner más atención en el código para mejorar la calidad. "Queremos derribar las paredes para que todos puedan ver a los demás. La transparencia y la buena comunicación nos permiten construir comunidades dentro de Asos”, afirma el ingeniero principal de Asos, Tony Gorman.
"La idea es mejorar el código y habilitar más capacidades y respetar que el código es propiedad de alguien -todo el mundo es valioso con el código de alguna manera- por lo que hacer las cosas de forma clara y transparente es clave”, afirma.
Sin embargo, eso no significa que todo funcionó sin complicaciones. "Es un viaje. Uno escribe código de manera diferente cuando sabe que otros lo verán y contribuirán, que cuando es solo interno. La documentación y la automatización son clave”, afirma Green.
No se cometieron demasiados errores en esos primeros días, según Green y Gorman, pero hubo un caso en el que un ingeniero frustrado decidió impulsar una nueva función sin seguir el proceso adecuado antes de irse de vacaciones. "Eso llevó a una conversación sólida”, afirma Gorman.
Este viaje llevó a que surgiera una especie de mantra en Asos: "No debería haber sorpresas en torno a una [solicitud de extracción] de relaciones públicas”. Al utilizar GitHub y Microsoft Azure Repos, junto con herramientas de colaboración como Slack y Microsoft Teams, los ingenieros de Asos pueden trabajar de forma segura en una fuente interna, donde la colaboración entre equipos se ha convertido en la norma.
Ahora Asos está viendo cómo los proyectos internos se desarrollan de una manera que podría valer la pena volver a abrir en la comunidad. "Hay un deseo de retribuir”, afirma Gorman.
Por dónde empezar con la fuente interna
Muchos de los ingenieros con los que habló InfoWorld señalaron a PayPal como el estándar de oro para comenzar con la fuente interna.
Otros recursos útiles para comenzar con la fuente interna incluyen los libros electrónicos Getting started with InnerSource y Adopting InnerSource.
Para una comunidad activa en torno a la fuente interna, no busque más allá de InnerSource Commons, que cuenta con blogs, una wiki, un repositorio de Git, una serie de videos de ruta de aprendizaje en YouTube, historias de usuarios y patrones probados.
Basado en el artículo de Scott Carey (InfoWorld) y editado por CIO Perú