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.

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

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.

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

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

• 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

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.