Motivação de Desenvolvedores Open Source

UNIVERSIDADE DE PERNAMBUCO
FACULDADE DE CIÊNCIA E TECNOLOGIA DE CARUARU
BACHARELADO EM SISTEMAS DE INFORMAÇÃO

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

DANILO MONTEIRO RIBEIRO

Caruaru, Junho de 2012.

UNIVERSIDADE DE PERNAMBUCO

DANILO MONTEIRO RIBEIRO

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

Monografia apresentada a Faculdade de Ciência e
Tecnologia de Caruaru - Universidade de
Pernambuco, como requisito parcial à obtenção do
grau de Bacharel em Sistemas de Informação, sob
orientação do Profº. M.Sc. Pietro Pereira Pinto e co-
orientação pelo Profº M.Sc Alberto César Cavalcanti
França.

Orientador: M.Sc Pietro Pereira Pinto

Co-orientador: M.Sc Alberto César Cavalcanti França

CARUARU

2012

iii

Dedico este trabalho à minha família, amigos e
professores.

iv

AGRADECIMENTOS

Gostaria de agradecer neste trabalho, o meu grande amigo e incentivador tio
Neto que sempre me ajudou durante a graduação, me fez pensar questões mais
amplas e a sempre buscar dar o melhor de mim, assim como meu tio Sandro, são
exemplos de superação e de seres humanos que eu quero ser.

Minha mãe que apesar de tudo fez sempre o possível e o impossível para eu
me tornar a pessoa que sou e apesar da saudade sempre me incentivou a continuar
no curso.

Meus amigos de Casa e de Graduação, em especial Levi, Carlos Magno, o
mão de vaca do César Albuquerque, Maryvania e José “Marola” Paulo, enchi muito o
saco desse povo, mas passamos juntos e sobrevivemos.

Minha namorada Juliett Figueiredo com quem eu quero construir minha
família, que me acompanhou durante essa jornada, cerca de 3 anos de graduação
me ouvindo falar de pesquisa, artigos, trabalhos, deve ter sido um saco mas quase
nunca reclamou e sempre foi compreensiva.

Gostaria de agradecer Humberto Rocha pela oportunidade que tive de ser
aluno bolsista de Iniciação Cientifica, assim como Vinicius Garcia que aceitou a ideia
de ser meu orientador, aprendi muito com os dois durante esse tempo e foi muito
proveitoso.

Alguns professores me marcaram mais que outros, não desmerecendo os
outros claros, Almir Moura com sua didática sensacional, tornou-se um grande
amigo meu, Fernando Pontual, Carvalho e Cristóvão que com suas experiências me
ensinaram muita coisa na hora do almoço, sempre me ensinaram a ver mais que o
curso pode proporcionar. Cicero Garrozi, um professor com que eu ainda quero
trabalhar um dia.

Não menos importante quero agradecer a Pietro por ter aceitado o desafio de
orientar em uma área que não é a dele, sempre atento as correções foi uma figura
importante na construção deste trabalho. Outra pessoa com que aprendi muito e foi
muito importante para a construção deste trabalho foi o César França que me ouviu
atentamente quando eu fui pedir para trabalhar em pesquisa de outra instituição,
aceitou me orientar mesmo eu não sendo aluno do mesmo, nem da instituição que
ele trabalha. Muito obrigado.

Um alô especial para Flavio Neves, obrigado por tudo. A todos não citados,
infelizmente o espaço é pouco, mas obrigado. Deus, obrigado por todas as coisas
boas e ruins na minha vida.

v

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

vi

Abstract

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

Key Words: Software Engineer, Motivation, Open Source.

vii

SUMÁRIO

1. INTRODUÇÃO ................................................................................................... 11

1.2 Objetivos ..................................................................................................... 12
1.2.1 Objetivo Geral ...................................................................................... 12
1.2.2 Objetivos Específicos ........................................................................... 12
1.3 Justificativa de pesquisa ............................................................................. 13
1.4 Organização do Trabalho ............................................................................ 15

2 REFERENCIAL TEÓRICO ................................................................................ 16

2.1 Open Source e Software Livre ......................................................................... 16
2.1.1 Software Livre ...................................................................................... 16
2.1.2 Free Software Fundation ...................................................................... 17
2.1.3 Software Open Source ......................................................................... 18
2.1.3.1 Características do desenvolvimento Open Source .............................. 21
2.2 O Estudo da Motivação e suas Aplicações ao Contexto da Engenharia de
Software................................................................................................................. 22
2.2.1 O Estudo da Motivação na Psicologia .................................................. 22
2.2.2 Motivação no Desenvolvimento de Software ....................................... 23
2.2.3 Motivação no contexto Open Source ................................................... 27
2.2.3.1 WU et al (2007) .................................................................................... 28
2.2.3.2 Oreg e Nov (2007)................................................................................ 29
2.2.3.3 Von Krogh et al (2008) ......................................................................... 31
2.3 Discussão ........................................................................................................ 34

3 MÉTODOS ......................................................................................................... 35

3.1 Natureza da Pesquisa ................................................................................. 35
3.1.1 Quanto aos Fins ................................................................................... 35
3.1.2 Quanto à Forma de Abordagem ................................................................ 35
3.1.3 Quanto aos métodos de procedimentos .................................................... 36
3.2 Premissas ........................................................................................................ 37
3.3 Etapas de pesquisa ......................................................................................... 37

viii

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

4. Resultados ........................................................................................................... 48

4.1 Descrição do Contexto..................................................................................... 48
4.2 Resultados da Codificação aberta ................................................................... 50
4.2.1 Aspectos da Comunidade ............................................................................. 51
4.2.3 Aspectos do trabalho em equipe .................................................................. 55
4.3 Resultados da codificação axial ....................................................................... 60
4.4 Resultados da codificação seletiva .................................................................. 63
4.5 Avaliações dos Resultados .............................................................................. 65

5. Conclusão ............................................................................................................ 68

5.1 Trabalhos futuros ............................................................................................. 69

REFERÊNCIAS......................................................................................................... 71

ix
Índice de figuras

Figura 1 - MOCC .................................................................................................................... 26
Figura 2 - Motivadores intrínsecos e extrínsecos ............................................................. 27
Figura 3 - Geração da teoria da comunidade ................................................................... 65

x

Índice de Tabelas

Tabela 1 - Evolução do conceito de Motivação ................................................................ 22
Tabela 2 - Fatores Motivadores........................................................................................... 24
Tabela 3 - Fatores Desmotivadores ................................................................................... 25
Tabela 4 - Fatores Motivacionais intrínsecos .................................................................... 32
Tabela 5 - Fatores Motivacionais extrínsecos internos ................................................... 32
Tabela 6 - Fatores Motivacionais extrínsecos................................................................... 33
Tabela 7 - Aspectos motivacionais ..................................................................................... 50
Tabela 8 - Sinais de motivação ........................................................................................... 58

11

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.

12

Seguindo a premissa que pessoas motivadas produzem mais, Von Krogh et al
(2008) busca entender o que motiva os engenheiros de software Open Source. Para
este autor, neste contexto, as equipe 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/

13

• 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

14

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.

15

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.

16

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

17

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

18

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/

19

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

20

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

21

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.

22

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

23

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

24

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 Satisfação da
incentivos necessidade de
desenvolvimento
Variedade do trabalho Plano de Carreira
Sensação de Equilíbrio entre a vida
pertencimento a uma pessoal e profissional
esquipe
Trabalhar em uma Participação
empresa de sucesso
Empowerement/ Feedback
Responsabilidade

25

Bom gerenciamento Reconhecimento
Confiança/ respeito Equidade

Trabalho tecnicamente Segurança no emprego
desafiador
Contribuir/ importância Condições apropriadas
da tarefa 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 Falta de promoção
recompensa
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 Equidade
má qualidade
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

26

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)

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

27

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.

28

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.

29

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.

30

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

31

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.

32

Tabela 4 - Fatores Motivacionais intrínsecos
Motivação Conceito Trabalhos Relacionados
Ideologia Ideologia é citada como um dos principais HEMETSBERGER (2004);
motivos para iniciar um projeto Open Source. GHOSH, (2005);
Pode ser observada com o uso de termos DAVID et al. (2003);
como: “Software deve ser livre para todos”, LAKHANI e WOLF (2005);
ou “o código aberto deve substituir o HERTEL et al. (2003);
software proprietário”. 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 BENKLER (2002);
“cultura hacker” que emergiu na década de OSTERLOH e ROTA (2007);
1980. LAKHANI e VON HIPPEL
(2003);
LUTHIGER e JUNGWIRTH
(2007);
LAKHANI e WOLF (2005);
HERTEL et al. (2003);
ROBERTS et al. (2006);
Amigos de Sangue É um tipo de organização social, onde cada ZEITLYN (2003);
(Kinship família (casta) tende a fazer tudo pelo HEMETSBERGER (2004);
Amity) sucesso da própria família, ou dos seus HARS e OU (2002);
próprios membros. LAKHANI e WOLF (2005);

Adaptado de Von KROGH et al (2008)
Tabela 5 - Fatores Motivacionais extrínsecos internos
Reputação A reputação pode ser classificada como: RAYMOND (1998);
reputação interna, quando é direcionada aos STEWART (2005);
membros da comunidade ou potenciais LERNER e TIROLE (2002);
empregadores, e externa vem de fora da OSTERLOH e ROTA (2007);
comunidade e de outras pessoas LAKHANI e VON HIPPEL
significantes, como amigos. (2003);
LATTEMANN e STIEGLITZ
(2005);
SPAETH et al (2008);
HARS e OU (2002); GHOSH
(2005)
ROBERTS et al (2006);
STEWART (2005);
HERTEL et al (2003);

33

Reciprocidade / Para o desenvolvimento Open Source a BERGQUIST e LJUNGBERG
Economia da economia da doação faz com que os (2001);
doação desenvolvedores distribuam seu código HEMETSBERGER (2004);
esperando que haja reciprocidade. LAKHANI e WOLF (2005);
DAVID et al (2003);
LAKHANI e VON HIPPEL
(2003);

Aprendizado É a motivação de aprender novas GHOSH (2005);
habilidades ou a oportunidade de HEMETSBERGER (2004);
experiência de desenvolver software e tê-lo LAKHANI e WOLF (2005);
testado e comentado por outras pessoas WU et al (2007);
após o lançamento. ROBERT et al (2006)
YE e KISHIDA (2003);
LAVE e WENGER (1991);
RULLANI (2007);
Valor de uso É a motivação de criar software para uso RAYMOND (1999);
próprio próprio, ou seja, resolver algum problema LAKHANI e VON HIPPEL
que os aplicativos atuais não conseguem (2003);
resolver de maneira satisfatória. 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
Carreira Os desenvolvedores são motivados por LAKHANI e WOLF (2005);
preocupações na carreira. Publicar um HEMETSBERGER (2004);
software livre pode mostrar seu talento para WU et al (2007) ;
potenciais empregadores, aumentado, HARS e OU (2002);
assim, seu valor no mercado de trabalho. ROBERTS et al (2006);
GHOSH (2005);
Pagamento Uma minoria significativa (aproximadamente LAKHANI e WOLF (2005);
40%) dos colaboradores são pagos para HARS e OU (2002);
participar de projetos Open Source. O HERTEL et al. (2003);
conceito é semelhante ao de uma empresa LUTHIGER e JUNGWIRTH
de software proprietário em que o (2007);
desenvolvedor ganha por produção. DAHLANDER AND WALLIN
(2006);

34

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.

35

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

36

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

37

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

38

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

39

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;

40

 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

41

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

42

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.

43

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.

44

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

45

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

46

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,

47

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.

Motivação de Desenvolvedores Open Source

Motivação de Desenvolvedores Open Source

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (16)

Similar a Motivação de Desenvolvedores Open Source

Similar a Motivação de Desenvolvedores Open Source (20)

Motivação de Desenvolvedores Open Source