Extensións para o crecemento sostible
un proxecto InnerSource está a recibir demasiadas contribucións, o que dificulta o seu mantemento. Os/As responsables ofrecen un mecanismo de extensión fóra do proxecto principal, que permite escalar as capacidades do proxecto cun custo e gastos xerais de mantemento mínimos.
A medida que o número de contribucións a un repositorio InnerSource maduro aumenta rapidamente, engádese máis carga de traballo nas revisións e mantemento do código. Isto provoca unha grande acumulación de código pendente de revisión ou un rexeitamento prematuro das contribucións de novas funcionalidades.
Como pode o host team lanzar novas funcionalidades de contado e fomentar a innovación e a experimentación, ao tempo que se encarga do mantemento do repositorio?
Trátase dun proxecto estratéxico co obxectivo de recompilar nunha pila compartida as mellores innovacións dentro dun espazo de dominio, o que permite a reutilización dunha infraestrutura común e proporciona unha experiencia de usuario/a estándar. A través de InnerSource, distintos equipos da organización que traballen neste espazo de dominio, poderán ter a oportunidade de colaborar e contribuír coas súas innovacións á base de código común.
Non obstante, ter un gran número de contribucións paralelas de varios/as desenvolvedores/as dificulta o mantemento da base de código. Isto está a engadir unha enorme carga para os/as mantedores/as do proxecto, que asumen a responsabilidade dos estándares de calidade do código e habilitan á comunidade a través de diversas formas de comunicación.
Os/As encargados/as do mantemento do proxecto poderían estar en risco de esgotamento por:
A acumulación continua de pull requests de contribuidores/as que precisan ser revisadas.
A insatisfacción laboral: Os/As mantedores/as empregan a meirande parte do seu tempo no servizo de asistencia á comunidade, o que non deixa espazo para a innovación.
A percepción de falta de consecución de logros: Se non contan con suficiente demanda dos/as usuarios/as, non tódalas funcionalidades engadidas tornarán na súa conseguinte adopción.
Os lanzamentos que levan moito tempo: Máis funcionalidades na base de código requiren probas de longa duración.
O aumento das actividades de mantemento: Xorden máis erros (bugs) a medida que se engaden novas capacidades.
Dedícase moito tempo a madurar cada nova funcionalidade engadida, antes de que os/as potenciais usuarios/as teñan a oportunidade de explorala para os seus casos de uso. Se a nova funcionalidade non resultase satisfactoria para o caso de uso, todo o tempo empregado en acadar os estándares de calidade de código desexados suporía un desproveito.
Unha base de código estratéxica de InnerSource escálase rapidamente coas contribucións de novas funcionalidades de distintos/as empregados/as.
A proporción número de revisores/as por contribucións ten como resultado unha crecente acumulación de pull requests. Isto desacelera o lanzamento de novas funcionalidades á comunidade.
A calidade da base de código estase a degradar e a experiencia do/a usuario/a vese afectada negativamente.
Os/As mantedores/as da base de código están sobrecargados/as e non poden seguir o ritmo da afluencia de contribucións e o incremento do servizo de asistencia á comunidade.
Algunhas das características engadidas non están a ser adoptadas polos/as usuarios/as, e mesmo poderían quedar completamente inactivas. Sen embargo, aínda se non se empregan, estas características contribúen á suma dos gastos xerais de mantemento.
A organización inverte considerablemente no fortalecemento das contribucións de novas funcionalidades para manter os estándares de calidade, mesmo antes de que esas ideas sexan exploradas pola comunidade.
O modelo aplícase en calquera escenario:
Os/As mantedores/as teñen que rexeitar ideas de novas funcionalidades para limitar o alcance do proxecto. Isto está a dificultar a innovación na comunidade e a restrinxir unha expansión maior.
Para reducir as acumulacións, lánzanse novas funcionalidades sen documentación, fortalecemento ou probas exhaustivas; o que xera unha experiencia de usuario/a deficiente. Ademais, isto está a aumentar o tamaño da base de código, un grande engadido no gráfico de dependencia que dificulta o seu mantemento.
Os/As mantedores/as e product owners queren permitir a expansión, fomentar a innovación e a experimentación sen ser excesivamente restritivos/as nas contribucións; cun bo código e estándares de calidade para a experiencia do/a usuario/a.
Para cumprir eses estándares do produto, dedícase unha gran cantidade de tempo ao fortalecemento e probas exhaustivas das funcionalidades. Por outra banda, os/as product owners tamén poderían permitir un lanzamento máis rápido de innovacións, para adoptar produtos que explorar antes de investir tempo en madurar as súas capacidades.
Os/As mantedores/as queren alentar á comunidade a compartir innovacións que combinen as capacidades do produto con outros casos de uso, sen engadir máis dependencias ao repositorio primario.
Permitir extensións/plugins para bases de código InnerSource a grande escala pode aliviar a carga de traballo dos/as mantedores/as do repositorio e permitir un lanzamento máis rápido de novas funcionalidades para adoptar produtos que explorar. Isto traslada o mantemento das capacidades aos/ás extension owners, ao tempo que permite que o repositorio primario atenda ás capacidades adoptadas dun xeito máis extenso e estratéxico.
As extensións proporcionan un filtro para novas capacidades que, eventualmente, poden pasar ao núcleo do proxecto. Estas extensións tamén actúan como un entorno de incubación e fortalecemento da comunidade, o que permite que gran parte dese fortalecemento ocorra de xeito orgánico, en lugar de nun custoso proceso de revisión.
Para que o modelo de extensións teña éxito, haberá que ter en conta algunhas consideracións arquitectónicas coas que cumprir:
Fáciles de crear: Para obter a participación da comunidade, as extensións deben ser doadas de crear.
As extensións deberían ter como punto de partida un repositorio prototipo. A creación destes prototipos permite que as novas funcionalidades das extensións se engadan a novos repositorios separados do proxecto principal. O prototipo debe aportar a mesma estrutura modular que o repositorio primario e incluír o marco de traballo para empaquetar e lanzar extensións.
É necesario asegurarse de que, a medida que cambia o repositorio primario, os prototipos continúan ben mantidos. Os/As propios/as mantedores/as do devandito repositorio serán tamén os/as responsables de actualizar os prototipos para garantir a súa compatibilidade co proxecto principal. Seguir bos mecanismos de versionado, por exemplo, SemVer, facilita ese proceso.
Recoméndase, ademais, que os/as mantedores/as do repositorio primario proporcionen orientación sobre como actualizar as extensións baseadas en versións antigas dos prototipos, a medida que se publiquen versións máis novas.
É preciso engadir exemplos de extensións desenvolvidas a partir do prototipo, que os/as desenvolvedores/as do proxecto poidan consultar para comprender como escribir unha extensión ben modelada.
E haberá que afrouxar os requisitos para que os/as contribuidores/as creen extensións que eviten as revisións e permitir así un lanzamento ou experimentación máis rápidos.
Baixa dependencia: Ter compoñentes modulares que conteñan funcionalidades pode favorecer a baixa dependencia, na que os cambios nas extensións non afectan á calidade da base de código principal ou doutras extensións.
Xestión de dependencia: Cada extensión debe coidar de fixar o rango de versións do repositorio primario sobre o que se constrúe (do mesmo xeito que faría con calquera outra dependencia). Tamén se debe ter coidado no uso doutras dependencias que ocultan as do repositorio primario, e que as versións elixidas para esas dependencias sexan compatibles coas versións seleccionadas. Calquera conflito co repositorio primario recollerase no marco de proba da extensión.
Estratexia de proba: Como probar as extensións tanto individualmente como de xeito combinado?
Probar a extensión individualmente: O prototipo de extensión proporcionará un marco de proba, que será empregado polos/as desenvolvedores/as de extensións para probar a capacidade engadida. Isto pode incluír un marco para probas unitarias, o rendemento en tempo de execución e probas de calidade.
Probar a extensión en combinación co repositorio primario: Os/As desenvolvedores/as de extensións teñen un método ben establecido para probar a súa extensión fronte a versións específicas do repositorio primario sen a implicación dos/as mantedores/as do devandito repositorio.
Probar a extensión en combinación con outras extensións: Proporcionar un marco de proba para este escenario podería resultar excesivo, especialmente se hai un gran número de extensións que aínda están explorando os/as usuarios/as e é improbable que se empreguen todas de xeito combinado. Se un/unha usuario/a se atopa con conflitos ao usar extensións combinadas (o que debería ser improbable cunha baixa dependencia), pode informar dunha incidencia aos/ás respectivos/as extension owners para que o resolvan. A medida que unha extensión acade as derradeiras fases do seu ciclo de vida e se integre co repositorio primario, pasará probas combinadas co resto da libraría e calquera incidencia posible resolveríase nese intre.
Dispoñibilidade e utilización:
É necesario que os/as usuarios/as que crearon as extensións as mostren nunha páxina de publicación, co fin de compartilas de maneira sinxela para o seu uso.
Será preciso permitir o rexistro de extensións co proxecto primario, para que os/as usuarios/as poidan valerse das extensións xunto co proxecto orixinal, mantendo así a mesma experiencia de usuario/a.
Ciclo de vida das extensións e o seu mantemento: Débese establecer o ciclo de vida das extensións desde a súa creación ata a súa portabilidade á base de código primario, xunto con directrices de propiedade claras.
Os/As creadores/as de extensións teñen que continuar o seu mantemento, proporcionar asistencia e corrixir as fallas. Calquera extensión sen mantemento será eliminada da páxina de publicación.
Teranse que crear criterios específicos para cando unha extensión pode ser portada ao repositorio primario, como a adopción da extensión por produtos internos e a demanda da funcionalidade.
O proceso de portar a extensión ao repositorio primario seguirá directrices de revisión de código máis estritas, establecidas polos/as mantedores/as da libraría.
Seguir estes principios garante que:
Os/As desenvolvedores/as poidan engadir novas funcionalidades ao ecosistema do proxecto sen a esixencia de ter que escribir grandes cantidades de código repetitivo.
As extensións pódense descubrir dun xeito replicable por tódolos/as usuarios/as do proxecto principal. Só porque o código non estea no repositorio primario non implica que non sexa valioso.
A carga de traballo do/a mantedor/a redúcese ata que unha extensión permita cubrir un baleiro importante no proxecto primario.
O código central común do proxecto (por exemplo, clases base e funcionalidades de utilidade) pode ser un punto de partida para novos desenvolvementos que estendan o dominio de proxecto. Isto evita a necesidade de portar traballos innovadores despois, reducindo así a carga xeral de desenvolver funcionalidades novidosas para o proxecto.
É máis probable que os/as desenvolvedores/as contribúan e sigan involucrados/as no mantemento e na construción de comunidades para a súa base de código, o que tamén é bo para a saúde xeral do ecosistema do proxecto.
O proxecto é capaz de escalar coa adición de novas funcionalidades, sen engadir sobrecarga de mantemento no repositorio primario do proxecto.
Un lanzamento máis rápido de novas funcionalidades para que a comunidade explore, fomenta a innovación e a experimentación.
Cómpre reducir o custoso proceso de revisión de código e o fortalecemento das funcionalidades ata que se poida probar a utilidade da funcionalidade. Pois isto repercutirá nos beneficios de aforro de custos para a organización.
Un problema que pode xurdir posteriormente é: que pasa se unha extensión non pode completar o ciclo de vida?
Se unha extensión non se adopta durante un período de tempo e non se puido construír unha comunidade ao seu redor para dar soporte ao seu mantemento, corresponderíalle ao/á extension owner continuar manténdoa durante tanto tempo como queira. Se unha extensión non ten mantemento, quedaría sen publicar.
Se un/unha desenvolvedor/a de extensións non pode seguir mantendo o seu proxecto e outros/as desenvolvedores/as da comunidade quixesen seguir prestándolle soporte, estes/as últimos/as poderían continuar co mantemento da extensión no futuro.
IBM Corporation adoptou esta solución para escalar librarías InnerSource de IA. Ao usar extensións, os/as desenvolvedores/as poden ampliar as librarías IA con máis algoritmos e compartir as súas innovacións coa comunidade interna da compañía. As librarías principais conteñen só algoritmos estratéxicos que xa foron adoptados e validados, polo que serán máis doados de manter segundo escalamos as contribucións.
Extensións para xestionar contribucións a escala
Estruturado
Sukriti Sharma, IBM
Alexander Brooks, IBM
Gabe Goodhart, IBM
Leticia Gómez Cadahía
María Lucía González Castro