Infraestrutura

A infraestrutura é un dos puntos chave de InnerSource. Proporciona as ferramentas necesarias para o desenvolvemento e a comunicación entre equipos.

O equipo de desenvolvemento, os mandos intermedios e a dirección forman parte do mesmo proceso, que require dun cambio de mentalidade para pasar a formar parte dun proceso máis achegado ao empregado no software libre. E haberán de ser capaces de aceptar as novas regras do xogo.

Xa que InnerSource fomenta a emprega dalgúns dos principios de desenvolvemento das comunidades de software libre, as comunidades InnerSource precisan dun cambio cultural no que a comunicación aberta e a transparencia no proceso de toma de decisións sexan vitais.

Así pois, a infraestrutura seleccionada debe ser aberta e transparente, e facilitar aos/ás desenvolvedores/as o cumprimento dalgunhas pautas específicas como os procesos de revisión de código. Isto tamén debería axudar a evitar imprevistos. Cada contribuidor/a dunha nova infraestrutura deberá seguir as mesmas regras, mais haberá diferenzas no nivel de acceso permitido; por exemplo, entre as novas incorporacións e quen xa está a presentar commits.

Ademais, esta infraestrutura debe ser sinxela seguindo o enfoque KISS (polas súas siglas en inglés, Keep It Short and Simple, facer algo curto e doado) para diminuír a barreira de acceso de novos/as contribuidores/as. Canto máis fácil sexa o proceso, máis atractivo resultará para quen queira facer a súa primeira contribución a algunha das fontes de datos.

Nas comunidades de software libre ocorre o mesmo; polo xeral é preciso contar cunha subscrición para algunhas das ferramentas, como poden ser as listaxes de correo ou as wikis. Unha vez obtida, xa se poden facer actualizacións das wikis ou enviar correos electrónicos. No caso do código fonte, o proceso foise burocratizando a medida que a revisión do código foi cobrando importancia.

Con todo, webs como GitHub e GitLab proporcionan acceso ao código fonte, ás incidencias, ás pull requests e á edición das wikis mediante unha única conta. As comunidades que empregan esta infraestrutura adoitan contar cun modelo de gobernación no que calquera cambio deberá ser revisado polo/a trusted committer.

En InnerSource existen algúns aspectos chave que cómpre ter en conta. Estes están vencellados principalmente aos atributos de accesibilidade e transparencia, mais tamén deben ser arquivables, localizables e sinxelos no uso e na minería de datos.

• Accesibilidade: Todas as ferramentas empregadas no proceso de desenvolvemento de software deben ser accesibles para calquera persoa da organización. Isto permite xerar confianza entre os/as desenvolvedores/as e reduce as barreiras para calquera que queira contribuír nos proxectos InnerSource. Deste xeito, tódalas contribucións son benvidas e estas poden vir de calquera.

• Transparencia: Co foco na autoría das distintas contribucións. Desde o mesmo proceso de envío do código, ata a corrección de erratas, todo debe quedar rexistrado, incluída a autoría de cada contribución ou cambio realizado. Isto axuda a identificar aos/ás principais contribuidores/as da comunidade, pois co tempo pasarán a conformar o equipo principal da devandita comunidade. Como non tódalas contribucións son ao código, a autoría debería axudar a comprender as doutros tipos; como a documentación, as mentorías ou a resolución de dúbidas nos foros a outros membros. Todas estas son actividades de interese nas comunidades InnerSource.

• Arquivable: As ferramentas deben xerar un rexistro no que se garde a información de accións previas. Isto será de grande axuda en relación a fragmentos concretos do código, para solucionar discusións técnicas nas canles de comunicación ou na toma de decisións durante os cumios de deseño. Tamén servirán como referencia.

• Localizable: A medida que máis proxectos se suman a InnerSource, a cantidade de repositorios de información crecerá de igual xeito. É importante dispor de capacidades de busca dentro da plataforma. Isto axudará a reutilizar e descubrir proxectos e contribuidores/as útiles para os nosos propósitos. Tamén será de axuda saber se existen outros proxectos que cubran as súas necesidades específicas.

• Fácil de minar: O conxunto de ferramentas seleccionado debería ser sinxelo de minar. Podería tratarse dunha ferramenta externa que mine calquera fonte de datos dispoñible e constrúa áreas específicas do proceso de desenvolvemento de software ou podería proporcionala a propia estrutura. Isto será útil para que a comunidade entenda onde se atopan os puntos de conxestión no proceso, mais tamén axudará a detectar posibles problemas, bloqueos ou calquera outra situación non desexada. Tal e como se explicará máis adiante, no capítulo dedicado ás métricas, os datos desempeñan un papel fundamental na aplicación de InnerSource. Permiten comprender cara onde se dirixe todo o proceso; así como tomar decisións cando sexa necesario co obxectivo de seguir na dirección correcta. Para isto, serán tamén de importancia as ferramentas que permiten recuperar información a través dunha API (como GitHub API) ou grazas a un sistema de log (como a liña de comandos «git log»).

• Dereitos de acceso: Ao existir un proceso aberto e transparente para tomar decisións que fomentan a participación, merece a pena empregar unha infraestrutura que limite o acceso a determinados roles dentro da organización. Calquera está convidado/a a participar, pero só un subconxunto de contribuidores/as terá dereito a enviar os fragmentos de código fonte ou editar as wikis de documentación. A infraestrutura debe permitir esta división de roles. Deste xeito, calquera poderá ler a documentación, pero só algunhas persoas terán permiso para escribir.

É probable que estes aspectos resulten familiares, posto que son chave á hora de poñer en marcha unha infraestrutura nos proxectos de software libre. Dous grandes libros falan desta circunstancia. Producing Open Source Software [Produción de software en código aberto] de Karl Fogel e The Art of Community [O arte da comunidade] de Jono Bacon. O primeiro céntrase nas necesidades básicas dunha infraestrutura de proxectos de software libre establecida desde cero. O segundo, pola súa parte, pon o foco en como dar sorporte específico aos fluxos de traballo coas ferramentas. Ambos proporcionan unha excelente perspectiva sobre os proxectos de software libre que é tamén parcialmente aplicable en proxectos InnerSource.

Tal e como declara Jono no seu libro: «para elixir as ferramentas axeitadas, primeiro temos que saber que queremos conseguir. Temos que saber cal é o noso fluxo de traballo.».

A seguinte sección céntrase nas necesidades da infraestrutura ao iniciar un proxecto InnerSource. Non existen grandes diferencias desde o punto de vista dos aspectos chave. Non obstante, temos que lidar coa infraestrutura existente, interna e, en moitos casos, de acceso restrinxido, e comprobar se a devandita infraestrutura é suficiente para os nosos propósitos e obxectivos da posta en marcha de InnerSource.

Polo tanto, haberá dúas áreas principais a considerar; en primeiro lugar, se é posible reutilizar a infraestrutura existente e, en segundo lugar, que ferramentas están dispoñibles que se axusten aos nosos requisitos chave no caso de necesitar unha nova infraestrutura.