\section{Discussion and Final Remarks}
\label{sec:discussion}

In this paper, we examined an empirical model used in a government-academia
project, which successfully harmonized differences in their usual development
approaches.  We mapped the key decisions to improve the communication and the
development process as a whole. We designed also surveys and conducted them
separately for three groups of participants: government analysts, IT market
professionals, and interns. Finally, we collected \textit{post-mortem} public
data on project management from the platform developed. The results revealed
nine practices from three key decisions taken, and these practices brought 11
benefits, as summarized in the Table \ref{practices-table}.

\begin{table}[]
\centering
\resizebox{\textwidth}{!}{%
\begin{tabular}{ | m{4cm} m{10cm} m{10cm} | } 
\hline
\textbf{Decision} & \textbf{Practice Explanation} & \textbf{Benefits} \\ \hline
\textbf{Project management and communication on the developing platform itself} 
&
\begin{itemize}
\item Migration of project management and communication into 
the platform under development using its integrated software components Gitlab 
and Mailman 
\end{itemize} &
\begin{itemize}
\item Trusting developed code; 
\item Communicating with transparency and efficiency;
\item Easier monitoring and increasing interactions between development team and public servants;
\item Producting organically documentation and records;
\end{itemize} \\ \hline

\textbf{Bring together government staff and development team} &
\begin{itemize} 
\item Biweekly gov staff, senior developers and coaches met to planning and 
review sprint at the UnB headquarters. \item Most of features under development 
were discussed on Gitlab Issue Tracker. \item Only strategic decisions or 
bureaucratic issues involve board directors. \item Continuous Delivery
\end{itemize} &
\begin{itemize} 
\item Reducing communication misunderstood and better meeting expectations of both sides;
\item Overcoming the government bias regarding low productivity of collaboration with academia;
\item Aligning both activities execution pace;
\item Improving the translation of the process from one side to the other;
\end{itemize} \\ \hline

\textbf{Split development team into priority work fronts with IT market specialists} &
\begin{itemize}
\item The development was divided into four fronts (DevOps / UX / Noosfero / Colab) with a certain self-organization of tasks.
\item IT market professionals with recognized experience on each front were hired to work in person or remotely.
\item For each front, there was at least one senior developer and the role of coach.
\item The meta-coach role was also defined to coordinate tasks between teams.
\end{itemize} & 
\begin{itemize}
\item Helping to reconciliate development processes and decision-making;
\item Creating support-points for students, senior developers, and gov staff;
\item Transfering of knowledge from industry and FLOSS community to both academia and government;
\end{itemize}\\ \hline
\end{tabular}%
}
\caption{Empirical SPB management method and its benefits}
\label{practices-table}
\end{table}

Regarding our first question,\textit{What practices based on open source
development experiences would help to combine teams with different management
processes in a government-academia collaboration project?}, we mapped practices
covering aspects from communication of the project to the delivery process of
developed code, as presented in the second column of the Table
\ref{practices-table} (Practice Explanation).

The results of the surveys revealed the benefits of implementing each set of
practices for the case study, answering our second question: \textit{How do
open source development practices benefit the process of 74 developing an
e-government platform in a government-academia collaboration?}. The third
column of the Table \ref{practices-table} (Benefits) shows how the practices
adopted impacted on the relationship between members from both sides, on the
understanding of project development process, and on the appropriation of the
developed platform.

The fruits of this current work corroborate with the lessons learned and reported in our
previous work \cite{meirelles2017spb}, adding the point of view of the
government and the academia in diverse performed levels. Moreover, our results
suggest that many open source practices could be replicated in different
contexts in which the diversity and plurality of its stakeholders need to be
leveled and reconciled.

This work also exposed issues that were not overcome during the project
and need to be evaluated for future government-academia collaborations for
software development. In the interviews, MPOG analysts reported some
difficulties during the project in understanding the idea of collaboration.
They said they needed time to realize that the project was not a client-executor
relationship, but a partnership and both organizations were in the same
hierarchical level in the work plane. They lacked the role of decision maker in
times of deadlock and in the requirements definition. Additionally, the
analysts reported they sometimes felt coerced by coordinators when they tried
to communicate directly with the interns.

As threats to validity of this work, we can point the lack of traceable
qualitative and quantitative records related to the first phase of the project
(about the organization prior to the adoption of the practices mentioned above)
and the application of surveys after project completion, depending on the
memory of the interviewees about 30 months of the project.

Finally, the project investigated in this paper was also an important experience
in teaching open source ecosystems dynamics and agile methodologies applied a
real-work development project. A large amount of data and testimonies were
collected in this work related to the educational context. As future work, we
intend to analyze this information to propose improvements in the teaching of
information technology for undergraduates.