Escenarios

Onde se emprega a metodoloxía InnerSource? Que tipo de compañías xa a están a empregar?

No ano 2000, Tim O’Reilly definiu InnerSource como «o uso de técnicas de desenvolvemento de software libre dentro dunha corporación». Evidentemente, esta definición aplicase tanto ás compañías que desenvolven software para o seu uso propio, como para outros.

Algunhas técnicas comúns para o desenvolvemento de software libre son:

• Desenvolvemento transparente: Calquera pode revisar e contribuír.

• As forks son benvidas: Xeralmente, a innovación vese impulsada por novas ideas que xorden de proxectos existentes.

• Equipos diversos: Xente de tódalas partes do mundo pode contribuír, independentemente do seu xénero, educación ou raza.

• Comunicación transparente: Todo sempre por escrito e debe formar parte do arquivo, desde documentos ata as conversas, para contar cun historial no caso de precisar revisalo.

InnerSource, como o software libre, é idónea para fomentar a colaboración entre organizacións, posto que elimina as barreiras entre diferentes equipos, áreas empresariais e, mesmo, as posibles barreiras xeográficas.

Máis aló do perfil evidente das compañías dedicadas ao desenvolvemento de software, imos ver tamén algúns outros escenarios e situacións en que a emprega de InnerSource pode ser de utilidade.

A onda transformadora dixital

Durante os últimos anos, moitas compañías tiveron que enfrontarse á chamada «transformación dixital», para tornar en compañías . Na actualidade, convertéronse en grandes usuarias das TI e os pasos chave desta transformación estiveron xeralmente definidos por:

• A rotura os silos entre as organizacións (cambio cultural).

• A adopción de novas TI (a nube, big data, móbiles etc.).

A adopción destas tecnoloxías adoita significar que as compañías necesitan crear equipos DevOps competentes. Iso é, «DevOps», se cadra o segundo termo máis relevante nestes últimos anos logo da «transformación dixital».

E os equipos DevOps comparten algunhas características cos equipos de desenvolvemento colaborativo do software libre. Tal e como xa fora descrito por John Willis e Damon Edwards en 2010, o «marco DevOps» correspóndese con CALMS —que (polas súas siglas en inglés) significa Cultura (de colaboración), Automatización, Axilidade, Medición e Uso compartido— e, sen dúbida, contén termos familiares para calquera desenvolvedor/a de software libre.

Estes equipos adoitan desenvolver solucións de software personalizadas mediante receitas de implementación para as súas compañías. Para as pequenas e medianas empresas (PEME), isto podería ser útil e sinxelo de xestionar. Pero que é o que acontece cando a compañía conta con varios equipos DevOps arredor do mundo? Como poden garantir que se comparta o código e o coñecemento en toda a organización?

Xa vimos empresas que afrontaron o mesmo problema con diferentes solucións, por mor da falta de organización transparente entre organizacións, así como de metodoloxías colaborativas.

O mundo dos silos

Nalgúns casos, son os altos cargos corporativos ou unha unidade central da compañía os que deciden a tecnoloxía do resto das áreas de negocio. Cando estas adoptan a tecnoloxía, polo xeral precisan personalizala ata obter algo lixeiramente diferente do produto orixinal. Mentres que a unidade central avanza co seu produto no seu «silo pechado», é moi posible que as outras áreas empresariais estean a facer o mesmo nos seus silos. E cal será o resultado diso? Que o intento de integración de calquera actualización do produto principal vai ser un pesadelo.

Noutros casos, as unidades de negocio pode que se comporten como compañías independentes. Cada unha emprega a súa propia arquitectura TI, o que remata cunha xestión dos recursos ineficiente causada pola multiplicación de tecnoloxías, desenvolvementos etc.

O desenvolvemento colaborativo en ecosistemas de software libre empregouse en máis dunha ocasión como exemplo de que estas metodoloxías permiten romper os silos entre compañías que mesmo poderían ser competidoras de mercado. Esas compañías foron capaces de compartir o seu coñecemento e recursos por unha meta común. Se a competencia pode colaborar para construír a tecnoloxía na que basear os seus negocios, por que as distintas unidades empresariais dunha corporación non poderían facer o mesmo se a súa misión é o éxito corporativo?

A burbulla das start-ups

Moita xente podería argumentar sobre se estamos ou non a vivir nunha «burbulla start-up»; mais non hai dúbida de que nos atopamos rodeados de noticias sobre pequenos grupos de persoas que, mediante roldas de inversión, pasaron dun garaxe a fundar compañías multinacionais en poucos anos.

A nosa experiencia dinos que a apertura de oficinas no estranxeiro sempre é un reto, e a xestión de equipos de desenvolvemento que crecen con rapidez pode ser un problema serio. A falta de canles de comunicación efectivos e transparentes, así como de procedementos de documentación, podería dificultar a incorporación de novo persoal e diminuír o seu compromiso coa empresa.

Por outra banda, as compañías de recente creación xa naceron aproveitando as solucións informáticas existentes para proporcionar servizos omnicanle. Están acostumadas a traballar baixo a «cultura DevOps» e pode que lles resulte máis doado adoptar unha metodoloxía común a toda a organización que permita a transparencia e a colaboración.

Falta de implicación no traballo

Se algún dos escenarios anteriores lle resulta familiar, é posible que a súa implicación no traballo non sexa moi alta. Mais non se preocupe, é bastante habitual. De acordo co World Economic , o 70 % dos/as traballadores/as afirma non sentirse comprometido/a co seu labor profesional.

No mesmo artigo pódese ler que: «Unha investigación da Universidade de California descubriu que cando o persoal está motivado é un 31 % máis produtivo, as súas ventas crecen un 37 % e é o triple de creativo que os membros do persoal sen motivación. E, segundo un estudo do Consello de Liderazgo Corporativo levado a cabo con máis de 50 000 persoas, tamén hai un 87 % menos de probabilidades de que queiran renunciar».

Towers descubriu que as empresas con traballadores/as comprometidos/as producían un 19,2 % máis de ingresos operativos nun ano, pero as compañías cun menor grao de compromiso reducían os seus ingresos operativos nun 32,7 %.

Foi Daniel Pink, no seu libro titulado Drive, quen sostivo que a motivación humana é en gran medida intrínseca. Os aspectos desta motivación pódense dividir en:

• Autonomía, típica dos equipos de desenvolvemento de software libre con capacidade para a autoxestión.

• Mestría ou desexo de perfeccionar as habilidades de desenvolvemento para mellorar o proxecto no que están a participar.

• Propósito, que en moitos proxectos de software libre defínese como a misión.

Estes aspectos son chave para a motivación dos/as desenvolvedores/as de software, xa que as súas tarefas implican habilidades cognitivas, toma de decisións, creatividade ou pensamento de orde superior.