\section{Conclusion}
\label{sec:conclusion}

In this paper we presented and discussed issues experienced during a government-funded 
project, in partnership with the University of Brasilia and the University of
São Paulo, to evolve the Brazilian Public Software Portal. 
Its contributions are twofold. First, we present the strategy used to develop
and to deliver an unprecedented platform to Brazilian government. Second,
based on the results of the SPB Portal project, we point out that it is
possible to mitigate conflicts experienced in the development environment
and to conciliate governmental and academy cultures. 

The SPB portal integrates more than 10 FLOSS tools and provides several features,
such as social network, mailing list, version control, content management and
source code quality monitoring. Concerned with the platform susteinability and
maintainabilty, the aforementioned 10 FLOSS tools were integrated with minimum
differences from their official versions and the new developed features were
sent upstream to ensure an alignment between the portal systems and their
respective official versions. In the integration process, the main softwares
were identified, specific teams were formed to work with each one of them
and each team was composed of students with different levels of skills and at
least one senior professional.

In terms of mitigating conflicts, we tried to show that, as long as the
institution can provide a healthy and challenging environment to its students,
one may conciliate studies and professional training in universities.
In our work process, based on open and collaborative software development
practices, students could negotiate their work schedule as well as count on IT
professionals to solve development issues.
Among the students, we have defined coachs for each team and a meta-coach
(coach of whole project). All coaches, together with professors, have
intermediated the comunication between client (Ministry of Planning of Brasil)
and the rest of the group. 
After the end of the project, some students successfully
embraced opportunities in public and private sectors, within national borders
and abroad. Some other students went further and started their own companies.

We also demonstrate that, with some adaptations/"translation processes", it is feasible
to conciliate agile methodologies and FLOSS practices to develop software to 
governmental organizations with functional hierarchical structures that use 
traditional development paradigm.
Aiming at reducing client questions about workconclusion, a DevOps front was
created to automate all deploy process and also  to work in continuous
delivery. The government was brought to our work environment and interacted
with our management and comunication tools. For the project success, we
focused on providing a friendly working environment as well as on showing to
governmental agents another way to interact with the FLOSS community and the
university. 

Future work should use data produced by the project to validate and evaluate
how the used FLOSS and Agile practices have impacted the students and the
governmental development process. For this, we would conduce a \textit{postmortem}
analysis using the project open data and a survey targeting the involved actors.

\textbf{Final remarks}

The portal is available at \url{softwarepublico.gov.br}. All
documentation, including detailed architecture and operation manuals are
also available\footnote{\url{https://softwarepublico.gov.br/doc/}
(in Portuguese only at the moment)}.
%
All the integrated tools are FLOSS and our contributions were published
in open repositories, available on the SPB Portal itself. We also
contributed these features back to the respective communities, which
benefits both those communities and us, since we can share future
development and maintenance effort with other organizations that
participate in these projects. 

%===========
% Conclusion
%===========

% * Gestão dos recursos: Fizemos mais por menos (2.6M de 3.2M) --- sem os dados
%% (escopo, custo, tempo e qualidade) bem discutidos é difícil sustentar essa
%% afirmação, embora eu e Paulo consigamos perceber isso.


%* utilização do projeto para formação de recursos humanos (alunos)

%* dados da verificação dos repositório para a análise da qualidade dos código via Mezuro e CodeClimate

%* o que achamos que irá acontecer com o SPB no futuro breve (acabar)

%* 69 projetos marcados como SPB, de 81 no total na plataforma.

%* 47\% é desenvolvido em PHP.

% foi constatado que aproximadamente 75\% dos softwares \textbf{não} possuem seus códigos-fonte versionados nesta ferramenta. Realizado algumas pesquisas, foi encontrado o código-fonte em outros serviços (Github, Bitbucket).

% Foram adicionados 31 softwares do SPB em ambas as ferramentas (Mezuro e Code Climate), desenvolvidos em PHP e Python. Estas adições resultaram na análise descrita nos próximos parágrafos. No Mezuro, dos 31 softwares adicionados, somente 4 obtiveram sucesso na avaliação. No Code Climate, 16 softwares realizaram a \textit{build} da avaliação com sucesso. Nos que falharam, alguns dos erros foram encontrados em três das \textit{engines}: ora em \textit{duplication}, ora na \textit{phpmd}, ora na \textit{eslint}.

% também foram inseridos no Mezuro para avaliação, 5 projetos dos 17 desenvolvidos em Java, com o intuito de ser um contraponto ao Code Climatepor esta não compreender a análise de projetos em Java, C, ou C++. Infelizmente nenhuma das \textit{builds} resultou em resultados concretos.

%* Debater economia de recursos em orgão públicos