Post on 05-Jun-2015
description
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);
Adaptado de Von KROGH et al (2008)
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);
Adaptado de Von KROGH et al (2008)
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.”
(Engenheiro de Software).
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.”
(Engenheiro de Software).
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
75 # Perguntas da Pesquisa Original
(Da SILVA et al, 2011) Pergunta modificada para o Contexto
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
76 # Perguntas da Pesquisa Original
(Da SILVA et al, 2011) Pergunta modificada para o Contexto
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
77 # Perguntas da Pesquisa Original
(Da SILVA et al, 2011) Pergunta modificada para o Contexto
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
78 # Perguntas da Pesquisa Original
(Da SILVA et al, 2011) Pergunta modificada para o Contexto
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
79 # Perguntas da Pesquisa Original
(Da SILVA et al, 2011) Pergunta modificada para o Contexto
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?