Open source e sua influência no desenvolvimento de software – parte 3

No primeiro post desta série falamos sobre o que é open source no contexto da indústria de software. A segunda parte abordou reflexões acerca dos aspectos da engenharia de software tradicional em comparação com algumas práticas open source. Finalmente, nesta terceira e última parte desta série falaremos sobre a influência open source na economia e as conclusões gerais.

Open Source e seus efeitos na economia

Vemos hoje exemplos de sucesso do open source o sistema operacional Linux e o servidor web Apache [Perens 2005], [Garzarelli 2002], com uma forte adesão de novos usuários. Além disso, estudos apontam crescimento de 37% a 45% em setores relacionados com Linux, com movimentação estimada de U$ 35 bilhões em 2008. [Perens 2005]

Por que grandes empresas como IBM estão participando desses projetos? Uma justificativa plausível é que aborda o impacto do open source na cadeia de valor do software [Taurion 2004]. Ainda segundo o autor, a cadeia de valor é a série de atividades relacionadas e desenvolvidas por agentes produtivos para satisfazer às necessidades do mercado (relações com fornecedores, ciclos de produção, vendas e distribuição dos produtos). Os aspectos dessa cadeia são bastante voltados às formas como os negócios se dão. A IBM percebeu essa mudança na cadeia de valor e está direcionando o seu modelo de negócio na área de desenvolvimento.

Outro fator importante é que as empresas precisam construir novos modelos de negócio para continuar lucrando nesses novos mercados, pois veremos mais adiante que os custos para os usuários estão bem acessíveis, isso modifica o sistema de como explorar o mercado de TI. Alguns vêem open source como uma estratégia uniforme para desenvolvimento de software e um estilo de vida próprio, mas alguns também vêem como um novo modelo de negócio. [Riehle 2007]

Hoje a função econômica do software em um negócio é estrategicamente muito importante conforme abordam a maioria dos trabalhos consultados [Perens 2005], [Riehle 2007], [Taurion 2004]. Nem todas as empresas estão no negócio de manufatura de software. No entanto, sem o software, muitas empresas seriam menos eficientes ou seriam impossíveis de operarem. Como exemplos práticos considerem o planejamento financeiro antes das planilhas de computador, a correspondência antes do e-mail, etc.

Hoje necessitamos de software para fazer o negócio. Qualquer negócio com mais de 50 funcionários é provável empregar serviços de programadores. Os software melhoram a qualidade do produto. O modelo open source criou uma nova forma de relacionamento econômico [Riehle 2007], [Perens 2005], [Taurion 2004]. Uma nova forma de relacionamento peer-to-peer com os clientes do software da empresa. Isso permitiu que participantes do processo se envolvessem diretamente na criação do software open source e assimtornando-se colaboradores.

Havia também novos relacionamentos nas vendas do software em projetos opensource, que competiam em outros setores, mas contribuem em projetos de interesses em comum. Mudanças também no relacionamento do cliente-vendedor: o cliente poderia agora participar com o vendedor no desenvolvimento do software. Assim, muitos vendedores poderiam alcançar agora o mesmo código fonte, e suportar assim o produto, havia menos restrições e menos exclusividades neste relacionamento [Perens 2005].

Especialistas sugerem que as empresas podem usar software open source para fazer crescer suas comunidades de usuários e construir um ecossistema sobre seus produtos e serviços [Riehle 2007]. As instituições financeiras começam a observar o open source como prováveis respostas para necessidades ainda não esclarecidas aos fenômenos presentes, tais como:[Perens 2005] o projeto de passatempo de um estudante – resultou o Linux,influenciando as TI das empresas; A IBM, com sua postura tradicional e conservadora deixando de apostar em seu sistema (IBM AIX) para investir dinheiro em projetos open source aliando-se com programadores, cujo líder não tem nenhum poder, mas conquistou respeito de outros; a Microsoft enfrenta seu primeiro concorrente sério em uma década: os programadores open source que vão afastando seu trabalho. Estes eventos parecem absurdos: certamente não cabem no paradigma econômico tradicional da produção de tecnologia. Um fenômeno econômico novo está operando-se, e para explicá-lo segundo o autor, é preciso olhar mais profundamente na economia da produção do software, os seus impactos.

Por que o custo e preço do software open source é muito mais barato do que software fechado?

Para responder esta pergunta é preciso analisar o modelo fechado, seu custo e preço de venda [Riehle 2007]. No modelo de negócio do software fechado o custo do investimento se dá nas primeiras vendas. O lucro começa a ser adquirido com as vendas sucessivas que serão comercializadas. Custos adicionais de vendas e melhorias do produto são relativamente baixos. Os softwares são geralmente instalados através de CDs ou downloads do produto, e incorporam uma licença de usuário, que garante suporte, etc.

O advento do software open source tem reduzido os custos dos aplicativos para os usuários. Isso está mudando o cenário econômico no ecossistema das negociações do software. [Riehle 2007] Empresas não querem pagar por licenças sem ter certeza que a solução contratada atende suas expectativas. Pode-se observar que existe uma queda no número de clientes dispostos a comprarem esses recursos. Quanto mais baixo for o preço dos produtos mais há interesses na compra destes. Além disso, essas mudanças se refletem principalmente em como algumas empresas estão ofertando seus produtos e serviços para os usuários, através da Integração de Sistemas (IS) [Riehle 2007]. Para haver crescimento desse negócio a empresa que provê uma integração de sistemas precisa ao menos cobrir seus custos. Os preços tendem a ficar mais baixos e como conseqüência mais vendas são realizadas, as margens de lucro se estabilizam se as vendas forem contínuas.

Os sistemas integrados estão sendo vistos como uma perspectiva para manter os lucros usando open source. Os sistemas que provem integração de soluções fazem parte de um conjunto de tecnologias de hardware, software e serviços, que são oferecidos de forma transparente e comercializados como produtos [Rieble 2007].

Observam-se mudanças na forma de distribuir softwares, mudanças na economia e na cadeia de valor do software. No entanto, se for oferecido somente serviços como componentes e API e infra-estrutura, é necessário fazer soluções de software para usar aqueles serviços no dia a dia. Logo, os lucros podem ser afetados se não houver clientes interessados neste negócio. O modelo open source pode contribuir neste sentido. Empresas que provem integração de soluções podem alavancar seus produtos incentivando a comunidade open source a usarem seus serviços, reduzindo o custo das suas soluções. Isso pode incentivar empreendedores e empresas a pagarem o uso dos serviços. A cadeia de valor do software open source está bastante consolidada e estável para os clientes e usuários.[ Riehle 2007] Não é muito fácil repassar o custo de produção hoje em dia para os clientes. Há algumas razões: os clientes tendem a incorporar o produto como um todo, melhor do que em componentes individuais. Isso exige fornecer soluções mais complexas que demandam custos mais altos para as empresas. Há também uma competição muito grande no mercado, no qual é preciso investir constantemente em inovação, não é fácil ficar a frente desses novos mercados. Mas se tratando de sistemas de integrações de soluções open source pode-se manter as margens de lucro.

Nas comunidades de software open source não há barreiras de mercado existentes para efetuar vendas de serviços, manutenção e suporte, desde que tenha uma licença que permita explorar a tecnologia [Riehle 2007]. O mercado é bastante competitivo, a fixação de preço se dá pelo pagamento dos custos. Se os lucros são altos, novas companhias incorporarão esse mercado, se os lucros são baixos as empresas deixarão o mercado. Quanto mais maduro o produto mais baixo será o preço total. Os custos variam de empresa para empresa, em geral, os custos são mais altos nas primeiras unidades porque se espera vender um serviço melhor.

Conclusão
Neste artigo abordamos sobre open source e algumas de suas facetas nas áreas da engenharia de software, nos seus processos de desenvolvimento e alguns reflexos na economia da indústria do software. Grandes empresas, tal como a IBM, está sinalizando que open source não é somente discurso filosófico ou ideológico, mas como uma alternativa viável de exploração de mão de obra qualificada e serviços com custos reduzidos. Nesta conjuntura um novo modelo de negócio desenha uma forma de envolver clientes e usuários em torno do produto, que agora passa a ser construído de forma mais participativa.

[Kubota 2006] demonstra essas tendências aqui no Brasil ao atestar que os modelos de open source terão um grande impacto econômico não apenas na indústria de software, mas na sociedade como um todo. Afirma ainda: “os países e empresas que adotarem tecnologias de fonte aberta terão grande vantagem competitiva, e a sociedade em geral poderá se beneficiar de uma adoção precoce. As tecnologias de fonte aberta representam uma mudança no modelo de comercialização tradicional, e sua maior fonte de receita é representada pelas licenças. No novo modelo, o valor das licenças é nulo ou baixo e as receitas advêm principalmente de serviços, o que pode representar oportunidade para as empresas brasileiras de software”.

Referências

• Perens, B. (2005) The Emerging Economic Paradigm of Open Source, Senior Research Scientist, Open Source, Cyber Security Policy Research Institute, George Washington University.

• Garzarelli, G., (2002), Open Source Software and the Economics of Organization, Università degli Studi di Roma, 'La Sapienza' Dipartimento di Teoria Economica e Metodi Quantitativi per le Scelte Politiche Piazzale Aldo Moro,Rome, Italy

• Taurion, C., (2004) "Software Livre: potencialidades e modelos de negócio", RJ: Editora Brasport.

• Riehle, D. (2007) The Economic Motivation of Open Source Software: Stakeholder Perspectives, Publish ed by the IEEE Computer Society April

  Kubota, L.C., (2006), DESAFIOS PARA A INDÚSTRIA DE SOFTWARE, Brasília,

• IPEA, TEXTO PARA DISCUSSÃO No 1150,

• http://www.ipea.gov.br/082/08201008.jsp?ttCD_CHAVE=2480

Créditos desse estudo também se devem aos meus colegas:
Ana Carina M. Almeida, Cleyton C. da Trindade e Marcio M. de Souza

Open source e sua influência no desenvolvimento de software – parte 2

No primeiro post desta série falamos sobre o que é open source no contexto da indústria de software. A pergunta principal foi: práticas open source no desenvolvimento de software aumentam a qualidade dos produtos derivados da engenharia de software? A resposta a essa questão ficou longe de se encerrar. Aqui, continuaremos a desenvolvê-la partindo da reflexão acerca dos aspectos da engenharia de software tradicional e compará-lo com algumas práticas open source.

Cenário da guerra do software (open source e sua influência na indústria)

Engenharia de Software Open Source

Desde o seu surgimento, a engenharia de software tem evoluído com o objetivo de construir produtos de maior qualidade, economizando tempo e recursos. Isto não é uma meta fácil de alcançar, pois muitas vezes qualidade está atrelada ao custo. Considerando práticas open source no projeto de software e em relação aos aspectos desejáveis da engenharia de software (otimização de recursos, qualidade e tempo), um projeto Open Source tende a ser organizado em comunidades, influenciando principalmente os seguintes aspectos:

• Minimizar o custo da produção; pois os membros da comunidade geralmente são voluntários e não há limites para a entrada de novos integrantes, o que normalmente, visam obter alta qualidade no produto final, o que leva conseqüentemente, alta qualidade no código produzido. Estando este disponível, pode ser revisado e alterado por qualquer programador, eliminando a dependência de uma empresa detentora da tecnologia que melhore as funcionalidades do software ou corrija os erros;
  
• Variação do tempo de desenvolvimento do software; normalmente os prazos não são bem definidos, pois a maioria do trabalho é voluntária, e dependerá do esforço coletivo e das lideranças envolvidas. No entanto o risco da descontinuidade dos projetos é baixo, pois qualquer desenvolvedor pode assumir e dar continuidade ao projeto [Beline, Menta e Salvi 2005].
  

Através de projetos distribuídos, a Indústria de software encontra dificuldades semelhantes aos projetos Open Source, por exemplo, problemas de comunicação e cultura entre as equipes que estão geograficamente distribuídas. Na tentativa de minimizar estes problemas é possível notar em [Hogan 2000], a importância do uso de ferramentas, tais como programas de mensagens instantâneas, voz sobre IP e vídeo documentação, no intuito de agilizar a comunicação; já para estreitar os laços culturais, foram criados embaixadores que realizavam intercâmbios entre as equipes.

O Source Forge é um exemplo de espaço compartilhado em projetos Open Source, sendo este o maior site mundial de hospedagem, com o objetivo de valorizar a comunidade oferecendo vários serviços e ferramentas web para o desenvolvimento colaborativo de sistema, suporte ao gerenciamento de projetos e downloads, manipulação de conteúdo, banco de dados, controle de versões e mecanismos de hospedagem e divulgação [Parreiras, Silva, Bastos e Brandão 2004].

Observando as diversas áreas da Engenharia de Software é possível estabelecer uma relação com o Open Source, considerando os seguintes pontos:

• Gerência de Projetos: Esta área já vem sofrendo modificações nas empresas que realizam projetos distribuídos, pois elas têm de compartilhar os seus recursos entre os projetos e garantir a entrega de um produto no menor tempo possível, dentro das especificações técnicas e orçamentos esperados para garantir a satisfação do cliente. Como os recursos são limitados, a indústria utiliza técnicas, tal como, a corrente crítica, de forma a não prejudicar o tempo de desenvolvimento do projeto [Quelhas e Barcaui 2005]. Entretanto, técnica como a citada anteriormente é colocada em cheque no Open Source, pois há uma abundância de recursos voluntários, dificultando a gestão tradicional (baseada em comandos e hierarquia) [Soares 2002]. Outro ponto delicado na gestão de um projeto Open Source é no caso dos integrantes da comunidade não aprovarem as decisões tomadas e criarem uma nova comunidade a partir dos códigos fontes já desenvolvidos.
  
• Teste: Esta área, conceitualmente, tem o objetivo de avaliar se o software se comporta conforme a sua especificação, isto é, através de uma execução controlada. Como o software possui características que possibilitam mudanças, aumento de complexidade e intangibilidade, testar torna-se um processo caro e não trivial [Crespo, Silva, Borges e etc 2004]. Porém, nos projetos Open Souce, geralmente, existem menos defeitos que os proprietários e o tempo entre identificar o defeito e repará-los são mais rápidos, ajudando no crescimento da confiabilidade nos projetos [Paulson, Succi e Eberlein 2004].
  

  Requisitos: A Engenharia de Requisitos é uma área da Engenharia de Software focada em analisar e documentar os requisitos, incluindo análise de necessidades e especificação de requisitos. Para isto, são fornecidos mecanismos que facilitam as atividades relacionadas [Lopes, Majdenbaum e Audy 2003] No Open Source, as etapas de elicitação, análise, especificação, validação e comunicação dos requisitos são feitos de maneira informal e sem suporte de notações especificas ou documentação formal. Apesar desta informalidade, os membros da comunidade ao utilizar e-mail, sites, fóruns e diretórios compartilhados de código fonte podem facilmente conhecer as exigências do projeto.
  

  
  

Colaborações de projetos open source em processo de desenvolvimento de software

Um processo de desenvolvimento de software se caracteriza por um conjunto de atividades necessárias para criação eficaz de um programa. [Pressman 2004]

Pode-se observar que as comunidades de software livre vivem com processo de desenvolvimento de software bastante simples, com poucas ferramentas, pouca documentação, sem muita preocupação com questões de usabilidade de interface e sem muito formalismo da etapa de testes de sistemas. Segundo [Reis 2004] alguns projetos nem possuem plano de teste.

[Herbsleb e Grinter 1999] terminou o seu artigo com a seguinte pergunta "Se o desenvolvimento distribuído é tão difícil, como é que projetos open source têm êxito, dada a relativa simplicidade do seu processo e das suas ferramentas?" [Barnett 2004] mostra (veja a tabela abaixo) uma comparação entre as fases de um ciclo de desenvolvimento de software de um processo tradicional e de um open source.

Tabela:. Comparação entre processo tradicional e open source.

	Tradicional	Open source
Documentação	A documentação significa controle de qualidade e ferramenta para gerência de projeto [Barnett 2004].	Na maioria dos projetos a documentação é escassa devido ao código fonte ser aberto e rico em comentários [Reis, Silva e Fortes 2004].
Requisitos	O analista de negócio transcreve a necessidade do usuário dentro do documento de requisito.	Normalmente os usuários são os desenvolvedores do software [Silveira, S.,(2004)].
Alocação de Pessoas	Os desenvolvedores estão alocados a um único projeto.	Os desenvolvedores estão alocados a projetos distintos com diferentes níveis de envolvimento.
Revisão em par	É aceita, porém não é largamente utilizada.	É uma necessidade e praticada quase de forma universal.
Planejamento dos Releases	Número grande de requisitos e poucos releases.	Releases muito freqüentes. [Raymond 2000]
Qualidade/Teste	Existe formalismo nesta etapa. O teste de sistema é planejado e executado antes do release formal. As auditorias de qualidade são feitas durante todo o processo de desenvolvimento de software na maioria dos todos os artefatos gerados.	Diferente do senso comum, não são realizadas muitas atividades de garantia de qualidade ao longo do desenvolvimento. Por exemplo, executar testes periódicos, possuir um plano de testes, um processo de revisão ou regras para integração de alterações no código. A disponibilização do código publicamente, por meio de releases alpha, beta e release candidates, visando a execução de testes pelo usuário final, é a principal atividade executada para garantir qualidade.
Distribuição do Trabalho	Diferentes partes do código são atribuídas para diferentes pessoas.	Qualquer pessoa pode modificar qualquer parte do código, porém apenas os "committers" podem fazer as modificações oficiais.

[Barnett 2004] menciona no seu artigo algumas atividades de um processo open source que podem ser aplicadas a ambientes coorporativos a fim que possam ajudar a produtividade e qualidade dos produtos. É possível exemplificar as seguintes tarefas:

• Envolvimento do usuário durante todas as fases do desenvolvimento do software. Nos projetos open source normalmente o desenvolver é também o usuário; Este tipo de situação facilita esclarecimento de dúvidas, antecipando correção de especificação.
  

• Staffing Model; Os desenvolvedores open source normalmente trabalham em mais de um projeto ao mesmo tempo, apesar de estar mais envolvido em um do que nos outros.
  
• Aumentar a transparência do andamento do trabalho para as pessoas que não fazem parte do projeto. Aumentando a transparência pode-se aumentar a responsabilidade e produtividade dos participantes, visto que o trabalho gerado fica disponível para toda comunidade validar.
  
• Recrutar alguns usuários para teste beta da aplicação
  para que seja possível detectar erros antes do release oficial.
  
• Adoção de processos ágeis, "Release early. Release often and listen to your customers." [Raymond 2000]. Liberando pacotes pequenos do software de forma rápida, é possível validar juntamente com o cliente o que está sendo desenvolvido evitando re-trabalho desnecessário.
  

A partir destes exemplos, podemos perceber que existem aspectos positivos do processo de desenvolvimento de software livre e se aplicados em um processo tradicional teremos ganhos de qualidade, produtividade e conseqüentemente redução dos custos do projeto.

No próximo post abordaremos o Open Source e seus efeitos na economia.

Referências:

Beline, W., Menta, E., Salvi, R., (2005) "EAD no mundo Open Source: construindo conhecimento com liberdade", II Secomp - Semana de Computação da Universidade Estadual de Londrina, v. 1, p. 1-10

Hogan, B.(2006) "Lessons learned from an extremely distributed project, IEEE Computer Society", agile , pp. 321-326

Parreiras, F., Silva, A., Bastos, J., Brandão, W. "Informação e cooperação nas comunidades de desenvolvimento de software livre: um panorama do cenário

brasileiro". In: CINFORM, Salvador. Anais. Salvador: UFBA

Soares, M. (2002) "O Processo e a (Des)organização da Produção de Software Livre"In: CONGRESSO BRASILEIRO DE COMPUTAÇÃO, Itajaí-SC. Univali

Crespo, A. Silva, O. Borges, C. Salviano, C. Argollo Junior, M. Jino, M., (2004)" Uma Metodologia para Teste de Software no Contexto da Melhoria de Processo.", III

Simpósio Brasileiro de Qualidade de Software, v. 3. p. 271-285

Paulson, J., Succi, G. Eberlein, A. (2004) "An Empirical Study of Open-Source and Closed-Source Software Products", IEEE Computer Society

Lopes, L.; Majdenbaum, A.; Audy, J.(2003) "Uma proposta para processo de requisitos em ambientes de desenvolvimento distribuído de software.", In: WER'03 – Workshop em Engenharia de Requisitos – SBC, Anais do WER'03, v. 1. p. 78-92

Pressman, R. (2004) "Engenharia de Software". 5ª Edição. McGraw-Hill Interamericana do Brasil

Reis, C., Silva, M., Fortes, R., (2004) "Levantamento sobre processo de Software Livre".

Barnett, L., (2004) "Applying Open Source Process in Corporate Development Organizations".

Silveira, S., (2004). "Software Livre – A luta pela liberdade de conhecimento". Editora Fundação Perseu – (Coleção Brasil Urgente).

Raymond, E., (2000). "The Cathedral and the Bazaar". Available at http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

Barnett, L., (2004) "Applying Open Source Process in Corporate Development Organizations".

Créditos desse estudo também se devem aos meus colegas:
Ana Carina M. Almeida, Cleyton C. da Trindade e Marcio M. de Souza

Open source e sua influência no desenvolvimento de software – parte 1

Práticas open source no desenvolvimento de software aumentam a qualidade dos produtos derivados da engenharia de software?

Revisão 001 (16/03/2008).

A popularidade de software open source está crescendo a cada dia que passa e diversos produtos de amplo conhecimento popular, tais como, sistema operacional Linux e servidor de aplicações Apache. Estes softwares estão sendo criados e mantidos, principalmente, baseados em práticas Open Source, e com a Internet, tornou-se um grande e dinâmico repositório de softwares livre/aberto em diversas áreas de negócios. Alguns estudos de Gacek e Arief (2004) confirmam que práticas open source é uma forma diferenciada de trabalho com impactos positivos às fábricas de software tradicionais.

Apresentarei aqui uma série de posts sobre resultados de um estudo em disciplina de mestrado realizado ano passado (2007), sobre as influências, os efeitos e colaborações do desenvolvimento de software open source na engenharia de software, processo de desenvolvimento e na economia. Estou aprofundando um pouco este estudo para posterior publicação em congressos da área, mas por hora, compartilho as principais idéias investigadas.

Algumas definições relevantes

Os pesquisadores citados acima afirmam que o termo Open Source refere-se, freqüentemente, a um processo de desenvolvimento de software que dá suporte a contribuições, via Internet, de desenvolvedores dispersos geograficamente e que, também, contém um requisito básico, o acesso ao código fonte.

Por outro lado, outros estudiosos como Elliott e Scacchi (2004) destacam uma verdade indispensável, um pacote de open source não necessariamente significa ser livre (no sentido de ser de graça, sem custo); um programa livre é aquele que pode ser usado, copiado, modificado e redistribuído, ou seja, é um sistema que dispõe de total liberdade para que seja realizada qualquer intervenção no código. Um software que é coberto por uma licença livre, não significa que esse software não terá custo para ser operacionalizado. Dependerá da lincença de uso. Assunto que será tratado mais a frente. Ter garantia de acesso ao código fonte e fazer com ele certas coisas é que está mais próximo da liberdade dita acima. Mas, como observou Patricia (ver comentários), nem todo opensource é software livre.

Open source possui várias peculiaridades que se modificam consideravelmente de projeto para projeto. Os estudos de Gacek e Arief (2004) propõem uma classificação em dois grupos de características nos projetos open source: as Comuns e as Variáveis.

Classificação de características de projetos open source segundo Gacek e Arief (2004)

Comuns	Variáveis	Característica
Aderência à definição de open source e a usuários-programadores		Esta significa que um desenvolvedor é um subconjunto dos usuários de open source e, desta forma, é correto afirmar que todos os desenvolvedores são usuários, mas a recíproca não é verdadeira. Aquela determina se a distribuição de um software, em particular, baseia-se nos critérios do OSI (Open Source Initiative).
	Pontos de Início de um Projeto	Um projeto de open source é iniciado de um já existente em código fechado (no geral).
	Motivação	É uma questão pessoal. Os desenvolvedores desejam ganhar respeito e reconhecimento através do reconhecimento da comunidade. Estudantes podem aumentar suas chances na carreira ganhando experiência no desenvolvimento de um projeto real.
	Comunidade	É organizada em estruturas restritas ou liberais, na qual ocorre a centralização ou descentralização na tomada de decisão a depender da composição escolhida. Quanto ao destaque de um componente numa organização deste tipo, a mesma ocorre quando há o reconhecimento do grupo, decorrente das contribuições realizadas por um indivíduo.
	Suporte ao Desenvolvimento de Software	Requer um processo similar aodesenvolvimento de software tradicional. Desta forma, é imprescindível que necessidades específicas geradas pelos desenvolvedores distribuídos tenham algum apoio efetivo, tais como: modularidade, visibilidade da arquitetura do software, documentação e teste, aceitação de submissões, ferramentas e suporte operacional.
	Licença	Vários tipos de licenças estão de acordo com a definição de open source OSI e vários destes, garantem que, se algum código for usado em outro software, o mesmo estará sob os termos da licença original.
	Tamanho	A dimensão da comunidade e da base de código varia fortemente de projeto a projeto.

Para melhor compreender um projeto open source temos que analisar o seu processo de desenvolvimento, ou seja, como o software open source se caracteriza por um conjunto de atividades necessárias para criação eficaz de um programa. Assunto este para o próximo post.

O Sistema Operacional Linux é o grande exemplo do que esse modelo pode construir. O video abaixa demonstra essa analogia. Obs. trata-se de um comercial da IBM.

Do ponto de vista prático, produtos ou serviços open source trazem oportunidades para empresas? Compartilhar seus produtos com as comunidades em rede, promove a marca e permite maior interesse dos usuários? essas e outras questões serão discutidos no decorrer dos próximos posts.

Para saber mais, procure no google e leia os seguintes artigos:

• The Many Meanings of Open Source - Gacek, Cristina e Arief, Budi. (2004), University of Newcastle Tyne, England, IEEE Software Computer Society.
  
• Open Source Definition - OSI, Open Source Initiative (2007) http://www.opensource.org/docs/definition.php.
  
• Mobilization of Software Developers: The Free Software Movement - Elliott, M. S. e Scacchi, W. (2004).

Créditos desse estudo também se devem aos meus colegas:
Ana Carina M. Almeida, Cleyton C. da Trindade e Marcio M. de Souza