Relatorio tecnico sobre os fatores motivadores em equipe open source

RELATORIO TECNICO

Motivação de Engenheiros de Software no Contexto Open Source: Um Estudo de Caso com a Comunidade Android Brasil Projetos

DANILO MONTEIRO RIBEIRO

PIETRO PEREIRA PINTO

ALBERTO CÉSAR CAVALCANTI FRANÇA

CARUARU

2013

ii

Resumo

Este trabalho tem como tema central o estudo da motivação 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 necessário identificar quais

fatores influenciam na comunidade e quais são os sinais externos de motivação e

desmotivação. Foram entrevistadas quatro pessoas da comunidade sendo um

mantenedor e três desenvolvedores. Os dados coletados foram analisados utilizando

métodos da Teoria Fundamentada (Grounded Theory), e sintetizados em uma teoria

fundamentada nos dados que pode fornecer um entendimento sobre os

relacionamentos, causas e consequências dentro do contexto estudado. Como

resultado foram encontrados 27 fatores que influenciam na motivação da amostra

estudada e foram desenvolvidas 11 proposições. Além disso, foram definidos como

os fatores centrais da teoria o comprometimento e o interesse pessoal.

Palavras-chave: Engenheiro de Software, Motivação, Open Source.

iii

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 27 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.

iv

SUMÁRIO

1. INTRODUÇÃO ..................................................................................................... 8

1.2 Objetivos ....................................................................................................... 9 1.2.1 Objetivo Geral ........................................................................................ 9 1.2.2 Objetivos Específicos ............................................................................. 9

1.3 Justificativa de pesquisa ............................................................................. 10 1.4 Organização do Trabalho ........................................................................... 12

2 REFERENCIAL TEÓRICO ................................................................................ 13

2.1 Open Source e Software Livre ......................................................................... 13 2.1.1 Software Livre ...................................................................................... 13 2.1.2 Free Software Fundation ...................................................................... 14 2.1.3 Software Open Source ......................................................................... 15 2.1.3.1 Características do desenvolvimento Open Source .............................. 18 2.2 O Estudo da Motivação e suas Aplicações ao Contexto da Engenharia de Software ................................................................................................................. 19 2.2.1 O Estudo da Motivação na Psicologia ................................................. 19 2.2.2 Motivação no Desenvolvimento de Software ....................................... 20 2.2.3 Motivação no contexto Open Source ................................................... 24 2.2.3.1 WU et al (2007) .................................................................................... 25 2.2.3.2 Oreg e Nov (2007) ............................................................................... 26 2.2.3.3 Von Krogh et al (2008) ......................................................................... 28 2.3 Discussão ........................................................................................................ 31

3 MÉTODOS ......................................................................................................... 32

3.1 Natureza da Pesquisa ................................................................................. 32 3.1.1 Quanto aos Fins ................................................................................... 32 3.1.2 Quanto à Forma de Abordagem ............................................................... 32 3.1.3 Quanto aos métodos de procedimentos ................................................... 33

3.2 Premissas ........................................................................................................ 34 3.3 Etapas de pesquisa ......................................................................................... 34 3.4 Seleção de sujeitos .......................................................................................... 35 3.4.1 Entrevista ...................................................................................................... 35

v

3.5 Procedimentos da análise de dados ................................................................ 38 3.5.1 Teoria Fundamentada em Dados (Ground Theory) ..................................... 38 3.5.2 Procedimento de codificação ........................................................................ 39 3.5.2.1 Codificação Aberta .................................................................................... 41 3.5.2.2 Codificação Axial .................................................................................. 42 3.5.2.3 Codificação Seletiva ............................................................................. 43 3.6 Limitações ................................................................................................... 44 3.7 Discussão ................................................................................................... 45

4. Resultados ........................................................................................................... 45

4.1 Descrição do Contexto .................................................................................... 45 4.2 Resultados da Codificação aberta ................................................................... 47 4.2.1 Aspectos da Comunidade ............................................................................. 48 4.2.3 Aspectos do trabalho em equipe .................................................................. 52 4.3 Resultados da codificação axial ...................................................................... 56 4.4 Resultados da codificação seletiva .................................................................. 60 4.5 Avaliações dos Resultados .............................................................................. 62

5. Conclusão ............................................................................................................ 64

5.1 Trabalhos futuros ............................................................................................. 65

REFERÊNCIAS ......................................................................................................... 67

vi Índice de figuras

Figura 1 - MOCC .................................................................................................................... 23

Figura 2 - Motivadores intrínsecos e extrínsecos ............................................................. 24

Figura 3 - Geração da teoria da comunidade ................................................................... 61

vii

Índice de Tabelas

Tabela 1 - Evolução do conceito de Motivação ................................................................ 19

Tabela 2 - Fatores Motivadores ........................................................................................... 21

Tabela 3 - Fatores Desmotivadores ................................................................................... 22

Tabela 4 - Fatores Motivacionais intrínsecos .................................................................... 29

Tabela 5 - Fatores Motivacionais extrínsecos internos ................................................... 29

Tabela 6 - Fatores Motivacionais extrínsecos ................................................................... 30

Tabela 7 - Aspectos motivacionais ..................................................................................... 47

Tabela 8 - Sinais de motivação ........................................................................................... 54

8 1. INTRODUÇÃO

A atividade de desenvolvimento de software enfrenta crescentes desafios

visando a diminuição de custo, esforço e tempo de chegada dos produtos no

mercado. Contudo, a complexidade e tamanho dos produtos estão aumentando e,

consequentemente, os gestores precisam buscar novas alternativas para o processo

de desenvolvimento.

Uma dessas alternativas pode ser a utilização de software Open Source

(FERREIRA, 2005). Segundo Koch (2008) e Subramanyam e Xia (2008), os

aplicativos Open Source são aqueles cujo código fonte está disponível para qualquer

pessoa, ou seja, ele está sob uma licença que estabelece condições para

modificação, reuso e redistribuição do software, oferecendo assim a possibilidade de

um usuário modificá-lo, adequando-o as suas necessidades.

De acordo com IBM (2007), uma das principais características deste tipo de

software é fato de ser normalmente desenvolvido por equipes distribuídas

geograficamente. Em geral, os membros dessas equipes não se conhecem

pessoalmente e são coordenados por estruturas baseadas em meritocracia, nas

quais, de acordo com Ferreira (2008), as pessoas obtêm tarefas e responsabilidades

de acordo com seu merecimento. Essa forma de organização é bem diferente das

estruturas hierárquicas formais que contam com um gerente para distribuir

atividades e cobrar produtividades de seus subordinados.

Conforme França et al (2011), o comportamento de equipes de

desenvolvimento de software tem sido estudado de forma crescente nos últimos

anos, principalmente através de pesquisas que buscam entender, em especial, os

fatores que motivam e desmotivam engenheiros de software durante o

desenvolvimento do projeto.

França e Da Silva (2009) afirmam que existem duas ideias principais de

interesse da indústria na gestão comportamental: a primeira corresponde à

necessidade de criação de um clima organizacional no qual os colaboradores

possam obter respeito e valorização; a segunda parte da premissa que pessoas

motivadas produzem mais.

9

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 são formadas por colaboradores voluntários,

que trabalham quando querem, de forma autônoma e sem vínculos empregatícios,

ou obrigações com o projeto. Apesar destes colaboradores poderem se desligar do

projeto a qualquer momento, eles conseguem desenvolver, com sucesso, projetos

de alto nível e complexidade (IBM, 2007).

Para realização 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) são 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 específicos:

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 Específicos

• Identificar, com base em revisões de literatura, os principais fatores motivacionais ligados aos projetos de desenvolvimento de software Open Source;

• Adaptar o questionário 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 motivação;

1 Para mais informações http://www.android.com/

10

• Analisar os dados coletados através do instrumento de pesquisa aplicado;

• Encontrar quais fatores motivacionais afetam a comunidade Android-Brasil-Projetos;

• Conhecer quais são os sinais externos de motivação na comunidade Android-Brasil-Projetos.

• Explicar como os fatores encontrados agem na comunidade Android-Brasil-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

proprietários. Entretanto, segundo a TIINSIDE (2008), essa projeção já foi superada

e estima-se que esse percentual já estava em 85% em 2008.

Desde então, 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 licença 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 código aberto estão sendo

constantemente utilizados por empresas no seu dia-dia, destacando-se como as três

principais razões para a utilização de programas de código aberto: (i) a diminuição

do custo total de propriedade, (ii) a redução dos custos de desenvolvimento e (iii) o

fato de o software livre ser mais fácil de ser implementado em novos projetos de TI.

Segundo Von Krogh et al (2008), nos últimos 15 anos os aplicativos Open

Source fizeram incursões bem-sucedidas em diversos segmentos, atraindo milhões

de usuários. Atualmente, as empresas investem e colaboram em grande quantidade

neste tipo de produto. Como resultado disto, Von Krogh et al (2008 p.4, tradução

2 é uma designação de uma licença para software livre idealizada por Richard Matthew Stallman

11 nossa) afirma que: “os gestores destas empresas estão cada vez mais dependente

de recursos de desenvolvimento que estão fora do seu controle direto”.

Assim, esses gestores estão preocupados com o que motiva colaboradores

externos a participar na criação de um software Open Source. Von Krogh et al

(2008) cita como exemplo que se uma empresa decide investir milhões de dólares a

fim de migrar os seus servidores para um sistema Linux da IBM os gestores vão

querer saber até que ponto o Linux continuará a receber contribuições por

voluntários, como o software irá evoluir, e se Linux e outros projetos envolvidos

terão melhoria em novas versões.

Desta forma, entender os fatores envolvidos na motivação no

desenvolvimento de software no cenário Open Source é de grande importância 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 benefícios para a empresa e mantendo a competitividade da

mesma.

Além disso, os mantenedores3 de comunidades Open Source também

precisam saber o que faz os membros contribuírem mais com a comunidade e

permanecerem nos projetos até que estes sejam concluídos com sucesso, ou

continuem a trabalhar na evolução do mesmo.

Para isso, é de suma importância a realização de uma pesquisa que vise

encontrar indícios sobre os fatores motivacionais aplicados nesse contexto, para que

se possa compreender melhor o fenômeno estudado e encontrar possíveis novos

fatores motivacionais.

Entretanto, ainda são escassos os estudos que visam identificar os fatores

motivacionais no contexto de projetos de software Open Source usando uma

abordagem qualitativa. Sendo assim, a problemática 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?

3 Os mantenedores são os responsáveis pelos projetos na comunidade.

12 1.4 Organização do Trabalho

Neste capítulo foi realizada uma breve introdução aos temas deste trabalho:

Motivação no desenvolvimento de software e Open Source software. Foi também

apresentado o problema de pesquisa, os objetivos gerais e específicos do trabalho e

a justificativa para realização deste. O restante do trabalho está organizado da

seguinte forma:

Capítulo 2 – Referencial teórico: Neste capítulo é feita uma revisão

bibliográfica acerca dos principais temas relacionados à pesquisa, a saber: Open

Source e Software Livre, Motivação na engenharia de Software e no contexto Open

Source;

Capítulo 3 – Métodos: É o capítulo no qual se contempla a descrição do

método de pesquisa utilizado no trabalho, bem como as limitações deste;

Capítulo 4 – Resultados: Onde serão apresentados os resultados da

codificação aberta, axial e seletiva.

Capítulo 5 – Conclusão e trabalhos futuros: Contempla as conclusões

obtidas da realização da pesquisa e geração da teoria, assim como os trabalhos

futuros.

13 2 REFERENCIAL TEÓRICO

Neste capítulo de referencial teórico são apresentadas as definições dos

conceitos necessários ao desenvolvimento do trabalho, a saber: software livre, Open

Source e motivação.

2.1 Open Source e Software Livre

Este capítulo aborda de forma sucinta o assunto Software Open Source,

discorrendo brevemente sobre sua Historia, sua definição e diferenças com o

software livre e algumas características 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 cópias originais,(iv) distribuir livremente cópias modificadas.

O software livre é diferente do software proprietário, pois, segundo Saleh

(2004 p.13), “No software proprietário em geral a única liberdade garantida ao

usuário é a de usar o programa, mesmo assim somente após seu licenciamento, e

com compromisso de não redistribuí-lo nem modifica-lo”. Existem ainda software

proprietários grátis, como jogos e mensageiros instantâneos. Contudo, como estes

não seguem as quatro premissas do software livre, apresentadas anteriormente, não

são considerados livres.

Saleh (2004) afirma que nas décadas de 1960 e 1970 praticamente todo o

software era livre, pois a pratica da comercialização de licenças ainda não 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 usuários que

compravam o hardware, sendo específicos para a arquitetura adquirida.

Devidos a estas características, universidades, empresas e centros de

pesquisas compartilhavam os códigos da mesma comunidade, sem preocupações

14 com direitos autorais. Como na segunda metade da década de 1970 a

comercialização de licenças começou a aparecer com mais força, o movimento do

software livre sentiu a necessidade de se organizar mais, tendo como umas das

consequências a criação 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 informática o espírito cooperativo

que se apresentava no inicio da computação, em que seus códigos, informações e

maneiras de trabalho eram livremente compartilhados (STALLMAN, 2002). Esta

organização é considerada como a principal patrocinadora do projeto GNU/LINUX

(GNU, 1996).

Em 1981, o laboratório de inteligência artificial do Massachusetts Institute of

Technology (MIT) teve seu principal computador, que tinha o sistema operacional e

aplicativos desenvolvidos pela própria equipe da universidade, com software livre,

substituído por outro computador com códigos proprietários e fechados do fabricante

do novo computador (STALLMAN, 2002).

Richard Stallman, até então professor do MIT, resolveu que não deveria

assinar os acordos de não divulgação impostos pelo fornecedor do hardware,

decidindo assim, não trabalhar com o software proprietário do fornecedor. Stallman

queria incentivar as pessoas a criarem software suficiente que permitisse a utilização

de um computador sem a necessidade de qualquer programa proprietário, pois ele

acredita que essa opção é a única socialmente justa (STALLMAN, 1999 apud Saleh

2004).

Stallman (1999 apud Saleh, 2004, p.18) afirma que:

“o software proprietário implica numa organização social na qual não é

permitido às pessoas compartilhar conhecimento, não é permitido ajudar ao

próximo e incita à competição ao invés da colaboração: 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 malefícios

15 que benefícios.” Quando o usuário resolve pagar pela licença, está acontecendo

uma transferência de riquezas que será benéfica para ambas as partes, uma vez

que o usuário terá o software para resolver seu problema e a empresa terá o valor

da licença. Todavia, se o usuário resolve não adquirir o software, pois existe à

necessidade de pagamento, está havendo prejuízo a uma das partes sem que haja

benefício de ninguém.

Stallman (1999 apud SALEH 2004) pondera que o prejuízo à sociedade pela

restrição é maior que os possíveis ganhos individuais da empresa, já que se estão

sendo impostas restrições a um bem cujo custo marginal de produção é zero, ou

seja, não ocorre acréscimo (ou decréscimo) do custo total quando se aumenta (ou

diminui) a quantidade de software produzida, e que as empresas de software

proprietário restringem a cooperação entre as pessoas e limitam o conhecimento da

sociedade com a proibição da distribuição do software. A principal ideia que

Stallman (1999 apud Saleh 2004) quer passar é que o software fechado nega o

acesso à informação e ao conhecimento, elementos sem os quais é impossível

estabelecer uma sociedade mais justa e democrática.

2.1.3 Software Open Source

A Open Source Initiative4 [s.d] aponta que a publicação 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 práticas populares na

comunidade Software Livre, foi de grande importância para o difusão do software

Open Source. Sua análise, centrada na ideia de revisão por pares distribuída, na

liberação 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 apresentação deste trabalho em setembro de 1997 foi o incentivo para a

Netscape, em 22 de janeiro de 1998, liberar o código 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 Para maiores informações: http://www.opensource.org 5 Texto disponível em http://www.catb.org/~esr/writings/cathedral-bazaar/

16 desenvolvimento estavam prestes a mudar, e que qualquer coisa seria possível”.

(OPEN SOURCE INITIATIVE, s.d, tradução nossa)

O rótulo "Open Source" foi concebido em uma sessão realizada em 03 de

fevereiro de 1998, em Palo Alto, Califórnia. Dentre as pessoas presentes nesta

sessão estavam: Todd Anderson, Chris Peterson (do Foresight Institute), John

"maddog" Hall e Larry Augustin (ambos da Linux International), Sam Ockman (do

Grupo Vale do Silício do usuário 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 não

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 pragmáticas que motivaram Netscape. Eles debateram as táticas que

deveriam usar e um novo rótulo, "Open Source", foi proposto por Chris Peterson.

Cinco dias depois, em 8 de fevereiro de 1998, foi emitida a primeira chamada

pública para a comunidade começar a usar o novo termo.

As pessoas envolvidas no movimento Open Source trabalhavam com

software livre, mas sentiam-se incomodadas com o caráter ideológico imposto pela

FSF e sua licença GNU GPL. Então, esse movimento quis retirar do

desenvolvimento de software livre qualquer componente social ou ideológico. O

software deve ser aberto não por questões de liberdade, mas sim porque o modelo

aberto de desenvolvimento é mais eficiente tanto técnica quanto economicamente

(OPEN SOUCE INITIATIVE, s.d; SALEH, 2004). A ideia principal é que enquanto os

programadores estão lendo e modificando o código, naturalmente vão aparecer

melhorias, adaptações e correções, que têm como consequência uma maior

evolução do programa.

Qualquer licença de software pode ser considerada aberta caso siga os

seguintes termos (PERENS, 1999; OPEN SOUCE INITIATIVE s.d):

(i) Distribuição livre – A licença não deve impedir a venda ou distribuição do

programa gratuitamente, seja ele como componente de outro programa ou não.

(ii) Código fonte – O programa deve incluir seu código fonte ou deve haver

algum maneira de obtê-lo pela internet ou com custo de reprodução, permitindo a

17 sua distribuição também na forma compilada. O código deve ser legível e inteligível

por qualquer programador.

(iii) Trabalhos Derivados – A licença deve permitir modificações e trabalhos

derivados, permitindo, inclusive, que esses sejam distribuídos sobre os mesmos

termos da licença original.

(iv) Integridade do autor do código fonte - A licença pode impedir que o

código fonte seja distribuído em uma forma modificada apenas se a ela permitir a

distribuição de arquivos de atualização com o código fonte para o propósito de

modificar o programa. A licença também deve permitir a distribuição do programa

desenvolvido a partir do código fonte modificado. Todavia, a licença pode ainda

requerer que programas derivados tenham um nome ou número de versão

diferentes do programa original.

(v) Não pode haver discriminação contra pessoas ou grupos - A licença não

pode ser discriminatória contra qualquer pessoa ou grupo de pessoas.

(vi) Não pode haver discriminação contra áreas de atuação - A licença não

deve impedir qualquer pessoa de usar o programa em um ramo específico de

atuação. Por exemplo, ela não deve proibir que o programa seja usado em um

empresa, ou para pesquisa genética.

(vii) Distribuição da Licença - Os direitos ao programa devem ser aplicáveis

para todos aqueles que receberem o programa, sem a necessidade da execução de

uma licença adicional para estas partes.

(viii) A Licença não é específica a um produto - Os direitos associados ao

programa não devem estar sujeitos que o programa seja parte de uma distribuição

específica de programas, ou seja, não se pode obrigar a executar o programa

somente em alguma distribuição do Linux, por exemplo. Se o programa é extraído

desta distribuição e usado ou distribuído dentro dos termos da licença do programa,

todas as partes para as quais o programa é redistribuído devem ter os mesmos

direitos que aqueles que são garantidos em conjunção com a distribuição de

programas original.

(ix) A Licença não restringe outros programas - A licença não pode colocar

empecilhos em outros programas que são distribuídos juntos com o programa

18 licenciado. Isto é, a licença não pode especificar que todos os programas

distribuídos na mesma mídia de armazenamento sejam programas de código aberto.

(x) A Licença é neutra em relação a tecnologia - Nenhuma cláusula da

licença pode estabelecer uma tecnologia individual, estilo ou interface a ser aplicada

no programa

Como pode ser notado na leitura dos termos, na definição da licença Open

Source não é feita qualquer referência a aspectos políticos, sociais e de liberdade,

diferentemente da licença 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 distribuído como

software proprietário, algo não permitido pela licença 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 louvável, mas não o

mais importante, pois o mais importante para ele é que o software siga as quatro

premissas do software livre.

2.1.3.1 Características do desenvolvimento Open Source

Segundo Nunes (2007), os projetos Open Source apresentam algumas

características que os tornam diferentes do paradigma de desenvolvimento

convencional, como: (i) Trabalho voluntário, uma vez boa parte dos desenvolvedores

trabalham sem remuneração, (ii) Trabalho não é designado, as tarefas ficam

disponíveis para os membros que tenham interesse ou aptidão as escolham para

realizar, (iii) Ausência de cumprimento de horários e de lista de entregas, uma vez

que o trabalho é voluntário, as pessoas trabalham em horários diversificados e

contribuem da maneira que podem, (iv) lançamentos de versões, a própria

comunidade em conjunto com os mantenedores discute quando será lançada uma

nova versão do software e atualizações da mesma, (v) teste, em projetos Open

Source é comum utilizar os usuários como testadores do software, assim como nem

sempre existe um sistema bem definidos de testes de software e (vi) planejamento,

nem sempre é possível devido ao não determinismo da colaboração.

19

Todavia, estas caraterísticas não estão presentes em todas as comunidades,

algumas comunidades podem ter características únicas ou não utilizar algumas das

caraterísticas citadas.

2.2 O Estudo da Motivação e suas Aplicações ao Contexto da Engenharia de Software

Nas subseções a seguir serão apresentados os conceitos de motivação na

psicologia, no desenvolvimento de software e no contexto Open Source.

2.2.1 O Estudo da Motivação na Psicologia

Segundo Todorov e Moreira (2005), o estudo da motivação humana vem

sendo observado desde o começo do século XX, com base na psicoterapia, na

psicometria e nas teorias de aprendizagem.

França e Da Silva (2009) afirmam que a definição de motivação tem resultado

em diversas teorias, trazendo consigo, inclusive, diversas definições para o termo,

conforme exemplificado na Tabela 1.

Tabela 1 - Evolução do conceito de Motivação

Ano Autores O que é motivação?

1959 Krech e Crutchfield Um motivo é a uma necessidade ou desejo acoplado com a intenção de atingir um objetivo apropriado

1961 Young Uma busca dos determinantes (todos os determinantes) da atividade humana e animal.

1964 Atkinson Uma concepção coerente dos determinantes contemporâneos da direção, do vigor e da persistência da ação.

1967 Hilgard e Atkinson “Motivo” é algo que incita o organismo á ação ou que sustenta ou dá direção à ação quando o organismo foi ativado.

1997 Rogers, Ludington e Graham Motivação é um sentimento interno, é um impulso que alguém tem de fazer para realizar alguma coisa.

2000 Licury e Fenouillet ... a motivação é o conjunto de mecanismos biológicos e psicológicos que possibilitam o desencadear da ação, da orientação (para uma meta ou, ao contrário, para se afastar dela) e, enfim, da intensidade e da persistência: quanto mais motivada a pessoa está, mais persistente e

20

maior é a atividade.

2001 Penna É o conjunto de relações entre as operações de estimulação ou privação e as modificações observadas no comportamento que se processa após as citadas operações.

2004 Bzuneck A motivação tem sido entendida ora como um fator psicológico, ou conjunto de fatores ora como um processo. Estes fatores levam a uma escolha, instigam, fazem iniciar um comportamento direcionado a um objetivo.

Fonte: França e Silva (2009)

Pode ser observado na Tabela 1 uma série de conceitos sobre motivação,

que possuem características semelhantes, como fatores psicológicos e biológicos,

sendo um sentimento interno, que leva um indivíduo a executar uma ação com

intensidade e persistência para maximizar o resultado.

Isto corrobora com a definição apresentada por Minicucci (2009 apud Da

SILVA et al 2011), que define motivação como sendo algo interno ao indivíduo, que

varia de acordo com o objetivo, apresentando direção, intensidade, força e duração,

determinando um comportamento.

Todavia, um problema recorrente na literatura que aborda motivação é a

confusão que existe com outros fenômenos como entusiasmo, satisfação, conforto,

alegria, necessidade, vontade, fé, desejo e instinto (Da SILVA; FRANÇA, 2011;

BERGAMINI, 1998; Da SILVA et al, 2011). Contudo, motivação se distingue destas

palavras, pois ela é intrínseca à pessoa e pela sua capacidade de gerar um

comportamento sustentável e por isso deve ser analisada de maneira mais completa

(Da SILVA et al, 2011).

2.2.2 Motivação no Desenvolvimento de Software

De acordo com Sharp et al (2009), a motivação 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 motivação existentes. Beecham et al (2007) realizaram uma revisão

sistemática na literatura na qual catalogaram 92 artigos sobre motivação em

21 Engenharia de Software, publicados entre os anos de 1980 a 2006. Tal estudo

procurou responder as seguintes questões: (i) Quais as características dos

engenheiros de software? (ii) O que (des)motiva engenheiros de software a serem

mais produtivos ou menos produtivos? (iii) Quais são 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 motivação existentes na Engenharia de Software?

França et al (2011) realizaram uma atualização desta revisão com o objetivo

de responder as mesmas questões do estudo original, porém com artigos publicados

no período de 2006 até 2010. Essa atualização da revisão encontrou 53 artigos, os

quais foram analisados para se chegar a novas evidências, com relação ao estudo

original, que reforçam alguns resultados encontrados no trabalho de Beecham et al.

(2007).

Com a aplicação da pesquisa de Beecham et al (2007) foi observado que a

motivação dos engenheiros de software é definida por três fatores que estão

relacionados: características individuais, controles internos e moderadores externos.

Além disso, a pesquisa apresenta que engenheiros desmotivados tendem a deixar

as organizações onde trabalham, enquanto que o aumento de produtividade e a

retenção de membros da organização tende a serem resultados associados aos

engenheiros motivados. O trabalho apresenta também a divisão 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 motivação-higiene

criada pelo psicólogo Frederick Herzberg (1923-2000).

Tabela 2 - Fatores Motivadores

Motivação para Engenheiros de Software

Recompensa e incentivos

Satisfação da necessidade de desenvolvimento

Variedade do trabalho Plano de Carreira Sensação de

pertencimento a uma esquipe

Equilíbrio entre a vida pessoal e profissional

Trabalhar em uma empresa de sucesso

Participação

Empowerement/ Responsabilidade

Feedback

22

Bom gerenciamento Reconhecimento Confiança/ respeito Equidade

Trabalho tecnicamente desafiador

Segurança no emprego

Contribuir/ importância da tarefa

Condições apropriadas de trabalho

Autonomia Identificação com a tarefa

Recursos suficientes Adaptado de Da Silva et al. (2011)

Tabela 3 - Fatores Desmotivadores

Desmotivadores para Engenheiros de Software

Risco Stress Inequidade Trabalho interessante

feito por outras partes Sistema desleal de

recompensa Falta de promoção

Comunicação Ruim Pagamento não competitivo

Metas não realísticas Mau relacionamento com os colegas e

usuários Gerenciamento ruim Ambiente de trabalho

ruim (falta de recursos) Produção de Software de

má qualidade Equidade

Falta de influência Adequação cultural ruim

Adaptado de Da Silva et al (2011) O principal fator motivador encontrado no trabalho de Beecham et al (2007)

foi a identificação com a tarefa. Quanto mais o indivíduo se identifica com a tarefa

mais ele fica motivado. Outros fatores motivadores que também tiveram destaque

são: participação, bom gerenciamento, plano de carreira e variedade da tarefa. No

estudo realizado por França et al (2011), foi encontrado que os fatores mais

recorrentes são: identificação com a tarefa, participação e bom gerenciamento.

Outros fatores que também estão entre os mais citados são: boa auto-imagem,

aprendizagem e auto-desenvolvimento.

Quanto aos fatores desmotivacionais, o ambiente de trabalho ruim, com a

falta de recurso se destaca como característica mais citada, de acordo com o estudo

de Beecham et al (2007). Já o trabalho de França et al (2011) cita como principais:

complexidade da tarefa (muito fácil ou muito difícil) e carga de trabalho. Entre os

23 fatores em comum do estudo de França et al (2011) com estudo de Beecham et al

(2007) aparecem gerenciamento ruim e pagamento não competitivo.

Sharp et al (2009) propõem um novo modelo de motivação em Engenharia de

Software, baseado em na teoria da motivação-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 motivação e desmotivação são constructos

diferentes.

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

6Para mais informações: http://www.sobreadministracao.com/tudo-sobre-a-teoria-dos-dois-fatores-de-frederick-herzberg/

24

Figura 2 - Motivadores intrínsecos e extrínsecos

Fonte: Da Silva et al (2011)

2.2.3 Motivação 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. Também são

característica desse tipo de projeto os integrantes contribuírem mesmo sem terem

vínculos empregatícios, pagamentos ou mesmo sem serem recrutados pelas

organizações responsáveis pelo produto em desenvolvimento (LERNE;TIROLE,

2002). Nas seções 2.2.3.1, 2.2.3.2, 2.2.3.3 são apresentados estudos que abordam

os motivos dos engenheiros de software contribuírem voluntariamente, com seu

tempo e habilidades, em projetos Open Source. Após isso, será feito uma

consideração final sobre os assuntos.

25 2.2.3.1 WU et al (2007)

Este trabalho investiga a intenção 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 empírico, validado com 148 participantes e utilizando a escala de Likert7.

Com base na revisão de literatura o autor encontra uma lista de fatores

extrínsecos e intrínsecos envolvidos no Open Source. Os fatores extrínsecos,

segundo o autor, são os fatores ambientais, interpostos pela organização a um

indivíduo. Os motivadores intrínsecos, também chamados de motivadores internos,

estão relacionados às necessidades do indivíduo. Vale destacar que neste trabalho

o autor não analisou o conjunto completo de possíveis motivadores, se

concentrando, então, naqueles que ele acredita terem efeito mais forte, que são:

(i) Comportamento de ajuda: Wu et al (2005) acredita que o altruísmo é 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 mão aos outros e, simultaneamente, gostam de ter a mesma ajuda

quando precisam.

(ii) Aprimoramento do capital humano: O capital humano é um dos incentivos

extrínsecos envolvidos no software Open Source. Sendo assim, o capital humano

envolve o acumulo de investimentos das pessoas na sua educação e no treinamento

do trabalho que elas desenvolvem no dia-a-dia.

(iii) Progressão na carreira: Baseado em outros estudos, acredita-se que a

participação em um projeto Open Source pode avançar a carreira de uma pessoa de

duas maneiras: através da demonstração de suas capacidades e habilidades para

potenciais empregadores; usando a participação em projetos para obter acesso ao

capital de risco, aquisição de ações ou para lançar um empreendimento empresarial.

(IV) Satisfação de necessidades pessoais: Vários projetos Open Source começam

porque os desenvolvedores não conseguem encontrar produtos que satisfazem uma

7 É uma escala onde os respondentes são solicitados não só a concordarem ou discordarem das afirmações, mas também a informarem qual o seu grau de concordância / discordância.

26 função em particular, dessa forma, o software e o conhecimento necessário para

utilizá-lo provêm um valor extrínseco para o desenvolvedor.

Além disso, para sua pesquisa WU et al (2007, tradução nossa p.259)

também relaciona o nível de satisfação com o projeto afirmando que: “A satisfação

(em trabalhar em um projeto Open Source) deve depender de suas expectativas

pós-participação contra a sua percepção de valência para o seu desempenho”, ou

seja, a reação emocional às suas próprias motivações. De acordo com Reilly (2005),

a baixa satisfação no trabalho pode levar a comportamentos de indisciplina e

sabotagem. Em contraste, a satisfação no trabalho pode aumentar o

comprometimento organizacional e a cidadania (LEE; MODAWY, 1987).

Neste trabalho, o fator satisfação com a participação em projetos Open Souce é

a influência mais forte na participação em futuros projetos, seguido de:

aperfeiçoamento do capital humano e satisfação de necessidade pessoal. Ou seja,

os membros quando satisfeitos com sua particição 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 estão relacionados com os tipos de motivação

deles. Para isso eles usaram um survey, que foi aplicado a 300 contribuintes, em

dois contextos Open Source: Software e Conteúdo. O autor encontrou que os

contribuintes do contexto de software dão maior ênfase sobre a reputação e as

motivações de auto-desenvolvimento, enquanto que os contribuintes do contexto de

conteúdo (mantenedores da Wikipedia, por exemplo) dão maior ênfase nos motivos

altruístas.

Para realizar sua pesquisa o autor encontrou e classificou os seguintes

fatores motivadores:

(i) Reputação: Os autores acreditam, assim como Lakhani e Wolf (2005), que

empresas procuram programadores com habilidades especiais e podem

encontrar essas habilidades examinando códigos de software Open Source.

27

Assim, ganhar reputação pode ser extremamente interessante para quem

quer progredir a carreira na indústria de Software (LERNER; TIROLE, 2002).

(ii) Desenvolvimento próprio (aprendizado): Raymond (1999) afirma que o

processo de desenvolvimento de software Open Source envolve um

mecanismo de revisão de pares intensivo. Através deste processo os

colaboradores recebem feedback e podem obter sugestões de estilos de

programação e lógicas 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 conteúdo, só que por

motivos diferentes. No conteúdo as pessoas querem compartilhar o

conhecimento que elas detém (BONACCORSI; ROSSI, 2003); enquanto que

no contexto de software as pessoas estão mais focadas no que elas podem

ganhar do outros na comunidade e nas implicações no crescimento da

própria carreira (LERNER; TIROLE, 2002).

Para realizar sua pesquisa os autores utilizaram quatro valores de Schwartz

(1994) que eles acreditavam que teriam as seguintes relações com os três fatores:

(i) Realização com Reputação, pois os desenvolvedores pretende demostrar sua

competência para comunidade; (ii) Autodireção com Desenvolvimento próprio, já

que para o autor envolve a criatividade e liberdade; (iii) Benevolência e

Universalismo com Altruísmo, já que ambos, segundo os autores, promoviam o bem-

estar do próximo. Como resultado da pesquisa, os autores encontraram que motivação para

construir uma reputação em Open Source está correlacionada com ênfase do valor

da realização do individuo. Já a motivação para melhorar as suas competências

(Desenvolvimento próprio) está associada com sua ênfase pessoal em autonomia,

crescimento e livre pensamento. A motivação de ajudar a comunidade Open Source

está ligada ao valor da promoção do bem-estar ao próximo.

Embora a reputação, conforme a hipótese dos autores, era para ser mais forte

no contexto de software do que no contexto de conteúdo, foi, no entanto, de forma

inesperada o fator de motivação mais fraco dos três, em ambos os contextos. Oreg e

28 Nov (2007) acreditavam que exigência dos contribuintes em tornar pública a sua

experiência tornaria a reputação o fator mais forte, ao invés 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 intrínsecos (Tabela 4), também chamados de motivadores internos,

que estão relacionados com as necessidades que satisfazem o indivíduo; (ii) Motivacionais extrínsecos (Tabela 5), que são os fatores ambientais interpostos pela

organização a um indivíduo; (iii) fatores motivacionais extrínsecos internos (Tabela

6), que são definidos como auto-reguladores de comportamento, diferenciando dos

fatores extrínsecos porque estes são imposições externas (VON KROGH et al,

2008).

Na revisão de literatura foram adotados métodos de análise crítica, qualitativa

e sintética, com quatro passos principais na identificação 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 “motivação”. O

segundo passo foi revisar a lista de referências dos artigos encontrados para

procurar novas fontes que não foram listados na primeira etapa ou artigos excluídos

por conta dos critérios utilizados. No terceiro passo, os pesquisadores navegaram

por repositórios de artigos on-line (por exemplo, www.opensource.mit.edu) para

identificar artigos que correspondem aos critérios de pesquisa. Em quarto lugar, com

artigos de conferências e capítulos de livros que eram conhecidos pelos

pesquisadores e colegas de trabalho que ainda não tinham constado nas pesquisas.

Trabalhos teóricos e conceituais foram examinados buscando-se fatores

motivacionais usados para criar a teoria. Fatores motivacionais que se mostraram

relevante em trabalhos empíricos também foram incluídos na revisão. A inclusão de

trabalhos empíricos é compreensiva, considerando que a inclusão das contribuições

puramente teóricas é mais seletiva (Von KROGH et al, 2008). Se um estudo utilizou

uma terminologia diferente, mas a motivação parecia suficientemente com uma já

existente na taxonomia, esta foi incorporada a taxonomia existente.

29

Tabela 4 - Fatores Motivacionais intrínsecos

Motivação Conceito Trabalhos Relacionados Ideologia 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 código aberto deve substituir o software proprietário”.

HEMETSBERGER (2004); GHOSH, (2005); DAVID et al. (2003); LAKHANI e WOLF (2005); HERTEL et al. (2003); GOSAIN (2006);

Altruísmo É a preocupação pelo bem-estar do próximo. OSTERLOH e ROTA (2007); LINDENBERG (2001); HEMETSBERGER (2004); HARS e OU (2002); GHOSH (2005);

Prazer e diversão Prazer e diversão são impulsionadores da “cultura hacker” que emergiu na década de 1980.

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);

Amigos de Sangue (Kinship Amity)

É um tipo de organização social, onde cada família (casta) tende a fazer tudo pelo sucesso da própria família, ou dos seus próprios membros.

ZEITLYN (2003); HEMETSBERGER (2004); HARS e OU (2002); LAKHANI e WOLF (2005);

Adaptado de Von KROGH et al (2008)

Tabela 5 - Fatores Motivacionais extrínsecos internos

Motivação Conceito Trabalhos Relacionados Reputação A reputação pode ser classificada como:

reputação interna, quando é direcionada aos membros da comunidade ou potenciais empregadores, e externa vem de fora da comunidade e de outras pessoas significantes, como amigos.

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);

30 Motivação Conceito Trabalhos Relacionados Reciprocidade / Economia da doação

Para o desenvolvimento Open Source a economia da doação faz com que os desenvolvedores distribuam seu código esperando que haja reciprocidade.

BERGQUIST e LJUNGBERG (2001); HEMETSBERGER (2004); LAKHANI e WOLF (2005); DAVID et al (2003); LAKHANI e VON HIPPEL (2003);

Aprendizado É a motivação de aprender novas habilidades ou a oportunidade de experiência de desenvolver software e tê-lo testado e comentado por outras pessoas após o lançamento.

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);

Valor de uso próprio

É a motivação de criar software para uso próprio, ou seja, resolver algum problema que os aplicativos atuais não conseguem resolver de maneira satisfatória.

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);


Tabela 6 - Fatores Motivacionais extrínsecos

Motivação Conceito Trabalhos Relacionados Carreira Os desenvolvedores são motivados por

preocupações na carreira. Publicar um software livre pode mostrar seu talento para potenciais empregadores, aumentado, assim, seu valor no mercado de trabalho.

LAKHANI e WOLF (2005); HEMETSBERGER (2004); WU et al (2007) ; HARS e OU (2002); ROBERTS et al (2006); GHOSH (2005);

Pagamento Uma minoria significativa (aproximadamente 40%) dos colaboradores são pagos para participar de projetos Open Source. O conceito é semelhante ao de uma empresa de software proprietário em que o desenvolvedor ganha por produção.

LAKHANI e WOLF (2005); HARS e OU (2002); HERTEL et al. (2003); LUTHIGER e JUNGWIRTH (2007); DAHLANDER AND WALLIN (2006);


31

2.3 Discussão O trabalho de Von Krogh et al (2008) foi de suma importância para a

pesquisa realizada, pois forneceu análise bastante abrangente e permitiu a

identificação de uma taxonomia dominante na literatura, utilizada para agrupar os

fatores de motivação identificados depois que a codificação ficou pronta. Em sua

pesquisa, foram encontrados 10 fatores ao todo, sendo dois fatores motivacionais

extrísicos (Carreira e Pagamento), quatro fatores motivacionais intrísicos (Altruismo,

Ideologia, Prazer, e Amigos de sangue) e quatro fatores motivacionais extrínsecos

internos (Reputação, Reciprocidade, Valor de uso próprio e aprendizado).

Os trabalhos de Wu et al (2008) e Oreg e Nov (2007) fornecem proposições

que ajudam a entender melhor algumas questões inerentes ao desenvolvimento de

software Open Source.

Baseado no referencial teórico desenvolvido neste capítulo foi possível

realizar a pesquisa e escolher uma metodologia a ser utilizada para se obter

sucesso na realização da mesma.

32 3 MÉTODOS

Neste capítulo é exposta a metodologia adotada para a realização deste

trabalho. Segundo Pinheiro (2010, p.20), o método científico “É o conjunto de

processos ou operações mentais que se deve empregar na investigação científica”.

3.1 Natureza da Pesquisa

3.1.1 Quanto aos Fins

Esta pesquisa pode ser classificada como descritiva e exploratória. Ela é

descritiva, pois visa descrever características de um fenômeno e exploratória porque

visa conhecer inicialmente o tema de estudo.

Segundo Pinheiro (2010, p.21), a pesquisa exploratória “visa proporcionar

maior familiaridade com o problema com vistas a torná-lo explícito ou a construir

hipóteses”. Ainda segundo este autor, a pesquisa descritiva visa “descrever as

características de determinada população ou fenômeno ou o estabelecimento de

relações entre variáveis.”

Este trabalho tem como principal característica descobrir como os principais

fatores motivacionais que afetam os engenheiros de software no contexto de

desenvolvimento de software Open Source agem na comunidade Android-Brasil-

Projetos.

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; além disso, não busca enumerar ou medir eventos e, geralmente, não emprega instrumental estatístico para análise dos dados; seu foco de interesse é amplo e parte de uma perspectiva diferenciada da adotada pelos métodos quantitativos.

Desta forma, esta pesquisa busca investigar os fatores que motivam os

engenheiros de software na realização do seu trabalho a partir dos relatos das

entrevistas.

Além disso, a pesquisa utilizará como abordagem o método indutivo, que,

segundo Marconi e Lakatos (2004, p.53), a partir de dados específicos e

33 suficientemente constatados, infere-se uma verdade geral. Marconi e Lakatos (2004

p.54) consideram três etapas para essa abordagem:

• Observação dos fenômenos: Observar e analisar os fenômenos, a

fim de descobrir as causas da sua manifestação;

• Descoberta da relação entre eles: comparar buscando identificar

similaridades ou diferenças entre os fatos ou fenômenos, com o

objetivo de descobrir relacionamento entre eles;

• Generalização da relação: generalizar os relacionamentos

encontrados na etapa anterior, entre os fatos e fenômenos

semelhantes.

A partir de dados coletados de um grupo de participantes deseja-se chegar a

uma teoria fundamentada, baseada em interpretações e abstrações, objetivando

identificar os principais fatores motivacionais que afetam os engenheiros de software

no contexto de desenvolvimento de software Open Source na comunidade Android-

Brasil-Projetos. Todavia, neste trabalho não será realizada a generalização da

relação.

3.1.3 Quanto aos métodos de procedimentos

Conforme Marconi e Lakatos (2004), os métodos de procedimentos são

etapas mais concretas de uma pesquisa, com uma finalidade mais restrita de

explicação geral dos fenômenos. Para esse trabalho o procedimento adotado foi o

estudo de caso. Yin (2005, tradução nossa p. 32) descreve que: “um estudo de caso investiga um fenômeno contemporâneo dentro do seu

contexto da vida real, especialmente quando os limites entre o fenômeno e o

contexto não estão claramente definidos”.

Segundo Runeson e Host (2008), na Engenharia de Software um caso pode

ser: um projeto de desenvolvimento de software, uma tecnologia, indivíduo, grupo de

pessoas, um processo, entre outros. Já uma unidade de análise pode ser constituída

por um projeto, indivíduo, grupo, entre outros.

De acordo com Yin (2005), este trabalho é um estudo de caso holístico de

caso único. Holístico porque a unidade de análise é o engenheiro de software, pois o

objetivo da pesquisa é estudar os fenômenos e aspectos que influenciam a

34 motivação dos indivíduos 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 organização como caso representativo, que se deseja investigar os

acontecimentos que motivam ou desmotivam os engenheiros de software na

realização das suas atividades.

3.2 Premissas

Este estudo tem como premissa a existência de fatores que influenciam na

motivação, em projetos Open Source, dos engenheiros de software relacionados à

área de Engenharia de Software, às atividades técnicas, ao trabalho em equipe,

além de aspectos organizacionais que influenciam os indivíduos. Também se

acredita que existam indicativos ou sinais percebidos pelos indivíduos quando da

ocorrência da motivação e que suas ações e comportamento influenciam o resultado

do seu trabalho, assim como, se considera que as ações organizacionais, para

motivar os indivíduos, podem ser influenciadas pelo conceito que a organização

apresenta sobre o tema.

3.3 Etapas de pesquisa

As etapas de pesquisa utilizadas foram baseadas no trabalho de França et al

(2011). Foram feitas alterações no protocolo base para adequá-lo ao contexto de

Open Source. De inicio, foi realizada uma revisão bibliográfica para adquirir um

conhecimento maior sobre motivação e desenvolvimento de software Open Source.

Com isso, foram encontrados trabalhos que abordavam os seguintes temas:

conceitos básicos de motivação e software Open Source, revisões sistemáticas da

literatura envolvendo motivação na Engenharia de Software e motivação no contexto

Open Source. Foram considerados nessa revisão livros, artigos científicos e

dissertações acadêmicas escritos em Português ou Inglês.

Depois desta etapa, foram utilizadas as revisões sistemáticas na literatura

sobre motivação na Engenharia de Software e motivação no desenvolvimento de

software Open Source. A partir destas revisões iniciais, sobre os temas, as questões

35 de pesquisa foram refinadas. Após esta fase foi realizada uma adaptação no roteiro

de entrevista utilizado por França et al (2011), de forma a enquadra-lo ao contexto

Open Source.

Dando sequência a pesquisa, foi realizada a coleta de dados através 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 análise utilizando

os procedimentos da Teoria Fundamentada (Grounded Theory) (STRAUSS;

CORBIN, 2008). Com base nesta metodologia, os dados foram codificados

utilizando codificação aberta, codificação axial e codificação seletiva. Como

resultados destes procedimentos foram derivadas preposições e histórias para

geração de uma teoria fundamentada nos dados (França et al 2011).

3.4 Seleção de sujeitos A seleção de sujeitos foi realizada utilizando o critério de conveniência,

abordando indivíduos através da melhor acessibilidade. Os dados adquiridos são do

tipo primário, ou seja, foram conseguidos diretamente pelo pesquisador através das

técnicas escolhidas (entrevistas) (GIL, 2008).

Foi utilizado a auto-seleção9 de amostragem que é útil quando se quer

permitir que os indivíduos possam escolher se desejam participar da pesquisa

voluntariamente, todavia os indivíduos não são 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

opinião de Runeson e Host (2008 apud Da SILVA et al 2011), são muito importantes

8 Skpe é um software de comunicação de voz e vídeo, para mais informações http://www.skype.com 9 Para mais informações sobre auto-seleção: http://dissertation.laerd.com/articles/self-selection-sampling-an-overview.php

36 como fonte de evidências e, de acordo com Seaman(1999 apud Da SILVA et al,

2011), são comumente empregadas como técnicas 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 execução das suas tarefas, no seu trabalho em

equipe, além da percepção dos mesmos sobre características organizacionais que

influenciavam na sua motivação e desmotivação para o trabalho.

Pinheiro (2010 p. 35) define que a entrevista serve para se obter informações

do entrevistado sobre determinado assunto e podem ser divididas como

estruturadas, ou não estruturadas. Queiroz (1988 apud DUARTE, 2002) afirma que

existe mais um tipo de entrevista além dos apresentados por Pinheiro (2010 p.35): a

entrevista semiestruturada, que é uma técnica de coleta de dados que supõe uma

conversação 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 não existe rigidez no roteiro e algumas questões podem

ser mais exploradas, bem como, durante entrevista, pode-se decidir por se seguir

uma ordem diferente do roteiro, ou seja, não necessariamente todas as questões

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 questões de pesquisa, o roteiro original e os roteiros

adaptados podem se observados nos Apêndices B e C.

Para isso, o roteiro foi desenvolvido de maneira que cada questão do roteiro

de entrevista fosse classificada segundo um conjunto de seis tipos de questões

conforme, Merriam (2009 apud Da SILVA et al, 2011), de forma semelhante ao

trabalho desenvolvido por Da Silva et al (2011).

• Experiência e comportamento: Nesta categoria as questões visam obter

informações de comportamento ou experiência do entrevistado;

37

• Opinião e valor: Nesta categoria a intenção é obter a opinião ou crença

referente a alguma coisa por parte do entrevistado;

• Sentimento: Quando o pesquisador deseja focar na dimensão afetiva

humana do participante, procurando adjetivos como respostas, exemplo:

alegre, medo, intimidado, comprometimento, distraído, entre outros;

• Sensoriais: Tem um foco maior em saber sobre o que o entrevistado ouviu,

escutou, entre outros;

• Conhecimento: Neste tipo de questão o objetivo é obter do participante o seu

conhecimento sobre alguma situação;

• Background: Este tipo de questões serve para obter uma visão geral do

entrevistado como idade, renda e escolaridade.

Da Silva et al (2011) evitou desenvolver alguns tipos de questões, que

também serão evitadas nessa pesquisa:

• Múltiplas questões: Evitar elabora uma série de questões dentro de uma

única pergunta, levando o entrevistado a se perder nas respostas e não

responder uma por uma;

• Questão principal: Evitar perguntar ao entrevistado questões principais da

pesquisa;

• Questões sim ou não: Evitar elaborar questões que podem ser respondidas

simplesmente com um sim ou um não.

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 e-

mail pessoal com antecedência à realização das entrevistas para marcar um melhor

dia e horário. As entrevistas não estruturadas foram agendadas e conduzidas

utilizando o Skype, de forma individual. No momento da entrevista foi feita a

apresentação de detalhes da pesquisa, citando o grupo de pesquisadores

responsáveis, política de confidencialidade, objetivos e resultados esperados. Foi

entregue um termo de confidencialidade (Apêndice A) e a coleta de autorização

38 realizada. O pesquisador solicitava autorização verbal para gravar as entrevistas e,

se permitido, as entrevistas eram gravadas.

3.5 Procedimentos da análise de dados

Este trabalho, assim como o desenvolvido por Da Silva et al (2011), adotou

métodos de análise de dados qualitativos, devido a semelhança de abordagem.

Segundo Runeson e Host (2008 apud Da Silva et al 2011) e Seaman (1999 apud Da

Silva et al 2011), os métodos de uma análise de dados qualitativos podem ser

divididos em duas categorias que podem ser utilizadas em estudos de caso. Da

Silva et al (2011) justifica a utilização desses métodos a fim de fundamentar os

resultados baseados e evidenciados a partir dos dados.

• Geração de teoria: Segundo Da Silva et al (2011), é geralmente utilizada

com o objetivo de extrair um conjunto de declarações e proposições

fundamentadas em dados, a partir de algum trecho de transcrições e

refinadas e modificadas sobre outras passagens relacionadas. Da Silva et al

(2011 p.44) ainda afirma que: “Estes métodos são frequentemente chamados

de “grounded theory” ou teoria fundamentada nos dados, pois as teorias ou

hipóteses geradas são fundamentadas nos dados”.

Neste trabalho foram usados alguns aspectos de grounded theory que serão

mencionados a seguir, todavia pela quantidade de dados, não foram gerados

hipóteses e sim proposições, além disso, essas proposições geram indícios de uma

teoria da motivação 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 sociólogos (Glaser e Strauss) para ser

utilizada na pesquisa qualitativa. A escolha dessa forma de abordagem se dá pela

sua grande aceitação por pesquisadores qualitativos (STRAUSS; CORBIN, 2008).

39

Easterbrook (2008) acredita que na Teoria Fundamentada em Dados a

análise inicial dos dados é desenvolvida sem categorias pré-estabelecidas, pois os

padrões de interesse relacionados ao contexto da pesquisa emergem a partir de

comparações 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 hipóteses

são elaboradas como parte integrante da metodologia e que as hipóteses têm como

objetivo obter entendimento dos fenômenos, no caso desta pesquisa foram geradas

proposições, como abordado anteriormente, e que a abrangência da teoria usada

está circunscrita ao espaço amostral utilizado, a comunidade Open Source Android-

Brasil-Projetos.

Kimura et al (2003) acredita que a abordagem metodológica da Teoria

Fundamentada em Dados proporciona algumas dificuldades práticas, como, a

quantidade de tempo que o pesquisador precisa para proceder à coleta, codificação

e o grande volume de dados a serem analisados, a exposição do pesquisador com

os participantes para criar um "clima" de interação (Sheldon, 1998 apud Kimura et al

2003). Kimura et al (2003) acredita, também, que outro ponto que deve ser

considerado pelo pesquisador é a busca pela eliminação consciente das crenças

preconcebidas a respeito do fenômeno em estudo, a fim de permitir que os dados

apontem a identificação dos conceitos e suas inter-relações, desenvolvendo, dessa

forma, uma teoria descontaminada de preconceitos do pesquisador.

3.5.2 Procedimento de codificação

Os procedimentos de codificação utilizados nesta pesquisa são semelhantes

aos utilizados por Da Silva et al (2011) em sua pesquisa. Da Silva et al (2011)

acredita que o procedimento de codificação tem como entrada a transcrição na

íntegra das gravações de entrevistas e notas de campo obtidas no processo de

coleta de dado.

40

Da Silva et al (2011) ressalta ainda que não é um processo estático e rígido,

pois ele é justamente o contrário, já que o pesquisador evolui a sua análise e

interpretação dos dados de forma criativa oscilando entre os três tipos de

codificação, e na utilização de técnicas e procedimentos analíticos. Os três tipos do

processo de codificação 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 analíticas que são importantes para o

desenvolvimento de uma teoria e muito utilizadas durante as três etapas de

codificação, 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) Formulação de perguntas: As perguntas “quem?”, “quando?”, “por quê?”,

“onde?”, “o que?”, “como?”, “com que resultados?”, são uteis para o pesquisador

quando ele está com dificuldades durante uma análise sem conseguir enxergar

explicações dos fenômenos. Da Silva et al (2011) ainda destaca que o objetivo da

formulação de perguntas não é gerar dados e sim formas e ideias de como olhar

para os dados.

b) Comparações: É uma maneira que estimula o pensamento do pesquisador

no desenvolvimento de propriedades e dimensões de uma categoria. Comparação

incidente por incidente, com o objetivo de identificar propriedades, significa comparar

um incidente a outro buscando similaridades e diferenças entre eles. Segundo Da

Silva et al (2011), durante a análise de dados, esse procedimento é utilizado

quando não se consegue classificar ou nomear um incidente porque ainda não se

tem um entendimento aprofundado. Utilizando um pensamento comparativo e

metáforas o pesquisador pode encontrar situações e propriedades que o ajudem a

desenvolver uma categoria.

41 3.5.2.1 Codificação Aberta

Durante a codificação aberta se dar início ao processo de confrontar os

incidentes aplicáveis 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 possível. Todos os dados são passíveis,

neste momento, de uma codificação. A codificação é o processo em que os dados

são codificados, comparados com outros dados e designados em categorias.

Da Silva et al (2011) afirma que a codificação aberta é uma série de passos

analíticos cuja finalidade é a identificação de categorias com suas propriedades e

dimensões. Segundo este autor, o passo inicial é a rotulação de conceitos, a partir

de porções do texto. Essas porções 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 parágrafo que foi

conceituado a partir da identificação 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) expõem o conceito como um fenômeno rotulado a

partir dos dados, que é a representação 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 identificação de conceitos linha por linha

para início 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

indicação para conceituação linha por linha é para algum trecho do texto que não

está claro. Outra forma é codificar uma frase ou parágrafo inteiro, dessa maneira

deve-se perguntar e tentar identificar “Qual é a principal ideia revelada por essa

sentença ou parágrafo?” (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 são

conceitos mais abstratos derivados dos dados que representam um fenômeno (um

42 problema, uma questão, preocupações 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 dimensões. 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 codificação aberta o resultado dever ser uma lista de códigos e categorias com

suas propriedades e dimensões. Para complementar, o pesquisador pode se utilizar

de memorandos e anotações a fim de explicar e registrar suas observações e

pensamentos sobre cada categoria gerada.

3.5.2.2 Codificação Axial Segundo Da Silva et al (2011), após a codificação aberta, deve ser feita uma

codificação axial, que tem como objetivo relacionar as categorias resultantes da

codificação aberta com às suas subcategorias para que se tenha um maior poder

explanatório sobre os fenômenos. Da Silva et al (2011) afirma que subcategorias

são categorias, porém no lugar de representar um fenômeno, elas têm a capacidade

de responder as seguintes perguntas sobre os fenômenos (“de que forma?”,

“quando?”, “como?”, “por quê?”, “para que?”, “com que consequências?”, entre

outros).

Ao identificar essas subcategorias, começa-se a descobrir relações entre as

categorias de forma a contextualizar melhor o fenômeno estudado (STRAUSS;

CORBIN, 2008; FLICK, 2009 apud Da SILVA et al, 2011).

Strauss e Corbin (2008) apresentaram um mecanismo analítico conceitual em

relação aos dados para organizar a formulação desse relacionamento chamado

paradigma. Segundo Da Silva et al (2011), a ideia desse mecanismo é apoiar o

esclarecimento e a identificação das relações entre um fenômeno, identificando

suas causas, consequências e estratégias de ações envolvidas. Os termos utilizados

no paradigma fornecem uma linguagem familiar e lógica facilitando a discussão. A

43 seguir serão apresentados os termos de acordo Strauss e Corbin (2008) e Flick

(2009 apud Da SILVA et al, 2011):

• Fenômeno: Na codificação, fenômeno é uma categoria que responde a

pergunta “o que está acontecendo aqui?”, são padrões de acontecimentos, fatos ou

ações que as pessoas, ou grupo de pessoas, fazem respondendo a situações ou

problemas nas quais elas estão envolvidas.

• Condições: Agrupamento de conceitos com respostas a questões do tipo:

"como", "por que", "quando", "de que forma". Forma uma estrutura contextual, ou

conjunto de situações ou circunstâncias na qual os fenômenos estão envolvidos.

• Ações/interações: Surgem a partir das condições. São respostas

estratégicas, ou rotineiras das pessoas, grupo de pessoas ou organizações a

problemas, acontecimentos ou fatos.

• Consequências: São os resultados (consequências) das ações/interações.

Sempre que acontece uma ação/interação ou a ausência delas, seja por uma

pessoa, grupo ou organização em relação algum problema, questão ou evento, há

alguma consequência envolvida. Entender essas consequências bem como a forma

como elas alteram o fenômeno possibilita a obtenção de explicações mais completas

sobre o fenômeno

Quando se identificam a relação entre as categorias e a associação com suas

subcategorias, junto com a utilização do mecanismo paradigma, o pesquisador

começa a identificar o que são condições, ações/interações e consequências.

3.5.2.3 Codificação Seletiva

De acordo com Da Silva et al (2011), o último passo do processo de

codificação é a codificação seletiva, que tem como objetivo integrar e refinar as

categorias a fim de descrever uma teoria final. Essa descrição da teoria se dá

através da identificação 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 codificação

seletiva é a identificação da categoria central. A categoria central, ou categoria

básica, representa o tema principal da pesquisa e, assim como as demais

categorias, é uma abstração que emergiu dos dados. Da Silva et al (2011) afirma,

44 ainda, que essa categoria tem um grande poder analítico, pois tem uma capacidade

de reunir e de se relacionar com as outras categorias e, dessa forma, obtém um

poder explanatório ao seu redor. Uma técnica para a descoberta dessa categoria é

redigir, em poucas linhas, uma história descritiva da pesquisa com o foco sobre “O

que parece estar acontecendo ali?”, “Qual a principal questão ou problema com o

qual essas pessoas parecem estar lidando?”. Um retorno aos dados para reler as

entrevistas ajuda nessa identificação (STRAUSS;CORBIN, 2008, p.146-148; FLICK,

2009 apud Da SILVA et al, 2011).

Strauss e Corbin (2008) explicam que após essa identificação da categoria

central o pesquisador escreve novamente uma história, mas, desta vez, utilizando as

demais categorias existentes e os relacionamentos com a categoria central. A partir

dessa história 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 teórico é necessário refinar e validar o

esquema teórico”. 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 Limitações

Os objetivos da pesquisa foram alcançados, todavia existiu dificuldade

principalmente na questão das realizações de entrevistas, já que essa etapa

depende bastante dos membros participantes da comunidade Android-Brasil-

Projetos, que possuem diversas tarefas durante o dia e tem seu tempo limitado. As

entrevistas foram realizada via Skype devido a dispersão dos membros que estão

localizados em várias partes do Brasil, o que também dificultou na realização do

processo. Inicialmente foram obtidos 8 respostas positivas para realização das

entrevistas, contudo, somente 4 pessoas responderam positivamente em relação

ao horário da entrevista e estiveram disponíveis no Skype para participar no

horário marcado. Devido à limitação de tempo, o número de entrevistados se

restringiu a quatro integrantes.

45 3.7 Discussão

Utilizar uma metodologia baseada no trabalho de Da Silva et al (2011) facilitou

no desenvolvimento do trabalho e na obtenção dos resultados propostos, vale

salientar também que a mesma metodologia foi utilizada em outros trabalhos como

o de Carneiro (2011).

Apresentada a metodologia proposta, no próximo capítulo os dados serão

analisados das proposições e da teoria, utilizado com a utilização o roteiro

adaptado (Apêndices B e C).

4. Resultados

Nesse capitulo serão descritos os resultados da codificação Aberta, Axial e

Seletiva que foram obtidos com as entrevistas realizadas na comunidade Android-

Brasil-Projetos. Primeiro será apresentada a descrição do contexto para que

posteriormente sejam apresentados os relatos dos resultados da codificação aberta,

os resultados da codificação axial, com as proposições geradas, e os resultados da

codificação seletiva, com a geração da teoria e, por fim, uma avaliação dos

resultados. As perguntas que foram realizadas nas entrevistas podem ser

observadas no Apêndice B (Mantenedor) e no Apêndice C (Engenheiros de

Software), juntamente com as perguntas originais desenvolvidas por Da Silva et al

(2011).

4.1 Descrição 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 aplicações de código aberto, de forma bem documentada e

seguindo padrões de projetos. Qualquer um, mesmo que não saiba programar,

pode participar propondo projetos e testando os programas.

A lista tem cerca de 530 e-mails cadastrados, contudo não significa dizer que

esse número é de pessoas ativas, pois os usuários podem cadastrar mais de um e-

10 Ferramenta para criação de grupos virtuais do Google.

46 mail, assim como não significa dizer que somente 530 pessoas participaram da

comunidade, pois o membro pode sair do Google Groups quando desejar. No mês

de Maio de 2012 cerca de 30 membros participaram da lista, e alguns deles apenas

com dúvidas de desenvolvimento não 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 irão adiciona-lo no grupo de desenvolvedores do projeto. Basicamente

o novo membro será adicionado ao documento de especificação do projeto, ou seja,

receberá permissão para edita-lo, e no repositório de código fonte.

Os projetos são desenvolvidos utilizando a método ágil SCRUM11. Eles são

quebrados em tarefas menores que ficam disponíveis para que qualquer membro

possa escolher alguma tarefa que goste, essas tarefas ficam esperando alguém que

as faça, caso ninguém queira fazer o líder do projeto, que normalmente é quem tem

a ideia do projeto, pode designar alguém, mas esse não é obrigado a fazer, ou ainda

o próprio líder pode fazer a tarefa.

Como existe distância entre os membros da equipe e cada um pode realizar

suas tarefas no local e horário que achar mais adequado, existe algumas

particularidades inerentes ao desenvolvimento do software na comunidade Android-

Brasil-Projetos, como a comunicação que ocorre via e-mail e Skype. Geralmente as

reuniões via Skype são 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 são utilizados para tirar dúvidas, auxiliar o

processo de ensino e em comunicações corriqueiras. Além disso, é criado um

arquivo no Google Docs12 que armazena as informações do projeto, como:

funcionalidades, contato dos envolvidos, ferramentas utilizadas, e responsáveis

pelas tarefas.

11 Para mais informações http://www.scrum.org/ 12 Para mais informações http://www.google.com/apps/intl/pt-BR/business/docs.html

47

Para auxiliar a manter o código único e evitar o retrabalho, é utilizado um

software de controle de versão que fica responsável por controlar as diferentes

versões do código, permitindo que os membros da equipe trabalhem com o mesmo

conjunto de códigos ao mesmo tempo podendo minimizar os desgastes provocados

por problemas em conflito de edições e pela distância física.

4.2 Resultados da Codificação aberta

Nesta etapa foram geradas quatro categorias e 27 fatores, que afetam os

engenheiros de software na comunidade Android-Brasil-Projetos, nove sinais de

motivação, percebidos pelos participantes e, por fim, quatro definições de motivação,

de acordo com os participantes. Fragmentos de entrevistas foram utilizados como

prova, e descrições claras e não-conflitantes também foram atribuídas a categorias,

a fim de manter as categorias coerentes com outras teorias de motivação

encontradas na literatura. Na Tabela 7 são apresentadas as categorias e seus

fatores.

Tabela 7 – Aspectos motivacionais

Diminuição da Motivação Aumento da Motivação Aspectos da Comunidade

Conflito de opiniões Ajuda mútua Interação baixa Atenção Contribuição social do projeto Reconhecimento interno da comunidade

Reconhecimento externo à comunidade

Ausência de remuneração Participação na definição do produto (dar

opinião como usuário) Aspetos pessoais

Concorrência com atividades externas

Mudança de interesse pessoal

Dificuldade para aprender Gratidão Ideologia Autonomia Flexibilidade de tempo Utilidade do produto para si Larga rede de contatos profissionais

Aspectos do trabalho em equipe

Falta de integração da equipe Divisão do trabalho Qualificação técnica dos integrantes da

equipe

48

Poder Proatividade dos outros

Aspectos da tarefa

Utilidade da tarefa p/ fora da comunidade

Aprendizado Desafio técnico Boa Qualidade da documentação

Fonte: Autor (2012).

4.2.1 Aspectos da Comunidade

Os aspectos da comunidade são aqueles que a comunidade proporciona para

os membros que participam dos projetos desenvolvidos por ela. Essa categoria é a

que contém mais fatores, sejam eles de aumento de motivação (seis, juntamente

com aspectos pessoais) e de diminuição da motivação (quatro). A seguir são

apresentados cada um desses fatores:

a) Conflito de Opiniões (Diminuição da Motivação): Esse fator acontece

quando alguma opinião do membro não é aceita pelos outros membros,

como exemplificado no seguinte trecho de entrevista: “Quando a pessoa está desmotivada é quando acontece alguma coisa que

não 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) Interação Baixa (Diminuição de Motivação): É quando existe falta de

comprometimento com os membros da comunidade, como exemplificado no

seguinte trecho de entrevista: “[...]as vezes tinha incompatibilidade de horário e as vezes você acaba

perdendo a interação com os outros membros” (Engenheiro de Software).

c) Ausência de remuneração (Diminuição de Motivação): Esse fator

acontece devido à comunidade não ter nenhuma remuneração financeira

para os membros, como pode ser exemplificado no seguinte trecho de

entrevista: “[...]como não tem nenhuma remuneração, não tem nada que te obrigue a

participar do projeto, você está ali porque você quer, as pessoas começam

saindo[...]” (Engenheiro de Software).

49

d) Ajuda mútua (Aumento da Motivação): Também pode ser definido como

reciprocidade, é quando os membros se ajudam, como exemplificado no

seguinte trecho de entrevista: “[...]essa relação que existe entre as pessoas, uma ajudando a outra, isso daí

para mim foi fundamental.” (Engenheiro de Software).

e) Atenção (Aumento da Motivação): Esse fator ocorre quando um membro

dá atenção para o outro, como exemplificado no seguinte trecho de

entrevista: “É uma coisa que já vi em vários lugares, não só em comunidade Open

Source, é que você dá atenção para ela.” (Engenheiro de Software).

f) Contribuição social (Aumento da Motivação): É quando a comunidade

propõe contribuir para a sociedade, como exemplificado no seguinte trecho

de entrevista: “[...]geralmente é um projeto que não tem fins lucrativos, mas tem uma

contribuição social[...]” (Engenheiro de Software).

g) Reconhecimento interno da comunidade (Aumento da Motivação): É

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 Motivação): É

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, então, poxa, vamos ser reconhecidos mesmo! O

negocio tá bombando! Vamos ficar famoso, por assim dizer.” (Engenheiro de

Software).

i) Participação na definição do produto (Aumento da Motivação): A

comunidade oferece ao Engenheiro de Software a oportunidade de

expressar sua opinião no desenvolvimento daquele software, como

exemplificado no seguinte trecho de entrevista:

50

“Era exatamente poder colocar minha opinião como usuário e não somente

como desenvolvedor, porque quando você está em um projeto as vezes você

dá opinião, mas é como desenvolvedor e as vezes não é exatamente o que o

usuário quer ou precisa. E naquele projeto não, você tinha oportunidade de

escrever e dizer o que você queria.” (Engenheiro de Software).

4.2.2 Aspectos Pessoais

Os Aspectos Pessoais são aqueles que são inerentes aos engenheiros de

software. Os fatores contidos nessa categoria estão 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. São os fatores

de Aspectos pessoais:

a) Concorrência com atividades externas (Diminuição da Motivação): Esse

fator ocorre quando existem atividades externas concorrendo com a

participação do membro na comunidade, sejam elas do trabalho ou

faculdade, ou também ficar com a família no final de semana e ir à praia,

como observado no seguinte trecho de entrevista: “[...]as vezes é um estudante que está em férias, janeiro e dezembro, chega

fevereiro tem aula tem, prova, não dá para continuar, as vezes é um cara que

tem família, não dá para ficar reunindo, fazer reunião ou ficar gastando um

tempo durante a semana[...]”(Engenheiro de Software).

b) Mudança de interesse pessoal (Diminuição da Motivação): Esse fator ocorre

quando existe mudança nos interesses das pessoas ou organizações, 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 (Diminuição da Motivação): 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ê não sabe isso aqui , ai você tem que correr

51

atrás, parar o que você está fazendo e começar a aprender de novo, então

isso é chato, fica chato” (Engenheiro de Software).

d) Gratidão (Aumento da Motivação): Esse fator ocorre quando existe um

sentimento de gratidão por uma ação de algum membro, como observado no

trecho a seguir: “A gratidão, a pessoa ver que você se esforçou para ajuda-la e ela vai querer

fazer a parte dela também, 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 código aqui e pelo Skype, pela

minha área de trabalho compartilhada, ele começou 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 Motivação): É 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 Motivação): 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, então a gente

escolhia por isso.” (Engenheiro de Software).

g) Flexibilidade do Tempo (Aumento da Motivação): 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

questão é isso, você vai fazer na hora que você quer[...]” (Engenheiro de

Software).

h) Utilidade do produto para si (Aumento da Motivação): 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

52

ele iria utilizar, então tipo com certeza é um incentivador [...]”(Engenheiro de

Software).

i) Larga rede de contatos profissionais (Aumento da Motivação): 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 também é 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 integração da equipe (Diminuição da Motivação): Esse fator ocorre

principalmente porque os projetos são desenvolvidos de forma distribuída,

muitas vezes as pessoas envolvidas na comunidade não se conhecem.

Trecho do fator: “Marcar uma cerveja, fazer outras atividades, fazer atividades que não estão

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 questão de você ficar só na Internet, no e-mail no computador é

um pouco impessoal.” (Engenheiro de Software).

b) Divisão do trabalho (Aumento da Motivação): 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) Qualificação técnica dos integrantes da equipe (Aumento da Motivação): A

qualificação técnica dos membros envolvidos nos projetos influencia no

aumento da motivação 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 Motivação): A possibilidade de mandar nas outras

pessoas também foi um dos fatores mencionados pelos membros, como no

53

trecho a seguir, quando o entrevista é perguntado se tinha alguma função

que gostaria de fazer: “Bem, Gerente, ai eu ia mandar em todo mundo lá, mas não 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) Pró-atividade dos outros (Aumento da Motivação): Fazer ou observar

alguma ação que era de outro membro, buscando a pró-atividade, como no

trecho a seguir: “[...]ver que tem alguma coisa errada que você não tinha percebido, as

vezes é seu código, você desenvolveu aquele código e o cara vai lá e “ou, eu

vi isso aqui, já comitei13 uma correção." Oh que legal, você estudou o código

que outra pessoa desenvolveu e foi lá e já comitou uma

correção[...]”(Engenheiro de Software).

4.2.3 Aspectos da Tarefa

Os Aspectos da tarefa são questões 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 Motivação):

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 atrás

ele tinha uma fama de ser muito feio e agora tá melhorando bastante isso,

então é uma coisa que eu gosto de trabalhar e me estimula bastante.”


b) Aprendizado (Aumento da Motivação): O que essa tarefa pode trazer de

conhecimento para o membro, o que ele pode aprender fazendo determinada

tarefa. “claro que tem a questão que a pessoa tá aprendendo, muitas pessoas usam

isso: ah estou aprendendo, estou começando a desenvolver para Android e

vamos fazer um projeto?” (Engenheiro de Software).

13 Enviar uma atualização de código para o controle de versão.

54

c) Desafio técnico (Aumento da Motivação): Os desafios no desenvolvimento

da tarefa também 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 documentação (Aumento da Motivação): A qualidade da

documentação também influi na motivação 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 documentação [...]o projeto do KDE, é um projeto

grande por isso tem muita documentação e é bem

estruturado[...]”(Engenheiro de Software).

4.2.4 Sinais de motivação

Durante a codificação aberta foram identificados nove sinais de motivação,

sendo que cinco negativos e três positivos, que foram divididos em Aspectos da

comunidade, Aspectos pessoais e Aspectos da tarefa, conforme a Tabela 8.

Os sinais de desmotivação são:

(i) Nível de Comprometimento (Aspectos da Comunidade): A falta de comprometimento dos membros em relação à realização das

tarefas, na comunidade e no projeto foi comentada pelos quatros entrevistados

como um sinal de desmotivação, como pode ser observado a seguir: “Ele não participa de nada, é um cara que tá nem ai” (Engenheiro de

Software) e “[...]uma pessoa que não tá motivada não vai participar desse tipo

de ... não vai se envolver muito[...]” (Engenheiro de Software)

Tabela 8 - Sinais de motivação

Sinais de Desmotivação Sinais de motivação Aspectos da Comunidade

Nível de Comprometimento

Participação

Nível de comunicação Falta de interesse em ajudar

Aspetos pessoais Pessimismo

55 Aspectos da tarefa Demora em realizar

tarefas

Código de qualidade Maior produção

Fonte: Autor (2012).

(ii) Nível de comunicação (Aspectos da Comunidade): O nível de comunicação entre os membros é importante, quando existe pouca

comunicação entre os membros do projeto, pode causar uma falta de animação

para a equipe, como pode ser observado no trecho a seguir: “[...]você não tem um feedback dele em relação às ideias do projeto, ao desenvolvimento do projeto ao problemas que aparecem no projeto, ele não dá um feedback, não acompanha, falta comunicação dele, então isso para mim é um ponto de verificação 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 não está motivado, como foi

comentado por um participante: “[...]eu vejo pessoas que assim, tão na comunidade e não querem militar, não querem ajudar sabe?” (Engenheiro de Software)

(iv) Pessimismo (Aspectos Pessoais): Se o membro estiver com atitudes pessimista, os outros membros podem

acreditar que ele não 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 não...tão 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): Quando é passada uma tarefa para um membro e este demora na realização

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 não 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 não

procurei mais, a pessoa não procurou mais para conversar e consideramos

que a pessoa tinha desistido do projeto[...]”(Engenheiro de Software)

Já os sinais de motivação percebidos são:

56

(i) Participação (Aspectos da Comunidade): A participação do membro é observada como sinal de motivação por outros

membros, caso o membro participe muito os outros membros acreditam que ele está

motivado. Ela foi citada por três membros, como pode ser visto a seguir: “Participação em tudo, quando você vai fazer uma escrita de historia, debate

essas aparição alguma coisa, vamos usar isso aqui, às vezes o cara fica por

fora e não acompanha. Já é um sinal que ele não está estimulado a participar

do projeto.” (Engenheiro de Software)

“Quando o cara manda três e-mail por dia falando em alguma coisa do

projeto, todo animado, dando um gás, vendo que ele correu atrás, tá em

reunião e o cara aparece[...]” (Engenheiro de Software)

(ii) Qualidade de código (Aspectos da Tarefa): Quando um membro produz software com uma boa qualidade do código, os

outros membros acham que é um sinal de que ele está motivado, conforme o trecho

a seguir: “Uai! Uma pessoa dedicada produz um código 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 Produção (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 citação a seguir: “A pessoa motivada é uma pessoa produtiva, é uma pessoa que produz.” (Engenheiro de Software)

4.3 Resultados da codificação axial

Proposição 1: A boa qualidade da documentação e a qualificação técnica 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 começar, como se

inteirar, um kit iniciante para começar a desenvolver e rodar no projeto,

57

projetos menores é um pouco mais complicado porque não tem uma wiki

explicando direitinho como que faz[...]”(Engenheiro de Software)

Proposição 2: Ajudar os outros e a contribuição 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 contribuição social do projeto, pois são formas

de contribuir com o próximo (HERTEL et al, 2003). “contribuição social do projeto, porque geralmente é um projeto que não tem fins lucrativos, mas tem uma contribuição social, as vezes essa contribuição não fica visível a todos”(Engenheiro de Software)

“[...]essa relação que existe entre as pessoas, uma ajudando a outra, isso daí

para mim foi fundamental.” (Engenheiro de Software).

Proposição 3: O reconhecimento externo e interno, a rede de contatos e o Aprendizado afetam positivamente a Autopromoção, 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

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 também é 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, então, poxa, vamos ser reconhecidos mesmo! O

58

negocio tá bombando! Vamos ficar famoso, por assim dizer.” (Engenheiro de

Software).

Proposição 4: A ausência de remuneração e a concorrência com atividades externas afetam negativamente o comprometimento dos membros.

Por influência da ausência de remuneração e por causa da concorrência 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 serviço” as vezes o pessoal fala que vai fazer e não

faz[...]”(Engenheiro de Software)

“[...]como não tem nenhuma remuneração, não tem nada que te obrigue a

participar do projeto, você está ali porque você quer, as pessoas começam

saindo[...]”(Engenheiro de Software)

Proposição 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 usuário

daquele projeto ali e quer ver aquele projeto ir para frente.” (Engenheiro de

Software)

Proposição 6: A integração 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 laço 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, então eu

acho que um meio de se passar conhecimento adiante para outras

pessoas[...]”(Engenheiro de Software)

59 Proposição 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

não consigo melhorar isso aqui, ou desenvolver uma caraterística que eu

estou interessado ?[...]” (Engenheiro de Software)

Proposição 8: O comprometimento afeta positivamente a comunicação. Quando o usuário está mais comprometido a comunicação é feita de maneira

melhor. O trecho a seguir exemplifica a preposição: “[...] Ele não participa de nada, é um cara que não tá nem ai, fechado você

não tem um feedback dele em relação as ideias do projeto, ao

desenvolvimento do projeto ao problemas que aparecem no projeto, ele não

dá um feedback, não acompanha, falta comunicação dele[...]”(Engenheiro de

Software). Proposição 9: O comprometimento afeta positivamente a contribuição.

Quando as pessoas estão mais comprometidas, elas contribuem mais,

conforme o trecho as seguir: “Quando o cara manda três e-mail por dia falando em alguma coisa do

projeto, todo animado, dando um gás, vendo que ele correu atrás, tá em

reunião e o cara aparece “Nossa que legal” o cara tá interessado, o cara dá

ideia no projeto, corrige o código, ver que tem alguma coisa errada que você

não tinha percebido, as vezes é seu código, você desenvolveu aquele código

e o cara vai lá e “ou eu vi isso aqui, já comitei uma correção[...]”(Engenheiro

de Software).

Proposição 10: A ideologia afeta positivamente o comprometimento. Raymond (1999) acredita que a ideologia da pessoa faz com que ela seja

comprometida para desenvolver de código fonte aberto.

Proposição 11: O comprometimento com as pessoas afeta o reconhecimento interno. Quando o membro não está integrado com a equipe e não existe

reciprocidade o reconhecimento dele é afetado negativamente, por exemplo, no

trecho a seguir quando foi perguntado de que forma a falta integração e a

reciprocidade afetariam o trabalho do membro:

60

“Acho que não no trabalho dele em si, mas em relação à imagem dele em si

na comunidade, ele fica com imagem de irresponsável, de desleixado.”


4.4 Resultados da codificação seletiva

Para gerar a teoria, foi desenvolvido um levantamento das categorias que

eram mais relevantes entre os fatores motivadores e os fatores desmotivadores na

codificação aberta. O resultado desse levantamento permitiu identificar as principais

categorias que foram citadas dentre as 27 categorias criadas na codificação aberta.

Depois disso, foi desenvolvido um trabalho de leitura das citações para que

fossem identificados os relacionamentos entre estas categorias, fazendo com que

fosse possível 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 importância destacada

nos relatos feitos durante as entrevistas, observando também os relacionamentos

com as outras categorias citadas.

As proposições 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 ausência de remuneração faz com que o comprometimento seja afetado

negativamente, juntamente com a concorrência com atividades externas. Isso é

justificável, pois o membro precisa de remuneração financeira para realizar ações do

dia-a-dia, como: pagamento das contas de energia, luz, água e Internet. Essa

necessidade leva a obrigação do membro de ter outra fonte de renda, que

normalmente concorre com a contribuição em projetos deste tipo. Além disso, alguns

membros tem a concorrência com atividades de lazer, como ir à praia ou ficar com a

família.

O aprendizado é influenciado pela boa qualidade da documentação, pois

devido às informações estarem mais bem explicadas e disponíveis 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 soluções para problemas.

61

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 também 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.

Figura 3 - Geração da teoria da comunidade

Fonte: Autor (2012)

62 4.5 Avaliações dos Resultados

Foram realizadas quatro entrevistas que resultaram cerca de 3 horas de áudio e

30 páginas de conversas transcritas. Pode-se destacar que foram encontradas 27

categorias de fatores motivacionais, as quais foram descritas e classificadas entre

questões relativas a aspectos pessoais, da comunidade, da tarefa e do trabalho em

equipe.

Além disso, também foram geradas nove proposições e uma teoria

relacionando às principais categorias encontradas durante a análise 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 organizações Open Source.

Todos os quatro fatores apontados por Wu et al (2005), Comportamento de

ajuda, Aprimoramento do capital humano, Progressão na carreira e Satisfação de

necessidade pessoais, foram encontrado nesta pesquisa e são observados como

fatores que levam as pessoas a contribuir na comunidade, assim como os fatores

propostos por Oreg e Nov (2007), Reputação, Desenvolvimento próprio e Altruísmo.

O conjunto dos fatores citados por Wu et al (2005) e Oreg e Nov (2007) aparecem

também como os mais relevantes na comunidade Android-Brasil-Projetos.

Dos 10 fatores encontrados por Von Krogh et al (2008) apenas prazer/

diversão e amigos de sangue(Kinship amity) não foram citados. O fator reputação foi

classificado separadamente como interno e externo. Alguns fatores como divisão do

trabalho, boa qualidade da documentação, desafio técnico, utilidade da tarefa para

fora da comunidade, poder, concorrência com atividades externas, flexibilidade do

tempo, e participação na definição do produto não aparecem na pesquisa realizada

por Von Krogh et al (2008) e foram encontrados em na pesquisa e são importantes

para entender melhor a motivação dos membros.

Pode-se Salientar também que além da pesquisa dividir em fatores

motivacionais e desmotivacionais para melhor entende-los, também foram

encontrados os sinais de motivação e desmotivação na comunidade, tornando ainda

mais rica a contribuição, pois com eles é possível perceber o comportamento do

63 membro e evitar que ele abandone o projeto ou notar se o membro está satisfeito

com o projeto.

Uma observação que deve ser levada em consideração, é que a teoria foi

gerada com uma baixa quantidade de entrevistas, o que leva a pouca quantidade de

dados analisados, além disso, como foi estudado apenas a comunidade Android-

Brasil-Projetos, a teoria gerada é especifica para o contexto e comunidade

estudados.

A teoria estudada, aborda alguns fatores que não foram observados

anteriormente, mas em geral encontra resultados semelhantes aos encontrados com

os de Von Krogh et al (2008), a principal diferença entre a teoria gerada e as

hipóteses encontradas com Wu et al (2005) é o indício que o interesse pessoal é um

dos fatores preponderantes que levam aos membros contribuírem em um contexto

Open Source, assim como a ideologia foi citada de maneira tímida pelos membros

nesta pequisa, diferentemente da pesquisa realizada por Wu et al (2005), isso se

deve em parte a utilização do Skype e a realização de entrevistas para obtenção dos

dados.

Esses novos indícios de fatores devem ser melhores pesquisados e

ampliados, de preferencia utilizando os mesmos métodos, para observar como

esses fatores atuam em outras comunidades, assim como ampliar a pesquisa na

comunidade utilizada.

64

5. Conclusão

Com o aumento da utilização 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 também é importante

entender o que leva os membros a contribuir e não abandonar o projeto, assim como

perceber com antecedência se o membro está desmotivado.

Devido à necessidade por mais estudos sobre o tema “motivação no contexto

Open Source”, principalmente utilizando a pesquisa qualitativa, este trabalho traz

contribuições 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 contribuição dos membros no

projeto.

Para atingir tal fim, foram encontrados na revisão de literatura diversos fatores

motivacionais que auxiliaram no desenvolvimento da pesquisa, também foram

realizadas entrevistas para identificar se os fatores encontrados na revisão

influenciavam na comunidade e encontrar novos fatores que ainda não tinham sido

observados nos trabalhos relacionados.

O objetivo deste trabalho era responder a questão 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 adaptação do protocolo utilizado em outras

pesquisas realizadas permitiram ao pesquisador obter resultados claros. Também

deve se destacar que o método de pesquisa utilizado, a pesquisa qualitativa, exigiu

dedicação do pesquisador na etapa de coleta dos dados e posteriormente a análise

dos dados para se chegar aos resultados desejados com sucesso.

Baseado nos dados coletados através do método de pesquisa e da análise

feita no Capítulo 4 pode-se concluir que este trabalho realizado alcançou os

objetivos proposto, além disso, o trabalho contribui para as pesquisas na área de

65 motivação, mais especificamente no setor de engenharia de software, além de

contribuir para a área de desenvolvimento de software Open Source.

Como contribuições desta pesquisa foram evidenciados, para futuros estudos,

27 fatores motivacionais, 8 sinais externos de motivação e 11 proposições que

geraram uma teoria da motivação no contexto Open Source dentro da comunidade

Android-Brasil-Projetos.

Os resultados aqui encontrados podem servir para empresas que mantêm

software Open Source a entenderem quais são os fatores motivacionais que levam

os participantes a contribuir, como melhorar a contribuição dos membros e evitar

que eles abandonem o projeto, e também 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 ausência de remuneração e a

concorrência com atividades externas, para evitar que esses membros saiam da

comunidade pode-se tentar maximizar a questão do aprendizado e da reputação

obtida pelos membros, o aprendizado pode ser melhorado com a documentação e a

qualificação dos membros que pertencem a comunidade, que pode ser realizada

com a manutenção de membros mais experientes na comunidade, e a reputação

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 através 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, além disso, a pesquisa também poderia ser desenvolvida em

outra comunidade para tentar conseguir diferentes fatores baseados nas

características de outra comunidade, podendo até comparar os resultados obtidos

nas diferentes comunidades e tentar encontrar indícios dos fatores motivacionais no

contexto Open Source.

66

Além disso, pode-se tentar classificar os fatores encontrados nesta pesquisa

de acordo com o trabalho de Von Krogh et al (2008) em motivacionais intrínsecos,

motivacionais extrínsecos e fatores motivacionais extrínsecos 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 motivação dos desenvolvedores de softwares que abrangeria

diversos contextos, dentre eles os de softwares Open Source.

67

REFERÊNCIAS

BERGAMINI, Cecilia Witaker A difícil Administração das motivações. Revista

Brasileira de Administração de Empresas, São 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), 1243–1258, 2003.

CARNEIRO, David Emanuel Souza. Motivação em integrantes de equipes de desenvolvimento de software no contexto de uma empresa privada: um estudo de caso Dissertação, Universidade Federal de Pernambuco. CIN. Ciência da

Computação, 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 Ribeirão Preto Dec. 1996

Da SILVA, Fabio Queda Bueno; FRANÇA, Alberto César Cavalcanti; FELIX, Adelnei

de L.C.; ARAUJO, Ana Catarina M.L.; CARNEIRO, Carneiro E.S.; SALLES, Eric;

GOUVÊIA, Tatiana B.; Protocolo para Estudos de Caso sobre Motivação de Engenheiro de Software. Technical Report. In:HASE, 2011.

DA SILVA, Fabio Q. B.;FRANÇA, A. CÉSAR C. Towards Understanding the Underlying Structure of Motivational Factors for Software Engineers to Guide the Definition of Motivational Programs.Journal Article. In:JSS, 2011.

68 DUARTE, Rosalia: “Pesquisa qualitativa: reflexões sobre o trabalho de campo”

Departamento de Educação da Pontifícia Universidade Católica do Rio de Janeiro

Cadernos de Pesquisa, n. 115, p. 139-154, março 2002

DRIVER, Mark; WEISS George., Predicts 2006: the effects of open-source software on the IT software industry, Gartner Research 28, 2005.

FRANÇA, Alberto César Cavalcanti. Um estudo sobre motivação em integrantes de equipes de desenvolvimento de software. 1. ed. Recife: Editora Universitária

UFPE, 2009.

FRANÇA, A. César C.;GOUVEIA, Tatiana B. ; SANTOS, Pedro C. F. ; SANTANA,

Celio A. ; DA SILVA, Fabio Q. B. Motivation in Software Engineering - A Systematic Review Update. 15th International Conference on Evaluation and

Assessment in Software Engineering EASE. [S.l.]: [s.n.]. 2011.

FRANÇA, Alberto César Cavalcanti; Da Silva, Fabio Queda Bueno; Developing Motivational Programs for Software Engineers through an Experimental Method. In XXIII Simpósio Brasileiro de Engenharia de Software, 135- 154. 2009

FERREIRA, Alexandre João Petetim Leal; OPEN SOURCE SOFTWARE. COMUNICAÇÃO & PROFISSÃO Departamento de Engenharia Informática,

Universidade de Coimbra, 2005

FERREIRA, Aurélio Buarque de Holanda. Dicionário Aurélio Básico da Língua Portuguesa. Rio de Janeiro: Nova Fronteira, 2008.

GNU. What is Free Software? ; Disponível em http://www.gnu.org/ acessado em

16/03/2012 , 1996.

GIL, Antonio Carlos. Métodos e Técnicas de Pesquisa Social. São Paulo; Atlas

S.A, 2008.

GOUVEIA, Valdiney V., MARTÍNEZ, Eva. MEIRA, Maja. e MILFONT, Taciano M. “A estrutura e o conteúdo universais dos valores humanos: análise fatorial confirmatória da tipologia de Schwartz” Estudos de Psicoogia,6(2) 133-142, 2001.

69 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” disponível 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 effort 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 Mowday’s model of turnover, Academy of

Management Journal 30, pp. 721–743, 1987.

LERNER, Josh; TIROLE, Jean; Some simple economics of Open Souce, Journal

of Industrial Economics 50 (2), pp. 197–234 , 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 (26 de fevereiro de

2012).

MOTOROLA “Android apresenta seus incríveis números de crescimento em todo o mundo”, disponível em http://blogmotorola.com.br/2012/03/19/android-

apresenta-seus-incriveis-numeros-de-crescimento-em-todo-o-mundo/ Acessado em

25/06/2012, (2012)

NEVES, José Luís. Pesquisa qualitativa - características, usos e possibilidades.

Caderno de Pesquisas em Administração, São Paulo, v. 1, n. 3, 1996.

70 OPEN SOUCE INITIATIVE; History; Disponível 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 2055–2073, 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é Maurício dos Santos. Da Iniciação Científica ao TCC: Uma

Abordagem para os Cursos de Tecnologia.1ª edição. Ciência Moderna, 2010.

RELLY, Richard R; Motivating and retaining technical employees, Stevens

Alliance for Technology Management 9 (3), 2005, pp. 1–3.

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. Adoção de tecnologia: Um estudo sobre o uso de software livre nas empresas. Dissertação (mestrado) – Faculdade de Economia,

Administração e Contabilidade. São Paulo: Universidade de São Paulo, 2004.

SoftwareLivreBrasil, Crise impulsiona software de código aberto; Disponível 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. 219–233. 2009

71 STALLMAN, Richard M. Free Software, Free Society: Selected Essays of Richard M. Stallman.Boston: GNU Press, 2002.

STRAUSS, A.; CORBIN, J. Pesquisa Qualitativa: Técnicas e procedimentos para o desenvolvimento de teoria fundamentada. Tradução 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 são grandes disponível em: http://www.tiinside.com.br/News.aspx?ID=103996&C=265 acessado

em 29/03/2012, 2008.

TODOROV, João C.; MOREIRA, Márcio B.; O Conceito de Motivação 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 criação. 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 Praça. (Org.). Abordagens

Teórico-Metodológicas Qualitativas: a vivência da mulher no período reprodutivo. Rio

de Janeiro: Guanabara Koogan, 2003, v. 1, p. 39-45.

72

APÊNDICE A – Consentimento da Participação da Pessoa Como Participante Eu, xxxxxx, portador do RG XXXXXXX e CPF número XXXXXXX, concordo em participar da Pesquisa Etnográfica sobre Motivação de Engenheiros de Software Open Source, como voluntário. Fui devidamente informado e esclarecido pelo pesquisador Danilo Monteiro Ribeiro sobre a pesquisa, os procedimentos nela envolvidos, assim como os possíveis riscos e benefícios decorrentes de minha participação. Também foi me garantido que posso recusar a participar da pesquisa, ou retirar meu consentimento a qualquer momento, mesmo após o início dos trabalhos, sem precisar justificar, sem que isto leve a qualquer prejuízo em minha relação com a organização.

Estou ciente e fui esclarecido de que minha privacidade será respeitada, ou seja, qualquer informação ou elemento que possa de qualquer forma me identificar será mantido em sigilo.

Enfim, tendo sido orientado quanto ao teor de todo o conteúdo aqui mencionado e compreendido a natureza e o objetivo do já referido estudo, manifesto meu livre consentimento em participar, estando totalmente ciente de que não há nenhum valor econômico ou material a receber, ou a pagar, por minha participação. Local e data: _______________________________________________________________

73 APÊNDICE B – Guia de Entrevista com Mantenedor

Introdução

• Apresentação o Agradecimento ao participante o Permissão 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 benefícios para a organização o Explicar cuidadosamente o que se espera da entrevista sobre

motivação.

# Perguntas da Pesquisa Original (Da SILVA et al, 2011)

Pergunta modificada para o Contexto

1. Fale um pouco de você: Sua formação, idade, trajetória profissional

Mesma Pergunta

2. Há quanto tempo você trabalha nesta empresa?

Há quanto tempo você trabalha com desenvolvimento de software?

3. Pergunta Adicionada E com desenvolvimento Open Source?

4. Como você descreveria o ambiente de trabalho aqui?

Como você descreveria o ambiente de trabalho no contexto Open Souce?

5. Pergunta Adicionada Sua diferenças e semelhanças com projetos proprietários?

6. Descreva o(s) projeto(s) no qual atua. Mesma Pergunta 7. Descreva a sua função atual,

principais atividades e responsabilidades.

Mesma Pergunta

74 # Perguntas da Pesquisa Original

(Da SILVA et al, 2011) Pergunta modificada para o Contexto

8. Atualmente, com quantas pessoas você lida no seu dia a dia? Quais os papeis desempenhados por elas?

Atualmente, com quantas pessoas você lida no(s) projeto(s) Open Source em que você atua? Quais os papeis desempenhados por elas?

9. Em comparação com outros campos/áreas, como você avalia o trabalho dos engenheiros de software? Mais/menos estressante, divertido, puxado, significativo, recompensador, etc.

Em comparação com projetos de software proprietários, como você avalia o trabalho com projetos Open Source? Mais/menos estressante, divertido, puxado, significativo, recompensador, etc.

10. Em sua opinião, qual é o maior atrativo da empresa para atrair profissionais?

Na sua opinião, qual é o maior atrativo deste Projeto Open Source?

11. Quais são os maiores motivos de saída de profissionais desta empresa?

Quais são os maiores motivos de saída de profissionais destes projetos Open Source?

12. Em relação a empresas no qual você já trabalhou anteriormente como GP, como você acha que os engenheiros de software se sentem trabalhando nesta empresa?

Em relação 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?

13. Em relação 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 características desses projetos anteriores possuem?

Mesma Pergunta

14. Como funciona a divisão de trabalho/tarefas dentro da sua equipe?

Mesma Pergunta

15. Como você acha que os engenheiros se sentem trabalhando em equipe?

Mesma Pergunta

16. Descreva o que você considera um dia extraordinariamente BOM para um membro de sua equipe.

Retirada



17. Em sua opinião, quais aspectos da Engenharia de Software mais motivam os engenheiros?

Em sua opinião, quais aspectos da Engenharia de Software mais estimulam os engenheiros em projetos Open Source?

18. Como você percebe que esses aspectos estão presentes ou ausentes no seu projeto?

Mesma Pergunta

19. Em sua opinião, dentre as características desta empresa, quais são as que mais estimulam os engenheiros de software?

Em sua opinião, dentre as características deste projeto, quais são as que mais estimulam os engenheiros de software?

20. Em sua opinião, dentre as características do projeto, quais são as que mais estimulam os engenheiros de software?

Mesma Pergunta

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 consideração no momento de atribuir alguma atividade a um membro da equipe?

Retirada

22. O que você acha que estas atividades possuem, para deixar os engenheiros tão estimulados?

Retirada

23. Você poderia descrever uma situação 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 motivação?

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

24. Descreva alguma situação em que você notou um engenheiro realmente estimulado para trabalhar especificamente nesse projeto.

Mesma Pergunta



25. Como você descreveria o comportamento de um engenheiro de software que está claramente motivado com o trabalho?

Mesma Pergunta

26. Como você descreveria os resultados de um engenheiro de software que está claramente motivado com o trabalho?

Mesma Pergunta

27. O que a sua organização oferece ou faz para estimular a motivação dos engenheiros de software?

O que a comunidade oferece ou faz para estimular a motivação dos engenheiros de software?

28. De que forma essas ações afetam o comportamento positivamente dos engenheiros?

Mesma Pergunta

29. De que forma essas ações afetam os resultados positivamente dos engenheiros?

Mesma Pergunta

30. Descreva o que você considera um dia extraordinariamente RUIM para um membro de sua equipe.

Retirada

31. Em sua opinião, quais aspectos da Engenharia de Software mais desmotivam os engenheiros?

Em sua opinião, quais aspectos da Engenharia de Software mais desmotivam a desenvolver software Open Source?

32. Como você percebe que esses aspectos estão presentes ou ausentes no seu projeto?

Mesma Pergunta

33. Em sua opinião, dentre as características desta empresa, quais são as que mais desestimulam os engenheiros de software?

Em sua opinião, dentre as características dos projetos Open Source dos quais você participa ou participou, quais são as que mais desestimulam os engenheiros de software?

34. Em sua opinião, dentre as características do projeto, quais são as que mais desestimulam os engenheiros de software?

Mesma Pergunta



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 consideração no momento de atribuir alguma atividade a um membro da equipe?

Dentre as atividades do dia a dia da sua equipe de engenheiros de software, quais vocês acha que eles menos gostam? Sondagem: Você leva isso em consideração no momento de atribuir alguma atividade a um membro da equipe?

36. O que estas atividades possuem, para deixar os engenheiros tão desestimulados?

Mesma Pergunta

37. Você poderia descrever uma situação 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 desmotivação? O que você acha que causou aquela desmotivação?

Mesma Pergunta

38. Descreva alguma situação em que você notou um engenheiro realmente desestimulado para trabalhar especificamente nesse projeto.

Mesma Pergunta

39. Como você descreveria o comportamento de um engenheiro de software que está claramente desmotivado com o trabalho?

Mesma Pergunta

40. Como você descreveria os resultados um engenheiro de software que está claramente desmotivado com o trabalho?

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

41. O que você faz quando percebe algum membro da sua equipe desmotivado?

Mesma Pergunta

42. O que a sua organização faz (e/ou que não deveria fazer) que mais desmotiva os engenheiros de software?

O que a comunidade faz (e/ou que não deveria fazer) que mais desmotiva os engenheiros de software?

43. De que forma essas ações afetam o comportamento negativamente dos engenheiros?

Retirar ou Mesma Pergunta



44. De que forma essas ações afetam os resultados negativamente dos engenheiros?

Retirar ou Mesma Pergunta

45. Qual critério você utiliza para realizar a divisão do trabalho na sua equipe?

Mesma Pergunta

46. Suponha que um determinado membro da sua equipe goste de realizar uma determinada tarefa, mas ele não tem habilidade, conhecimento ou experiência para realizá-la o que você faz? Sondagem: Qual a reação dele?

Retirada

47. Quais são os pontos fortes da sua equipe?

Mesma Pergunta

48. Como você acha que os engenheiros se sentem em relação a cada um destes pontos fortes?

Mesma Pergunta

49. Quais são os pontos fracos da equipe?

Mesma Pergunta

50. Como você acha que os engenheiros se sentem em relação a cada um destes pontos fracos?

Mesma Pergunta

51. Como você percebe que a MOTIVAÇÃO da sua equipe está em BAIXA?

Mesma Pergunta

52. O que você faz quando verifica que a motivação da equipe está baixa?

Mesma Pergunta

53. Pense em alguém na sua equipe que você considera altamente motivado. Agora, pense em alguém na sua equipe que você considera altamente desmotivado. Você poderia descrever a diferença entre os resultados destes dois engenheiros?

Mesma Pergunta

54. Na sua opinião, o que a empresa deveria/poderia fazer (mas não o faz) para trabalhar melhor a motivação dos engenheiros de software?

Na sua opinião, o que a comunidade deveriam/poderiam fazer (mas não o fazem) para trabalhar melhor a motivação dos engenheiros de software?

55. Para finalizar, como você definiria o termo “motivação”?

Mesma Pergunta



56. Você gostaria de adicionar alguma informação ou observação que não foi perguntada, mas que você considere importante para a motivação de engenheiros de software?

Você gostaria de adicionar alguma informação ou observação que não foi perguntada, mas que você considere importante para a motivação de engenheiros de software no contexto Open Source?

57. Por favor, faça uma avaliação de dois pontos fortes e dois pontos fracos desta entrevista.

Mesma Pergunta

80 APENDICE C – Guia de Entrevista com Engenheiros de Software

Introdução

• Apresentação o Agradecimento ao participante o Permissão 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 benefícios para a organização o Explicar cuidadosamente o que se espera da entrevista sobre

motivação.

# Perguntas da Pesquisa Original (Da SILVA et al 2011)

Pergunta modificada para o Contexto

1. Fale um pouco de você: sua formação, idade, trajetória profissional.

Mesma pergunta

2. O que o levou a trabalhar nesta área (Engenharia de Software)? Sondagem: Teve contato com outras áreas da computação, ou mesmo com outros campos de trabalho antes de trabalhar com Engenharia de Software? Quais?

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

3. Como você se sente atualmente trabalhando como engenheiro de software? * Em comparação com outros campos/áreas, como você avalia o seu trabalho como engenheiro de software? Mais/menos estressante, divertido, puxado, significativo, etc. Em comparação as outras comunidades que você já trabalhou como se sente nesta?

Como você se sente atualmente trabalhando com software Open Source?

4. Há quanto tempo você trabalha nesta empresa?

Há quanto tempo você trabalha com software Open Source e nessa comunidade?

5. O que o levou a trabalhar nesta Empresa?

O que levou a trabalhar neste projeto e na comunidade?

81 6. Dentre as características desta quais

te estimulam a trabalhar aqui? Dentre as características deste projeto quais te estimulam a trabalhar aqui?

7. Pergunta Adicionada Dentre as características deste projeto quais te estimulam nesta comunidade?

8. Dentre as características deste projeto, o que te desestimula?

Dentre as características deste comunidade, o que te desestimula?

9. Antes desta função atual, quais outras funções ou atividades você desempenhou nessa empresa?

Antes desta função atual, quais outras funções ou atividades você desempenhou na comunidade?

10. Descreva a sua função atual e responsabilidades.

Mesma pergunta

11. Quais as atividades que você faz no dia-a-dia?

Quais as atividades que você faz/fazia para o projeto?

12. Agora imagine um dia extraordinariamente bom. Um dia no qual várias, ou todas, as coisas dão certo. Imagine este dia deste a hora em que você acorda até a hora de dormir. Você pode descrever este dia? Depois da resposta espontânea: 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?

Retirada

13. Dentre as atividades do seu dia a dia, quais são as que você mais gosta?

Quais atividade que você mais gostava de Fazer?

14. Descreva o que estas atividades possuem, que características elas tem, que te deixa estimulado?

Mesma pergunta

82 15. Quais atividades você gostaria de

fazer e não faz? Como você se sente?

Mesma pergunta

16. Agora imagine um dia extraordinariamente ruim. Um dia no qual várias, ou todas, as coisas dão errado. Imagine este dia deste a hora em que você acorda até a hora de dormir. Você pode descrever este dia? Depois da resposta espontânea: 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?

Retirada

17. Dentre as atividades do seu dia a dia, quais são as que você menos gosta?

Quais atividades que você menos gostava?

18. Considerando outras atividades do projeto que não fazem parte do seu dia a dia, quais NÃO gostaria de fazer de jeito nenhum

Retirada

19. Descreva o que estas atividades possuem, que características elas tem, que te deixam desestimulado. Sondagem: Em comparação a funções realizadas anteriormente, como você se sente atuando nesta função?

Mesma pergunta

20. Descreva quem são as pessoas da sua equipe com quem você tem relação direta no seu dia-a-dia.

Descreva quem são as pessoas da sua equipe com quem você tem relação direta.

21. Como funciona a divisão de trabalho? Como é a dinâmica do trabalho em equipe? Qual o seu papel?

Mesma pergunta

22. Como você se sente trabalhando nesta equipe?

Mesma pergunta

83 23. Na sua opinião, quais são alguns

pontos fortes da sua equipe? Mesma pergunta

24. Como você sente ao porto forte XX, YY, ZZ.

Mesma pergunta

25. Dê-me um exemplo de uma situação que realmente você se sentiu parte desta equipe.

Mesma pergunta

26. Como você descreveria um colega de trabalho que está claramente motivado com o trabalho?

Mesma pergunta

27. De que forma você acha que isso impacta no trabalho da equipe?

Mesma pergunta

28. De que forma você acha que isso impacta no trabalho dele?

Mesma pergunta

29. Na sua opinião, quais são alguns pontos fracos da sua equipe?

Mesma pergunta

30. Como você sente ao porto fraco XX, YY, ZZ.

Mesma pergunta

31. Dê-me um exemplo de uma situação que realmente você não se sentiu parte desta equipe.

Mesma pergunta

32. Como você descreveria um colega de trabalho que está claramente desmotivado com o trabalho?

Mesma pergunta

33. De que forma você acha que isso impacta no trabalho da equipe?

Mesma pergunta

34. De que forma você acha que isso impacta no trabalho dele?

Mesma pergunta

35. Tem alguma outra função ou projeto [dentro da empresa?] que você preferiria estar alocado? c Como você se sentiria trabalhando lá...

Tem alguma outra função ou projeto dentro da comunidade que você preferiria estar alocado? Como você se sentiria trabalhando lá...

36. E tem alguma outra função ou projeto [dentro da empresa?] que você não gostaria de ser alocado de jeito nenhum? Como você se sentiria trabalhando lá...

Retirada

37. O que a sua organização oferece ou faz para estimular a motivação dos engenheiros de software?

O que a comunidade lhe oferece para estimular a motivação dos desenvolvedores?

38. Como essas ações afetam o seu trabalho?

Mesma pergunta

84 39. O que a sua organização faz (e/ou

que não deveria fazer) que mais desmotiva os engenheiros de software?

O que a sua comunidade faz (e/ou que não deveria fazer) que mais desmotiva os engenheiros de software? Ou retirar

40. Como essas ações afetam o seu trabalho? Sondagem: Tanto comportamental como profissional.

Retirada

41. Na sua opinião, o que a empresa deveria/poderia fazer (mas não o faz) para trabalhar melhor a motivação dos engenheiros de software?

Na sua opinião, o que o mantenedor deveria/poderia fazer (mas não o faz) para trabalhar melhor a motivação dos engenheiros de software?

42. Projetando você daqui a 5 anos, que atividades você gostaria de estar fazendo? No que você gostaria de estar trabalhando ?

Mesma pergunta

43. Projetando você daqui a 5 anos, que atividades você não queria fazer de jeito nenhum? E que tipo de projeto não gostaria de trabalhar?

Mesma pergunta

44. Para finalizar, como você definiria o termo “motivação”?

Mesma pergunta

45. Você gostaria de adicionar alguma informação ou observação que não foi perguntada, mas que você considere importante para a motivação de engenheiros de software?

Você gostaria de adicionar alguma informação ou observação que não foi perguntada, mas que você considere importante para a motivação de engenheiros de software no contexto Open Source?

46. Por favor, faça uma avaliação de dois pontos fortes e dois pontos fracos desta entrevista.

Mesma pergunta

85 APENDICE D – E-mail de convite

Boa tarde a todos,

Estou desenvolvendo meu Trabalho de Conclusão 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 indícios 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

máximo umas 4 a 5 pessoas que participam do mesmo projeto. A entrevista é uma

conversa normal com algumas questões sobre o que leva você a desenvolver

projetos Open Source, nada cansativo nem complexo.

Todas as informações captadas nas entrevistas serão confidências e claro eu

enviarei uma copia do tcc para o grupo.

Alguém gostaria de me ajudar?

Relatorio tecnico sobre os fatores motivadores em equipe open source

Documents

Transcript of Relatorio tecnico sobre os fatores motivadores em equipe open source