UNIVERSIDADE DE PERNAMBUCO FACULDADE DE CINCIA E TECNOLOGIA DE CARUARU BACHARELADO EM SISTEMAS DE INFORMAO

Motivao de Engenheiros de Software no Contexto Open Source: Um Estudo de Caso com a Comunidade Android Brasil Projetos

DANILO MONTEIRO RIBEIRO

Caruaru, Junho de 2012.

UNIVERSIDADE DE PERNAMBUCO

DANILO MONTEIRO RIBEIRO

Motivao de Engenheiros de Software no Contexto Open Source: Um Estudo de Caso com a Comunidade Android Brasil Projetos

Monografia apresentada a Faculdade de Cincia e Tecnologia de Caruaru - Universidade de Pernambuco, como requisito parcial obteno do grau de Bacharel em Sistemas de Informao, sob orientao do Prof. M.Sc. Pietro Pereira Pinto e coorientao pelo Prof M.Sc Alberto Csar Cavalcanti Frana.

Orientador: M.Sc Pietro Pereira Pinto Co-orientador: M.Sc Alberto Csar Cavalcanti Frana

CARUARU 2012

iii

Dedico este trabalho minha famlia, amigos e professores.

iv

AGRADECIMENTOS

Gostaria de agradecer neste trabalho, o meu grande amigo e incentivador tio Neto que sempre me ajudou durante a graduao, me fez pensar questes mais amplas e a sempre buscar dar o melhor de mim, assim como meu tio Sandro, so exemplos de superao e de seres humanos que eu quero ser. Minha me que apesar de tudo fez sempre o possvel e o impossvel para eu me tornar a pessoa que sou e apesar da saudade sempre me incentivou a continuar no curso. Meus amigos de Casa e de Graduao, em especial Levi, Carlos Magno, o mo de vaca do Csar Albuquerque, Maryvania e Jos Marola Paulo, enchi muito o saco desse povo, mas passamos juntos e sobrevivemos. Minha namorada Juliett Figueiredo com quem eu quero construir minha famlia, que me acompanhou durante essa jornada, cerca de 3 anos de graduao me ouvindo falar de pesquisa, artigos, trabalhos, deve ter sido um saco mas quase nunca reclamou e sempre foi compreensiva. Gostaria de agradecer Humberto Rocha pela oportunidade que tive de ser aluno bolsista de Iniciao Cientifica, assim como Vinicius Garcia que aceitou a ideia de ser meu orientador, aprendi muito com os dois durante esse tempo e foi muito proveitoso. Alguns professores me marcaram mais que outros, no desmerecendo os outros claros, Almir Moura com sua didtica sensacional, tornou-se um grande amigo meu, Fernando Pontual, Carvalho e Cristvo que com suas experincias me ensinaram muita coisa na hora do almoo, sempre me ensinaram a ver mais que o curso pode proporcionar. Cicero Garrozi, um professor com que eu ainda quero trabalhar um dia. No menos importante quero agradecer a Pietro por ter aceitado o desafio de orientar em uma rea que no a dele, sempre atento as correes foi uma figura importante na construo deste trabalho. Outra pessoa com que aprendi muito e foi muito importante para a construo deste trabalho foi o Csar Frana que me ouviu atentamente quando eu fui pedir para trabalhar em pesquisa de outra instituio, aceitou me orientar mesmo eu no sendo aluno do mesmo, nem da instituio que ele trabalha. Muito obrigado. Um al especial para Flavio Neves, obrigado por tudo. A todos no citados, infelizmente o espao pouco, mas obrigado. Deus, obrigado por todas as coisas boas e ruins na minha vida.

Resumo

Este trabalho tem como tema central o estudo da motivao em engenheiros de software no contexto Open Source. Foi realizado um estudo de caso na comunidade Android-Brasil-Projetos para identificar como os fatores motivadores agem nos membros das equipes de desenvolvimento de software no contexto Open Source na comunidade Android-Brasil-Projetos, para isso, foi necessrio identificar quais fatores influenciam na comunidade e quais so os sinais externos de motivao e desmotivao. Foram entrevistadas quatro pessoas da comunidade sendo um mantenedor e trs desenvolvedores. Os dados coletados foram analisados utilizando mtodos da Teoria Fundamentada (Grounded Theory), e sintetizados em uma teoria fundamentada nos dados que pode fornecer um entendimento sobre os relacionamentos, causas e consequncias dentro do contexto estudado. Como resultado foram encontrados 28 fatores que influenciam na motivao da amostra estudada e foram desenvolvidas 11 proposies. Alm disso, foram definidos como os fatores centrais da teoria o comprometimento e o interesse pessoal. Palavras-chave: Engenheiro de Software, Motivao, Open Source.

vi

Abstract This work is focused on the study of motivation on Open Source software engineers. A case study was performed in the community Android-Brasil-Projetos to identify as the motivating factors act on members of software development in the Open Source context within the community Android-Brasil-Projetos, for this, it was necessary identify which factors influence in the community and what are the external signs of motivation and demotivation. We interviewed four members from the community: a maintainer and three developers, the collected data were analyzed using Grounded Theory and were synthesized in a theory based on data to provide an understanding of the relationships, causes and consequences within the context studied. As a result were found 29 factors that influence the motivation of the sample studied and were developed 11 propositions. Furthermore, were defined as the central factors of theory the commitment and personal interest. Key Words: Software Engineer, Motivation, Open Source.

vii

SUMRIO 1. INTRODUO ................................................................................................... 11 1.2 Objetivos ..................................................................................................... 12 Objetivo Geral ...................................................................................... 12 Objetivos Especficos ........................................................................... 12

1.2.1 1.2.2 1.3 1.4 2

Justificativa de pesquisa ............................................................................. 13 Organizao do Trabalho ............................................................................ 15

REFERENCIAL TERICO ................................................................................ 16 2.1 Open Source e Software Livre ......................................................................... 16 2.1.1 2.1.2 2.1.3 2.1.3.1 Software Livre ...................................................................................... 16 Free Software Fundation ...................................................................... 17 Software Open Source ......................................................................... 18 Caractersticas do desenvolvimento Open Source .............................. 21

2.2 O Estudo da Motivao e suas Aplicaes ao Contexto da Engenharia de Software................................................................................................................. 22 2.2.1 2.2.2 2.2.3 2.2.3.1 2.2.3.2 2.2.3.3 O Estudo da Motivao na Psicologia .................................................. 22 Motivao no Desenvolvimento de Software ....................................... 23 Motivao no contexto Open Source ................................................... 27 WU et al (2007) .................................................................................... 28 Oreg e Nov (2007)................................................................................ 29 Von Krogh et al (2008) ......................................................................... 31

2.3 Discusso ........................................................................................................ 34 3 MTODOS ......................................................................................................... 35 3.1 Natureza da Pesquisa ................................................................................. 35 Quanto aos Fins ................................................................................... 35

3.1.1

3.1.2 Quanto Forma de Abordagem ................................................................ 35 3.1.3 Quanto aos mtodos de procedimentos .................................................... 36 3.2 Premissas ........................................................................................................ 37 3.3 Etapas de pesquisa ......................................................................................... 37

viii

3.4 Seleo de sujeitos .......................................................................................... 38 3.4.1 Entrevista ...................................................................................................... 38 3.5 Procedimentos da anlise de dados ................................................................ 41 3.5.1 Teoria Fundamentada em Dados (Ground Theory) ...................................... 41 3.5.2 Procedimento de codificao ........................................................................ 42 3.5.2.1 Codificao Aberta..................................................................................... 44 3.5.2.2 3.5.2.3 3.6 3.7 Codificao Axial .................................................................................. 45 Codificao Seletiva ............................................................................. 46

Limitaes ................................................................................................... 47 Discusso ................................................................................................... 48

4. Resultados ........................................................................................................... 48 4.1 Descrio do Contexto..................................................................................... 48 4.2 Resultados da Codificao aberta ................................................................... 50 4.2.1 Aspectos da Comunidade ............................................................................. 51 4.2.3 Aspectos do trabalho em equipe .................................................................. 55 4.3 Resultados da codificao axial ....................................................................... 60 4.4 Resultados da codificao seletiva .................................................................. 63 4.5 Avaliaes dos Resultados .............................................................................. 65 5. Concluso ............................................................................................................ 68 5.1 Trabalhos futuros ............................................................................................. 69 REFERNCIAS......................................................................................................... 71

ix ndice de figuras

Figura 1 - MOCC .................................................................................................................... 26 Figura 2 - Motivadores intrnsecos e extrnsecos ............................................................. 27 Figura 3 - Gerao da teoria da comunidade ................................................................... 65

ndice de Tabelas Tabela 1 - Evoluo do conceito de Motivao ................................................................ 22 Tabela 2 - Fatores Motivadores........................................................................................... 24 Tabela 3 - Fatores Desmotivadores ................................................................................... 25 Tabela 4 - Fatores Motivacionais intrnsecos .................................................................... 32 Tabela 5 - Fatores Motivacionais extrnsecos internos ................................................... 32 Tabela 6 - Fatores Motivacionais extrnsecos................................................................... 33 Tabela 7 - Aspectos motivacionais ..................................................................................... 50 Tabela 8 - Sinais de motivao ........................................................................................... 58

11 1. INTRODUO A atividade de desenvolvimento de software enfrenta crescentes desafios visando a diminuio de custo, esforo e tempo de chegada dos produtos no mercado. Contudo, a complexidade e tamanho dos produtos esto aumentando e, consequentemente, os gestores precisam buscar novas alternativas para o processo de desenvolvimento. Uma dessas alternativas pode ser a utilizao de software Open Source (FERREIRA, 2005). Segundo Koch (2008) e Subramanyam e Xia (2008), os aplicativos Open Source so aqueles cujo cdigo fonte est disponvel para qualquer pessoa, ou seja, ele est sob uma licena que estabelece condies para modificao, reuso e redistribuio do software, oferecendo assim a possibilidade de um usurio modific-lo, adequando-o as suas necessidades. De acordo com IBM (2007), uma das principais caractersticas deste tipo de software fato de ser normalmente desenvolvido por equipes distribudas geograficamente. Em geral, os membros dessas equipes no se conhecem pessoalmente e so coordenados por estruturas baseadas em meritocracia, nas quais, de acordo com Ferreira (2008), as pessoas obtm tarefas e responsabilidades de acordo com seu merecimento. Essa forma de organizao bem diferente das estruturas hierrquicas formais que contam com um gerente para distribuir atividades e cobrar produtividades de seus subordinados. Conforme Frana et al (2011), o comportamento de equipes de

desenvolvimento de software tem sido estudado de forma crescente nos ltimos anos, principalmente atravs de pesquisas que buscam entender, em especial, os fatores que motivam e desmotivam engenheiros de software durante o

desenvolvimento do projeto. Frana e Da Silva (2009) afirmam que existem duas ideias principais de interesse da indstria na gesto comportamental: a primeira corresponde necessidade de criao de um clima organizacional no qual os colaboradores possam obter respeito e valorizao; a segunda parte da premissa que pessoas motivadas produzem mais.

12 Seguindo a premissa que pessoas motivadas produzem mais, Von Krogh et al (2008) busca entender o que motiva os engenheiros de software Open Source. Para este autor, neste contexto, as equipe so formadas por colaboradores voluntrios, que trabalham quando querem, de forma autnoma e sem vnculos empregatcios, ou obrigaes com o projeto. Apesar destes colaboradores poderem se desligar do projeto a qualquer momento, eles conseguem desenvolver, com sucesso, projetos de alto nvel e complexidade (IBM, 2007). Para realizao deste estudo foi utilizada uma comunidade Open Source, a Android-Brasil-Projetos, que utiliza uma tecnologia recente de desenvolvimento mobile (Android1), Open Source, que segundo a Motorola (2012) so ativados mais de 850 mil aparelhos que funcionam base desta tecnologia no mundo por dia. 1.2 Objetivos Para responder pergunta de pesquisa: Como os fatores motivadores agem na comunidade Android-Brasil-Projetos? Foram definidos os seguintes objetivos, divididos em geral e especficos: 1.2.1 Objetivo Geral Este trabalho tem como objetivo identificar como agem os principais fatores motivacionais que afetam os engenheiros de software no contexto de

desenvolvimento de software Open Source na comunidade Android-Brasil-Projetos. 1.2.2 Objetivos Especficos Identificar, com base em revises de literatura, os principais fatores motivacionais ligados aos projetos de desenvolvimento de software Open Source; Adaptar o questionrio desenvolvido por Da Silva et al (2011) para realidade do projetos de desenvolvimento de software Open Source; Realizar as entrevistas com engenheiros de software de projetos Open Source da comunidade Android-Brasil-Projetos para obter dados sobre o que os motiva e o sinais externos de motivao;
1

Para mais informaes http://www.android.com/

13 Analisar os dados coletados atravs do instrumento de pesquisa aplicado; Encontrar quais fatores motivacionais afetam a comunidade AndroidBrasil-Projetos; Conhecer quais so os sinais externos de motivao na comunidade Android-Brasil-Projetos. Explicar como os fatores encontrados agem na comunidade AndroidBrasil-Projetos. 1.3 Justificativa de pesquisa De acordo com Wu et al (2007), a comunidade Open Source tem produzido um grande numero de projetos software de sucesso, dentre eles: Linux, Apache, Perl e SendMail. Driver e Weiss (2005) projetaram que o software Open Source estaria no ano de 2010 em 75% das empresas, operando em conjunto com software proprietrios. Entretanto, segundo a TIINSIDE (2008), essa projeo j foi superada e estima-se que esse percentual j estava em 85% em 2008. Desde ento, o movimento de software Open Source vem crescendo muito, atraindo novos parceiros e desenvolvendo novos aplicativos, como o Linux, que um sistema operacional desenvolvido com a licena GNU GPL 2. Em uma pesquisa realizada em 2009 foi observada uma taxa de crescimento do software livre de cerca de 20% anual, mostrando novamente o interesse das pessoas e empresas na rea (SOFTWARELIVREBRASIL, 2009). De acordo TIINSIDE (2008), o software livre e o de cdigo aberto esto sendo constantemente utilizados por empresas no seu dia-dia, destacando-se como as trs principais razes para a utilizao de programas de cdigo aberto: (i) a diminuio do custo total de propriedade, (ii) a reduo dos custos de desenvolvimento e (iii) o fato de o software livre ser mais fcil de ser implementado em novos projetos de TI. Segundo Von Krogh et al (2008), nos ltimos 15 anos os aplicativos Open Source fizeram incurses bem-sucedidas em diversos segmentos, atraindo milhes de usurios. Atualmente, as empresas investem e colaboram em grande quantidade neste tipo de produto. Como resultado disto, Von Krogh et al (2008 p.4, traduo
2

uma designao de uma licena para software livre idealizada por Richard Matthew Stallman

14 nossa) afirma que: os gestores destas empresas esto cada vez mais dependente de recursos de desenvolvimento que esto fora do seu controle direto. Assim, esses gestores esto preocupados com o que motiva colaboradores externos a participar na criao de um software Open Source. Von Krogh et al (2008) cita como exemplo que se uma empresa decide investir milhes de dlares a fim de migrar os seus servidores para um sistema Linux da IBM os gestores vo querer saber at que ponto o Linux continuar a receber contribuies por voluntrios, como o software ir evoluir, e se Linux e outros projetos envolvidos tero melhoria em novas verses. Desta forma, entender os fatores envolvidos na motivao no

desenvolvimento de software no cenrio Open Source de grande importncia para uma empresa que investe ou deseja investir em nesse tipo de sistema, pois ela deve acompanhar e incentivar a comunidade e seus membros, para que os aplicativos utilizados por ela tenham seus problemas corrigidos e evoluam de acordo com suas necessidades, trazendo benefcios para a empresa e mantendo a competitividade da mesma. Alm disso, os mantenedores3 de comunidades Open Source tambm precisam saber o que faz os membros contriburem mais com a comunidade e permanecerem nos projetos at que estes sejam concludos com sucesso, ou continuem a trabalhar na evoluo do mesmo. Para isso, de suma importncia a realizao de uma pesquisa que vise encontrar indcios sobre os fatores motivacionais aplicados nesse contexto, para que se possa compreender melhor o fenmeno estudado e encontrar possveis novos fatores motivacionais. Entretanto, ainda so escassos os estudos que visam identificar os fatores motivacionais no contexto de projetos de software Open Source usando uma abordagem qualitativa. Sendo assim, a problemtica da pesquisa pode ser representada pela pergunta: Como os principais fatores motivadores que levam engenheiros de software a contribuir com projetos Open Source agem na comunidade Android-Brasil-Projetos?

Os mantenedores so os responsveis pelos projetos na comunidade.

15 1.4 Organizao do Trabalho Neste captulo foi realizada uma breve introduo aos temas deste trabalho: Motivao no desenvolvimento de software e Open Source software. Foi tambm apresentado o problema de pesquisa, os objetivos gerais e especficos do trabalho e a justificativa para realizao deste. O restante do trabalho est organizado da seguinte forma: Captulo 2 Referencial terico: Neste captulo feita uma reviso bibliogrfica acerca dos principais temas relacionados pesquisa, a saber: Open Source e Software Livre, Motivao na engenharia de Software e no contexto Open Source; Captulo 3 Mtodos: o captulo no qual se contempla a descrio do mtodo de pesquisa utilizado no trabalho, bem como as limitaes deste; Captulo 4 Resultados: Onde sero apresentados os resultados da codificao aberta, axial e seletiva. Captulo 5 Concluso e trabalhos futuros: Contempla as concluses obtidas da realizao da pesquisa e gerao da teoria, assim como os trabalhos futuros.

16 2 REFERENCIAL TERICO Neste captulo de referencial terico so apresentadas as definies dos conceitos necessrios ao desenvolvimento do trabalho, a saber: software livre, Open Source e motivao. 2.1 Open Source e Software Livre Este captulo aborda de forma sucinta o assunto Software Open Source, discorrendo brevemente sobre sua Historia, sua definio e diferenas com o software livre e algumas caractersticas do processo de desenvolvimento de software Open Source. 2.1.1 Software Livre De acordo com GNU (1996), um software para ser considerado livre deve garantir a qualquer pessoa as premissas de: (i) executar o programa, (ii) a qualquer momento modificar o programa para atender a novas necessidades, (iii) distribuir livremente cpias originais,(iv) distribuir livremente cpias modificadas. O software livre diferente do software proprietrio, pois, segundo Saleh (2004 p.13), No software proprietrio em geral a nica liberdade garantida ao usurio a de usar o programa, mesmo assim somente aps seu licenciamento, e com compromisso de no redistribu-lo nem modifica-lo. Existem ainda software proprietrios grtis, como jogos e mensageiros instantneos. Contudo, como estes no seguem as quatro premissas do software livre, apresentadas anteriormente, no so considerados livres. Saleh (2004) afirma que nas dcadas de 1960 e 1970 praticamente todo o software era livre, pois a pratica da comercializao de licenas ainda no era difundida, j que o foco dos fornecedores de tecnologia estava no hardware, muitas vezes fornecido em conjunto com os sistemas operacionais. Os aplicativos geralmente eram desenvolvidos de acordo com as necessidades dos usurios que compravam o hardware, sendo especficos para a arquitetura adquirida. Devidos a estas caractersticas, universidades, empresas e centros de pesquisas compartilhavam os cdigos da mesma comunidade, sem preocupaes

17 com direitos autorais. Como na segunda metade da dcada de 1970 a comercializao de licenas comeou a aparecer com mais fora, o movimento do software livre sentiu a necessidade de se organizar mais, tendo como umas das consequncias a criao da Free Software Fundation (SALEH, 2004). 2.1.2 Free Software Fundation Em 1985 foi iniciada a Free Software Fundation, criada por Richard Stallman, com o objetivo de promover na comunidade de informtica o esprito cooperativo que se apresentava no inicio da computao, em que seus cdigos, informaes e maneiras de trabalho eram livremente compartilhados (STALLMAN, 2002). Esta organizao considerada como a principal patrocinadora do projeto GNU/LINUX (GNU, 1996). Em 1981, o laboratrio de inteligncia artificial do Massachusetts Institute of Technology (MIT) teve seu principal computador, que tinha o sistema operacional e aplicativos desenvolvidos pela prpria equipe da universidade, com software livre, substitudo por outro computador com cdigos proprietrios e fechados do fabricante do novo computador (STALLMAN, 2002). Richard Stallman, at ento professor do MIT, resolveu que no deveria assinar os acordos de no divulgao impostos pelo fornecedor do hardware, decidindo assim, no trabalhar com o software proprietrio do fornecedor. Stallman queria incentivar as pessoas a criarem software suficiente que permitisse a utilizao de um computador sem a necessidade de qualquer programa proprietrio, pois ele acredita que essa opo a nica socialmente justa (STALLMAN, 1999 apud Saleh 2004). Stallman (1999 apud Saleh, 2004, p.18) afirma que:
o software proprietrio implica numa organizao social na qual no permitido s pessoas compartilhar conhecimento, no permitido ajudar ao prximo e incita competio ao invs da colaborao: acredita que todo software deveria ser livre.

Stallman (1999 apud Saleh 2004, p.18) considera que: uma vez pagos os custos de desenvolvimento limitar o acesso ao software traz muito mais malefcios

18 que benefcios. Quando o usurio resolve pagar pela licena, est acontecendo uma transferncia de riquezas que ser benfica para ambas as partes, uma vez que o usurio ter o software para resolver seu problema e a empresa ter o valor da licena. Todavia, se o usurio resolve no adquirir o software, pois existe necessidade de pagamento, est havendo prejuzo a uma das partes sem que haja benefcio de ningum. Stallman (1999 apud SALEH 2004) pondera que o prejuzo sociedade pela restrio maior que os possveis ganhos individuais da empresa, j que se esto sendo impostas restries a um bem cujo custo marginal de produo zero, ou seja, no ocorre acrscimo (ou decrscimo) do custo total quando se aumenta (ou diminui) a quantidade de software produzida, e que as empresas de software proprietrio restringem a cooperao entre as pessoas e limitam o conhecimento da sociedade com a proibio da distribuio do software. A principal ideia que Stallman (1999 apud Saleh 2004) quer passar que o software fechado nega o acesso informao e ao conhecimento, elementos sem os quais impossvel estabelecer uma sociedade mais justa e democrtica. 2.1.3 Software Open Source A Open Source Initiative4 [s.d] aponta que a publicao do trabalho de Eric Raymond (1997), intitulado de A Catedral e o Bazar5, o qual apresenta ao leitor uma nova maneira de compreender e descrever as prticas populares na comunidade Software Livre, foi de grande importncia para o difuso do software Open Source. Sua anlise, centrada na ideia de reviso por pares distribuda, na liberao de software para que as pessoas testem antes do produto final, teve sucesso, tanto dentro como (e de forma at inesperada) fora da cultura livre. A apresentao deste trabalho em setembro de 1997 foi o incentivo para a Netscape, em 22 de janeiro de 1998, liberar o cdigo fonte de seu popular navegador da Web como software livre, de acordo com a Open Source Initiative, que afirma ainda que: existia um sentimento generalizado de que as regras de

4 5

Para maiores informaes: http://www.opensource.org Texto disponvel em http://www.catb.org/~esr/writings/cathedral-bazaar/

19 desenvolvimento estavam prestes a mudar, e que qualquer coisa seria possvel. (OPEN SOURCE INITIATIVE, s.d, traduo nossa) O rtulo "Open Source" foi concebido em uma sesso realizada em 03 de fevereiro de 1998, em Palo Alto, Califrnia. Dentre as pessoas presentes nesta sesso estavam: Todd Anderson, Chris Peterson (do Foresight Institute), John "maddog" Hall e Larry Augustin (ambos da Linux International), Sam Ockman (do Grupo Vale do Silcio do usurio do Linux), Michael Tiemann, e Eric Raymond, cones da comunidade livre (OPEN SOUCE INITIATIVE, s.d). A Open Source Initiative [s.d] afirma que os conferencistas decidiram que no era interessante ficar limitado pela atitude moralizadora e de confronto que tinha sido associada ao software livre no passado, e que seria interessante vender as ideias estritamente pragmticas que motivaram Netscape. Eles debateram as tticas que deveriam usar e um novo rtulo, "Open Source", foi proposto por Chris Peterson. Cinco dias depois, em 8 de fevereiro de 1998, foi emitida a primeira chamada pblica para a comunidade comear a usar o novo termo. As pessoas envolvidas no movimento Open Source trabalhavam com software livre, mas sentiam-se incomodadas com o carter ideolgico imposto pela FSF e sua licena GNU GPL. Ento, esse movimento quis retirar do desenvolvimento de software livre qualquer componente social ou ideolgico. O software deve ser aberto no por questes de liberdade, mas sim porque o modelo aberto de desenvolvimento mais eficiente tanto tcnica quanto economicamente (OPEN SOUCE INITIATIVE, s.d; SALEH, 2004). A ideia principal que enquanto os programadores esto lendo e modificando o cdigo, naturalmente vo aparecer melhorias, adaptaes e correes, que tm como consequncia uma maior evoluo do programa. Qualquer licena de software pode ser considerada aberta caso siga os seguintes termos (PERENS, 1999; OPEN SOUCE INITIATIVE s.d): (i) Distribuio livre A licena no deve impedir a venda ou distribuio do programa gratuitamente, seja ele como componente de outro programa ou no. (ii) Cdigo fonte O programa deve incluir seu cdigo fonte ou deve haver algum maneira de obt-lo pela internet ou com custo de reproduo, permitindo a

20 sua distribuio tambm na forma compilada. O cdigo deve ser legvel e inteligvel por qualquer programador. (iii) Trabalhos Derivados A licena deve permitir modificaes e trabalhos derivados, permitindo, inclusive, que esses sejam distribudos sobre os mesmos termos da licena original. (iv) Integridade do autor do cdigo fonte - A licena pode impedir que o cdigo fonte seja distribudo em uma forma modificada apenas se a ela permitir a distribuio de arquivos de atualizao com o cdigo fonte para o propsito de modificar o programa. A licena tambm deve permitir a distribuio do programa desenvolvido a partir do cdigo fonte modificado. Todavia, a licena pode ainda requerer que programas derivados tenham um nome ou nmero de verso diferentes do programa original. (v) No pode haver discriminao contra pessoas ou grupos - A licena no pode ser discriminatria contra qualquer pessoa ou grupo de pessoas. (vi) No pode haver discriminao contra reas de atuao - A licena no deve impedir qualquer pessoa de usar o programa em um ramo especfico de atuao. Por exemplo, ela no deve proibir que o programa seja usado em um empresa, ou para pesquisa gentica. (vii) Distribuio da Licena - Os direitos ao programa devem ser aplicveis para todos aqueles que receberem o programa, sem a necessidade da execuo de uma licena adicional para estas partes. (viii) A Licena no especfica a um produto - Os direitos associados ao programa no devem estar sujeitos que o programa seja parte de uma distribuio especfica de programas, ou seja, no se pode obrigar a executar o programa somente em alguma distribuio do Linux, por exemplo. Se o programa extrado desta distribuio e usado ou distribudo dentro dos termos da licena do programa, todas as partes para as quais o programa redistribudo devem ter os mesmos direitos que aqueles que so garantidos em conjuno com a distribuio de programas original. (ix) A Licena no restringe outros programas - A licena no pode colocar empecilhos em outros programas que so distribudos juntos com o programa

21 licenciado. Isto , a licena no pode especificar que todos os programas distribudos na mesma mdia de armazenamento sejam programas de cdigo aberto. (x) A Licena neutra em relao a tecnologia - Nenhuma clusula da licena pode estabelecer uma tecnologia individual, estilo ou interface a ser aplicada no programa Como pode ser notado na leitura dos termos, na definio da licena Open Source no feita qualquer referncia a aspectos polticos, sociais e de liberdade, diferentemente da licena de software livre, proposta pela FSF, na qual o aspecto principal a liberdade. Em um software Open Source existe a possibilidade de que um software aberto seja fechado posteriormente e para ser distribudo como software proprietrio, algo no permitido pela licena do software livre. Stallman (2002) afirma que o objetivo do software Open Source produzir software poderoso e de alta qualidade, e que isso um objetivo louvvel, mas no o mais importante, pois o mais importante para ele que o software siga as quatro premissas do software livre. 2.1.3.1 Caractersticas do desenvolvimento Open Source Segundo Nunes (2007), os projetos Open Source apresentam algumas caractersticas que os tornam diferentes do paradigma de desenvolvimento convencional, como: (i) Trabalho voluntrio, uma vez boa parte dos desenvolvedores trabalham sem remunerao, (ii) Trabalho no designado, as tarefas ficam disponveis para os membros que tenham interesse ou aptido as escolham para realizar, (iii) Ausncia de cumprimento de horrios e de lista de entregas, uma vez que o trabalho voluntrio, as pessoas trabalham em horrios diversificados e contribuem da maneira que podem, (iv) lanamentos de verses, a prpria comunidade em conjunto com os mantenedores discute quando ser lanada uma nova verso do software e atualizaes da mesma, (v) teste, em projetos Open Source comum utilizar os usurios como testadores do software, assim como nem sempre existe um sistema bem definidos de testes de software e (vi) planejamento, nem sempre possvel devido ao no determinismo da colaborao.

22 Todavia, estas caratersticas no esto presentes em todas as comunidades, algumas comunidades podem ter caractersticas nicas ou no utilizar algumas das caratersticas citadas.

2.2 O Estudo da Motivao e suas Aplicaes ao Contexto da Engenharia de Software Nas subsees a seguir sero apresentados os conceitos de motivao na psicologia, no desenvolvimento de software e no contexto Open Source. 2.2.1 O Estudo da Motivao na Psicologia Segundo Todorov e Moreira (2005), o estudo da motivao humana vem sendo observado desde o comeo do sculo XX, com base na psicoterapia, na psicometria e nas teorias de aprendizagem. Frana e Da Silva (2009) afirmam que a definio de motivao tem resultado em diversas teorias, trazendo consigo, inclusive, diversas definies para o termo, conforme exemplificado na Tabela 1.
Tabela 1 - Evoluo do conceito de Motivao Ano 1959 1961 1964 Autores Krech e Crutchfield Young Atkinson O que motivao? Um motivo a uma necessidade ou desejo acoplado com a inteno de atingir um objetivo apropriado Uma busca dos determinantes (todos os determinantes) da atividade humana e animal. Uma concepo coerente dos determinantes contemporneos da direo, do vigor e da persistncia da ao. Motivo algo que incita o organismo ao ou que sustenta ou d direo ao quando o organismo foi ativado. Motivao um sentimento interno, um impulso que algum tem de fazer para realizar alguma coisa. ... a motivao o conjunto de mecanismos biolgicos e psicolgicos que possibilitam o desencadear da ao, da orientao (para uma meta ou, ao contrrio, para se afastar dela) e, enfim, da intensidade e da persistncia: quanto mais motivada a pessoa est, mais persistente e

1967

Hilgard e Atkinson

1997 2000

Rogers, Ludington e Graham Licury e Fenouillet

23
maior a atividade. 2001 Penna o conjunto de relaes entre as operaes de estimulao ou privao e as modificaes observadas no comportamento que se processa aps as citadas operaes. A motivao tem sido entendida ora como um fator psicolgico, ou conjunto de fatores ora como um processo. Estes fatores levam a uma escolha, instigam, fazem iniciar um comportamento direcionado a um objetivo. Fonte: Frana e Silva (2009)

2004

Bzuneck

Pode ser observado na Tabela 1 uma srie de conceitos sobre motivao, que possuem caractersticas semelhantes, como fatores psicolgicos e biolgicos, sendo um sentimento interno, que leva um indivduo a executar uma ao com intensidade e persistncia para maximizar o resultado. Isto corrobora com a definio apresentada por Minicucci (2009 apud Da SILVA et al 2011), que define motivao como sendo algo interno ao indivduo, que varia de acordo com o objetivo, apresentando direo, intensidade, fora e durao, determinando um comportamento. Todavia, um problema recorrente na literatura que aborda motivao a confuso que existe com outros fenmenos como entusiasmo, satisfao, conforto, alegria, necessidade, vontade, f, desejo e instinto (Da SILVA; FRANA, 2011; BERGAMINI, 1998; Da SILVA et al, 2011). Contudo, motivao se distingue destas palavras, pois ela intrnseca pessoa e pela sua capacidade de gerar um comportamento sustentvel e por isso deve ser analisada de maneira mais completa (Da SILVA et al, 2011). 2.2.2 Motivao no Desenvolvimento de Software De acordo com Sharp et al (2009), a motivao na Engenharia de Software reconhecida como um fator preponderante para o sucesso os projetos desse tipo. Alguns trabalhos foram realizados com o objetivo de explorar e delinear os fatores que motivam e desmotivam os engenheiros de software, bem como verificar quais os modelos de motivao existentes. Beecham et al (2007) realizaram uma reviso sistemtica na literatura na qual catalogaram 92 artigos sobre motivao em

24 Engenharia de Software, publicados entre os anos de 1980 a 2006. Tal estudo procurou responder as seguintes questes: (i) Quais as caractersticas dos engenheiros de software? (ii) O que (des)motiva engenheiros de software a serem mais produtivos ou menos produtivos? (iii) Quais so os sinais externos ou resultados de engenheiros de software (des)motivados? (iv) Quais aspectos da Engenharia de Software (des)motivam os engenheiros de software? (v) Quais os modelos de motivao existentes na Engenharia de Software? Frana et al (2011) realizaram uma atualizao desta reviso com o objetivo de responder as mesmas questes do estudo original, porm com artigos publicados no perodo de 2006 at 2010. Essa atualizao da reviso encontrou 53 artigos, os quais foram analisados para se chegar a novas evidncias, com relao ao estudo original, que reforam alguns resultados encontrados no trabalho de Beecham et al. (2007). Com a aplicao da pesquisa de Beecham et al (2007) foi observado que a motivao dos engenheiros de software definida por trs fatores que esto relacionados: caractersticas individuais, controles internos e moderadores externos. Alm disso, a pesquisa apresenta que engenheiros desmotivados tendem a deixar as organizaes onde trabalham, enquanto que o aumento de produtividade e a reteno de membros da organizao tende a serem resultados associados aos engenheiros motivados. O trabalho apresenta tambm a diviso em duas listas dos fatores que motivam (Tabela 2) e desmotivam (Tabela 3) o Engenheiro de Software com base em outros trabalhos da literatura como a teoria da motivao-higiene criada pelo psiclogo Frederick Herzberg (1923-2000).
Tabela 2 - Fatores Motivadores

Motivao para Engenheiros de Software

Recompensa e incentivos Variedade do trabalho Sensao de pertencimento a uma esquipe Trabalhar em uma empresa de sucesso Empowerement/ Responsabilidade Satisfao da necessidade de desenvolvimento Plano de Carreira Equilbrio entre a vida pessoal e profissional Participao Feedback

25
Bom gerenciamento Confiana/ respeito Trabalho tecnicamente desafiador Contribuir/ importncia da tarefa Autonomia Reconhecimento Equidade Segurana no emprego Condies apropriadas de trabalho Identificao com a tarefa

Recursos suficientes Adaptado de Da Silva et al. (2011) Tabela 3 - Fatores Desmotivadores

Desmotivadores Software
Risco Inequidade

para

Engenheiros

de

Sistema desleal de recompensa Comunicao Ruim Metas no realsticas

Stress Trabalho interessante feito por outras partes Falta de promoo Pagamento no competitivo Mau relacionamento com os colegas e usurios Ambiente de trabalho ruim (falta de recursos) Equidade

Gerenciamento ruim Produo de Software de m qualidade Falta de influncia

Adequao cultural ruim Adaptado de Da Silva et al (2011)

O principal fator motivador encontrado no trabalho de Beecham et al (2007) foi a identificao com a tarefa. Quanto mais o indivduo se identifica com a tarefa mais ele fica motivado. Outros fatores motivadores que tambm tiveram destaque so: participao, bom gerenciamento, plano de carreira e variedade da tarefa. No estudo realizado por Frana et al (2011), foi encontrado que os fatores mais recorrentes so: identificao com a tarefa, participao e bom gerenciamento. Outros fatores que tambm esto entre os mais citados so: boa auto-imagem, aprendizagem e auto-desenvolvimento. Quanto aos fatores desmotivacionais, o ambiente de trabalho ruim, com a falta de recurso se destaca como caracterstica mais citada, de acordo com o estudo de Beecham et al (2007). J o trabalho de Frana et al (2011) cita como principais: complexidade da tarefa (muito fcil ou muito difcil) e carga de trabalho. Entre os

26 fatores em comum do estudo de Frana et al (2011) com estudo de Beecham et al (2007) aparecem gerenciamento ruim e pagamento no competitivo. Sharp et al (2009) propem um novo modelo de motivao em Engenharia de Software, baseado em na teoria da motivao-higiene de Herzberg6, o qual eles denominam de MOCC (Motivators, Outcomes, Characteristics and Context). Esse modelo, apresentado na Figura 1, foca apenas nos resultados referentes aos fatores motivadores, j que para o autor a motivao e desmotivao so constructos diferentes.

Figura 1 - MOCC Fonte: Da Silva et al (2011)

Para mais informaes: http://www.sobreadministracao.com/tudo-sobre-a-teoria-dos-dois-fatores-de-frederickherzberg/

27

Figura 2 - Motivadores intrnsecos e extrnsecos Fonte: Da Silva et al (2011)

2.2.3 Motivao no contexto Open Source Segundo WU et al (2007) o software, no contexto Open Source,

desenvolvido espontaneamente por participantes de comunidades organizadas, localizadas ao redor do mundo e trabalhando com o auxilio da Internet. Tambm so caracterstica desse tipo de projeto os integrantes contriburem mesmo sem terem vnculos empregatcios, pagamentos ou mesmo sem serem recrutados pelas organizaes responsveis pelo produto em desenvolvimento (LERNE;TIROLE, 2002). Nas sees 2.2.3.1, 2.2.3.2, 2.2.3.3 so apresentados estudos que abordam os motivos dos engenheiros de software contriburem voluntariamente, com seu tempo e habilidades, em projetos Open Source. Aps isso, ser feito uma considerao final sobre os assuntos.

28 2.2.3.1 WU et al (2007)

Este trabalho investiga a inteno dos desenvolvedores de software Open Souce de continuarem envolvidos em projetos futuros, identificando os fatores que os influenciam para isso. Para realiza-lo o autor desenvolveu um modelo de pesquisa emprico, validado com 148 participantes e utilizando a escala de Likert7. Com base na reviso de literatura o autor encontra uma lista de fatores extrnsecos e intrnsecos envolvidos no Open Source. Os fatores extrnsecos, segundo o autor, so os fatores ambientais, interpostos pela organizao a um indivduo. Os motivadores intrnsecos, tambm chamados de motivadores internos, esto relacionados s necessidades do indivduo. Vale destacar que neste trabalho o autor no analisou o conjunto completo de possveis motivadores, se concentrando, ento, naqueles que ele acredita terem efeito mais forte, que so: (i) Comportamento de ajuda: Wu et al (2005) acredita que o altrusmo natural do ser humano, e exibido de alguma maneira por todos. Baseado nesse ponto de vista acredita-se que os desenvolvedores contribuem porque eles gostam de estender a mo aos outros e, simultaneamente, gostam de ter a mesma ajuda quando precisam. (ii) Aprimoramento do capital humano: O capital humano um dos incentivos extrnsecos envolvidos no software Open Source. Sendo assim, o capital humano envolve o acumulo de investimentos das pessoas na sua educao e no treinamento do trabalho que elas desenvolvem no dia-a-dia. (iii) Progresso na carreira: Baseado em outros estudos, acredita-se que a participao em um projeto Open Source pode avanar a carreira de uma pessoa de duas maneiras: atravs da demonstrao de suas capacidades e habilidades para potenciais empregadores; usando a participao em projetos para obter acesso ao capital de risco, aquisio de aes ou para lanar um empreendimento empresarial. (IV) Satisfao de necessidades pessoais: Vrios projetos Open Source comeam porque os desenvolvedores no conseguem encontrar produtos que satisfazem uma

uma escala onde os respondentes so solicitados no s a concordarem ou discordarem das afirmaes, mas tambm a informarem qual o seu grau de concordncia / discordncia.

29 funo em particular, dessa forma, o software e o conhecimento necessrio para utiliz-lo provm um valor extrnseco para o desenvolvedor. Alm disso, para sua pesquisa WU et al (2007, traduo nossa p.259) tambm relaciona o nvel de satisfao com o projeto afirmando que: A satisfao (em trabalhar em um projeto Open Source) deve depender de suas expectativas ps-participao contra a sua percepo de valncia para o seu desempenho, ou seja, a reao emocional s suas prprias motivaes. De acordo com Reilly (2005), a baixa satisfao no trabalho pode levar a comportamentos de indisciplina e sabotagem. Em contraste, a satisfao no trabalho pode aumentar o

comprometimento organizacional e a cidadania (LEE; MODAWY, 1987). Neste trabalho, o fator satisfao com a participao em projetos Open Souce a influncia mais forte na participao em futuros projetos, seguido de: aperfeioamento do capital humano e satisfao de necessidade pessoal. Ou seja, os membros quando satisfeitos com sua particio em algum projeto Open Source tendem a continuar participando em futuros projetos. 2.2.3.2 Oreg e Nov (2007)

Oreg e Nov (2007) examinaram como o contexto de projetos Open Source e os valores pessoais dos contribuintes esto relacionados com os tipos de motivao deles. Para isso eles usaram um survey, que foi aplicado a 300 contribuintes, em dois contextos Open Source: Software e Contedo. O autor encontrou que os contribuintes do contexto de software do maior nfase sobre a reputao e as motivaes de auto-desenvolvimento, enquanto que os contribuintes do contexto de contedo (mantenedores da Wikipedia, por exemplo) do maior nfase nos motivos altrustas. Para realizar sua pesquisa o autor encontrou e classificou os seguintes fatores motivadores: (i) Reputao: Os autores acreditam, assim como Lakhani e Wolf (2005), que empresas procuram programadores com habilidades especiais e podem encontrar essas habilidades examinando cdigos de software Open Source.

30 Assim, ganhar reputao pode ser extremamente interessante para quem quer progredir a carreira na indstria de Software (LERNER; TIROLE, 2002). (ii) Desenvolvimento prprio (aprendizado): Raymond (1999) afirma que o processo de desenvolvimento de software Open Source envolve um mecanismo de reviso de pares intensivo. Atravs deste processo os colaboradores recebem feedback e podem obter sugestes de estilos de programao e lgicas para melhorar suas habilidades profissionais (LAKHANI; WOLF, 2005). (iii) Altruismo: Para Oreg e Nov (2007), o altruismo um motivador tanto no contexto de desenvolvimento quanto no contexto de contedo, s que por motivos diferentes. No contedo as pessoas querem compartilhar o conhecimento que elas detm (BONACCORSI; ROSSI, 2003); enquanto que no contexto de software as pessoas esto mais focadas no que elas podem ganhar do outros na comunidade e nas implicaes no crescimento da prpria carreira (LERNER; TIROLE, 2002). Para realizar sua pesquisa os autores utilizaram quatro valores de Schwartz (1994) que eles acreditavam que teriam as seguintes relaes com os trs fatores: (i) Realizao com Reputao, pois os desenvolvedores pretende demostrar sua competncia para comunidade; (ii) Autodireo com Desenvolvimento prprio, j que para o autor envolve a criatividade e liberdade; (iii) Benevolncia e Universalismo com Altrusmo, j que ambos, segundo os autores, promoviam o bemestar do prximo. Como resultado da pesquisa, os autores encontraram que motivao para construir uma reputao em Open Source est correlacionada com nfase do valor da realizao do individuo. J a motivao para melhorar as suas competncias (Desenvolvimento prprio) est associada com sua nfase pessoal em autonomia, crescimento e livre pensamento. A motivao de ajudar a comunidade Open Source est ligada ao valor da promoo do bem-estar ao prximo. Embora a reputao, conforme a hiptese dos autores, era para ser mais forte no contexto de software do que no contexto de contedo, foi, no entanto, de forma inesperada o fator de motivao mais fraco dos trs, em ambos os contextos. Oreg e

31 Nov (2007) acreditavam que exigncia dos contribuintes em tornar pblica a sua experincia tornaria a reputao o fator mais forte, ao invs de mais fraco, em ambos os contextos. 2.2.3.3 Von Krogh et al (2008)

Von Krogh et al (2008) identificaram na literatura os principais fatores motivacionais ligados aos projetos Open Souce. Os autores dividem os fatores em: (i) motivacionais intrnsecos (Tabela 4), tambm chamados de motivadores internos, que esto relacionados com as necessidades que satisfazem o indivduo; (ii) Motivacionais extrnsecos (Tabela 5), que so os fatores ambientais interpostos pela organizao a um indivduo; (iii) fatores motivacionais extrnsecos internos (Tabela 6), que so definidos como auto-reguladores de comportamento, diferenciando dos fatores extrnsecos porque estes so imposies externas (VON KROGH et al, 2008). Na reviso de literatura foram adotados mtodos de anlise crtica, qualitativa e sinttica, com quatro passos principais na identificao do material. Primeiro, foi identificado artigos listados no banco de dados da Institute for Scientific Information, que continham as palavras chaves Open Source software e motivao. O segundo passo foi revisar a lista de referncias dos artigos encontrados para procurar novas fontes que no foram listados na primeira etapa ou artigos excludos por conta dos critrios utilizados. No terceiro passo, os pesquisadores navegaram por repositrios de artigos on-line (por exemplo, www.opensource.mit.edu) para identificar artigos que correspondem aos critrios de pesquisa. Em quarto lugar, com artigos de conferncias e captulos de livros que eram conhecidos pelos pesquisadores e colegas de trabalho que ainda no tinham constado nas pesquisas. Trabalhos tericos e conceituais foram examinados buscando-se fatores motivacionais usados para criar a teoria. Fatores motivacionais que se mostraram relevante em trabalhos empricos tambm foram includos na reviso. A incluso de trabalhos empricos compreensiva, considerando que a incluso das contribuies puramente tericas mais seletiva (Von KROGH et al, 2008). Se um estudo utilizou uma terminologia diferente, mas a motivao parecia suficientemente com uma j existente na taxonomia, esta foi incorporada a taxonomia existente.

32

Tabela 4 - Fatores Motivacionais intrnsecos Motivao Ideologia Conceito Ideologia citada como um dos principais motivos para iniciar um projeto Open Source. Pode ser observada com o uso de termos como: Software deve ser livre para todos, ou o cdigo aberto deve substituir o software proprietrio. a preocupao pelo bem-estar do prximo. Trabalhos Relacionados HEMETSBERGER (2004); GHOSH, (2005); DAVID et al. (2003); LAKHANI e WOLF (2005); HERTEL et al. (2003); GOSAIN (2006); OSTERLOH e ROTA (2007); LINDENBERG (2001); HEMETSBERGER (2004); HARS e OU (2002); GHOSH (2005); BENKLER (2002); OSTERLOH e ROTA (2007); LAKHANI e VON HIPPEL (2003); LUTHIGER e JUNGWIRTH (2007); LAKHANI e WOLF (2005); HERTEL et al. (2003); ROBERTS et al. (2006); ZEITLYN (2003); HEMETSBERGER (2004); HARS e OU (2002); LAKHANI e WOLF (2005);

Altrusmo

Prazer e diverso

Prazer e diverso so impulsionadores da cultura hacker que emergiu na dcada de 1980.

Amigos de Sangue (Kinship Amity)

um tipo de organizao social, onde cada famlia (casta) tende a fazer tudo pelo sucesso da prpria famlia, ou dos seus prprios membros. Adaptado de Von KROGH et al (2008)

Tabela 5 - Fatores Motivacionais extrnsecos internos Motivao Reputao Conceito A reputao pode ser classificada como: reputao interna, quando direcionada aos membros da comunidade ou potenciais empregadores, e externa vem de fora da comunidade e de outras pessoas significantes, como amigos. Trabalhos Relacionados RAYMOND (1998); STEWART (2005); LERNER e TIROLE (2002); OSTERLOH e ROTA (2007); LAKHANI e VON HIPPEL (2003); LATTEMANN e STIEGLITZ (2005); SPAETH et al (2008); LAKHANI e WOLF (2005); HEMETSBERGER (2004); HARS e OU (2002); GHOSH (2005) LAKHANI e WOLF (2005); ROBERTS et al (2006); STEWART (2005); HEMETSBERGER (2004); HERTEL et al (2003);

33
Motivao Reciprocidade / Economia da doao Conceito Para o desenvolvimento Open Source a economia da doao faz com que os desenvolvedores distribuam seu cdigo esperando que haja reciprocidade. Trabalhos Relacionados BERGQUIST e LJUNGBERG (2001); HEMETSBERGER (2004); LAKHANI e WOLF (2005); DAVID et al (2003); LAKHANI e VON HIPPEL (2003); GHOSH (2005); HEMETSBERGER (2004); LAKHANI e WOLF (2005); WU et al (2007); ROBERT et al (2006) YE e KISHIDA (2003); LAVE e WENGER (1991); RULLANI (2007); RAYMOND (1999); LAKHANI e VON HIPPEL (2003); OSTERLOH e ROTA (2007); GHOSH (2005); DAVID et al (2003); HARS e OU (2002); LAKHANI E WOLF (2005); WU et al (2007) ; HARS e OU (2002); HERTEL et al (2003); ROBERTS et al (2006);

Aprendizado

a motivao de aprender novas habilidades ou a oportunidade de experincia de desenvolver software e t-lo testado e comentado por outras pessoas aps o lanamento.

Valor de uso prprio

a motivao de criar software para uso prprio, ou seja, resolver algum problema que os aplicativos atuais no conseguem resolver de maneira satisfatria.

Adaptado de Von KROGH et al (2008)

Tabela 6 - Fatores Motivacionais extrnsecos Motivao Carreira Conceito Os desenvolvedores so motivados por preocupaes na carreira. Publicar um software livre pode mostrar seu talento para potenciais empregadores, aumentado, assim, seu valor no mercado de trabalho. Uma minoria significativa (aproximadamente 40%) dos colaboradores so pagos para participar de projetos Open Source. O conceito semelhante ao de uma empresa de software proprietrio em que o desenvolvedor ganha por produo. Adaptado de Von KROGH et al (2008) Trabalhos Relacionados LAKHANI e WOLF (2005); HEMETSBERGER (2004); WU et al (2007) ; HARS e OU (2002); ROBERTS et al (2006); GHOSH (2005); LAKHANI e WOLF (2005); HARS e OU (2002); HERTEL et al. (2003); LUTHIGER e JUNGWIRTH (2007); DAHLANDER AND WALLIN (2006);

Pagamento

34 2.3 Discusso O trabalho de Von Krogh et al (2008) foi de suma importncia para a

pesquisa realizada, pois forneceu anlise bastante abrangente e permitiu a identificao de uma taxonomia dominante na literatura, utilizada para agrupar os fatores de motivao identificados depois que a codificao ficou pronta. Em sua pesquisa, foram encontrados 10 fatores ao todo, sendo dois fatores motivacionais extrsicos (Carreira e Pagamento), quatro fatores motivacionais intrsicos (Altruismo, Ideologia, Prazer, e Amigos de sangue) e quatro fatores motivacionais extrnsecos internos (Reputao, Reciprocidade, Valor de uso prprio e aprendizado). Os trabalhos de Wu et al (2008) e Oreg e Nov (2007) fornecem proposies que ajudam a entender melhor algumas questes inerentes ao desenvolvimento de software Open Source. Baseado no referencial terico desenvolvido neste captulo foi possvel realizar a pesquisa e escolher uma metodologia a ser utilizada para se obter sucesso na realizao da mesma.

35 3 MTODOS Neste captulo exposta a metodologia adotada para a realizao deste trabalho. Segundo Pinheiro (2010, p.20), o mtodo cientfico o conjunto de processos ou operaes mentais que se deve empregar na investigao cientfica. 3.1 Natureza da Pesquisa 3.1.1 Quanto aos Fins Esta pesquisa pode ser classificada como descritiva e exploratria. Ela descritiva, pois visa descrever caractersticas de um fenmeno e exploratria porque visa conhecer inicialmente o tema de estudo. Segundo Pinheiro (2010, p.21), a pesquisa exploratria visa proporcionar maior familiaridade com o problema com vistas a torn-lo explcito ou a construir hipteses. Ainda segundo este autor, a pesquisa descritiva visa descrever as caractersticas de determinada populao ou fenmeno ou o estabelecimento de relaes entre variveis. Este trabalho tem como principal caracterstica descobrir como os principais fatores motivacionais que afetam os engenheiros de software no contexto de desenvolvimento de software Open Source agem na comunidade Android-BrasilProjetos. 3.1.2 Quanto Forma de Abordagem Quanto forma de abordagem, a pesquisa classifica-se como qualitativa, utilizando o paradigma interpretativo-construtivista. Segundo Neves (1996, p.1):
A pesquisa qualitativa costuma ser direcionada, ao longo de seu desenvolvimento; alm disso, no busca enumerar ou medir eventos e, geralmente, no emprega instrumental estatstico para anlise dos dados; seu foco de interesse amplo e parte de uma perspectiva diferenciada da adotada pelos mtodos quantitativos.

Desta forma, esta pesquisa busca investigar os fatores que motivam os engenheiros de software na realizao do seu trabalho a partir dos relatos das entrevistas. Alm disso, a pesquisa utilizar como abordagem o mtodo indutivo, que, segundo Marconi e Lakatos (2004, p.53), a partir de dados especficos e

36 suficientemente constatados, infere-se uma verdade geral. Marconi e Lakatos (2004 p.54) consideram trs etapas para essa abordagem: Observao dos fenmenos: Observar e analisar os fenmenos, a fim de descobrir as causas da sua manifestao; Descoberta da relao entre eles: comparar buscando identificar similaridades ou diferenas entre os fatos ou fenmenos, com o objetivo de descobrir relacionamento entre eles; Generalizao da relao: generalizar os relacionamentos

encontrados na etapa semelhantes.

anterior, entre os fatos e fenmenos

A partir de dados coletados de um grupo de participantes deseja-se chegar a uma teoria fundamentada, baseada em interpretaes e abstraes, objetivando identificar os principais fatores motivacionais que afetam os engenheiros de software no contexto de desenvolvimento de software Open Source na comunidade AndroidBrasil-Projetos. Todavia, neste trabalho no ser realizada a generalizao da relao. 3.1.3 Quanto aos mtodos de procedimentos Conforme Marconi e Lakatos (2004), os mtodos de procedimentos so etapas mais concretas de uma pesquisa, com uma finalidade mais restrita de explicao geral dos fenmenos. Para esse trabalho o procedimento adotado foi o estudo de caso. Yin (2005, traduo nossa p. 32) descreve que:
um estudo de caso investiga um fenmeno contemporneo dentro do seu contexto da vida real, especialmente quando os limites entre o fenmeno e o contexto no esto claramente definidos.

Segundo Runeson e Host (2008), na Engenharia de Software um caso pode ser: um projeto de desenvolvimento de software, uma tecnologia, indivduo, grupo de pessoas, um processo, entre outros. J uma unidade de anlise pode ser constituda por um projeto, indivduo, grupo, entre outros. De acordo com Yin (2005), este trabalho um estudo de caso holstico de caso nico. Holstico porque a unidade de anlise o engenheiro de software, pois o objetivo da pesquisa estudar os fenmenos e aspectos que influenciam a

37 motivao dos indivduos ligados rea de Engenharia de Software no contexto Open Source, abrangendo os seguintes perfis nesta categoria: desenvolvedores, mantenedores, contudo, sendo focada nos desenvolvedores. Caso nico, no qual considerada a organizao como caso representativo, que se deseja investigar os acontecimentos que motivam ou desmotivam os engenheiros de software na realizao das suas atividades. 3.2 Premissas Este estudo tem como premissa a existncia de fatores que influenciam na motivao, em projetos Open Source, dos engenheiros de software relacionados rea de Engenharia de Software, s atividades tcnicas, ao trabalho em equipe, alm de aspectos organizacionais que influenciam os indivduos. Tambm se acredita que existam indicativos ou sinais percebidos pelos indivduos quando da ocorrncia da motivao e que suas aes e comportamento influenciam o resultado do seu trabalho, assim como, se considera que as aes organizacionais, para motivar os indivduos, podem ser influenciadas pelo conceito que a organizao apresenta sobre o tema. 3.3 Etapas de pesquisa As etapas de pesquisa utilizadas foram baseadas no trabalho de Frana et al (2011). Foram feitas alteraes no protocolo base para adequ-lo ao contexto de Open Source. De inicio, foi realizada uma reviso bibliogrfica para adquirir um conhecimento maior sobre motivao e desenvolvimento de software Open Source. Com isso, foram encontrados trabalhos que abordavam os seguintes temas: conceitos bsicos de motivao e software Open Source, revises sistemticas da literatura envolvendo motivao na Engenharia de Software e motivao no contexto Open Source. Foram considerados nessa reviso livros, artigos cientficos e dissertaes acadmicas escritos em Portugus ou Ingls. Depois desta etapa, foram utilizadas as revises sistemticas na literatura sobre motivao na Engenharia de Software e motivao no desenvolvimento de software Open Source. A partir destas revises iniciais, sobre os temas, as questes

38 de pesquisa foram refinadas. Aps esta fase foi realizada uma adaptao no roteiro de entrevista utilizado por Frana et al (2011), de forma a enquadra-lo ao contexto Open Source. Dando sequncia a pesquisa, foi realizada a coleta de dados atravs de entrevistas via Skype8 com envolvidos no desenvolvimento de software Open Source, a saber: desenvolvedores e mantenedores de projetos da comunidade Android-Brasil-Projetos. Os dados coletados foram transcritos para anlise utilizando os procedimentos da Teoria Fundamentada (Grounded Theory) (STRAUSS; CORBIN, 2008). Com base nesta metodologia, os dados foram codificados utilizando codificao aberta, codificao axial e codificao seletiva. Como resultados destes procedimentos foram derivadas preposies e histrias para gerao de uma teoria fundamentada nos dados (Frana et al 2011). 3.4 Seleo de sujeitos A seleo de sujeitos foi realizada utilizando o critrio de convenincia, abordando indivduos atravs da melhor acessibilidade. Os dados adquiridos so do tipo primrio, ou seja, foram conseguidos diretamente pelo pesquisador atravs das tcnicas escolhidas (entrevistas) (GIL, 2008). Foi utilizado a auto-seleo9 de amostragem que til quando se quer permitir que os indivduos possam escolher se desejam participar da pesquisa voluntariamente, todavia os indivduos no so abordado pelo pesquisador diretamente(LAERD [s.d]). Para isso foi enviado um e-mail, no dia 07/05/2012, para o Grupo do AndroidBrasil-projetos, perguntado aos membros quem gostaria de participar das pesquisas. Os membros que aceitaram o convite enviaram um e-mail de reposta ao pesquisador e foram contatados posteriormente para marcar a entrevista. 3.4.1 Entrevista Para o desenvolvimento deste trabalho foram realizadas entrevistas, que, na opinio de Runeson e Host (2008 apud Da SILVA et al 2011), so muito importantes

8 9

Skpe um software de comunicao de voz e vdeo, para mais informaes http://www.skype.com Para mais informaes sobre auto-seleo: http://dissertation.laerd.com/articles/self-selection-sampling-anoverview.php

39 como fonte de evidncias e, de acordo com Seaman(1999 apud Da SILVA et al, 2011), so comumente empregadas como tcnicas de coletas de dados em pesquisas qualitativas. Desta forma, o objetivo das entrevistas foi realizar um levantamento dos fatores que motivavam os engenheiros de software Open Source no

desenvolvimento dos projetos, na execuo das suas tarefas, no seu trabalho em equipe, alm da percepo dos mesmos sobre caractersticas organizacionais que influenciavam na sua motivao e desmotivao para o trabalho. Pinheiro (2010 p. 35) define que a entrevista serve para se obter informaes do entrevistado sobre determinado assunto e podem ser divididas como estruturadas, ou no estruturadas. Queiroz (1988 apud DUARTE, 2002) afirma que existe mais um tipo de entrevista alm dos apresentados por Pinheiro (2010 p.35): a entrevista semiestruturada, que uma tcnica de coleta de dados que supe uma conversao continuada entre informante e pesquisador que deve ser dirigida por este de acordo com seus objetivos. Neste estudo de caso, o tipo de entrevista adotado foi o de entrevista semiestruturada, no qual no existe rigidez no roteiro e algumas questes podem ser mais exploradas, bem como, durante entrevista, pode-se decidir por se seguir uma ordem diferente do roteiro, ou seja, no necessariamente todas as questes precisam ser feitas e outras podem surgir de acordo com o andamento do processo (SEAMAN, 1999 apud Da SILVA et al , 2011). Assim como no roteiro proposto por Da Silva et al (2011), este trabalho se preocupou em adaptar as perguntas para que os entrevistados se sintam estimulados a responder as questes de pesquisa, o roteiro original e os roteiros adaptados podem se observados nos Apndices B e C. Para isso, o roteiro foi desenvolvido de maneira que cada questo do roteiro de entrevista fosse classificada segundo um conjunto de seis tipos de questes conforme, Merriam (2009 apud Da SILVA et al, 2011), de forma semelhante ao trabalho desenvolvido por Da Silva et al (2011). Experincia e comportamento: Nesta categoria as questes visam obter informaes de comportamento ou experincia do entrevistado;

40 Opinio e valor: Nesta categoria a inteno obter a opinio ou crena referente a alguma coisa por parte do entrevistado; Sentimento: Quando o pesquisador deseja focar na dimenso afetiva humana do participante, procurando adjetivos como respostas, exemplo: alegre, medo, intimidado, comprometimento, distrado, entre outros; Sensoriais: Tem um foco maior em saber sobre o que o entrevistado ouviu, escutou, entre outros; Conhecimento: Neste tipo de questo o objetivo obter do participante o seu conhecimento sobre alguma situao; Background: Este tipo de questes serve para obter uma viso geral do entrevistado como idade, renda e escolaridade. Da Silva et al (2011) evitou desenvolver alguns tipos de questes, que tambm sero evitadas nessa pesquisa: Mltiplas questes: Evitar elabora uma srie de questes dentro de uma nica pergunta, levando o entrevistado a se perder nas respostas e no responder uma por uma; Questo principal: Evitar perguntar ao entrevistado questes principais da pesquisa; Questes sim ou no: Evitar elaborar questes que podem ser respondidas simplesmente com um sim ou um no. Para este trabalho foram adaptados dois diferentes roteiros de entrevista que foram desenvolvidos para os perfis de engenheiros de software Open Source, coordenadores/gerentes/lideres de projetos Open Source. Os participantes da pesquisa foram contatados pelo e-mail do grupo. Posteriormente, os que aceitaram participar da pesquisa foram contatados pelo email pessoal com antecedncia realizao das entrevistas para marcar um melhor dia e horrio. As entrevistas no estruturadas foram agendadas e conduzidas utilizando o Skype, de forma individual. No momento da entrevista foi feita a

apresentao de detalhes da pesquisa, citando o grupo de pesquisadores responsveis, poltica de confidencialidade, objetivos e resultados esperados. Foi entregue um termo de confidencialidade (Apndice A) e a coleta de autorizao

41 realizada. O pesquisador solicitava autorizao verbal para gravar as entrevistas e, se permitido, as entrevistas eram gravadas. 3.5 Procedimentos da anlise de dados Este trabalho, assim como o desenvolvido por Da Silva et al (2011), adotou mtodos de anlise de dados qualitativos, devido a semelhana de abordagem. Segundo Runeson e Host (2008 apud Da Silva et al 2011) e Seaman (1999 apud Da Silva et al 2011), os mtodos de uma anlise de dados qualitativos podem ser divididos em duas categorias que podem ser utilizadas em estudos de caso. Da Silva et al (2011) justifica a utilizao desses mtodos a fim de fundamentar os resultados baseados e evidenciados a partir dos dados. Gerao de teoria: Segundo Da Silva et al (2011), geralmente utilizada com o objetivo de extrair um conjunto de declaraes e proposies fundamentadas em dados, a partir de algum trecho de transcries e refinadas e modificadas sobre outras passagens relacionadas. Da Silva et al (2011 p.44) ainda afirma que: Estes mtodos so frequentemente chamados de grounded theory ou teoria fundamentada nos dados, pois as teorias ou hipteses geradas so fundamentadas nos dados. Neste trabalho foram usados alguns aspectos de grounded theory que sero mencionados a seguir, todavia pela quantidade de dados, no foram gerados hipteses e sim proposies, alm disso, essas proposies geram indcios de uma teoria da motivao que atua somente na comunidade Android-Brasil-Projetos, muito embora acredita-se que os fatores encontrados possam ser observados em outras comunidades, eles devem ser mais bem estudados antes de serem aplicados em outras comunidades. 3.5.1 Teoria Fundamentada em Dados (Ground Theory) A abordagem utilizada nesta pesquisa chamada de Teoria Fundamentada em Dados. Ela foi desenvolvida por dois socilogos (Glaser e Strauss) para ser utilizada na pesquisa qualitativa. A escolha dessa forma de abordagem se d pela sua grande aceitao por pesquisadores qualitativos (STRAUSS; CORBIN, 2008).

42 Easterbrook (2008) acredita que na Teoria Fundamentada em Dados a anlise inicial dos dados desenvolvida sem categorias pr-estabelecidas, pois os padres de interesse relacionados ao contexto da pesquisa emergem a partir de comparaes realizadas repetidamente pelo pesquisador a partir dos dados existentes. Para Strauss e Corbin (2008), o nome Teoria Fundamentada em Dados significa que a teoria foi desenvolvida a partir dos dados, sistematicamente coletados, e analisados por meio de um processo de pesquisa. Para Da Silva et al (2011), na Teoria Fundamentada em Dados as hipteses so elaboradas como parte integrante da metodologia e que as hipteses tm como objetivo obter entendimento dos fenmenos, no caso desta pesquisa foram geradas proposies, como abordado anteriormente, e que a abrangncia da teoria usada est circunscrita ao espao amostral utilizado, a comunidade Open Source AndroidBrasil-Projetos. Kimura et al (2003) acredita que a abordagem metodolgica da Teoria Fundamentada em Dados proporciona algumas dificuldades prticas, como, a quantidade de tempo que o pesquisador precisa para proceder coleta, codificao e o grande volume de dados a serem analisados, a exposio do pesquisador com os participantes para criar um "clima" de interao (Sheldon, 1998 apud Kimura et al 2003). Kimura et al (2003) acredita, tambm, que outro ponto que deve ser considerado pelo pesquisador a busca pela eliminao consciente das crenas preconcebidas a respeito do fenmeno em estudo, a fim de permitir que os dados apontem a identificao dos conceitos e suas inter-relaes, desenvolvendo, dessa forma, uma teoria descontaminada de preconceitos do pesquisador. 3.5.2 Procedimento de codificao Os procedimentos de codificao utilizados nesta pesquisa so semelhantes aos utilizados por Da Silva et al (2011) em sua pesquisa. Da Silva et al (2011) acredita que o procedimento de codificao tem como entrada a transcrio na ntegra das gravaes de entrevistas e notas de campo obtidas no processo de coleta de dado.

43 Da Silva et al (2011) ressalta ainda que no um processo esttico e rgido, pois ele justamente o contrrio, j que o pesquisador evolui a sua anlise e interpretao dos dados de forma criativa oscilando entre os trs tipos de codificao, e na utilizao de tcnicas e procedimentos analticos. Os trs tipos do processo de codificao devem ser encarados como formas diferentes de tratar o material nesse caso os dados. (FLICK, 2009 apud Da SILVA et al 2011; STRAUSS ; CORBIN, 2008, p. 67). Existem duas ferramentas analticas que so importantes para o

desenvolvimento de uma teoria e muito utilizadas durante as trs etapas de codificao, que tem por objetivo ajudar o pesquisador a entender e reconhecer o que realmente est contido no texto (STRAUSS e CORBIN, 2008; Da SILVA et al , 2011): a) Formulao de perguntas: As perguntas quem?, quando?, por qu?, onde?, o que?, como?, com que resultados?, so uteis para o pesquisador quando ele est com dificuldades durante uma anlise sem conseguir enxergar explicaes dos fenmenos. Da Silva et al (2011) ainda destaca que o objetivo da formulao de perguntas no gerar dados e sim formas e ideias de como olhar para os dados. b) Comparaes: uma maneira que estimula o pensamento do pesquisador no desenvolvimento de propriedades e dimenses de uma categoria. Comparao incidente por incidente, com o objetivo de identificar propriedades, significa comparar um incidente a outro buscando similaridades e diferenas entre eles. Segundo Da Silva et al (2011), durante a anlise de dados, esse procedimento utilizado

quando no se consegue classificar ou nomear um incidente porque ainda no se tem um entendimento aprofundado. Utilizando um pensamento comparativo e metforas o pesquisador pode encontrar situaes e propriedades que o ajudem a desenvolver uma categoria.

44 3.5.2.1 Codificao Aberta Durante a codificao aberta se dar incio ao processo de confrontar os incidentes aplicveis em cada categoria (GLASER & STRAUSS, 1967 apud CASSIANI et al, 1996). Segundo Cassiani et al (1996), o investigador codifica os incidentes em tantas categorias quanto possvel. Todos os dados so passveis, neste momento, de uma codificao. A codificao o processo em que os dados so codificados, comparados com outros dados e designados em categorias. Da Silva et al (2011) afirma que a codificao aberta uma srie de passos analticos cuja finalidade a identificao de categorias com suas propriedades e dimenses. Segundo este autor, o passo inicial a rotulao de conceitos, a partir de pores do texto. Essas pores de texto que foram transcritos recebem um conceito, que um nome que os representa dentro do contexto da pesquisa, podendo ser uma palavra, uma linha, uma frase ou um pargrafo que foi conceituado a partir da identificao nos dados de incidentes, ideias, eventos, atos, acontecimentos ou fatos (STRAUSS; CORBIN, 2008, p. 103-107; FLICK, 2009, p.277-279 apud Da SILVA et al, 2011). Strauss e Corbin (2008) expem o conceito como um fenmeno rotulado a partir dos dados, que a representao abstrata de um fato, ideia ou acontecimento que o pesquisador julgou importante dentro do contexto da pesquisa. Da Silva et al (2011) explica que a identificao de conceitos linha por linha para incio de uma pesquisa a mais indicada, j que o pesquisador ainda est se acostumando com os dados e isso o ajuda a entender o que est ocorrendo. Outra indicao para conceituao linha por linha para algum trecho do texto que no est claro. Outra forma codificar uma frase ou pargrafo inteiro, dessa maneira deve-se perguntar e tentar identificar Qual a principal ideia revelada por essa sentena ou pargrafo? (STRAUSS e CORBIN, 2008, p. 120). Depois de abrir o texto e identificado alguns conceitos, o passo seguinte do procedimento o agrupamento desses conceitos em um conceito mais abstrato, que deve ter a capacidade de explicar O que est acontecendo aqui?. Esse agrupamento de conceitos identificado como uma categoria. Categorias so conceitos mais abstratos derivados dos dados que representam um fenmeno (um

45 problema, uma questo, preocupaes ou assuntos) que tem a capacidade de explicar O que est acontecendo aqui? (STRAUSS; CORBIN, 2008; FLICK, 2009 apud Da SILVA et al , 2011). As categorias descobertas devem ser desenvolvidas em termos de suas propriedades e dimenses. Um exemplo utilizado para representar isso o conceito de cor. Suas propriedades podem ser tonalidade, intensidade e matiz. Onde cada uma dessas propriedades pode ser dimensionada. Uma tonalidade mais clara ou mais escura, uma intensidade maior ou menor. (STRAUSS e CORBIN, 2008;

FLICK, 2009 apud Da SILVA et al, 2011). Da Silva et al (2011) acredita que no final da codificao aberta o resultado dever ser uma lista de cdigos e categorias com suas propriedades e dimenses. Para complementar, o pesquisador pode se utilizar de memorandos e anotaes a fim de explicar e registrar suas observaes e pensamentos sobre cada categoria gerada. 3.5.2.2 Codificao Axial

Segundo Da Silva et al (2011), aps a codificao aberta, deve ser feita uma codificao axial, que tem como objetivo relacionar as categorias resultantes da codificao aberta com s suas subcategorias para que se tenha um maior poder explanatrio sobre os fenmenos. Da Silva et al (2011) afirma que subcategorias so categorias, porm no lugar de representar um fenmeno, elas tm a capacidade de responder as seguintes perguntas sobre os fenmenos (de que forma?, quando?, como?, por qu?, para que?, com que consequncias?, entre outros). Ao identificar essas subcategorias, comea-se a descobrir relaes entre as categorias de forma a contextualizar melhor o fenmeno estudado (STRAUSS; CORBIN, 2008; FLICK, 2009 apud Da SILVA et al, 2011). Strauss e Corbin (2008) apresentaram um mecanismo analtico conceitual em relao aos dados para organizar a formulao desse relacionamento chamado paradigma. Segundo Da Silva et al (2011), a ideia desse mecanismo apoiar o esclarecimento e a identificao das relaes entre um fenmeno, identificando

suas causas, consequncias e estratgias de aes envolvidas. Os termos utilizados no paradigma fornecem uma linguagem familiar e lgica facilitando a discusso. A

46 seguir sero apresentados os termos de acordo Strauss e Corbin (2008) e Flick (2009 apud Da SILVA et al, 2011): Fenmeno: Na codificao, fenmeno uma categoria que responde a pergunta o que est acontecendo aqui?, so padres de acontecimentos, fatos ou aes que as pessoas, ou grupo de pessoas, fazem respondendo a situaes ou problemas nas quais elas esto envolvidas. Condies: Agrupamento de conceitos com respostas a questes do tipo:

"como", "por que", "quando", "de que forma". Forma uma estrutura contextual, ou conjunto de situaes ou circunstncias na qual os fenmenos esto envolvidos. Aes/interaes: Surgem a partir das condies. So respostas

estratgicas, ou rotineiras das pessoas, grupo de pessoas ou organizaes a problemas, acontecimentos ou fatos. Consequncias: So os resultados (consequncias) das aes/interaes.

Sempre que acontece uma ao/interao ou a ausncia delas, seja por uma pessoa, grupo ou organizao em relao algum problema, questo ou evento, h alguma consequncia envolvida. Entender essas consequncias bem como a forma como elas alteram o fenmeno possibilita a obteno de explicaes mais completas sobre o fenmeno Quando se identificam a relao entre as categorias e a associao com suas subcategorias, junto com a utilizao do mecanismo paradigma, o pesquisador comea a identificar o que so condies, aes/interaes e consequncias. 3.5.2.3 Codificao Seletiva

De acordo com Da Silva et al (2011), o ltimo passo do processo de codificao a codificao seletiva, que tem como objetivo integrar e refinar as categorias a fim de descrever uma teoria final. Essa descrio da teoria se d atravs da identificao e do relacionamento de uma categoria central com as demais categorias identificadas em todo o processo. Da Silva et al (2011) afirma que a primeira coisa a se fazer na codificao seletiva a identificao da categoria central. A categoria central, ou categoria bsica, representa o tema principal da pesquisa e, assim como as demais categorias, uma abstrao que emergiu dos dados. Da Silva et al (2011) afirma,

47 ainda, que essa categoria tem um grande poder analtico, pois tem uma capacidade de reunir e de se relacionar com as outras categorias e, dessa forma, obtm um poder explanatrio ao seu redor. Uma tcnica para a descoberta dessa categoria redigir, em poucas linhas, uma histria descritiva da pesquisa com o foco sobre O que parece estar acontecendo ali?, Qual a principal questo ou problema com o qual essas pessoas parecem estar lidando?. Um retorno aos dados para reler as entrevistas ajuda nessa identificao (STRAUSS;CORBIN, 2008, p.146-148; FLICK, 2009 apud Da SILVA et al, 2011). Strauss e Corbin (2008) explicam que aps essa identificao da categoria central o pesquisador escreve novamente uma histria, mas, desta vez, utilizando as demais categorias existentes e os relacionamentos com a categoria central. A partir dessa histria emerge a teoria final da pesquisa. Da Silva et al (2011, p.53) afirma que Uma vez seguida sistematicamente metodologia e o desenvolvimento do modelo terico necessrio refinar e validar o esquema terico. O refinamento da teoria consiste em complementar categorias mal desenvolvidas, podendo inclusive voltar a campos para isso. No refinamento da teoria podem-se encontrar excessos de dados e conceitos estranhos que nunca foram desenvolvidos, quando isso verificado, esses excessos devem ser deixados de lado (STRAUSS e CORBIN, 2008, p.155-157). 3.6 Limitaes Os objetivos da pesquisa foram alcanados, todavia existiu dificuldade principalmente na questo das realizaes de entrevistas, j que essa etapa depende bastante dos membros participantes da comunidade Android-BrasilProjetos, que possuem diversas tarefas durante o dia e tem seu tempo limitado. As entrevistas foram realizada via Skype devido a disperso dos membros que esto localizados em vrias partes do Brasil, o que tambm dificultou na realizao do processo. Inicialmente foram obtidos 8 respostas positivas para realizao das entrevistas, contudo, somente 4 pessoas responderam positivamente em relao ao horrio da entrevista e estiveram disponveis no Skype para participar no horrio marcado. Devido limitao de tempo, o nmero de entrevistados se restringiu a quatro integrantes.

48 3.7 Discusso Utilizar uma metodologia baseada no trabalho de Da Silva et al (2011) facilitou no desenvolvimento do trabalho e na obteno dos resultados propostos, vale salientar tambm que a mesma metodologia foi utilizada em outros trabalhos como o de Carneiro (2011). Apresentada a metodologia proposta, no prximo captulo os dados sero analisados das proposies e da teoria, utilizado com a utilizao o roteiro adaptado (Apndices B e C). 4. Resultados Nesse capitulo sero descritos os resultados da codificao Aberta, Axial e Seletiva que foram obtidos com as entrevistas realizadas na comunidade AndroidBrasil-Projetos. Primeiro ser apresentada a descrio do contexto para que posteriormente sejam apresentados os relatos dos resultados da codificao aberta, os resultados da codificao axial, com as proposies geradas, e os resultados da codificao seletiva, com a gerao da teoria e, por fim, uma avaliao dos resultados. As perguntas que foram realizadas nas entrevistas podem ser observadas no Apndice B (Mantenedor) e no Apndice C (Engenheiros de Software), juntamente com as perguntas originais desenvolvidas por Da Silva et al (2011). 4.1 Descrio do Contexto O grupo Android-Brasil-Projetos no Google Groups10 foi criado em dezembro de 2010 com o intuito de fazer a comunidade Android crescer e desenvolver projetos de software Open Source. Esse grupo formado por pessoas interessadas em desenvolver aplicaes de cdigo aberto, de forma bem documentada e seguindo padres de projetos. Qualquer um, mesmo que no saiba programar, pode participar propondo projetos e testando os programas. A lista tem cerca de 530 e-mails cadastrados, contudo no significa dizer que esse nmero de pessoas ativas, pois os usurios podem cadastrar mais de um e10

Ferramenta para criao de grupos virtuais do Google.

49 mail, assim como no significa dizer que somente 530 pessoas participaram da comunidade, pois o membro pode sair do Google Groups quando desejar. No ms de Maio de 2012 cerca de 30 membros participaram da lista, e alguns deles apenas com dvidas de desenvolvimento no relacionadas com os projetos desenvolvidos pela comunidade. Para participar de algum projeto o participante deve cadastrar seu e-mail na lista do grupo e esperar que um dos moderadores do grupo aceite a entrada do membro. J para participar de um projeto ele deve mandar um e-mail para o grupo dizendo que deseja participar de determinado projeto, as pessoas que j participam deste projeto iro adiciona-lo no grupo de desenvolvedores do projeto. Basicamente o novo membro ser adicionado ao documento de especificao do projeto, ou seja, receber permisso para edita-lo, e no repositrio de cdigo fonte. Os projetos so desenvolvidos utilizando a mtodo gil SCRUM11. Eles so quebrados em tarefas menores que ficam disponveis para que qualquer membro possa escolher alguma tarefa que goste, essas tarefas ficam esperando algum que as faa, caso ningum queira fazer o lder do projeto, que normalmente quem tem a ideia do projeto, pode designar algum, mas esse no obrigado a fazer, ou ainda o prprio lder pode fazer a tarefa. Como existe distncia entre os membros da equipe e cada um pode realizar suas tarefas no local e horrio que achar mais adequado, existe algumas particularidades inerentes ao desenvolvimento do software na comunidade AndroidBrasil-Projetos, como a comunicao que ocorre via e-mail e Skype. Geralmente as reunies via Skype so para formalizar o escopo do projeto e suas funcionalidades, mas pode ocorrer dos membros utilizarem esse tipo de encontro para auxiliar o processo de ensino. J os e-mails so utilizados para tirar dvidas, auxiliar o processo de ensino e em comunicaes corriqueiras. Alm disso, criado um arquivo no Google Docs12 que armazena as informaes do projeto, como: funcionalidades, contato dos envolvidos, ferramentas utilizadas, e responsveis pelas tarefas.

11 12

Para mais informaes http://www.scrum.org/ Para mais informaes http://www.google.com/apps/intl/pt-BR/business/docs.html

50 Para auxiliar a manter o cdigo nico e evitar o retrabalho, utilizado um software de controle de verso que fica responsvel por controlar as diferentes verses do cdigo, permitindo que os membros da equipe trabalhem com o mesmo conjunto de cdigos ao mesmo tempo podendo minimizar os desgastes provocados por problemas em conflito de edies e pela distncia fsica. 4.2 Resultados da Codificao aberta Nesta etapa foram geradas quatro categorias e 28 fatores, que afetam os engenheiros de software na comunidade Android-Brasil-Projetos, nove sinais de motivao, percebidos pelos participantes e, por fim, quatro definies de motivao, de acordo com os participantes. Fragmentos de entrevistas foram utilizados como prova, e descries claras e no-conflitantes tambm foram atribudas a categorias, a fim de manter as categorias coerentes com outras teorias de motivao encontradas na literatura. Na Tabela 7 so apresentadas as categorias e seus fatores.
Tabela 7 Aspectos motivacionais Aspectos da Comunidade Diminuio da Motivao Conflito de opinies Interao baixa Ateno Contribuio social do projeto Reconhecimento interno da comunidade Reconhecimento externo comunidade Ausncia de remunerao Participao na definio do produto (dar opinio como usurio) Aspetos pessoais Concorrncia com atividades externas Mudana de interesse pessoal Dificuldade para aprender Gratido Ideologia Autonomia Flexibilidade de tempo Utilidade do produto para si Larga rede de contatos profissionais Aspectos do trabalho em equipe Falta de integrao da equipe Diviso do trabalho Qualificao tcnica dos integrantes da equipe Aumento da Motivao Ajuda mtua

51
Poder Ajudar os outros (interno a tarefa) Proatividade dos outros Utilidade da tarefa p/ fora da comunidade Aprendizado Desafio tcnico Boa Qualidade da documentao Fonte: Autor (2012).

Aspectos da tarefa

4.2.1 Aspectos da Comunidade Os aspectos da comunidade so aqueles que a comunidade proporciona para os membros que participam dos projetos desenvolvidos por ela. Essa categoria a que contm mais fatores, sejam eles de aumento de motivao (seis, juntamente com aspectos pessoais) e de diminuio da motivao (quatro). A seguir so apresentados cada um desses fatores:

a) Conflito de Opinies (Diminuio da Motivao): Esse fator acontece quando alguma opinio do membro no aceita pelos outros membros, como exemplificado no seguinte trecho de entrevista:
Quando a pessoa est desmotivada quando acontece alguma coisa que no gosta, estava indo bem, aconteceu alguma coisa que veio de encontro ali[...]vem uma resposta que via de encontro que a pessoa tem como certo e ai a pessoa fica desmotivada[...] (Engenheiro de Software). b)

Interao Baixa (Diminuio de Motivao): quando existe falta de comprometimento com os membros da comunidade, como exemplificado no seguinte trecho de entrevista:
[...]as vezes tinha incompatibilidade de horrio e as vezes voc acaba perdendo a interao com os outros membros (Engenheiro de Software).

c) Ausncia de remunerao (Diminuio de Motivao): Esse fator acontece devido comunidade no ter nenhuma remunerao financeira para os membros, como pode ser exemplificado no seguinte trecho de entrevista:
[...]como no tem nenhuma remunerao, no tem nada que te obrigue a participar do projeto, voc est ali porque voc quer, as pessoas comeam saindo[...] (Engenheiro de Software).

52
d)

Ajuda mtua (Aumento da Motivao): Tambm pode ser definido como reciprocidade, quando os membros se ajudam, como exemplificado no seguinte trecho de entrevista:
[...]essa relao que existe entre as pessoas, uma ajudando a outra, isso da para mim foi fundamental. (Engenheiro de Software).

e) Ateno (Aumento da Motivao): Esse fator ocorre quando um membro d ateno para o outro, como exemplificado no seguinte trecho de entrevista:
uma coisa que j vi em vrios lugares, no s em comunidade Open Source, que voc d ateno para ela. (Engenheiro de Software).

f) Contribuio social (Aumento da Motivao): quando a comunidade prope contribuir para a sociedade, como exemplificado no seguinte trecho de entrevista:
[...]geralmente um projeto que no tem fins lucrativos, mas tem uma contribuio social[...] (Engenheiro de Software).

g) Reconhecimento interno da comunidade (Aumento da Motivao): quando a comunidade faz com que o membro seja reconhecido dentro dela, como exemplificado no seguinte trecho de entrevista:
[...]o reconhecimento uma coisa muito legal, as vezes voc tem o sobre do software e tem os desenvolvedores e tem seu nome l, nossa que legal, eu ajudei a fazer isso aqui, meu nome t aqui entendeu? O reconhecimento que voc fez parte de alguma coisa bem legal. (Engenheiro de Software).

h) Reconhecimento externo da comunidade (Aumento da Motivao): quando a comunidade faz com que o membro seja reconhecido fora dela, como exemplificado no seguinte trecho de entrevista:
[...]tipo, a gente sabia que nosso trabalho poderia ser visto e utilizado por milhares de pessoas, ento, poxa, vamos ser reconhecidos mesmo! O negocio t bombando! Vamos ficar famoso, por assim dizer. (Engenheiro de Software).

i) Participao na definio do produto (Aumento da Motivao): A comunidade oferece ao Engenheiro de Software a oportunidade de expressar sua opinio no desenvolvimento daquele software, como exemplificado no seguinte trecho de entrevista:

53
Era exatamente poder colocar minha opinio como usurio e no somente como desenvolvedor, porque quando voc est em um projeto as vezes voc d opinio, mas como desenvolvedor e as vezes no exatamente o que o usurio quer ou precisa. E naquele projeto no, voc tinha oportunidade de escrever e dizer o que voc queria. (Engenheiro de Software).

4.2.2 Aspectos Pessoais Os Aspectos Pessoais so aqueles que so inerentes aos engenheiros de software. Os fatores contidos nessa categoria esto relacionados com cada individuo e mudam de pessoa para pessoa, por exemplo, mesmo se o membro quiser mudar de comunidade, esses fatores continuariam os mesmo. So os fatores de Aspectos pessoais: a) Concorrncia com atividades externas (Diminuio da Motivao): Esse fator ocorre quando existem atividades externas concorrendo com a participao do membro na comunidade, sejam elas do trabalho ou faculdade, ou tambm ficar com a famlia no final de semana e ir praia, como observado no seguinte trecho de entrevista:
[...]as vezes um estudante que est em frias, janeiro e dezembro, chega fevereiro tem aula tem, prova, no d para continuar, as vezes um cara que tem famlia, no d para ficar reunindo, fazer reunio ou ficar gastando um tempo durante a semana[...](Engenheiro de Software).

b) Mudana de interesse pessoal (Diminuio da Motivao): Esse fator ocorre quando existe mudana nos interesses das pessoas ou organizaes, ela pode, por exemplo, estar desenvolvendo por que a empresa que trabalha usa, como observado no seguinte trecho de entrevista:
A rotina da pessoa muda, o interesse da pessoa muda. (Engenheiro de Software).

c) Dificuldade em aprender (Diminuio da Motivao): Esse fator ocorre quando um membro tem dificuldade no aprendizado das tecnologias utilizadas, como observado no seguinte trecho de entrevista:
As vezes desestimulante, as vezes nem sempre, mas voc est desenvolvendo alguma coisa e voc tem que aprender algo a mais ali, voc est quase resolvendo e ai voc no sabe isso aqui , ai voc tem que correr

54
atrs, parar o que voc est fazendo e comear a aprender de novo, ento isso chato, fica chato (Engenheiro de Software).

d) Gratido (Aumento da Motivao): Esse fator ocorre quando existe um sentimento de gratido por uma ao de algum membro, como observado no trecho a seguir:
A gratido, a pessoa ver que voc se esforou para ajuda-la e ela vai querer fazer a parte dela tambm, isso ajuda no interesse. A pessoa fala: ou o cara me ensinou isso, gastou maior tempo e abriu o Skype comigo, me ensinou e eu abri minha rea de trabalho e ele viu meu cdigo aqui e pelo Skype, pela minha rea de trabalho compartilhada, ele comeou a me falar o que eu tinha que fazer e deu o toque e passou, escreveu um tutorial (Engenheiro de Software).

e) Ideologia (Aumento da Motivao): o fator que acontece quando o membro acredita que o software deve ajudar as pessoas e ser livre, como no trecho a seguir:
Bom, Open Source faz parte da minha ideia de que o conhecimento tem que ser livre (Engenheiro de Software).

f) Autonomia (Aumento da Motivao): Esse fator ocorre porque os desenvolvedores possuem liberdade para desenvolver como eles querem, os projetos que eles querem. O trecho a seguir serve para exemplificar o fator:
[...]cada um escolhia o que queria desenvolver, ou seja, o que voc tinha mais afinidade, voc acha mais interessante desenvolver, ento a gente escolhia por isso. (Engenheiro de Software).

g) Flexibilidade do Tempo (Aumento da Motivao): A flexibilidade do tempo ajuda a motivar os membros da comunidade pois eles podem desenvolver na hora que achar mais adequada. O trecho a seguir exemplifica o fator:
[...]vai querer fazer no momento que voc quer, que te dar vontade, a questo isso, voc vai fazer na hora que voc quer[...] (Engenheiro de Software).

h) Utilidade do produto para si (Aumento da Motivao): Esse fator ocorre quando o Engenheiro de Software busca desenvolver ou modificar o software de acordo com suas necessidades.
[...]fazer alguma coisa que gosta ou algum software que vai utilizar que acha til[...]sabia que aquilo ali ia ser uma coisa a ser utilizada, por exemplo, que

55
ele iria utilizar, ento tipo com certeza um incentivador [...](Engenheiro de Software).

i) Larga rede de contatos profissionais (Aumento da Motivao): Esse fator ocorre quando o Engenheiro de Software deseja aumentar sua rede de contatos profissionais. O trecho a seguir foi retirado das entrevistas:
[...]os contatos que voc faz, o network tambm grande porque voc tem gente de todo lugar do mundo em si[...](Engenheiro de Software).

4.2.3 Aspectos do trabalho em equipe a) Falta de integrao da equipe (Diminuio da Motivao): Esse fator ocorre principalmente porque os projetos so desenvolvidos de forma distribuda, muitas vezes as pessoas envolvidas na comunidade no se conhecem. Trecho do fator:
Marcar uma cerveja, fazer outras atividades, fazer atividades que no esto direcionadas com o desenvolvimento daquilo ali, uma vez por ano ou a cada seis meses as pessoas que moram mais perto marcarem para conversar ao vivo, essa questo de voc ficar s na Internet, no e-mail no computador um pouco impessoal. (Engenheiro de Software).

b) Diviso do trabalho (Aumento da Motivao): Esse fator ocorre porque os desenvolvedores possuem liberdade para realizar as tarefas que eles quiserem. O trecho a seguir serve para exemplificar o fator:
[...]cada pessoa falava o que gostaria de fazer e com isso acabava pegando as atividades que estavam l na lista... era assim que era dividido. (Engenheiro de Software).

c) Qualificao tcnica dos integrantes da equipe (Aumento da Motivao): A qualificao tcnica dos membros envolvidos nos projetos influencia no aumento da motivao dos membros, como constatado no trecho a seguir:
Ah! bom trabalhar com pessoas qualificadas, n? Quando voc v que uma pessoa da equipe desenvolve com uma qualidade de software boa, que entende o que voc t falando, d ideias que realmente constroem, que ajudam a construir o software, voc se sente bem. Trabalhar com pessoa qualificadas bom. (Engenheiro de Software). d)

Poder (Aumento da Motivao): A possibilidade de mandar nas outras pessoas tambm foi um dos fatores mencionados pelos membros, como no

56 trecho a seguir, quando o entrevista perguntado se tinha alguma funo que gostaria de fazer:
Bem, Gerente, ai eu ia mandar em todo mundo l, mas no mandar, gerenciar, ter um contato mais direto com as pessoas, resolver os problemas do grupo e do projeto com as pessoas. (Engenheiro de Software).

e) Ajudar os outros (interno a tarefa) (Aumento da Motivao): a possibilidade de ajudar as tarefas das outras pessoas.
O que me estimulou ali a participar, na verdade eu no estava participando, mas o Mantenedor e um Desenvolvedor
13

me vieram pedir uma mo para

ajudar na parte de interface que eles estavam tendo alguns problemas resolvi dedicar um tempo para melhorar o aplicativo e poder ajudar eles. (Engenheiro de Software).

f) Pr-atividade dos outros (Aumento da Motivao): Fazer ou observar alguma ao que era de outro membro, buscando a pr-atividade, como no trecho a seguir: [...]ver que tem alguma coisa errada que voc no tinha percebido, as
vezes seu cdigo, voc desenvolveu aquele cdigo e o cara vai l e ou, eu vi isso aqui, j comitei que outra pessoa
14

uma correo." Oh que legal, voc estudou o cdigo desenvolveu e foi l e j comitou uma

correo[...](Engenheiro de Software).

4.2.3 Aspectos da Tarefa Os Aspectos da tarefa so questes inerentes ao desenvolvimento da tarefa, esses aspectos podem variar de tarefa para tarefa, ou seja, eles acontecem pelo que o desenvolvimento da tarefa proporciona aos membros. a) Utilidade da tarefa para fora da comunidade (Aumento da Motivao): Algumas tarefas podem desenvolver, por exemplo, bibliotecas ou melhorar o layout do Android, e isso pode ser til em um contexto externo a comunidade.
Ah! Eu precisaria desenvolver isso aqui, isso aqui legal, e poderia ser interessante para outras pessoas, ah legal, vamos fazer uma bliblioteca[...] interesse de melhorar a parte visual do android porque at um tempo atrs ele tinha uma fama de ser muito feio e agora t melhorando bastante isso,

13 14

Foram retirados os nomes citados por causa da confidencialidade. Enviar uma atualizao de cdigo para o controle de verso.

57
ento uma coisa que eu gosto de trabalhar e me estimula bastante. (Engenheiro de Software).

b) Aprendizado (Aumento da Motivao): O que essa tarefa pode trazer de conhecimento para o membro, o que ele pode aprender fazendo determinada tarefa.
claro que tem a questo que a pessoa t aprendendo, muitas pessoas usam isso: ah estou aprendendo, estou comeando a desenvolver para Android e vamos fazer um projeto? (Engenheiro de Software).

c) Desafio tcnico (Aumento da Motivao): Os desafios no desenvolvimento da tarefa tambm estimulam os desenvolvedores da comunidade, como no trecho a seguir:
[...]essa coisa do ter um objetivo e buscar a melhor maneira, acho que os desafios, os desafios sempre motivador[...](Engenheiro de Software).

d) Boa qualidade de documentao (Aumento da Motivao): A qualidade da documentao tambm influi na motivao dos desenvolvedores, como pode ser observado no trecho a seguir:
[...] Olha eu vou te falar que um ambiente que depende muito de quem est desenvolvendo o projeto, se for um projeto maior mais bem estruturado, tem mais documentao [...]o projeto do KDE, um projeto grande por isso tem muita documentao e bem estruturado[...](Engenheiro de Software).

4.2.4 Sinais de motivao Durante a codificao aberta foram identificados nove sinais de motivao, sendo que cinco negativos e trs positivos, que foram divididos em Aspectos da comunidade, Aspectos pessoais e Aspectos da tarefa, conforme a Tabela 8. Os sinais de desmotivao so: (i) Nvel de Comprometimento (Aspectos da Comunidade): A falta de comprometimento dos membros em relao realizao das tarefas, na comunidade e no projeto foi comentada pelos quatros entrevistados como um sinal de desmotivao, como pode ser observado a seguir:

58
Ele no participa de nada, um cara que t nem ai (Engenheiro de Software) e [...]uma pessoa que no t motivada no vai participar desse tipo de ... no vai se envolver muito[...] (Engenheiro de Software) Tabela 8 - Sinais de motivao

Aspectos da Comunidade

Aspetos pessoais Aspectos da tarefa

Sinais de Desmotivao Nvel de Comprometimento Nvel de comunicao Falta de interesse em ajudar Pessimismo Demora em realizar tarefas

Sinais de motivao Participao

Cdigo de qualidade Maior produo

Fonte: Autor (2012).

(ii) Nvel de comunicao (Aspectos da Comunidade): O nvel de comunicao entre os membros importante, quando existe pouca comunicao entre os membros do projeto, pode causar uma falta de animao para a equipe, como pode ser observado no trecho a seguir:
[...]voc no tem um feedback dele em relao s ideias do projeto, ao desenvolvimento do projeto ao problemas que aparecem no projeto, ele no d um feedback, no acompanha, falta comunicao dele, ento isso para mim um ponto de verificao de desestimulo do participante (Engenheiro de Software)

(iii) Falta de interesse em ajudar (Aspectos da Comunidade): Quando observado em um membro que existe falta de interesse em ajudar os outros membros, estes membros acreditam que ele no est motivado, como foi comentado por um participante:
[...]eu vejo pessoas que assim, to na comunidade e no querem militar, no querem ajudar sabe? (Engenheiro de Software)

(iv) Pessimismo (Aspectos Pessoais): Se o membro estiver com atitudes pessimista, os outros membros podem acreditar que ele no est motivado na comunidade, como no trecho a seguir:
[...]uma pessoa pessimista, que fala alguma coisa que traz um conflito, alguma coisa assim as outras pessoas que no...to em um ritmo diferente, num ritmo positivo assim alto astral, levando o projeto legal ela pode ficar desmotivada[...] (Engenheiro de Software)

(v) Demora em realizar tarefas (Aspectos da Tarefa):

59 Quando passada uma tarefa para um membro e este demora na realizao da mesma, os outros membros acreditam que ele esteja desmotivado, como no trecho a seguir:
[...]fica enrolando, tipo a ideia dividir em tarefas pequenas o projeto, exatamente para a pessoa no dedicar tanto tempo assim e fazer a parte dela. Isso uma das coisas que aconteceu e a pessoa enrolou durante 3 semanas uma coisa simples e acabou que eu peguei e fiz porque tava atrasando todo o andar das outras coisas e depois de 3 semanas no procurei mais, a pessoa no procurou mais para conversar e consideramos que a pessoa tinha desistido do projeto[...](Engenheiro de Software)

J os sinais de motivao percebidos so: (i) Participao (Aspectos da Comunidade): A participao do membro observada como sinal de motivao por outros membros, caso o membro participe muito os outros membros acreditam que ele est motivado. Ela foi citada por trs membros, como pode ser visto a seguir:
Participao em tudo, quando voc vai fazer uma escrita de historia, debate essas apario alguma coisa, vamos usar isso aqui, s vezes o cara fica por fora e no acompanha. J um sinal que ele no est estimulado a participar do projeto. (Engenheiro de Software) Quando o cara manda trs e-mail por dia falando em alguma coisa do projeto, todo animado, dando um gs, vendo que ele correu atrs, t em reunio e o cara aparece[...] (Engenheiro de Software)

(ii) Qualidade de cdigo (Aspectos da Tarefa): Quando um membro produz software com uma boa qualidade do cdigo, os outros membros acham que um sinal de que ele est motivado, conforme o trecho a seguir:
Uai! Uma pessoa dedicada produz um cdigo de boa qualidade, uma pessoa que gasta tempo estudando aquilo ali, que produz um resultado que voc ver a qualidade do software desenvolvida boa. (Engenheiro de Software)

(iii)Maior Produo (Aspectos da Tarefa): Quando se observado que um membro produz mais, os membros da equipe acham que ele est motivado com o projeto, conforme a citao a seguir:
A pessoa motivada uma pessoa produtiva, uma pessoa que produz. (Engenheiro de Software)

60

4.3 Resultados da codificao axial Proposio 1: A boa qualidade da documentao e a qualificao tcnica da equipe afetam positivamente o aprendizado do desenvolvedor de software. Os trechos a seguir apresentam esses fatores:
quando voc ver que uma pessoa da equipe desenvolve com uma qualidade de software boa, que entende o que voc t falando, d ideias que realmente constroem, que ajudam a construir o software, voc se sente bem, trabalhar com pessoa qualificadas bom. (Engenheiro de Software). [...]para quem quiser desenvolver tem tutoriais de como comear, como se inteirar, um kit iniciante para comear a desenvolver e rodar no projeto, projetos menores um pouco mais complicado porque no tem uma wiki explicando direitinho como que faz[...](Engenheiro de Software)

Proposio 2: Ajudar os outros e a contribuio social do projeto afetam positivamente o Ideologia dos membros da comunidade. A oportunidade de ajudar nas tarefas de outras pessoas afeta positivamente a ideologia do membro, assim como a contribuio social do projeto, pois so formas de contribuir com o prximo (HERTEL et al, 2003).
contribuio social do projeto, porque geralmente um projeto que no tem fins lucrativos, mas tem uma contribuio social, as vezes essa contribuio no fica visvel a todos(Engenheiro de Software) [...]essa relao que existe entre as pessoas, uma ajudando a outra, isso da para mim foi fundamental. (Engenheiro de Software).

Proposio 3: O reconhecimento externo e interno, a rede de contatos e o Aprendizado afetam positivamente a Autopromoo, que algo procurado pelos membros da comunidade. Quando existe a possibilidade do trabalho ser visto por outras, quando tem seu nome escrito como desenvolvedor do software, o membro tem a possibilidade de ganhar visibilidade externa e interna pelo trabalho desenvolvido. Quando o membro tem uma larga rede de contatos pode conseguir melhores empregos, desde que o membro tenha aprendido determinada tecnologia. Essa ideia pode ser

61 observada nos trabalhos de Oreg e Nov (2007), Lerner e Tirole (2002) e Lakhani e Wolf (2005).
[...]eu aprendi a programar de verdade, utilizando Open Source (Engenheiro de Software). [...]os contatos que voc faz, o network tambm grande porque voc tem gente de todo lugar do mundo em si[...](Engenheiro de Software). [...]o reconhecimento uma coisa muito legal, as vezes voc tem o sobre do

software e tem os desenvolvedores e tem seu nome l, nossa que legal, eu ajudei a fazer isso aqui, meu nome t aqui entendeu? O reconhecimento que voc fez parte de alguma coisa bem legal.(Engenheiro de Software).
[...]tipo, a gente sabia que nosso trabalho poderia ser visto e utilizado por milhares de pessoas, ento, poxa, vamos ser reconhecidos mesmo! O negocio t bombando! Vamos ficar famoso, por assim dizer. (Engenheiro de Software).

Proposio 4: A ausncia de remunerao e a concorrncia com atividades externas afetam negativamente o comprometimento dos membros. Por influncia da ausncia de remunerao e por causa da concorrncia com atividades externas o comprometimento afetado negativamente. Como nos trechos a seguir:
[...]tentava atribuir para ela alguma atividade ah, essa semana est muito apertada, tem muito servio as vezes o pessoal fala que vai fazer e no faz[...](Engenheiro de Software) [...]como no tem nenhuma remunerao, no tem nada que te obrigue a participar do projeto, voc est ali porque voc quer, as pessoas comeam saindo[...](Engenheiro de Software)

Proposio 5: A utilidade do produto para o membro afeta positivamente o comprometimento. A utilidade do produto faz com que o membro se comprometa no desenvolvimento dele. Como pode ser observado no trecho a seguir:
O que eu acho o maior incentivador de uma pessoa a ajudar no desenvolvimento de um projeto open source porque ele um usurio daquele projeto ali e quer ver aquele projeto ir para frente. (Engenheiro de Software)

62 Proposio 6: A integrao de equipe e a reciprocidade afetam positivamente o comprometimento. Quanto mais a equipe est integrada, mais existe comprometimento, como no trecho a seguir:
[...]quando voc conhece as pessoas pessoalmente voc tem um lao maior com aquelas pessoas, voc se compromete mais com aquelas pessoas[...](Engenheiro de Software)

A reciprocidade ajuda a aumentar o comprometimento pois a pessoa quer ajudar os outros a aprender, como no trecho a seguir:
[...]eu utilizei muito como uma forma de ganhar conhecimento, ento eu acho que um meio de se passar conhecimento adiante para outras pessoas[...](Engenheiro de Software)

Proposio 7: O interesse pessoal afeta positivamente o comprometimento dos membros. O interesse pessoal ajuda a aumentar o comprometimento dos membros, como pode ser observado no trecho a seguir:
[...]eu tenho conhecimento em desenvolvimento de software e ser que eu no consigo melhorar isso aqui, ou desenvolver uma caraterstica que eu estou interessado ?[...] (Engenheiro de Software)

Proposio 8: O comprometimento afeta positivamente a comunicao. Quando o usurio est mais comprometido a comunicao feita de maneira melhor. O trecho a seguir exemplifica a preposio:
[...] Ele no participa de nada, um cara que no t nem ai, fechado voc no tem um feedback dele em relao as ideias do projeto, ao desenvolvimento do projeto ao problemas que aparecem no projeto, ele no d um feedback, no acompanha, falta comunicao dele[...](Engenheiro de Software).

Proposio 9: O comprometimento afeta positivamente a contribuio. Quando as pessoas esto mais comprometidas, elas contribuem mais, conforme o trecho as seguir:
Quando o cara manda trs e-mail por dia falando em alguma coisa do projeto, todo animado, dando um gs, vendo que ele correu atrs, t em reunio e o cara aparece Nossa que legal o cara t interessado, o cara d ideia no projeto, corrige o cdigo, ver que tem alguma coisa errada que voc no tinha percebido, as vezes seu cdigo, voc desenvolveu aquele cdigo

63
e o cara vai l e ou eu vi isso aqui, j comitei uma correo[...](Engenheiro de Software).

Proposio 10: A ideologia afeta positivamente o comprometimento. Raymond (1999) acredita que a ideologia da pessoa faz com que ela seja comprometida para desenvolver de cdigo fonte aberto. Proposio 11: O comprometimento com as pessoas afeta o reconhecimento interno. Quando o membro no est integrado com a equipe e no existe reciprocidade o reconhecimento dele afetado negativamente, por exemplo, no trecho a seguir quando foi perguntado de que forma a falta integrao e a reciprocidade afetariam o trabalho do membro:
Acho que no no trabalho dele em si, mas em relao imagem dele em si na comunidade, ele fica com imagem de irresponsvel, de desleixado. (Engenheiro de Software).

4.4 Resultados da codificao seletiva Para gerar a teoria, foi desenvolvido um levantamento das categorias que eram mais relevantes entre os fatores motivadores e os fatores desmotivadores na codificao aberta. O resultado desse levantamento permitiu identificar as principais categorias que foram citadas dentre as 28categorias criadas na codificao aberta. Depois disso, foi desenvolvido um trabalho de leitura das citaes para que fossem identificados os relacionamentos entre estas categorias, fazendo com que fosse possvel se chegar categoria central, que a base da teoria gerada. As categorias identificadas como centrais foram o comprometimento e o interesse pessoal, que foram as categorias que tiveram sua importncia destacada nos relatos feitos durante as entrevistas, observando tambm os relacionamentos com as outras categorias citadas. As proposies 8 e 9 apresenta comprometimento como um fator que leva a pessoa a contribuir com o desenvolvimento de Software Open Source e os membros a se comunicar melhor na comunidade. A ausncia de remunerao faz com que o comprometimento seja afetado negativamente, juntamente com a concorrncia com atividades externas. Isso

64 justificvel, pois o membro precisa de remunerao financeira para realizar aes do dia-a-dia, como: pagamento das contas de energia, luz, gua e Internet. Essa necessidade leva a obrigao do membro de ter outra fonte de renda, que normalmente concorre com a contribuio em projetos deste tipo. Alm disso, alguns membros tem a concorrncia com atividades de lazer, como ir praia ou ficar com a famlia. O aprendizado influenciado pela boa qualidade da documentao, pois devido s informaes estarem mais bem explicadas e disponveis para os novos membros que desejem participar do projeto. J quando um membro bastante qualificado pode ajudar os outros integrantes a aprenderem, transmitindo o conhecimento e identificando solues para problemas. Alguns membros buscam uma oportunidade pessoal, para melhorar a carreira, por exemplo, e por isso buscam aprender na comunidade. Essa oportunidade pode chegar com o reconhecimento externo, de empresas da rea que buscam talentos na comunidade e de pessoas de fora da comunidade ou com o reconhecimento interno dos membros que fazem a comunidade, que podem reconhecer o membro como um desenvolvedor de qualidade. A rede de contatos desenvolvida na comunidade pode proporcionar oportunidade de melhorar a carreira. A utilidade do produto para o membro faz com que ele se comprometa mais, pois ele deseja que o produto seja finalizado para que ele mesmo possa usa-lo e tambm para que o produto resolva um problema existente para o membro ou no trabalho dele. Uma equipe integrada no desenvolvimento do software e a reciprocidade dos membros em se ajudar fazem com que os membros se comprometam mais, levando reconhecimento interno do trabalho dos membros da comunidade. A Figura 3 exemplifica esses relacionamentos.

65

Figura 3 - Gerao da teoria da comunidade Fonte: Autor (2012)

4.5 Avaliaes dos Resultados Foram realizadas quatro entrevistas que resultaram cerca de 3 horas de udio e 30 pginas de conversas transcritas. Pode-se destacar que foram encontradas 28 categorias de fatores motivacionais, as quais foram descritas e classificadas entre questes relativas a aspectos pessoais, da comunidade, da tarefa e do trabalho em equipe. Alm disso, tambm foram geradas nove proposies e uma teoria relacionando s principais categorias encontradas durante a anlise dos dados. A pesquisa gerou dados importantes que devem ser analisados no contexto de desenvolvimento de software Open Source, em especial dentro da comunidade Android-Brasil-Projetos, contudo esses dados podem atuar de forma semelhante em outras organizaes Open Source. Todos os quatro fatores apontados por Wu et al (2005), Comportamento de ajuda, Aprimoramento do capital humano, Progresso na carreira e Satisfao de necessidade pessoais, foram encontrado nesta pesquisa e so observados como

66 fatores que levam as pessoas a contribuir na comunidade, assim como os fatores propostos por Oreg e Nov (2007), Reputao, Desenvolvimento prprio e Altrusmo. O conjunto dos fatores citados por Wu et al (2005) e Oreg e Nov (2007) aparecem tambm como os mais relevantes na comunidade Android-Brasil-Projetos. Dos 10 fatores encontrados por Von Krogh et al (2008) apenas prazer/ diverso e amigos de sangue(Kinship amity) no foram citados. O fator reputao foi classificado separadamente como interno e externo. Alguns fatores como diviso do trabalho, boa qualidade da documentao, desafio tcnico, utilidade da tarefa para fora da comunidade, poder, concorrncia com atividades externas, flexibilidade do tempo, e participao na definio do produto no aparecem na pesquisa realizada por Von Krogh et al (2008) e foram encontrados em na pesquisa e so importantes para entender melhor a motivao dos membros. Pode-se Salientar tambm que alm da pesquisa dividir em fatores motivacionais e desmotivacionais para melhor entende-los, tambm foram encontrados os sinais de motivao e desmotivao na comunidade, tornando ainda mais rica a contribuio, pois com eles possvel perceber o comportamento do membro e evitar que ele abandone o projeto ou notar se o membro est satisfeito com o projeto. Uma observao que deve ser levada em considerao, que a teoria foi gerada com uma baixa quantidade de entrevistas, o que leva a pouca quantidade de dados analisados, alm disso, como foi estudado apenas a comunidade AndroidBrasil-Projetos, a teoria gerada especifica para o contexto e comunidade estudados. A teoria estudada, aborda alguns fatores que no foram observados anteriormente, mas em geral encontra resultados semelhantes aos encontrados com os de Von Krogh et al (2008), a principal diferena entre a teoria gerada e as

hipteses encontradas com Wu et al (2005) o indcio que o interesse pessoal um dos fatores preponderantes que levam aos membros contriburem em um contexto Open Source, assim como a ideologia foi citada de maneira tmida pelos membros nesta pequisa, diferentemente da pesquisa realizada por Wu et al (2005), isso se deve em parte a utilizao do Skype e a realizao de entrevistas para obteno dos dados.

67 Esses novos indcios de fatores devem ser melhores pesquisados e ampliados, de preferencia utilizando os mesmos mtodos, para observar como esses fatores atuam em outras comunidades, assim como ampliar a pesquisa na comunidade utilizada.

68 5. Concluso Com o aumento da utilizao de software Open Source pelas empresas que buscam cortar custo e melhorar a qualidade dos aplicativos, entender como os participantes desse tipo de projeto se motivam a contribuir acaba se tornando um aspecto importante para as empresas. Para a comunidade tambm importante entender o que leva os membros a contribuir e no abandonar o projeto, assim como perceber com antecedncia se o membro est desmotivado. Devido necessidade por mais estudos sobre o tema motivao no contexto Open Source, principalmente utilizando a pesquisa qualitativa, este trabalho traz contribuies interessantes para a rea, tanto para empresas que desejam investir em software Open Source quanto para mantenedores de projetos que queiram diminuir a rotatividade de membros e melhorar a contribuio dos membros no projeto. Para atingir tal fim, foram encontrados na reviso de literatura diversos fatores motivacionais que auxiliaram no desenvolvimento da pesquisa, tambm foram realizadas entrevistas para identificar se os fatores encontrados na reviso influenciavam na comunidade e encontrar novos fatores que ainda no tinham sido observados nos trabalhos relacionados. O objetivo deste trabalho era responder a questo de pesquisa, como os fatores que motivam e desmotivam engenheiros de software agem na comunidade Open Source Android-Brasil-Projetos, sendo assim, o trabalho atendeu ao seu objetivo central e trouxe consigo novas perspectivas para trabalhos futuros a serem realizados na mesma rea. A metodologia utilizada e a adaptao do protocolo utilizado em outras pesquisas realizadas permitiram ao pesquisador obter resultados claros. Tambm deve se destacar que o mtodo de pesquisa utilizado, a pesquisa qualitativa, exigiu dedicao do pesquisador na etapa de coleta dos dados e posteriormente a anlise dos dados para se chegar aos resultados desejados com sucesso. Baseado nos dados coletados atravs do mtodo de pesquisa e da anlise feita no Captulo 4 pode-se concluir que este trabalho realizado alcanou os objetivos proposto, alm disso, o trabalho contribui para as pesquisas na rea de

69 motivao, mais especificamente no setor de engenharia de software, alm de contribuir para a rea de desenvolvimento de software Open Source. Como contribuies desta pesquisa foram evidenciados, para futuros estudos, 28 fatores motivacionais, 8 sinais externos de motivao e 11 proposies que geraram uma teoria da motivao no contexto Open Source dentro da comunidade Android-Brasil-Projetos. Os resultados aqui encontrados podem servir para empresas que mantm software Open Source a entenderem quais so os fatores motivacionais que levam os participantes a contribuir, como melhorar a contribuio dos membros e evitar que eles abandonem o projeto, e tambm a comunidades independentes que podem fazer a mesma coisa. Na comunidade Android-Brasil-Projetos, os principais fatores encontrados que levam as pessoas a deixarem a comunidade foram a ausncia de remunerao e a concorrncia com atividades externas, para evitar que esses membros saiam da comunidade pode-se tentar maximizar a questo do aprendizado e da reputao obtida pelos membros, o aprendizado pode ser melhorado com a documentao e a qualificao dos membros que pertencem a comunidade, que pode ser realizada com a manuteno de membros mais experientes na comunidade, e a reputao com maneiras que deixe bem claro, tanto para os membros da comunidade quantos para pessoas fora da comunidade, o quanto a pessoa experiente e contribuiu para comunidade, isso pode ser obtido atravs de um sistema de patentes, por exemplo, que ajudaria a melhorar o sistema de meritocracia da comunidade.

5.1 Trabalhos futuros Como trabalho futuro seria interessante conseguir mais pessoas dispostas a serem entrevistada para adquirir mais dados e tentar encontrar e analisar mais fatores motivacionais, alm disso, a pesquisa tambm poderia ser desenvolvida em outra comunidade para tentar conseguir diferentes fatores baseados nas caractersticas de outra comunidade, podendo at comparar os resultados obtidos nas diferentes comunidades e tentar encontrar indcios dos fatores motivacionais no contexto Open Source.

70 Alm disso, pode-se tentar classificar os fatores encontrados nesta pesquisa de acordo com o trabalho de Von Krogh et al (2008) em motivacionais intrnsecos, motivacionais extrnsecos e fatores motivacionais extrnsecos internos ou ainda classificar fatores com valores de acordo com Schwartz (1994). Por fim, pode se utilizar os resultados encontrados para gerar uma teoria mais completa sobre a motivao dos desenvolvedores de softwares que abrangeria diversos contextos, dentre eles os de softwares Open Source.

71 REFERNCIAS

BERGAMINI, Cecilia Witaker A difcil Administrao das motivaes. Revista Brasileira de Administrao de Empresas, So Paulo, v. 38, n. 1, p. 6-17, jan/mar 1998. BEECHAM, Sarah; BADDOO, Nathan; HALL, Tracy ROBINSON, Hugh SHARP, Helen Motivation in Software Engineering: A Systematic Literature Review. Information and Software Technology, v. 50, p. 860-878, 2007. ISSN

10.1016/j.infsof.2007.09.004 , 2007. BONACCORSI, Andrea.; ROSSI, Cristina. Why open source software can succeed. Research Policy,32(7), 12431258, 2003. CARNEIRO, David Emanuel Souza. Motivao em integrantes de equipes de desenvolvimento de software no contexto de uma empresa privada: um estudo de caso Dissertao, Universidade Federal de Pernambuco. CIN. Cincia da Computao, 2011. CASSIANI, Silvia H. L; CALIRI, Maria H. L.; PEL, Nilza T. R.; A teoria fundamentada nos dados como abordagem da pesquisa interpretativa; Rev. Latino-Am. Enfermagem vol.4 no.3 Ribeiro Preto Dec. 1996 Da SILVA, Fabio Queda Bueno; FRANA, Alberto Csar Cavalcanti; FELIX, Adelnei de L.C.; ARAUJO, Ana Catarina M.L.; CARNEIRO, Carneiro E.S.; SALLES, Eric; GOUVIA, Tatiana B.; Protocolo para Estudos de Caso sobre Motivao de Engenheiro de Software. Technical Report. In:HASE, 2011. DA SILVA, Fabio Q. B.;FRANA, A. CSAR C. Towards Understanding the Underlying Structure of Motivational Factors for Software Engineers to Guide the Definition of Motivational Programs.Journal Article. In:JSS, 2011.

72 DUARTE, Rosalia: Pesquisa qualitativa: reflexes sobre o trabalho de campo Departamento de Educao da Pontifcia Universidade Catlica do Rio de Janeiro Cadernos de Pesquisa, n. 115, p. 139-154, maro 2002 DRIVER, Mark; WEISS George., Predicts 2006: the effects of open-source software on the IT software industry, Gartner Research 28, 2005. FRANA, Alberto Csar Cavalcanti. Um estudo sobre motivao em integrantes de equipes de desenvolvimento de software. 1. ed. Recife: Editora Universitria UFPE, 2009. FRANA, A. Csar C.;GOUVEIA, Tatiana B. ; SANTOS, Pedro C. F. ; SANTANA, Celio A. ; DA SILVA, Fabio Q. B. Systematic Review Update. Motivation in Software Engineering A

15th International Conference on Evaluation and

Assessment in Software Engineering EASE. [S.l.]: [s.n.]. 2011. FRANA, Alberto Csar Cavalcanti; Da Silva, Fabio Queda Bueno; Developing Motivational Programs for Software Engineers through an Experimental Method. In XXIII Simpsio Brasileiro de Engenharia de Software, 135- 154. 2009 FERREIRA, Alexandre Joo Petetim Leal; OPEN SOURCE SOFTWARE.

COMUNICAO & PROFISSO Departamento de Engenharia Informtica, Universidade de Coimbra, 2005 FERREIRA, Aurlio Buarque de Holanda. Dicionrio Aurlio Bsico da Lngua Portuguesa. Rio de Janeiro: Nova Fronteira, 2008. GNU. What is Free Software? ; Disponvel em http://www.gnu.org/ acessado em 16/03/2012 , 1996. GIL, Antonio Carlos. Mtodos e Tcnicas de Pesquisa Social. So Paulo; Atlas S.A, 2008. GOUVEIA, Valdiney V., MARTNEZ, Eva. MEIRA, Maja. e MILFONT, Taciano M. A estrutura e o contedo universais dos valores humanos: anlise fatorial confirmatria da tipologia de Schwartz Estudos de Psicoogia,6(2) 133-142, 2001.

73 HERTEL, G., NIEDNER, S., e HERRMANN, S. Motivation of software developers in open source projects: An internet-based survey of contributors to the Linux Kernel Research Policy (32:7), pp. 1159-1177, 2003. LAKHANI, Karim R., von HIPPEL, Eric. How Open Source Software Works: Free User- to-User Assistance Research Policy (32:6), pp. 923-943, 2003. LAERT; Self-selection sampling: An overview disponvel em:

http://dissertation.laerd.com/articles/self-selection-sampling-an-overview.php Acessado em 25/06/2012, [s.d]. LAKHANI, Karim R. e WOLF, Robert G.. Why hackers do what they do: Understanding motivation and eort in free/opensource software projects. Perspectives in free and open source software. Cambridge: MIT, 2005. LEE, W. Thomas, MOWDAY, T. Richard; Voluntarily leaving an organization: an empirical investigation of steers and Mowdays model of turnover, Academy of Management Journal 30, pp. 721743, 1987. LERNER, Josh; TIROLE, Jean; Some simple economics of Open Souce, Journal of Industrial Economics 50 (2), pp. 197234 , 2002 KOCH, Daniel . "HowStuffWorks - Como funcionam os projetos Open Souce ". Publicado em 29 de janeiro de 2008 (atualizado em 31 de janeiro de 2008) http://informatica.hsw.uol.com.br/projetos-open-source.htm 2012). MOTOROLA Android apresenta seus incrveis nmeros de crescimento em todo o mundo, disponvel em http://blogmotorola.com.br/2012/03/19/androidapresenta-seus-incriveis-numeros-de-crescimento-em-todo-o-mundo/ Acessado em 25/06/2012, (2012) NEVES, Jos Lus. Pesquisa qualitativa - caractersticas, usos e possibilidades. Caderno de Pesquisas em Administrao, So Paulo, v. 1, n. 3, 1996. (26 de fevereiro de

74 OPEN SOUCE INITIATIVE; History; Disponvel em: http://www.opensource.org/history Acessado em 20/03/2012, [s.d]. OREG, Shaul. e NOV, Oded. Exploring motivations for contributing to open source initiatives: The roles of contribution context and personal values Computers in Human Behavior 24 20552073, 2007 OSTERLOH, Margit., e ROTA, Sandra. G.. Open Source Software Development Just Another Case of Collective Invention?, Research Policy (36:2), pp. 157-171, 2007. PERENS, Bruce. The Open Source Definition in Open Sources: Voices from the Open Souce Revolution - O'Reilly & Associates Inc., 1999. PINHEIRO, Jos Maurcio dos Santos. Da Iniciao Cientfica ao TCC: Uma Abordagem para os Cursos de Tecnologia.1 edio. Cincia Moderna, 2010. RELLY, Richard R; Motivating and retaining technical employees, Stevens Alliance for Technology Management 9 (3), 2005, pp. 13. RUNESON, P.; HOST, M. Guideline for Conducing and Reporting Case Study Research in Software Engineering, Empirical Software Engineering, v. 14, n. 2, p. 131- 164, 2008. DOI 10.1007/s10664-008-9102-8. SALEH, Amir Mostafa. Adoo de tecnologia: Um estudo sobre o uso de software livre nas empresas. Dissertao (mestrado) Faculdade de Economia, Administrao e Contabilidade. So Paulo: Universidade de So Paulo, 2004. SoftwareLivreBrasil, Crise impulsiona software de cdigo aberto; Disponvel em
http://softwarelivre.org/portal/empresas/crise-impulsiona-software-de-codigo-aberto

acessado

em

16/03/2012 , 2009. SHARP, Helen; BADDOO, Nathan; BEECHAM, Sarah; HALL, Tracy e ROBINSON, Hugh. Models o motivation in software engineering. Information and Software Technology, 51(1), pp. 219233. 2009

75 STALLMAN, Richard M. Free Software, Free Society: Selected Essays of Richard M. Stallman.Boston: GNU Press, 2002. STRAUSS, A.; CORBIN, J. Pesquisa Qualitativa: Tcnicas e procedimentos

para o desenvolvimento de teoria fundamentada. Traduo de Luciane de Oliveira da Rocha. 2nd. ed. Porto Alegre: Artmed, 2008. SUBRAMANYAM, Ramanath; XIA, Um; Free/Libre Open Source Software development in developing and developed countries: A conceptual framework with an exploratory study. In Journal Decision Support Systems archive Volume 46 Issue 1,December, 2008 TIINSIDE. Uso de software livre cresce, mas desafios ainda so grandes disponvel em: http://www.tiinside.com.br/News.aspx?ID=103996&C=265 acessado em 29/03/2012, 2008. TODOROV, Joo C.; MOREIRA, Mrcio B.; O Conceito de Motivao na Psicologia. Revista Brasileira de Terapia Comportamental e Cognitiva. Vol. VII, n 1, 119-132. ISSN 1517-5545. 2005. TORVALDS, Linus. S por prazer: Linux : os bastidores da sua criao. Rio de Janeiro:Campus, 2001. Von KROGH, Georg; HAEFLIGER, Stefan; SPAETH, Sebastian; WALLIN, Martin; WHAT WE KNOW (AND DO NOT KNOW) ABOUT MOTIVATIONS TO CONTRIBUTE, Department Of Management, Technology, and Economics, ETH Zurich, Switzerland, 2008. WU, C.Guang, GERLACH H. James, YOUNG, E.Clifford. An empirical analysis of Open Source software developers motivation and continuance intention. In Journal Information and Management, Volume 44 Issue 3, Abril, 2007. KIMURA A F ; TSUNECHIRO MA ; ANGELO M . Teoria fundamentada nos dados. In: Miriam Aparecida Barbosa Merighi; Neide de Souza Praa. (Org.). Abordagens Terico-Metodolgicas Qualitativas: a vivncia da mulher no perodo reprodutivo. Rio de Janeiro: Guanabara Koogan, 2003, v. 1, p. 39-45.

76

APNDICE A Consentimento da Participao da Pessoa Como Participante

Eu, xxxxxx, portador do RG XXXXXXX e CPF nmero XXXXXXX, concordo em participar da Pesquisa Etnogrfica sobre Motivao de Engenheiros de Software Open Source, como voluntrio. Fui devidamente informado e esclarecido pelo pesquisador Danilo Monteiro Ribeiro sobre a pesquisa, os procedimentos nela envolvidos, assim como os possveis riscos e benefcios decorrentes de minha participao. Tambm foi me garantido que posso recusar a participar da pesquisa, ou retirar meu consentimento a qualquer momento, mesmo aps o incio dos trabalhos, sem precisar justificar, sem que isto leve a qualquer prejuzo em minha relao com a organizao. Estou ciente e fui esclarecido de que minha privacidade ser respeitada, ou seja, qualquer informao ou elemento que possa de qualquer forma me identificar ser mantido em sigilo. Enfim, tendo sido orientado quanto ao teor de todo o contedo aqui mencionado e compreendido a natureza e o objetivo do j referido estudo, manifesto meu livre consentimento em participar, estando totalmente ciente de que no h nenhum valor econmico ou material a receber, ou a pagar, por minha participao.

Local e data: _______________________________________________________________

77

APNDICE B Guia de Entrevista com Mantenedor

Introduo Apresentao o Agradecimento ao participante o Permisso para gravar o udio da entrevista o Estimativa de tempo da entrevista (45 a 60 minutos) o Sobre o projeto de pesquisa o Metas, resultados esperados e benefcios para a organizao o Explicar cuidadosamente o que se espera da entrevista sobre motivao.

# 1.

2.

Perguntas da Pesquisa Original (Da SILVA et al, 2011) Fale um pouco de voc: Sua formao, idade, trajetria profissional H quanto tempo voc trabalha nesta empresa?

Pergunta modificada para o Contexto Mesma Pergunta

3. 4.

5.

6. 7.

H quanto tempo voc trabalha com desenvolvimento de software? Pergunta Adicionada E com desenvolvimento Open Source? Como voc descreveria o ambiente Como voc descreveria o de trabalho aqui? ambiente de trabalho no contexto Open Souce? Pergunta Adicionada Sua diferenas e semelhanas com projetos proprietrios? Descreva o(s) projeto(s) no qual atua. Mesma Pergunta Descreva a sua funo atual, Mesma Pergunta principais atividades e responsabilidades.

78 # 8. Perguntas da Pesquisa Original (Da SILVA et al, 2011) Atualmente, com quantas pessoas voc lida no seu dia a dia? Quais os papeis desempenhados por elas? Em comparao com outros campos/reas, como voc avalia o trabalho dos engenheiros de software? Mais/menos estressante, divertido, puxado, significativo, recompensador, etc. Pergunta modificada para o Contexto Atualmente, com quantas pessoas voc lida no(s) projeto(s) Open Source em que voc atua?
Quais os papeis desempenhados por elas?

9.

Em comparao com projetos de software proprietrios, como voc avalia o trabalho com projetos Open Source?
Mais/menos estressante, divertido, puxado, significativo, recompensador, etc.

10. Em sua opinio, qual o maior atrativo da empresa para atrair profissionais? 11. Quais so os maiores motivos de sada de profissionais desta empresa? 12. Em relao a empresas no qual voc j trabalhou anteriormente como GP, como voc acha que os engenheiros de software se sentem trabalhando nesta empresa?

13. Em relao a projetos no qual voc j gerenciou/participou anteriormente, como voc acha que os engenheiros de software se sentiram trabalhando especificamente neste projeto?
Sondagem: Quais as principais caractersticas desses projetos anteriores possuem?

Na sua opinio, qual o maior atrativo deste Projeto Open Source? Quais so os maiores motivos de sada de profissionais destes projetos Open Source? Em relao a outros projetos, nos quais voc j participou anteriormente como GP, como voc acha que os engenheiros de software se sentem trabalhando no contexto Open Source? Mesma Pergunta

14. Como funciona a diviso de trabalho/tarefas dentro da sua equipe? 15. Como voc acha que os engenheiros se sentem trabalhando em equipe? 16. Descreva o que voc considera um dia extraordinariamente BOM para um membro de sua equipe.

Mesma Pergunta

Mesma Pergunta Retirada

79 # Perguntas da Pesquisa Original (Da SILVA et al, 2011) 17. Em sua opinio, quais aspectos da Engenharia de Software mais motivam os engenheiros? Pergunta modificada para o Contexto Em sua opinio, quais aspectos da Engenharia de Software mais estimulam os engenheiros em projetos Open Source? Mesma Pergunta

18. Como voc percebe que esses aspectos esto presentes ou ausentes no seu projeto? 19. Em sua opinio, dentre as caractersticas desta empresa, quais so as que mais estimulam os engenheiros de software? 20. Em sua opinio, dentre as caractersticas do projeto, quais so as que mais estimulam os engenheiros de software? 21. Dentre as atividades do dia a dia da sua equipe de engenheiros de software, quais voc acha que eles se sentem mais estimulados fazer? Sondagem: Voc leva isso em considerao no momento de atribuir alguma atividade a um membro da equipe? 22. O que voc acha que estas atividades possuem, para deixar os engenheiros to estimulados? 23. Voc poderia descrever uma situao REAL em que voc percebeu que um de seus engenheiros de software estava altamente motivado com o trabalho? Sondagem: Como foi que voc percebeu? Porque voc considerou que ele estava motivado? O que voc acha que causou aquela motivao? 24. Descreva alguma situao em que voc notou um engenheiro realmente estimulado para trabalhar especificamente nesse projeto.

Em sua opinio, dentre as caractersticas deste projeto, quais so as que mais estimulam os engenheiros de software? Mesma Pergunta

Retirada

Retirada

Voc j conseguiu perceber alguma situao REAL em que um dos seus colegas de projeto estava altamente motivado com o trabalho? Se sim, voc pode descrever a situao?
Sondagem: Como foi que voc percebeu? Porque voc considerou que ele estava motivado? O que voc acha que causou aquela motivao?

Mesma Pergunta

80 # Perguntas da Pesquisa Original (Da SILVA et al, 2011) 25. Como voc descreveria o comportamento de um engenheiro de software que est claramente motivado com o trabalho? 26. Como voc descreveria os resultados de um engenheiro de software que est claramente motivado com o trabalho? 27. O que a sua organizao oferece ou faz para estimular a motivao dos engenheiros de software? 28. De que forma essas aes afetam o comportamento positivamente dos engenheiros? 29. De que forma essas aes afetam os resultados positivamente dos engenheiros? 30. Descreva o que voc considera um dia extraordinariamente RUIM para um membro de sua equipe. 31. Em sua opinio, quais aspectos da Engenharia de Software mais desmotivam os engenheiros? Pergunta modificada para o Contexto Mesma Pergunta

Mesma Pergunta

O que a comunidade oferece ou faz para estimular a motivao dos engenheiros de software? Mesma Pergunta

Mesma Pergunta

Retirada

32. Como voc percebe que esses aspectos esto presentes ou ausentes no seu projeto? 33. Em sua opinio, dentre as caractersticas desta empresa, quais so as que mais desestimulam os engenheiros de software?

Em sua opinio, quais aspectos da Engenharia de Software mais desmotivam a desenvolver software Open Source? Mesma Pergunta

34. Em sua opinio, dentre as caractersticas do projeto, quais so as que mais desestimulam os engenheiros de software?

Em sua opinio, dentre as caractersticas dos projetos Open Source dos quais voc participa ou participou, quais so as que mais desestimulam os engenheiros de software? Mesma Pergunta

81 # Perguntas da Pesquisa Original (Da SILVA et al, 2011) 35. Dentre as atividades do dia a dia da sua equipe de engenheiros de software, quais voc acha que eles menos gostam? Sondagem: Voc leva isso em considerao no momento de atribuir alguma atividade a um membro da equipe? 36. O que estas atividades possuem, para deixar os engenheiros to desestimulados? 37. Voc poderia descrever uma situao REAL em que voc percebeu que um de seus engenheiros de software estava altamente desmotivado com o trabalho?
Sondagem: Como foi que voc percebeu? E por que voc acha que aquilo era desmotivao? O que voc acha que causou aquela desmotivao?

Pergunta modificada para o Contexto Dentre as atividades do dia a dia da sua equipe de engenheiros de software, quais vocs acha que eles menos gostam?
Sondagem: Voc leva isso em considerao no momento de atribuir alguma atividade a um membro da equipe?

Mesma Pergunta

Mesma Pergunta

38. Descreva alguma situao em que voc notou um engenheiro realmente desestimulado para trabalhar especificamente nesse projeto. 39. Como voc descreveria o comportamento de um engenheiro de software que est claramente desmotivado com o trabalho? 40. Como voc descreveria os resultados um engenheiro de software que est claramente desmotivado com o trabalho? 41. O que voc faz quando percebe algum membro da sua equipe desmotivado? 42. O que a sua organizao faz (e/ou que no deveria fazer) que mais desmotiva os engenheiros de software? 43. De que forma essas aes afetam o comportamento negativamente dos engenheiros?

Mesma Pergunta

Mesma Pergunta

Como voc descreveria os resultados um engenheiro de software que est claramente desmotivado com o projeto? Mesma Pergunta

O que a comunidade faz (e/ou que no deveria fazer) que mais desmotiva os engenheiros de software? Retirar ou Mesma Pergunta

82 # 44. Perguntas da Pesquisa Original (Da SILVA et al, 2011) De que forma essas aes afetam os resultados negativamente dos engenheiros? Qual critrio voc utiliza para realizar a diviso do trabalho na sua equipe? Suponha que um determinado membro da sua equipe goste de realizar uma determinada tarefa, mas ele no tem habilidade, conhecimento ou experincia para realiz-la o que voc faz? Sondagem: Qual a reao dele? Quais so os pontos fortes da sua equipe? Como voc acha que os engenheiros se sentem em relao a cada um destes pontos fortes? Quais so os pontos fracos da equipe? Como voc acha que os engenheiros se sentem em relao a cada um destes pontos fracos? Como voc percebe que a MOTIVAO da sua equipe est em BAIXA? O que voc faz quando verifica que a motivao da equipe est baixa? Pense em algum na sua equipe que voc considera altamente motivado. Agora, pense em algum na sua equipe que voc considera altamente desmotivado. Voc poderia descrever a diferena entre os resultados destes dois engenheiros? Na sua opinio, o que a empresa deveria/poderia fazer (mas no o faz) para trabalhar melhor a motivao dos engenheiros de software? Pergunta modificada para o Contexto Retirar ou Mesma Pergunta Mesma Pergunta Retirada

45. 46.

47. 48.

Mesma Pergunta Mesma Pergunta

49. 50.

Mesma Pergunta Mesma Pergunta

51.

Mesma Pergunta

52. 53.

Mesma Pergunta Mesma Pergunta

54.

55. Para finalizar, como voc definiria o termo motivao?

Na sua opinio, o que a comunidade deveriam/poderiam fazer (mas no o fazem) para trabalhar melhor a motivao dos engenheiros de software? Mesma Pergunta

83 # Perguntas da Pesquisa Original (Da SILVA et al, 2011) 56. Voc gostaria de adicionar alguma informao ou observao que no foi perguntada, mas que voc considere importante para a motivao de engenheiros de software? Pergunta modificada para o Contexto Voc gostaria de adicionar alguma informao ou observao que no foi perguntada, mas que voc considere importante para a motivao de engenheiros de software no contexto Open Source? Mesma Pergunta

57. Por favor, faa uma avaliao de dois pontos fortes e dois pontos fracos desta entrevista.

84 APENDICE C Guia de Entrevista com Engenheiros de Software

Introduo Apresentao o Agradecimento ao participante o Permisso para gravar o udio da entrevista o Estimativa de tempo da entrevista (45 a 60 minutos) o Sobre o projeto de pesquisa o Metas, resultados esperados e benefcios para a organizao o Explicar cuidadosamente o que se espera da entrevista sobre motivao.

# 1.

2.

3.

Perguntas da Pesquisa Original (Da SILVA et al 2011) Fale um pouco de voc: sua formao, idade, trajetria profissional. O que o levou a trabalhar nesta rea (Engenharia de Software)? Sondagem: Teve contato com outras reas da computao, ou mesmo com outros campos de trabalho antes de trabalhar com Engenharia de Software? Quais? Como voc se sente atualmente trabalhando como engenheiro de software?
* Em comparao com outros campos/reas, como voc avalia o seu trabalho como engenheiro de software? Mais/menos estressante, divertido, puxado, significativo, etc. Em comparao as outras comunidades que voc j trabalhou como se sente nesta?

Pergunta modificada para o Contexto Mesma pergunta

O que o levou a trabalhar nesta rea (Engenharia de Software)? e com software Open Source?

Como voc se sente atualmente trabalhando com software Open Source?

4.

H quanto tempo voc trabalha nesta empresa?

5.

O que o levou a trabalhar nesta Empresa?

H quanto tempo voc trabalha com software Open Source e nessa comunidade? O que levou a trabalhar neste projeto e na comunidade?

85 6. Dentre as caractersticas desta quais te estimulam a trabalhar aqui? Dentre as caractersticas deste projeto quais te estimulam a trabalhar aqui? Dentre as caractersticas deste projeto quais te estimulam nesta comunidade? Dentre as caractersticas deste comunidade, o que te desestimula? Antes desta funo atual, quais outras funes ou atividades voc desempenhou na comunidade? Mesma pergunta Quais as atividades que voc faz/fazia para o projeto? Retirada

7.

Pergunta Adicionada

8.

Dentre as caractersticas deste projeto, o que te desestimula? Antes desta funo atual, quais outras funes ou atividades voc desempenhou nessa empresa?

9.

10. Descreva a sua funo atual e responsabilidades. 11. Quais as atividades que voc faz no dia-a-dia? 12. Agora imagine um dia extraordinariamente bom. Um dia no qual vrias, ou todas, as coisas do certo. Imagine este dia deste a hora em que voc acorda at a hora de dormir. Voc pode descrever este dia? Depois da resposta espontnea: como voc se sente ao acordar e sair de casa? Como sua chegada no trabalho? Pela manh, quais foram suas principais atividades? Como voc se sentiu no final da manh? Como foi a volta para o trabalho tarde? Como foi o trabalho na parte da tarde? Como voc encerrou o seu dia de trabalho? Como foi a volta para casa? Como voc encerrou o seu dia? 13. Dentre as atividades do seu dia a dia, quais so as que voc mais gosta? 14. Descreva o que estas atividades possuem, que caractersticas elas tem, que te deixa estimulado?

Quais atividade que voc mais gostava de Fazer? Mesma pergunta

86 15. Quais atividades voc gostaria de fazer e no faz? Como voc se sente? 16. Agora imagine um dia extraordinariamente ruim. Um dia no qual vrias, ou todas, as coisas do errado. Imagine este dia deste a hora em que voc acorda at a hora de dormir. Voc pode descrever este dia? Depois da resposta espontnea: como voc se sente ao acordar e sair de casa? Como sua chegada no trabalho? Pela manh, quais foram suas principais atividades? Como voc se sentiu no final da manh? Como foi a volta para o trabalho tarde? Como foi o trabalho na parte da tarde? Como voc encerrou o seu dia de trabalho? Como foi a volta para casa? Como voc encerrou o seu dia? 17. Dentre as atividades do seu dia a dia, quais so as que voc menos gosta? 18. Considerando outras atividades do projeto que no fazem parte do seu dia a dia, quais NO gostaria de fazer de jeito nenhum 19. Descreva o que estas atividades possuem, que caractersticas elas tem, que te deixam desestimulado. Sondagem: Em comparao a funes realizadas anteriormente, como voc se sente atuando nesta funo? 20. Descreva quem so as pessoas da sua equipe com quem voc tem relao direta no seu dia-a-dia. Mesma pergunta

Retirada

Quais atividades que voc menos gostava? Retirada

Mesma pergunta

Descreva quem so as pessoas da sua equipe com quem voc tem relao direta. 21. Como funciona a diviso de trabalho? Mesma pergunta Como a dinmica do trabalho em equipe? Qual o seu papel? 22. Como voc se sente trabalhando Mesma pergunta nesta equipe?

87 23. Na sua opinio, quais so alguns pontos fortes da sua equipe? 24. Como voc sente ao porto forte XX, YY, ZZ. 25. D-me um exemplo de uma situao que realmente voc se sentiu parte desta equipe. 26. Como voc descreveria um colega de trabalho que est claramente motivado com o trabalho? 27. De que forma voc acha que isso impacta no trabalho da equipe? 28. De que forma voc acha que isso impacta no trabalho dele? 29. Na sua opinio, quais so alguns pontos fracos da sua equipe? 30. Como voc sente ao porto fraco XX, YY, ZZ. 31. D-me um exemplo de uma situao que realmente voc no se sentiu parte desta equipe. 32. Como voc descreveria um colega de trabalho que est claramente desmotivado com o trabalho? 33. De que forma voc acha que isso impacta no trabalho da equipe? 34. De que forma voc acha que isso impacta no trabalho dele? 35. Tem alguma outra funo ou projeto [dentro da empresa?] que voc preferiria estar alocado? c Como voc se sentiria trabalhando l... 36. E tem alguma outra funo ou projeto [dentro da empresa?] que voc no gostaria de ser alocado de jeito nenhum? Como voc se sentiria trabalhando l... 37. O que a sua organizao oferece ou faz para estimular a motivao dos engenheiros de software? 38. Como essas aes afetam o seu trabalho? Mesma pergunta Mesma pergunta Mesma pergunta

Mesma pergunta

Mesma pergunta Mesma pergunta Mesma pergunta Mesma pergunta

Mesma pergunta

Mesma pergunta

Mesma pergunta Mesma pergunta Tem alguma outra funo ou projeto dentro da comunidade que voc preferiria estar alocado? Como voc se sentiria trabalhando l... Retirada

O que a comunidade lhe oferece para estimular a motivao dos desenvolvedores? Mesma pergunta

88 39. O que a sua organizao faz (e/ou que no deveria fazer) que mais desmotiva os engenheiros de software? 40. Como essas aes afetam o seu trabalho? Sondagem: Tanto comportamental como profissional. 41. Na sua opinio, o que a empresa deveria/poderia fazer (mas no o faz) para trabalhar melhor a motivao dos engenheiros de software? O que a sua comunidade faz (e/ou que no deveria fazer) que mais desmotiva os engenheiros de software? Ou retirar Retirada

42. Projetando voc daqui a 5 anos, que atividades voc gostaria de estar fazendo? No que voc gostaria de estar trabalhando ? 43. Projetando voc daqui a 5 anos, que atividades voc no queria fazer de jeito nenhum? E que tipo de projeto no gostaria de trabalhar? 44. Para finalizar, como voc definiria o termo motivao? 45. Voc gostaria de adicionar alguma informao ou observao que no foi perguntada, mas que voc considere importante para a motivao de engenheiros de software?

Na sua opinio, o que o mantenedor deveria/poderia fazer (mas no o faz) para trabalhar melhor a motivao dos engenheiros de software? Mesma pergunta

Mesma pergunta

Mesma pergunta Voc gostaria de adicionar alguma informao ou observao que no foi perguntada, mas que voc considere importante para a motivao de engenheiros de software no contexto Open Source? Mesma pergunta

46. Por favor, faa uma avaliao de dois pontos fortes e dois pontos fracos desta entrevista.

89 APENDICE D E-mail de convite

Boa tarde a todos,

Estou

desenvolvendo

meu

Trabalho

de

Concluso

de

Curso,

intitulado

(provisoriamente) de Uma Pesquisa Qualitativa Sobre os Principais Fatores Motivacionais dos Engenheiros de Software no Contexto Open Source, neste trabalho eu procuro encontrar indcios de fatores que motivam as pessoas a entrar no mundo "Open Source", como sou desenvolvedor de Android e participo do grupo gostaria de aplicar a pesquisa aqui.

Eu pretendo realizar uma entrevista via Skype com membros de um projeto, no mximo umas 4 a 5 pessoas que participam do mesmo projeto. A entrevista uma conversa normal com algumas questes sobre o que leva voc a desenvolver projetos Open Source, nada cansativo nem complexo.

Todas as informaes captadas nas entrevistas sero confidncias e claro eu enviarei uma copia do tcc para o grupo.

Algum gostaria de me ajudar?