Ecossistemas baseados em software aberto

Um caminho específico para o estabelecimento de um SECO pode ser efetuado através da utilização de software aberto como suporte tecnológico para a plataforma do SECO. Os termos software aberto, software livre, ou software open source, podem, à primeira vista, parecer uma referência simples ao software enquanto programa ou conjunto de instruções a serem executadas por um computador. No entanto, estas designações acarretam consigo um contexto também específico, que inclui as comunidades que desenvolvem o software e as formas de organização social, legal e de negócio, próprias deste modelo de desenvolvimento de software (Raymond, 1999).

O software aberto ou Free/Libre/Open Source Software (FLOSS) tem-se estabelecido como uma plataforma promissora para ecossistemas de software, nas suas mais diversas facetas (técnicas, metodológicas, legais, comerciais, etc), levando a que cada vez mais empresas adiram a este paradigma de software aberto e baseiem os seus ecossistemas de software em plataformas abertas. Sendo esta tendência relativamente recente, ainda há pouco trabalho desenvolvido sobre como criar e manter um ecossistema de software aberto sustentável, a partir de software proprietário. Tão pouco estão estabelecidas as melhores práticas sobre como as diferentes facetas de uma plataforma de software aberto devem ser tidas em conta no estabelecimento de um ecossistema viável (Lundell et al., 2009).

Assim, no âmbito da análise do estabelecimento de um SECO, é interessante abordar estes vários aspetos, para melhor compreender a forma como a utilização de software aberto condiciona e modela um SECO nas suas várias dimensões.

4.3.4.1 Contexto de utilização de software aberto

Conforme já referido, um SECO assenta numa plataforma de software, utilizada por um conjunto de participantes, que a estendem, introduzindo inovação, desenvolvendo produtos,

Capítulo 4 – Ecossistemas de software

107

e repartindo os custos e benefícios deste investimento conjunto. A opção pelo software aberto pode ser considerada em contextos distintos:

 Utilização de produtos de software aberto como peças para a construção da plataforma de um SECO;

 Criação da plataforma de um SECO como um produto em software aberto;

 Conversão de um produto (ou linha de produtos) fechado num produto aberto.

A utilização de produtos de software aberto, como peças para a construção da plataforma de um SECO, permite a construção rápida de uma plataforma, ou partes dela, sem grandes custos iniciais e beneficiando da transparência de desenvolvimento inerente a produtos desenvolvidos em software aberto. De facto, podem ser construídos sistemas complexos a partir da composição inteligente de peças em software aberto disponíveis. Esta opção pressupõe uma adesão à comunidade que desenvolve, suporta e utiliza o respetivo produto em software aberto (Walton, 2002).

A criação da plataforma de um SECO como um produto em software aberto, ou a adoção deste modelo para um produto anteriormente fechado, pressupõe o desenvolvimento do SECO em torno da comunidade de software aberto da respetiva plataforma, vem como a responsabilidade de desenvolver e gerir a comunidade (Kilamo, Hammouda, Mikkonen, & Aaltonen, 2012).

As comunidades de software aberto podem ser consideradas como ecossistemas sociais, com a particularidade de se estruturarem de acordo com uma hierarquia ditada pelo contexto da engenharia de software, em contraponto com a generalidade dos ecossistemas sociais, que normalmente apresentam estruturas planas. No contexto da engenharia de software, uma comunidade de software aberto é estratificada de acordo com o papel que cada participante desempenha no desenvolvimento e no projeto de software. O desenvolvimento de uma plataforma em software aberto pressupõe então a responsabilidade de fazer crescer e manter a comunidade associada a essa plataforma. Estas comunidades podem ser representadas por modelos estratificados em forma de cebola, com os elementos mais influentes no centro e os outros em camadas mais periféricas, de acordo com uma escala decrescente de influência (Kilamo et al., 2012).

Um modelo muitas vezes referido na literatura é o proposto por Nakakoji et al. (Nakakoji, Yamamoto, Nishinaka, Kishida, & Ye, 2002), que parte do estudo dos sistemas per si, para analisar, numa perspetiva mais abrangente, a evolução das comunidades associadas e

relação entre a evolução dos sistemas e a evolução das respetivas comunidades. A Figura 22 - Modelo de comunidades de software aberto, representa este modelo com as respetivas camadas. No centro encontra-se o líder de projeto – Project leader, que terá iniciado o projeto e será um dos elementos mais ativos na comunidade. A segunda camada compreende aos elementos nucleares do projeto – Core member, que num projeto de software aberto típico, são um pequeno grupo, que começa com três a quatro membros e cresce até dez a quinze membros (Gloor, 2005). Este grupo que participa no projeto durante um período muito significativo da sua vida, coordenando-o e contribuindo com muito do código. As camadas subsequentes são constituídas por grupos maiores, culminando na camada dos utilizadores passivos do produto de software – Passive user. Com número diferente de membros e com graus de participação distintos, todos estes elementos, nas várias camadas são essenciais para a sustentabilidade da comunidade.

Figura 22 - Modelo de comunidades de software aberto, adaptado de Nakakoji et al. (2002)

O modelo proposto por Nakakoji é uma perspetiva apenas sobre a comunidade ligada ao produto de software aberto. Na perspetiva mais abrangente de um ecossistema baseado em software aberto, devem ser também incluídos outros elementos, como sejam, parceiros de negócios, grupos de interesse, etc. De facto, criar e manter uma comunidade sustentável de software aberto é um processo complexo que pode ser influenciado por inúmeros fatores (Nonnecke, Andrews, & Preece, 2006; Paredes & Martins, 2007; Preece, 2000).

Para a conversão de uma plataforma proprietária num produto de software aberto, e evolução para um SECO baseado em software aberto, é necessário compreender os fatores que podem

Capítulo 4 – Ecossistemas de software

109

influenciar este processo de conversão. Kilamo propõe uma perspetiva em que se agrupam, em seis dimensões, os fatores que podem influenciar o processo: software; comunidade; processo; legalidade; marketing; e infraestrutura (Kilamo, Aaltonen, Hammouda, Heinimäki, & Mikkonen, 2010).

Figura 23 - Dimensões da construção de uma comunidade (Kilamo et al., 2012)

Com base nesta perspetiva (Figura 23), é proposta a framework OSCOMM, composta por um conjunto de boas práticas e de um elemento central, que é um processo para a criação de um ecossistema de software aberto a partir de um produto ou linha de produtos de software proprietário (Kilamo et al., 2012).

A framework OSCOMM propõe três fases:

1. Avaliação da prontidão do projeto (Release Readiness Rating) para transitar para um modelo de software aberto;

2. Transição para software aberto (Open Source Engineering) do produto de software, com base na avaliação efetuada na fase anterior;

3. Medição (Community Watchdog) do ecossistema após a transição para software aberto.

A Figura 24 - A framework OSCOMM, ilustra as três fases do processo, bem como as atividades necessárias à execução de cada fase.

Figura 24 - A framework OSCOMM (Kilamo et al., 2012)

A avaliação da prontidão do projeto para transitar para um modelo de software aberto permite identificar possíveis obstruções ao processo de transição e delinear um plano de ação que culmine com a edição (release) do software em modo de software aberto. Este plano de ação irá ser executado na segunda fase do processo, em que se resolvem as obstruções identificadas através da reengenharia do produto de software, transformando num produto em software aberto e redefinido o papel que a comunidade que suporta o produto irá ter no futuro e como deverá evoluir. Esta comunidade deverá nascer a partir da comunidade restrita já existente à volta do produto e será da sua responsabilidade a decisão do momento de publicação do produto. No final desta segunda fase, ter-se-á um produto em software aberto com a respetiva comunidade de suporte. A terceira fase corresponde ao período pós nascimento do produto, em que se mantém alguma monitorização da comunidade de suporte, que, num contexto de software aberto, passa a ter um papel preponderante no desenvolvimento do produto. A empresa que originou a publicação do produto e a criação da comunidade de suporte passa agora a ter um papel de condução ou orientação da comunidade, de acordo com a informação de monitorização que for sendo recolhida na terceira fase.

Após a consolidação da terceira fase, pode-se concluir que foi criado um ecossistema de software a partir de um produto fechado, anteriormente detido por uma empresa.

O sucesso da aplicação de uma abordagem semelhante à proposta pela framework OSCOMM depende grandemente da capacidade de atrair membros para a comunidade que suportará o sistema de software, sendo por isso particularmente eficaz quando o sistema de software for uma plataforma que proporcione níveis elevados de personalização através de configuração e adaptação a diferentes contextos de utilização. Um exemplo comum é a externalização do desenvolvimento da plataforma de software, de uma linha de produtos, através da inclusão de programadores e outros parceiros externos (Bosch, 2009; Bosch & Bosch-Sijtsema, 2010).

Capítulo 4 – Ecossistemas de software

111

Nesta framework, um elemento essencial para o seu sucesso é a transformação da comunidade restrita de interessados, que existe em torno do produto proprietário, numa comunidade de software aberto, em moldes semelhantes aos propostos por Nakakoji. Assim, vale apena analisar esta transformação com maior detalhe. Kilamo propõe que a partir do conjunto de interessados (stakeholders) do produto proprietário se crie uma comunidade aberta, tendo o cuidado de balancear as forças de cada interessado, de forma que a todos seja garantido um nível de satisfação mínimo. Deve-se também ter em consideração outros aspetos que possam comprometer o sucesso da comunidade, como sejam, normas sociais e matérias legais.

Figura 25 - Comunidade do ecossistema

A Figura 25 - Comunidade do ecossistema, representa forma como a comunidade, emergente da aplicação da framework, se organiza em três camadas. A camada central, composta pela entidade ou empresa responsável pela abertura do software e pelos seus programadores que programam o software; a segunda camada, composta pelos parceiros industriais que utilizam o software e também contribuem para a sua programação; e a terceira camada, composta por uma comunidade mais vasta ou até por várias comunidades setoriais, elas próprias organizadas de acordo com o modelo de Nakakoji e que utilizam e contribuem para o ecossistema. Um ecossistema de software, visto nesta perspetiva, da comunidade que o suporta, pode conter várias subcomunidades focadas em subprojectos específicos.