Criando Comunidades de Desenvolvimento de Código Aberto Alan Kelon Oliveira de Moraes

Breve História do Open Source [Hars and Ou, 2001] Working for Free? - Motivations of Participating in Open Source Projects

Sumário Lei de Lotka Motivações dos desenvolvedores OSS Melhores práticas OSSD O Dilema Referências

Lei de Lotka

“The number of authors making n contributions is about 1/n a of those making one contribution, where a is often nearly 2” [Lotka, 1926]

MetaLab apenas 13 de 2429 contribuidores fazem mais de 10 contribuições 91.4% contribuíram uma ou duas vezes 2.2% contribuem com cinco ou mais contribuições [Dempsey et al., 2002]

25 milhões de linhas de código 3149 projetos ~ contribuições [Gosh and Prakash, 2000] [Lerner and Tirole, 2002] Red Hat Kernel

10% da população escreve 72% do código 20% da população escreve 81% do código [Gosh and Prakash, 2000] Para cada um que escreve código, cinco apenas irão reportar erros [Valloppillil, 1998] [Lerner and Tirole, 2002] Red Hat Kernel

Apache & GNOME 4% de 400 programadores são responsáveis por 88% do código do servidor web Apache [Mockus et al., 2002] No GNOME, 17% de 301 programadores contribuiram com 80% do código [Koch and Schneider, 2002]

Uma ressalva Nem todos os desenvolvedores possuem acesso de escrita no CVS As estatísticas podem estar infladas...

Motivações dos Desenvolvedores OSS

Trabalhando de graça? Fatores internos –Motivações intrínsecas “Innate desire to code, and code, and code until the day I die.” –Altruísmo –Identificação com a comunidade Recompensas externas –Retorno futuro: renda de serviços/produtos associados, capital humano, auto-marketing, reconhecimento –Necessidade pessoal [Hars and Ou, 2001]

Entrevista com 79 desenvolvedores Trabalhando de graça? [Hars and Ou, 2001]

Trabalhando de graça? [Hars and Ou, 2001]

$$ Benefícios imediatos –Aprimorar seu conhecimento –É mais divertido que seu trabalho Benefícios futuros –Ofertas de empregos, participação em empresas, acesso a capital de risco –Ego, reconhecimento [Lerner and Tirole, 2002]

Fatores que influenciam a participação em OSSD Motivações intrínsecas Identificação com o grupo Aprendizagem Reputação Plano de carreira [Lattemann and Stieglitz, 2005]

Principais papéis Bug fixers (75% dos usuários [Raymond 1999]) Programmers Managers – são [ou querem ser] pagos [Lattemann and Stieglitz, 2005]

Ciclo de vida [Lattemann and Stieglitz, 2005]

Por que há declínio? Muitas regras para programar Decisões dos gerentes não são entendidas pela comunidade Muita influência de empresas Pessoas importantes deixam o projeto [Lattemann and Stieglitz, 2005]

Melhores Práticas OSSD

Arquitetura Modular Possibilita desenvolvimento concorrente Mas a arquitetura do sistema é retida sob as mãos do(s) autor(es) originais ou atuais arquitetos (mantenedores) do software. [Arief et al., 2001]

O que um projeto OSS precisa? Pesquisa com 80 projetos do SourceForge –40 projetos com sucesso –40 projetos sem sucesso (*) Os projetos de sucesso utilizam um processo de coordenação e de comunicação mais bem definido [Michlmayr, 2005]

Onde estão as diferenças? Utilização de CVS Uso de listas de discussão e armazenamento de seu histórico Testes: lançamentos de versões beta Qualidade: uso do bugzilla [Michlmayr, 2005]

O que é comum? Ambos disponibilizam documentação para os usuários, porém pouca documentação voltada para desenvolvedores Não se preocupam em criar testes automáticos Preocupação com portabilidade [Michlmayr, 2005]

O Dilema

Comunidades orgânicas vs. sintéticas Dois tipos de comunidades: –orgânicas: bazar –sintéticas: criadas por empresas Dilema: como controlar o projeto para atender minhas [empresas] necessidades e ainda construir uma comunidade? Como influenciar o processo padrão em uma direção que seja positiva para a empresa? Qual o modelo de governo ideal? [O’Mahony and West, 2005]

Comunidades orgânicas vs. sintéticas Projeto OSS significa: licença, processo de desenvolvimento, modelo de governo. O termo “open source project” não possui um significado claro e tão bem definido quanto “open source license”. [O’Mahony and West, 2005]

Comunidades Orgânicas Governo não é imposto, mas emerge da necessidade de organização do projeto Custo inicial muito alto “Furthermore, the continued reference to the same handful of successful projects (notably Linux and Apache) suggests that there is tremendous difficulty building projects this way” [O’Mahony and West, 2005]

Comunidades Sintéticas Por quê? –Criação de um mercado para o projeto ou reduzir o mercado do concorrente –Acelerar distribuição e redução de custos com o marketing –Diversificar seus produtos –Serviços associados [O’Mahony and West, 2005]

Como? –Desenvolvimento fechado mas transparente –Doando código, recursos e reduzindo o start- up do projeto –Transferir responsabilidade para a comunidade após algum tempo –Deixar o desenvolvedor deixar sua marca –Contrate os melhores da comunidade! Comunidades Sintéticas [O’Mahony and West, 2005]

Open Source e CMM? Desenvolvimento fechado –CMM nível 2 Migração para Open Source –Qualidade do código e documentação aumentou porque estavam preocupados com sua reputação –Gerência do processo tornou-se mais explícito –CMM nível 3, com tendência para nível 4 Projeto Open Source –Acabou o financiamento –Diminuição da comunicação face a face –Volta para o CMM nível 2, faltando apenas a gerência do processo para voltar a nível 3 [Bleek et al., 2005]

Referências Lotka, A. J The Frequency Distribution of Scientific Productivity, Journal of the Wash. Academy of Sciences, 16(12): Dempsey, B. J., Weiss, D., Jones, P. and Greenberg, J Who is an open source software developer? Comm. of the ACM, volume 45, number 2 (February), pp Lattemann, C. and Stieglitz, S Framework for Governance in Open Source Communities. In Proceedings of the Proceedings of the 38th Annual Hawaii international Conference on System Sciences (Hicss'05) - Track 7 - Volume 07 (January , 2005). HICSS. IEEE Computer Society, Washington, DC,

Raymond, E. S. (1999), “The Magic Cauldron”, (Accessed: June 6, 2004): Lerner, J., Tirole, J. (2002). "Some Simple Economics of Open Source," Journal of Industrial Economics, 52, 197—234 Hars, A. and Ou, S Working for Free? - Motivations of Participating in Open Source Projects. In Proceedings of the 34th Annual Hawaii international Conference on System Sciences ( Hicss-34)-Volume 7 - Volume 7 (January , 2001). HICSS. IEEE Computer Society, Washington, DC, 7014 Referências

Mockus, A., Fielding, R. & Herbsleb, J. (2000) A case study of open source software development: the Apache server. In: Proceedings of the 22nd International Conference on Software Engineering, pp. 263–272. Koch, S. and Schneider, G. Effort, cooperation and coordination in an open source software project: GNOME. Information Systems Journal, 12(1):27--42, O’Mahony, S. and West, J. “What makes a project open source? Migrating from organic to synthetic communities.” Academy of Management conference, Technology and Innovation Management division, Honolulu, August 2005.

Referências Bleek, Wolf-Gideon and Matthias Finck and Bernd Pape, Towards an Open Source Development Process – Evaluating the Migration to an Open Source Project by Means of the Capability Maturity Model, OSS 2005: Proceedings of the First International Conference on Open Source Systems(OSS 2005), Juli 2005, Genua, Italien, Arief, L.B., Gacek, C. and Lawrie, T. Software Architectures and Open Source Software - Where can Research Leverage the Most?. 1st Workshop on Open Source Software Engineering: Making Sense of the Bazaar (part of the 23rd IEEE International Conference on Software Engineering (ICSE 2001)), Toronto, Canada, 15 May 2001, pp - 3-5, Michlmayr, M. (2005). Software Process Maturity and the Success of Free Software Projects.In: Zieliński, K., Szmuc, T. (Eds.), Software Engineering: Evolution and Emerging Technologies. 3–14