A comunidade InnerSource Commons aporta cada vez máis modelos a este libro; o que é incrible!

Pero, como facilitar que os/as lectores/as descubran os modelos que poden axudalos/as na súa situación particular?

Para isto proporcionamos este mapa conceptual, que clasifica os modelos en función das diferentes fases dun programa InnerSource e dos desafíos que poden xurdir nas respectivas fases.

Mellore este mapa conceptual

Se vostede detecta algo neste mapa conceptual que lle resulta incorrecto, pode abrir unha incidencia na que describa o problema xunto co arranxo que se debería levar a cabo.

Ademais, se ten outras ideas para dar a coñecer estes modelos ou desexa mellorar este mapa conceptual, revise a documentación do noso enfoque de Categorización de modelos e verifique como contribuír a este libro.

Referencias

A idea de categorizar modelos como este baséase, parcialmente, na descrición en Thoughts on an InnerSource Pattern Language [Reflexións arredor do modelo InnerSource] de Tim Yao, Bob Hanmer e Padma Sudarsan (2018). Para obter máis detalles, pode consultar a diapositiva 15 da presentación.

• Introdución

• Índice

• Explore os modelos

• Contribúa a este libro

Modelos

• Agradecemento aos/ás participantes - Tras unha contribución a un proxecto InnerSource, é importante agradecer ao/á colaborador/a polo seu tempo e esforzo. Este modelo brinda unha orientación que non só recoñece dun xeito eficaz a súa contribución, senón que tamén xera un maior compromiso deste/a e doutros/as contribuidores/as.

• Casos de uso cun sistema de seguimento de incidencias - o host team de InnerSource non logra ter transparencia nos plans nin no progreso, e tampouco no contexto para os cambios. Isto resólvese aumentando os casos de uso co sistema de seguimento de incidencias do proxecto para que tamén favoreza o intercambio de ideas, o debate sobre estas e o deseño de funcionalidades.

• Comece como un experimento - comece a súa iniciativa InnerSource como un experimento de tempo limitado para facilitar que o persoal directivo, que non estea familiarizado con InnerSource, secunde e apoie a iniciativa.

• Comité de revisión - o modelo de traballo InnerSource é un afastamento radical dos enfoques máis tradicionais, tanto para os/as desenvolvedores/as como para os/as seus/súas superiores/as. Ao establecer un comité de revisión como interface entre a iniciativa InnerSource e todos os altos cargos das áreas empresariais que participan nela, é máis probable que estes últimos se familiaricen coa iniciativa e a apoien; xa que lles brinda un certo nivel de supervisión e control, sen fomentar a microxestión.

• Contracted contributor - os/as socios/as que desexen contribuír a InnerSource son disuadidos/as de facelo polos/as seus/súas superiores/as. Os contratos e acordos formais son un alivio.

• Core team - incluso cando se necesita moito un proxecto InnerSource, as colaboracións e o seu uso poden verse obstaculizados porque é difícil traballar co proxecto. Estableza un core team que se dedique a coidar dos elementos fundamentais do proxecto. O traballo do core team permítelle aos/ás contribuidores/as engadir e empregar as funcionalidades que achegan valor aos seus escenarios.

• Cualificación da actividade do repositorio - os/as potenciais contribuidores/as queren atopar proxectos InnerSource activos que precisen da súa participación. Ao calcular a cualificación da actividade do repositorio para cada proxecto, pódese crear unha listaxe clasificada de proxectos (por exemplo, no portal InnerSource) para que os/as posibles contribuidores/as poidan determinar dun xeito máis doado en que proxecto desexan colaborar.

• Documentación base estándar - ós/ás novos/as contribuidores/as dun proxecto InnerSource teñen dificultades para determinar quen mantén o proxecto, en que traballar e como contribuír. Ao proporcionar documentación en arquivos estándar como README.md/CONTRIBUTING.md permítese un proceso de autoservizo para os/as novos/as contribuidores/as, de xeito que poidan atopar por si mesmos/as as respostas ás preguntas máis comúns.

• Documente os seus principios reitores - a explicación habitual de InnerSource baseada en «aplicar as mellores prácticas de software libre dentro dunha organización» non funciona correctamente coas persoas que carecen de experiencia con software libre. Como solución, os principios InnerSource máis importantes documéntanse e publícanse de maneira aberta.

• 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.

• Ferramentas de comunicación - os/as usuarios/as dun proxecto InnerSource teñen problemas para obter axuda e poñerse en contacto co host team. Mediante o uso sistemático de ferramentas de comunicación asíncrona, os debates serán visibles e permanecerán arquivados e accesibles; o que se traduce nunha mellora do nivel de asistencia aos/ás usuarios/as.

• Garantía de 30 días - cando se aceptan contribucións externas, existe unha aversión natural do equipo a asumir a responsabilidade do código que non foi escrito por eles/as. A través da garantía de 30 días, o equipo contribuidor acepta proporcionar correccións de erros ao equipo receptor. Isto aumentará o nivel de confianza de ambos os equipos e fará que sexa máis probable que se acepten as contribucións.

• Gig marketplace - establécese un marketplace mediante a creacion dunha intranet que enumere as necesidades específicas do proxecto InnerSource como «Gigs», con requisitos explícitos de tempo e habilidades. Isto permitiralle ao personal directivo comprender mellor o compromiso no tempo e os beneficios profesionais dos seus/súas traballadores/as, o que aumentará a probabilidade de obter a aprobación para realizar contribucións InnerSource.

• Licenza InnerSource - dúas entidades xurídicas que pertencen á mesma organización queren compartir o código fonte do software entre elas, mais preocúpanlles as implicacións en termos de responsabilidades legais ou de contabilidade entre as empresas.

• Líder da comunidade experto/a en InnerSource - seleccione persoas con habilidades técnicas e de comunicación para liderar as comunidades e garantir o éxito no inicio dunha iniciativa InnerSource

• Modelo de madurez - os equipos comezaron a adoptar InnerSource e a práctica estase estendendo a varios departamentos. Con todo, a comprensión do que constitúe un proxecto InnerSource varía. A solución consiste en proporcionar un modelo de madurez que lles permita aos equipos realizar unha autoavaliación e descubrir modelos e prácticas que aínda non coñecían.

• Portal InnerSource - os/as contribuidores/as potenciais non poden descubrir dun xeito sinxelo os proxectos InnerSource nos que están interesados/as. Ao crear unha intranet que indexe toda a información dispoñible do proxecto InnerSource, permítese que os/as contribuidores/as coñezan os proxectos que lles poderían interesar; do mesmo xeito que lles serve aos/ás project owners de InnerSource para atraer a un público externo.

• Requisitos comúns - o código común dun repositorio compartido non satisfai as necesidades de todos os equipos do proxecto que desexan empregalo; isto resólvese mediante a aliñación de requisitos e a refactorización.

• Servizo vs. libraría - os equipos DevOps poden ser reticentes a traballar máis alá dos límites do equipo, en bases de código comúns; posto que non está definido quen sería a persoa responsable de responder ante unha situación de inactividade do servizo. Con frecuencia, a solución pode ser implantar o mesmo servizo en contextos independentes con cadeas de escalada separadas, en caso de caída do servizo ou de factorización dunha gran cantidade de código compartido nunha libraría na que se poidan facer colaboracións.

• Soporte grupal - que acontece se un equipo ou unha persoa abandona un proxecto InnerSource? Para manter vivo o proxecto fórmase un novo grupo de colaboradores/as interesados/as.

• Toma de decisións transparente entre equipos mediante RFC - os proxectos InnerSource que desexan lograr un alto índice de participación e tomar as mellores decisións posibles para todas as persoas involucradas, necesitan atopar formas de crear sistemas participativos durante todo o ciclo de vida do software. A publicación de documentos internos con peticións de comentarios (RFC) permite manter debates desde o comezo do proceso de deseño. Tamén aumenta as posibilidades de idear solucións cun alto grao de compromiso por parte de tódalas partes implicadas.

• Trusted commiter - moitos proxectos InnerSource recibirán valoracións constantemente ou requirirán a posta en marcha de novas funcionalidades e a corrección de erros por parte dos contribuidores/as. Nestas situacións, as persoas encargadas do mantemento do proxecto buscan formas de recoñecer e recompensar o traballo do contribuidor/a máis alá das contribucións individuais.

• Valoración de proxectos entre equipos - é difícil convencer acerca do valor dos proxectos InnerSource desenvolvidos entre equipos que non teñen un impacto directo nos ingresos da empresa. Velaquí unha forma de representar o seu proxecto baseada en datos, que articula o seu valor e amplifícao.

Apéndice

• Prototipo de modelo

• Extras

  • Prototipo README

  • Prototipo CONTRIBUTING

Recursos

• O libro en GitHub

• InnerSource Commons

Quere mellorar este libro? Estupendo!

O libro Modelos InnerSource é un proxecto de software libre en si mesmo e dá a benvida a calquera forma de contribución, por pequena que sexa.

Non importa se desexa axudarnos a corrixir erratas, a mellorar o deseño ou a contribuír con modelos completamente novos baseados nas experiencias InnerSource que realizou no seu lugar de traballo. Calquera aportación é benvida.

Se nunca antes realizou unha contribución a un proxecto de software libre, saiba que a comunidade de Modelos InnerSource é un grupo de persoas amigables e, polo tanto, é un lugar seguro para tentalo.

Antes de comezar

As fontes do Modelo InnerSource e este mesmo libro atópanse nun repositorio de GitHub. Polo tanto, necesitará unha conta de usuario/a de GitHub para realizar modificacións e suxestións a este libro. Se aínda non ten unha, diríxase a github.com e cree unha conta gratuíta.

Diferentes xeitos de contribución

Velaquí algunhas formas nas que pode contribuír:

1. Corrección ortotipográficas, de formato ou doutros erros que atope neste libro.

2. Mellora do contido dun modelo existente (por exemplo, pode engadir unha breve descrición de como está a empregar vostede o modelo no apartado Exemplos coñecidos).

3. Aportación dun novo modelo no que describa como superou os desafíos relacionados con InnerSource na súa organización.

Para (1) e (2), basta con premer na ligazón Editar en GitHub que observa na parte superior de cada páxina deste libro para acceder directamente ao arquivo respectivo do noso repositorio de GitHub, onde pode suxerir os cambios que considere.

Para (3) necesita clonar o repositorio InnerSourcePatterns e engadir un novo arquivo co modelo suxerido. Para facer tales importantes contribucións a este libro, revise a sección de CONTRIBUTING.md e tamén o noso Manual de contribución.

Licenzas das Contribucións

O contido deste repositorio ten licenza CC-BY-SA-4.0. Se contribúe ao mesmo, estanos a outorgar (e, por ende, a tódolos/as demais) o dereito a empregar a súa contribución de acordo coa devandita licenza.

Title

Agradecemento aos/ás participantes

Patlet

Tras unha contribución a un proxecto InnerSource, é importante agradecer ao/á colaborador/a polo seu tempo e esforzo. Este modelo brinda unha orientación que non só recoñece dun xeito eficaz a súa contribución, senón que tamén xera un maior compromiso deste/a e doutros/as contribuidores/as.

Problema

Como podemos expresar axeitadamente a nosa gratitude a un/unha contribuidor/a de InnerSource pola súa contribución a un proxecto? Pode ser doado esquecerse de facelo ou non coñecer as palabras ou o medio a empregar para conseguir un efecto e sinceridade axeitados. Tanto os eloxios como os agradecementos son formas sinxelas e económicas de manter aos/ás colaboradores/as e aos/ás seus/súas xestores/as motivados/as e entusiasmados/as por continuar. Un modelo nesta área fai que sexa fácil de facer e garante que a mensaxe se transmita con claridade e sinceridade.

Contexto

• É o/a trusted committer ou mantedor/a dun proxecto InnerSource.

• Valora a comunidade de contribuidores/as e quere mantela e seguir a medrar.

Aspectos que mellorar

• Está moi ocupado/a e adoita esquecerse dos toques persoais como os eloxios e agradecementos.

• Se cadra non se sinte cómodo/a en situacións sociais ou non é bo/boa coas palabras.

• O recoñecemento entre iguais é moi importante para a satisfacción laboral e o desenvolvemento profesional.

Solucións

A todos/as nos gusta ser recoñecidos/as polos/as demais. No ámbito profesional, un maior recoñecemento supón tamén unha vía para aumentar a nosa influencia e crecemento profesional. Cada vez que alguén faga un aporte ao teu proxecto InnerSource, recoñéceo/a cun sincero e cumprido «grazas».

Para as contribucións non triviais (tódalas contribucións ao código e as contribucións significativas de tempo), podes dar as grazas a través dos seguintes mecanismos:

(1) Chama á persoa polo seu nome en calquera das canles de mensaxería instantánea nas que organices a actividade do seu proxecto (por exemplo, Slack). Que todos/as saiban o que fixo a través dun agradecemento público.

Exemplo:

Todo o mundo @aquí pode darlle a noraboa a @andrew.clegg por actualizar o rcs-viewer á última versión do hebo-client (https://github.com/rcs/rcs-viewer/pull/81). Grazas por axudar a manter a libraría actualizada, Andy!

(2) Envíalles un correo electrónico a eles/as e ao/á seu/súa xestor/a (cc'd) de xeito privado agradecéndolles a contribución. Nos casos de aportacións ao código, moitas veces pódese simplemente reenviar o correo co que se notifica a nova combinación do código.

Exemplo:

Ola, Andy, quero agradecerche de novo que fixeras esta actualización. Tal vez levase pouco tempo, pero son as accións individuais como esta as que fan que o proxecto RCS funcione para todos/as nós. Grazas por resolver o teu propio problema dun xeito que tamén fai que o rcs-viewer sexa mellor para todo o equipo.

Contexto resultante

Comentarios como este deixan ao/á contribuidor/a cunha sensación fantástica e listo/a para volver por máis. A combinación de ambas as dúas formas de agradecemento proporciónalles recoñecemento diante dos/as seus/súas compañeiros/as (maior alcance) e diante do/a seu/súa superior/a directo/a (maior calado). Isto provoca un sutil efecto chamada para que os/as seus/súas compañeiros/as no chat consideren contribuír eles/as mesmos/as e para que o/a seu/súa superior/a procure alentar aos/ás outros/as subordinados/as directos/as a facer o mesmo. Ademais, o coñecemento do proxecto de InnerSource esténdese ao/á xestor/a, que quizais non coñecía previamente o uso e a implicación do equipo con el/ela.

Como advertencia: é necesario mantelo crible. Asegúrese de que as súas palabras deriven do agradecemento sincero que sentes pola aportación que fixeron. Manteña o nivel e a énfase dos agradecementos en relación ao seu nivel de implicación. Esaxerar resultará mecánico e pouco sincero e será unha derrota no seu propósito de chegar aos/ás traballadores/as.

Modelos relacionados

• Just Say Thanks (do libro Fearless Change)

Exemplos coñecidos

• Nike (múltiples proxectos)

Estado

• Estruturado

Autoría

• Russ Rutledge

Recoñecementos

• Todd Lisonbee polos ánimos á hora de «mantelo real».

• Isabel Drost-Fromm por esta explicación extra do que é un agradecemento «cualificado».

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Casos de uso cun sistema de seguimento de incidencias

Patlet

o host team de InnerSource non logra ter transparencia nos plans nin no progreso, e tampouco no contexto para os cambios. Isto resólvese aumentando os casos de uso co sistema de seguimento de incidencias do proxecto para que tamén favoreza o intercambio de ideas, o debate sobre estas e o deseño de funcionalidades.

Problema

Un equipo desenvolve un compoñente do que dependen moitos outros equipos da organización. Usa un sistema de seguimento de incidencias estándar para rastrexar bugs e feature requests. Non obstante, o contexto en cada entrada é moi limitado. Como resultado, os/as posibles contribuidores/as non teñen forma de saber a que cambio se refire exactamente cada unha das incidencias.

Contexto

Está configurada a ferramenta InnerSource para proxectos. Aínda que o sistema de seguimento de incidencias do proxecto emprégase principalmente para compartir o progreso. Nos proxectos InnerSource hai moitos máis casos de uso nos que se pode usar un sistema de seguimento de incidencias que facilitan a comunicación remota e asíncrona.

Aspectos que mellorar

• Os/As contribuidores/as precisarían saber se a funcionalidade que están a botar en falta está xa na folla de ruta. Falta moito contexto nas incidencias, aínda que é imposible decidir se os problemas existentes coinciden coas necesidades do equipo contribuidor.

• Como resultado, ábrense moitas incidencias duplicadas das que ten que dar conta o host team.

• Como o contexto das incidencias abertas é tan limitado, os/as contribuidores/as non poden axudar ao host team introducindo algunha das incidencias máis sinxelas que xa están abertas. Como resultado, queda moito traballo nas mans do host team.

• Co foco orientado principalmente na comunicación verbal, é imposible discernir despois dun par de meses ou anos por que se escolleu engadir unha determinada funcionalidade e non outra. Como resultado, as refactorizacións, en particular a simplificación do compoñente, convértense nun exercicio de arqueoloxía do proxecto, así como de selección memorística, co fin de recordar o que se acordou.

Solución

Adopte a filosofía «o escrito prevalece sobre a palabra», non só para o desenvolvemento de software puro, senón tamén durante a fase de planificación de novas funcionalidades:

• Para erros, funcionalidades planificadas e ideas de funcionalidades, cómpre crear incidencias separadas. En cada unha delas inclúa a maior cantidade de información posible para que os/as potenciais contribuidores/as externos/as poidan comprender o contexto. Idealmente, e en concreto para os cambios máis doados, inclúa información suficiente para que os/as colaboradores/as externos/as poidan prestar soporte ao host team cando introduzan a funcionalidade en cuestión.

• Empregue o sistema de seguimento de incidencias como canle potencial para facer preguntas. Isto é especialmente útil cando se carece doutras fontes de comunicación para resolver as preguntas dos/as usuarios/as.

• Faga uso de etiquetas e categorías para distinguir cuestións utilizadas para diferentes fins.

• Para comezar unha sesión de intercambio de ideas de forma asíncrona, abra unha incidencia para a recollida de ideas. Cando a discusión comece a calmarse, resuma os puntos identificados neste número nun documento separado. Publíqueo para a súa revisión como unha pull request para profundizar en puntos individuais que aínda precisan certa aclaración. O documento resultante pódese utilizar para publicar os resultados noutras canles apropiadas, así como para futuras referencias.

• A maioría das introducións do sistema de seguimento de incidencias permiten obter prototipos das mesmas. Faga uso destes, non só para recoller a información que se necesita habitualmente para os informes de erros, senón tamén para incluír suxestións sobre que tipo de información é necesaria para os outros tipos de uso.

Contexto resultante

• Facer un maior uso do sistema de seguimento de incidencias do proxecto para a comunicación permite que os/as contribuidores/as externos/as se deixen guiar e tomen mellores decisións no concernente ás contribucións.

• Un enfoque na comunicación escrita estruturada permite que os membros do equipo de acollida participen de xeito remoto.

• Comunicarse de forma consistente por escrito significa que a documentación pasiva sobre as decisións do proxecto acumúlase como un subproduto en lugar de necesitar atención adicional.

• O uso constante das canles de comunicación públicas fai que cada vez máis persoas poidan seguir a discusión. Isto supón máis xente informada con capacidade para dar resposta ás preguntas, falar de incidencias abertas ou sinalar defectos nas funcionalidades planificadas que, doutro xeito, só se atoparían moito máis tarde.

• Trasladar as discusións a un medio de debate público crea unha oportunidade para que os/as posibles contribuidores/as futuros/as lean, sigan, se sintan cómodos/as e coñezan as vías do proxecto moito antes de formar parte del.

Exemplos coñecidos

• Europace AG – Vexa Issue Use Cases [incidencias de casos de uso]

Autoría

• Isabel Drost-Fromm

Estado

• Estruturado

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Comece como un experimento

Patlet

comece a súa iniciativa InnerSource como un experimento de tempo limitado para facilitar que o persoal directivo, que non estea familiarizado con InnerSource, secunde e apoie a iniciativa.

Problema

A empresa considera adoptar unha iniciativa InnerSource pero non se pon en marcha porque a dirección non está segura do seu resultado e, polo tanto, non está disposta a comprometerse cun investimento.

Contexto

A empresa está a considerar a aplicación de InnerSource para aumentar a eficiencia da colaboración nos proxectos de software. Porén, a maioría do persoal directivo non está familiarizado co modelo de traballo do sistema de software libre e, en cambio, están acostumados a unha xestión xerárquica de arriba cara abaixo. A iniciativa InnerSource é moi popular entre os/as desenvolvedores/as de software da empresa, sobre todo porque moitos/as deles/as xa a están a empregar ou porque están a desenvolver de maneira activa o software libre.

Aspectos que mellorar

• A dirección procurará verificar as afirmacións arredor das melloras na colaboración mediante InnerSource antes de realizar un investimento a longo prazo. Isto, xeralmente, implica medir as melloras.

• No caso de que sexa probable que a iniciativa InnerSource teña unha grande aceptación entre os/as desenvolvedores/as e que moitos proxectos dependan dela, a decisión de eliminala tería mala acollida e, polo tanto, sería unha decisión difícil de tomar. A percepción de perda de control resultante podería disuadir algún/algunha directivo/a de tan sequera comezar a implantar InnerSource.

• A implantación de modelos de traballo ao estilo InnerSource adoita supor un cambio radical con respecto aos modelos de traballo que se empregaban anteriormente. Polo tanto, é probable que os procesos obrigatorios existentes xa non sexan aplicables e que os procesos de goberno tampouco sexan apropiados. O resultado podería ser que a empresa teña que operar cun regulamento que se atope en terra de ninguén desde o punto de vista xurídico. Como, por exemplo, no caso das regulacións relacionadas co control de taxas e exportacións en grandes corporacións con múltiples entidades xurídicas en múltiples países.

Solución

Declare a iniciativa InnerSource como un experimento cun tempo limitado. Defina e comunique os criterios para que os proxectos se sumen ao experimento InnerSource. Seleccione aqueles criterios que maximicen as posibilidades de construír unha comunidade saudable. Resulta positivo seleccionar unha serie deles cando os coñecementos xerados a partir destes criterios, no contexto do experimento, se poden aplicar intuitivamente a contextos que involucren a outros posibles proxectos InnerSource.

Exemplos de tales criterios son:

• Axeitada distribución xeográfica dos/das desenvolvedores/as.

• Axeitada mestura de departamentos nos que se atopan os/as desenvolvedores/as.

• Apertura da comunicación na comunidade.

• Traxectoria profesional baseada nos méritos acadados nesa comunidade.

• Toma de decisións democrática na comunidade.

Considere a posibilidade de designar o final do experimento como o punto a partir do cal facer un cambio ou pausa para a reavaliación. Considere tamén establecer un comité de revisión para aumentar as probabilidades de que a dirección se implique a través da participación. Dependendo da cultura da empresa, podería ser útil acompañar o experimento con métricas axeitadas como en Primeiros pasos coas métricas. Se os proxectos no experimento non brindan un impacto directo nos ingresos da empresa, considere presentalos a unha avaliación entre equipos e para resaltar as súas contribucións de valor.

Contexto resultante

O persoal directivo pode pór en marcha InnerSource polas seguintes razóns:

• A configuración de carácter experimental alivia a necesidade de que o persoal directivo escudriñe os números do programa InnerSource do mesmo xeito que o farían cos proxectos habituais.

• Enténdese e acéptase a posibilidade de que o experimento fracase. Por outra banda, o risco persoal para os/as directivos/as de apoio minimízase.

• Incluso no caso de fracasar, a configuración garante que a empresa aprenderá do experimento.

• En caso de éxito, os datos recollidos durante o experimento permitirán que o persoal directivo se comprometa a longo prazo con InnerSource.

As persoas participantes no experimento InnerSource son agora conscientes de que teñen que demostrarlle ao persoal directivo que InnerSource produce os beneficios prometidos. Polo tanto, será útil centrar o traballo naquelas actividades que acheguen un valor máis demostrable, aumentando así as posibilidades de éxito.

Finalmente, comezar cunha práctica a modo experimento, fai que sexa moito máis fácil eludir as normativas e os impedimentos tales como as políticas de ferramentas e os procesos, que poderían diminuír as posibilidades de éxito.

Modelos relacionados

• «Trial Run» (do libro Fearless Change)

Exemplos coñecidos

• Robert Bosch GmbH (desenvolvemento de software distribuído globalmente)

Estado

• Estruturado

Autoría

• Georg Grütter (Robert Bosch GmbH)

Recoñecementos

• Jason Zink (Robert Bosch GmbH)

• Diogo Fregonese (Robert Bosch GmbH)

• Robert Hansel (Robert Bosch GmbH)

• Hans Malte Kern (Robert Bosch GmbH)

• Russ Rutledge (Nike)

• Tim Yao (Nokia)

• Clint Caín (Optum)

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Comité de revisión

Patlet

o modelo de traballo InnerSource é un afastamento radical dos enfoques máis tradicionais, tanto para os/as desenvolvedores/as como para os/as seus/súas superiores/as. Ao establecer un comité de revisión como interface entre a iniciativa InnerSource e todos os altos cargos das áreas empresariais que participan nela, é máis probable que estes últimos se familiaricen coa iniciativa e a apoien; xa que lles brinda un certo nivel de supervisión e control, sen fomentar a microxestión.

Problema

Os altos cargos percibirán o modelo de traballo de InnerSource como un afastamento radical dos modelos de traballo aos que están afeitos e cos que teñen experiencia. Como consecuencia, é probable que rexeiten ou microxestionen a iniciativa InnerSource para tratar de minimizar o risco percibido deste cambio. En ambos os dous casos, os beneficios de InnerSource non se poderían alcanzar. E, como resultado, InnerSource sería logo desacreditado.

Contexto

A empresa A quere presentar a súa primeira iniciativa InnerSource. A meirande parte dos cargos superiores da empresa A non están familiarizados co modelo de traballo de software libre e, en cambio, están afeitos á xestión de estilos de control xerárquico e descendente.

Aspectos que mellorar

• Canto máis control perciba un/unha directivo/a sobre o traballo na iniciativa InnerSource, máis probable é que apoie a iniciativa sen contar con experiencia previa.

• Canta menos experiencia teña un/unha xestor/a co modelo de traballo de software libre, máis probable é que queira controlar o risco da iniciativa.

• Canto máis draconiana e microxestionada sexa a dirección das iniciativas InnerSource, menos probable é que se adopte o modelo de traballo de software libre na medida necesaria. E, como resultado, os beneficios de InnerSource non se poderán acadar.

Solución

• Establecer un comité de revisión composto por altos/as directivos/as de tódalas áreas empresariais que participan na iniciativa InnerSource.

• Os membros do Comité de revisión teñen a autoridade de decidir grupalmente, e en xeral, que proxectos InnerSource recibirán asistencia; así como cales en particular contarán con financiamento.

• Os/As candidatos/as poden ser elixidos/as con anterioridade polos membros do Comité de revisión para presentar a súa proposta de proxecto InnerSource, para a súa consideración durante as reunións do devandito Comité.

• Os/As líderes dos proxectos InnerSource, financiados actualmente polo Comité de revisión, están obrigados/as a informar sobre o estado do seu proxecto durante cada xuntanza do comité.

• Os membros do Comité de revisión están obrigados a proporcionar retroalimentación tanto ás novas persoas candidatas/solicitantes como aos/ás líderes actuais do proxecto durante as reunións do comité.

• Cada proxecto de InnerSource debe ter a oportunidade de reaccionar ás valoracións recibidas nunha sesión do Comité de revisión, no espazo de tempo que reste ata a sesión seguinte, para evitar o peche prematuro do proxecto.

• Un/Unha líder de proxecto InnerSource tamén pode presentar unha moción de cese por iniciativa propia no Comité de revisión. A continuación, o Comité de revisión ten que decidir se ás áreas empresariais que empregan o software se lles debe dar tempo ou non para poñer en marcha medidas para garantir que o desenvolvemento e/ou o mantemento da base de código continúe ata que se atope unha solución alternativa ao desenvolvemento por parte da comunidade InnerSource. (Se é relevante para o negocio ou é unha misión crítica).

• O Comité de revisión debería reunirse regularmente. Xa se probou que unha cadencia de dúas reunións ao ano resulta exitosa.

Contexto resultante

• Os/As directivos/as empregan con InnerSource unha ferramenta coa que se senten cómodos/as, co fin de obter a cantidade necesaria de información e control sobre o funcionamento interno da iniciativa. Esta familiaridade fará que teñan máis probabilidades de asinar a iniciativa InnerSource e poder conceder o grao de liberdade necesario para os proxectos de InnerSource.

• Os/As desenvolvedores/as aínda poden autoorganizarse ata certo punto. Non hai lugar para a microxestión, xa que o Comité de revisión non se convoca con demasiada frecuencia.

Exemplos coñecidos

• BIOS en Robert Bosch GmbH

Estado

• Estruturado

• Finalizado e revisado na data: 31/8/17

Autoría

• Georg Grütter, Robert Bosch GmbH

• Diogo Fregonese, Robert Bosch GmbH

Título alternativo

Cheese Interface

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Contracted contributor

Patlet

os/as socios/as que desexen contribuír a InnerSource son disuadidos/as de facelo polos/as seus/súas superiores/as. Os contratos e acordos formais son un alivio.

Problema

Sen o apoio dos/as responsables de área, é probable que o número total de contribuidores/as e, en consecuencia, a cantidade de contribucións realizadas, así como o calidade xerada pola iniciativa InnerSource, sexa inferior á das expectativas dos altos cargos. Probablemente esta situación se vexa agravada se non se financia adecuadamente aos/ás líderes da comunidade expertos/as en InnerSource e se lles capacita correctamente. Córrese o risco de que a dirección decida non seguir adiante coa inicitiva InnerSource.

Contexto

Unha gran corporación puxo en marcha unha iniciativa InnerSource. Os principais obxectivos da iniciativa son aumentar a eficiencia do desenvolvemento do software distribuído e fomentar a innovación permitindo que tódolos/as traballadores/as contribúan voluntariamente nos proxectos InnerSource, independentemente do tema e da unidade de negocio.

Os altos cargos apoian a iniciativa InnerSource. Para eles/as, é só unha das moitas iniciativas para fomentar a innovación e a eficacia. Financian InnerSource con diñeiro e capacitación para os/as líderes da comunidade, ademais de dotalos/as de autonomía para o gasto do presuposto. Tamén limitan a amplitude e a duración da iniciativa e participan en revisións periódicas ata que haxa probas de que da os resultados esperados (vexa Comité de revisión). Os/As directivos/as anunciaron o seu apoio á iniciativa InnerSource en varias reunións internas de empresa.

Con todo, aínda non capacitaron ou incentivaron aos/ás responsables de área para que permitan, ou incluso motiven, aos/ás seus/súas traballadores/as a participar en actividades InnerSource interdivisionais. Ademais, a capacidade de cada socio/a adoita asignarse a proxectos alleos a InnerSource durante toda a súa xornada de traballo. A colaboración entre organizacións aínda non é a norma e os cargos superiores non adoitan ter obxectivos fóra da súa propia compañía. Espérase que as contribucións aos proxectos InnerSource teñan lugar durante o horario laboral, non durante o tempo libre.

Aspectos que mellorar

• O persoal directivo é responsable dos resultados das súas unidades de negocio. Permitir que o seu persoal participe en actividades InnerSource nas que poderían perder tempo facendo contribucións fóra da súa área empresarial, reduce eficazmente a capacidade da súa unidade. É probable que isto dificulte que o persoal directivo alcance ou supere os seus obxectivos.

• Os/As responsables de área e RR HH xulgarán, por defecto, o rendemento dos/as seus/súas subordinados/as en función dos obxectivos das súas unidades de negocio, que poderían non estar aliñados cos obxectivos da comunidade InnerSource.

• Canto menor sexa o apoio executivo percibido polo/a superior/a inmediato/a, menos probable será que permita que o seu persoal participe en actividades InnerSource que contribúan a outra unidade de negocio.

• Canta menor transparencia e control teña o/a superior/a do traballo realizado por un/unha dos/das seus/súas subordinados/as, menos probable será que lles permita facer contribucións.

• Canto menos formal sexa a xestión e organización do traballo en InnerSource, menos probable será que un cargo superior acostumado aos procesos oficiais autorice a un/unha dos/as seus/súas traballadores/as a contribuír en InnerSource.

• Canto máis tempo dedique un/unha socio/a a contribuír a un proxecto InnerSource que non beneficie ao seu propio traballo diario, máis aumentará a carga de traballo para os/as seus/súas compañeiros/as de equipo na súa unidade de negocio.

• É probable que os/as contribuidores/as individuais consideren participar en InnerSource para ter a oportunidade de mellorar a súa rede profesional dentro da empresa e adquirir coñecementos e experiencia na área técnica das súas contribucións.

Solución

Estableza un sistema de contratación formal entre o/a contribuidor/a, o/a seu/súa superior/a e unha oficina de gobernación InnerSource (ISGO), financiada e dirixida de maneira centralizada. Faga que a ISGO reembolse ás unidades de negocio que contrataron a contribuidores/as polo tempo contratado.

• A contratación especifica unha porcentaxe máxima de tempo de traballo dos/as socios/as en InnerSource.

• A contratación establece, claramente, que o traballo na unidade de negocio do/a contribuidor/a ten prioridade sobre o traballo en InnerSource.

• A contratación establece que non é obrigatorio traballar en InnerSource durante a porcentaxe máxima especificada no contrato.

• A contratación está firmada polo/a contribuidor/a, o/a seu/súa superior/a inmediato/a, a oficina de gobernación e o/a líder da comunidade experto/a en InnerSource coa que vaia colaborar o/a contribuidor/a.

• A oficina de gobernación ofrécese a mediar entre o/a contribuidor/a e o/a seu/súa superior/a en caso de conflito acerca do horario das contribucións.

• O/A líder da comunidade experto/a en InnerSource participa nas revisións do rendemento dos/as contribuidores/as contratados/as por máis dun 20% ou realiza aportacións ás mesmas.

Contexto resultante

A contratación formal e os reembolsos financiados de xeito centralizado comunican de forma convincente o apoio da organización á iniciativa InnerSource, capacitando así aos mandos intermedios para que aproben a devandita iniciativa:

• A asignación dos fondos corporativos das unidades de negocio para o reembolso da capacidade de desenvolvemento indícalles aos/ás responsables de área que InnerSource aporta valor á organización, que conta con apoio executivo e que se espera que tamén eles/as a apoien.

• A contratación formal indica que o traballo mediante InnerSource se xestiona de xeito profesional e inspira confianza.

• Unha contratación formal aumenta a transparencia e proporciona unha mellor visión de conxunto sobre a capacidade dispoñible do/a socio/a para a súa unidade de negocio e sobre os seus proxectos InnerSource, reducindo así o risco de planificar en exceso a capacidade de produción.

A contratación formal tamén é beneficiosa para os/as contribuidores/as e as comunidades:

• Cun grupo estable de contribuidores/as, é moito máis probable que algúns/algunhas deles/as rematen acadando o status de Trusted committer

• Unha contratación formal proporciona un marco para resolver conflitos vencellados á participación nas actividades InnerSource. Teña en conta que probablemente a mediación só sexa frutífera para as compañías que teñan unha cultura que o propicie.

Exemplos coñecidos

• BIOS na empresa Robert Bosch GmbH

Estado

• Estruturado

Autoría

• Georg Grütter (Robert Bosch GmbH)

Recoñecementos

• Diogo Fregonese (Robert Bosch GmbH)

• Robert Hansel (Robert Bosch GmbH)

• Jim Jagielski

• Tim Yao

• Klaas-Jan Stol

• Padma Sudarsan

• Nick Stahl

• Ofer Hermoni

• Robert C. Hanmer

Rexistro de cambios

• 2016-10-25: Primeira revisión

• 2017-05-09: Reelaboración

• 2017-09-08: Segunda revisión, reelaboración final e unificación

• 2021-02-27: Solución de cuestións coa visualización do modelo do libro

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Documentación base estándar

Patlet

ós/ás novos/as contribuidores/as dun proxecto InnerSource teñen dificultades para determinar quen mantén o proxecto, en que traballar e como contribuír. Ao proporcionar documentación en arquivos estándar como README.md/CONTRIBUTING.md permítese un proceso de autoservizo para os/as novos/as contribuidores/as, de xeito que poidan atopar por si mesmos/as as respostas ás preguntas máis comúns.

Problema

O equipo quere compartir un proxecto iniciado recentemente ou preexistente co resto da empresa e que ese proxecto reciba contribucións. A miúdo, os/as posibles contribuidores/as pérdense. Deste xeito, non conseguen identificar cales son as canles de comunicación predilectas do equipo. Tamén teñen problemas para xulgar con rapidez se ten sentido poñer en marcha unha nova funcionalidade ou non. Por outra banda, resúltalles difícil comprender que compañeiros/as en particular están a manter de xeito activo o proxecto nese momento.

Contexto

O proxecto debe compartirse con outros/as contribuidores/as como proxecto InnerSource. Para que outros/as poidan comprender de que trata o proxecto e como contribuír a el, este debe proporcionar certa documentación básica. Polo de agora, o proxecto carece da documentación ou dalgúns aspectos necesarios para que os/as usuarios/as poidan probalo en modo autoservicio, así como para que os/as contribuidores/as se actualicen rapidamente.

Aspectos que mellorar

• O proxecto converteuse nun proxecto InnerSource fai pouco. Antes, os/as usuarios/as eran só internos/as ou incorporábanse en sesións presenciais cara a cara. Do mesmo xeito, as persoas que traballaban no proxecto asistían a sesións presenciais de incorporación que non se adaptaban ao crecente número de contribuidores/as ou ás situacións daqueles/as que colaboraban en remoto. Como resultado, existe unha falta de documentación de autoservicio.

• O proxecto creouse como unha iniciativa InnerSource fai pouco. Con todo, o equipo anfitrión carece da experiencia con InnerSource. Como consecuencia, este necesita orientación para saber que información incluír na súa documentación, onde colocar esa documentación do código para que outros/as poidan atopala, ademais de entender como dirixirse ás persoas que despois van a ler esa documentación de código.

• O proxecto converteuse nun proxecto InnerSource recentemente, o equipo anfitrión ten experiencia limitada con InnerSource. Como resultado, a documentación de código existente aborda moitos aspectos técnicos. Así a todo, non se aborda a comunicación, a coordinación ou a información necesaria para facilitar unha planificación transparente.

• O proxecto converteuse nun proxecto InnerSource recentemente. Como resultado, a meirande parte do coñecemento implícito que existe dentro do equipo non está escrito, polo que non é visible para os/as contribuidores/as.

• A falta de documentación de código fai que os/as posibles contribuíntes tarden moito tempo en distribuírse e comezar. Elaborar documentación de código (e mantela actualizada) require un investimento de tempo. Incluso se o equipo anfitrión confía nos/nas contribuidores/as para que o axuden coa documentación de código que falta, esta aínda precisa dun tempo para revisarse.

• Os membros do proxecto pasan moito tempo respondendo a preguntas con respecto á posta en marcha do devandito proxecto. Porén, manter unha base de datos exhaustiva cunha especie de preguntas de asistencia, require moito tempo e esforzo.

• Os distintos equipos da empresa teñen estándares diverxentes respecto a como formatar o código fonte e que modelos de software empregar. Por conseguinte, a miúdo a maior parte de contribucións teñen que reescribirse ata incluso na súa totalidade. Estandarizar estes aspectos e facer que se cumpra a norma adoita requirir de moito tempo e traballo.

• O traballo adicional resultado das explicacións repetidas e as reescrituras diminúe a utilidade do enfoque InnerSource.

• As escaladas frecuentes por mor do traballo adicional e dos atrasos son o resultado das reescrituras de código e, estas, conducen a unha situación que require a intervención dun/dunha especialista.

Solución

Abordar a necesidade de establecer unha documentación de código máis clara para os/as novos/as contribuidores/as. O obxectivo á hora de crear esta documentación de código debería ser que a posta en marcha sexa un proceso de autoservizo na medida do posible, que dea resposta ás preguntas máis frecuentes nun formato de documentación estándar.

README.md

Se aínda non o fixo, cree un arquivo README.md para o seu proxecto que conteña:

• Unha sección de «Comezo» para os/as usuarios/as intermedios/as do proxecto. Esta sección debe explicar como configurar/integrar os dispositivos do proxecto, así como tamén ha de incluír unha explicación dalgúns dos primeiros pasos habituais para os/as usuarios/as recentemente incorporados/as.

• Documentación máis detallada para os/as usuarios/as do proxecto ou unha ligazón a ela.

• Documentación necesaria para realizar modificacións no proxecto ou unha ligazón a ela.

• Documentación sobre como contribuír ao proxecto ou unha ligazón á mesma.

• Unha sección de «Comezo» que explique que canles de comunicación públicas, arquivadas e asociadas se empregan no proxecto. Isto debe incluír unha ligazón ao sistema de seguimento de incidencias do proxecto, pero tamén a calquera outro medio de discusión utilizado.

• Unha explicación que expoña os criterios do proxecto polos que os/as contribuidores/as pasan a ser trusted committers, no caso de que exista esa posibilidade.

CONTRIBUTING.md

Se a guía dos pasos para facer unha contribución é demasiado complicada, cree un documento CONTRIBUTING.md por separado. Este documento debe responder ás preguntas máis frecuentes que outros/as contribuidores/as fixeron no pasado. Non hai necesidade de proporcionarlles un libro detallado con antelación. Máis ben, comparta a información que sexa indispensable para os/as contribuidores/as. É probable que esta información aborde un ou máis dos seguintes temas:

• Como verificar o código fonte do proxecto desde o control de versións.

• Como facer as modificacións no proxecto (que posiblemente inclúa información sobre as pautas de codificación).

• Como construír o proxecto.

• Como executar probas para asegurarse de que as modificacións anteriores non engaden novos bugs.

• Como enviar as súas modificacións ao proxecto.

• Información sobre o tempo total necesario para que se fagan as modificacións.

Contexto resultante

• O tempo que tardan os/as contribuidores/as en poñerse ao día redúcese de xeito significativo.

• As escaladas por mor de malentendidos e discordancias redúcense de xeito significativo.

Exemplos coñecidos

• Paypal inc.

• Mercado Libre: cree un sitio de documentación que conteña instrucións para iniciarse en InnerSource e tamén defina os elementos básicos que debe ter un repositorio para poder ser considerado InnerSource (README, CONTRIBUTING, CODING_GUIDELINES etc.).

Autoría

• Isabel Drost-Fromm

Título alternativo

Proporcionar documentación base estándar a través dun README

Estado

• Estruturado

• Redactado en decembro de 2019

Referencias

Créditos

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Extensións para o crecemento sostible

Patlet

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.

Problema

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?

Historia

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.

Contexto

• 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.

Aspectos que mellorar

• 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.

Solucións

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:

1. 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.

     • 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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:

• 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.

Contexto resultante

• 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.

Exemplos coñecidos

Título alternativo

Extensións para xestionar contribucións a escala

Estado

• Estruturado

Autoría

• Sukriti Sharma, IBM

• Alexander Brooks, IBM

• Gabe Goodhart, IBM

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Core team

Patlet

incluso cando se necesita moito un proxecto InnerSource, as colaboracións e o seu uso poden verse obstaculizados porque é difícil traballar co proxecto. Estableza un core team que se dedique a coidar dos elementos fundamentais do proxecto. O traballo do core team permítelle aos/ás contribuidores/as engadir e empregar as funcionalidades que achegan valor aos seus escenarios.

Problema

• É difícil contribuír ao proxecto. Isto podería deberse a aspectos como:

  • Non se pode executar o proxecto de maneira local.

  • Documentación deficiente.

  • Código intrincado.

  • Probas inadecuadas.

• É difícil usar o proxecto. Algunhas causas posibles son:

  • Documentación deficiente (unha vez máis).

  • Erros frecuentes.

  • Configuración pouco intuitiva.

Historia

Hai un proxecto central do que todos/as dependen. Gran candidato para InnerSource! Desafortunadamente, o proxecto creceu de maneira orgánica e con varias contribucións e adicións fortuítas. Agora trátase dunha maraña de código desordenado e denso que ninguén entende e no que todo o mundo ten medo a somerxerse. Está claro que necesita unha revisión (por exemplo, refactorización, probas, documentación etc.), pero aínda que todos/as necesitan e queren que se leve a cabo a tarefa, ninguén emprega tempo en facelo.

Contexto

• Moitos equipos necesitan o proxecto.

• O proxecto ten unha débeda tecnolóxica significativa.

• A adopción e iteración do proxecto é lenta.

• Non hai un/unha propietario/a ou encargado/a do mantemento que asuma a responsabilidade do proxecto e o ecosistema de contribución no seu conxunto.

Aspectos que mellorar

• Tódolos equipos contribuidores están ocupados e, por tanto, priorizan o traballo que supón unha recompensa inmediata para eles mesmos.

• A medida que o proxecto crece, a tendencia natural é que se volva máis difícil de empregar e modificar.

Solución

Forme un core team cuxo traballo sexa manter este proxecto nun estado no que outros/as poidan incorporarse e contribuír facilmente. Este equipo leva a cabo o traballo necesario para crear un ecosistema saudable de uso e de contribución. Este traballo crítico a miúdo non se prioriza tanto como a contribución. As categorías deste tipo de traballo inclúen a comunicación, un entorno local e unha infraestrutura DevOps.

Velaquí algúns exemplos específicos:

• Erros de produción.

• Documentación.

• Titorial de incorporación e exemplos.

• CI/CD.

• Medio local.

• Modularización.

• Versión actualizada.

• Monitorización.

• Clases/categorías de funcionalidades pioneiras.

Cada un destes elementos é moi importante para un ecosistema de produtos saudable, pero é pouco probable que se lle dea tanta prioridade como á contribución.

O core team pode estar composto por un pequeno número de persoas a tempo completo ou parcial. A elección depende da cantidade de traballo necesario, a dispoñibilidade de recursos e a cultura da organización. A consideración máis importante é formar ao equipo de maneira que permita á organización capacitalos e responsabilizalos da mesma maneira que a outro equipo calquera.

Unha boa maneira de recordarlles constantemente ao equipo central este obxectivo é facer que estes proporcionen información regularmente sobre:

• O número de equipos activos que emprega o proxecto.

• O número de contribucións externas ao equipo.

Centrarse de xeito continuo nestas métricas, naturalmente, impulsará ao core team a priorizar, en xeral, o traballo axeitado co fin de crear un ecosistema InnerSource próspero arredor do proxecto.

Contexto resultante

• É doado de empregar e contribuír ao proxecto.

• Moitos equipos empregan e contribúen ao proxecto.

• O éxito do core team defínese nos termos da interacción dos/as demais e a resposta ao seu proxecto.

Fundamento

Separar a un core team e asignarlle tarefas axuda a encher os baleiros que necesita un proxecto frutífero e que, porén, exclúe aos/ás contribuíntes que só se preocupan dos seus propios obxectivos. O core team enche eses baleiros e engraxa as rodas para que o ecosistema de contribución se manteña saudable.

Exemplos coñecidos

• Nike aplicou este modelo para xestionar o esforzo InnerSource arredor das súas planificacións non reutilizables de CI/CD.

Estado

• Estruturado

Autoría

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Licenza InnerSource

Patlet

dúas entidades xurídicas que pertencen á mesma organización queren compartir o código fonte do software entre elas, mais preocúpanlles as implicacións en termos de responsabilidades legais ou de contabilidade entre as empresas.

Unha licenza InnerSource proporciona un marco legal reutilizable para compartir o código fonte dentro da organización. Isto abre novas opcións de colaboración e fai explícitos os dereitos e as obrigas das persoas xurídicas implicadas.

Problema

Cando dúas ou máis entidades xurídicas dentro dunha organización queren compartir código entre elas, necesitan un acordo sobre os termos e moitas veces un contrato legal. Crear tales acordos con base no proxecto require esforzo e xera unha barreira para compartir; isto é, un equipo dunha entidade xurídica pode decidir non compartir o seu código fonte con outra entidade xurídica da organización por parecer complicado.

As barreiras para compartir poden levar a silos e duplicación de esforzos na reconstrución de solucións similares en varias partes da organización.

No momento de compartir o código fonte, non se pode prever de forma fiable cal será o valor de compartir. Se a actividade compartida require un esforzo significativo (por exemplo, negociar os termos para o uso), as persoas xurídicas teñen menos probabilidades de facelo, xa que están preocupadas polo retorno do investimento.

Contexto

• Cando unha grande organización con moitas entidades xurídicas (filiais) crece, o valor do modelo en que estas queren compartir código aumenta.

• Por definición, as entidades xurídicas teñen os seus propios dereitos e obrigas legais.

• Varias destas entidades xurídicas están a desenvolver software e empregan os servizos doutras entidades xurídicas. De xeito que existe unha motivación para contribuír ao código fonte do/da outro/a.

• Suficiente complexidade da organización e da súa estrutura.

Aspectos que mellorar

• Nivel de esforzo. Necesario para redactar acordos formais, especialmente se teñen que ter en conta perspectivas técnicas, legais e empresariais.

• Regulacións internas. Unha organización grande (formada por moitas entidades xurídicas) ten moitas regulacións internas. Calquera acordo novo terá que cumprir as normativas de, por exemplo, seguridade, privacidade, procesos de contratación etc. O volume das regulacións pode dificultar a valoración de se o uso compartido de software entre dúas entidades xurídicas cumpre coa normativa, especialmente cando non existe un procedemento normalizado.

• Modelo de negocio. Deberase discernir se algunha das entidades xurídicas da organización ten un modelo de negocio que depende do código propietario e da contabilidade dos custos de licenza dentro da organización.

• Cultura da empresa. Non acostuma a colaborar e compartir código de InnerSource. Isto provoca incerteza sobre os dereitos e as obrigas cando se emprega código compartido.

• A liberdade de usar o software leva á competencia e á difusión da propiedade.

• Existen contratos legais para cubrir o feito de compartir o código fonte. Estes contratos non están estandarizados, polo que crean un esforzo adicional na negociación e comprensión de cada proxecto. Os contratos existentes tamén poderían non permitir compartir o código fonte nun sentido o suficientemente aberto como para apoiar un verdadeiro enfoque InnerSource.

• Alternativamente, non hai contratos legais en vigor, pero o código fonte compártese de forma informal. Isto pode xerar incerteza nos casos en que se precisa claridade sobre a propiedade e os dereitos e obrigas.

Solucións

Creación dunha licenza InnerSource personalizada ás necesidades da organización en cuestión (e das súas entidades xurídicas). Esta licenza terá que ser o suficientemente xenérica como para poderse aplicar ás relacións entre empresas máis importantes.

É necesario escribir a licenza InnerSource de xeito que permita as colaboracións reais de tipo software libre entre os límites das entidades xurídicas implicadas. Polo tanto, as catro liberdades do software libre deberían estar integradas na licenza.

A licenza está escrita como un documento legal formal e pódese utilizar como parte dos contratos entre as entidades xurídicas para rexer os acordos polos que se comparten os códigos.

Contexto resultante

Coa licenza InnerSource temos unha ferramenta para compartir código entre entidades xurídicas dentro da nosa organización.

A licenza simplifica as conversas dentro da organización sobre o feito de compartir o código fonte, e xa está a motivar as primeiras entidades xurídicas a facelo.

Nota: o experimento descrito nos Exemplos coñecidos atópase nunha fase inicial. Polo tanto, aínda non se formou un Contexto resultante firme. Nun par de meses, con efectos máis claros da licenza InnerSource neste espazo problemático, poderase actualizar.

Exemplos coñecidos

As primeiras entidades xurídicas (empresas) dentro da DB AG están a usar a súa licenza InnerSource.

Un efecto positivo e visible é que simplifica a conversación, especialmente se algunhas das partes implicadas aínda non coñecen ben InnerSource. As licenzas son un concepto moi coñecido, polo que ter unha licenza InnerSource é un grande inicio de discusión.

Os experimentos tamén están a descubrir outros retos de colaboración que deben resolverse para chegar a un verdadeiro modelo de colaboración e contribución InnerSource.

Os retos de colaboración mencionados inclúen:

• Facer que os proxectos con licenza InnerSource sexan detectables.

• Crear comunidades para a colaboración en proxectos, como no software libre.

Paga a pena mencionar que, ata agora, o software compartido baixo esta licenza InnerSource consiste principalmente en empregar unha serie de ferramentas e infraestruturas.

Estado

• Estruturado.

• O experimento que aparece en Exemplos coñecidos está en execución desde 02/2020. A experiencia inicial mostra os primeiros efectos positivos, pero necesítase máis experiencia para avaliar completamente o modelo.

Autoría

• Cornelius Schumacher (DB Systel GmbH)

• Schlomo Schapiro (DB Systel GmbH)

• Sebastian Spier

Referencias

Glosario

• Organización: un paraugas para varias entidades xurídicas. (Sinónimos: grupo, empresa. Por exemplo, Lufthansa.).

• Entidade xurídica: unha entidade que ten os seus propios dereitos e obrigas legais. (Sinónimos: empresa, filial. Por exemplo, Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH etc).

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Ferramentas de comunicación

Patlet

os/as usuarios/as dun proxecto InnerSource teñen problemas para obter axuda e poñerse en contacto co host team. Mediante o uso sistemático de ferramentas de comunicación asíncrona, os debates serán visibles e permanecerán arquivados e accesibles; o que se traduce nunha mellora do nivel de asistencia aos/ás usuarios/as.

Problema

Un equipo está aberto a recibir contribucións de usuarios/as intermedios/as do seu compoñente. A coordinación e a comunicación prodúcense de maneira ad hoc, o que causa que se comparta información incoherente, que se reciban respostas con atraso ou que os/as contribuidores/as fagan ping a varios membros do host team antes de recibir unha resposta definitiva.

Contexto

• Hai un equipo dependente do compoñente do outro equipo.

• Hai un equipo ao que lle gustaría facer contribucións a ese compoñente.

• Incluso cando isto ocorre por escrito, a comunicación ten lugar de maneira individual.

Aspectos que mellorar

• O equipo anfitrión está interesado en recibir contribucións e disposto a asesorar aos/ás contribuidores/as.

• Os equipos teñen unha cultura sólida baseada na comunicación verbal e non teñen experiencia na configuración de canles de comunicación asíncrona específicas do proxecto.

• As canles de comunicación poden estar aliñadas cos grupos específicos aos que se debe chegar, pero non por un propósito comunicativo.

Solución

O host team debe proporcionar canles de comunicación públicas, arquivadas, con capacidade de busca e vinculables ás que poida subscribirse calquera persoa da empresa; posto que o apoio ás canles abertas de comunicación escrita aporta beneficios medibles.

O obxectivo ao optimizar as canles de comunicación para os proxectos InnerSource debe ser aliñar a comunicación arredor de temas, non arredor de certos grupos de persoas.

Un proxecto debe establecer as seguintes ferramentas de comunicación:

2. Canles conversacionais públicas cunha estrutura menos ríxida. Polo xeral, trátase de listaxes de correo, foros en liña, sistemas Q&A ou, incluso, canles de chat arquivadas. Normalmente, abonda con comezar cunha soa canle para o proxecto. Se o tráfico aumenta demasiado, é útil separar as conversacións sobre o uso do proxecto das outras acerca do desenvolvemento do proxecto.

Mentres que a comunicación pode ter lugar fóra desas canles escritas, debería ser devolta ás canles asíncronas tanta información como sexa posible.

Os membros do host team necesitan facer o esforzo de dirixir as preguntas que reciban persoalmente (por exemplo, por medio do correo electrónico ou chats de mensaxería) de volta á comunicación nas canles oficiais.

Contexto resultante

Cando a comunicación é aberta, os/as demais poden seguir facilmente o progreso do proxecto e obter contribucións activas. O feito de que outros/as estean espreitando e poidan lelas reduce a barreira de participación e aumenta a probabilidade de recibir contribucións.

Se as preguntas se contestan en público, máis persoas poden aportar a súa opinión, o que conduce a ter unha visión xeral: Isto inclúe non só aos membros do host team, senón tamén aos/ás usuarios/as do proxecto.

Manter a comunicación en canles asíncronas permite que os/as participantes con horarios diferentes —xa sexa por mor das diferenzas horarias, por ter rutinas de traballo diferentes, diferentes calendarios de reunións ou rutinas de traballo en equipo— contribúan de xeito significativo ao proxecto.

Responder ás preguntas nesas canles significa que non só outros membros do equipo poden escoitar e proporcionar información adicional, senón que tamén outros/as usuarios/as que teñan a mesma pregunta poden consultar (e máis tarde atopar) a resposta; o que reduce a necesidade de repetir as explicacións.

Exemplos coñecidos

• Europace AG

• Paypal Inc.

• Mercado Libre

Autoría

• Isabel Drost-Fromm

Recoñecementos

• Sebastian Spier (nos visuais)

Status

• Estruturado

• Redactado en decembro de 2019

Créditos

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Documente os seus principios reitores

Patlet

a explicación habitual de InnerSource baseada en «aplicar as mellores prácticas de software libre dentro dunha organización» non funciona correctamente coas persoas que carecen de experiencia con software libre. Como solución, os principios InnerSource máis importantes documéntanse e publícanse de maneira aberta.

Problema

A organización está intentando despregar InnerSource a grande escala. A iniciativa comezou cos/coas entusiastas do software libre e,agora, o obxectivo agora é conseguir a adhesión de persoas que carecen de experiencia no software libre. Para ese público, o típico slogan de «aplicar as mellores prácticas de software libre» non basta para transmitir a mensaxe do que supón InnerSource, os problemas que se poden resolver ou as ferramentas que se poden empregar para resolvelos. Como resultado, a adopción de InnerSource na organización relentízase. Os equipos desenvolven ideas diverxentes sobre os obxectivos de InnerSource e a mellor forma de aplicalo, o que xera confusión cando os/as contribuidores/as comezan a cruzar os límites dos equipos.

Historia

Os primeiros experimentos levados a cabo nunha organización demostraron que as mellores prácticas de colaboración en software libre poden ser beneficiosas. O seguinte paso agora é trasladar a iniciativa aos equipos e persoal que carecen de formación en software libre. O obxectivo agora é comunicar claramente os obxectivos da iniciativa InnerSource, así como o camiño claro cara a consecución destes obxectivos.

Contexto

• O termo InnerSource estase a dar a coñecer entre os/as traballadores/as.

• A iniciativa xurdiu entre os/as entusiastas do software libre.

Aspectos que mellorar

• Os equipos teñen dificultades á hora de comunicar de xeito exacto cales son os aspectos fundamentais de InnerSource.

• Quen carece de experiencia en software libre non entende o que significa implantar as mellores prácticas do software libre na empresa.

• No día a día, os equipos que intentan seguir as mellores prácticas InnerSource teñen dificultades para decidir se o que están facendo se atopa aliñado cos valores xerais de InnerSource.

Solución

Quen impulsa a iniciativa InnerSource na organización debe axudar aos equipos e individuos que carecen dunha forte formación en software libre e, polo tanto, teñen unha comprensión menos intuitiva de InnerSource.

Débese proporcionar claridade aos equipos e individuos documentando estas dúas áreas:

1. Propósito: Por que quere adoptar InnerSource a organización?

2. Principios: Que principios InnerSource axudarán a abordar estes retos?

As seguintes seccións proporcionan máis detalles acerca destas áreas pensadas como posibles puntos de partida para documentalos para a súa organización.

Cal é o motivo polo que as organizacións queren adoptar InnerSource?

No pasado, InnerSource amosou a súa eficacia na resolución de problemas habituais das organizacións.

Con todo, que retos organizativos espera mellorar a súa organización cando emprega InnerSource?

Na contra de facer xeneralizacións, intente identificar exactamente as solucións que se axustan aos retos da súa organización, preferiblemente coas persoas afectadas polo cambio que desexa aplicar.

Algúns retos que outras empresas abordaron seguindo as mellores prácticas InnerSource son:

• Reducir o desenvolvemento de silos causados pola cultura da propiedade excesiva.

• Aumentar a velocidade da innovación reducindo o tempo dedicado a resolver problemas similares mediante o fomento da reutilización saudable do código.

• Aumentar a velocidade de desenvolvemento mediante unha mellor colaboración entre equipos

• Resolver as dependencias de proxecto/equipo máis aló da espera e das solucións provisionais, reducindo así os puntos de conxestión na enxeñaría.

• Aumentar a calidade.

• Aumentar a felicidade dos/as traballadores/as.

• Aumentar o éxito das novas contratacións.

• Crear documentación viable.

Que principios InnerSource axudarían a abordar estes retos?

Unha vez que os equipos entendan que problemas lles axudarían a resolver InnerSource, o seguinte paso é explicar que principios axudan a afrontar estes retos.

Baseándonos nos principios básicos do desenvolvemento de software libre, as seguintes directrices amosaron a súa eficacia:

(1) O código debe aloxarse de maneira transparente na organización.

O código fonte, a documentación e os datos relevantes para o desenvolvemento do proxecto deben estar dispoñibles e ser fáciles de atopar para calquera persoa da organización.

(2) As contribucións priman sobre as feature requests.

Tódalas partes interesadas no proxecto actúan como posibles contribuidores/as e son tratados/as e apoiados/as como tal. As contribucións seguen sendo suxestións na contra de requisitos. A coordinación previa axuda a evitar esforzos inútiles. Os proxectos proporcionan directrices para evitar friccións.

(3) Os erros son oportunidades para aprender.

Cando o traballo é visible para toda a organización, calquera erro será tamén visible para todos/as. Deste xeito, debe establecerse unha cultura na que os erros sexan oportunidades de aprendizaxe na contra de fracasos que deben ser evitados a toda costa.

(4) A comunicación escrita prima respecto da comunicación oral.

Para os proxectos que abarcan varios equipos, con posibles calendarios de reunións diverxentes, ten que ser posible colaborar de maneira asíncrona. O obxectivo dos proxectos InnerSource é recrutar a novos/as contribuidores/as. Para iso, os/as posibles futuros/as contribuidores/as deben poder seguir o progreso do proxecto de maneira autónoma con poucas barreiras de acceso. Se a comunicación relevante do proxecto se produce a través da comunicación asíncrona, os razoamentos que se debatan deben facerse transparentes na canle escrita; as decisións unicamente poden finalizar nesa canle. Como efecto secundario, isto conduce a unha documentación de pasivos base moi valiosa para calquera novo/a colaborador/a do proxecto.

(5) Permita que o asesoramento escrito se acumule nun arquivo accesible no que se poidan realizar buscas.

Toda a comunicación do proxecto, en particular as decisión tomadas e os debates que conduciron a esas decisións, deben ser arquivados. Debe ser posible facer referencia á comunicación a través de URL estables. As conversacións previas deben poder almacenarse de maneira que se poidan atopar facilmente.

Mais é necesario facer dúas advertencias:

1. Isto non substitúe a unha documentación estruturada. Con todo, pode servir como punto de partida para recompilar a documentación estruturada.

2. Existen excepcións á regra de que todo debe estar por escrito e ser accesible para toda a organización: as conversacións relacionadas cos/coas traballadores/as, así como coa seguridade, son confidenciais e non deben facerse públicas.

(6) Recompensa aos/ás trusted committers.

Contexto resultante

• Os membros da organización comprenden que retos poden abordar aplicando as mellores prácticas InnerSource.

• Os membros da organización que carecen de experiencia previa no software libre comprenden os valores e os principios básicos dos proxectos InnerSource.

• Os membros da organización que carecen de experiencia previa en software libre son capaces de contrastar a súa actividade diaria cun conxunto de valores comúns establecidos.

Exemplos coñecidos

• Europace AG

• Github

• Robert Bosch GmbH

Europace AG

GitHub

Finalidade

A miúdo en GitHub traballamos cun modelo no que os equipos aportan funcionalidades a áreas que están fóra do seu ámbito de competencia. Algúns exemplos comúns inclúen a enxeñaría de ventas que aporta funcionalidades para desbloquear unha venta, os proxectos especiais que contribúen cando é estritamente necesario, as funcionalidades de grande impacto en todo o produto e un equipo de traballo en múltiples áreas para entregar unha funcionalidade.

Principios

Polo xeral, os principios descritos neste documento son evitar o aumento da débeda tecnolóxica e a carga para o equipo propietario. A miúdo, préstase axuda a un equipo que quedou atrás por mor dos costes de soporte e mantemento na súa área de competencia e non ten ancho de banda para contribuír á funcionalidade. Calquera nova funcionalidade realizada por outro equipo que aumente a carga de soporte ou a débeda técnica supón aínda menos tempo para que o equipo propietario traballe nas novas funcionalidades, polo que queremos asegurarnos de que se fai ben.

Do mesmo xeito, esforzámonos por ser unha empresa na que os/as enxeñeiros/as traballen libremente máis aló das fronteiras e as prioridades empresariais que, a miúdo, esixen que contribuamos en áreas alleas ás nosas principais áreas de especialidade.

Un bo resumo dos principios é deixar a área en tan bo estado ou nun estado aínda mellor do que a atopou.

Tendo isto en conta, velaquí os principios nos que estamos de acordo:

• Evite os produtos menos viables (MVP, polas súas siglas en inglés, Produto-Viable-Mínimo) que acumulan débeda de funcionalidades. Está ben lanzar un MVP para obter retroalimentación dos/as clientes/as, pero o equipo que contribúe debe comprometerse a rematar o conxunto de funcionalidades. Algúns exemplos son:

  • Compromiso de ir máis aló do MVP para chegar a unha solución que satisfaga á maioría dos/as clientes/as.

  • Soporte completo para a administración das novas funcionalidades (por exemplo, soporte na interface de usuario/a (IU)).

  • Presentar as funcionalidades tanto na IU como na API (polas súas siglas en inglés, Interface de Programación de Aplicacións).

  • Garantir que as funcionalidades responden en ambientes de servidores locais e na nube.

• Apoie o traballo das funcionalidades ata o seu despregamento para a produción e tras esta.

  • Xestionar o despregamento progresivo.

  • Xestionar os tíckets de asistencia.

  • Planificar o tempo para responder aos comentarios dos/as clientes/as (funcionalidades e erros).

• Crear funcionalidades do xeito correcto (sen acumular débeda tecnolóxica).

  • Acordar os requisitos e a solución cos equipos de produto e de enxeñaría.

  • Arquitectura e deseño axeitados.

  • Asegúrese de que os datos se almacenan correctamente para evitar posteriores migracións de datos.

  • Implantar telemetría apropiada.

  • Soporte en ambientes de produción locais e na nube (incluídos a instalación, configuración e copia de seguridade/restauración, migracións etc.).

  • Erros reparados.

  • Documentación actualizada.

Compromiso

Empregamos un modelo de compromiso porque nos gusta establecer que pasos concretos pode dar un equipo cando contribúe con funcionalidades a áreas fóra do seu ámbito de responsabilidade.

Un modelo de compromiso típico de GitHub é o seguinte:

• Obter a aprobación do conxunto de características e do plan de despregamento do/a product owner.

• Obter a aprobación do deseño da enxeñaría, incluído o cumprimento dos requisitos non funcionais (telemetría, cobertura de probas, ensaios e asistencia multiambientais) do/a propietario/a de enxeñaría (normalmente o/a enxeñeiro/a xefe/a e o/a director/a).

• Facer revisións do código ao longo do proceso, así como revisión de requisitos novos ou modificados.

Robert Bosch GmbH

Finalidade

O principal obxectivo da iniciativa InnerSource de Bosch (BIOS) é fomentar a colaboración, a aprendizaxe e a innovación.

Principios

Para isto, Bosch aplica os seguintes principios:

• Apertura: Reducimos ao máximo as barreiras de entrada ás comunidades BIOS.

• Transparencia: Somos radicalmente transparentes, compartimos o traballo realizado e comunicámonos na toma de decisións tendo en conta a tódolos/as socios/as da empresa.

• Carácter voluntario: A decisión de unirse e contribuír a unha comunidade BIOS corresponde a cada socio/a. Os/As socios/as deben traballar na BIOS por mor da súa motivación intrínseca, non porque o persoal directivo llo pedise.

• Autodeterminación: As comunidades BIOS son libres de elixir en que traballar, cando traballar e que ferramentas e procesos empregar.

• Meritocracia: O poder conferido aos membros do proxecto BIOS vén dado en función dos seus méritos, é dicir, en función da calidade e da cantidade de contribucións.

Os principios de apertura, transparencia e carácter voluntario axudaron a crear comunidades diversas de traballadores/as cunha motivación intrínseca. A meritocracia amosou ser unha motivación eficaz para realizar grandes contribucións. E a autodeterminación permitiu ás comunidades empregar o seu tempo limitado para facer contribucións dunha maneira máis eficaz e eficiente.

Estado

• Estruturado

Autoría

• Isabel Drost-Fromm

• Georg Grütter

Recoñecementos

• Zack Koppert, por compartir o enfoque de GitHub nos exemplos coñecidos.

Título alternativo

Principios explícitos InnerSource

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Garantía de 30 días

Patlet

cando se aceptan contribucións externas, existe unha aversión natural do equipo a asumir a responsabilidade do código que non foi escrito por eles/as. A través da garantía de 30 días, o equipo contribuidor acepta proporcionar correccións de erros ao equipo receptor. Isto aumentará o nivel de confianza de ambos os equipos e fará que sexa máis probable que se acepten as contribucións.

Problema

Un equipo desenvolve un compoñente que se emprega na organización e resístese a aceptar ou directamente rexeita as contribucións (feature requests). Este comportamento bloquea o progreso e xera frecuentes interrupcións a causa das escaladas.

Contexto

• Os equipos dependen de que outro equipo acepte as súas contribucións para que o compoñente producido polo equipo receptor poida ser empregado polo equipo contribuidor.

• O equipo receptor non dispón dos recursos, dos coñecementos, dos permisos ou da disposición necesaria para escribir, por si mesmo, o compoñente/funcionalidade aportado/a.

Aspectos que mellorar

• Desconfíase das contribucións a causa dun pasado de enganos: os equipos enviaban contribucións que non estaban rematadas e, posteriormente, presentaban peticións de correccións que as deixaban listas para o seu uso en produción.

• Se se aporta código externo, o equipo receptor pode albergar a sospeita natural de que o outro equipo non saiba escribir un código que satisfaga as súas expectativas.

• Cada equipo tenta axudar primeiro a que os/as seus/súas propios/as líderes acaden as súas propias metas. Esta lealdade cara a directiva pode complicar a resolución deste problema.

• Naturalmente, existe un rexeitamento a responsabilizarse do código que non foi escrito por un/unha mesmo/a.

• As contribucións de código deben reescribirse a fondo antes de ser aceptadas na base de código.

• Témese que os/as contribuidores/as non estean dispoñibles para recibir asistencia coa corrección de erros unha vez transcorrido o tempo da contribución.

• Os equipos temen que as contribucións de código xeren custos de mantemento elevados, pero non saben como controlalo.

• Os equipos receptores poden temer que, ensinar a outras persoas a contribuír co código, expoña unha débeda técnica no seu sistema e que a visibilidade poida ser prexudicial.

• É posible que os equipos receptores non crean que obterán un código aceptable por moito asesoramento que brinden.

• Calquera dos equipos pode sentirse inseguro á hora de medir os riscos ou certificar que están mitigados nunha contribución; o sistema en si é algo fráxil (pode que non haxa maneiras de probalo completamente e detectar tódolos problemas).

Solución

Aborde os temores dos equipos receptores e contribuidores establecendo un período de garantía de 30 días, a partir do momento no que a contribución de código entra na fase de produción. Durante este período de garantía, o equipo contribuidor comprométese a proporcionar correccións de erros ao equipo receptor.

Teña en conta que o período de garantía tamén pode chegar a ser de 45, 60 ou 100 días. A duración pode variar en función das limitacións do proxecto, o ciclo de vida do software do proxecto ou os compromisos cos/coas clientes/as, entre outros factores.

Contexto resultante

• O equipo receptor está disposto a aceptar contribucións e pode compartir a carga de traballo das adaptacións/reparacións iniciais.

• Maior transparencia e equidade.

• Evita que as escaladas se volvan demasiado pesadas.

Exemplos coñecidos

• Isto foi probado con éxito en PayPal.

• GitHub emprega internamente este modelo cun prazo de garantía modificado de 6 semanas.

• Microsoft recomenda este modelo coma un principio: os equipos establecen o seu propio obxectivo temporal específico en función das súas necesidades e confianza.

Autoría

• Cedric Willians

Recoñecementos

• Dirk-Willem van Gulik

• Padma Sudarsan

• Klaas-Jan Stol

• Georg Grütter

Estado

• Estruturado

• Redactado no Cume InnerSource de primavera de 2017; revisado o 18 de xuño de 2017.

Variantes

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Gig marketplace

Patlet

establécese un marketplace mediante a creacion dunha intranet que enumere as necesidades específicas do proxecto InnerSource como «Gigs», con requisitos explícitos de tempo e habilidades. Isto permitiralle ao personal directivo comprender mellor o compromiso no tempo e os beneficios profesionais dos seus/súas traballadores/as, o que aumentará a probabilidade de obter a aprobación para realizar contribucións InnerSource.

Problema

Nin os/as directivos/as nin os/as empregados/as entenden como poderían beneficiarse de involucrarse nun proxecto InnerSource.

Para os/as empregados/as é difícil comunicar á xerencia o compromiso de tempo que supón para eles/as a implicación nun proxecto InnerSource.

Os cargos superiores non contan cun sistema uniforme de seguimento ou recompensas en relación á implicación dos/as seus/súas empregados/as en proxectos InnerSource.

Historia

Créase con éxito un programa InnerSource, coa aceptación dos altos cargos, mandos intermedios e desenvolvedores/as da compañía. Non obstante, despois de case un ano, apenas houbo contribucións reais a ningún proxecto de InnerSource fóra dos equipos que os crearon. Tras entrevistar a tódalas partes implicadas, o principal escollo resulta ser a dificultade para coñecer o compromiso de tempo que se lles ía ter que pedir aos/ás desenvolvedores/as que elixisen involucrarse nalgún proxecto InnerSource e como se beneficiarían persoalmente ao facelo. Tampouco existe un sistema establecido para anunciar as oportunidades dispoñibles para os/as contribuidores/as, expor o que se lles vai pedir facer ou unha aproximación do tempo que poden precisar. Os/As directivos/as apoian e alentan aos/ás seus/súas empregados/as a participar pero, ata agora, non tiñan forma de contabilizar ou recompensar as actividades destes/as empregados/as dentro dos proxectos InnerSource. Como se pode mellorar esta situación para tódalas partes (project owners de InnerSource, potenciais contribuidores/as e xestores/as de desenvolvemento)?

Contexto

Os/As empregados/as desexan poder aumentar a súa exposición a actividades que se desenvolven noutras áreas da compañía sen ter que abandonar os seus cargos actuais. A existencia dos proxectos InnerSource poderíalles proporcionar nova experiencia, mais son dous os principais factores que impiden que os/as empregados/as participen. En primeiro lugar, a incapacidade tanto para descubrir con facilidade cales son as oportunidades de contribución dentro dos proxectos InnerSource en curso, como para comunicalo aos/ás seus/súas superiores/as. En segundo lugar, a incapacidade dos altos cargos para planificar e dar conta do compromiso de tempo dos/as seus/súas empregados/as con estas tarefas; que ten como resultado que os/as project owners de InnerSource estean a atopar dificultades á hora de construír comunidades dun tamaño suficiente como para cumprir os obxectivos manifestados.

Aspectos que mellorar

• Os/As empregados/as non contan cun sistema sinxelo para descubrir as oportunidades de InnerSource.

• Os/As empregados/as non teñen modo de comprobar como a súa contribución podería beneficialos/as profesionalmente.

• A xerencia non entende os requisitos tempo/esforzo asociados ás tarefas relacionadas co proxecto InnerSource.

Requisitos previos

• Os/As directivos/as proporcionan tempo aos/ás empregados/as para implicarse nos proxectos InnerSource.

• As contribucións a InnerSource deben ser cuantificables para que os altos cargos poidan rastrexalas e rexistralas e, á súa vez, sexan debidamente contabilizadas e recompensadas.

Solucións

Será necesaria a creación dunha intranet baseada en Gig na que os/as empregados/as poidan anunciar de maneira individual as súas habilidades e áreas de interese, e os/as project owners de InnerSource poidan atopar oportunidades de colaboración.

Os/As empregados/as crearían un perfil na aplicación no que enumerarían as súas habilidades e áreas de interese. O sistema tomaría estes datos e, de maneira proactiva e individual (por correo electrónico ou por outros medios), informaría da publicación dun Gig que coincida cun ou máis deses criterios.

Cada Gig publicado polo/a project owner de InnerSource debería incluír os requisitos estimados de tempo e habilidades precisadas, na procura do/a empregado/a dispoñible mais indicado/a; para poder comunicarllo directamente ao/á seu/súa superior/a inmediato/a. A descrición tamén debería incluír a base dos beneficios para a persoa que asuma a tarefa, de modo que resulte o máis atractiva posible.

Pódese crear un sistema baseado en puntos para recompensar e rastrexar a participación dun/dunha empregado/a nun Gig. Así, outorgaríanse, por exemplo, 10 puntos ao/á propietario/a do Gig por publicalo unha vez completado e 100 puntos para o/a desenvolvedor/a que o complete. Os puntos acumulados ao completar Gigs poderían usarse como mecanismo de gamificación e como criterio de xestión do rendemento ao obter información sobre as áreas de especialización que existen dentro dunha organización.

Quen queira aceptar un Gig será examinado/a primeiro polo/a propietario/a do mesmo para determinar que o/a empregado/a cumpre cos requisitos previos de habilidades e adxudicación de tempo do/a seu/súa xestor/a para completar o Gig.

A transparencia das contribucións a través de Gigs pode axudar a construír (ou desmerecer) a reputación dun/dunha contribuidor/a, favorecendo por iso a probabilidade de que a calidade da contribución sexa alta. Completar Gigs tamén poderá servir para probar a experiencia nun área en particular.

A natureza dos Gigs publicados no marketplace pode incluír tanto habilidades técnicas como competencias sociais; tales como organizar un evento grupal, escribir un informe ou solicitar unha mentoría etc.

A responsabilidade da creación do «Gig marketplace» debería ser asumida por un equipo dunha organización que proporcione infraestrutura e capacidades para toda a compañía.

Contexto resultante

O «Gig marketplace» de InnerSource aumentou considerablemente o número de proxectos InnerSource; así como o número de empregados/as implicados/as neles. A natureza autodirixida do Gig marketplace mellorou a satisfacción laboral entre os/as empregados/as, pois permitiulles elixir o traballo que realizan e con quen asociarse dentro da empresa. Os/As empregados/as saben exactamente a que se comprometen e o que poden esperar da experiencia. Os/As directivos/as poden estimar e rastrexar mellor os compromisos de tempo dos/as seus/súas empregados/as con respecto aos proxectos InnerSource, recoñecer os seus esforzos individuais e tomar os Gigs completados como unha forma de validar as súas habilidades específicas. Ademais, os cargos superiores poden aproveitar o tempo dispoñible de inactividade dun/dunha empregado/a e permitirlle que pase a traballar no Gig marketplace. Os datos xerados polas interaccións no Gig marketplace axudan tamén a impulsar as decisións de contratación e formación en tódolos departamentos.

Cando se usa en combinación co modelo do portal InnerSource, o Gig marketplace ofrece unha maior precisión de contexto e datos, xunto coas ligazóns aos repositorios de código e a documentación do proxecto relacionado co Gig.

Exemplos coñecidos

• Unha grande organización de servizos financeiros empregou a creación dunha web Gig marketplace de InnerSource para promover o seu programa InnerSource.

• SAP implementou o modelo de Gig marketplace, engadindo un novo programa InnerSource á plataforma de traballo interna na que se poden publicar ofertas similares.

Estado

• Estruturado

Autoría

• Stephen McCall

• Shreyans Dugar

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Benvido ao libro Modelos de InnerSource.

Este libro contén as mellores prácticas de InnerSource debulladas nun formato pensado especificamente para que sexan sinxelas de comprender, de avaliar e de aplicar no seu contexto. Referímonos a este tipo de formato como modelo.

InnerSource Commons recompilou estes modelos ao longo de varios anos e publicou os máis maduros neste libro, no que os membros da comunidade revisitan cada modelo a partir de, polo menos, un exemplo de uso coñecido.

Nesta introdución explicamos que é InnerSource, que é un modelo e como empregar eses modelos na súa organización.

Se xa está a empregar InnerSource na súa empresa e quere contribuír achegando experiencias a este libro, encantaríanos recibir as súas contribucións

Que é InnerSource?

Definimos InnerSource como:

O uso de principios e prácticas de software libre para o desenvolvemento de software dentro dos límites dunha organización.

InnerSource toma as leccións aprendidas do desenvolvemento de software libre e aplícaas á forma en que as empresas desenvolven software de maneira interna. Cando os/as desenvolvedores/as xa estaban afeitos a traballar en software libre de xeito universal, xurdiu un forte desexo de volver a introducir esas prácticas dentro do firewall e de aplicalas ao software que as empresas poden amosarse reticentes a lanzar.

Para as empresas que crean na súa meirande parte software de código pechado, InnerSource pode ser unha boa ferramenta coa que eliminar os silos, fomentar e escalar a colaboración interna, acelerar a incorporación de novos/as enxeñeiros/as e identificar as oportunidades para contribuír ao mundo do software libre.

Que son os modelos InnerSource?

Os modelos son unha forma de describir unha solución probada e repetible para un problema nun contexto concreto. Os modelos empregan un formato sinxelo co que, na propia aplicación da solución, axudan a comprender as limitacións do problema, os aspectos que mellorar e o contexto resultante; é dicir, a nova situación xerada tras a aplicación desta solución.

Os modelos poden proporcionar aos/ás participantes de InnerSource Commons un medio polo que compartir información de xeito conciso, para mellorar a práctica InnerSource. Algunhas das seccións principais destes modelos son: Título, Problema, Contexto, Aspectos que mellorar e Solucións.

• Vídeos de Youtube sobre que son os modelos: visualice esta serie de vídeos de YouTube de entre 2 e 5 minutos, na que se explican os modelos InnerSource.

• Webinario sobre os modelos: o16 de marzo de 2017 levouse a cabo este webinario no que se debateu en vivo un modelo donut (minuto 24:30). É un exemplo do proceso de revisión que seguimos. Tamén pode consultar o webinario sobre modelos InnerSource de O’Reilly do 1 de xuño de 2017.

• Prototipo de modelo: observe a estrutura dun modelo InnerSource para ter unha idea do que acontece nun modelo novo.

• Introdución aos modelos InnerSource (presentación en inglés do cumio de outono de 2016), de Tim Yao e Padma Sudarsan (PDF). Expón os antecedentes e algúns exemplos de modelos, e permitiralle comprender en detalle os motivos polos que facer uso dos nosos modelos e como facelo. Consulte tamén a Introdución aos modelos InnerSource (do cume de outono de 2017) de Tim Yao e Bob Hanmer (PDF).

Como pode empregar os modelos InnerSource?

Os modelos deben empregarse coidadosamente. Non poden aplicarse de xeito indiscriminado. Na maioría dos casos, vostede necesitará adaptar unha solución á súa situación particular; mais a información proporcionada no modelo, que define o contexto (os límites inamovibles) e os aspectos que mellorar (os límites que poden cambiar e equilibrarse entre si), debería servir de axuda para poñela en práctica. Teña en conta que tamén deberá determinar se existen limitacións adicionais (o contexto e os aspectos que queira mellorar a empresa) que se apliquen á súa compañía/organización en particular e deban engadirse ao modelo (como se fose unha especie de filtro). Estas limitacións adicionais poden chegar a requirir pasos adicionais para chegar a unha solución.

O impreso do modelo é útil para describir solucións probadas, pero tamén se pode empregar para xerar ideas sobre novas solucións onde aínda non se estableceron modelos. Isto débese a que a anatomía dun modelo proporciona un marco de traballo para pensar sobre un problema dun xeito estruturado. Vostede tamén pode crear un modelo de donut (completando os campos de problema, contexto, aspectos que mellorar e contexto resultante; pero deixando a solución en branco) como unha forma de pedir axuda á comunidade InnerSource Commons (para encontrar unha solución comprobada ou para achegar ideas sobre que cousas probar).

Como contribuír?

Consulte: como contribuír a este libro.

Créditos

Este libro é o resultado de moitos anos de traballo de incontables contribuidores/as de software libre de todo o mundo. A súa vontade de compartir abertamente os desafíos que afrontaron as súas empresas e o xeito no que InnerSource os axudou a abordar eses desafíos, fan deste libro un recurso valioso para calquera que inicie o seu percorrido InnerSource.

Queremos facer unha mención especial ao InnerSource Patterns Working Group, que nutriu a calidade dos modelos e axudou a outros/as a facer contribucións. E tamén compilou a selección de modelos dispoñibles neste libro.

A imaxe do título do libro foi creada por Sebastian Spier e adaptada dunha imaxe de Tony Hisgett - Alhambra 6, dispoñible baixo a licenza CC BY 2.0.

Moitas grazas a todos os/as contribuidores/as! E feliz día InnerSource. :)

Licenza

Modelos InnerSource de InnerSourceCommons.org ten unha licenza Creative Commons Attribution-ShareAlike 4.0 International.

Sobre a tradución

Esta tradución á lingua galega foi elaborada pola AMTEGA (Xunta de Galicia). Cofinanciada a través de Fondos Europeos. Esta iniciativa foi coordinada pola Oficina de Software Libre.

Distribúese baixo licenza Creative Commons Atribución - Compartir Igual 4.0 Internacional (CC BY-SA 4.0). Pode consultar as condicións desta licenza aquí.

Autoras da tradución:

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Cualificación da actividade do repositorio

Patlet

os/as potenciais contribuidores/as queren atopar proxectos InnerSource activos que precisen da súa participación. Ao calcular a cualificación da actividade do repositorio para cada proxecto, pódese crear unha listaxe clasificada de proxectos (por exemplo, no portal InnerSource) para que os/as posibles contribuidores/as poidan determinar dun xeito máis doado en que proxecto desexan colaborar.

Problema

En que orde se presentarán os proxectos InnerSource? Os KPI de clasificación típicos como as estrelas de GitHub, o número de forks, o número de commits, as liñas de código e a última actualización non son suficientes para indicar de forma concisa a actividade dun proxecto.

Os proxectos activos con moito soporte, pero tamén os proxectos bastante novos e entusiastas que necesitan novos/as colaboradores/as, deberían clasificarse nun rango superior ao dos proxectos madurados con pouca actividade ou en modo de mantemento.

Precísase unha nova métrica derivada de varios KPI para definir unha cualificación fiable e versátil para o nivel de actividade dun proxecto. Pódese utilizar para ordenar proxectos segundo o seu nivel de actividade.

Historia

Cando InnerSource se practica durante moito tempo ou se escala máis aló dun determinado número de proxectos (digamos 50 para dar un limiar significativo), é difícil atopar os proxectos InnerSource máis populares e activos actualmente. Os proxectos que existen desde hai moito tempo son coñecidos, pero poden non estar xa moi activos. Por outra banda, proxectos bastante recentes aínda non teñen unha reputación nin unha comunidade activa.

Unha listaxe de proxectos InnerSource non debe considerarse un recurso estático, senón un lugar emocionante para descubrir e explorar proxectos novos e activos, do mesmo xeito que unha páxina de noticias que enumera primeiro os temas máis interesantes do día. Así, resulta beneficioso cando a orde dos proxectos se actualiza regularmente e cambia segundo a popularidade e a actividade do proxecto.

Estas consideracións levaron a un primeiro prototipo para calcular unha cualificación de actividade do repositorio, que funcionou sorprendentemente ben e determinou unha orde de proxectos en constante cambio segundo a súa actividade.

Contexto

Descubrir proxectos InnerSource pódese facilitar co e o modelo , ou promovendo proxectos noutras canles e plataformas de comunicación. A cualificación da actividade define unha orde predeterminada na que se presentan os proxectos á comunidade.

Aspectos que mellorar

Os KPI automatizados que se poden obter consultando a API de GitHub son só parte da verdade. Que pasa coa calidade do código, a dispoñibilidade dunha boa documentación ou dunha comunidade activa e disposta a axudar que faga do proxecto un lugar divertido para contribuír?

Tales KPI «brandos» terían que engadirse manual ou semiautomaticamente ao cálculo e á cualificación resultante. Se existen ferramentas que proporcionan máis contexto para o repositorio, como un informe de cobertura de código, pódense introducir facilmente.

Exemplo ilustrativo

Solucións

A cualificación da actividade do repositorio é un valor numérico que representa a actividade (GitHub) dun proxecto InnerSource. Derívase automaticamente de estatísticas do repositorio como as estrelas, as visitas e os forks de GitHub e pódense enriquecer con KPI doutras ferramentas ou avaliacións manuais.

Ademais, considera parámetros de actividade como a última actualización e a data de creación do repositorio para darlle un impulso aos proxectos novos con moita actividade. Os proxectos con pautas de contribución, estatísticas de participación activa e incidencias (de acumulación xeral) tamén reciben unha clasificación máis alta.

O código seguinte asume que o repositorio contén unha entidade obtida da API de busca GitHub e que o obxecto de participación contén unha entidade da API de estatísticas/participación de GitHub.

Contexto resultante

Os/As colaboradores/as son libres de dedicar unha parte do seu tempo ao proxecto InnerSource. De tódolos xeitos, poden optar por contribuír a un proxecto do que dependen para o traballo no seu equipo habitual. Non obstante, tamén poden escoller colaborar en algo completamente diferente, en función dos seus intereses e obxectivos de desenvolvemento persoal.

Os proxectos pódense clasificar e presentar segundo a cualificación da actividade do repositorio, para dar unha orde significativa nun portal que presente proxectos aos/ás posibles novos/as colaboradores/as. A cualificación pódese calcular sobre a marcha ou nun traballo de fondo que avalíe tódolos proxectos de forma regular e almacene unha listaxe de resultados.

Fundamento

A cualificación da actividade do repositorio é un cálculo sinxelo baseado na API de GitHub. Pódese automatizar completamente e adaptar aos novos requisitos de forma sinxela.

Exemplos coñecidos

Estado

• Estruturado

Autoría

Recoñecementos

Grazas á comunidade InnerSource Commons polos consellos rápidos como un lóstrego e moitas aportacións útiles para alimentar este modelo. Especialmente:

• Johannes Tigges

• Sebastian Spier

• Maximilian Capraro

• Tim Yao

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Líder da comunidade experto/a en InnerSource

Patlet

seleccione persoas con habilidades técnicas e de comunicación para liderar as comunidades e garantir o éxito no inicio dunha iniciativa InnerSource

Problema

Como asegura que a nova iniciativa InnerSource ten o líder da comunidade axeitado/a para que o impacto poida ser maior?

Ao seleccionar a persoas coas habilidades erróneas e/ou non proporcionarlles a capacitación suficiente, arríscase a desperdiciar esforzos e, en última instancia, a que a nova iniciativa InnerSource fracase.

Historia

Considere o seguinte escenario. Unha empresa quere comezar unha iniciativa InnerSource para fomentar a colaboración fóra dos límites da organización. A empresa decidiu comezar cunha fase experimental de alcance limitado. O persoal directivo foi escollendo un tema piloto axeitado para a primeira comunidade InnerSource e espera contribucións de moitas áreas de negocio de toda a organización. A empresa nomeou un/unha novo/a traballador/a para dirixir a comunidade durante o 50 % do seu tempo de traballo, porque aínda non estaba planificado ao 100 %. Despois de seis meses, a comunidade recibiu só unhas poucas contribucións, a maioría das cales proveñen só dunha unidade de negocio. A empresa substitúe o seu/súa líder da comunidade por alguén cunha maior traxectoria na empresa, esta vez só durante un 30 % do seu tempo. Ao cabo doutros seis meses, o número de contribucións aumenta só lixeiramente.

Contexto

• A empresa é grande e antiga. Non ten experiencia previa en software libre ou outros modelos de traballo colaborativo. A cultura da empresa caracterízase por un estilo de xestión clásico de arriba cara abaixo: xeralmente está en desacordo coa cultura da comunidade.

• Aínda que hai paritarios/as e un/unha patrocinador/a no alto cargo, aos/ás responsables de área da empresa non lles entusiasma InnerSource.

• Non se conseguiu convencer a dirección para que achegase máis ca un presuposto limitado para financiar unicamente un/unha líder da comunidade a tempo parcial.

• O/A líder da comunidade seleccionado/a inicialmente ten pouca ou ningunha experiencia previa co modelo de traballo de software libre.

• O/A desenvolvedor/a seleccionado/a como líder da comunidade inicialmente non conta cunha ampla rede de contactos dentro da empresa.

Aspectos que mellorar

Se unha empresa non inviste de xeito significativo na comunidade inicial de InnerSource en termos de presuposto e de capacitación, a credibilidade do seu compromiso coa iniciativa podería parecer cuestionable. O impulso común dunha empresa cunha cultura de xestión tradicional ante un proxecto ou iniciativa que non funciona como se esperaba, será a de substituír o seu/súa líder. Facer isto sen involucrar a comunidade e sen seguir os principios meritocráticos, socavará aínda máis o compromiso da empresa con InnerSource ao pór de manifesto a fricción existente entre a cultura actual da empresa e a cultura obxectivo: a cultura comunitaria.

A achega de do valor dos proxectos InnerSource non resultará evidente para o persoal directivo que está inmerso nos métodos tradicionais de xestión de proxectos. É menos probable que o persoal directivo lle asigne a unha persoa de alto cargo, que xeralmente ten unha gran demanda de proxectos que non son InnerSource, a un proxecto InnerSource que ocuparía unha parte significativa da súa xornada de traballo.

A meirande parte do traballo diario dun/dunha líder da comunidade ocúpao na comunicación. Do mesmo xeito, é probable que tamén teña que encabezar un desenvolvemento inicial. Ante a capacidade limitada, os/as líderes sen experiencia tenderán a centrarse no desenvolvemento e descoidar a comunicación. A barreira para que os/as posibles contribuidores/as fagan a súa primeira contribución e se comprometan coa comunidade será moito maior se non é doado contactar co/coa líder da comunidade ou se tarda en dar retroalimentación e responder a preguntas por falta de tempo. Ademais, os/as líderes inexpertos/as no ámbito técnico probablemente terán máis dificultades para atraer e reter contribuidores/as con moita experiencia, das que tería un/unha líder cun alto desempeño e grao de visibilidade dentro da empresa.

Se unha comunidade non pode crecer o suficientemente rápido e alcanzar a velocidade suficiente, é probable que non poida demostrar de maneira convincente o potencial de InnerSource.

Se a empresa selecciona un/unha responsable de área con experiencia que está empapado/a dos métodos de xestión tradicionais para que sexa o/a líder da comunidade, é probable que este/a se centre en temas de xestión tradicionais como a asignación de recursos, a provisión dunha estrutura e as canles de información; na contra de liderar co exemplo a través de principios meritocráticos. Isto socavaría a credibilidade da iniciativa InnerSource aos ollos dos desenvolvedores/as.

Solución

Seleccione un/unha líder da comunidade que:

• Teña experiencia no modelo de traballo de software libre ou modelos de traballo baseados na comunidade que sexan similares.

• Que teña habilidades brandas necesarias para actuar como un/unha auténtico/a líder.

• Que predique co exemplo e así xustifique a súa posición na meritocracia comunitaria.

• Que sexa un/unha excelente networker.

• Que inspire os membros da comunidade.

• Que poida comunicarse de maneira efectiva tanto coa xerencia executiva como cos/coas desenvolvedores/as.

• Que sexa capaz de xestionar aspectos administrativos do traballo colaborativo.

Apoderar o/a líder da comunidade para que dedique o 100 % do seu tempo ao traballo comunitario, incluíndo a comunicación e o desenvolvemento. Informar a xerencia sobre a necesidade de ter en conta os puntos de vista da comunidade ao xerar un cambio na xestión comunitaria. No mellor dos casos, apoderar a comunidade para que eles/as mesmos/as nomeen un/unha líder da comunidade.

Contexto resultante

Un/unha líder da comunidade coas prioridades descritas anteriormente dará a cara e encarnará o compromiso da empresa con InnerSource. Así será máis probable que outros/as socios/as da súa rede sigan o seu exemplo e contribúan a InnerSource. Co tempo, o/a líder da comunidade poderá crear un core team estable de desenvolvedores/as e, por tanto, aumentar as posibilidades de éxito do proxecto InnerSource. Ao convencer un público o suficientemente amplo dentro da súa empresa do potencial de InnerSource, contribuirá a cambiar a cultura da empresa vixente por unha cultura comunitaria.

Contar con excelentes líderes da comunidade especializados/as é unha condición previa para o éxito de InnerSource. Con todo, non é unha solución milagrosa. InnerSource abrangue moitos retos que superan o que un/unha líder da comunidade pode abordar, como son os retos presupostarios, xurídicos, fiscais e outros retos organizativos.

Exemplos coñecidos

• BIOS en Robert Bosch GmbH: Teña en conta que InnerSource en Bosch estivo dirixido maioritariamente a aumentar a innovación de gran magnitude ao encargarse de produtos de revestimento interno. Actualmente, este modelo non se está a empregar en Bosch por mor da falta de financiamento.

Título alternativo

Coordinador/a da comunidade experto/a en InnerSource

Estado

• Estruturado

Autoría

• Greorg Grütter (Robert Bosch GmbH)

• Diogo Fregonese (Robert Bosch GmbH)

Recoñecementos

• Tim Yao

• Padma Sudarsan

• Nigel Green

• Nick Yeates

• Erin Bank

• Daniel Izquierdo

Rexistro de cambios

• 2016-11-06; 1ª revisión

• 2017-04-06; 2ª revisión

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Modelo de madurez

Patlet

os equipos comezaron a adoptar InnerSource e a práctica estase estendendo a varios departamentos. Con todo, a comprensión do que constitúe un proxecto InnerSource varía. A solución consiste en proporcionar un modelo de madurez que lles permita aos equipos realizar unha autoavaliación e descubrir modelos e prácticas que aínda non coñecían.

Problema

Cando a adopción de InnerSource nunha empresa comeza a incrementarse, a mentoría individual de cada proxecto por un/unha experto/a en InnerSource faise inviable. Ademais, cada vez máis persoas están a adquirir, polo menos, unha comprensión básica do que significa traballar nun proxecto InnerSource. Abarcan tódolos proxectos InnerSource aínda que diverxa a profundidade de comprensión do concepto. Os equipos poden non coñecer modelos probados que lles axuden a pasar ao seguinte nivel e a resolver as incidencias e puntos problemáticos cos que estean a tratar.

Contexto

Varios equipos comezaron a adoptar prácticas InnerSource. O nivel exacto de comprensión da práctica diverxe entre os equipos. Os problemas exactos cos que se atopan os equipos diverxen segundo o contexto e o ambiente de traballo de cada equipo. Como resultado, a definición de cales son as mellores prácticas de importancia nun proxecto InnerSource varía dependendo de cada equipo.

Aspectos que mellorar

Os equipos que comparten aprendizaxe en InnerSource teñen malentendidos, pois non son conscientes do seu respectivo nivel de adopción de InnerSource.

Os equipos cren que «todo consiste en migrar a unha forxa de desenvolvemento de software compartido» (GitLab, GitHub ou Bitbucket son exemplos coñecidos deste tipo de forxas).

Os equipos non coñecen as mellores prácticas que lles axuden a resolver as incidencias coas que se atopan na súa actividade diaria.

Solución

Pedir aos equipos que se autoavalíen en base ao modelo de madurez proposto.

Transparencia

Plans e produtos

O proxecto InnerSource benefíciase de que a planificación sexa transparente en toda a organización ao permitir que as partes interesadas comprendan mellor as decisións e inflúan nelas de xeito que poidan ser seguidas por outros/as.

• PP-0: Os individuos e os equipos non divulgan regularmente os seus plans ou produtos a múltiples partes interesadas. Non existen accións formais na organización.

• PP-1: Os individuos e equipos dan visibilidade aos seus plans ou produtos a múltiples partes interesadas antes de comezar. Folla de ruta compartida.

• PP-2: Xa hai follas de ruta compartidas con directrices claras e regras de contribución nas que os/as interesados/as poden aportar retroalimentación. Non obstante, isto non está estandarizado en toda a organización e non tódolos proxectos proporcionan esta información.

• PP-3: As follas de ruta compártense por defecto e hai un proceso estándar e unha forma homoxénea de facelo en toda a organización a nivel de cada proxecto InnerSource. Esta contén regras claras para contribuír e influír na folla de ruta.

Proceso de desenvolvemento e ferramentas

Os proxectos InnerSource prosperan cando os/as contribuidores/as se volven activos/as e participativos/as. Como resultado, facilitar as contribucións debería equilibrarse con obxectivos puramente técnicos.

• DP-0: Cada equipo segue o seu propio proceso de desenvolvemento e ferramentas. Non están definidos para compartir coñecementos e dispositivos fóra do equipo de desenvolvemento. Equipos de desenvolvemento en silos.

• DP-1: Os equipos de desenvolvemento usan repositorios de código compartido internamente. Algúns equipos desenvolven o seu propio proceso de CI, utilizando ferramentas de CI non corporativas ou estándar. Non hai un proceso de revisión de código definido, aínda que algúns equipos de proxectos fano internamente.

• DP-2: A organización patrocina e promove un repositorio compartido para o coñecemento colectivo. Algúns equipos desenvolven o seu propio proceso de CI, usando ferramentas de CI corporativas. Hai ambientes CI, así como un proceso de revisión do código definido que se emprega nalgúns proxectos. Ás veces, a revisión do código é realizada por membros externos do equipo.

• DP-3: A meirande parte dos equipos desenvolven o seu propio proceso de CI, utilizando ferramentas de CI corporativas. Existen ambientes CI, así como un proceso de revisión do código definido e utilizado. A revisión do código realízana os membros do equipo interno e externo.

Decisións

Para motivar aos/ás compañeiros/as a contribuír ao traballo fóra do seu core team, necesítase visibilidade sobre o proceso de toma de decisións do proxecto anfitrión, pero tamén precisan sentir que as súas voces están sendo escoitadas e valoradas.

• DC-0: Os/As encargados/as de tomar decisións adoitan reter de forma intencionada ou accidental datos e recursos relacionados coas decisións do proxecto.

• DC-1: Os materiais que forman parte das prácticas de toma de decisións están dispoñibles para a súa revisión despois de que se finalicen as decisións.

• DC-2: A xente sente que está ao día e que está axudando a darlle forma ás decisións máis importantes (pero non todas) a medida que se van desenvolvendo. Os materiais que forman parte das prácticas de toma de decisións están dispoñibles nos fitos do proxecto definidos.

• DC-3: As persoas senten que forman parte dun proceso común e estándar para a toma de decisións colectivas que a organización avala. Os materiais que forman parte das prácticas de toma de decisións están continuamente accesibles durante os procesos de traballo.

Recursos de utilidade

Para atraer contribuidores/as, o material útil de soporte debe ser facilmente accesible.

• RS-0: Individuos e equipos non contribúen nin recorren a un repositorio de coñecemento compartido.

• RS-1: Individuos e equipos liberan materiais do proxecto para a súa revisión interna, despois de rematar o seu traballo. Individuos e equipos comparten recursos, pero en sistemas ou repositorios desconectados, fragmentados ou individualizados/en silos. Individuos e equipos comparten recursos, pero non existe unha comprensión común ou compartida dos criterios utilizados para determinar se a información é sensible ou non.

• RS-2: Individuos e equipos fan que os materiais relacionados co proxecto sexan accesibles a algúns membros dos equipos do proxecto segundo formatos e/ou protocolos compartidos claramente definidos. Individuos e equipos manteñen datos e recursos confidenciais e proporcionan detalles, contexto e alcance limitados.

• RS-3: Individuos e equipos fan que os materiais relacionados co proxecto sexan amplamente accesibles para a organización e, posiblemente, tamén fóra dela, segundo formatos e/ou protocolos claramente definidos e compartidos. Os individuos e equipos que deben reter datos e recursos confidenciais teñen claro o que non están a compartir, e outros entenden por que eses materiais non están dispoñibles para eles/as.

Historia

Cando se traballe en equipos anfitrións, os erros serán visibles de xeito automático. Para manter os niveis de contribución elevados, a cultura corporativa debe celebrar o fracaso como unha oportunidade de crecemento e aprendizaxe.

• ST-0: Individuos e equipos non comparten éxitos ou fracasos para que outros aprendan.

• ST-1: Individuos e equipos están cómodos compartindo historias sobre éxitos, pero non sobre fracasos.

• ST-2: Individuos e equipos están cómodos compartindo historias de éxitos e fracasos durante retrospectivas e revisións.

• ST-3: Individuos e equipos están cómodos compartindo historias de éxitos e fracasos e aprenden dos fracasos segundo protocolos formais.

Colaboración

Canles de retroalimentación

Para que se reduzan os silos, os/as compañeiros/as deben sentirse cómodos/as compartindo retroalimentación mutua de maneira aberta. Unha forma sinxela de favorecer isto é utilizar os mesmos principios de comunicación para tódalas xerarquías.

O ideal é ter unhas canles de comunicación adecuadas que sexan coñecidas por calquera persoa da organización, e centradas en diferentes obxectivos (anuncios, soporte ao/á usuario/a, canles de desenvolvemento, infradiscusións etc.). Algunhas das mellores prácticas que se poden establecer a medida que maduren os seus proxectos InnerSource son: Adopción de directrices de netiqueta, abrir un conxunto probado de canles estándar (que se manteñan arquivados, sexan accesibles ao público e permitan facer procuras) para cada novo proxecto InnerSource.

• CF-0: Non hai procesos nin canles establecidos. Algúns membros da organización comparten materiais a través de canles ou discusións privadas.

• CF-1: A organización está en proceso de establecer directrices internas e canles para fomentar diversos puntos de vista sobre as decisións empresariais/departamentais, para que calquera persoa pertencente á organización poida utilizalas. Algúns membros da organización comparten materiais para a toma de decisións de forma informal utilizando plataformas non oficiais. Os/As líderes manteñen, polo menos, unha canle clara e directa para que os membros da organización compartan opinións de forma construtiva sobre algúns asuntos relevantes para o seu traballo.

• CF-2: A organización estableceu pautas e canles internas e proporciona recursos específicos (programas de formación, acceso a contidos etc.) para fomentar e solicitar puntos de vista diversos sobre o equipo ou as decisións.

• CF-3: Os membros da organización comparten materiais para a toma de decisións en plataformas oficialmente autorizadas. Os membros da organización comparten materiais abertamente a través de múltiples canles e métodos para obter retroalimentación. Os/As líderes tamén usan esas mesmas canles, animan abertamente a outros/as a que os utilicen e manteñan rexistros de comentarios públicos ou da retroalimentación recibida polo equipo e/ou das accións que tomaron para abordala.

Liderado

Os proxectos de InnerSource animan aos/ás empregados/as a contribuír a proxectos fóra da influencia directa do/a seu/súa superior directo/a. Isto precisa dunha cultura de confianza.

• LS-0: Cultura de mando e control dentro dunha organización altamente xerárquica.

• LS-1: Algúns/Algunhas líderes están abertos/as a recibir valoracións e crear un ambiente no que a xente se sinta segura proporcionándoas.

• LS-2: A meirande parte dos/as líderes da organización están abertos/as a recibir retroalimentación e crear un ambiente no que a xente se sinta segura proporcionándoa. Pasividade dos/as líderes ao entender que tódolos membros se senten con poder e habilitados para compartir. A organización anima aos/ás líderes a buscar activamente voces non presentes no diálogo para a súa inclusión.

• LS-3: Os membros séntense con poder e habilitados para compartir opinións de forma construtiva sobre calquera asunto relevante para o seu traballo ou sobre o que lles apaixona.

Estrutura organizativa e funcional

Cando InnerSource abandona o nivel de codificación pura e entra no nivel da comunidade e do grupo de traballo, hai potencial para reducir os silos aínda que non sexa posible a colaboración directa no código.

• OF-0: Os grupos de traballo tenden a ser estáticos en termos de pertenza e conxuntos de habilidades.

• OF-1: Existen equipos multifuncionais, pero os roles do equipo adoitan estar pouco claros e as estruturas de goberno son vagas.

• OF-2: Os equipos multifuncionais son comúns e os roles e obxectivos do equipo publícanse abertamente.

• OF-3: Os equipos transversais son comúns e dan a coñecer tódalas súas actividades á organización; á súa vez, a organización promove as mellores prácticas para traballar xuntos/as.

Contribución

No deseño de modelos de contribucións, o obxectivo é ter en conta a colaboración na procura da redución dos silos.

• CB-0: Totalmente illado, non hai practicamente colaboración fóra dos equipos; salvo nos casos de equipos multifuncionais.

• CB-1: Os membros da organización e os equipos colaboran pero, con frecuencia, atópano «demasiado difícil». Os equipos apenas revisan os resultados das súas colaboracións.

• CB-2: Os membros da organización e dos equipos buscan activamente oportunidades de colaboración. Os equipos discuten, revisan e debaten habitualmente os resultados dos seus esforzos de colaboración e, de xeito predeterminado, encárganse de que os seus resultados estean dispoñibles.

• CB-3: Os membros da organización colaboran tanto interna como externamente, de forma que beneficie a tódolos/as implicados/as. Os equipos discuten, revisan e debaten habitualmente os resultados dos seus esforzos de colaboración, comparten as súas aprendizaxes fóra da organización e encárganse de que os seus resultados estean dispoñibles de maneira externa por defecto.

Comunidade

Políticas para compartir

Ter unha base de referencia de valores compartidos fai que sexa máis fácil traballar transcendendo os límites do equipo. Cruzar os límites faise máis fácil se un conxunto limitado de regras e directrices base se aplican en todas partes e se poden referenciar con facilidade.

• SP-0: Non se comparte cultura nin políticas escritas.

• SP-1: Algúns membros da organización únense para definir valores e principios, pero non existe un claro apoio nestes casos.

• SP-2: Os membros da organización documentan colectivamente visións comúns e acordos, como declaracións de misión e códigos de conduta; e son de fácil acceso se precisan consultalos a miúdo. Os materiais de incorporación e os rituais de orientación proporcionan o contexto adecuado para axudar aos novos membros a comprender como se beneficiará a organización das súas contribucións.

• SP-3: Os valores e principios compartidos conforman a toma de decisións, a resolución de conflitos e os procesos de avaliación entre os membros da organización, que fan referencia a estes valores e principios de forma consistente tanto en formato oral como escrito.

Sentirse parte da organización

Unha das posibles razóns para introducir InnerSource nas organizacións pode ser favorecer un maior grao de compromiso. Este punto fai un seguimento de como está a cambiar a implicación dos/as traballadores/as ao adoptar InnerSource.

• PA-0: Baixo grao de compromiso, sen colaboración a xente non se sente cómoda compartindo cos/coas demais.

• PA-1: Os membros da organización séntense cómodos compartindo as súas opinións sen medo a represalias, pero só en ámbitos coñecidos. A xente entende que as mellores ideas gañan e as responsabilidades de liderado recaen en persoas cun historial de contribución e compromiso.

• PA-2: Os membros da organización séntense cómodos compartindo os seus pensamentos e opinións sen medo a represalias. Os/As líderes demostran dedicación aos valores compartidos da organización.

• PA-3: A empresa é proactiva á hora de facerlles saber aos membros que se beneficia das súas contribucións; como tal, os membros amosan ter unha conciencia compartida e unha execución apoderada, e senten un sentido de responsabilidade coa comunidade. Os/As líderes entenden que crecen axudando a outros/as a crecer e son mentores/as dos membros máis novos da organización.

Gobernación

Recompensas

Para impulsar a adopción, pódense usar motivadores extrínsecos na procura do incremento da colaboración entre equipos.

• RW-0: Sen recompensas.

• RW-1: Anímase aos/ás líderes a recompensar colaboracións excepcionais, pero non hai políticas nin procesos establecidos.

• RW-2: Establécense procesos estándar para recompensar colaboracións fóra dos equipos de desenvolvedores/as. Os/As líderes dos equipos ou xuntas deciden quen ten que ser recompensado/a.

• RW-3: As recompensas non só son propostas pola organización, senón que as comunidades poden definir as súas recompensas máis valiosas. A comunidade é a responsable de decidir quen ten que ser recompensado/a.

Políticas de seguimento

Os proxectos InnerSource necesitan un medio para a autoavaliación. As métricas poden ser unha maneira de facilitar esta avaliación. Ademais, en organizacións cun nivel de adopción de InnerSource maduro, esperamos que se faga un seguimento da adopción do método en función de métricas claras e acordadas.

• MP-0: Non existen políticas de seguimento a ningún nivel da organización.

• MP-1: As métricas son importantes para certos equipos e comezan a empregalas de forma illada.

• MP-2: Existe unha estratexia a nivel organizativo con respecto ás métricas que axudan a validar políticas específicas en toda a organización. Esta política de seguimento existe a nivel dalgúns proxectos InnerSource.

• MP-3: Hai pautas, recomendacións e adestramentos claros sobre o uso de métricas cunha certa infraestrutura que proporcionou a organización. Isto funciona en ambos niveis: programa InnerSource para comprender a adopción xeral de InnerSource dentro da organización e a nivel dos proxectos InnerSource.

Soporte e mantemento

O desenvolvemento de funcionalidades non só debe ser propiedade dos equipos de InnerSource: o soporte e o mantemento tamén forman parte das tarefas fundamentais dos equipos.

• SM-0: Soporte ofrecido polo equipo de desenvolvemento principal ou o equipo de soporte. Un contrato comercial garante o soporte. Non hai coñecemento do produto fóra do equipo.

• SM-1: Existen normas e regulamentos para formalizar o soporte ao produto, impartido por un equipo de soporte especializado.

• SM-2: O soporte ás contribucións de InnerSource formalízase a través de modelos de InnerSource como Garantía de 30 días ou Servizo vs. Libraría.

• SM-3: Existen normas e regulamentos para formalizar o soporte do produto por unha comunidade madura.

Cultura

Hai varios niveis que avanzan cara a unha cultura colaborativa.

• CL-0: Silos: os equipos traballan independentemente, pero tamén de forma illada.

• CL-1: Reactiva: Os equipos traballan de forma independente, pero saben como reaccionar ante fallos nas dependencias.

• CL-2: Contributiva: Os equipos axudan activamente coas súas contribucións a mellorar as súas dependencias.

• CL-3: Activista: Os equipos buscan axuda, orientan e contratan novos/as colaboradores/as de forma activa.

Roles InnerSource

InnerSource inclúe roles explícitos. Aínda que nas fases iniciais algúns modelos pódense empregar sen adoptar eses roles, a comunicación dentro de proxectos será máis doada ao empregar explicitamente títulos de roles .

• RO-0: Non hai roles específicos que axuden á adopción de InnerSource. Só están presentes os roles de desenvolvemento comúns: desenvolvedor/a, analista, tester etc.

• RO-1: Ás veces algúns individuos e equipos contribúen a outros proxectos. Trátase de contribucións técnicas, nas que se ve o rol de usuario/a-colaborador/a. Nalgúns equipos, pódese identificar polo menos un membro como referencia técnica e que explica o proceso de desenvolvemento a outros membros do equipo de desenvolvemento. Podería ser un/unha candidato/a para cubrir o papel de trusted committer.

• RO-2: O rol de InnerSource officer encárgase da gobernación e do soporte, así como dos procesos etc. Identifica as necesidades educativas e garante que estas se lles proporcionen á organización. Lidera e orienta á organización no compromiso en proxectos de InnerSource. É o primeiro paso formal no camiño, definindo a visión e a folla de ruta de InnerSource. A organización definiu un papel de trusted committer como un punto de contacto/referencia non só para os membros do equipo de desenvolvemento, senón tamén para os/as contribuidores/as externos/as. Hai un proceso estándar que describe como contribuír á comunidade, no que está presente o rol de contribuidor/a. O rol de data scientist encárgase de xestionar os rastros de actividade que deixa a iniciativa InnerSource, necesarios para medir a súa evolución. O papel de trusted committer evolucionará a un perfil máis técnico, e un/unha coordinador/a da comunidade será o/a encargado/a de «dinamizala», sendo a súa principal responsabilidade atraer e reter novos/as desenvolvedores/as-usuarios/as (contribuidores/as-membros da comunidade).

• RO-3: Os/As expertos/as en InnerSource están a moverse dentro da organización para que outros/as coñezan o traballo actual, para que serve InnerSource e como poñelo en marcha; e axudan aos/ás demais a comprender e formar parte da iniciativa. Aparecen tamén colaboradores/as non técnicos/as.

Contexto resultante

Tódolos equipos coñecen as mellores prácticas dispoñibles.

Os equipos comprenden o seu nivel de adopción de InnerSource.

Antes de adoptar InnerSource como modelo de traballo, os equipos son conscientes das prácticas que se esperan deles, tanto a curto como a longo prazo.

Exemplos coñecidos

• Entelgy

• Zylk

• Bitergia

Autoría

• Daniel Izquierdo Cortazar

• Isabel Drost-Fromm

• Jorge

• Nerea

Recoñecementos

• Alexander Andrade (especial agradecemento polas correccións ortográficas da versión orixinal).

Título alternativo

Modelo de madurez: Información sobre as mellores prácticas de InnerSource

Estado

• Estruturado

• Elaborado en setembro de 2019

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Servizo vs. libraría

Patlet

os equipos DevOps poden ser reticentes a traballar máis alá dos límites do equipo, en bases de código comúns; posto que non está definido quen sería a persoa responsable de responder ante unha situación de inactividade do servizo. Con frecuencia, a solución pode ser implantar o mesmo servizo en contextos independentes con cadeas de escalada separadas, en caso de caída do servizo ou de factorización dunha gran cantidade de código compartido nunha libraría na que se poidan facer colaboracións.

Problema

Cando os equipos traballan nun marco DevOps, as persoas desenvolvedoras son responsables da posta en marcha de funcionalidades de principio a fin: desde o trato co/coa cliente/a, ata a execución das devanditas funcionalidades, o mantemento e o soporte. Isto supón un desafío cando se traballa máis alá dos límites do equipo: as cadeas de escalada poden non ser as mesmas para os erros que se poden producir en calquera dos equipos. A dependencia do código fonte e a súa execución fai que os equipos se pregunten quen será a persoa responsable de proporcionar asistencia no caso de que se detecten erros. Como consecuencia, os equipos son reticentes a unir forzas incluso cando existe un solapamento significativo dos requisitos.

Contexto

• Os equipos traballan nun marco de microservizos.

• Están organizados/as en equipos DevOps totalmente funcionais: cada equipo é responsable das súas contribucións de principio a fin, entre as que se inclúen o mantemento, a asistencia e a atención ao/á cliente/a.

• Un equipo ten a tarefa de proporcionar un servizo aos/ás seus/súas clientes/as finais, bastante similar a un servizo existente creado por outro equipo.

Aspectos que mellorar

• As rutas de escalada da empresa poden ser diferentes para cada un dos equipos.

• É posible que os membros de cada equipo non estean dispostos a responder ao servizo de asistencia no caso de que se detecten erros que non afectan aos/ás seus/súas propios/as clientes/as.

• Os niveis de gravidade para os mesmos tipos de erros poden ser dispares para cada equipo por mor dos distintos estándares SLA (polas súas siglas en inglés, Acordo do nivel de servizo) que delimitan a relación equipo-cliente/a.

• Os equipos poden ter diferentes restricións de seguridade e barreiras lexislativas que rexen os seus campos de actuación.

Solucións

Separar a responsabilidade do código fonte da súa implantación: ambos equipos traballan para identificar de maneira exacta onde hai solapamentos e sinerxías.

Só o código fonte compartido se mantén como parte do proxecto InnerSource con responsabilidade compartida. O código fonte compartido debe ser coherente, posto que inclúe todo o código de proba (como as probas de integración, se están dispoñibles) e a maior parte posible do fluxo de traballo da CI para facilitar a validación da contribución.

Desvinculara configuración e posta en marcha do fluxo de traballo da lóxica empresarial real. Estableza unha segunda implantación do servizo para o segundo equipo.

Trate a base común como unha libraría que empreguen ambos equipos coa propiedade do código compartido.

A implantación das configuracións pódese incluír como proxectos independentes na súa carteira InnerSource co obxectivo de permitir que os equipos debatan/colaboren ou que un novo equipo as copie.

Contexto resultante

Os equipos están dispostos a colaborar, o que os beneficia á hora de compartir o traballo de poñer en marcha a lóxica empresarial.

Un servizo que orixinalmente se creou para funcionar nun marco de traballo específico, convértese nunha solución máis xeralizada baseada nunha necesidade comercial específica.

Ambos equipos chegan a familiarizarse coas súas respectivas políticas de escalada e coa implantación da configuración, a cal podería identificar melloras na súa propia configuración.

A probabilidade de que se precisen cambios e se realicen no código fonte compartido aumenta, o que xera oportunidades máis frecuentes para perfeccionar, mellorar e optimizar a execución.

Finalmente, foméntase a estandarización gradual das operacións no paquete de lanzamento, na telemetría, nos puntos finais de estado/preparación etc., a medida que os equipos se dan conta de que poden manter a configuración de maneira máis eficiente no código compartido, se estes chegan a un acordo sobre as convencións estándar.

Ver máis

Este modelo está relacionado co de garantía de 30 días, o cal adopta un enfoque diferente para resolver os aspectos que mellorar descritos anteriormente.

Exemplos coñecidos

• Europace AG

• Flutter Entertainment: Aaplicación Flutter InnerSourceten un repositorio de «servizo» de código compartido para as contribucións entre equipos e o fluxo de traballo da CI co fin de crear e publicar un dispositivo de lanzamento compartido. Cada equipo ten un repositorio de «configuración de uso» que define a súa propia implantación. Isto débese a requisitos normativos cambiantes que impulsaron diferentes requisitos normativos, prácticas de xestión de servizos e incidencias e conxuntos de habilidades de infraestrutura en diferentes áreas de negocio.

Estado

• Estruturado

Autoría

• Isabel Drost-Fromm

• Rob Tuley

Recoñecementos

Grazas Tobias Gesellchen pola revisión interna de Europace AG.

Título alternativo

Servizo vs. libraría: É InnerSource, non execución interna.

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Soporte grupal

Patlet

que acontece se un equipo ou unha persoa abandona un proxecto InnerSource? Para manter vivo o proxecto fórmase un novo grupo de colaboradores/as interesados/as.

Problema

• Un proxecto InnerSource popular queda orfo.

• Non se conta cun sitio claro para a súa publicación.

Historia

Máis de 50 proxectos de toda a compañía empregan unha libraría de widgets UI. O equipo disólvese ao esgotarse o financiamento do equipo propietario da libraría. Nun principio, ninguén se decata mais, despois dalgún tempo, cada vez que alguén pregunta quen é o/a propietario/a, non hai resposta. Que vai pasar agora? Os novos equipos evitarán usala? Estancarase o proxecto e permanecerá así ata que finalmente os/as seus/súas usuarios/as se vexan obrigados/as a cambiar a outra cousa? Unha mágoa se iso pasase cun proxecto bo e perfectamente útil!

Contexto

• Proxecto InnerSource popular.

• Consumido como unha dependencia do tempo de compilación (por exemplo, o módulo de código).

• Ninguén lle presta soporte de forma activa.

• A compañía non pode asignar un equipo de soporte.

Aspectos que mellorar

• Ninguén ten asignado como traballo principal encargarse do caso.

• Todos/as están ocupados/as.

• A migración fóra do proxecto ten un alto custo.

Solucións

Convocar voluntarios/as interesados/as de calquera sector da compañía para formar un grupo de trusted committers que dean soporte ao proxecto. Pode ser preciso pórse en contacto con individuos específicos, en función do historial de uso e commits. É importante que sexan suficientes para que a carga de cada un/unha deles/as sexa razoablemente pequena.

Ao formarse, este grupo debería identificar ou constituír unha documentación base estándar e ferramentas de comunicación.

O grupo fará o posible para xestionar estes aspectos do proxecto:

• Mantemento. Se o proxecto está totalmente roto para o caso de uso estándar, haberá que arranxalo. É preciso manter o proxecto actualizado a medida que as dependencias e os marcos que usa seguen a desenvolverse.

• Incorporación. Se alguén ten unha pregunta sobre como empregar o proxecto, haberá que asegurarse de que obtén unha resposta razoable.

• Actualizacións. Se alguén quere engadir novas funcionalidades ao proxecto, proporcionaráselle o deseño e soporte técnico precisos para a súa contribución, de xeito que sexa tanto bo para eles/as como para o proxecto. As pull requests entrantes revisaranse de maneira oportuna.

Posto que o grupo está formado por voluntarios/as, é importante comunicar que o soporte é só o seu «mellor esforzo». E, en consecuencia, este modelo de soporte non é adecuado para proxectos de produción críticos en tempo de execución como as live API. Será máis axeitado para proxectos que se consomen no tempo de compilación, como librarías/paquetes/módulos. Non se espera que o grupo introduza ningunha funcionalidade nova para outros.

Contexto resultante

• Soporte feble para o proxecto InnerSource.

• A longo prazo, é probable que volva faltar o soporte nalgún momento. Polo que se o proxecto continúa no tempo, deberá empregarse este período de soporte grupal estable para dar cunha forma duradeira de mantelo (por exemplo, o core team).

Fundamento

A xente xeralmente estará disposta a axudar. Se alguén quere converterse en trusted committer, o máis probable é que un gran número de persoas estean de acordo. Sentirse parte dun grupo e ter certa estrutura e responsabilidade, en xeral, motiva á xente a dar o máximo posible, o que a meirande parte das veces acaba sendo suficiente.

Exemplos coñecidos

• WellSky

Estado

• Estruturado

Autoría

• Russell R. Rutledge

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Valoración de proxectos entre equipos

Patlet

é difícil convencer acerca do valor dos proxectos InnerSource desenvolvidos entre equipos que non teñen un impacto directo nos ingresos da empresa. Velaquí unha forma de representar o seu proxecto baseada en datos, que articula o seu valor e amplifícao.

Contexto

• Vostede é responsable da colaboración entre equipos que serve de plataforma para outros/as traballadores/as da empresa.

• O proxecto de colaboración entre equipos non achega ningún valor directo aos ingresos da empresa.

Problema

Os proxectos de colaboración entre equipos poden ter un grande impacto na empresa, pero son difíciles de representar mediante datos. En consecuencia, é doado e habitual seguir adiante con proxectos que non achegan valor real ou non inverter suficiente diñeiro, o que, en caso contrario, si achegaría un gran valor.

Aspectos que mellorar

• Os proxectos deben amosar valor (obxectivo ou subxectivo) ao liderado da empresa para que se poidan financiar.

• O valor do proxecto de colaboración entre equipos distribúese entre múltiples unidades comerciais afíns.

• Por mor desta dispersión, o valor do proxecto de colaboración entre equipos é difícil de medir de xeito directo.

Solución

Estableza un modelo e unha fórmula para avaliar os proxectos de colaboración entre equipos. Estes modelos bríndannos a ferramenta que necesitamos para centrar e amplificar a colaboración de gran valor para a empresa.

O núcleo do valor de todo proxecto de colaboración entre equipos é a idea de que podemos facer máis cousas xuntos/as que separados/as. Atribuírlle valor ao esforzo de colaboración entre equipos é un exercicio para cuantificar canto máis se está avanzando xuntos/as. O delta exacto de produtividade variará segundo o ámbito e o proxecto. Existe un proceso común, mediante o cal pode crear unha fórmula para calculalo.

Explicación

Reúna un pequeno equipo de expertos/as na materia do seu ámbito. Empregando ese equipo de expertos/as, estime catro aspectos sobre cada consumidor/a da produción do seu proxecto:

• Canto tempo lles leva consumir a produción do seu proxecto?

• Canto tempo lles levaría, pola contra, calcular o valor da produción do seu proxecto por si mesmos/as?

• Que porcentaxe da produción do seu proxecto é realmente útil para eles/as?

• Canto tempo (por uso óptimo) dedicarían a empregar unha solución caseira?

Á hora de facer estas estimacións, é imposible saber con gran precisión canto tempo leva cada actividade. Ese non é o seu obxectivo. En lugar da exactitude, debe esforzarse en establecer un límite para delimitar o peor escenario posible destas estimacións.

A idea é que no grupo de expertos/as poidan dicirse uns/unhas a outros/as: «Non sabemos exactamente canto tempo nos levaría, pero todos/as estamos de acordo en que, polo menos nos levaría este tempo». Concretamente, debe estimar un tempo máximo razoable e tempos mínimos razoables para que os/as consumidores/as poidan, por outra parte, improvisar e aplicar as súas propias solucións.

Un apunte sobre o custo de idear unha «solución caseira propia»; o custo de pór en marcha unha solución caseira NON é necesariamente (de feito, é moi pouco probable) o mesmo que o de crear unha solución común. A miúdo, para a mesma funcionalidade, a modularidade e a calidade involucradas na creación dunha solución mediante a colaboración entre equipos, fai que sexa un investimento notablemente maior que unha aplicación rápida e codificada que se emprega só unha vez.

Fórmula

Unha vez que teña os límites do peor escenario posible, pode valorar o resultado do seu proxecto de colaboración entre equipos durante un período de tempo concreto a través da sinxela fórmula:

[Time Saved] - [Time Invested]

([Count of New Onboardings] * [Cost to Home-Roll] * [Percent Useful Functionality] + [Count of Usages] * [Maintenance Cost Per Use]) - ([Count of New Onboardings] * [Cost to Onboard])

[Count of New Onboardings] * ([Cost to Home-Roll] * [Percent Useful Functionality] - [Cost to Onboard]) + [Count of Usages] * [Maintenance Cost Per Use]

Comentario

A pesar do seu rigor, este proceso non produce unha forma exacta para medir o resultado nun proxecto de colaboración entre equipos. Na práctica, con todo, brinda un marco mediante o cal pode tomar unha decisión acertada para financiar este traballo. Tras dispor de datos fiables e razoables, de acordo coa explicación anterior, debe financiar as horas de desenvolvemento dedicadas a executar o proxecto ata, polo menos, chegar ao nivel máis baixo destes tres niveis seguintes:

1. As horas brutas que se aforraron mediante a fórmula anterior. Posto que todos/as estamos seguros/as de que a fórmula nos devolverá unha cifra inferior ao número real de horas aforradas, pode estar seguro/a de que financiar o proxecto é unha vitoria asegurada.

2. A cantidade de tempo que se necesita para apoiar as contribucións InnerSource a proxectos de colaboración entre equipos. Posto que o/a contribuidor/a probablemente tería feito o traballo de todos os xeitos puntualmente, merece a pena financiar o tempo que se necesita para facilitar que o seu traballo pase a estar nunha arquitectura de información compartida.

3. O que a vostede lle pareza mellor. Un efecto secundario intencionado de dispor dunha fórmula de valoración é que, naturalmente, obriga a medir puntos chave que dan valor aos/ás consumidores/as.

Esas medicións poden entenderse e consumirse na súa forma bruta para que vostede poida intuír a valía deste proxecto:

Pode que a algúns/algunhas lles preocupe a falta de precisión deste método de valoración. Está ben que este proceso non teña un resultado de medición exacta. Só ten que ser o suficientemente preciso para cumprir dous obxectivos:

1. Ofrecer un medio para representar o valor do que está acontecendo a quen organiza e financia o esforzo dos equipos.

2. Axudar os/as implicados/as a saber que áreas dos esforzos entre os equipos son máis prioritarias en función do seu valor.

Na práctica, sempre que estas valoracións se atopen dentro dunha orde de magnitude da realidade e entre si, son suficientemente precisas para cumprir con estes fins. Mellorarán de sobra os resultados obtidos respecto das valoracións ad hoc (e dos efectos resultantes) descritas na sección Problema ao comezo deste documento.

Contexto resultante

• Medios baseados en datos para debater o valor e financiamento do proxecto de colaboración entre equipos mediante o liderado.

• Métricas clave arredor do proxecto de colaboración entre equipos instrumentados en bruto.

• Definir a forma na que o proxecto de colaboración entre equipos achegar valor e como iso adoita producir un maior valor para a empresa.

• Éxito xeral do proxecto e axitación ao seu redor.

Exemplos coñecidos

• Nike

Estado

• Estruturado

• Probado en múltiples dominios

Autoría

• Russ Rutledge

Recoñecementos

• Jeremiah Wright, por ensinarme a considerar os proxectos de colaboración entre equipos como un negocio interno no que a moeda é o tempo dos desenvolvedores/as.

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Tipos de contribucións

Nesta sección proporcione información sobre o tipo de contribucións que está a procurar o seu proxecto. Por exemplo, poden ser informes de erros, axuda para responder preguntas dos/das usuarios/as, melloras da documentación, corrixir erros e a posta en marcha de funcionalidades.

Informes de erros

Engada información sobre como enviar informes de erros neste apartado. Isto debe incluír suxestións sobre o tipo de información que precisará o proxecto para reproducir e solucionar problemas. Tamén pode incluír información sobre os erros de configuración máis comúns que parecen bugs.

Ademais, deberá incluír información sobre o que os/as contribuidores/as poden esperar en termos do tempo que transcorre dende a primeira resposta e o proceso posterior.

Peticións de funcionalidades

Engada información sobre como enviar feature requests. Do mesmo xeito, tamén debería incluír neste apartado a información sobre o que cabe esperar por parte dos/das contribuidores/as, en termos do tempo da primeira resposta e do proceso posterior.

Contribucións de documentación

Inclúa información sobre as mellores prácticas de documentación que segue o seu proxecto, así como instrucións sobre como crear a documentación, a execución de verificacións e o envío de cambios realizados no proxecto.

Contribucións de código fonte

Esta sección debería conter información sobre:

• Como acceder ao código fonte do proxecto.

• Disposición xeral do proxecto.

• Calquera requisito para o medio de desenvolvemento.

• Directrices de formato de código.

• Como executar o conxunto de probas.

Como chegar a ser trusted committer

Esta sección debe facer explícito o proceso para converterse nun/nunha trusted committer se esa ruta está aberta aos/ás contribuidores/as.

Como nomear o/a trusted committer

Esta sección serve a modo de recordatorio para os/as trusted committers existentes e como explicación para os/as novos/as. Nela detállase como engadir a outras persoas ao host team. Deste xeito, o ideal é que esta información sexa idéntica para tódolos proxectos da organización, de modo que a información máis relevante se poida vincular desde aquí.

Title

Trusted commiter

Patlet

moitos proxectos InnerSource recibirán valoracións constantemente ou requirirán a posta en marcha de novas funcionalidades e a corrección de erros por parte dos contribuidores/as. Nestas situacións, as persoas encargadas do mantemento do proxecto buscan formas de recoñecer e recompensar o traballo do contribuidor/a máis alá das contribucións individuais.

Problema

• As persoas encargadas do mantemento de proxectos queren atopar xeitos de incrementar a súa capacidade para brindar apoio a un proxecto.

• As persoas encargadas do mantemento de proxectos queren atopar xeitos de prolongar o valor que aportou o proxecto.

• As persoas encargadas do mantemento de proxectos queren recompensar visiblemente aos/ás contribuidores/as frecuentes e capacitalos/as para que melloren o valor das contribucións.

• Falla de mecanismos e linguaxe para recoñecer as contribucións que levaban a cabo os equipos dunha organización.

Contexto

• Vostede é a persoa encargada do mantemento dunha libraría, un servizo ou un recurso compartido entre equipos.

• Recibe contribucións regularmente.

• Recibe peticións de funcionalidades regularmente.

• Recibe solicitudes periódicas de corrección de erros.

• Hai contribuidores/as con motivación propia que buscan desenvolver as súas competencias a través de proxectos InnerSource.

Aspectos que mellorar

• Durante o ciclo de vida dun proxecto, o enfoque dos/as mantedores/as pode mudar co fin de adaptarse ás prioridades comerciais cambiantes.

• Os/As contribuidores/as buscan un recoñecemento visible das súas contribucións, que amose valor.

• Manter un proxecto de complexidade razoable resulta complexo para un equipo pequeno.

• Desenvolver funcionalidades de proxecto a escala é esixente para un equipo pequeno.

Solución

Definir o rol do/a trusted committer nun proxecto

O labor do/a trusted committer depende de cada proxecto e do seu persoal encargado de mantemento. Asegúrese de documentar no proxecto o alcance da función do seu/súa trusted committer. A documentación específica establece o que cabe esperar dos novos membros da comunidade e establece o papel dos/as futuros/as candidatos/as.

A continuación, enuméranse algunhas pautas para identificar un/unha posible trusted committer:

• Un/Unha participante activo/a nas canles da comunidade (Slack, triaxe de problemas en JIRA etc.) convértese nun/nunha trusted committer formalizando, así, o seu papel de apoio á comunidade.

• Alguén que envía código, documentación ou outros cambios no repositorio. Comece por incluír a esta persoa nas pull requests. Se participa de xeito activo nas pull requests, considere achegarse a esa ou a esas persoas para propoñerlle unha maior colaboración no proxecto.

Formalizar aos/ás trusted committers

O primeiro paso é achegarse ás persoas candidatas para que se convertan en trusted committer. O persoal encargado do mantemento debe educar ás persoas candidatas sobre o papel do/a trusted committer. Non se espera que as persoas candidatas acepten o rol de trusted committer. Cada candidato/a debe avaliar se ten o ancho de banda necesario para asumir as responsabilidades.

Cando un/unha candidato/a acepta o rol, correspóndelle ao persoal encargado de mantemento do proxecto recoñecer publicamente o paso de usuario/a a trusted committer. Tamén é unha boa idea engadir o seu nome a unha sección de trusted committers no README do seu proxecto. Como por exemplo:

# project-name

... your project's readme ...

## Project Leaders

### Maintainers

  - Your team

### [Trusted Committers]

  - The name of the new trusted committer

[Trusted Committers]: https://example.com/link/to/your/trusted/committer/documentation.md

Mantemento de relacións entre trusted committers

Unha vez que formalice a incorporación dun/dunha novo/a trusted committer, é unha boa idea mantelo/a informado/a mentres continúa iterando no seu proxecto. Manter informados/as aos/ás trusted committers pode ser tan sinxelo como convidalos/as á súa canle de proxecto ou incluílos/as nas súas sesións de planificación. Deste xeito, se os/as trusted committers teñen máis oportunidades de participación, poderán ter acceso ao persoal encargado do mantemento, se así o desexan.

Ademais de manter informados/as aos/ás trusted committers, resulta positivo pórse en contacto de maneira periódica. Unha cadencia suxerida é comezar cada semana antes de progresar gradualmente a cada poucas semanas. O propósito destes contactos é asegurarse de que o/a trusted committer se sinte apoiado no seu novo papel. Ao igual que nas reunións 1:1 co/coa seu/súa xerente, se hai algún problema, escoite e empatice para tratar de comprender que está a impedir que o/a trusted committer teña éxito. Agradézalle sempre a este o seu esforzo continuo por facer que o proxecto sexa exitoso e estableza, así, unha nova data para volver a contactar.

Cese dun/dunha trusted committer

Hai momentos nos que pode ser necesario prescindir dun/dunha trusted committer. Estas circunstancias acontecen cando o/a trusted committer:

• Xa non está disposto/a a participar.

• Xa non pode cumprir coas súas funcións.

• Xa non é empregado/a da empresa.

Ambas partes deben acordar un plan para eliminar o acceso aos recursos do proxecto, tales medidas inclúen a transición da súa entrada na sección de trusted committer dun proxecto a unha listaxe de contribuidores/as anteriores.

Despois de eliminar o acceso, agradeza ao/á trusted committer a súa participación de maneira pública. O recoñecemento público asegura unha comunicación clara no proceso de transición e continuidade da comunidade.

Contexto resultante

Para os/as contribuidores/as

Acadar o status de trusted committer nun proxecto demostra iniciativa á hora de contribuír a un proxecto comunitario. O recoñecemento destes esforzos pódese utilizar durante as revisións anuais cos/coas xerentes.

Para os/as mantedores/as

Á medida que un proxecto madura, as persoas encargadas do mantemento poden familiarizarse menos cos aspectos chave dun proxecto. Os/As trusted committers enchen estes ocos baleiros, asegurando que todos os aspectos do proxecto sexan atendidos mellor co tempo.

Contar cun conxunto robusto de trusted committers asegura que, se o persoal encargado do mantemento do proxecto segue adiante, sempre existirá un plan para a Administración responsable.

Exemplos coñecidos

Esta iniciativa foi levada a cabo con éxito en:

• Nike

• Paypal

• Mercado Libre: Engadindo unha sección no arquivo CONTRIBUTING.md para informar de quen son os/as trusted committers.

• Robert Bosch GmbH: non se designou co nome de «trusted committer», pero si se implantou este rol ao comezo da implantación de InnerSource. Os/As trusted committers recibiron financiación para o 100 % do seu tempo laboral co obxectivo de que puidesen centrarse neste papel.

Estado

• Estruturado.

• Publicado internamente en Nike; redactado a través dunha pull request en xuño de 2018.

Autoría

• Fernando Freire

Recoñecementos

• Rusell Rutledge

• Loren Sanz

• Noah Cawley

• Jeremy Hicks

• Doron Katz

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Toma de decisións transparente entre equipos mediante RFC

Patlet

os proxectos InnerSource que desexan lograr un alto índice de participación e tomar as mellores decisións posibles para todas as persoas involucradas, necesitan atopar formas de crear sistemas participativos durante todo o ciclo de vida do software. A publicación de documentos internos con peticións de comentarios (RFC) permite manter debates desde o comezo do proceso de deseño. Tamén aumenta as posibilidades de idear solucións cun alto grao de compromiso por parte de tódalas partes implicadas.

Problema

Para que un proxecto InnerSource goce de boa saúde, precisa dunha cantidade substancial de contribuidores/as. Estes contribuidores/as (ou equipos) poden ter diferentes requisitos para o proxecto en cuestión. Por exemplo, é posible que desexen engadir funcionalidades ao proxecto que, ou ben non sexan compatibles entre si ou ben causen unha inflamación insán da arquitectura.

Descubrir este tipo de desacordos ou malentendidos nunha fase avanzada do proceso, por exemplo, unha vez que o software xa está construído, pode resultar moi custoso. Estes desacordos poden provocar frustracións en tódalas partes, e incluso poden ser prexudiciais para a saúde da cultura de colaboración no proxecto. Unha situación común na que xorde tal desacordo é na pull request, a cal se atopa aberta durante moito tempo porque o/a autor/a da solicitude de cambio e as persoas encargadas do mantemento do proxecto non están de acordo en que o cambio proposto deba levarse a cabo.

No caso dun proxecto InnerSource, esta situación ocorre con maior frecuencia cando varios equipos da empresa se encargan do mantemento do proxecto, é dicir, cando se trata dunha propiedade compartida.

Historia

Un proxecto ou unha aplicación composta por múltiples proxectos mantense grazas a varios equipos diferentes, e cada un deles posúe diferentes áreas do proxecto ou da aplicación. Estes equipos fan contribucións InnerSource ás áreas dos demais, pero os cambios transversais de maior envergadura só os impulsan os/as líderes técnicos/as dos equipos que colaboran entre si, do contrario non se levan a cabo. Isto ten como resultado que a maioría dos/as enxeñeiros/as sexan incapaces de efectuar cambios transversais a grande escala, o que reduce a innovación e as oportunidades de colaboración.

Ao executar un proceso e un prototipo para as RFC, os equipos e as persoas teñen a capacidade de propor cambios transversais importantes a través dun proceso de toma de decisións transparente, con consultas entre equipos levadas a cabo de xeito asíncrono. O resultado é unha maior innovación, unha colaboración máis intensa e unha maior difusión do coñecemento. Isto depende da aceptación de tódalas disciplinas en todos os niveis e da creación dunha contorna de seguridade psicolóxica para que as persoas poidan propor e debater ideas abertamente.

Como en todo proceso, isto debe mellorarse de maneira continua. É posible que sexa necesario realizar cambios no prototipo ou no proceso de RFC para garantir que sexa inclusivo, colaborativo e eficaz.

Contexto

• Propiedade compartida por moitos equipos dun proxecto de InnerSource.

• As decisións xerais sobre o deseño non poden tomarse sempre desde un organismo central (por exemplo, un grupo de arquitectos/as), xa que non dispoñen do tempo nin amplos coñecementos técnicos para tomar decisións acertadas en calquera situación que se presente.

• Distintos tipos de usuarios/as teñen unha opinión respecto á dirección que está a tomar un determinado proxecto. Con «usuarios/as» referímonos a: desenvolvedores/as, product owners, product managers etc.

• As decisións deben tomarse de maneira asíncrona, polo menos nalgúns casos, xa que non é factible convocar reunións síncronas con tódalas persoas participantes de maneira frecuente.

• Procúrase documentar as decisións tomadas, é dicir, asegurarse de que se toman por escrito, no canto de só verbalmente.

Aspectos que mellorar

• A maioría das veces, as partes involucradas queren tomar unha decisión con bastante rapidez (por exemplo, o tempo de deseño inicial é bastante limitado).

• Escribir cousas (sen levalas á práctica previamente) adoita ser unha nova habilidade para moitas das persoas implicadas.

Exemplo ilustrativo

Solucións

Eliximos un proceso similar a RFC para aumentar a transparencia do noso proceso de toma de decisións entre equipos (vexa tamén RFC).

Os elementos importantes para resolver este caso son:

• Unha descrición que informe do momento no que publicar un RFC (e cando non hai que facelo).

• Un prototipo para documentos RFC:

  • Debe facer que o autor de RFC considere a súa proposta desde múltiples ángulos.

  • Debe apuntar tanto unha descrición xeral accesible de alto nivel como unha explicación detallada en profundidade.

• Un proceso comprensible e ben coñecido arredor dos RFC, por exemplo:

  • Como publicar RFC e compartilo con tódalas partes interesadas (por exemplo, en Slack ou pola listaxe de correo).

  • Como recoller comentarios para RFC.

  • Como traballar a retroalimentación.

  • Como trasladar o RFC cara unha conclusión ou decisión (por exemplo, no caso de designar ás persoas responsables de mantemento pertinentes para que a proben).

  • Elección das ferramentas apropiadas (por exemplo, é posible que os/as non enxeñeiros/as non teñan acceso ás ferramentas de control de código fonte).

• Un compromiso que repetir no proceso e prototipo RFC.

Exemplos/Prototipos

• Rust é un bo exemplo de prototipo e proceso RFC dun software libre, e foi a base de moitos outros procesos RFC.

• Prototipo RFC xeralizado en BBC iPlayer & Sounds, orixinalmente baseado no prototipo de Rust.

Contexto resultante

A posta en práctica dun proceso similar a RFC demostrou ser valiosa, xa que fai que o proceso de toma de decisións entre equipos sexa máis transparente para todos/as, o que permite que tódalas voces sexan escoitadas.

Efectos positivos observables:

• Democratización do proceso de toma de decisións que afectan a moitos equipos (o que tamén libera aos/ás líderes de equipo desa carga).

• Un método de comunicación asíncrono e aberto que funciona ben con múltiples equipos en zonas xeográficas.

• Apodera a individuos e equipos para efectuar cambios a grande escala.

• Rexistro de decisións tomadas para que as persoas poidan consultalas en contexto.

• Aumenta o impacto dos/as enxeñeiros/as experimentados/as, xa que poden dar solucións de forma asíncrona e en remoto, en lugar de ter que estar presentes nunha reunión.

• Aliñación terminolóxica, por exemplo, detallando a nosa terminoloxía de diagnose como: «Que é unha proba de sistema?».

• Aliñación de procesos, por exemplo, detallando o proceso de soporte fóra de horario laboral.

• Maior claridade de pensamento, xa que escribir un RFC fai que a persoa autora se desafíe a si mesma máis que de costume.

O enfoque RFC tamén ten o risco de:

• Non funcionar sempre; por exemplo, algunhas persoas poderían argumentar en contra dunha decisión que xa se tomou a través dun RFC. Porén, que o proceso de toma de decisións sexa por escrito segue sendo beneficioso nestes escenarios, xa que pode indicarlles ás persoas cando e por que se tomou unha determinada decisión.

• Redactar propostas de deseño (arquitectura, protocolos etc.) por adiantado ten un elemento de desenvolvemento en fervenza que non se axusta ao enfoque de desenvolvemento iterativo que prefiren moitos equipos. Lembre: «Software de traballo sobre documentación completa» (Agile Manifesto). O proceso RFC debe ser o máis lixeiro posible.

• Un RFC pode volverse grande e demasiado difícil de manexar. Isto adoita amosarse en forma de longos fíos de comentarios e discusións que o rodean. Nesas situacións, podemos decidir complementar o RFC con comunicación síncrona, elaborando un grupo de traballo e pautando reunións presenciais. Aínda así conséguese aforrar tempo, posto que as persoas poden ler o RFC antes da xuntanza no canto de compartir toda a información só durante a xuntanza.

Fundamento

Os RFC demostraron a súa valía no mundo do software libre durante moitos anos. Un exemplo disto é o da Internet no seu conxunto, no cal os RFC foron fundamentais no desenvolvemento de estándares (por exemplo, consulte 30 anos de RFC), como para outros proxectos de software libre que adaptaron este método co obxectivo de promover a toma de decisións transparente na súa comunidade (por exemplo, RUST e ZeroMQ).

No contexto InnerSource, outras empresas tamén compartiron xa as súas experiencias con enfoques similares a RFC, como é o caso de Uber e Europace.

Por outra banda, en canto á toma de decisións fóra das puras decisións de deseño de software, os exemplos de transparencia poden ser efectivos, por exemplo, cando se traballa de cara a unha Organización Aberta. Para ver un exemplo, consulte Red Hat’s Open Decision Framework (feito público o 7 de xuño de 2016).

Exemplos coñecidos

• BBC iPlayer & Sounds: Tal como se presentou no cume de outono de 2020 de ISC, Using Internal RFCs to Enhance Collaboration [O uso de RFC para promover a colaboración].

• Europace: Como se describe en Open Organization: Setting cross-team standards and best practices in the open [Establecemento de estándares entre equipos e mellores prácticas no marco de decisións aberto].

• Uber: Segundo esta publicación de blog de Gergely Orosz: Scaling Engineering Teams via RFCs: Writing Things Down [A escalada dos equipos de enxeñaría mediante RFC].

• Google Design Docs: Como se describe na publicación de blog de Malte Ubl: Design Docs at Google.

• DAZN (10/2021): Un dos xeitos mediante os que DAZN leva a cabo a toma decisións técnicas é a través de RFC. Os RFC empréganse para decisións que se aplican exclusivamente a procesos de enxeñaría! Os RFC atópanse nun repositorio de GitHub, os estándares técnicos adóptanse gradualmente dentro das súas ferramentas e polos/as seus/súas enxeñeiros/as. Así, calquera enxeñeiro/a pode propor un RFC e o resto dos/as enxeñeiros/as poden votar por este RFC. Se os votos a favor superan aos votos en contra, adóptase o RFC. Vale a pena sinalar que o proceso de votación de RFC aínda non foi probado por ningunha decisión contenciosa. Tal e como se describe nesta publicación de blog de Lou Bichard: Building A DX Team: Lessons Learned [A construción dun equipo A DX: Leccións aprendidas].

Estado

• Estruturado

Autoría

• Tom Sadler

• Sebastian Spier

Títulos alternativos

• Design Docs

• Architecture Decision Record (ADR, en inglés, Rexistro das decisións sobre a arquitectura): Non necesariamente un título alternativo, xa que ás veces pódense usar de maneira moi diferente, por exemplo, o uso de RFC para buscar aportes e xerar consenso, o uso de ADR para rexistrar decisións e facer execucións en detalle.

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Portal InnerSource

Patlet

os/as contribuidores/as potenciais non poden descubrir dun xeito sinxelo os proxectos InnerSource nos que están interesados/as. Ao crear unha intranet que indexe toda a información dispoñible do proxecto InnerSource, permítese que os/as contribuidores/as coñezan os proxectos que lles poderían interesar; do mesmo xeito que lles serve aos/ás project owners de InnerSource para atraer a un público externo.

Problema

Os equipos do proxecto InnerSource teñen dificultades para atraer contribucións externas.

Os proxectos InnerSource da súa organización están en aumento, pero os/as posibles contribuidores/as non poden descubrilos dun xeito sinxelo.

Historia

Está tentando establecer unha práctica InnerSource dentro da súa organización. Coñece algúns proxectos que se executan mediante un modelo InnerSource, pero a súa existencia só se comunica a través do boca en boca, o correo electrónico ou conversas privadas con outros/as empregados/as. Como resultado, os/as project owners de InnerSource teñen dificultades para atraer os/as contribuidores/as.

Non hai un recurso de acceso único e compartido para os/as empregados/as de toda a organización que lles permita descubrir facilmente todos os proxectos InnerSource en curso. Isto está a limitar dun xeito importante o potencial de crecemento de cada proxecto InnerSource.

Que se pode facer para axudar a que todos os proxectos de InnerSource eleven a súa visibilidade a un público tan grande como sexa posible e poidan atraer contribuidores/as de toda a organización?

Contexto

• A súa organización está interesada en adoptar un estilo de traballo InnerSource.

• Os/As project owners de InnerSource buscan unha forma de atraer público aos seus proxectos. Non obstante, están limitados/as polas canles de comunicación dispoñibles a través das cales poderían facer publicidade ante posibles contribuidores/as.

• O número de proxectos InnerSource na súa organización está aumentando.

• O agravante deste problema é o feito de que a aplicación compartida en uso, de xestión de control de fontes, ten capacidades de busca tan limitadas que, ata para os/as desenvolvedores/as que buscan proxectos InnerSource, resulta frustrante localizalos.

Requisitos previos

• Os/As directivos/as aceptan de maneira tácita que os/as seus/súas empregados/as participen nos proxectos InnerSource.

• Está en uso un sistema compartido de xestión de control de fontes que proporciona acceso programático aos contidos dos repositorios que aloxa.

• Existe un departamento dentro da súa organización coa responsabilidade de promover a colaboración InnerSource.

Aspectos que mellorar

• Non se está a conseguir todo o potencial de equipos separados de enxeñaría para colaborar en desafíos compartidos.

• É difícil que os individuos descubran que proxectos InnerSource existen.

• É difícil para os/as project owners de InnerSource atraer un público de contribuidores/as externos/as.

Solucións

É necesario crear unha web de intranet do portal InnerSource na que os/as project owners de InnerSource poidan anunciar facilmente a dispoñibilidade dos seus proxectos.

As propiedades chave do portal poden ser:

• As persoas visitantes do portal InnerSource deberían poder ver todos os proxectos dispoñibles e buscar proxectos específicos en función de varios criterios, como o nome do proxecto, as tecnoloxías en uso, os nomes dos contribuidores/as, a área empresarial patrocinadora etc.

• A información que se mostra a través do portal InnerSource debe estar baixo o control total dos project owners de InnerSource en todo momento. E, preferiblemente, esta información obterase directamente dun ficheiro de datos específico ou de metadatos almacenados no propio repositorio do proxecto.

• Os/As project owners deben incluír toda a información relevante sobre os seus proxectos nos ficheiros de datos; e engadir o nome do proxecto, os nomes dos trusted contributors, unha breve descrición e ligazóns ao repositorio de código ou calquera documentación do soporte.

• (Opcional) Aínda que a meirande parte das organizacións escollerá facer o seu portal dispoñible só na súa intranet, algunhas outras optaron por deixalo dispoñible na internet pública. Esta última opción pode ser interesante para as organizacións que queiran mostrar información adicional sobre o seu enfoque InnerSource no seu portal; por exemplo, con fins corporativos e de contratación.

No lanzamento do portal debe terse en consideración unha campaña de comunicación que promova a suma de ficheiros InnerSource de datos ou metadatos aos repositorios de código, para reforzar o número de proxectos que se mostran no portal.

Unha implantación de referencia dun portal InnerSource está dispoñible en GitHub e aberta ás contribucións. Enumera todos os proxectos InnerSource dunha organización dun xeito interactivo e fácil de usar. Os proxectos poden autorrexistrarse a partir dun tema dedicado de GitHub e proporcionar metadatos adicionais.

Contexto resultante

• O portal InnerSource permitiulles aos/ás project owners anunciar os seus proxectos a toda a organización. Debido a esta maior visibilidade, están a atraer comunidades de contribuidores/as moito máis grandes que nunca antes.

• Para aqueles/as que buscan involucrarse en proxectos InnerSource, o portal InnerSource permitiulles descubrir exactamente o tipo de oportunidades que lles interesan ou poder buscar de maneira simultánea entre todos os proxectos InnerSource dispoñibles, en función dos seus criterios específicos.

• Satisfacer as necesidades destes dous tipos de audiencia axudou a establecer InnerSource como unha opción viable e atractiva para que todas as áreas da organización poidan chegar a logros comúns que non poderían alcanzar por separado.

Exemplos coñecidos

• Unha grande organización de servizos financeiros empregou a creación dun portal InnerSource para ofrecer un mecanismo de publicidade e descubrimento de proxectos InnerSource existentes en diferentes áreas empresariais.

• SAP promove proxectos InnerSource no portal InnerSource: Os proxectos poden autorrexistrarse usando temas de GitHub. A cualificación da actividade do repositorio define a orde predeterminada dos proxectos InnerSource no portal. Podes ver tamén Michael Graf & Harish B (SAP) at ISC.S11 - The Unexpected Path of Applying InnerSource Patterns [A senda inesperada na aplicación de modelos InnerSource]. A súa base de código publícase como implantación de referencia e está aberta a contribucións.

• Elbit Systems usou este modelo e engadiulle gamificación.

  • Gamificación como medio de cambio cultural e potenciador de compromiso InnerSource | Shelly Nizri | OSCON 2018: Portland, Oregon.

  • De islas, monstros e InnerSource (presentación), (vídeo) | Cume InnerSource primavera de 2019 (Galway, Ireland).

  • O código desta plataforma era de software libre.

• American Airlines promove proxectos InnerSource a través dun Marketplace InnerSource interno. Do mesmo xeito que SAP, os proxectos autorrexístranse engadindo InnerSource como tema de GitHub. Os proxectos pódense buscar e filtrar por idioma, temas, número de incidencias abertas etc.

• Banco Santander creou un portal público chamado «Santander ONE Europe InnerSource Community» para dar soporte e mellorar a adopción de InnerSource. Ademais do catálogo de proxectos, o portal inclúe contidos relevantes como documentación, forma de traballar, noticias e eventos.

• Airbus implantou o portal SAP con pequenas modificacións para que coincida coa identidade gráfica de Airbus. Ademais, o/a indexador/a de Python foi parcheado para funcionar con exemplos de GitHub Enterprise.

• Mercado Libre emprega o portal SAP para descubrir os proxectos InnerSource que existen na organización.

Referencias

• Probouse que o modelo do portal InnerSource funciona moi ben co modelo InnerSource de Gig marketplace neste contexto.

Estado

• Estruturado

Autoría

• Stephen McCall

Recoñecementos

• Shelly Nizri

• Melinda Malmgren

• Michael Graf

• Jesús Alonso Gutierrez

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Title

Requisitos comúns

Patlet

o código común dun repositorio compartido non satisfai as necesidades de todos os equipos do proxecto que desexan empregalo; isto resólvese mediante a aliñación de requisitos e a refactorización.

Problema

O código común do repositorio compartido non satisfai as necesidades de tódolos proxectos que queren empregalo.

Contexto

• Moitos proxectos están tentando empregar un código común. Tódolos proxectos teñen acceso a un repositorio compartido.

• Alguén (ou algún proxecto) escribe o código desde o principio e apórtao ao repositorio.

• O código común é unha pequena porcentaxe da entrega global de calquera dos proxectos.

• Cada proxecto ten o seu propio calendario de entrega, o seu propio conxunto de entregables e os/as seus/súas propios/as clientes/as.

• Este modelo aplícase en calquera destas situacións:

  • Existe un/unha propietario/a do código sólido; de modo que tódolos cambios no repositorio compartido deben ser aprobados por el/ela.

  • A propiedade do código é débil, polo que ninguén é o/a propietario/a do código realmente.

  • Non hai un/unha patrocinador/a benévolo/a, polo que ningunha organización ou executivo/a proporciona recursos para organizar o código común á maneira InnerSource.

Aspectos que mellorar

O proxecto que fixo que o código estivera dispoñible ten certas necesidades, similares ás de parte da organización receptora, pero non exactamente as mesmas. Os requisitos do código han de derivarse das necesidades reais do/a cliente/a.

As necesidades dos/as distintos/as clientes/as adoitan ser bastante similares; con todo, poden expresarse de maneira diferente ou ponderarse de distinto xeito entre uns/unhas clientes/as e outros/as. Un exemplo podería ser que algúns/algunhas clientes/as queren que un resultado se presente dunha maneira, mentres que outros/as queren que se presente na orde contraria. É sinxelo facer a tradución entre eles/as, pero require codificación adicional para un dos casos e, como resultado, o compoñente que computa o resultado non pode ser reempregado para ambos/as clientes/as.

Moitos/as clientes/as queren que o/a provedor/a lles axude no que precisan. A empresa ten moitos/as enxeñeiros/as de sistemas que redactan os requisitos para os produtos. Suponse que estes requisitos foron extraídos das necesidades do/a cliente/a para guiar o desenvolvemento do produto. Reempregar o código é un obxectivo importante para aforrarlle tempo e diñeiro á empresa.

Solución

Hai dous aspectos que deben facerse en paralelo para resolver este problema:

1. Aliñar os requisitos dos proxectos para que o código que cumpra os requisitos dun proxecto tamén cumpra as necesidades dos demais proxectos.

2. Refactorizar o código en fragmentos máis pequenos para que os numerosos proxectos que o empregan poidan poñerse de acordo acerca dos requisitos.

Ademais, aproveite que os/as clientes/as esperan que o/a provedor/a axude a dilucidar os requisitos. Consiga a aliñación dos requisitos durante as negociacións cos/coas clientes/as e inflúa nos requisitos do/a cliente/a na contra de cambiar o compoñente.

No exemplo presentado anteriormente, o/a provedor/a axuda a ambos/as clientes/as a darse conta de que queren o mesmo e aforraralles esforzo (e diñeiro) a todos/as se se poñen de acordo á hora de elixir o resultado no mesmo formato.

Contexto resultante

Para isto podería ser necesario negociar os cambios nos requisitos co/coa cliente/a. Os cambios tamén poden requirir a participación dos equipos de ventas e dos/as xefes/as de produtos para conseguir a aliñación cos requisitos. O/A cliente/a pode necesitar incentivos, como descontos, para aceptar os cambios.

Un reto relacionado (e un posible modelo novo) é un exercicio circular de redacción de historias de usuario/a do que se informa nunha empresa que emprega InnerSource. En poucas palabras:

• Os/As desenvolvedores/as escriben unha historia de usuario/a para resolver un problema dunha maneira.

• Os/As directivos/as do programa reescriben a historia de usuario/a para expresar mellor as súas necesidades, mantendo a mesma esencia. No momento no que regresa ás mans dos/as desenvolvedores/as, estes/as non recoñecen o que querían facer nun primeiro lugar e, por tanto, resístense a poñelo en práctica.

• A solución a este modelo é contar con máis asentos arredor da mesa de planificación para que as modificacións da historia de usuario/a se entendan en todo o proxecto, non só no grupo dos/as desenvolvedores/as ou directivos/as de programas.

Exemplos coñecidos

• Gran provedor/a de telecomunicacións

Estado

• Estruturado

Autoría

• Roberto Hanmer

Recoñecementos

• Manrique López

• Daniel Izquierdo

• Tim Yao

• Sebastian Spier

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro

Misión

Esta sección debe conter unha descrición breve (de entre tres e cinco liñas) na que se describe a misión do seu proxecto. O obxectivo é indicar en que planea traballar e axudar os/as contribuidores/as externos/as a comprender que tipos de funcionalidades serán benvidas neste proxecto.

Véxase tamén o capítulo de definición da en produción de software libre.

Comezo

Esta sección debe conter documentación breve escrita para os/as novos/as usuarios/as, sobre como comezar a usar o proxecto. Pódese vincular documentación máis detallada desde aquí.

Máis información

Esta sección pode enumerar calquera ou cada un dos seguintes aspectos:

• Unha listaxe de funcionalidades, casos de uso que aborda o software.

• Información sobre os principios de deseño que se utilizan para resolver as contradicións.

• Ligazóns á documentación adicional a nivel de usuario/a.

• Respostas a preguntas frecuentes (FAQ), preferiblemente nun formato que permita vincular preguntas específicas máis as súas respostas para facilitar a súa consulta.

Axuda

Esta sección debe conter unha breve documentación sobre a maneira de obter axuda para o proxecto como persoa usuario/a. Isto podería ser tan simple como dirixir ás persoas aos/ás usuarios/as ao sistema de seguimento de incidencias se así é como lle gustaría responder as preguntas relativas ao proxecto. Tamén podería indicar unha canle de chat arquivada na que se poidan realizar buscas, algunha listaxe de correo arquivada na que se poidan realizar buscas ou algún foro de usuarios/as en liña.

Familiarización

Esta sección debe incluír información breve sobre como entrar en contacto co proxecto; polo xeral, este apartado contén as ligazóns ás canles de comunicación arquivadas e de busca.

Quen somos

Este é un bo lugar para dar crédito aos/ás trusted committers do proxecto.

Tamén é a sección na que incluír información sobre o que significa ser un/unha trusted committer no proxecto, aínda que o ideal é que todos os proxectos dunha organización empreguen a mesma definición, á cal pode acceder só mediante unha ligazón neste apartado. A razón de poñer aquí a ligazón é que, deste xeito, os/as compañeiros/as que teñen pouca ou ningunha experiencia traballando ou contribuíndo en proxectos InnerSource contan cunha canle directa á información dos proxectos tecnolóxicos da empresa que precisan para o seu traballo diario.

Contribucións

Nesta sección debe documentar (ou incluír unha ligazón á documentación) aqueles aspectos que calquera novo/a contribuidor/a precisa saber para comezar. Polo xeral, non se cubrirán todos os temas seguintes. Céntrese naquilo que difire no seu proxecto respecto da configuración estándar, así como naquilo que lles resultou difícil de entender aos/ás contribuidores/as anteriores.

• Atopar o código fonte.

• Atopar unha listaxe de incidencias coas que o seu proxecto precisa axuda que pode ser técnica ou non. Polo xeral, os/as contribuidores/as poden acceder a través dun sistema de seguimento de incidencias.

• Ligazóns á documentación adicional, por exemplo, sobre a arquitectura do proxecto, convencións xerais de codificación, convencións de proba...

• Para contribucións técnicas: Facer cambios, construír o proxecto e probar os cambios.

• Enviar os cambios ao proxecto.

Tamén incluirá información sobre como é o proceso preferente para os cambios no proxecto: os/as contribuidores/as deberían primeiro abrir unha incidencia e enviar unha proposta, ou son benvidos/as a enviar os cambios directamente? Que é importante para vostede á hora de revisar as contribucións?

Ademais, debe describir os valores de deseño que desexa seguir no proxecto. Facelos explícitos adoita axudar a resolver as contradicións con maior rapidez e facilidade. Ademais, axuda a facer transparentes os cambios en supostos, que doutro xeito, estarían implícitos.

Co tempo notará que esta sección crece substancialmente. Nese caso, pense en trasladar a información a arquivos separados, por exemplo, a CONTRIBUTING.md e TESTING.md.

Prototipo de modelo

Título

Engadir un título curto

Descrición do caso

Descrición concisa de entre unha ou dúas liñas na que se expón o problema e a solución. Os/As lectores/as poden revisar de maneira rápida ducias destas descricións de casos e navegar pola libraría de modelos.

Problema

Cal é o problema? Neste apartado definirase o problema de maneira concisa; breve descrición, xeralmente non máis dun par de liñas, que explique cales son os problemas e os desafíos. Teña coidado con non mesturar a información que se atopa nas seccións seguintes.

Historia (opcional)

Ás veces hai un caso particular que permite comprender mellor o modelo.

Contexto

Onde está o problema? Cales son as circunstancias previas? É importante describir cales son os aspectos inalterables antes de que a solución se poña en marcha. O contido que aquí se describe, a miúdo, está vencellado á aplicación do modelo para outros/as usuarios/as que se pregunten: «É esta unha a situación semellante á miña?».

Aspectos que mellorar

Que dificulta o problema? Cales son os sacrificios? Neste apartado, abórdanse as limitacións que poden cambiar a un certo custo. A solución podería mudar un ou máis destes impedimentos co obxectivo de resolver o problema, o cal tamén afecta o contexto.

Exemplo ilustrativo (opcional)

Ilustración visual.

Solucións

Resolucións verificadas e posibles solucións ao problema.

Contexto resultante

Cal é a situación resultante unha vez que se resolve o problema? O contexto orixinal cambia de xeito indirecto unha vez aplicada a solución. A miúdo, esta sección pode incluír a discusión dos posibles modelos/problemas presentados a continuación. O contido deste apartado pode ser breve, pois é posible que a solución non presente novos problemas nin modifique moito o contexto.

Fundamento (opcional)

Nesta sección explícase o motivo polo cal unha solución concreta é a axeitada; empréganse outras palabras para explicar a razón pola que esa solución equilibra eses aspectos que se precisan mellorar co contexto, co fin de resolver o problema. Esta sección poderíase ampliar segundo outros posibles escenarios ou teorías.

Exemplos coñecidos (opcional)

Onde se aplicou o modelo antes? Esta sección axuda a reforzar a idea de que se trata dun modelo REAL e que coincide co contexto.

Pode facer referencia a:

• Un negocio en concreto.

• Casos anónimos, por exemplo: «Tres empresas demostraron que esta é unha boa solución» ou «a grande organización de servizos financeiros...».

Estado (opcional ata a integración)

O estado xeral do modelo almacénase no sistema de etiquetaxe de GitHub; consulte aquí calquera pull request. Teña en conta que o sistema de etiquetaxe de GitHub se fai menos visible unha vez que o modelo se remata e se integra, polo que é útil contar con información neste eido.

Tamén pode almacenar outra información de interese neste apartado, como un historial de revisión, por exemplo: «Tres de nós revisamos isto o 5/2/17 e precísase dos coñecementos especializados de John antes de que se poida continuar».

Autoría (opcional)

En moitos casos, vostede mesmo/a pode formar parte da autoría. Se é necesario, procure alguén en InnerSource Commons para que sexa o/a autor/a nominal (tal e como se explicou anteriormente). Tamén podería manter o anonimato no caso de que non queira asumir a autoría (algo común cando se emprega un donut para procurar unha solución).

Recoñecementos (opcional)

Inclúa aquelas persoas que axudaron a desenvolver este modelo; tanto para a atribución como para un posible seguimento futuro. Aínda que é opcional, a maioría dos modelos deben citar as persoas que contribuíron na súa creación.

Título alternativo (opcional)

No caso de que o modelo tamén se coñeza cun nome distinto ao que amosa o Título, enumere eses títulos alternativos aquí. Por exemplo, nos casos nos que o modelo leve o nome do problema que está a resolver, un alias útil podería ser aquel que describa a solución que se vai aplicar.