Compare View

switch
from
...
to
 
Commits (3)
Showing 4 changed files   Show diff stats
oss2018/content/01-introduction.tex
  Diff comments   View file @7b530d0
... ... @@ -3,32 +3,38 @@
3 3 E-government projects differ from others due to their complexity and extension
4 4 \cite{anthopoulos2016egovernment}. They are complex because they combine
5 5 construction, innovation, information \& communications technologies, politics,
6   -and social impact. Their extension, on the other hand, is related to their scope,
7   -target audience, organizational size, time, and the corresponding resistance to
8   -change. Government-academia collaborative projects can be considered an
9   -alternative to create novelty for e-government projects and to meet the needs of
10   -society. This collaborative work has challenges, such as organizing the
11   -collaboration project, aligning goals, synchronizing the pace of between
  6 +and social impact. Their extension, on the other hand, is related to their
  7 +scope, target audience, organizational size, time, and the corresponding
  8 +resistance to change. Government-academia collaborative projects may be treated
  9 +as an alternative to create novelty for e-government projects and to meet the
  10 +needs of society. This collaborative work has challenges, such as organizing
  11 +the collaboration project, aligning goals, synchronizing the pace of between
12 12 government and academia \cite{anthopoulos2016egovernment}, and overcoming the
13 13 failure trend of e-government projects \cite{goldfinch2007pessimism}.
14 14  
15   -Poor project management is one of the main reasons why e-government projects
16   -fail \cite{anthopoulos2016egovernment}. When government and academia combine
17   -efforts to develop an e-government solution, the differences in the project
18   -management become an issue. Academia commonly work on cutting edge of
19   -technology while government is still relying on traditional techniques.
20   -Changing the development process in large-size institutions represents
21   -an organizational disturbance which impacts on structure, culture, and
22   -management practices \cite{nerur2015challenges}. As a result, government and
23   -academia have to harmonize their view to increasing the chances of success in
24   -projects with tight deadlines and short budgets.
  15 +Poor project management is one of the causes of e-government projects failure
  16 +\cite{anthopoulos2016egovernment} which in turn grows into a critical issue
  17 +when government and academia combine efforts to develop an e-gov solution.
  18 +Academia commonly works on cutting edge of technology while the government is
  19 +still relying on traditional techniques. Changing the development process in
  20 +large-size institutions represents an organizational disturbance with impacts
  21 +on structure, culture, and management practices \cite{nerur2015challenges}. As
  22 +a result, government and academia have to harmonize their view to increasing
  23 +the chances of success in projects with tight deadlines and short budgets.
25 24  
26   -% TODO: Projetos de sl tem x características e muitas de suas práticas tem se mostrado válidas e que abrem precedentes para utilizar no contexto governo academia. Falar da influência do SL no projeto
  25 +Due to the plurality of the Free Libre Open Source (FLOSS) ecosystems and the
  26 +diversity of organizations which currently employ agile methodologies,
  27 +procedures from both may be an option for harmonizing different management
  28 +approaches. Open communication, project modularity, the community of users, and
  29 +fast response to problems are just a few of the FLOSS ecosystem practices
  30 +\cite{capiluppi, warsta}. Individuals and interactions, working software,
  31 +customer collaboration, responding to change \cite{beck} are the core of agile
  32 +development. With this in mind, FLOSS and agile practices may improve the process
  33 +management and the cooperation of distinct teams.
27 34  
28   -In this work we investigate a set of practices from a 30-month
  35 +In this work, we investigate the empirical method built during 30 months of a
29 36 government-academia project that helped to harmonize the differences between
30   -government and academia management cultures. We trace the best practices based
31   -on open source ecosystems and agile methodologies. Finally, we validate their
32   -benefits by collecting data from the main project repository and by surveying
33   -the project participant points of view.
34   -
  37 +both organization management cultures. We trace the best practices based on
  38 +FLOSS ecosystems and agile methodology. Finally, we collect data from the
  39 +project repository and survey the project participant points of view to
  40 +extracting a set of methods which favor government-academia collaboration.
... ...
oss2018/content/02-relatedwork.tex
  Diff comments   View file @7b530d0
1 1 \section{Related work}
2 2 \label{sec:relatedwork}
3 3  
4   -% TODO:
5   -%O related work está bem montado. Contudo, eu senti falta de falar sobre
6   -%software livre. A adoção dele ou de suas práticas. Se não existe ainda esse
7   -%estudo, então essa seria uma bela colaboração da nossa parte e deveria ser
8   -%evidênciada no último parágrafo. IMO isso é importante uma vez que é a nossa
9   -%chance de por a parte de FLOSS que sempre defendemos, em adição a conferência é
10   -%sobre FLOSS e talvez possam dizer que a gente não se 'enquadra' na conferência.
11   -%Não acho que precisamos tirar a parte 'agile', mas precisamos ser mais conciso
12   -%sobre isso
13   -
14   -%Sugestão do Fabio: Colocar referências de trabalho que conseguiram conciliar
15   -%ou que reportam dificuldade em conciliar ou aplicar processos de gerenciamento
16   -%em um projeto de colaboração
17   -
  4 +% TODO: Verificar se não vale a pena citar os fatores que o Strode descobriu.
  5 +% Eu acho que deixaria a frase mais completa
18 6 Discussions on how to introduce new management methods into an organization are
19   -present in several papers. Nerur et al. identify the critical issues that involve
20   -migrating from traditional to agile by comparing main practices of the two
  7 +present in several papers. Nerur et al. recognized critical issues concerning
  8 +the migration from traditional to agile by comparing practices of both
21 9 methodologies \cite{nerur2015challenges}. The authors point out managerial,
22 10 organizational, people, process, and technological issues to be rethought and
23 11 reconfigured in an organization for a successful migration. Strode et al.
24   -investigate the correlation between adoption of agile methodologies and
25   -organizational culture \cite{impactOfOrganizationalCulture}. They evaluate the
26   -perception of organizational culture and the use of agile practices in nine
27   -software development projects, identifying organizational culture factors that
28   -are correlated to the implementation of agile methods.
  12 +investigated the relationship between the adoption of agile methodologies and
  13 +organizational culture \cite{impactOfOrganizationalCulture} by evaluating nine
  14 +projects. They identified a set of factors directly linked to the agile
  15 +methods.
29 16  
30 17 Some works also discuss how academia can collaborate with the industry in the
31   -management of software projects. Chookittikul et al. evaluates the increasing
32   -use of the agile methods by software development organizations in Thailand and
33   -suggests universities create curricula which develop in their undergraduate
34   -students' practical skills required by industry (mainly agile practices) to
35   -encourage the software industry growth in the region \cite{cho2011gap}.
36   -Sandberg et al. report the use of Scrum in a collaborative research
37   -consortium between industry and academia (involving ten industry partners and
38   -five universities in Sweden) \cite{sandberg2017iacollaboration}.
39   -
40   -New variables arise when a different approach to project management is
41   -introduced to complex and large-scale organizations, such as the public
42   -administration. Alleman et al. describe a production deployment for the US
43   -government, focus on describing the methodology applied to address long-term
44   -planning and value estimation \cite{alleman2003making}. Agile methods
45   -application in the Brazilian public sector are approached by Melo et al. \cite{melo2013agileBr} and De
46   -Sousa et al. \cite{de2016using}, both are experiences limited
47   -to pilot projects. Not production-ready one that will provide more accurate
48   -data with the real world.
49   -
50   -This paper differentiates itself from others by describing a production level
51   -software development collaboration between government and academia,
52   -analyzing differences in the development process and administrative issues of
53   -the two organizations, and evidencing empirical practices that harmonized the
54   -interactions and satisfied the development and management process of both
55   -sides.
56   -
57   -% TODO: if needed, we can add this paper as related work
58   -%% Staying Agile in Government Software Projects - reports how the agile culture and practices (XP and Scrum) were introduced in a development team working on a government project. Describes practices added, adapted and abandoned. They had a experienced small team that did not know agile. TODO: Not sure if any process had to be added/adapted/abandoned at the government side.
59   -
60   -%Talvez seria relevante citar Extending Patterns for Fearless Change: sobre como introduzir novas ideias em uma organização tradicional (em particular, como introduzir métodos ágeis)
61   -%O Mestrado do Alexandre Freire sobre como ensinar métodos ágeis que tem toda um capítulo sobre governo: https://www.ime.usp.br/~ale/dissertacao_ale_para_web.pdf
  18 +management of software projects. Chookittikul et al. evaluated the increasing
  19 +use of the agile techniques in the software development companies in Thailand.
  20 +The authors suggested that universities should create curricula which develop
  21 +in their undergraduate student's practical skills required by industry (mainly
  22 +agile practices) to promote growth in the local software business \cite{cho2011gap}.
  23 +Sandberg et al. report the use of Scrum in a collaborative research consortium
  24 +between industry and academia (involving ten industry partners and five
  25 +universities in Sweden) \cite{sandberg2017iacollaboration}.
  26 +
  27 +Complex and large-scale organizations, such as the public administration, have
  28 +to deal with multiple project variables. Alleman et al. describe a production
  29 +deployment for the US government, focus on the methodology applied to address
  30 +long-term planning and value estimation \cite{alleman2003making}. Agile
  31 +methods application in the Brazilian public sector are approached by Melo et
  32 +al. \cite{melo2013agileBr} and De Sousa et al. \cite{de2016using}, both are
  33 +experiences limited to pilot projects.
  34 +
  35 +Several works tried to highlight the FLOSS practices, while others attempted to
  36 +determine the relationship between the FLOSS practices and agile methods.
  37 +Capiluppi et al. examined about 400 projects to find FLOSS project properties
  38 +\cite{capiluppi}. In their work, they extracted generic characterization
  39 +(project size, age, license, and programming language), analyzed the average
  40 +number of people involved in the project, the community of user, and
  41 +documentation characteristics. Warsta et al. found differences and similarities
  42 +between agile development and FLOSS practices \cite{warsta}. The authors argued
  43 +that FLOSS development may differ from agile by philosophical and economic
  44 +perspective, on the other hand, both shares the definition of work. Finally,
  45 +Eric Raymond describes many of his experience and decisions in his work with
  46 +FLOSS communities \cite{raymond}, this report has many intersections with the
  47 +agile manifesto.
  48 +
  49 +This paper distinguishes itself from others by studying a a production level
  50 +software development collaboration between government and academia. We extracted
  51 +empirical practices that helped to harmonize the interactions between two
  52 +different development process and satisfied the management process of both
  53 +sides. We analyzed these methods from the FLOSS an agile perspective.
... ...
oss2018/content/03-methods.tex
  Diff comments   View file @7b530d0
1 1 \section{Research Design}
2 2 \label{sec:researchdesign}
3 3  
4   -The focus of this paper is investigating practical ways to conciliate cultural
5   -differences in software development processes between government and academia,
6   -without modifying their internal processes. Our analysis was guided by the
7   -following research questions:
  4 +% TODO: Tenho a impressão de que esse parágrafo cairia bem no último parágrafo
  5 +% da introdução. Pelo menos a ideia dele uma vez que resume bem o trabalho
  6 +In this paper, we studied practical alternatives to harmonize different
  7 +software development processes. We are interested in the relationship between
  8 +government and academia from the project management perspective, without the
  9 +enforcement of changing the internal processes. We present two research
  10 +question that guided our work:
8 11  
9 12 \textbf{RQ1.}\textit{How to introduce open source and agile best practices into
10 13 government-academia collaboration project?}
... ... @@ -12,12 +15,12 @@ government-academia collaboration project?}
12 15 \textbf{RQ2.}\textit{What practices would favor effective team management in
13 16 government-academia collaborative project?}
14 17  
15   -To answer these questions, we use as a case study the evolution project of the
16   -SPB portal \cite{meirelles2017spb}, a government-academia collaborative
17   -development based on open source software integration. We designed two surveys
18   -and an interview to the different roles performed by the project
19   -participants and we collected public data from the project development
20   -environment. Our research approach is detailed in the following subsections.
  18 +To answer these questions, we use as a case study research method. We selected
  19 +as a case the evolution of the Brazilian Public Software portal (SPB)
  20 +\cite{meirelles2017spb}, a government-academia collaborative project based on
  21 +open source software. To validate our answers, we picked three different points
  22 +of views: developers, government agent, and data collected from the project
  23 +repository.
21 24  
22 25 \subsection{The case study}
23 26  
... ... @@ -25,62 +28,60 @@ environment. Our research approach is detailed in the following subsections.
25 28 %Apresentar melhor a SPB plataforma aqui para preparar a discussão dos resultados (usar modelo IEEE Software)
26 29  
27 30 %TODO por parágrafo
28   -%five existing open source software (substitutir software por systems)
29   -%systems-of-sytems software (Colab) (substitutir software por framework)
30   -
31   -The project to evolve the Brazilian Public Software Portal was a partnership
32   -between government and academia held between 2014 and 2016
33   -\cite{meirelles2017spb}. To solve maintenance problems and fill design-reality
34   -gaps in the portal, the Ministry of Planning (MPOG) joined the University of
35   -Brasília (UnB) and the University of São Paulo (USP) to develop a platform
36   -based on the integration and evolution of five existing open source
37   -software. This environment was a novelty in the context of the Brazilian
38   -government, due to the technologies employed and its diverse features,
39   -including social networking (Noosfero), mailing lists (MailMan), version
40   -control system (GitLab), and source code quality monitoring (Mezuro), all
41   -integrated using a system-of-systems software (Colab) \cite{meirelles2017spb}.
42   -
43   -%Não usar empirical practices => best practices
44   -%undergraduate students => undergraduate interns
45   -%Colocar no discurso direto: The project hired 6 IT profectionals, and 2 designers.
46   -
  31 +%five existing open source software (substitutir software por systems) --> As minhas modificações removeram isso, contudo vale a pena verificar
  32 +%systems-of-sytems software (Colab) (substitutir software por framework) --> Não alterei uma vez que me parece inconsistente com os trabalhos antigos.
  33 +
  34 +The project to evolve the SPB was a partnership between government and academia
  35 +held between 2014 and 2016 \cite{meirelles2017spb}. The old version of SPB
  36 +suffers from maintenance problems and design-reality gaps. In this sense,
  37 +Ministry of Planning (MPOG) decided to join the University of Brasília (UnB)
  38 +and the University of São Paulo (USP) to develop a new platform based existing
  39 +open source software. However, it was required to integrate multiple software
  40 +in the same system in the way that end user has a unified experience between
  41 +the tools.
  42 +
  43 +The new SPB portal was a novelty in the context of the Brazilian government,
  44 +due to the technologies employed and its diverse features. The project includes
  45 +social networking (Noosfero), mailing lists (MailMan), version control system
  46 +(GitLab), and source code quality monitoring (Mezuro). All of this software is
  47 +integrated using a system-of-systems software (Colab) [1].
  48 +
  49 +%Colocar no discurso direto: The project hired 6 IT profectionals, and 2 designers. -> Eu acho importante falar que eles tinham backgroun em FLOSS
47 50 The academic team carried out development activities in the Advanced Laboratory
48 51 of Production, Research and Innovation in Software Engineering (LAPPIS) at UnB.
49   -The project management and development process in this laboratory are usually
50   -executed adopting empirical practices from open source communities and agile
51   -methodologies. For this project, a total of 42 undergraduate students and two
52   -professors participated in the development team. Six IT professionals were also
53   -hired as senior developers due to their experiences in open source projects and
54   -two designers specialized in User eXperience.
55   -
56   -%(Melhorar a frase) Although they were responsible... Sugestão de sequência: theses government servants did not develop software. Their responsability was contracting...
  52 +The laboratory born from members of Brazillian FLOSS community and from
  53 +professors that worked with agile values, naturally, LAPPIS embrace the best
  54 +practices of both ecosystems. For this project, the laboratory had a total of
  55 +42 undergraduate interns, and two professors engaged in the development team.
  56 +Finally, the project had 6 senior professionals with vast experience with
  57 +FLOSS, and two designers specialized in User eXperience (UX).
57 58  
58 59 The government team was composed of one director, one coordinator, and two IT
59   -analysts from MPOG. Although they were responsible for the
60   -execution of this collaboration, their department generally does not execute
61   -development of ministry's software projects, since its responsibility is
62   -contracting and homologating software development services, following
63   -traditional management approaches, such as the RUP, CMMI, and PMBOK.
64   -
65   -%Met in person to manage...
66   -%To improve the project management process we have adopted and evolute a set of empirical practices based on open source ecosystems and agile methodologies, establishing an empirical management model.
67   -%Melhorar frase como um todo tirando o 'we' (diferenciar autor (we) do coordenador do projeto): To improve the project management process we have adopted and evolved a set of empirical practices based on open source ecosystems and agile methodologies, establishing an empirical management model.
68   -%Sugestão de conteúdo para finalizar a última frase
69   -%"Ao longo do projeto, os seus responsáveis foram experimentando e testando práticas coletadas do OSS de forma intuitiva e não-sistemática. Neste paper tentamos analisar e sistematizar essas melhores práticas."
70   -The leaders of these two aforementioned teams periodically met in person for
71   -the purpose of managing the project progress, discussing strategic and
72   -technical goals. Initially, these meetings took place at the ministry's
73   -headquarters and, usually, only directors and professors participated. The
74   -management of the development team was concentrated in the academic side and
75   -was organized in biweekly sprints and 4-month releases. With the progress of
76   -the project, this workflow proved to be inefficient. Conflicts between the
77   -internal management processes and differences in pace and goals of each
78   -institution were compromising the platform development. To improve the project
79   -management process we have adopted and evolute a set of empirical practices
80   -based on open source ecosystems and agile methodologies, establishing an empirical
81   -management model.
82   -
83   -\subsection{Survey and data collection}
  60 +analysts from MPOG. They were responsible for contracts and managed the
  61 +collaboration, which means they do not produce software. Analysts following
  62 +traditional management approaches (e.g., RUP, CMMI, and PMBOK) for a new
  63 +contract and homologating software services.
  64 +
  65 +The leaders of LAPPIS and MPOG periodically met in person to manage the project
  66 +progress, discussing strategic issues and technical goals. Initially, these
  67 +meetings took place at the Ministry's headquarters and, usually, only directors
  68 +and professors participated. On the academic side, the management of the
  69 +development teams often spends two weeks per sprint and release a new version
  70 +each 4-month. During the project progress, this workflow proved to be
  71 +inefficient. Conflicts between the internal management processes and
  72 +differences in pace and goals of each institution were compromising the
  73 +platform development.
  74 +
  75 +% TODO: Eu alterei de acordo com os comentário. Contudo, da minha experiência no projeto eu não sei se isso é verdade. Eu acho que não foi bonito como descrito aqui.
  76 +We decided to adopt and assess a set of empirical practices based on FLOSS
  77 +ecosystems and agile values. We tried this strategy as an attempt to improve
  78 +the project management process by reducing the conflict between the government
  79 +and academia. We built an experimental management model to harmonize the
  80 +different cultures. During the project, the members were encouraged to try
  81 +FLOSS practices in intuitive a non-systematic way. In this paper, we try to
  82 +analyze and codify these practices.
  83 +
  84 +\subsection{Survey, Interview and Data Collection}
84 85  
85 86 %UnB undergraduate interns
86 87 %Online questionnaire (Não usar survey, usar sempre questionnaire)
... ... @@ -88,69 +89,61 @@ management model.
88 89 %The questions are classified into categories
89 90 %tirar "in the context of government and project;"
90 91  
91   -We divided the UnB development team into two groups of target participants
92   -according to their roles during the project: \textit{UnB Interns} and
93   -\textit{Senior Developers}. For each group, we designed an online survey with
  92 +We divided the development team into two groups of participants according to
  93 +their roles during the project: UnB undergraduate interns and Senior
  94 +developers. For each set of members, we designed an online questionnaire with
94 95 topics related to project organization, development process, communication and
95 96 relationship between members, acquired knowledge, and experience with open
96   -source projects. We interviewed also two \textit{MPOG analysts} who directly
97   -interacted with the development team and project development process. The
98   -interview questions could be classified into four parts: Professional profile;
99   -Organization, communication and development methodologies in the context of
100   -government and project; Satisfaction with the developed platform; Lessons
101   -learned.
102   -
103   -%UnB interns (undergraduate students) => interns
104   -%their average age [in september 2017] are...
105   -%arredondar as casas das porcentagem, nada depois da virgula 43,2% => 43%
  97 +source projects. We also interviewed two MPOG analysts who directly interacted
  98 +with the development team and project development process. The interview
  99 +questions had four parts: (1) Professional profile; (2) Organization,
  100 +communication and development methodologies in the context of government; (3)
  101 +Satisfaction with the developed platform; (3) Lessons learned.
  102 +
  103 +
106 104 %falar as porcentagens sobre a profissão de todos inclusive teacher and public servants
107 105 %link to online questionnaire throught e-mail
108   -
109   -We sent the link to the online survey through emails to 42 UnB interns
110   -(undergraduate students), who participated in any time of the project as
111   -developer receiving a scholarship. We received a total of 37 responses. Their
112   -average age is 25 years old and 91.9\% of them are male. Currently, 35.1\%
113   -continue at the university as undergraduate or graduate students, 18.9\% work as
114   -a developer in a small company and 18.9\% in medium or large companies, 10.8\%
115   -are entrepreneurs, 8.1\% are unemployed and the others work as teachers or
116   -civil servants. 43.2\% said the SPB project was their first experience with
117   -open source software.
  106 +We sent the online questionnaire link via email to 42 interns, all of them
  107 +worked at any period of the project as a developer and received a scholarship.
  108 +We received a total of 37 responses. Their average age in September 2017 is 25
  109 +years old, and 92\% of them are male. Currently, 35\% continue at the university
  110 +as undergraduate or graduate students, 19\% work as a developer in a small
  111 +company and 19\% in medium or large enterprises, 11\% are entrepreneurs, 8% are
  112 +unemployed, and the others work as teachers or civil servants. About of the
  113 +interns 43\% said the SPB project was their first experience with open source
  114 +software.
118 115  
119 116 %We also invited the 8 seniors developers to filling the oline questionnaire and all of them did.
120 117 %They average age are
121 118  
122   -We also sent the link to the online survey through emails to eight senior
123   -developers (IT professionals). All of them answered the questionnaire.
124   -Their average age is 32 years old and 87.5\% are male. They have an average of
125   -11 years of experience in the IT market, and currently, 62.5\% of respondents
126   -are company employees, 37.5\% are freelance developers, 25\% are master's
127   -degree students and 25\% entrepreneurs. They have worked on average in 5
128   -companies and participated in 4 to 80 projects. They participated in this
129   -collaborative project between 7 to 24 months. 85.7\% of them had some
130   -experience with free software before the SPB project.
131   -
132   -
133   -Two MPOG IT analysts were interviewed separately. Each interview took an
134   -average of 2 hours with 28 open questions. They are more than 30 years old and
135   -have been government employees for more than 7 years. Only one of them
136   -continues working in the same ministry. For both, this collaborative project
137   -was their first experience of government-academia development collaboration.
138   -
  119 +We also sent the online questionnaire through emails to 8 senior developers (IT
  120 +professionals), and all of them participated. Their average age is 32 years
  121 +old, and 87\% are male. On average they have 11 years of experience in the IT
  122 +market. Currently, 62\% of the interviewed have a formal job, 37\% are freelance
  123 +developers, 25\% are master's degree students, and 25\% are entrepreneurs. On
  124 +average they worked in 5 different companies and participated in 4 to 80
  125 +projects. They joined in this collaborative project between 7 to 24 months, and
  126 +86\% of them had some experience with FLOSS before the SPB project.
  127 +
  128 +We interviewed two MPOG analysts separately. Each interview took an average of
  129 +2 hours with 28 open questions. They are over 30 years old, and they have more
  130 +than 7 years of experience working in the government. Only one of them
  131 +continues working in the same ministry. Both of the analysts said this
  132 +collaborative project was their first experience of government-academia
  133 +development collaboration.
  134 +
139 135 %We collected from the repository manager all open issues and commits.
140 136 %We collected from the main project repository all the issues and commits.
141 137 %The number of comment authors
142 138 %In the main project repository
143   -
144 139 Finally, we quantitatively analyze data about the development of the project,
145   -publicly available on the SPB platform. We collected from the repository
146   -manager tool of the platform all open issues and commits related to the main
147   -repository of the platform, that is, the development repositories of the
148   -integrated software were not considered. For issues, we collected project
149   -name, author of the issue, opening date, issue title, and the number of comments.
150   -We also collected information about total open issues, the total commits,
151   -different authors of issues, the number of different authors of issues, the number of
152   -comments, authors of comments, the number of authors other than comments. During
153   -the period from April 2015 to June 2016, 879 issues were opened by 59 distinct
154   -authors with a total of 4,658 comments and 64 distinct commentators. The
155   -development team made 3,256 commits in the repository provided by SPB platform.
156   -
  140 +publicly available on the SPB platform. We collected data from the repository
  141 +manager all open issues and commits. We not considered the development
  142 +repositories of the integrated software (e.g., Noosfero and Gitlab). Regarding
  143 +the issues, we collected the total of them, project name, authors, opening
  144 +date, title, and the number of comments. We also get information about the
  145 +total commits, different authors per issues, the number of comments, authors of
  146 +comments, the number of authors other than comments. During the period from
  147 +April 2015 to June 2016, 879 issues were opened by 59 distinct authors with a
  148 +total of 4,658 comments and 64 different commentators. The development team
  149 +made 3,256 commits in the repository provided by SPB platform.
... ...
oss2018/spb-oss-2018.bib
  Diff comments   View file @7b530d0
... ... @@ -195,3 +195,38 @@
195 195 organization={IEEE}
196 196 }
197 197  
  198 +@inproceedings{capiluppi,
  199 + title={Characteristics of open source projects},
  200 + author={Capiluppi, Andrea and Lago, Patricia and Morisio, Maurizio},
  201 + booktitle={Software Maintenance and Reengineering, 2003. Proceedings. Seventh European Conference on},
  202 + pages={317--327},
  203 + year={2003},
  204 + organization={IEEE}
  205 +}
  206 +
  207 +@inproceedings{warsta,
  208 + title={Is open source software development essentially an agile method},
  209 + author={Warsta, Juhani and Abrahamsson, Pekka},
  210 + booktitle={Proceedings of the 3rd Workshop on Open Source Software Engineering},
  211 + pages={143--147},
  212 + year={2003}
  213 +}
  214 +
  215 +@article{beck,
  216 + title={Manifesto for Agile Software Development. Agile Alliance (2001)},
  217 + author={Beck, Kent and Beedle, M and Bennekum, A and others},
  218 + journal={Retrieved June},
  219 + volume={14},
  220 + year={2010}
  221 +}
  222 +
  223 +@article{raymond,
  224 + title={The cathedral and the bazaar},
  225 + author={Raymond, Eric},
  226 + journal={Philosophy \& Technology},
  227 + volume={12},
  228 + number={3},
  229 + pages={23},
  230 + year={1999},
  231 + publisher={Springer}
  232 +}
... ...