Study on open source software governance at the European Commission and selected other European institutions
FINAL VERSION OF THE REPORT
A study prepared for the European Commission Directorate-General for Informatics by:
This study was carried out for the European Commission by KPMG Italy.
Disclaimer
The information and views set out in this publication are those of the author(s) and do not necessarily reflect the official opinion of the Commission. The Commission does not guarantee the accuracy of the data included in this document. Neither the Commission nor any person acting on the Commission’s behalf may be held responsible for the use which may be made of the information contained therein. © European Union 2020
Study on open source software governance at the European Commission and selected other European Institutions Page 2
Table of Contents
ABSTRACT ...... 6
EXECUTIVE SUMMARY ...... 7
1. OPEN SOURCE SOFTWARE USE WORLDWIDE ...... 9
1.1. INTRODUCTION ...... 9
1.2. OPEN SOURCE SOFTWARE POLICIES/INITIATIVES WORLDWIDE ...... 10 1.2.1. EU public services policies ...... 10 United Kingdom ...... 10 France ...... 12 Italy ...... 15 Spain ...... 16 Germany ...... 18 The Netherlands ...... 20 Denmark ...... 20 Sweden ...... 21 Malta ...... 22 Greece ...... 23 1.2.2. Public services policies in the rest of the world ...... 25 Switzerland ...... 25 United States of America ...... 25 Brazil ...... 26 Malaysia ...... 28 Australia ...... 28 India ...... 29 South Africa ...... 30 1.2.3. Other Organisations ...... 31 Google ...... 31
1.3. FINDINGS FROM WORLDWIDE OPEN SOURCE SOFTWARE RESEARCH ...... 32 1.3.1. Strengths ...... 32 1.3.2. Weaknesses ...... 33 1.3.3. Further Interesting Recent Developments ...... 34 1.3.4. Successful open source software adoption approaches ...... 35
1.4. ANALYSIS OF OPEN SOURCE USAGE STATUS IN SELECTED ORGANISATIONS ...... 36 1.4.1. Focus panel of organisations: selection criteria and pertinent considerations ...... 37 1.4.2. Justification for the selection of the six organisations proposed for the analysis ...... 38 1.4.3. Organisation factsheets ...... 40 Factsheet – UK Government ...... 40
Study on open source software governance at the European Commission and selected other European Institutions Page 3
Factsheet – French Government ...... 43 Factsheet – Italian Government ...... 47 Factsheet – Municipality of Athens ...... 50 Factsheet – US Government ...... 53 Factsheet – Google ...... 57
1.5. FINDINGS FROM ORGANISATION ANALYSIS ...... 61
2. REVIEW OF THE CURRENT OPEN SOURCE SOFTWARE STRATEGY (2014-2017) ...... 64
2.1. INTRODUCTION ...... 64
2.2. REVIEW OF THE EC ‘OPEN SOURCE SOFTWARE STRATEGY 2014-2017’ AND SUPPORTING DOCUMENTATION ...... 64
2.3. UPDATE ON EC OPEN SOURCE SOFTWARE MATURITY INDEX ...... 67 2.3.1. Methodology and scope of the Index ...... 67 2.3.2. Calculating the EC Open Source Software Adoption Maturity Index ...... 68 2.3.3. Analysis of maturity per category ...... 69 2.3.3.1. Desktops ...... 69 2.3.3.2. Servers...... 70 2.3.3.3. Collaboration and web tools ...... 71 2.3.3.4. Development ...... 71 2.3.3.5. EC-published software ...... 72 2.4. ANALYSIS OF THE GAP BETWEEN COMMISSION’S OPEN SOURCE SOFTWARE APPROACH AND OTHER WORLDWIDE APPROACHES.. 73 2.4.1. Commonalities ...... 73 2.4.2. Differences ...... 76
2.5. RECOMMENDATIONS ON THE CURRENT EC ‘OPEN SOURCE SOFTWARE STRATEGY 2014-2017’ ...... 82
3. INTERVIEWS WITH EC INTERNAL STAKEHOLDERS ...... 84
3.1. OBJECTIVE ...... 84
3.2. INTERVIEWS OVERVIEW ...... 84
4. ANALYSIS AND RECOMMENDATIONS FOR EVOLUTION OF THE OPEN SOURCE SOFTWARE STRATEGY OF THE EUROPEAN COMMISSION ...... 87
4.1. OBJECTIVE AND SCOPE ...... 87
4.2. RECOMMENDATIONS: ANALYSIS, CLUSTERING AND HIGHLIGHTS ...... 87
4.3. RECOMMENDATIONS: SUPPORTING EVIDENCE ...... 104
5. INTERVIEWS WITH STAKEHOLDERS FROM OTHER PARTICIPATING EU INSTITUTIONS ...... 107
5.1. OBJECTIVE ...... 107
5.2. INTERVIEWS OVERVIEWS...... 107
6. ANALYSIS AND RECOMMENDATIONS ON THE FEASIBILITY OF ARRIVING WITH A SINGLE OPEN SOURCE SOFTWARE POLICY FOR EU INSTITUTIONS ...... 110
6.1. INTRODUCTION ...... 110
Study on open source software governance at the European Commission and selected other European Institutions Page 4
6.2. FEASIBILITY STUDY ...... 110 6.2.1. Factors favouring the extension of the open source software strategy to EU institutions ...... 111 6.2.2. Factors/Risks threatening the extension of the open source software strategy to EU institutions ...... 112
6.3. RECOMMENDATIONS ...... 113
6.4. CONCLUSIONS ...... 114
7. CONCLUSIONS AND LESSONS LEARNED ...... 115
7.1. SUMMARY OF THE STUDY AND HIGH-LEVEL OVERVIEW OF THE FINDINGS AND RECOMMENDATIONS ...... 115
7.2. LESSONS LEARNED ...... 118
8. APPENDIX ...... 121
8.1. BIBLIOGRAPHY ...... 121
Study on open source software governance at the European Commission and selected other European Institutions Page 5
Abstract The target of this study is to assist EU-FOSSA in shaping the new open source software strategy of the European Commission (EC). The study starts with a report on the status of open source software in the world, with emphasis on the developments after 2014 in the adoption of open source by public services and institutions. The fresh information that is presented helps identifying the weak and strong points of open source adoption by public organizations and it is used to review the latest (2014-2017) EC open source software strategy. EC internal stakeholders have been interviewed with the purpose of capturing their opinion on open source software adoption by the EC and their expectations for the future strategy. The document proceeds with a series of recommendations for the development of the new EC open source strategy that are based both on the evidence collected worldwide and the feedback from the interviews. Additionally, the study reports and advises on the extension of the EC strategy to EU institutions, and finally describes the lessons learned in view of the design and implementation of the new strategy.
Study on open source software governance at the European Commission and selected other European Institutions Page 6
Executive Summary Open source software has been used extensively by public organizations in the past twenty years. There is a huge body of evidence on this aspect, with a large amount of information and experience available both on successes and failures of open source software adoption. Following a generic trend favouring the use of open source worldwide, public organizations seek to develop strategies that encourage and regulate its use in the years to come. In the context of the EC, open source software strategies have been developed with the most recent one being the 2014-2017. The present study aims at developing a corpus of recommendations for the future EC open source software strategy in an informed way. The information used comes from (a) an analysis of the state of open source software worldwide, (b) feedback from EC internal stakeholders and (c) a thorough review of the 2014-2017 EC open source software strategy itself.
The study starts with the analysis of the state of open source software worldwide. The study reviews a number of selected countries, as it is impossible to provide a complete picture for the entire world. The countries examined are large EU countries, a sample of medium and small size EU countries, and one country per continent. Some additional countries have been added because of being very active in the field of open source software adoption. The study reviews the official government policies or strategies where they exist, the major open source software initiatives and landmark projects and a sample of recent (after 2014) significant cases. The study provides whatever evidence is available from trusted sources on the degree of success or failure of such projects or initiatives. A more in-depth analysis is performed for six cases, namely the development and implementation of open source policies by the governments of UK, France, Italy, USA, the Municipality of Athens and Google to provide more insight on different ways and mechanisms through which open source is adopted. The analysis of open source software worldwide adoption concludes with the identification of the strengths and weaknesses of its adoption by public organizations to provide ground for the recommendations that will follow.
Next, the 2014-2017 EC open source software strategy is examined with the purpose to (a) provide a review of its components, (b) compare it with recent strategies/policies and (c) check it against the weaknesses and strengths mentioned above. Particular emphasis is given to the commonalities and differences with the six organizations that have been examined in detail during the open source software worldwide analysis.
The study continues with the outcomes of the interviews with EC internal stakeholders. Interviewees have been chosen to represent all staff levels, from upper management to operational and technical staff. Interviewees were asked on their opinion on open source, their level of awareness of the 2014-2017 EC open source software strategy, the level of open source adoption and success within their units and their expectations for the future EC open source software strategy. The interview results provide a multi-faceted picture of open source adoption within the EC today. Of particular interest are the differing points of view on the extent and mechanics of adoption.
Based on the information collected in the previous stages, the study proceeds with compiling recommendations for the new EC open source strategy. The recommendations keep into account (a) the 2014-2017 EC open source software strategy, (b) the trends in open source software adoption that were identified in the open source software worldwide analysis and (c) the opinions and expectations of the EC internal stakeholders. Evidently, some compromises had to be made on some to address some possible conflicting inputs and interests. The degree of enforcement of open source adoption, new processes and ways of work, staff training and EC organization to successfully implement the new strategy were given special attention. Moreover, the basis for each recommendation has been explicitly traced back to the information that was collected in the previous stages. For each recommendation, the cases of countries or organizations where supporting evidence was found were pointed out, along with the interviewees who expressed a favourable opinion on the scope of the recommendation.
Study on open source software governance at the European Commission and selected other European Institutions Page 7
After having provided the recommendations on which it is suggested to base the future open source software strategy, the study continues with reporting a number of interviews with selected EU institutions and one private company, where the potential extension of the new strategy to other EU institutions was discussed. Interviewees were asked similar questions as with EC internal stakeholders, and the EU institutions representatives were also specifically asked whether they would be favourable to be included in an extended scope of the new strategy. Beyond collecting valuable information on open source software adoption in EU institutions, it was found that interviewed staff is eager to accept such strategy, provided that is not enforcing the mandatory adoption of open source at all levels and in all parts of their respective organisations. This evidence supports the extension of the new EC open source software strategy to other EU institutions as well.
The study concludes with a lessons learned section, which summarises the most salient features of the open source software policies worldwide, the trends in open source software adoption and what has been observed to lead to success or failures. In addition, the section reviews the most interesting opinions collected during the interviews and the lessons learned on open source software adoption within EC and other EU institutions up to now.
Study on open source software governance at the European Commission and selected other European Institutions Page 8
1. Open source software use worldwide
1.1.Introduction This chapter summarises the findings of the research done in this study on the status of use of open source software worldwide. Emphasis is given to the state of the art in public organizations and in particular in the context of EU member states.
It must be stressed that the scope of this study is extremely large: a similar study1 in 2010 identified 364 open source policy initiatives. Therefore, this study has rather started from the selection of a set of well-reputed sources and has considered the initiatives treated in such sources. In any case, the most significant cases are covered in the present study, especially those that are pertinent to its objectives2. In addition, the analysed sources do not report any study after 2014 providing concrete, hard evidence on the extent of use of open source software worldwide. Therefore, our analysis is based mainly on qualitative evidence.
The major sources for the present analysis have been:
1. official web sites reporting open source software policies, for example UK open source policy3;
2. The OSOR collection on the Joinup platform of the European Commission, reporting news on public sector open source software initiatives4;
3. publicly available surveys of open source software worldwide (e.g. Open source software governance at the European Commission5, OSOR Annual Report 20166);
4. scientific journal papers and papers presented at the annual Open Source Systems Conference that report useful information on public sector open source software initiatives7;
5. an Open Book by open source software experts8;
6. popular web pages that report open source software news, for example Bloomberg9;
7. open source software projects web sites reporting customer usage10;
8. direct communications of the project team with various open source software project members, through open source software networks11.
The rest of this chapter is structured as follows. Firstly, open source software policy initiatives enacted by public services worldwide are listed and discussed briefly. They are split between those pertinent to EU
1 Government open source policies, by Centre for Strategic and International Studies, https://www.csis.org/analysis/government- open-source-policies; reported in CSIS Updates Open Source Policy Survey, Open Source Initiative, https://opensource.org/node/549 2 As reported in the EU-FOSSA 2 Project Charter, see https://joinup.ec.europa.eu/sites/default/files/inline- files/Project%20Charter%20FOSSA%202%20v1.7_0.pdf Initiative 2, page 8 3UK government, https://www.gov.uk/guidance/be-open-and-use-open-source 4OSOR, https://joinup.ec.europa.eu/collection/open-source-observatory-osor 5Open source software governance at the European Commission, Deloitte study, 2014 6Open Source Observatory Annual Report 2016, https://joinup.ec.europa.eu/document/open-source-observatory-annual-report-2016 7 OSS 2018, https://www.oss2018.org/program/ 8Open source software: A Survey from 10,000 Feet, https://www.spinellis.gr/pubs/jrnl/2010-TOMS-OSS-Survey/html/ASKG10.pdf 9Russia weighs replacing IBM Microsoft with Open source software , https://www.bloomberg.com/news/articles/2016-10-05/russia- weighs-replacing-ibm-microsoft-with-open-source-software 10Alfresco, https://www.alfresco.com/customers 11FSFE legal network - https://fsfe.org/activities/ftf/ln.en.html and the FLOSS Foundations network https://flossfoundations.org/
Study on open source software governance at the European Commission and selected other European Institutions Page 9
member states and those pertinent to the rest of the world. Initiatives from private organisations are also discussed, while certain best practices, i.e. practices that are both innovative and reported to be successful, are exemplified. Some preliminary findings are given for worldwide open source software policy making, by way of a strengths/weaknesses analysis. Next, the selection of six organizations to analyse in detail is described. Criteria for selecting the six organizations are given, and eventually the justification for selecting such organizations is provided. There follows the detailed description and analysis of the open source software policies of the six analysed organizations and their results. Conclusions are drawn at the end of the chapter, paving the way for the subsequent activities in the context of this study. 1.2.Open source software policies/initiatives worldwide In this section we will list and discuss the most salient open source software policies worldwide by analysing a sample of 16 countries, designed to represent adequate diversity in geographical terms while covering the most significant experiences in the implementation of such policies. In particular, we will first see such policies in the context of EU public services and then proceed with the rest of the world. We aimed at a sample of countries that would consist of (a) major EU countries, (b) a collection of medium-small size EU countries and (c) one country for each of the other continents. For Asia, one further country, namely Malaysia, was included because of the special efforts it has put in place to support the adoption of open source software. The 16 countries have been selected based on one or more of the following criteria:
leading role in information technology;
release of open source software policies in the past few years;
noteworthy news about open source software adoption or rebuttal;
legacy related to open source software initiatives;
size and population;
inclusion in previous similar studies.
Some significant open source software policies implemented in large private companies and certain best practices identified will also be reported and reviewed.
The organizations that are treated in more detail through dedicated factsheets later in the document (Section 1.4.4.) are presented in the following paragraphs as well.
1.2.1.EU public services policies
In general, most EU public services have launched initiatives promoting the use of open source software. Diverse approaches may be observed, concerning the level and scope of such interventions, the commitment of issuing authorities, the amount of funding, and ultimately the level of their success.
United Kingdom
The UK is one case where the central government strongly supports the use of open source software. In particular, the UK government has formally released in 2017 an official guidance document with guidelines
Study on open source software governance at the European Commission and selected other European Institutions Page 10
and recommendations for the use of open source software12 (for example “How using open source will help your programme” or “Publishing code”).
This formal support of open source software is the result of a long series of high-level interventions, starting in 2004, when a concrete policy regarding open source software use was released. This policy was updated in 2009 to overcome issues encountered during its implementation, mainly related to lack of transparency. The revised strategy explicitly asks suppliers to provide evidence that they have considered open source software in their offerings. In 2010 the Government released an Action Plan13 to implement the strategy consisting of the following ten points:
clarity in procurement;
increasing capability within Government;
re-use as a practical principle;
maturity and sustainability;
supplier challenge;
international examples and policies, and keeping up to date with developments;
industry / government joint working;
open standards;
open source techniques and re-use within government, and appropriate release of code;
communication, consultation and review. In addition, a CIO Council, bringing together CIOs from across all parts of the public sector, has been established to empower the use of open source software in the UK.
Nevertheless, a study commissioned by the UK Cabinet Office to the London School of Economics adopted a more realistic point of view and reported that ‘migrating to open source is more likely to be successful if it is done when there is a real and present need for change or a new approach14’.
More recently, the Government Transformation Strategy 2017-202015, after stating that the UK Government is the most digitally advanced in the world according to a recent United Nations survey16, reports many cases of successful openings of source code and government data, establishing open standards, creating a culture of open policy-making and service delivery, embedding open approaches in procurement, contribution to
12UK guidelines for using open source, published 6 November 2017: https://www.gov.uk/guidance/be-open-and-use-open-source 13 Open Source, Open Standards and ReUse: Government Action Plan, https://assets.publishing.service.gov.uk /government/uploads/system/uploads/attachment_data/file/61962/open_source.pdf 14Total Cost of Ownership of Open Source Software, Maha Shaikh & Tony Cornford, London School of Economics, 2011, http://eprints.lse.ac.uk/39826/1/Total_cost_of_ownership_of_open_source_software_(LSERO).pdf 15Government transformation strategy, https://assets.publishing.service.gov.uk/government/uploads/system/uploads/ attachment_data/file/590199/Government_Transformation_Strategy.pdf 16See https://publicadministration.un.org/egovkb/en-us/Reports/UN-E-Government-Survey-2016
Study on open source software governance at the European Commission and selected other European Institutions Page 11
open source communities and so on. In 2018, the ‘Be open and use open source’ guidance mentioned above became part of the Cross-Government Transformation Programme17.
Finally, various open source software associations or centres of competence exist in the UK, including the UK Open Source Industry Association18, FLOSS UK19, Open Forum Europe20 and Community for Open Interoperability Standards21.
Specific UK public service areas that report benefits from the use of open source software are:
various government departments;
national health care system;
education (e.g. secondary schools);
municipalities (e.g. Birmingham, Yorkshire);
private IT industry (both small and large companies).
UK policies will be further analysed in Section 1.4.3.
France
The French government has been supporting the use of open source software since 2001. Efforts started in November 2001 with the creation of the Agency for the Development of the Electronic Administration (ADEA), formerly the Agency for Technologies of Information and Communication in Administration (ATICA), being ‘in charge of selecting open standards to be enforced all over public services in order to guarantee full interoperability’22.
In 2002, it was proposed to increase Open source software usage in order to support and give more development chances to French software industries (this aspect is also very strong in at least another country included in the present study, namely India). The ADULLACT (Association des Développeurs et Utilisateurs de Logiciels Libres pour les Administrations et les Collectivités Territoriales – Association of developers and users of open source software for administrations and territorial collectivities) organization was established in 2002, aiming at the promotion, development and maintenance of open source software for public services.23. Reuse is of particular importance to ADULLACT and the basic concept behind that is that ‘public money must be paid just once!’. ADULLACT is particularly active in the field and releases many FOSS products via their forges (FusionForge and, more recently, GitLab24). As of February 2019, 260 business Open source software applications were provided by the ‘compteur’ section on the ADULLACT platform.
17 UK Cross-Government Transformation Programme, https://www.gov.uk/government/collections/the-cross-government- transformation-programme#guidance-and-tools 18UK Open Source Industry Association, https://openuk.uk/ 19 FLOSS UK, https://www.flossuk.org/ 20 Open Forum Europe, http://www.openforumeurope.org/about-ofe/ 21 Community for Open Interoperability Standards, http://cois.org.uk/ 22 http://linuxtoday.com/developer/2001112102120PRLL 23ADULLACT, French platform for public sector FOSS, https://adullact.org/ 24GITLAB, https://gitlab.adullact.net/
Study on open source software governance at the European Commission and selected other European Institutions Page 12
In 2003, France increased the use of open source software operating systems in various ministries and developed an open source content management system to standardize government websites.
In 2004, the Ministry of Defense has formed a consortium to develop a highly secure Linux-based operating system. However, a bill of the Ministry of Culture and Communication did not succeed eventually in funding a full migration to open source software in 2005. Nevertheless in 2008 the French Gendarmerie decided to migrate all its 70,000 desktops from proprietary software to open source software, recognizing the security advantages and the lower Total Cost of Ownership of Open source software. The Agency for the Development of the Electronic Administration (ADEA) migrated approximately 10% of public service desktops to open source software by 2007. Further decisions were made to increase open source software usage in the public finance and education sectors. In 2009 the first version of the RGI (Référentiel Général d'Interopérabilité) was released25. This document provided a framework, guidelines and a collection of standards that favor the interoperability of public information systems.
In 2011, the former DSI (Direction des Systèmes d'Information) was transformed into DISIC (Direction Interministérielle des Systèmes d'Information et de Communication). In parallel, the Etalab26 had been established under the government’s Secretary General, to promote the concepts of open data and open government in France. In 2015, DISIC was merged with Etalab to form DINSIC (Direction Interministérielle du Numérique et du Système d'Information)27. DINSIC is today the government agency that promotes the use of open source software within French public sector.
In 2012, the “Circulaire Ayrault” (so-called from Jean-Marc Ayrault, then prime minister)28, encouraged the public services to actively participate in the development of open source software that the country depended upon. The Circulaire identified five inter-ministry groups in the context of the “Direction Interministerielle des Systemes d'Information et de Communication”, for managing open activities and sharing knowledge. The groups established are:
a ‘core’ group for making proposals, validating decisions and steering activities related to markets, software catalogues and implementations of directives act open source software the French public sector;
mimO: inter-ministerial group for an open government;
mimOG: inter-ministerial group for managing OCS and GLPI tools;
mimBD: inter-ministerial group for databases;
mimOS: inter-ministerial group for operating systems.
25RGI V1, http://references.modernisation.gouv.fr/sites/default/files/RGI_Version1%200.pdf 26 Etalab, http://www.etalab.gouv.fr/en/ 27DINSIC, https://www.numerique.gouv.fr/dinsic/ 28Circulaire Ayrault, http://circulaire.legifrance.gouv.fr/pdf/2012/09/cir_35837.pdf
Study on open source software governance at the European Commission and selected other European Institutions Page 13
In 2015, mimO, one of the five groups mentioned above, released SILL (Socle Interministériel de Logiciels Libres), a long list of open source software solutions recommended for the French public services29. The SILL list is updated annually30.
In 2016, the French law for the ‘République Numérique’ reinforced both the use of Open source software and the opening of code produced by French public services. In the same year, France’s Rhône-Alpes region prioritised open source software, as reported on OSOR31. In 2016, France hosted and chaired the Open Government Partnership (OGP) for the period 2016-207, after becoming a partner in 2015, while Paris hosted the OGP Summit in 2016. France is particularly active in this regard, with 29 OGP commitments completed. As of May 2019, 22 OGP commitments were active32. In the same year, the second version of the RGI has been released33.
As part of OGP, France led a working group with several national and international FOSS stakeholders aimed at developing a country-level policy detailing how civil servants can release and contribute to open source software projects. The policy has been officially adopted in February 2018.34
In addition, the French government ‘is building its own open source developer community, aiming to bring together software developers and IT scientists who want to contribute to government-led open source projects’35. This initiative is named ‘Blue Hats’ and was presented at the Paris Open Source Summit in Dec 2018. Moreover, France hosted the B-BOOST 2018 event in Bordeaux, aiming at accelerating the development of the Open source software industry36.
According to a Forrester Research in 2015, France was a leader of Open source software adoption in Europe, with 24% of companies having adopted open source software (21% in Germany, 17% in U.S.). In addition, the French National Council (CNNL) announced in 7 Dec. 2018 that it expects that job positions in open source software in France will raise to 70,000 by 2021. In the period 2017-2021, open source jobs are expected to increase annually by 6.2% on average37.
In summary, France is an example of long-term country-wide commitment to the adoption and development of FOSS. By further iterations across several decades the country has ramped up not only its actual use and development of FOSS, but also its mastering of best practices, its participation in the international FOSS community, and its efforts to nurture an ecosystem of national FOSS actors, citizens and companies alike.
France’s policies will be further analysed in Section 1.4.4.
29Socle Interministériel de Logiciels Libres, https://references.modernisation.gouv.fr/sites/default/files/SILL-2016-socle- interministeriel-logiciels-libres.pdf 30SILL-2019, https://disic.github.io/sill/2019/sill-2019.pdf 31France’s Rhône-Alpes region prioritises free software, https://joinup.ec.europa.eu/document/frances-rhone-alpes-region- prioritises-free-software 32France OGP commitments, https://www.opengovpartnership.org/countries/france 33RGI V2, http://references.modernisation.gouv.fr/sites/default/files/Referentiel_General_Interoperabilite_V2.pdf 34“Politique de contribution aux logiciels libres de l’État” (state policy for FOSS contribution) https://www.numerique.gouv.fr/publications/politique-logiciel-libre/, collaboratively developed on GitHub at https://github.com/DISIC/politique-de-contribution-open-source 35 Joinup, https://joinup.ec.europa.eu/news/les-blue-hats 36Boost 2018, https://b-boost.fr/en/ 37CNLL presentation at Paris Open Source Summit, job market study (7 Dec 2018), https://cnll.fr/media/enquete-cnll-2018-marche- travail-open-source.pdf
Study on open source software governance at the European Commission and selected other European Institutions Page 14
Italy
Italy started looking at open source software in 2001 when the Council of Ministers endorsed a recommendation by the Senate that urged the government ‘to draft regulations for the examination of open source projects and for the progressive adoption of non-proprietary operating systems and applications by public services’38.
In 2002, the Ministry for Innovation presented a set of Government Guidelines for the promotion of technological development (2002-2005). The document called for the adoption of open source software by public services. The guidelines also recommended that the government launch a national research program on open source39.
In 2003, based on a preliminary survey on open source software adoption in the public services40 by the Ministry of Innovation and Technologies (headed by MP L. Stanca), the Italian government published the first directive on “Development and use of informatics programme by the public services41”. The main topics of the “Stanca Directive” were the following:
The public services purchase of informatics programmes must be based on a technical and economic comparative evaluation of the market solutions;
The public services, in the procurement of informatics programme, must prefer interoperable solutions;
The systems must be non-dependant from a sole provider.
The directive was later translated into D. Lgs. 82/05 (Code of Digital Administration42 and in particular art. 68 and 69), which required that any software developed by one public service must be made available at no cost, with complete source code and documentation, to any other public service that can adapt it to its own needs.
In 2007, following a ministerial decree sponsored by the Minister for reforms and innovation in public services Luigi Nicolais43, an open Source Commission is formed with three main objectives:
analysis of the European and Italian open source sector;
definition of the operational guidelines for supporting public services in open source software procurement;
38“Emendamento n. 9.4885.564 (già emm. 50.0.1000 e 50.0.1001)”, Senato della Repubblica, 2000, http://www.senato.it/leg/13/resaula/input/00000981.htm 39“Linee guida del Governo per lo sviluppo della Società dell’Informazione nella legislatura”, Ministero per l’Innovazione e le Tecnologie, 2002 http://www.interlex.it/testi/pdf/lineeguida.pdf 40“Indagine conoscitiva sul software a codice sorgente aperto nella Pubblica Amministrazione” http://www.edscuola.it/archivio/software/open_software_pa.pdf 41Direttiva 19 Dicembre 2003, Sviluppo ed utilizzazione dei programmi informatici da parte delle pubbliche amministrazioni http://www.interlex.it/testi/dirett_os.htm 42Codice Amministrazione Digitale, https://www.agid.gov.it/it/agenzia/strategia-quadro-normativo/codice-amministrazione- digitale 43Decreto 16 maggio 2007 “Istituzione della Commissione per il software a codice sorgente aperto – “open source” nella Pubblica Amministrazione, http://www.asmenetcampania.it/images/documenti/decreto16maggio07.pdf
Study on open source software governance at the European Commission and selected other European Institutions Page 15
analysis of the open source approach to promote interoperability and reuse.
Of particular interest is the 2007 budget law44 allocation of 30 million euros (over three years, 2007 – 2009) to ICT projects, giving priority to open source software projects. Open source software usage in education had also been supported by the Ministry of Education in various occasions.
Detailed guidelines and methodologies for software evaluation are provided by the circular 63/201345 issued by Agenzia per l'Italia Digitale (AgID, a technical agency of the Council of Ministers), which specified and prioritised the parameters for the software procurement by public services. The circular suggested, as a first choice, the provisioning of free and open source solutions, where the buyer receives the copy of the pertinent source code.
The law n. 124 of 7 August 201546 promoted in the art. 1 the open source usage in order to optimise ICT expenditure, while keeping into account technical and economical evaluation and energy saving as well.
In 2015, the Ministry of Defence47 launched “LibreDifesa”, the most important Italian project related to the adoption of open source software. 150.000 desktops migrated to LibreOffice and the open Document Format was adopted as document standard in order to guarantee interoperability and security in the exchange of documents.
Most recently AgID, in collaboration with the Digital team (set-up by the Prime Minister in 2016 with the aim of modernising the Italian public services through the adoption of Innovative Digital tools and products in an open-source view), has produced a detailed guide on the procurement and reuse of software for the Italian public services48 (July 2018). The guidelines define a decision process that considers and prioritizes open source software in all its stages.
In May 2019 the Team Digitale has announced that the open source guidelines are in force. In addition, in June 2019 it announced it would work with the court of auditors: public services that fail to share code are considered to be damaging others for not being able to reuse that application. Non-compliance with the law will result in penalties since not sharing the code with other public services means obstructing cost saving.
Italy is an example of a country where the preference for open source software in public services scaled up from initial recommendations to strong endorsement through specific regulatory framework by the central authorities and intense, funded support. The Italian Digital Agency contributed in a strong way through the enforcement of the rules and strict. Italy policies will be further analysed in Section 1.4.3.
Spain
Spain is a country that has been supporting open source software for almost 20 years. Two early initiatives to establish full preference for open source software had been tried but with not much success. As early as 1999, the Ministry of Public Administration tried to fully migrate to open source software, but this project
44 Finanziaria 2007, https://www.altalex.com/documents/news/2011/01/18/finanziaria-2007-interventi-per-lo-sviluppo-e-la-ricerca 45Linee guida per la valutazione comparativa prevista dall’art. 68 del D.Lgs. 7 marzo 2005, n. 82 “Codice dell’Amministrazione digitale”, https://www.agid.gov.it/sites/default/files/repository_files/documentazione/circolare_agid_63- 2013_linee_guida_art_68_del_cad_ver_13_b_0.pdf 46LEGGE 7 agosto 2015, n. 124, http://www.gazzettaufficiale.it/eli/id/2015/08/13/15G00138/sg 47Forum PA, “Al Ministero della Difesa il più grande progetto italiano di migrazione a software open source”, https://www.forumpa.it/pa-digitale/al-ministero-della-difesa-il-piu-grande-progetto-italiano-di-migrazione-a-software-open- source/ 48Linee Guida su acquisizione e riuso di software per le pubbliche amministrazioni, https://lg-acquisizione-e-riuso-software-per-la- pa.readthedocs.io/it/latest/
Study on open source software governance at the European Commission and selected other European Institutions Page 16
seems to have been abandoned. In addition, in the time frame from 2002 to 2005 it was proposed, without success, to render all public services web sites, software and documents compatible with Linux and that all regional governments prefer open source software and promote its development.
Notwithstanding those initial failed attempts, Spain has been consistently supporting open source software at the highest level since 2003 with legislative efforts, recommending open source software whenever possible. In 2006, 12 million euros were allocated to open source software research projects and in 2007, a nearly unanimous resolution in the Parliament promoted the use of open source software in public services and the right and need to reuse software among public services. In the same year, the Spanish government created the Technology Transfer Centre (Centro de Transferencia de Tecnología - CTT)49, a portal for sharing and reusing technical solutions that develop e-administration.
In 2007, a law that gave the right to citizens to electronically access public services was passed50. Beyond moving towards e-government, the law prompted technological neutrality, giving the right to both the public services and the citizens to decide their own technological option.
Real Decreto 4 and Ley 40 in 2010 and 2015 respectively defined the national scheme for interoperability in the context of Spanish e-government, asking public services to consider reusing CTT-offered solutions and release their own developed software with an open license. Implementing such legal mandates, CTT facilitates the storage and reuse of solutions for all Spanish public services, offering a repository of such solutions and fostering the creation of communities. CTT has its own project area in GitHub; EUPL is the preferred license for such projects51.
Spain provides many examples of open source software adoption by regional/local authorities, e.g. the regions of Extremadura, Castilla-La Mancha, Galicia, the Basque Country, and the Cities of Valencia, Barcelona, Hospitalet. As an example, the City of Barcelona decided to break ties with Microsoft software52 and is in is in the process of migrating its computer system to open source technologies. Open source software initiatives and open government initiatives are combined in the cities of Madrid and Barcelona, according to a research report53. Moreover, Madrid has recently released (2018) Consul, an open source software citizen participation platform that is used by various European cities54.
Several open source software Centres of Excellence may be found in Spain. CENATIC is the country’s national reference centre for the application of open ICT principles and technologies, established in the form of a foundation in 200655 and depending since 2013 from Red.es, a public corporate entity that develops programmes to stimulate the digital economy. As another example, the region of Castilla-La Mancha established a Centre of Excellence for open source software, which in 2012 evolved into a Technology
49Centro de Transferencia de Tecnología – CTT, https://administracionelectronica.gob.es/ctt/CTTprincipalEs.htm?urlMagnolia=/ pae_Home/pae_SolucionesCTT.html#.XG7LEaIzZnQ 50Electronic Access Of Citizens To Public Services Law, https://www.boe.es/buscar/doc.php?id=BOE-A-2007-12352 51CTT GitHub Project Space, https://github.com/ctt-gob-es 52El Pais, 1 December 2017, https://elpais.com/ccaa/2017/12/01/catalunya/1512145439_132556.html 53Citizen Participation And The Rise Of The Open Source City In Spain, https://opendocs.ids.ac.uk/opendocs/bitstream/handle/123456789/13006/Research-Brief-Spain.pdf 54European cities reuse Madrid’s open source citizen participation solution, https://joinup.ec.europa.eu/news/open-discussion 55CENATIC, Spanish Centre of Reference for Open ICT, https://www.red.es/redes/es/que-hacemos/fuentes-abiertas-y-soluciones- reutilizables
Study on open source software governance at the European Commission and selected other European Institutions Page 17
Support Centre56. Finally, two particularly active business associations are present, namely ASOLIF and ESLE (in the Basque Country).
In an interview with the Free Software Foundation Europe (FSFE), Elena Muñoz Salinero, head of CTT, provides an overview of the use of free/open source software in Spain57. She states that ‘free software is not just a growing topic in Spanish administrative culture but a consolidated fact’. However, she also mentions that ‘there is still needed a major cultural change: bear in mind, from scratch, that the software developed should be reusable in the future’ in order to facilitate its reuse. Software currently offered for reuse is typically extensive and customized to the specific needs and characteristics of the administration that produced it.
Spain is a country that has chosen to privilege open source as a vehicle of open e-government and software reuse within its public sector. Despite problems have been encountered in the course of this migration, it is evident that the whole country, both at a central government and at the regional/municipal level, is gradually adopting open source. The country works towards not only a technical, but also a cultural shift, aiming at establishing a reuse mind-set.
Germany
In Germany there is no official government policy on open source. However, along the last years several initiatives were taken to foster the use of open source software in public services. For example, the Bundestag adopted in 2002 a resolution named ‘Creating an Information Society for All’ that called for increased use of open source software, acknowledging that 'open source is an important instrument that can provide for secure and stable IT solutions.' The resolution was backed by the Social Democrats, then the ruling party, and governmental contracts were signed with open source software providers. However, in 2003 the federal Ministry of Economy decided to stop preferring open source software and foster instead the competition with commercial software. This Ministry relied on an independent body of experts that would define the criteria for public procurement tenders. In the same year, the Ministry of the Interior released guidelines for open source software adoption.
In 2002, the Federal Government also published the “Standards and Architectures for eGovernment Applications” (SAGA), whose version 5 was adopted by the IT Council on 3 November 2011. As mentioned by the ISA2 study on German eGovernment58, SAGA 5 is a mandatory technology catalogue for all software systems of the German federal administration. Technologies must be chosen according to the classifications in SAGA in all software projects. Goals of SAGA are the reduction of risks and investment-safe developments as well as agility, security, interoperability, reusability and scalability for software systems.
Looking at examples of open source software adoption in the public sector, the German Foreign Office became the “cheapest” ministry from an IT spending point of view, with open source software being deployed on 11000 IT workstations around the world since 2002. MS Windows was used in virtual containers to avoid security issues59. However, in 2014 the German Foreign Office switched back to MS Windows and MS Office. In the same year, the German Federal Employment Office migrated 13000 workstations to openSuse. Richter et al. reported also a high penetration rate of open source software among private
56BILIB, https://www.bilib.es/ 57Elena Muñoz Salinero FSFE Interview in 2018, https://fsfe.org/news/2018/news-20180601-01.en.html 58 ISA2 eGovernment in Germany study, https://joinup.ec.europa.eu/sites/default/files/inline- files/eGovernment_in_Germany%20_March_2017_v2_00.pdf 59A Comparative Analysis of open source software Usage in Germany, Brazil, and India, Dominik Richter, Hangjung Zo, Michael Maruschke, Fourth International Conference on Computer Sciences and Convergence Information Technology, ICCIT '09, 2009
Study on open source software governance at the European Commission and selected other European Institutions Page 18
companies in Germany (higher than in UK or U.S) and concluded that, compared to two developing economy countries (namely Brazil and India), in Germany ‘mainly different local administrations have shown clear preference in using open source software’ and that ‘has yet only been small, but successful progress’.
Indeed, various local administrations have migrated or considered migrating to open source software (including Leipzig, Gummersbach, Isernhagen, Schwäbisch Hall and Treuchtlingen). However, not all cases were successful, for example the City of Freiburg did not adopt openOffice because of the cost of resolving the interoperability issues that would have emerged60.
In 2009, the Federal Agency for Information Technology recommended the open source collaboration suite Kolab to all public administrations. In that period, the LIMUX project (2005-2013) was already started by the City of Munich61. After many years of efforts, the Limux migration project was completed. However, the City of Munich is now in the process of falling back to Microsoft technology in order to achieve IT centralization, a decision made by a new administration. Another German state, namely Lower Saxony, also plans to switch back its tax office computers to MS Windows from Linux62. However, in a recent joint digital conference (2016), Germany and France governments officially stated that their software industry should extract the maximum possible profit from open source software63.
Germany's federal government adopted Nextcloud (a fork of openCloud) for their collaboration system for 300,000 government users in 2016. In late 2018, it was reported that the Ministry for Social Affairs and Integration in Hesse will be funding an open source smartphone application for patients to avoid queues when waiting for medical services64. Previously (2015) the University Hospital of the German city of Freiburg used ResearchKit, an open source app by Apple, to encourage users of smartphones and tablet PCs to share data that would help to improve treatments65. In early 2019, the public works department of Bad Oeynhausen (North Rhine-Westphalia) announced to have signed a support contract for their QGIS open source geographic information system for managing their geographic data. The data centre of the department uses open source software since 2002, and QGIS since 200966.
Even in absence of an official open source government policy, various success stories of open source adoption have been reported. However, there are also failed attempts at all administration levels, including large scale migration projects to Linux. Up to date analyses provide controversial results, either pointing to wrong managerial/technical decisions or political rivalries that affected the outcome. Nevertheless, Germany provides a lot of useful empirical evidence on the subject matter, and careful analysis may help future open source adopters avoiding pitfalls and wrong approaches to open source.
60Techrepublic, “It's not just Munich: Open source gains new ground in Germany”, https://www.techrepublic.com/blog/european- technology/its-not-just-munich-open-source-gains-new-ground-in-germany/ 61The rise and fall of Limux, M. Kirschner, Open Source Summit 2017, https://lwn.net/Articles/737818/ 62Another German state plans switch back from Linux to Windows, https://www.theregister.co.uk/2018/07/27/ lower_saxony_to_dump_linux/ 63Industry in France and Germany should embrace open source, https://joinup.ec.europa.eu/news/france-germany-promote-open 64Germany’s Hesse funds open source eHealth app, https://joinup.ec.europa.eu/news/no-more-waiting-doctor 65 ISA2 eGovernment in Germany study, https://joinup.ec.europa.eu/sites/default/files/inline-files/eGovernment_in_Germany% 20_March_2017_v2_00.pdf 66German municipalities attracted by open source GIS, https://joinup.ec.europa.eu/news/qgis-and-openstreetmap
Study on open source software governance at the European Commission and selected other European Institutions Page 19
The Netherlands
The Netherlands started considering open source software in 2003, with the parliament adopting a plan for the exclusive use of open standards and promotion of open source software in the public sector. A milestone was set to year 2007 for the implementation of the program, when indeed ten major Dutch cities signed the Manifesto of the open Cities67. In 2009, it was requested to all ministries to use open source software, or at least provide reasoning for not doing so. In the same year the Dutch Police started investigating the use of open source software on its computers. The Standardization Forum, an entity established in 2006 by ministerial decree to ensure implementation of the policy on electronic data exchange and (re) use of data and electronic services, supports actively the adoption of open standards throughout the public sector of the Netherlands68.
In 2015 it was reported69 that in about three out of four cases, open standards were requested by Dutch public services during software procurement. Nevertheless, it was observed that use of ODF was not required by the public services. The cities of Amsterdam, Nijmegen and Rotterdam re-confirmed their preference for open standards, pointing to the Standardization Forum mentioned above for directives. ‘Apply or Explain’ is one of them70. In addition, software vendors are requested to possess adequate open source software know- how and include open source software solutions in their offerings.
The Netherlands provide yet another example of a country that wishes to adopt open source and open standards wherever possible. The success rate is somewhat slower than expected, showing that often the open source/standard policies are over-optimistic about the targets they set and that the path to open source may be longer than anticipated. One barrier identified is the misinterpretation of the existing legal framework71. Nevertheless, the country has laid the foundations for a public IT approach that favours open source and open standards, and many bottom-up examples of successful open source projects exist.
Denmark
In 2002, the Danish Board of Technology released an analysis and recommendations document about ‘open source software in e-government’72. Following a decision of the Danish Parliament in 2006, in 2009 the use of open Document Format on all government computers was tried experimentally. More recently, the Digital Strategy 2016-2020 supports explicitly sharing and reuse of public data, while the sharing and reuse of ‘principles and methods’ developed by local authorities is also emphasized, without explicitly mentioning the opening of source code73. However, the open Government Partnership National Action Plan 2017-2019 explicitly states that ‘Municipal and regional data is made open and freely available on a shared data platform
67Manifesto of Open Cities, in Dutch, http://www.ososs.nl/page/208/ 68Dutch Standardization Forum, https://www.forumstandaardisatie.nl/ 69Annual Report 2016, https://joinup.ec.europa.eu/document/open-source-observatory-annual-report-2016 70Apply or Explain Directive, in Dutch, https://www.forumstandaardisatie.nl/thema/toepassen-van-pas-toe-leg-uit, https://joinup.ec.europa.eu/news/not-having-choose 71Netherlands lagging transition to open government, https://joinup.ec.europa.eu/news/netherlands-lagging-trans 72 Open Source in e-government, Danish Board of Technology http://www.tekno.dk/wp- content/uploads/2017/10/p03_opensource_paper_english.pdf 73Denmark Digital Strategy, https://en.digst.dk/media/14143/ds_singlepage_uk_web.pdf
Study on open source software governance at the European Commission and selected other European Institutions Page 20
(open source) so that it can be easily accessed and used as raw material in the development of applications and services, or serve as the foundation for analyses, trend assessments and research74.
In 2009, the Danish public libraries created the TING community, developing web services on Drupal. Later, in 2015, around half of the Danish public libraries joined forces to develop open source solutions75. In the meantime, the OS2 Community was formed by five municipalities to ‘specify, develop and govern digital solutions by municipalities and for municipalities’76. Interestingly, OS2 has also private companies as partners, and both public members and private partners ‘collaborate on creating the best possible digital solutions’. In 2017, it was reported that OS2 consisted of 56 out of 98 Danish municipalities. IT portfolio management system was the most OS2 popular product, used by 75 of the 98 municipalities77.
Another initiative was announced by the Municipality of Aarhus in terms of its open Source Action Plan in 2014, aiming to increase the use of open source software and open standards to free itself from IT vendors lock-in. The reason for seeking stronger open source software adoption was ‘the increased popularity of open source software that required an explicit strategy’78.
Denmark is another country that openly favours open source at various administration levels. An interesting factor here is the collaborative approach between public and private entities for achieving high quality open software solutions.
Sweden
Sweden lacks a clear legislative framework for open source software. In the period from 2003 to 2005, two initiatives in Sweden tried to foster open source software adoption. The Agency for Public Management released a study recommending the treatment of open source software on an equal basis with commercial software in public procurement. The Swedish Association of Local Authorities and Regions initiated a program to assist public services in adopting open source software or migrating to open source software.
In 2009 Kivos, a cooperative network founded by nine municipalities, recognized that closed MS format use is prohibiting municipalities to migrate to openOffice. Kivos asked ten Swedish software suppliers to support ODF and PDF formats. The same source reports that ‘In November 2012, Vinnova (the Swedish Government Agency for Innovation Systems) invested € 380,000 in the development of a platform for public e-services’. Another similar network, namely Sambruk, adopted the well-known FixMyStreet open source solution in 2013, and offered it in SaaS terms79.
In 2006 public procurement was moved from the Agency for Public Management to the Swedish National Procurement Services, the central purchasing body for the country’s public sector. In 2015 a procurement framework facilitating decision makers in selecting open source software solutions was prepared80. This new framework was based on previous work by Verva, another organisation caring for public procurement,
74Open Government partnership, https://en.digst.dk/media/14142/ogphandlingsplan-20172019-engelsk.pdf 75Danish public libraries unite around open source, https://joinup.ec.europa.eu/news/danish-public-libraries-unite 76OS2 Danish Community, https://os2.eu/node/332 77“Danish OS2 community for open source is professionalising”, https://joinup.ec.europa.eu/news/danish-os2-community-open 78“Danish Municipality of Aarhus aims to free itself from IT vendor lock-in (Aarhus Open Source Action Plan)”, https://joinup.ec.europa.eu/document/danish-municipality-aarhus-aims-free-itself-it-vendor-lock-aarhus-open-source-action-plan 79“Swedish public open source movement working from the bottom up”, https://joinup.ec.europa.eu/document/swedish-public-open- source-movement-working-bottom 80“Sweden to boost open source through procurement”, https://joinup.ec.europa.eu/news/sweden-boost-open-source-t
Study on open source software governance at the European Commission and selected other European Institutions Page 21
prepared in 2007. In a more recent open source software initiative, the PIKE INTERREG project formed the basis for RIGES project that produced an open ePlatform, an open platform for building digital government services81. Open source software in Sweden is promoted by Open Source Sweden, an ‘industry association that supports the interests of Swedish open source companies’ with the mission ‘to stimulate a healthy market for software through the development, provision, and support of products and services based on open source software and open standards’82. In 2017, IT experts released a report claiming that the country’s data centres are costly and poorly performing (e.g. in terms of procurement). They advised to reduce their number and turn them to run on open source software83. In May 2018 Vinnova awarded a grant of approx. € 225,000 to FOSSID, a company providing a database for scanning open source code and snippets, showing the interest of Swedish government for advanced solutions to open source software auditing84.From the cases presented above, it is evident that public open source initiatives often originate in a bottom-up fashion in Sweden. In absence of an official government open source policy, various attempts are reported to adopt open source that are based on a collaborative approach that has been developed at a municipality level. Sweden’s example shows the importance of a cultural paradigm that promotes and exploits co-making and sharing among public administrations. In this creative environment, government procurement regulations and funding come to support such projects.
Malta
In 2012, an open source software policy85 was released with the intention to ‘cover the procurement of open source software and the adoption of related open source business models throughout the public sector to facilitate reuse of Government procured software’. The directive requires among other that open source software be treated ‘on the same merits’ with other solutions and that open source software solutions provided on OSOR should be exploited as much as possible for government procurements. However, only internationalized open source software should be considered, i.e. supporting two languages, English being mandatory. EUPL is the preferred license for government software reuse. Open source software solutions that are already successfully used by government must be given priority, and other choices must be adequately justified. Public sector organisation CIOs are explicitly assigned the responsibility for applying the directive.
The country’s national IT strategy 2014-2020 emphasizes the need and importance for open standards and considers the lack of participation in open source software communities as a factor that reduces the IT capabilities of Malta86. Malta Information Technology Agency has established an internal open source software user group, namely open source software Communities, ‘in order to support the implementation
81Open ePlatform: an open platform for building digital government services, https://joinup.ec.europa.eu/document/open-eplatform- open-platform-building-digital-government-services-open-eplatform 82Open Source Sweden, http://opensourcesweden.org/mission 83“Experts: ‘Swedish govt. cloud should use open source’”, https://joinup.ec.europa.eu/news/experts-swedish-govt-cloud 84FOSSID Awarded Grant for Artificial Intelligence in Open Source Auditing by Sweden's Government Agency for Innovation, https://www.prnewswire.com/news-releases/fossid-awarded-grant-for-artificial-intelligence-in-open-source-auditing-by-swedens- government-agency-for-innovation-300654511.html 85 Malta Open source software Directive, https://www.mita.gov.mt/MediaCenter/PDFs/1_GMICT_D_0097_Open_ Source_Software_v3.0.pdf 86OSOR annual report 2016, https://joinup.ec.europa.eu/sites/default/files/inline-files/open_source_observatory_ annual_report_2.pdf
Study on open source software governance at the European Commission and selected other European Institutions Page 22
of the Open Source Vision’87. In addition, OSSMalta, the Open Source Society of Malta, is actively supporting open source software in the country88.
Malta is an example showing that even small European countries have expressed their interest in open source and are trying to implement open source in their public services’ IT systems.
Greece
In Greece there is no legislative framework or policy that clearly supports open source software use. However, there are many local or regional initiatives to adopt open source software. For example, because of the financial crisis, a lot of municipalities migrated their office automation software from MS-Office to LibreOffice after 2010. However, personnel experienced problems due to insufficient or non-existing training, and incompatibility with legacy templates and legacy applications of government. At least one municipality had to buy new MS-Office licenses after migrating to LibreOffice89.
Regional authorities too are using open source software in their infrastructure (e.g. for network management in the Region of Central Macedonia, or for system integration in the Region of Western Macedonia). In another interesting case, an attempt to acquire only open source software solutions for the schools of the Region of North Aegean was met by a strong protest by the Association of Greek ICT Companies, asking for commercial software to be eligible for the tender. In an interesting large-scale initiative, the Greek Network for Research and Technology, supported by open source software, the Greek Open Technology Organization90, funded the establishment of nine Centres of Excellence in various Universities and research centres in 2014 and 2015. After the end of the project such centres have been run based on the voluntary contribution of University staff and students. The Ministry of Education has established a programmers’ team that applies agile methods to use and produce open source solutions with the help of open source software. Among the educational institutions, the Aristotle University of Thessaloniki has started using Alfresco for their electronic document management since 2017, not without problems.
The municipalities of Athens and Heraklion excel in the use of open source software in different application areas. In particular, Athens, which is the largest municipality in Greece, has a long ICT tradition, having established its own ICT Company. Athens has adopted open source software in various areas, such as process modelling, document management, geospatial data management and identity management. They use BonitaSoft and Alfresco for the former two applications, recognizing the necessity to engineer their processes along with the adoption of an open source software solution for their documents. The whole project is also related to the use of a central repository of public service processes, managed by the Greek Open Technologies Alliance.
Athens policies will be further analysed in Section 1.4.3.
Greece is an example of a country that has not released any open source policy. Occasionally, public services (Ministry of Education, Municipality of Athens) adopt a positive attitude towards open source. As a
87Malta Open Source Software Communities, https://mita.gov.mt/en/Technology/Initiatives/OpenSource/Pages/ OSSCommunities.aspx 88OSS Malta, https://ossmalta.eu/ 89Interview with Municipality of Kalamaria IT personnel 90Greek Open Technologies Alliance, https://gfoss.eu/
Study on open source software governance at the European Commission and selected other European Institutions Page 23
consequence, open source initiatives are based on individual public or non-government organizations, or local open source communities91,92.
91Greek Linux Users Group (in Greek), https://www.greeklug.gr/el/ 92Hellenic Linux Users Group (in Greek), https://www.hellug.gr/
Study on open source software governance at the European Commission and selected other European Institutions Page 24
1.2.2.Public services policies in the rest of the world
Switzerland
In 2004, the Swiss IT council designed a strategy that enabled central and regional public services to consider open source software solutions and wanted to prepare ‘an environment for successful open source software implementation’. An entity that pursues actively a path to openness through open source is the Federal Supreme Court of Switzerland. The Swiss Federal Court has adopted open standards since 2001. As of 2009, the Court follows an open source strategy, i.e. use, publish and maintain open source software. Since 2010 they are using openOffice and ODF everywhere93.
As reported in 2019 in ‘Public Money, Public Code94’, in 2011 ‘the Swiss Federal Court offered its internally developed case management system called openJustitia as Free Software’. Due to negative reactions from the private sector, and after political debate, legal advice suggested that public services should not release their code freely. However, in 2014 the canton of Bern decided differently and in 2016 it solicited a different legal opinion in favour of open source software. Eventually, in 2018, the canton of Bern officially started its Free Software releasing activities, by stating clearly that open source software is an eligible option and by releasing guidelines for open source software management.
In general, as reported on OSOR, open source software is used extensively in various Swiss sectors, including education (e.g. Basel schools) and health (the VISTA hospital information system is one example). In 2015 a study was commissioned by the federal government to IT trade group SwissICT, the open source advocacy group CH Open, and other partners, including the University of Bern. The study came to the conclusion that open source software is being used in almost all major government agencies and companies, and that Swiss authorities should adopt open source software for the sake of open standards, knowledge sharing, cost savings and more independence and security95,96.
Switzerland may be seen as an example of (a) the political controversy that may stem from open source software policy discussions, and (b) the degree of liberty in open source software strategies by local/regional authorities. Nevertheless, open source software adoption by the public sector appears to be increasing.
United States of America
Many examples of open source software adoption have been observed in this country, until the recent (2016) release of the Federal Source Code Policy. Back in 1990, NASA paid for commercial support to open source software. In 2004, the Office of Management and Budget called for policy neutrality for technology and vendors. In 2003, the Department of Defense (DoD) established rules for open source software use within its organisation and in 2006 it released an open Technology Development Roadmap. In 2006 the Commonwealth of Massachusetts adopted officially the openDocument standard, while in 2009 the White House migrated its website to Linux servers and Drupal. In general, although ‘[the] US government has long used open-source software under President Obama, open-source software though is showing up in more and
93Presentation at Open Source World Conference 2012, https://www.slideshare.net/nice/open-source-project-openjustitia-of-the- federal-supreme-court-of-switzerland 94PMPC Modernising with Free Software: https://download.fsfe.org/campaigns/pmpc/PMPC-Modernising-with-Free-Software.pdf 95Open Source Switzerland, https://joinup.ec.europa.eu/document/open-source-study-switzerland-2015 96 Open source increase in Swiss public administration, https://joinup.ec.europa.eu/news/open-source-increase-swiss
Study on open source software governance at the European Commission and selected other European Institutions Page 25
more places’97.The same source reports on the Department of Defense releasing in 2009 a ‘Clarifying Guidance Regarding Open Source Software’98, stating that open source software can help to anticipate new threats and respond to changing requirements.
Government procurement has a strong preference for open source software and the use of open source software and open standards in the health sector have been preferred during the past years. As another example, the Consumer Financial Protection announced an open source policy in 2012, while NASA has integrated several open source software solutions in its Mars Rover vehicle and it recently open sourced the entire system99.
In 2014, the Federal Information Technology Acquisition Reform Act (FITARA) requested that ‘agencies should strengthen internal capacity to efficiently and securely deliver open source software as part of regular operations’, mentioning explicitly open source, open standards, and open systems architectures. In this regard, clear responsibilities were assigned to CIOs100.
In 2016, the Federal Source Code Policy was released101. This policy favours dramatically open source software in the US Agencies, requiring that 20% of the software produced by them be released under an open license. The official site for US public source code is https://code.gov, which follows the principles of US open data and open project policies102. One striking aspect of the Federal Source Code Policy is that monitoring of its implementation by the Agencies is accomplished by the Office of Management and Budget through standard government accountability mechanisms.
Open source software has been seriously considered in several public services throughout the US. Examples are the City of Portland, the State of California, the City of San Francisco and the state of New Hampshire, either favouring the acquisition of open source software or ensuring that open source software will be considered.
One factor that empowered open source software activity in the US is that large companies have endorsed open source software in various ways (e.g. IBM, Google and recently Microsoft). Quite recently (end of 2018) IBM acquired RedHat and Microsoft acquired GitHub with multi-billion agreements. Concluding, open source software developments in the US have been accelerated both due to the increased awareness of open source software technology and success among large companies and government policies.
This country provides a multitude of, often successful, examples of open source software policy initiatives. US policies will be further analysed in Section 1.4.3.
Brazil
This country is very active in establishing and implementing open source software policies at various levels. As reported in ‘Free Software as Public Service in Brazil: An Assessment of Activism, Policy, and Technology’103, the Brazilian state and local authorities have promoted the use of open source software
97Vaughan Nichols, Steven J. "Obama Invites Open Source into the White House" in PCWorld, 29 October 2009, https://www.pcworld.com/article/174746/obama_invites_open_source_into_the_white_house.html 98 https://dodcio.defense.gov/Portals/0/Documents/FOSS/2009OSS.pdf 99NASA Open Source Rover, https://github.com/nasa-jpl/open-source-rover 100Federal Information Technology Acquisition Reform Act, https://www.congress.gov/bill/113th-congress/house-bill/3979 101Federal Source Code Policy, https://sourcecode.cio.gov/ 102See also Project open data, https://www.data.gov/, https://project-open-data.cio.gov/ 103 ‘Free Software as Public Service in Brazil: An Assessment of Activism, Policy, and Technology’, Benjamin Birkinbine, University of Nevada, International Journal of Communication 10(2016), 3893–3908
Study on open source software governance at the European Commission and selected other European Institutions Page 26
throughout the country with various initiatives and policy statements. In 1999, IT agency employees of Rio Grande do Sul formed the Projeto Software Livre do Rio Grande do Sul (Free Software Project of Rio Grande do Sul) and later established the Associação Software Livre (Free Software Association) (ASL) in 2003. In 2003 four cities voted laws that encouraged open source software adoption. As reported on National Free and Open Source Software (FOSS) Strategy, in 2004, the government embarked on a project to convert 80% of departments’ computers from Windows to Linux. The project proved to be successful. As of 2005, about 60% of state departments were already using open source software solutions. The same source reports that in 2005 Brazilian presidency made open source software mandatory for the Brazilian public sector. A 2008 law of the state of Ceará gave preference to open sources systems and programs.
The Brazilian state supported financially open source migration in many ways. As reported in National Free and Open Source Software (FOSS) Strategy104, $2.1 million was allocated for research on open source and 2,100 public servants were trained for implementing and managing open source platforms. In 2008, the University of São Paulo established the Centro de Competência em Software Livre da USP (Free Software Competence Centre) (CCSL-USP) ‘to encourage research, education, development, and the use of free software both inside and outside the university’105.
The most ‘binding’ federal law was issued in 2010, namely Instrução Normativa MP/SLTI Nº04 (Normative Instruction No. 4). According to ‘Free Software as Public Service in Brazil: An Assessment of Activism, Policy, and Technology’ the law requested that ‘when government procurement agents are conducting feasibility analyses, they should consider the availability of free and open source software in general, and the software existing on the Portal do Software Público Brasileiro (Brazilian Public Software Portal), in particular’. Software Público Brasileiro is a GitHub-like platform for the Brazilian public sector open source software. In addition, justification of why proprietary software is preferred must be given before any relevant budget is approved.
Yet, in a recent report ‘Open Source in Brazil - Growing Despite Barriers’106 it is claimed that such efforts were not rewarded with success due to various reasons, including insufficient staff training and long delays for acquiring know-how on open source software engineering, lack of familiarity with working with communities and lack of private companies supporting open source software. Similar considerations apply to other Latin American countries such as Peru and Venezuela. Nevertheless, most public services have made significant steps towards open source software in Brazil, as reported on a recent study (2017) produced by the Brazilian Internet Steering Committee (CGI.br)107. The study reports that in 2017 open source software was commonly found in 93% of federal government bodies and 78% of state-level bodies. Moreover, 85% of federal government bodies and 57% of state-level bodies developed new open systems, while 52% of the federal systems had been also shared with other public services.
Recently, the experience gained through the implementation of Software Público Brasileiro was presented in ‘FLOSS Project Management in Government-Academia Collaboration’108. FLOSS stands for Free Libre Open
104National Free and Open Source Software (FOSS) Strategy, www.mcit.gov.eg/Upcont/Documents/FOSS_Strategy_EN_2014.pdf 105 ‘Free Software as Public Service in Brazil: An Assessment of Activism, Policy, and Technology’, Benjamin Birkinbine, University of Nevada, International Journal of Communication 10(2016), 3893–3908 106‘Open Source in Brazil - Growing Despite Barriers’, Andy Oram, O’Reilly, https://www.oreilly.com/programming/free/open-source- in-brazil.csp 107Survey on the Use of Information and Communication Technologies in the Brazilian Public Sector, https://cetic.br/publicacao/pesquisa-sobre-o-uso-das-tecnologias-de-informacao-e-comunicacao-tic-governo-eletronico-2017/. 108‘FLOSS Project Management in Government-Academia Collaboration)’, Melissa Wen, Paulo Meirelles, Rodrigo Siqueira and Fabio Kon, Open source software Systems Conference, https://www.oss2018.org/
Study on open source software governance at the European Commission and selected other European Institutions Page 27
Source Software, a term considered a synonym of FOSS. The most interesting finding was that a success factor was the mixing of volunteers/amateurs with professionals in the development of the platform. In general, Brazil is an example of a country that chose an aggressive road to open source software, mainly based on ideology, probably with less positive results than those expected.
Malaysia
Malaysia is considered a success story in public service open source software, mainly because the degree of open source software spread was measured and published in 2008. At that time more than 70% of Malaysian government offices were running on open source. First attempts started in 2003 and throughout the years the Malaysian government managed to establish the use of open source software in the Public Sector of the country. In 2003, the creation of open source software start-ups was funded with $36 million109 and a national GNU/Linux distribution was reported to be under development. In 2004, the Malaysian Public Sector Open Source Software Masterplan mandated preference to open source software.
The major coordination tool for Malaysian open source software strategy is the official portal of MAMPU (Malaysian Administrative Modernisation and Management Planning Unit)110. Malaysia has established an Open Source Competency Centre, that offers among other a Knowledge Bank (a public Community of Practice area for open source software implementers) and an E-Marketplace (for service providers and organisations looking for open source support)111. A detailed, 77-page guideline document is available, providing guidance for open source software adoption, procurement, ownership, technology, implementation, knowledge sharing, education and training112. In addition, the Malaysian Government Interoperability Framework for open source software (MyGIFOSS)113 was released recommending open source software solutions, open standards and technical specifications to ensure interoperability.
Malaysia is an example of a country that moved aggressively towards open source software according to a detailed Master Plan. However, there have been also policies requesting neutrality between open source software and proprietary software.
Australia
Australia is another example of a country that shows strong central preference for open source software combined with systematic efforts to promote open source software usage. The country has started working towards openness in 2005, although the focus was not yet on open source software. In 2010, the ICT Strategy Board of Trustees asked all departments to take open source software into account in their procurement process and provide justification when proprietary software was the final choice. In 2011, a general 67-page long open source software strategy was released, with many details on open source software (licenses,
109 Government-open-source-policies: https://www.csis.org/analysis/government-open-source-policies 110Malaysian Administrative Modernisation and Management Planning Unit, http://www.mampu.gov.my/en/open-source-software 111 http://dev.amtis.net/oscc_v3/index.php/en/ 112 Malaysia open source software Implementation Guideline, http://www.mampu.gov.my/images/agensikerajaan/ perkhidmatan/OSS-Implementation-Guideline.pdf 113 https://www.scribd.com/document/11164048/MyGIFOSS-Updates-3rdDraft-Final
Study on open source software governance at the European Commission and selected other European Institutions Page 28
concerns) and guidelines for acquisition plans, risk management and change management114. The strategy was based on convincing studies that demonstrated open source software benefits and cost savings.
There is multiple evidence on the Web that demonstrates the success of open source software adoption in Australia. For example, a government Digital Service Standard provides clear justification and guidance to open source software adoption115. Queensland government provides its own direction for open source software adoption. It recognises that ‘open source software products are becoming increasingly available, with a range of mature supported products that are suitable for use by agencies to achieve business outcomes’116. The policy poses also a number of constraints for open source software adoption and usage. Another case of Australian state government supporting open source software is Western Australia. This State’s ICT Strategy 2016-2020 includes an Agile Procurement Framework that facilitates ‘crowd-sourcing, open source solutions, and buying from start-ups and other small to medium enterprises (SMEs) and open source software is one of the first priorities in the Strategic Principles for ‘source solutions using good practice’117. Looking at the private sector, OSIA, Open Source Industry Australia, is a group of Australian private companies formed in 2004 that wants to ‘further the cause of both free and open source software (FOSS)’ 118. OSIA seems to be quite active nowadays: in 2018, OSIA lodged a submission to the Department of Communications and the Arts (DCA) to modernise copyright in Australia and a submission to the Senate Standing Committee on Foreign Affairs, Defence and Trade regarding the proposed "Comprehensive and Progressive agreement for Trans Pacific Partnership" (CPTPP). Other similar examples are SalsaDigital119, and Linux Australia. In a recent article on Computerworld, it is explained why Australian enterprises are turning to open source software120.
India
India provides one more example of extensive open source software usage in Asia. The former President of India Dr. Abdul Kalam was supporting open source software use in 2003 and had asked for use of open source software in military applications for security reasons. In 2011, the government issued an ICT policy recommending Linux usage in the public sector. Regional initiatives were started involving private companies for open source software support and training, including IBM. States of Kerala, Madhya Pradesh, Maharashtra, Uttaranchal are examples of regional open source software initiatives in e-governance and education. The government itself produced open source software distributions in local languages. Currently, open source software covers all 22 languages spoken in the country.
In 2014, the Policy on Adoption of open source software for Government of India was released (F. No. 1(3)/2014 – EG II) by the Ministry of Communication & Information Technology, Department of Electronics & Information Technology, to ensure ‘efficiency, transparency and reliability of such services at affordable
114A Guide to Open source software for Australian Government Agencies, https://www.finance.gov.au/files/2012/04 /AGuidetoOpenSourceSoftware.pdf 115Australian Digital Service Standard, https://guides.service.gov.au/digital-service-standard/8-make-source-code-open/ 116Queensland Open source software policy, https://www.qgcio.qld.gov.au/documents/open-source-software-policy 117 Digital Western Australia, https://www.wa.gov.au/sites/default/files/2018-06/Digital%20WA%20State%20ICT%20Strategy.pdf 118Open Source Industry Australia, http://www.osia.com.au/ 119 SalsaDigital, https://salsadigital.com.au/news/open-source-way-forward-government 120 Computerworld article regarding FOSS in Australia, https://www.computerworld.com.au/article/629907/why-australian- enterprises-embracing-open-source/
Study on open source software governance at the European Commission and selected other European Institutions Page 29
costs’121. The policy ‘encourages the formal adoption and use of open source software in Government Organizations’ and is mandatory. Exceptions are allowed ‘with sufficient justification’. A five-item implementation mechanism is included. For example, in all requests for proposals (RFPs) open source software will be given priority over proprietary solutions. Another two related policies are the policy on Collaborative Application Development by opening the Source Code of Government Applications122 and the Policy on open Application Programming Interfaces (APIs) for Government of India123. The former policy intends to ‘increase the pace of eGovernance application development and rapid roll out/implementation by adopting an open source development model’. Among other, the policy specifies the rights of the government for software that is developed by agencies and requires the code to be shared on a Collaborative Application Development Platform124. The API Policy wants to ‘encourage the formal use of open APIs in Government organizations’.
Centres of excellence and research centres have also contributed to open source software adoption. As an example, Indlinux.org125 has helped in open source software localization. Open Source India and Smart IT India are the major open source software events in India. Mozilla foundation has a special funding project for India, emphasizing the importance of this country for the open source software movement126. Interestingly, India has not proceeded in a legislation that favours open source software. The diffusion of open source software in India is probably due to the decentralised nature of the governance scheme and weak economic situation.
South Africa
This country developed an open source software strategy in 2002, based on studies that demonstrated the potential benefits of open source software for public services. The South African policy, entitled 'Open Software and Open Standards in South Africa: A Critical Issue for Addressing the Digital Divide', provided guidelines but did not contain a detailed implementation time plan. In 2005, during a conference on openness, it was decided to extend the open source software strategy document to include open content as well. The strategy gives priority to open source software development by public services, asks for migration to open source software wherever possible, and clearly promotes the concepts of openness in government products127.
The government even established an Open Source Centre in 2004. In 2006, an enhanced policy was released stating that ‘the South African Government will implement open source software unless proprietary software is demonstrated to be significantly superior’, while ‘reasons must be provided in order to justify the implementation of proprietary software’128. However, only partial success was reported in ‘An investigation
121 Policy on Adoption of Open source software for Government of India, https://meity.gov.in/writereaddata/files/policy_on_adoption_of_oss.pdf 122Policy On Collaborative Application Development by Opening the Source Code of Government Applications, https://meity.gov.in/writereaddata/files/policy_government_application.pdf 123 Policy on Open Application Programming Interfaces (APIs) for Government of India, https://meity.gov.in/writereaddata/files/Open_APIs_19May2015.pdf 124India’s OpenForge, https://openforge.gov.in/ 125Indlinux.org, https://indlinux.org/ 126Mozilla project for India, https://www.mozilla.org/en-US/moss/mission-partners-india/ 127South Africa FOSS policy, https://www.gov.za/sites/default/files/gcis_document/201409/fosspolicy0.pdf 128Policy on free and open source software use for South African government, https://www.gov.za/sites/default/files/gcis_document/201409/fosspolicy0.pdf
Study on open source software governance at the European Commission and selected other European Institutions Page 30
into the implementation of open source software within the SA government: an emerging expansion model129’, with 23 out of 31 Ministries adopting open source software and 97% of users still using Microsoft products for office automation, with open source software compatibility being the major obstacle. Overall, although central government was eager to adopt open source software, practical problems, combined probably with the lack of detailed implementation guidance, prohibited success of the whole project.
Some initiatives to support open source software are reported, e.g. OSSSA, Open Source Software for South Africa in 2014, showing some activity until 2015 only130. Last year, the first Open Source Week was organized in South Africa.
Overall, South Africa appears to be a country that has tried to adopt open source software in its public sector with limited success.
1.2.3.Other Organisations
Open source software is used widely by local/regional public services and private sector companies worldwide. Some companies that are distinguished in the adoption of open source software approaches are Google131, Engie digital132, Paypal, Microsoft133, IBM134, SalesForce135, Facebook 136and Dropbox137. We report briefly on Google that is going to be further analysed under Section 1.4.3.
Google uses open source software thoroughly for both internal operations—on both servers and workstations—and user-facing IT products and services. The company releases thousands of open source software products and participates to the development of third-party open source software products they depend upon. Code releases happen mainly via the company presence on GitHub.
Google finances open source software development via student programs like Summer of Code and Code In, the largest such programs in existence today. The company pays membership to large open source software foundations, and support both open source software events and individual projects, in order to both guarantee their longevity and promote the company brand in the open source software ecosystem.
Google introduced the notion of open Source Program Office (OSPO), providing a centralized structure to advise the rest of the company on all open source software-related needs, covering legal, strategic, and technical aspects. The OSPO notion has since then being adopted as a best practice by a large number of big IT corporations, who are now sharing best practices for using and releasing open source software via the informal TODO Group network138.
129‘An investigation into the implementation of open source software within the SA government: an emerging expansion model’, Jabu Mtsweni and Elmarie Biermann, in Proceedings of the 2008 annual research conference of the South African Institute of Computer Scientists and Information Technologists on IT research in developing countries: riding the wave of technology" 130OSSSA, Open source software for South Africa, http://osssa.org.za/ 131https://opensource.google.com/docs/ 132https://www.slideshare.net/fzara/be-proud-of-your-code-inner-source-it 133http://paypal.github.io/InnerSourceCommons/ 134https://developer.ibm.com/open/culture/ 135https://todogroup.org/guides/casestudies/salesforce/ 136 https://todogroup.org/guides/casestudies/facebook/ 137 https://todogroup.org/guides/casestudies/dropbox/ 138 https://todogroup.org/guides/
Study on open source software governance at the European Commission and selected other European Institutions Page 31
1.3.Findings from worldwide open source software research In this section we summarize some preliminary findings from the research on open source policies and initiatives described in the previous paragraph 1.2. This analysis will identify strengths and weaknesses that are relevant to open source software adoption in public organisations. The results of the analysis will be later used for providing recommendations for the future EC open source software strategy. In particular, the new strategy should contain elements that will be able to circumvent such weak points/threats and their potential consequences and/or indicate areas where careful decision making and planning is needed. For example, we have seen policies that pose constraints on open source software usage in order to avoid negative side- effects or ensure conformity with wider policies. On the contrary, strong points/opportunities should be profited from to implement sharper strategy elements accelerating successful open source software adoption, exploiting the positive experiences and good practices that have been observed. Some considerations come from the generic tendency in ICT worldwide, but we put emphasis on open source software ICT projects. At the end, we provide a list of open source software adoption approaches that we believe increase success chances.
1.3.1. Strengths
We have seen that open source software policies produce best results when a combination of the following factors is observed:
High level government or private personnel commits itself publicly in favour of open source software (US, France, India);
There is an established legal framework that favours open source software use or openness and transparency in general (France, Italy, Spain, Brazil);
There is a nation-wide favourable digital strategy (all analysed countries);
There are dedicated pro-open source software initiatives by open source software ‘champions’, may they be specific organizations, small teams or even single public sector employees (e.g. France, Municipality of Athens, Brazil). Open source software champions are for example referred to in a study on open source software costs from the London School of Economics139;
Internal or external communities are formed around open source software initiatives (France);
There is an organization entity that officially takes care of open source software issues (CIO Council in UK, core and satellite groups in France, Malaysia, and Google);
There are clear and detailed mechanisms for monitoring and quantifying open source software adoption (US, UK):
Synergy with open and transparency policies; effective policies combine free/open source with other open technology adoption, e.g. open data, open government or open content (UK Government Transformation Strategy, France, India, Australia, South Africa, and Municipality of Athens); furthermore, the GDPR implementation may be combined with and benefit from open source software (e.g., by open source-based frameworks as in openGDPR140. However, this may also be seen
139 Total Cost of Ownership of Open Source Software, Maha Shaikh & Tony Cornford, London School of Economics, 2011, http://eprints.lse.ac.uk/39826/1/Total_cost_of_ownership_of_open_source_software_(LSERO).pdf 140OpenGDPR, https://www.opengdpr.org/
Study on open source software governance at the European Commission and selected other European Institutions Page 32
as a potential threat, in cases where organizations using open source software and open source software projects/communities prove slow in adopting and implementing GDPR requirements;
Competence or Research centres are built to support open source software initiatives. Such centres, each one with different goals and scope, have been reported in UK, France, Spain, Greece, Brazil, India, Malaysia, and South Africa.
1.3.2.Weaknesses
The following factors have been observed to pose significant barriers to open source software adoption in public sectors. As such weak points had been already observed in the past, in several cases they have been addressed by the most recent policies reviewed above.
1. Unclear points in open source software licences: five recent policies try to clarify open source software license issues by imposing or otherwise suggesting specific licenses (US, UK, France, Italy, Malta, Australia);
2. Poor implementation results due to insufficient application of policies; such results may be attributed to insufficient preparation, poor guidance for migration to open source software or merely the many problems associated with open source software adoption. Poor results have been observed in many cases, even in countries that were eager to greatly favour open source software (Brazil, South Africa);
3. Open source software solutions are often adopted when there is no enterprise or technical architecture mind-set, i.e., open source software is adopted without taking into account the constraints of and the impact on the business and ICT vision of an organization. Such problem led the recent policy of UK to specify the need for a technical architecture point of view and suggest that open source software adopters participate in a community of software architects;
4. Many different design and implementation approaches are used among open source software initiatives, losing the advantage of reuse of code, experiences, adoption processes. Recent policies attempt to homogenize open source software processes and products by providing detailed guidance (US, UK, France);
5. No ownership of the open source software projects: open source software is proposed by upper management, but no one becomes the champion of the project. This issue has been addressed by several policies by indicating that, for example, CIOs be responsible for the implementation of open source software policies (US, UK, France, Malta).
6. Several human resource issues, with no sufficient open source software culture among end users being the most critical. In environments where commercial software has been used for decades, without any viable alternatives, people get addicted to it and refuse to switch to alternative open source software solution. Other human issues may be the “not invented here” syndrome (i.e. users’ reluctance to use or buy already existing products because of their external origins), resistance to (any kind of) change, fear of stronger staff control and monitoring of productivity, non-awareness of open source software characteristics (e.g., too much emphasis on cost savings), inadequate prior education and training. Higher level education is often responsible for the lack of open source software culture among public service employees. Countries where human resource issues have been reported explicitly are Brazil and South Africa, but it is reasonable to assume that they are commonly found everywhere;
Study on open source software governance at the European Commission and selected other European Institutions Page 33
7. Strong dependence on vendors/lock-in. Relationships with commercial software vendors have often been forged over decades and are hard to break for several reasons. This problem may also stem from technical pitfalls of open source software applications. Returning to commercial solutions after encountering problems with free/open source software has been observed in Germany and Greece, but is reasonable to assume that it may occur frequently in other countries as well;
8. Lack of pragmatism and unrealistic expectations from free/open source. Free open source adoption may fail to reach its targets when there is ‘no real need for change or a new approach141’ and ideology is the only driving force (Brazil). On the other hand, ideology has been a major driving force that brought free/open source phenomenon to its current dimensions;
9. Legal frameworks may be unclear and/or too complicated. Many policies are collections of few paragraphs that suggest actions favouring the adoption of free/open source software (Malta). While these policies demonstrate clearly the will of a central government/authority to propose free/open source, they do not offer clear guidance. Often such policies are replaced over the years with more structured, detailed and precise ones, with several statements/components that target specific issues that have emerged from the first years of application (US, UK, France, Italia, Malaysia);
10. In some cases, lack of continuity in management may jeopardize free/open source adoption efforts. Open source software initiatives are often proposed under specific political umbrellas and this is seen negatively by opposing political forces, leading to the cancellation of open source software projects (see the ongoing debate over the case of City of Munich);
11. Lack of vendors or poor open source software ICT vendor performance. Open source software projects may fail because of the same reasons that all kinds of ICT projects fail (unrealistic schedules, software process pitfalls, or other project/process/system issues). In the case of open source software, one more inhibiting factor is the potential lack of an ecosystem of private companies that offer adequate maintenance support (Municipality of Athens). Similar cases have been reported in the interviews with internal EC stakeholders;
12. Lack of sufficient funding, as often open source software is incorrectly considered costless. Proper open source software adoption requires investments in system migration and employee training, as well as investments in the sustainability of the adopted open source software solutions. Examples are direct community funding through donations, hiring of open source software developers working on the project of interest, active participation into open source software foundations, sponsoring of bug bounties and hackathons. In general, open source software is practically an investment with benefits that may not be always immediately evident142.
1.3.3.Further Interesting Recent Developments
Although not directly supported by the free/open source worldwide research presented above, there are some recent developments in the general context that we believe may affect the evolution of the EC open source software strategy.
141Total Cost of Ownership of Open Source Software, Maha Shaikh & Tony Cornford, London School of Economics, 2011, http://eprints.lse.ac.uk/39826/1/Total_cost_of_ownership_of_open_source_software_(LSERO).pdf 142Total Cost of Ownership of Open Source Software, Maha Shaikh & Tony Cornford, London School of Economics, 2011, http://eprints.lse.ac.uk/39826/1/Total_cost_of_ownership_of_open_source_software_(LSERO).pdf
Study on open source software governance at the European Commission and selected other European Institutions Page 34
Strong ICT/open source software European know-how. Europe has developed a strong software industry around open source software projects. Such companies may become leaders in supporting other emerging open source software applications. On the other hand, many software engineers knowledgeable in open source software work on commercial software because the latter is more used in businesses. Moreover, know-how transfer among EU state members has been occurring in the past years. Joinup (specifically, the OSOR collection within it) is a platform enabling this transfer and may be further leveraged accordingly.
As time progresses, gradually more ICT open source software-aware personnel enter EU public services, facilitating open source software adoption at all levels. At the same time, as open source software continuously gains terrain, citizens become gradually more familiar with it. Moreover, open source software is somehow associated with general consumer rights. There is one supporting case, namely the adoption of open source software by the Consumer Financial Protection in the US. Based on these remarks, EU Citizens would be more eager to appreciate any EC efforts towards open source software adoption nowadays.
Ever increasing demand for extensive digital services/reforms. This poses pressure on commercial software because available budgets are limited and cannot afford to cover all demands through commercial solutions. On the other hand, in the past few years, open source software has managed to provide solutions to most such requirements (e.g., by handling digital signatures).
Open source software based start-ups are being constantly created, as open source software is the natural low-cost choice for starting a small company with little capital. This ecosystem of start-up companies may become a partner in the expansion of open source software adoption within EU institutions.
Open source solutions are made available by cloud providers as software as a service. This fact may also be seen as an easier way to deploy open source software. The spread of virtualization is also an enabling factor allowing open source software to be deployed together with legacy systems.
An increase in the penetration of open source software ideas and systems at all levels of education is being observed. Educating early future ICT personnel and end users will have a paramount positive effect on accepting open source software based work environments and solutions.
Research in the field of open source software has been supported in the past either through funding or by establishing a dedicated research centre (Italy, Spain, France, India, Brazil). Such centres may focus on resolving specific hard problems in open source software adoption in public settings and provide critical assistance in cases where the path to open source software adoption is not straightforward.
1.3.4.Successful open source software adoption approaches
Elaborating on the strengths that emerged while studying open source software worldwide, we list seven particularly interesting and often successful approaches to be considered for the future.
High level commitment and dissemination. All kinds of ICT innovation projects need strong central or high- level management commitment and open source software adoption is no exception to this rule143.
143Total Cost of Ownership of Open Source Software, Maha Shaikh & Tony Cornford, London School of Economics, 2011, http://eprints.lse.ac.uk/39826/1/Total_cost_of_ownership_of_open_source_software_(LSERO).pdf
Study on open source software governance at the European Commission and selected other European Institutions Page 35
Alignment with other areas related to the concept of openness. Aligning open source software adoption with activities supporting other areas favouring open technologies (open hardware, open data, open content) leads to wider visibility (see, e.g. the recent initiative of over one hundred Open & Agile European cities that agreed on minimal interoperability mechanisms144).
Funding. Open source software adoption is not costless. Although initial acquisition cost is almost null, other significant costs are incurred in every open source software adoption project, such as training, installation, parameterization, customization, migration, maintenance and support costs. Countries that have a long- standing history in open source software adoption have considered, at least once, funding such projects.
Community building at local and national level. Leverage of existing open source software communities is of paramount importance. A nation-wide community may also be extremely helpful. The French government is building its own open source developer community, addressing various challenges in open source software adoption145.
Bottom-up adoption of open source software. This approach has been observed in all countries and shows how open source software usage may be adopted in lower level public services (municipalities or regions), although there is no generic framework that encourages or regulates the adoption of open source software at every single administration level.
Open source software reuse among different country public services. Obvious benefits stem from the reuse not only among the public services of the same country, as we saw for example in Italy, but among public services within EU. For example, in Spain the City of Valencia is using Epoptes, an open source environment for school PCs produced in Greece, although the future of that product in Greece is uncertain. Another example are the Minimal Interoperability Mechanisms fostered by the Open & Agile European cities initiative mentioned above.
Centres of open source software excellence / Program Offices. These centres may be established at various levels of public services, educational, or research institutions. They may foster the adoption of open source software and provide support to open source software users. They may specialize in specific open source software products or application areas rather than providing generic open source software support, as well as offer consultancy to the rest of the public services on all or a subset of legal, technical, and strategic aspects. 1.4.Analysis of open source usage status in selected organisations In order to identify the current situation on open source software usage in the public sector and related trends, six organisations have been selected, within current leaders among public/private administrations in open source software adoption in Europe and abroad, to be submitted to a more in-depth analysis of their open source policy frameworks. The analysis of each organisation is detailed below in a factsheet providing an overview of the status of their open source software usage, under organisational, cultural, technological, legal and IPR aspects.
144Open & Agile Cities’ minimal interoperability mechanisms, https://joinup.ec.europa.eu/news/open-data-source-apis 145Blue Hats French Community, https://joinup.ec.europa.eu/news/les-blue-hats
Study on open source software governance at the European Commission and selected other European Institutions Page 36
1.4.1.Focus panel of organisations: selection criteria and pertinent considerations
In line with the objectives of the present study, specific focus has been dedicated to a selection of 6 organizations, chosen according to the following criteria:
at least 4 of those organizations are public services;
the panel includes at least 1 enterprise-size (10,000+ employees) private organisation advanced in the implementation of open source software policies;
at least 3 of the analysed organisations are well advanced in the implementation of open source software policies;
at least 4 of the analysed organisations are based in the European Union;
selected organizations are from different countries.
Criteria for choosing among organisations in potential scope are:
countries/organisations already mentioned in the previous study “Open source software Governance at the European Commission”146 (e.g. AgID - Italy, Secretariat General du Governement - France, UK government, Danish government, Australian government, US Department of Defense);
input from OSOR147 and relevant articles/news on specific use-cases to be considered of interest for this analysis (e.g. City of Antwerp);
best practices in the context of open source software;
list of organizations attending / presenting the most important worldwide open source software events (e.g. Paris open source summit148, DIGITEC149);
well-known KPMG customers with an open source software mind-set and that implemented a valuable open source software strategy (e.g. INFOCAMERE three-year plan (2017-2019) for the migration and evolution of software platforms towards an open source environment;
input collected through the CGI - Open Source Centre in Glasgow and previous studies on the adoption of open Source by the US government;
available research material (from open source communities, academia and EC funded projects) on open source software about methodologies, framework, tools and development.
Additional desk research has been conducted with the aim of analysing the six organizations’ open source strategy and approach, investigating the hereunder main dimensions:
146“Open Source Software Governance at the European Commission”, EC-DIGIT, 2014 147OSOR, https://joinup.ec.europa.eu/collection/open-source-observatory-osor, or https://egyptfoss.org/en/ 148 https://www.opensourcesummit.paris/ 149Discussion panel, https://www.youtube.com/watch?v=6CiYCd86y7I
Study on open source software governance at the European Commission and selected other European Institutions Page 37
technology (e.g. desktop, servers, collaborations, development): analysing what is used, where it is used, and any potential issues related to the use of open source software;
cultural aspects (e.g. how organizations are transforming themselves using open source);
organizational aspects (e.g. open source software program manager “role” officially present in the organization, processes and procedure linked to the use of open source);
IPR and legal aspects linked to open source software;
trends in the use of open source software in the market and inside the organizations;
open source software policies at the national and EU Level and/or internal policies of the organization.
Where needed, for additional clarifications, phone or videoconference interviews have been conducted with representatives of those organizations.
1.4.2.Justification for the selection of the six organisations proposed for the analysis
EU member states: UK Government, Italian Government, French Government
These EU public sectors have been selected for the analysed panel because:
specific legislation and guidelines have been proposed at the highest possible level (meaning that there is a strong commitment by public institutions on the adoption of open source);
open source software promotion efforts are prolific (several successive pro-open source software actions are taken over the years);
there are several success stories (e.g. French Gendarmerie, UK CIO preference for open source software in 2009, Italian budget law in 2007);
often actions are combined with funding, further emphasizing high level commitment;
all of them are large countries ensuring high visibility of their open source software policies.
Municipality of Athens
Although the public sector context in Greece is not that favourable, this organization is fighting to adopt open source software solutions in different areas such as process modelling, document management, geospatial data management, identity management. Of particular importance is their approach for combining process management and open source software deployment, which is relevant because implementing any IT project in a public service involves also process engineering and re-engineering. Other cases identified involve more “plain” approaches and/or were harder to contact.
USA
In recent years, the US Government has been doing a very good and structured work with the Federal source code policy, code.gov, USDS, etc. Other countries (e.g. Brazil, Malaysia) may but the US is also more similar to the EU and has high visibility being a technology leader worldwide.
Study on open source software governance at the European Commission and selected other European Institutions Page 38
Google has been included in the panel not only due to how well-known the company is, but also because it has one of the best structured and comprehensive open source software policies. Other major companies either publish unstructured material (e.g., the TODO group case studies), or display mostly marketing oriented web presences (e.g., IBM, Microsoft), while the Google policy is very well-structured, covers both internal and external aspects, from both a strategic and legal perspective.
Study on open source software governance at the European Commission and selected other European Institutions Page 39
1.4.3.Organisation factsheets
Factsheet – UK Government
Summary
The UK government has stated since many years the importance of open source software for its public sector IT. Initial attempts to foster open source adoption had limited success. As mentioned under paragraph 1.2.1, the UK government has released in 2017 an updated open source software policy (the guidance document “Be open and use open source”), in order to further facilitate and accelerate open source software adoption. This policy is distinguished by the fact that it puts emphasis on technical software engineering issues, including reuse, security, bug fixing, technical architecture and configuration management. The UK policy uses also strong wording (‘be open and use open source’) to communicate a clear message in favour of open source. A central repository for UK open source is another important feature of the open source framework in the country.
Sources
UK Government Guidance: “Be open and use open source”, 2017, https://www.gov.uk/guidance/be- open-and-use-open-source
“Open source software Options for Government”, 2012, https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/fil e/78964/open_Source_Options_v2_0.pdf
“Introduction To Software Protection Under United Kingdom Law”, http://iopen source softwarelawbook.org/uk/
Repo containing the tech docs for data.gov.uk, https://github.com/alphagov
Information from the UK open source software competence centres listed under https://joinup.ec.europa.eu/collection/open-source-observatory-osor/competence-centres-open- source-software- open source software
UK’s oldest open systems user group, https://www.fl open source softwareuk.org/
Open UK, the association of IT companies providing services and solutions around free and open source software (FOSS) - ,https://openuk.uk/
Case study on the use of IBM LinuxONE servers by the UK Meteorological Office, https://www.ibm.com/case-studies/met-office
Main highlights on open source software use
Open source software was not widely used by UK public services (2012): see https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/fil e/78964/open_Source_Options_v2_0.pdf;
Open source adoption is not an isolated guideline, but rather one item of a broader Technology Code of Practice: https://www.gov.uk/government/publications/technology-code-of-practice/ technology-code-of-practice;
Study on open source software governance at the European Commission and selected other European Institutions Page 40
Open source adoption is directly linked to a public money spending process: https://www.gov.uk/service-manual/agile-delivery/spend-controls-check-if-you-need-approval-to- spend-money-on-a-service;
Open source adopters are warned about open source software related costs;
Specific guidelines are provided on how to publish code: https://www.gov.uk/service- manual/technology/making-source-code-open-and-reusable.
Technology
GitHub is recommended as repository of the source codes of most open source solutions produced by and for the UK public services: https://www.gov.uk/service-manual/technology/making-source- code-open-and-reusable#making-the-code-open.
Emphasis on technical architecture to decide which system part can be opened, consulting a technical architect if necessary, member of a specialized Technical Architecture community, https://www.gov.uk/service-manual/communities/technology-community-technical-architecture.
Emphasis is also given to configuration management issues, such as semantic versioning or version control; GitHub is suggested to facilitate configuration management: https://www.gov.uk/service- manual/technology/making-source-code-open-and-reusable#making-configuration-code-open, https://semver.org, https://www.gov.uk/service-manual/technology/maintaining-version-control- in-coding.
Cultural aspects
Recommendation to 'make your code open from the start', to avoid the cost of checking release quality and safety later: https://www.gov.uk/service-manual/technology/making-source-code-open- and-reusable#make-your-code-open-from-the-start.
Security flaws are the first issue to address when opening an existing code. Language matters, e.g. no rude messages in comments and good documentation is desired: https://www.gov.uk/service- manual/technology/making-source-code-open-and-reusable#how-to-make-existing-code-open.
Code that contributes to one's service security does not need to be kept closed; however, clear guidance for security is provided: https://www.gov.uk/government/publications/open-source- guidance/security-considerations-when-coding-in-the-open, https://www.gov.uk/government/ publications/open-source-guidance/when-code-should-be-open-or-closed.
Fast fixing of bugs found is requested: https://www.gov.uk/service-manual/technology/making- source-code-open-and-reusable#dealing-with-security-issues-in-published-code, https://www.gov. uk/government/publications/open-source-guidance/security-considerations-when-coding-in-the- open#deal-with-security-vulnerabilities.
Regular software deployment concept is promoted: https://www.gov.uk/service- manual/technology/deploying-software-regularly.
Organisational aspects
Broader scope standards and policies must be observed when open sourcing, e.g. see Cloud Security Guidance: https://www.gov.uk/service-manual/technology/making-source-code-open-and- reusable#making-the-code-open, https://www.ncsc.gov.uk/guidance/cloud-security-collection.
Study on open source software governance at the European Commission and selected other European Institutions Page 41
Exceptions to the code openness (cases where the code is not to be disclosed) are clearly defined: https://www.gov.uk/government/publications/open-source-guidance/when-code-should-be-open- or-closed.
A plan for how to upgrade or patch software is needed: https://www.gov.uk/service- manual/technology/making-source-code-open-and-reusable#making-configuration-code-open.
A Technical Architecture Community supports decisions on which parts of the code to open or keep closed.
IPR and legal aspects
Licenses of open Source Initiatives are proposed, making explicit reference to https://opensource.org/licenses: https://www.gov.uk/service-manual/technology/making-source- code-open-and-reusable#licensing-your-code;
All code produced by UK civil servants is automatically protected by Crown Copyright; the default license for most Crown copyright and Crown database right information is the open Government License: http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/, http://www.nationalarchives.gov.uk/information-management/re-using-public-sector- information/uk-government-licensing-framework/crown-copyright/.
Trends in the use of open source software
Open source software use appears to be increasing, e.g. considering the attempts of UK to switch to LibreOffice, and the release of a new open source software policy in Nov. 2017.
Security is of primary importance: see https://www.gov.uk/guidance/be-open-and-use-open-source.
Open source software related policies
Guidance on how to publish UK code 'openly and use open source technology to improve transparency, flexibility and accountability' (2017), https://www.gov.uk/guidance/be-open-and-use- open-source;
Open source software Options for Government (2012), https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/fil e/78964/open_Source_Options_v2_0.pdf.
Study on open source software governance at the European Commission and selected other European Institutions Page 42
Factsheet – French Government
Summary
The French government has an open source software-friendly approach for its public sector IT infrastructure. Its recent open source software initiatives distinguish this country for the high level commitment and the community-centric nature of open source software related efforts, while open source software initiatives receive a lot of publicity. France has also a distinct inter-ministerial organizational structure for supporting open source software and other open concepts, such as open data, with a central unit surrounded by satellite groups. In addition, this country has established since several years a research centre dedicated to open source software. Moreover, France is an example of a country where achievements towards open source are officially recognized, and open source software is becoming gradually a kind of national asset.
Sources
“Orientations pour l'usage des logiciels libres dans l'administration“ (2012), http://circulaire.legifrance.gouv.fr/pdf/2012/09/cir_35837.pdf
“France builds a government community for open source”, https://joinup.ec.europa.eu/news/les- blue-hats
Information from the French open source software competence centres listed under https://joinup.ec.europa.eu/collection/open-source-observatory-osor/competence-centres-open- source-software- open source software
PIA tool for GDPR compliance, by CNIL, an independent French administrative regulatory body whose mission is to ensure that data privacy law is applied to the collection, storage, and use of personal data, https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact- assesment
“Introduction to Software Protection Under French Law” (2010+), http://iopen source softwarelawbook.org/france/
Société Générale, “Open Source, A Key To Innovation”, https://www.societegenerale.com/en/open- source
“France begins IT research centre on innovation and free software”, https://joinup.ec.europa.eu/news/france-begins-it-research-cen
“The ‘open‘ in France has moved forward”, https://joinup.ec.europa.eu/news/open-france-has- move
“France: Henri Verdier to lead the newly-formed DINSIC”, https://joinup.ec.europa.eu/news/france- henri-verdier-lead
Main highlights on open source software use
Guidance for open source software usage is provided by the “Direction Interministérielle des Systèmes d'Information et de Communication” (18 pages, 2012);
French Government shows strong high-level commitment in favour of open source software, with open source software use being 'encouraged' by French digital law (2016), see for example https://joinup.ec.europa.eu/news/open-france-has-move;
Study on open source software governance at the European Commission and selected other European Institutions Page 43
Open source software is considered equal to commercial solutions;
Open source software use is not an 'ideological' issue but a reasonable choice;
It is proposed to invest part of the license costs saved back to the open source software projects used.
Technology
As an example of French public software, the PIA tool has been developed for GDPR compliance, by CNIL, an independent French administrative regulatory body whose mission is 'to ensure that data privacy law is applied to the collection, storage, and use of personal data': https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact- assesment.
Cultural aspects
The “Direction Interministérielle du Numérique et du Système d'Information” is trying to establish an open source software culture among public service staff, see section 3, “Le libre, un choix raisonné” in http://circulaire.legifrance.gouv.fr/pdf/2012/09/cir_35837.pdf. Advantages of open source software are clearly presented to the reader, along with non-favourable situations for open source software adoption. In section 4.8, the need to develop the culture of free licenses when developing public service software is emphasized;
“Free Digital Territory” is a label assigned to French public services for their use of open source software, open formats, open data and engagement in activities related to openness. Since 2016, 30 communities have been labelled as such, https://territoire-numerique-libre.org/;
A cyber-defence strategic review document proposes to make manufacturers liable for the security of a product while it is on the market, and possibly requiring its software to be made open-source at end of life: http://www.sgdsn.gouv.fr/uploads/2018/02/20180206-np-revue-cyber-public-v3.3- publication.pdf;
It is advised to contribute back to open source software communities, especially those of the projects from which substantial savings are obtained. Contribution may take the form, for example, of code commits, donations, financial support for specific function development, participation of public service personnel to open source software communities. Coordination of such activities is described at an inter-ministerial level;
Community building: as reported on OSOR, 'the French government is building its own open source developer community, aiming to bring together software developers and IT scientists who want to contribute to government-led open source projects. The new initiative, entitled ‘Blue Hats’ was launched at the Paris open Source Summit 2018'; the call for participation addresses developers, designers, and data scientists: https://joinup.ec.europa.eu/news/les-blue-hats.
Organisational aspects
The DINSIC, (Direction Interministérielle du Numérique et du Système d'Information et de Commucation) is the government agency that promotes the use of open source software within French public sector, https://www.numerique.gouv.fr/dinsic/;
CNLL, the National Council for Free Software, is a federation of 11 regional clusters and two
Study on open source software governance at the European Commission and selected other European Institutions Page 44
independent entities that support open source software use. Overall 300 enterprises are represented by CNLL, https://cnll.fr/. Similarly, ‘La Mouette’ is an association of both physical persons and legal entities for a ‘Free Bureaucracy’ (http://www.lamouette.org/), and PL open source software-RA is an association promoting open source software in Région Auvergne Rhône- Alpes and beyond: http://www.ploss-ra.fr/;
Five inter-ministry groups are defined by the “Direction Interministérielle des Systèmes d'Information et de Communication” in chapter 5.1, for managing open source software activities and artefacts. One core ('noyau') group has a coordination role and four groups (mimO, mimOG, mimBD and mimOS), have more specific roles, e.g. for database issues. Their roles, functions and tools are described in detail in http://circulaire.legifrance.gouv.fr/pdf/2012/09/cir_35837.pdf;
An official community building approach (Blue Hats, see above) exists, with a clear pro-open source software communication message (inspired by Red Hat) and the adoption of national colours (‘Le Bleu');
The IRILL centre (IT Innovation and Research Centre for Free Software) has been established by INRIA in 2009; its mission is 'to bring together in one place leading researchers and scientists, expert open source software developers, and open source software industry players to tackle the three fundamental challenges that open source software poses today: scientific, educational, economic': https://www.irill.org/.
A three to four-year contract was awarded in 2011 to three private companies, active in open source software support. In 2016, France's ministries collaborated with open source software communities and the public for preparing the newest version of this multi-year contract for services and support on open source software. As reported on OSOR150, ‘it is the first time that an IT services support contract will be co-written by administration and citizens’. A public forum was created to support this initiative151;
Various open source software competence centres exist in France, namely AFUL, April, Chtinux, FSF France, Adullact): https://joinup.ec.europa.eu/collection/open-source-observatory- osor/competence-centres-open-source-software- open source software;
Open source software champions exist within France private sector companies; one example is Société Générale: https://www.societegenerale.com/en/open-source.
IPR and legal aspects
An extensive description of French jurisdiction on open source software law issues (2011) is provided in http://iopen source softwarelawbook.org/france/;
An open source software license tailored to French law exists, namely CEA CNRS INRIA Logiciel Libre (CECILL), developed by eminent organizations (CEA, CNRS, INRIA): http://www.cecill.info/licences/Licence_CeCILL_V2-en.html;
Management of open source software licenses for any developed software code is left to each Ministry's IT department. It is advised anyway, to use with precaution hybrid/dual licenses, because of the risk to fall back in a proprietary license situation
150France involves public to draft support contract, https://joinup.ec.europa.eu/news/france-involves-public-dra 151Forum for French FOSS solutions, https://forum.etalab.gouv.fr/
Study on open source software governance at the European Commission and selected other European Institutions Page 45
(http://circulaire.legifrance.gouv.fr/pdf/2012/09/cir_35837.pdf).
Trends in the use of open source software
Increasing use of open source software is reported in https://joinup.ec.europa.eu/news/open- france-has-move: ‘The free software market in France should increase by 15% in 2016, more than was expected earlier', announced Axelle Lemaire, France’s Secretary of State in charge of Digital Affairs.
Open source software-related policies
Orientations pour l'usage des logiciels libres dans l'administration are given in: http://circulaire.legifrance.gouv.fr/pdf/2012/09/cir_35837.pdf.
Study on open source software governance at the European Commission and selected other European Institutions Page 46
Factsheet – Italian Government
Sources
“La trasformazione digitale nella Pubblica Amministrazione” 2018, https://teamdigitale.governo.it/assets/pdf/Relazione_TeamTrasformazioneDigitale_ITA_30set.pdf
“Italy creates Digital Transformation team” 2017, https://joinup.ec.europa.eu/news/italy-creates- digital-transfo
Github-Developers.italia.it, https://github.com/italia/developers.italia.it/pulls?q=is%3Apr+is%3A closed
Introduction to Software protection under Italian law, http://iopen source softwarelawbook.org/italy/
Guidelines for SW acquisition and reuse for public services, 2017, https://lg-acquisizione-e-riuso- software-per-la-pa.readthedocs.io/it/latest/
Main highlights on open source software use
The Digital team of the Italian government, in collaboration with AgID (Agenzia per l’Italia Digitale), maintains the ‘Guidelines for software acquisition and reuse’ for the public services (https://lg- acquisizione-e-riuso-software-per-la-pa.readthedocs.io/it/latest/), which explicitly favour open source software solutions over proprietary alternative, provided the desired technical requirements are equally supported. Thanks to the aforementioned guidelines, the Italian policy landscape has become one of the most advanced in public service open source software matters in Europe;
The Digital team, on-behalf of Italian Government and in collaboration with AgID (Agenzia per l’Italia Digitale), started in 2017 Developers Italia, a digital government transformation team and software development community focusing on open source software development, and Designers Italia, a public service design community, https://developers.italia.it/, https://designers.italia.it/;
On Developers Italia, 10 projects (PagoPA, SPID, DAF, IO, CIE, Devops Italia, Dati.gov.it, ANPR, OTELLO 2.0, and Carta Docente) have been published in order to provide developers with the possibility to contribute to the project source code, https://developers.italia.it/it/progetti;
Developers Italia software solutions and software libraries are to be published on GitHub.
Technology
Both community platforms (Developers Italia and Designers Italia) provide technical documentation, guidelines, software development kits, work methodologies and test environments. In addition, these platforms provide an issue tracking system that offers developers, designers, and technology suppliers the possibility to collaborate for the development of the digital public services (PagoPA, SPID, DAF, IO, CIE, Devops Italia, Dati.gov.it, ANPR, OTELLO 2.0 and Carta Docente).
Developers Italia software solutions and software libraries are to be published on GitHub under the BSD license (https://github.com/italia/developers.italia.it/);
For the first 10 projects published on Developers Italia, more than 800 developers have contributed to the evolution of the source code: 212 repositories have been opened and more than 2765 contributions have been integrated (bug fixes, enhancements, and new features).
Study on open source software governance at the European Commission and selected other European Institutions Page 47
Cultural aspects
Until now, except for some rare exceptions, the central public service limited itself to drafting laws and regulations in a non-technical bureaucratic language without any tools or initiatives to support the developers involved in building and integrating software. Developers Italia wants to fill this gap, starting with a handful of projects. Around these projects the Digital team wants to build a community, starting from the basics: re-writing the documentation in technical language, using as a publishing platform the open source software project ‘Read The Docs152’, and by providing a development environment, examples, and Software Development Kits (SDKs) for the most common languages and frameworks. The Digital team provides direct support via the forum, built on top of the open source software project ‘Discourse153’ and already accessible online, instead of a helpdesk accessible only by phone. The Digital team created the website to simplify and improve the interaction between the developers and the public service, beginning with some important projects like the ANPR, the National Registry of the Resident Population, or the SPID, the public identity digital management system.
Organisational aspects
The Digital team has structured the Developers Italia web site as follows:
Source Code: on GitHub Italia, the Digital team develops SDKs and examples to support the projects, with an open development process; the developers can track on GitHub the existing issues;
Slack: via Slack channels, the users can find all the maintainers and developers of Developers Italia.
Forum: helps the community discuss about the projects, exchange tips and tricks, and discuss with maintainers on the roadmap.
Docs: provisioning of the technical documentation of all the projects, mainly written in Markdown and ReStructured Text, and compiled with Sphinx and RedTheDocs.
API sandbox: possibility to play with all the APIs exposed by the projects, in a testing environment that will help developers exploring and fixing their implementation.
The maintainer is in charge of writing the source code, the documentation and the examples of the projects; it is also in charge of interacting with the developers’ community giving them support on adopting the technology.
Typically, the maintainer works with the product owner of the project and with the public service technical staff. For instance, in PagoPA project, the centralised payment system of the public services owned by AgID, the maintainers help AgID and provide support to the community to adopt PagoPA, building and maintaining the plugins for the most common CMSes, interface libraries for Python or Ruby and documentation of the APIs in technical language.
The Digital team chooses the maintainer based on technical expertise, knowledge of the project, the level of participation in the community itself and often in big projects. The Digital Team receives a compensation to put huge effort in terms of time and resources to contribute to the project itself. A maintainer is not only a supervisor, but also the contact point in terms of quantity and quality of the contribution.
152https://readthedocs.org/ 153https://www.discourse.org/
Study on open source software governance at the European Commission and selected other European Institutions Page 48
IPR and legal aspects
Copyright protection of software is regulated in Italy under a few articles added to the general Italian Copyright Law (Law n. 633 of 22 April 1941) under the Legislative Degree no. 518 dated 29 December 1992: http://iopen source softwarelawbook.org/italy/.
Trends in the use of open source software
Improve the quality of the public service software thanks to the creation of communities.
Promote developers’ collaboration.
Disseminate open source software culture within public services.
Open source software-related policies
In 2018, the Digital team of the Italian government, in collaboration with AgID, published the “Guidelines for software acquisition and reuse” (https://lg-acquisizione-e-riuso-software-per-la-pa.readthedocs.io/it/ latest/).
The guidelines, adopted for the implementation of the art. 68 and 69 of the “Codice dell’Amministrazione Digitale” (CAD), provide the operational process for the reuse and acquisition of software for all Italian public services, favouring open source software in the process.
Study on open source software governance at the European Commission and selected other European Institutions Page 49
Factsheet – Municipality of Athens
Summary
The Municipality of Athens is an example of a local authority that follows a bottom-up approach for adopting open source software solutions in different areas (process modelling, document management, geospatial data management, identity management). With no government open source policy available, cultural preference for open source software among Athens’ IT personnel appears to be the driving force for successfully and continuously implementing open source software solutions. It is evident that this attitude ensures that open source software will have a leading role in the future IT developments of this municipality. However, lack of support from private companies for maintaining core IT systems will be also a prohibiting factor. The example of Athens shows that things are rather easy when no particular support is needed for an open source solution. Whenever some type of maintenance support is needed, either internal or outsourced to another organization or company, open source needs careful consideration.
Sources
Interview with an IT Advisor at the Municipality of Athens
Presentation (in Greek), Athens Digital Roadmap (2018), https://www.aftodioikisi.gr/wp- content/uploads/2018/01/athens_digital_roadmap_2018.pdf
Main highlights on open source software use:
Extensive use of open source software by the IT staff of the Municipality;
Open source software is not used for financial services (Oracle based since 2000, moving to SAP);
Windows is anyway used by the majority of PC users;
Combined process modelling and open source document management are applied;
No open source software related policies at the national or municipality level exist; Open source software adoption is mainly based on the open source software culture within the IT department.
Technology
5% of the PC users are Linux users;
By mid-2019, LibreOffice will be used by approximately 50% of users;
Firefox is the standard browser;
Almost all servers are Linux/Ubuntu based;
Official municipal web site is based on Drupal:
Open source software used for Network Management (e.g. Nagios);
Postgress DB is extensively used;
Open source software for geospatial data (QGIS, PostGIS, Geoserver, Geonode) is also extensively used;
User/Identity management is ensured by open source solutions (WSO2, DSS, Fortify app);
Study on open source software governance at the European Commission and selected other European Institutions Page 50
GitHub is used as a repository for open source solutions produced and used by the Municipality: https://github.com/MunicipalityOfAthens;
Bonita BPM and Alfresco are used for process and document management and several processes have been modelled, and the Municipality is moving now to a simplified process scheme by merging processes; Alfresco loads hierarchy from LDAP server and makes it available to Bonita BPM.
Cultural aspects
Some open source software culture already exists among non-IT staff users;
Strong open source software culture exists among IT staff. No particular reason has been reported;
Continuous training on open source software is provided to interested users through external partner seminars;
There is clear support by the Mayor and the Council, as stated in Athens Digital Roadmap (2018, in Greek): 'Software code developed with public resources should be open and accessible to everyone. We start with our web site and digital signature software code.', https://www.aftodioikisi.gr/wp- content/uploads/2018/01/athens_digital_roadmap_2018.pdf, https://www.synathina.gr/en/.
Intuitively, the IT staff believes that the general movement of open technologies have helped open source software adoption in the Municipality.
Organisational aspects
In the past few years' tenders, it is required that source code must be delivered, with the option to be opened;
A municipal IT Company was established in 1983; the Company has inherited and adopted Athens IT open source software culture. They mostly use JEE in integration projects, mobile apps, etc.;
Main reason for non-adopting open source software solution for financial services was the lack of a strong commercial partner to undertake software maintenance;
Established collaboration with Greek Open Technologies Alliance (GOSS). GOSS participates in Athens projects, such as Technopolis and Digital Labs, https://gopen source software.eu/, https://www.athensdigitallab.gr/en;
Hackathons and contests on Smart Cities are organized, http://crowdhackathon.com/smartcity2/en/, https://www.athensdigitallab.gr/en#contest.
IPR and legal aspects
There is no standard license used, but there is some preference for Apache 2.0;
Trends in the use of open source software
Open source software use will increase reaching up to 50% of all PC users with LibreOffice;
There is a clear tendency to increase open source software use (e.g. through further development on various APIs, single sign on, identity management, intrusion detection systems, penetration testing, use of React/NodeJS); however, there are no plans to switch from Windows to Linux.
Study on open source software governance at the European Commission and selected other European Institutions Page 51
Open source software related policies
No nation-wide open source software related policies exist;
No detailed open source software policy for internal use exists;
GOSS considered the vehicle for promoting open source software initiatives.
Study on open source software governance at the European Commission and selected other European Institutions Page 52
Factsheet – US Government
Summary
The US government has a long-standing preference for open source software adoption by its Agencies. Its most recently released open source software policy (2016) distinguishes this country for the detailed and determined approach it poses on open source software adoption. Another salient characteristic is the measurement mechanism that has been put in place to quantitatively assess Public Agency performance and adherence to the policy. Beyond the central government, important public entities (Department of Defense, Consumer Financial Protection Bureau) are also moving towards more open source, by releasing their own source code policies. In addition, large companies based in the US are increasingly becoming important players for open source software developments and activities, including multi-billion business moves. A central code repository is used for hosting open public code.
Sources
Federal Source Code Policy: https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/ memoranda/2016/m_16_21.pdf, https://sourcecode.cio.gov/
America's primary platform for aggregating open source software from the Federal Government: https://code.gov/
Consumer Financial Protection Bureau Source Code Policy: https://cfpb.github.io/source-code- policy/
Open source at Department of Defense: https://code.mil/
Department of Defense memorandum 'Clarifying Guidance Regarding open source software ', 2009: https://dodcio.defense.gov/Portals/0/Documents/FOSS/2009OSS.pdf
Digital Services Playbook: https://playbook.cio.gov/, https://playbook.cio.gov/#play13
Information from OFSA, Open Source For America, a coalition of private organizations to encourage broader US Government support and participation in open source software projects and technologies: http://opensourceforamerica.org/
NASA open source software repository: https://code.nasa.gov/
Main highlights on open source software use
The US Government strongly promotes open source software development and acceleration. More specifically: Reuse of code among Federal Agencies. A recently released (2016) Federal Source Policy aims to ensure that 'new custom-developed Federal source code be made broadly available for reuse across the Federal Government;
Quantification of code reuse. In a pilot scheme, it is required that a specific percentage of new custom-developed code, set to 20% on a per year basis, is released as open source for three years. Federal Agencies need to collect data to allow the implementation of this policy. Measurement means are specified in https://code.gov/about/open-source/measuring-code;
The compliance of each Agency is constantly monitored and made available to the public, https://code.gov/about/compliance/dashboard;
Study on open source software governance at the European Commission and selected other European Institutions Page 53
Source code made available to the public. Code is shared with the general public, not only among Agencies. Security testing is mentioned as one benefit among other. This attitude encourages private sector companies to shift to an open source software model;
Need to explain why codebase has not been released as open source software. 'Key Question: “If the codebase has not been released under an open source license, explain why” in Digital Service Playbook, https://playbook.cio.gov/#play13.
Technology
The Federal Government has launched a central platform for aggregating open source software. The website includes additional materials such as definitions, evaluation metrics, checklists, case studies, and model contract language, https://code.gov/.
The US Department of Defense (DoD) launched a platform (https://code.mil/) to promote collaboration among the developer community on the Department open source projects. A “Getting Started” section makes things easier for newcomers. Clear guidance on licensing (see below) and contributing code are given to platform users; see https://github.com/Code-dot- mil/code.mil/blob/master/CONTRIBUTING.md.
The Department of Defense has released a Security Technical Implementation Guide (STIG) for the open source-based EDB Postgres Advanced Server database from EnterpriseDB (EDB) https://www.enterprisedb.com/blog/dod-publishes-first-stig-support-government-agencies- deploying-open-source-based-edb-postgres, https://iase.disa.mil/stigs/app-security/database/ Pages/index.aspx.
NASA makes its code available to the general public through its open source software platform, https://code.nasa.gov/. It hosts projects and provides guidance for adhering to federal standards and NASA procedures. There is a heavy use of GitHub, see https://github.com/nasa/open-source-catalog.
Cultural aspects
The Department of Defense, one of the most organised and trustworthy branches of US public services, clearly supports open source (“Clarifying Guidance Regarding open source software ”, 2009);
Consumer Agencies support open source software;
Public money invested in open source software and public code concept publicized, e.g. by the Consumer Financial Protection Bureau (https://www.consumerfinance.gov/about-us/blog/the- cfpbs-source-code-policy-open-and-shared/);
Strong wording is used when supporting open source software adoption: e.g. “we use open-source software, and we do so because it helps us fulfil our mission. Open-source software works because it enables people from around the world to share their contributions with each other. The CFPB has benefited tremendously from other people’s efforts, so it’s only right that we give back to the community by sharing our work with others.” See https://www.consumerfinance.gov/about- us/blog/the-cfpbs-source-code-policy-open-and-shared;
Blogging by eminent government staff in favour of open source software policies, see for example https://obamawhitehouse.archives.gov/blog/2016/08/08/peoples-code;
Study on open source software governance at the European Commission and selected other European Institutions Page 54
Also the Department of Education runs an open source software action (College Scorecard), being education a key area for promoting open source software use, https://collegescorecard.ed.gov/, https://github.com/RTICWDT/college-scorecard;
The Government links open source software with other concepts of openness that are easier to understand, such as open Government, https://obamawhitehouse.archives.gov/sites/default/ files/microsites/ostp/final_us_open_government_national_action_plan_3_0.pdf (released in 2015).
Organizational aspects
Broader scope standards and policies must be observed when open sourcing, e.g., see the NASA platform case above;
Precise Software Analysis Process, considering and prioritizing existing Federal software and open source software, in Federal Source Code Policy, https://sourcecode.cio.gov/Three-Step-Software- Solutions-Analysis;
It is required to “Inventory All Custom-Developed Code and Make It Available Government-Wide”, within a limited amount of time (90-120 days); external inventories are allowed, such as GitHub, https://sourcecode.cio.gov/Reuse/, https://sourcecode.cio.gov/Implementation;
it is required to release 20% of developed software as open source software, https://sourcecode.cio.gov/ OPEN SOURCE SOFTWARE;
Specific exceptions are defined; in case of exceptions, CIOs need to consult with OMB (Office of Management and Budget), https://sourcecode.cio.gov/Exceptions;
“Progress on agency implementation of the policy are primarily assessed centrally (by OMB) through an analysis of each agency’s internal Government repositories, public open source software repositories, and code inventories on Code.gov”, as well as data from various sources.
Agency compliance with open source policy is monitored and reports thereof are publicly available: https://code.gov/about/compliance/dashboard.
Agencies are required to conduct market research when preparing for the procurement of products or services. Market research for software should include open source software. It is requested that for software, including open source software, a plan for software support be adequate: https://cfpb.github.io/source-code-policy.
Redistribution is subject to a number of constraints, including the case where the code is "too crude to merit distribution or provide value to the broader community.' This is maybe also considered a cultural aspect; see https://cfpb.github.io/source-code-policy.
Open Source For America (OSFA), a coalition of all kinds of organisations (government, non- government and private) to encourage broader US Government support and participation in open source software projects and technologies (http://opensourceforamerica.org/). Although their website shows no activity after 2014, it is one example of how different organizations can cooperate to align with government open source software policies. Members reported are Debian, Alfresco, Linux Foundation, Defense Information Systems Agency, AMD, City of San Francisco etc. (http://opensourceforamerica.org/about-osfa/organizational-members/).
Study on open source software governance at the European Commission and selected other European Institutions Page 55
IPR and legal aspects
Rights for Government Reuse and Ensure Delivery of Source Code must be secured: https://sourcecode.cio.gov/Reuse/.
Appropriate open source software licenses to the source code must be appended. Code.gov provides specific guidance on how to do that. Ad-hoc licenses should be avoided, and clear preference is given to standard licenses (mainly Apache and GPL). Examples of their use by Agencies are given under, https://code.gov/about/open-source/licensing, https://sourcecode.cio.gov/ Implementation/.
The Department of Defense recommends attaching an 'intend' document to the license, clarifying how the open source code is meant to be used, https://github.com/Code-dot- mil/code.mil/blob/master/INTENT.md, https://code.mil/how-to-open-source.html. A GitHub webpage helping choosing an open source software license is proposed (https://choosealicense.com/). The Department of Defense takes a different approach and recommends permissive licenses (MIT, ISC, or BSD-3), unless patents are involved (Apache2.0).
Trends in the use of open source software
Open source software use appears to be increasing, considering the new instances of open source software adoption policies, the intensification of monitoring and regulation of open source software initiatives, and agency performance reported in https://code.gov/about/compliance/dashboard.
Open source software related policies
Federal Source Code Policy: https://www.whitehouse.gov/sites/whitehouse.gov/files/ omb/memoranda/2016/m_16_21.pdf
Consumer Financial Protection Bureau Source Code Policy: https://cfpb.github.io/source-code- policy/
Study on open source software governance at the European Commission and selected other European Institutions Page 56
Factsheet – Google
Summary
Google has several unique features that make it a distinct case of open source software adopter among large international companies. Google has been sponsoring open source software activities and events since many years but it goes way beyond this. It uses extensively open source software approaches for its internal code development processes and it actively participates in numerous open source software projects. Google also supports high visibility events such as Google’s Summer of Code154. Google’s Open source software attitude is documented in detail and statistics of Google’s open source software development activities are openly available. An internal organisational component, namely the open source Program Office, coordinates open source software activities within the company.
Sources
Google internal documentation on how to use, release, and support open source software: https://opensource.google.com/docs/
Guides of the TODO Group (https://todogroup.org/), a group of companies co-founded by Google, that are sharing best practices on how to adopt open Source at corporate scale. Guides available at https://todogroup.org/guides/.
Tech press discussion of Google open Source Program Office, e.g. https://opensource.com/business/16/9/google-open-source-program-office
Statistics about the participation of companies into open Source development on GitHub, published by GitHub at https://octoverse.github.com
gLinux announcement https://debconf17.debconf.org/talks/44/
Main highlights on open source software use
Google uses open source software thoroughly for both internal operations—on both servers and workstations—and user-facing IT products and services;
Google releases thousands of open source software products and participates to the development of third-party open source software products they depend upon. Code releases happen mainly via GitHub;
Google finances open source software development via student programs like Summer of Code and Code In, paid membership in open source software foundations, and open source software event/project sponsoring;
The internal Open Source Program Office (OSPO) provides a centralized structure to advise on all open source software related needs, covering legal, strategic, and technical aspects.
Technology
154https://summerofcode.withgoogle.com/
Study on open source software governance at the European Commission and selected other European Institutions Page 57
Google uses open source software thoroughly for its operations. All company workstations run an in-house customized version of the Debian distribution called gLinux (https://debconf17.debconf.org/talks/44/). No specific details released about which open source software components they use on the infrastructure, but the company declares to heavily depend on such components and their technical policies highlight special care for importing, maintaining, and track in the long term their evolution.
Google releases thousands of open source software components, primarily via its GitHub organization account (https://github.com/google). An archive of previously released, but no longer supported components is also available at https://github.com/googlearchive. Android is developed separately at the dedicated site https://developer.android.com.
Google also contributes to third party open source software components and projects by others: at the time of writing this study they are the second most prolific organization on GitHub, in terms of number of contributions (after Microsoft, who has recently acquired GitHub).
Cultural aspects
Google appears to be well aware of the ethos, practices, and expectations of open source software communities and has adapted its internal processes to use, release, and contribute to open source software accordingly.
In particular:
Releasing internal code as open source software is not strongly encouraged - the decision is left to individual teams based on strategic and legal consideration. Yet, when the decision to open source is made, support and facilitation is offered to the relevant teams via the centralized open source Program Office (detailed below); see https://opensource.google.com/docs/releasing/;
Technically, third party open source software components are well-separated from internal code, and assigned developers are responsible for keeping them up-to-date; clear expectations are imposed on users of third party open source software components so that internal code is also kept up-to-date to be compatible with latest upstream development; see https://opensource.google.com/docs/thirdparty/;
Being “good citizens” in the open source software technical ecosystem is encouraged, by providing guidance to employees on how to submit patches upstream, https://opensource.google.com/docs/patching/, participate in hackathons, https://opensource.google.com/docs/hackathons/, and continue the development of personal open source software projects not related to Google, https://opensource.google.com/docs/iarc/.
As part of their being “good citizens” in the broad open source software ecosystem, Google also participates financially in a number of homebrew and third-party initiatives:
o The company started Google Summer of Code, https://summerofcode.withgoogle.com, and Google Code-In, https://codein.withgoogle.com, the two largest world-wide initiatives that fund student participation in (non-Google) open source software projects, with a total of more than 20,000 students financed over the years.;
o Google sponsors third party open source software events, https://opensource.google.com/docs/growing/events/, individuals, https://opensource.
Study on open source software governance at the European Commission and selected other European Institutions Page 58
google.com/docs/growing/peer-bonus/, and organizations https://opensource.google.com/ community/affiliations/.
Organisational aspects
Google relies on the centralized open Source Program Office (OSPO) as a one-stop-shop for most open source software-related needs of the company. The office is relatively small in terms of personnel (about 15 employees) and is independent from specific product branches of the company. OSPO offers guidance and advice, similar to what external consultants would do, on strategic, legal, and practical matters related to open source software use, release, and support at Google. OSPO also defines standardized policies and processes that are constantly maintained and updated to set the best practices that should be followed for all open source software matters in the company. OSPO also maintains lists of various kinds of “good” and “bad” artefacts related to open source software, such as licenses, contributor license agreements (CLAs) and events and acts as a review board for updating those lists.
Google originally introduced the notion of OSPOs, which has since then been adopted by many other large corporations involved in IT. The TODO Group, preferably the most influential industry community of practice around open source software adoption in large corporations, recommends creating OSPO-like structures as a way to streaming open source software use; see https://todogroup.org/guides/create-program/.
IPR and legal aspects
The license of choice for releasing open source software components at Google is Apache2, unless releasing/contributing to an open source software community where a different license dominates, https://opensource.google.com/docs/releasing/preparing/#license.
For internal use of open source software components, most osi-approved licenses are accepted, with the notable exception of agpl due to the entangled nature of the Google software stack and user- facing services; see https://opensource.google.com/docs/using/agpl-policy/.
Google accepts external contributions to their open source software components, be them from individuals or employees, requiring in exchange to sign a standard Contribution License Agreement (CLA). The CLA allows contributors to retain copyright ownership, in exchange of a broad copyright and patent license to Google on the contribution, which includes the right to sublicense the contribution in the future, https://opensource.google.com/docs/releasing/contributions/.
Similarly, Google generally accepts (subject to passing legal review) to sign CLAs in order to have contributions made by company employees accepted in third party open source software components they depend upon; see https://opensource.google.com/docs/patching/.
Trends in the use of open source software
Historically the company has done a lot of open source software internally, using third party open source software components, but not releasing much. In recent years, the trend to contribute more has increased, in terms of release of both brand-new open source software components and patches to third party components, as well as the financial contribution to third party initiatives. This can be observed in:
the growth of programs like Google Summer of Code and Code-in;
the amount of code contributions published over time;
Study on open source software governance at the European Commission and selected other European Institutions Page 59
the number of Linux kernel contributions flowing from Android to upstream Linux.
Open source software-related policies
Company documentation on how they use, release, and support open source software: https://opensource.google.com/docs/.
Guides of the TODO Group, co-founded by Google with other major IT corporations, on how to use, release, and support open source software in a corporate context: https://todogroup.org/guides/, in particular the guide detailing the idea, purpose, and setup of open Source Program Offices (OSPOs) is published at https://todogroup.org/guides/create-program/.
Study on open source software governance at the European Commission and selected other European Institutions Page 60
1.5.Findings from Organisation Analysis The following section summarizes the most salient findings from the analysis of the six organisation of the panel, combined with the knowledge gained from the open source software worldwide analysis.
Technology
Little has been found on specific open source software solutions at government level, as policies avoid naming open source software preferred products. Several details may be found about the technology used by specific organizations (e.g., Google or the Municipality of Athens), but such information is hard to generalize. Nevertheless, France provides explicitly an official list of open source software applications for its public sector.
On the other hand, it was found that governments and other organizations are eager to host their code on public collaborative development platforms. Often GitHub is the preferred choice, but we have seen that the code is hosted on governmental repositories too, such the ones in the US by the Federal Government, the Department of Defense, NASA and Italy. Uploading code and other materials is subject to specific rules, allowing a better control of the amount of code created. Assistance is given to developers in various ways (tools, online guidelines). In addition, at least in the case of the US, an appraisal of the various agencies’ performance is made, through the use of appropriate metrics and continuous measurements.
Finally, some technical areas that were not specifically mentioned in previous versions of the examined policies have been identified in our analysis, namely configuration management, technical architecture, frequent releasing, fast bug fixing.
Cultural aspects
Several cultural issues emerged from our analysis. The clear commitment of high-level authorities seems to have been used to emphasize the importance and benefits of open source software. Strong phrasing has been used often to provoke a cultural shift towards open source software. One of the most often observed principles is ‘Public money, Public code’ which was recently brought forward by a popular FSFE campaign.155
Another point of interest is the expansion of the culture of openness, in terms of open data, open content or open government. It appears that this fact has also influenced people to be more receptive to open source software ideas and products. In addition, the area of education is obviously most important for developing a culture of any kind. Increasing open source software presence, and openness in general, at various levels of education will help diffuse open culture.
Organisational aspects
Four types of organization have been in scope of the analysis for of their use of open source software, namely (a) organizations at government level, (b) non-government organizations, (c) private organizations and (d) open source software competence centres.
In some cases, governments create new departments or agencies, while in other they assign duties related to open source software to existing departments. Such agencies have an inter-ministerial role, covering the entire spectrum of government functions. In one case, namely UK, a community of software architects is used as a means for helping public services decide what code to open and what code to keep closed.
155https://publiccode.eu
Study on open source software governance at the European Commission and selected other European Institutions Page 61
Non-government organizations have been seen in most cases as a way to support the set-up of open source software policies and practices, in the form of coalitions of universities, research centres, etc. They aim at promoting open source software and have a consulting role.
Private organizations seem to be of high importance for the implementation of open source software policies. They take the form of clusters of enterprises that form alliances to exchange experiences and be better represented when providing software services. Although it was observed that these alliances are not always prolific (e.g., in the US), in some countries they seem to be rather healthy and active. It was observed that the lack of strong, reliable, and competent private companies that will provide long time support to public services adopting open source software solutions is a prohibiting factor and can be considered one of the most important barriers for open source software usage expansion.
One last form of organization is the so-called open source software competence centres, either in the form of open source software communities, specializing on specific open source software solutions, or small groups of open source software user communities, institutions and individuals who are interested in open source software. The equivalent, state-of-the-art structure in corporate management are the Open Source Program Offices (OSPOs), providing a centralized go-to entity for all open source software related advice and policy definition.
Finally, the building of communities around government software is gaining attention recently (see the Blue Hats case in France). At least in the case of France, a research centre was founded to provide scientific support in the open issues of open source software products and processes.
IPR and legal aspects
Our analysis shows that licensing is of primary concern to open source software policy makers. In certain cases, specific types of licenses are recommended to open source software adopters (e.g. BSD in Italy), although different preferences may be found within the same country (see for example varying recommendations by US Government and Department of Defense). Hybrid licenses are not to be preferred, as seen from the French case examined.
In any case, policies draw the attention of open source software adopters to the significance of open source software licensing. In France, a separate section of the policy is devoted to explaining licensing, and the term ‘license’ appears 32 times in the 18-page Ayrault Circulaire document. Governments often provide assistance to open source software adopters in terms of tools or process steps to follow in choosing a license and direct them to trusted web pages for explaining licenses details.
Trends in the use of open source software
Open source software adoption (or “passive use”) is increasing over the years, because of (a) new favourable policies, (b) better open source software awareness and increased open source software culture among end users, (c) more, high quality open source software solutions in almost all areas of applications (e.g. Web browsers), (d) increased presence of open source software in the education process, and (e) the results of various open source software initiatives.
Active participation in open source software is also increasing, mainly by the means of releasing software developed in-house or for public services to the public via collaborative development platform. Participation to the development of third-party open source software products is also increasing (e.g., it is a recommended practice in France, in order to exercise technical influence on the future evolution of IT products the public service depends upon) but is not yet up to par with the increase in use and release of open source software by public services.
Study on open source software governance at the European Commission and selected other European Institutions Page 62
Open source software-related policies
Our analysis revealed various new policies in the past few years. Typically, policies may prioritize the use or acquisition of open source software or at least require that open source software be treated on an equal basis with commercial software. In the case of US, open source software is the major option for government software, especially the one developed by US Agencies. On the other hand, absence of explicit nation-wide policies favouring open source software is sometimes observed (Denmark, Sweden, Switzerland, Greece).
A recent trend we observed in modern open source software policies is the requirement of quantified tangible results from open source software adoption. The Federal US policy requires a specific amount of code to be uploaded to the open code central repository, while France is suggesting reinvesting 10% of the savings back in the open source software projects from which public services have mostly benefited. Security is also of primary concern. There are explicit UK open source software policy recommendations related to security.
Study on open source software governance at the European Commission and selected other European Institutions Page 63
2. Review of the current open source software strategy (2014- 2017)
2.1.Introduction This section provides a review of the current EC open source software strategy and the supporting documentation publicly available on DIGIT’s website156. It includes our understanding of the EC approach to implementing open source software internally, and the extent that the implementation has reached.
Additionally, leveraging on the main outcomes of the previous chapter, main differences between the EC open source software strategy and worldwide trends are analysed and an overview of the EC open source software tool inventory is performed. Based on that, a series of preliminary recommendations are proposed. In addition, the ‘EC open source software maturity index’ is reviewed and updated.
Findings and proposals of this section help shaping the questionnaires to be used in the subsequent interview activities with internal and external stakeholders.
The main sources analysed in this part of the study are the following:
EC ‘Open source software strategy 2014-2017’, including ‘EC open source strategy: history157’
EC open source software tool inventory
‘Open source software governance at the European Commission’
EU-FOSSA pilot study158
OSOR collection on Joinup
Chapter 1 - Open source software worldwide of the current study: publicly available information related to the six organisations chosen as worldwide benchmark (excluding EU institutions). 2.2.Review of the EC ‘Open source software strategy 2014-2017’ and supporting documentation The ‘EC open source strategy: history’ section of the EC open source strategy page shows that the European Commission is actively seeking to expand the use of open source software internally since 2000. The EC has produced several versions of its open source strategy, the latest one being that of 2014-2017, which replaced the ‘Open source strategy 2011-2013’. The salient characteristics of the latest strategy are the following:
commitment to continue and expand the EU strategy towards even more open source adoption;
fair treatment of open source software during public software procurement;
preference to open source and open standards in all future IT developments, to ensure, among other software qualities, interoperability;
156Open Source Software Strategy of European Commission, https://ec.europa.eu/info/departments/informatics/open-source- software-strategy_en 157Open Source Strategy history, https://ec.europa.eu/info/open-source-strategy-history_en 158EU-FOSSA Pilot, https://joinup.ec.europa.eu/solution/eu-fossa-pilot
Study on open source software governance at the European Commission and selected other European Institutions Page 64
preference is given to open source software for all internal development projects, including software developed by third parties.
The strategy also establishes that the EC pledges to:
further clarify various internal open source issues of legal nature, i.e. 'licensing schemes, IPRs, equal opportunities in the context of procurement and participation in open source software communities';
further develop guidelines for 'all professional services', including the deployment of open source software solutions to data centres;
continue to develop and adopt best practices and tools from open source software communities, with emphasis on security, while creating open source software communities for the tools developed internally and participating in external open source software communities.
Emphasis is also given to open source software in e-government and to combining internal and external open source software strategies (aligned with and using the results of the ISA2 programme159, which supports the development of digital solutions that enable public administrations, businesses and citizens in Europe to benefit from interoperable cross-border and cross-sector public services).
Finally, according to the strategy, DIGIT is expected to promote partnerships relevant to open source software between EU institutions and other stakeholders.
As an example of the actions taken to implement the pledges taken with the latest edition of the open source strategy:
From the IPR point of view, the EC has significantly progressed in the definition of a licensing scheme for open source software, namely EUPL, the European Union Public Licence160, which may be used in open source software licensing;
On the community building side, the EC has developed Joinup161, the collaborative platform managed by DIGIT, which offers a common working space for e-Government professionals on building, sharing and reusing open source solutions for the EU public sector. Joinup has incorporated OSOR, the Open Source Observatory for European public services, which currently posts news, events and studies on the use of free and open source software solutions in public services;
The EU has also proceeded in the implementation of its open source software strategy internally, using open source software for its data and web servers, user authentication, corporate solutions (including content management, surveying, e-invoicing, e-ordering) and internet browsing. In addition, the EU has adopted Java and open source software development tools for building its information systems.
More extensively, an action plan to implement the latest EC open source software strategy and consisting of the following list of items has been created162: 1. Inventory;
159 ISA2 Programme, https://ec.europa.eu/isa2/isa2_en 160European Union Public Licence, https://eupl.eu/ 161https://joinup.ec.europa.eu/ 162As reported on the Open Source strategy page at https://ec.europa.eu/info/departments/informatics/open-source-software- strategy_en
Study on open source software governance at the European Commission and selected other European Institutions Page 65
2. product management and procurement processes;
3. promotion of standards;
4. external diffusion of EC produced software;
5. open source software-based architecture stack;
6. compatibility of licences;
7. clarifications and recommendations to developers;
8. service around open source software used at the Commission;
9. actions around communities, follow-up, participation.
As these actions are mostly internal, the outcome visible outside of the EC ecosystem consists mainly in the provision of equal opportunities for open source in procurement, the publication of the clarifications for developers, the usage of the open source software in published developments as expressed in the strategy.
The following open source software related actions by the EC have contributed to the implementation of the above action plan. In parentheses the item(s) of the action plan that each initiative addresses.
Table 1 - Open source software related actions by the EC
Actions Description Action plan items
Open source software Full inventory of open source software used at the European (1) tool inventory163 Commission
A repository for sharing and reusing 'interoperability solutions for (1) to (9) public services, businesses and citizens'. As of April 2019, Joinup provided 106 Collections (an example is Connecting Europe Facility), 2792 Solutions, 16342 Events, discussions and news. However, a large number of solutions that are available on Joinup Joinup164 have 0 downloads, indicating lower practical impact than intended. OSOR165, a collection within Joinup, is the Open Source Software Observatory that 'brings news, studies and best practices on the use of free and open source software solutions in public services'. As of April 2019, OSOR hosted 1999 news, 613 events and 371 documents
Interoperability solutions for public administrators, businesses (3), (4), (5) ISA2 166 and citizens167
163EC OSS Tool Inventory, https://joinup.ec.europa.eu/sites/default/files/inline-files/DLV%20WP3%20- %2002_Inventories%20tools%20selection_published.pdf 164https://joinup.ec.europa.eu/ 165OSOR, Open Source Repository, https://joinup.ec.europa.eu/collection/open-source-observatory-osor 166New European Interoperability Framework, https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf 167https://ec.europa.eu/isa2/sites/isa/files/library/documents/isa2-work-programme-2016-detailed-action-descriptions_en.pdf
Study on open source software governance at the European Commission and selected other European Institutions Page 66
Actions Description Action plan items
An EC sponsored event. 'Europe Code Week is a big supporter of (9) Europe coding week168 open source software'169
The EC Bug Bounties program offers monetary reward to (3), (4), (8), (9) EC Bug Bounties developers who find security vulnerabilities in selected open program170 source software
European Interoperability Reference Architecture (EIRA©) for (3), (4), (5) classifying and organising building blocks relevant to EIRA171 interoperability, which are used in the delivery of digital public services
Connecting Europe Facility Digital building blocks to help teams (3), (4), (5) CEF building blocks172 deliver digital public services faster, comply with regulation and make the digital single market a reality
2.3.Update on EC open source software maturity index
2.3.1.Methodology and scope of the Index
The European Commission has designed the Open Source Software Maturity Index as a tool to represent in a summarised way the current situation regarding the use of Open Source Software at the Commission based on available data and sources, into a single summary chart and related score.
The Index is calculated over a five levels-scale:
1) No open source software allowed: There are no corporate products in several areas or there is even enforced use of proprietary software; random use of OSS is possible here and there but without a clear strategy.
2) Technical with no policy (Ad hoc): Individual users or teams are using OSS based on their own decisions or decisions of technical staff, the software selection decisions do not follow proper analysis even if maybe following corporate product management choices.
3) Unit-level policy: Units and teams are using open source software based on unit- or team-based policies though the choice is made properly by analysing the products available in the markets, possibly following product management choices. Open source software gets integrated into the product management.
4) EC-level policy: Single policy exists and is being used; long-term IT goals are taken into account when choosing software; open source software is used as competitive differentiator, also within product management.
168Europe Code Week, https://codeweek.eu/ 169Interview with Alja Isakovic of Europe Code Week on opensource.com, https://opensource.com/life/14/10/interview-alja-isakovic- europe-code-week 170Commission announces bug bounty awards, https://joinup.ec.europa.eu/news/eur-3000-eur-25000 171European Interoperability Reference Architecture, https://ec.europa.eu/isa2/solutions/eira_en 172CEF Digital, https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/Building+Blocks
Study on open source software governance at the European Commission and selected other European Institutions Page 67
5) Driver for change: open source software is used for its innovative aspects; it is also treated as a catalyst for change. Proprietary software is not entirely excluded though.
Inputs for assigning a certain level of usage are both the information gathered through the interviews to internal EC stakeholders and the data from the open source software inventory of the current year (compared where necessary with the data of the previous inventory, held in 2016).
The Index has been calculated separately for the following categories:
Desktops: this category includes all software available and used on the desktops of average (non- technical) Commission users.
Servers: this category includes all software used in the Data Centre and in local data centres.
Collaboration tools: this category includes all tools used for collaboration (excluding software development-related collaboration).
Development tools: this category includes all tools used for software development done within the Commission premises.
Software produced by the EC: this category includes all tools produced by the EC and its DGs / agencies.
Paragraph 2.3.3 provides the results of the calculation by category with the pertinent rationales.
2.3.2.Calculating the EC Open Source Software Adoption Maturity Index
The approach to Open Source Software adoption tends to be different per Unit / DG and even project, so we have to account for differences even within the same category. In order to take this into account, the Index does not assign a single level among the five mentioned above, but tries to identify which is the relative relevance and frequency of the situation represented by each level, assigning a percentage to each level so that their sum amounts up to 100%. Such percentage is used to weigh the scores assigned to each level.
The Open Source Adoption Maturity Index is therefore calculated as follows:
a score is assigned to each level as follows: level 1 – 1 point; level 2 – 2 points; level 3 – 3 points; level 4 – 4 points; level 5 – 5 points;
a percentage is assigned to each level, so to represent how the frequency and relevance of the situation represented by that level;
the value of the index is calculated by summing up the weighted average of the judged percentage, multiplying the score of that level by the percentage identified as above; for example, if in a certain category the weight of level 2 is estimated at 30% and level 3 at 70%, the Index value would be 0.3 * 2 + 0.7 * 3 = 2.7 points.
The calculation method described above is the same as the one used for the previous Open Source Software Adoption Maturity Index, for sake of comparability.
Figure 1 below graphically represents the index calculated for the five categories mentioned above, while the following paragraphs provide the rationale behind the respective calculations.
Study on open source software governance at the European Commission and selected other European Institutions Page 68
Figure 1 - Open Source Software Adoption Maturity Index
2.3.3.Analysis of maturity per category
2.3.3.1.Desktops
Regarding desktop software, the dominance of proprietary software that was highlighted in the previous calculation of the Index continues, especially regarding office automation. Almost all operating systems installed are Microsoft Windows (extremely limited use of Linux is encountered as the only alternative option taken), and in general almost all instances installed on workstations is proprietary software.
The prevailing office suite is still Microsoft Office, to which there are no available alternatives. On the other hand, some open source products are even used on basically all Commission PCs (Firefox, 7-Zip, VLC). However, no major progress in such usage is encountered, based on software inventory data; and the top positions in terms of instances are more or less held by the same products as in the previous inventory.
All in all, the positioning for this area remains between levels 1 and 2, with a slight improvement against the previous Index calculation.
Level Name Argumentation Percentage Score
Almost 100% of operating systems installed are Microsoft No open source Windows, the office suite is Microsoft Office, there are no 1 60% 0.6 software allowed available alternatives and users are not able to use other software even if they would like to.
Product List is relatively stable, in niches where proprietary products are either expensive or not available or where Technical with no 2 limited use of the software would not justify purchasing 20% 0.4 policy commercial products. Some of such products are used on virtually all Commission PCs (Firefox, 7-Zip, VLC).
Study on open source software governance at the European Commission and selected other European Institutions Page 69
Level Name Argumentation Percentage Score
Within several teams or units there are ad-hoc decisions on use of particular tools and products. Some units might even 3 Unit-level policy 10% 0.3 perform a proper market study before choosing a product to use.
The EC open source software policy provides a framework to 4 EC-level policy promote wide-spread use of open source software on the 10% 0.4 desktop.
No recorded cases of open source software use for 5 Driver for change innovative aspects or catalyst for change, it is only replacing 0% 0 proprietary software in certain situations.
Total score 1.7
2.3.3.2.Servers
As for servers, the situation is basically the opposite compared with what found for desktops. Open Source Software is definitely prevailing, following proper analysis of the markets and product management (Unix- based operating systems, databases). Actually, the top software items installed on servers are all open source (Qt, NSPR + NSS, OpenSSL and pyOpenSSL, glibc, libstdc++, libXau and Linux kernel).
However, there is no single policy for choosing software, so even in the servers area, we are still below Level 4.
Level Name Argumentation Percentage Score
No open source 1 Open Source Software is not disallowed in general. 0% 0 software allowed
In many areas, decisions on software choice follow Technical technical choices made in the past and/or without taking 2 with no 10% 0.4 Open Source Software into account or without a policy policy allowing use of Open Source Software in place.
In many areas, the Data Centre is using Open Source Unit-level Software more and more, following proper analysis of the 3 60% 1.5 policy markets and product management (for example, for Unix- based operating systems or databases).
EC-level For Unix-based systems, an EC-level policy obligating 4 20% 0.8 policy migration from Solaris to Linux is in place.
Installation of some specific open source software is Driver for 5 becoming increasingly possible (e.g. MySQL), allowing for 10% 0.5 change a bigger change.
Total score 3.3
Study on open source software governance at the European Commission and selected other European Institutions Page 70
2.3.3.3.Collaboration and web tools
On one hand, a group of collaboration platforms in use at the EC are open source:
DIGIT’s collaboration platform on interoperability matters (Joinup) runs in Drupal; in line of principle, all actions of the ISA2 programme are posted for communication in Joinup, so that a large and collaboration network passes through an open source platform;
another major collaboration site is CIRCABC, which is freely downloadable, multilingual Open Source Software. Contrary to Joinup, CIRCABC addresses groups collaborating in private workspaces.;
FPFIS (Flexible Platform for Information Systems), which is using mainly open source products.
On the other hand, there are widely used proprietary collaboration tools such as:
Confluence, a proprietary collaboration tool by Atlassian, whose EC instance encompasses 83 spaces, mostly concerning IT development projects but also other domains (e.g. support to policy making with the use of IT solutions);
Sharepoint, whose use is closely linked to the office suite and that is still available in most workstations.
The position of open source software in this category is therefore not securely established nor has it seen any major evolution since the last calculation of the Index.
Level Name Argumentation Percentage Score
No open source Some choices have been made in the past (e.g. SharePoint for 1 30% 0.3 software the intranet) and it is difficult to reverse this decision. allowed
Technical Collaboration tools are normally decided at least at the unit 2 with no 10% 0.2 level, but anyway within a list of available solutions. policy
Unit-level Some units may be using open source tools like Drupal for 3 20% 0.6 policy collaboration.
The use of open source for collaboration purposes is well EC-level 4 spread but not homogeneous across the EC, with still a 30% 1.2 policy significant presence of proprietary tools.
There are no major new initiatives involving the use of open source software in a change driving way. However, Joinup is Driver for 5 systematically used to foster collaboration in the open source 10% 0.5 change arena within the EC and towards European public administrations.
Total score 2.8
2.3.3.4.Development
Developers at the Commission are using extensively open source software, however the usage and choice of tools varies considerably depending on DG, Unit or project. There are DGs which do not consider open source
Study on open source software governance at the European Commission and selected other European Institutions Page 71
software at all and others being at the forefront of open source software usage. For example, open source software is indeed largely used as driver for change in DIGIT and several other DGs. At unit / DG level, DIGIT applies extensively the Open Source Software Strategy, which as a general principle states: “For the development of new information systems OSS will be the preferred choice”. There are also different development tools and methods depending on the software being developed as well as due to historical reasons. Anyway, according to the current Open Source Strategy, more than 60% of the information systems developed at the Commission are based on Java. All (100%) of these Java development projects include open source software tooling.
For example, regarding tools for project management, there are two main sets of tools: IBM Rational Tools and the CITnet platform (powered by the Atlassian suite). None of these is entirely open source, however the CITnet platform integrates several open source tools (e.g. SVN, Bamboo) under a single umbrella and promotes a collaborative method of work.
The use and development of open source software begins to be seen also in a more active presence of the Commission in the open source arena, for example in perspective of providing ad-hoc contribution to communities in order to have them contribute back. The expertise gained on Drupal is an example of having a “privilege seat” inside the EC to contribute to communities, and the FOSSA project is also another major step in the same direction.
Level Name Argumentation Percentage Score
No open source Some DGs do not consider open source software for 1 0% 0 software development at all. allowed
Technical with There are DGs where choice of development software is 2 20% 0.4 no policy purely technical, without a policy in place.
Unit-level In some DGs, choice of development software is based on 3 30% 0.9 policy Unit-level policy.
EC-level policy There is a lot of development software available in the Product Management List and recommended for use by 4 30% 1.2 DIGIT and its policies. The OS Strategy explicitly states an OS preference for development.
Driver for The Commission has started studying and implementing a 5 20% 1 change more active contribution to open source communities.
Total score 3.5
2.3.3.5.EC-published software
Software published by EC is mostly done within the ISA2 programme as well as in some units in DIGIT, which is published as Open Source.
Out of the 120 collections in Joinup, 23 of them contain EC software development projects, among which the most active are: IMAPS (Interoperability Maturity Assessment of a Public Service), Eurostat, CAMSS (Common Assessment Method for Standards and Specifications), INSPIRE, ARE3NA (A Reusable INSPIRE Reference Platform), EU Semantic Interoperability Catalogue, SEMIC (Semantic Interoperability Community).
Study on open source software governance at the European Commission and selected other European Institutions Page 72
However, there is no systematic approach to publishing internally developed software code by default. In absence of an explicit policy, at least at unit level, on the publication of internally developed software, developers are not allowed to publish software codes without agreement by the concerned internal stakeholder.
Further steps towards a more active presence of the EC in the Open Source arena require enhanced governance and additional security checks, as well as a “cultural change” presenting some concrete issues (e.g. support that the EC cannot provide, small interest by externals to contribute to EC code, market distortion).
Level Name Argumentation Percentage Score
No open source In general, publishing software as open source is not 1 0% 0 software disallowed. allowed
In general, the developers are not allowed to distribute the Technical with 2 results of their work outside unless decided so by their 10% 0.2 no policy teams or Units.
Unit-level Some units may publish software they produce as open 3 20% 0.6 policy source without knowing about the EC policies.
There is no systematic approach to publish EC open source software code. However, A lot of software stemming from 4 EC-level policy the ISA2 programme is consciously designed to be 50% 2 distributed as open source. Several projects led by DGs are published on Joinup.
Open source software developed under EC initiative is Driver for 5 published to support society changes (e.g. Citizens' 20% 1 change Initiatives, EUSurvey) as well as eGovernment solutions.
Total score 3.8
2.4.Analysis of the gap between Commission’s open source software approach and other worldwide approaches The previous chapter 1 has provided evidence on how open source software initiatives are officially set up and then implemented in a wide set of organisations, both public (in their various branches, central and local) and private. We have seen policies, projects, with varying degree of success, and on-going attempts to effectively adopt open source software at various levels and degrees.
We now analyse in the current sections the commonalities and differences between the EC open source software strategy and the other open source software Strategies investigated in this study (UK, France, Italy, US, Municipality of Athens, Google).
2.4.1.Commonalities
The six strategies examined in depth in paragraph 1.4.3 and the EC open source software strategy have the following major common characteristics:
Study on open source software governance at the European Commission and selected other European Institutions Page 73
1. Long term commitment to open source software. This has been verified in almost all examined cases. Open source software adoption efforts by the EU started in 2000. Compared with the four government organizations examined in deep, we found evidence that France and Italy government started considering open source software officially in 2001, and UK and US governments in 2004.
2. Fair treatment of open source software during public software procurement. This used to be a basic component in all country strategies we have examined, in an attempt to avoid the exclusion of open source software solutions in public tenders, a fact that may occur easily when proprietary products may be the preferred choice for reasons linked to, for example, legacy, licensing and vendor lock-in. In the UK Government strategy this component appeared explicitly in 2009. France has also implemented fair treatment. In the article Issues in open source procurement in the European public sector173 published on OSOR it is reported for France that 'public agencies specifically ask for open source-based solutions in their tenders'. In the US, the Office of Management and Budget (OMB) called for procurement neutrality in 2004. In Italy, the Codice Amministrazione Digitale (CAD) introduced comparative assessment requirements in 2005. Italy even went beyond fair treatment, giving in CAD explicit preference to open source software, when all other procurement factors are equal.
3. Preference for open source and open standards and preference for open source software in all internal IT development projects with emphasis on interoperability. Our analysis shows that the four state policies (UK, France, Italy and USA) have scaled up their stance towards open source software from fair treatment to preference. Open standards adoption is combined with free/open source adoption in the four government policies examined. The UK ICT strategy made open standards mandatory in 2011174 and it currently asks for 'making the source code open and reusable'. France defined the concept of open standard in 2004175, introduced open formats in 2009 and stated preference to ODF, Open Document Format, in 2016176. France enforced open source software in internal development through the République Numérique law in 2016 and the Circulaire Ayrault clearly states preference for open source software. In Italy, preference for open source software was enforced in 2014; the relevant article CAD/68 was modified in 2016 and 2017 to provide more guidance, including open standards and open data formats.
The EC ‘Open source software strategy 2014-2017’ mentions explicitly that ‘for the internal development of new information systems, in particular where deployment is foreseen by third parties outside the EC infrastructure, open source software shall be the preferred choice and used whenever possible’. On the other hand, the ‘EC digital strategy’ released in November 2018, states that ‘open source solutions will be preferred when equivalent in functionalities, total cost and cybersecurity’177. On the other side, although EC policies state preference to open source, we have
173Issues in open source procurement in the European public sector I, https://joinup.ec.europa.eu/document/issues-open-source- procurement-european-public-sector-i 174UK ICT Strategy published on 30 March 2011, https://assets.publishing.service.gov.uk/government/ uploads/system/uploads/attachment_data/file/85968/uk-government-government-ict-strategy_0.pdf 175Digital Economy Law, https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000801164& dateTexte=&categorieLien=id 176Référence Général d’Intéropérabilité, https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=?cidTexte=J ORFTEXT000021254225&dateTexte=&oldAction=rechJO&categorieLien=id and Référence Général dIntéropérabilité, https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=8A644E92C98962BDE82219C596F728FC.tpdila19v_2?cidTexte=JORFTEXT 000032438896&dateTexte=&oldAction=rechJO&categorieLien=id&idJO=JORFCONT000032438891 177European Commission Digital Strategy, https://ec.europa.eu/info/publications/EC-Digital-Strategy_en
Study on open source software governance at the European Commission and selected other European Institutions Page 74
not found evidence of any explicit request for justifying the choice of proprietary solutions and a mechanism/structure for validating such justification reports. We consider this aspect as a difference and will discuss it further in the next section.
4. Delivery of code with open source software terms in the case of external development. We consider that this is a natural interpretation of ‘preferably open technical specifications that can be freely adopted, implemented and extended’ mentioned in component 3 of the EC open source software strategy. This is a practice that is proposed to public agencies in the four countries examined (UK, France, Italy and US).
The UK open source software policy178, in its ‘Define your purchasing strategy’ item, asks to ‘follow government contractual rules and guidelines’ and ‘contracts must (...) be explicit about the ownership of intellectual property involved in the delivery of a technology service (including software code and the business rules that process information between user interfaces and stored data)’.
The French Circulaire Ayrault memorandum specifies (p.15/21) that ‘Regarding specific developments, the State must safeguard its ability to release code in a manner that maximizes its own benefit, regardless of which provider did the development.’ In addition, the Revue stratégique de cyberdéfense179 (February 12, 2018) proposes to make the vendors’ source code available for inspection to evaluators (p. 123/167) recommends the opening of the source code of proprietary products, after they are no more officially supported.
In Italy, the Codice per l’Amministrazione Digitale (Art. 69)180 clearly indicates in paragraph 2 the obligation for the public service to ‘make the source code available, complete with documentation, released in public repertoire under open license, for free use by other public services or legal entities that intend to adapt them to their needs’. Requiring open source software license for acquired software is then an easy way to adhere with regulations/recommendations.
The US Federal Source Code Policy, under art. 4.A (Government-Wide Code Reuse) states explicitly that ‘agencies that enter into contracts for the custom development of software shall—at a minimum—acquire and enforce rights sufficient to enable Government-wide reuse of custom- developed code. Agencies must ensure appropriate contract administration and use of best practices to secure the full scope of the Government’s rights, including—but not limited to—sharing and using the code with other Federal agencies.’
5. Participation in external open source software communities. This is a common factor in all four countries examined and Google. In all cases, public sector personnel are urged to collaborate with open source software communities. Looking at the FOSSA Pilot Study results, we observe that 45% of the EU projects analysed participate in open source software communities. Developers participate in external open source software projects on a personal basis because of legal constraints181.
178UK FOSS Policy, https://www.gov.uk/guidance/be-open-and-use-open-source, https://www.gov.uk/guidance/define-your- purchasing-strategy 179Revue stratégique de cyberdéfense, http://www.sgdsn.gouv.fr/uploads/2018/03/revue-cyber-resume-in-english.pdf 180Linee Guida su acquisizione e riuso di software per le pubbliche amministrazioni, https://lg-acquisizione-e-riuso-software-per-la- pa.readthedocs.io/it/latest/riuso-software/sviluppo-di-software-ex-novo.html 181EU-FOSSA Pilot Study, https://joinup.ec.europa.eu/document/project-deliveries
Study on open source software governance at the European Commission and selected other European Institutions Page 75
6. Technical guidelines for open source software deployment. In the EU context we found evidence that this is achieved through technical guidelines provided through the Joinup platform under the ‘Solutions’ section. In particular, the SEMIC collection offers guidelines and other resources of various nature on the development of interoperable solutions182, while the Discussions area provides a forum for getting technical assistance when reusing Joinup/OSOR hosted solutions. In all four countries examined and Google technical guidance is provided through guidelines offered on central repositories.
7. Adoption of best practice and tools from open source software communities. The open source software pilot study has analysed the practices adopted by both internal EC projects and open source software communities. This study provides several recommendations for open source software community practices that may be adopted by EC internal projects. In general, this is a global trend. A clear example is the use of GitHub as the tool for hosting government code. Using GitHub implies adopting certain typical open source software approaches, such as collaborative software development, issue tracking, following projects and developers and measuring important project activities (code commits). Hosting one organization’s code in a central well-known repository provides more visibility to code releases.
8. Emphasis on open source software in e-government. This is also in line with what happens in all four countries examined and worldwide. Open source software policies are meant to promote open source software solutions to be used in e-government software.
9. Open source software policy is part of broader initiatives. All four countries examined place open source software policies within broader scope initiatives. This is also true in the case of EC policies, considering for example that Joinup is a component of the ISA2programme, which has the broader scope to aim at interoperability and reuse of artefacts among EU public sectors. The EC open source software strategy contributes to the vision of a truly digital Commission by 2022, with effectiveness, transparency, security and borderless public services being the primary goals.
10. Promotion of partnerships relevant to open source software between EU Institutions and other stakeholders. This is implemented through the Joinup platform. All four state policies examined, and practically all other policies worldwide, aim at the reuse of software applications and exchange of information among public agencies, ministries and regional authorities. Google also is organized internally to support the collaboration between its different companies and the Municipality of Athens favours collaboration with external organizations.
2.4.2.Differences
Equally, there are some interesting points of divergence. Most of them are characteristics of open source software strategies that appeared in the years after the release of the EC ‘Open source software strategy 2014-2017’ in the four reference countries (UK, France, Italy, US). As such, they are still under evaluation and should be considered with care. However, by looking at the new components and guidelines of the four countries examined, one can pinpoint major trends in public sector open source software policies. These divergence items listed below will be targeted to form some preliminary recommendations for the future open source strategy. Such items may be revised according to inputs from the interviews. Certain practices
182See https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/our-resources, and in particular guidelines such as the Guideline for Producing Interoperability Assets (https://joinup.ec.europa.eu/document/guideline-producing- interoperability-assets) or the Asset Development Guidelines (https://joinup.ec.europa.eu/document/asset-development-guidelines)
Study on open source software governance at the European Commission and selected other European Institutions Page 76
and activities related to open source software might already be in place within EU Institutions, therefore softening the differences identified. We have grouped the differences around 6 main areas: procurement, licensing, culture and community involvement, organizations, technical solutions and security.
1. Procurement
Detailed justification when proprietary products are preferred over open source software solutions is a key factor to enforce the preference for open source. We found no evidence supporting this concept within the available information on the implementation of the EC open source software strategy. However, it appears to be a consistent practice among countries favouring open source software. A market research is needed before taking any decision and the results of such analysis should clearly and justifiably back any decision to adopt a commercial solution. At the same time, open source software adopters need also to be fully aware of potential costs associated with open source software acquisition, mainly related to installation, parameterization, training, customization, expansion, and maintenance that will affect significantly open source software Total Cost of Ownership. A clear guideline requesting such explanations would provide more insights for when proprietary software is deemed better than open source software by public agencies and would facilitate the development of further open source software policies and initiatives. A special document repository with annotated and semantic information could provide a data base for supporting future decisions on open source software. Making one step beyond that, the EC might opt for central approval for cases of software acquisition costing above a certain threshold, as is the case of the Government Digital Service in the UK
2. Licensing
External license issues. Clarity in external open source software product licenses is complicated for several reasons, e.g., existence of incompatible licenses in the same piece of software, or unseen combination of licenses. France policy is the only one with a clear suggestion to avoid hybrid licenses in external open source software procurement. We have found no evidence of any license constraints for external open source software solutions posed by UK, US or Italy policies.
On the other hand, when adopting external open source software solutions, it is desirable to be assisted by tools for determining the license or the combination of licenses that exist on the code. Such elaborate tools that may be helpful are FOSSOLOGY183 by Hewlett Packard, or software for extracting and combining license information from SPDX184, Software Package Data Exchange. Additional tools, such as the PIA, Private Impact Assessment tool reported in the case of France, may help achieving multiple goals, such as adherence to GDPR or other regulations.
Internal code licensing. EUPL185 is the natural choice for EC code developed internally and this may be seen as a clean approach for open source software licensing. Adopting EUPL is a means to provide a uniform licensing scheme and resolve legal issues stemming from too many, incompatible licenses. However, there are several issues about EUPL that have led to the initiation of an EC project to create a Joinup License Assistant, upgrading the current License Wizard. In the white paper of this future
183An open source license compliance software system and toolkit, https://www.fossology.org/ 184Georgia M. Kapitsaki, Frederik Kramer, Nikolaos D. Tselikas: Automating the license compatibility process in open source software with SPDX. Journal of Systems and Software 131: 386-401(2017) 185European Public License v1.2, 2017 https://joinup.ec.europa.eu/sites/default/files/custom-page/attachment/eupl_v1.2_en.pdf
Study on open source software governance at the European Commission and selected other European Institutions Page 77
tool it is reported that 'EUPL is far from being a unique instrument: there are currently no less than 348 different license texts, that are all different and are also more or less compatible or incompatible'186.
In comparison, the four reference countries have different approaches, in particular:
. All code produced by UK public sector is protected by a Crown Copyright, and then an open source software license may also apply. The licenses are enlisted by OSI on https://opensource.org/licenses are proposed.
. France has its own license, namely CeCILL187, CEA CNRS INRIA Logiciel Libre. It must be mentioned that the France government does not necessarily release under CeCILL. For instance, at https://github.com/etalab a lot of code released under MIT, Massachusetts Institute of Technology, may be found.
. In Italy, BSD, Berkeley Software Distribution, is the license chosen by Developers Italia.
. In the US, different organizations propose at least two different combinations of licenses: the government suggests mainly Apache and GPL, General Public Licence, while Department of Defence suggests permissive licenses (MIT, ISC, Internet System Consortium, or BSD-3).
. Google and the Municipality of Athens have both preference for Apache 2.0.
There are already web sites that provide advice on license selection. FSFE hosts the REUSE initiative188, while the US Department of Defence prefers choosealicense.com189.
3. Culture and community involvement
Open source software adoption is facilitated by the advancement of other open concept technologies. Concepts like open data, open content, open innovation, open science, open government, open education, open hardware have been attracting different audiences and have contributed to the creation of a 'digital commons' movement. Open source software is an enabling technology for all other open activities. A known example is Wikipedia, built over the MediaWiki open source software platform. Explicitly combining open source software initiatives with other open technology/culture initiatives may facilitate EC efforts in fostering open source software adoption and it is worth considering it for a successive EC open source software policy. The Strategic Plan 2016- 2020 of the EC Directorate-General for Research and Innovation190, in its mission statement, aims at achieving 'open innovation, open science, open to the world'. The analysis of the Municipality of Athens and other countries worldwide also revealed such a synergy.
Being the proponent of an EC open source software community. France has recently emphatically announced its Blue Hats community. This is a recent development and its degree of success and impact is yet to be discovered. The EC runs many activities that are related to open source software communities, but there is no evidence of an 'EC open source software community'. Because of its
186Joinup License Assistant white paper, https://joinup.ec.europa.eu/sites/default/files/document/2019- 02/Joinup%20Licensing%20Assistant%20-%20White%20Paper_v1.01.pdf 187CeCILL version 2.1, http://www.cecill.info/index.en.html 188Reuse Initiative be Free Software Foundation Europe, https://reuse.software/ 189Web page assisting users in choosing a license, https://choosealicense.com/, https://choosealicense.com/appendix/ 190Strategic plan 2016-2020 – Research and Innovation, https://ec.europa.eu/info/publications/strategic-plan-2016-2020-research- and-innovation_en
Study on open source software governance at the European Commission and selected other European Institutions Page 78
visibility, such a community would probably attract many members from public sector servants, academy, private company employees, EC IT staff, citizens and journalists. Building the community would reinforce the commitment of the EC to promoting the use of open source software, provide a 'meeting point' for all those interested in open source software within the EU, and help the EC forming clusters of members around open source software issues on which the EC has strong interest (e.g., security). The EC could even entrust specific tasks to clusters of members to accelerate development of open source software towards specific directions foreseen by its open source software policies. Aspects of open source software communities such as community modelling, metrics, and learning opportunities have been already studied extensively by researchers, providing the means for managing effectively such an initiative.
Cultural reinforcement mechanisms such as announcing open source software champions and certifying open source software compliance. As in the case of France, communities are assigned the title of 'Free Digital Territory', after demonstrating that they excel in opening their code, data and content. Individuals and groups that are engaged in open source software are typically proud of their achievements and open source software is often the vocation for many of them (open source software 'enthusiasts', open source software 'evangelists'). A simple but formal recognition of their achievements would encourage them to continue in their activity and it would attract other, not interested up to now, people. It would also help activate passive followers of open source software activities, producing a powerful recruitment mechanism. Recognition can be at a personal level ('open source software champion') or at a unit/division level.
4. Organisation
Open source Program Office. The analysis of France has shown that the creation of certain number of different bodies, each with its own role specialized in different open source software or openness aspects, is needed. This was deemed necessary given the multiplicity, different nature and complexity of open source software related issues. In France, open source software activities are organized around a core group with a coordination role and other groups that are dedicated to specific open source software areas. The concept of a central advisory and support office has been adopted by many other large companies. Google also provides the case of the OSPO, Open Source Programs Office, giving support to a multitude of external organizational entities, the TODO group. A similar organizational structure may be adopted by the EC, with specialized groups for open source software safety, legal matters, innovation, within the context of a central, coordinating unit. Such groups may allow better focus and specialization. The exact organization scheme of these groups and their precise role are left open for discussion.
Research activities around open source software. France has its own research centre, recognizing that several research issues exist around open source software. Other countries examined worldwide have taken similar steps (Italy, Spain, India, Malaysia, Brazil, South Africa), either by establishing an open source software research centre or by funding relevant research activities. A future EC open source software strategy may aim at producing specific questions to the research community that emerge from the adoption of open source software within EC departments and EU Institutions. The EC has several options for supporting such research activities:
. Commission research on specific emerging topics that are of interest to EC open source software strategy. Examples may be the efficiency of fuzz testing for open source
Study on open source software governance at the European Commission and selected other European Institutions Page 79
software191, the design and evaluation of license compliance tools mentioned above, the evaluation or the impact of technical debt in open source software;
. Fund research and development or education on open source through already existing research support programmes such as Horizon2020 or ERASMUS+, as has been already done in the past;
. Formally establish research groups in already existing structures, such as the European Software Institute;
. Establish its own independent open source research centre, considering that open source software is an inter-disciplinary scientific area, combining unique technical, social, economic and legal aspects. Alternatively, commission research tasks to existing research centres within the EU.
5. Technical solutions
Quantify open source software strategy and monitor departmental performance. The EC open source software strategy appears to be purely qualitative in nature: no quantified tangible results are expected to be reported back. On the contrary, the US open source software policy sets a specific target, namely that 20% of the code produced needs to be open. The US has implemented a pilot dashboard scheme for appraising and comparing the performance of governmental entities regarding open source software adoption in general and adherence to open source software policy guidelines. This approach was implemented by asking US Agencies to measure systematically the code they produced and then verify their compliance with the stated open source software policy. Agencies are given the flexibility to choose their own way of measuring their open source software production, in terms of cost, code size and number of components. Google also provides statistics that demonstrate the intensity of open source software production by Google companies.
The EC may adopt a similar mechanism to monitor the implementation of open source software policy by its internal departments. A new EC open source software strategy may require specific percentages of code to be open, potentially setting the threshold higher than the US 20% requirement, to accelerate open source software adoption. Even without setting such a measurable target, requiring code measurements would provide useful insights on the degree of open source software penetration. A further step would be to establish a common measurement method, to ensure that numbers reported back are consistent and comparable.
Central Repository equipped with several tools and guidance for users. The four countries examined have central open source software repositories for the code they produce, primarily hosted on GitHub. Such repositories offer explicit and detailed guidelines which are often implemented through an easy to use interface that shows clearly, step by step, how to open the code and present it to other adopters. The Developers Italia Web site shows how a public sector agency/group may produce open source software together with developers in a collaborative manner. We found that the OSPO office in Google has a similar role, providing support at several levels to open source software producers. Interestingly, Google provides not just open source software code, but open source
191As of 7 Feb 2019, Google opens the source code of its ClusterFuzz testing tool, https://github.com/google/clusterfuzz-tools
Study on open source software governance at the European Commission and selected other European Institutions Page 80
software components, i.e. relatively small size pieces of easier-to-reuse software code in its repository.
OSOR already provides help to users who want to upload their solutions192. On the other hand, the open source software Pilot Study reveals that just 30% of the EU projects examined share information on OSOR. Rethinking the central repository for collecting and making visible EC produced software is important, as such aspect is critical for the effectiveness and impact of the future open source software strategy. A central repository may also provide specialized guidance and reinforce the adoption of good software development practices (see below).
Emphasis on enterprise and technical architecture when considering open source software solutions. Projects involving open source software acquisition are above everything software projects and as such they need to be aligned with an enterprise architecture, including business goals and entities, and become part of a broad IT architecture. In addition, deciding what parts of the code to open may be a decision that necessitates a holistic view, as found in the UK open source software policy. In the case of the Municipality of Athens, it was observed that business processes were modelled together with the adoption of open source software applications, showcasing the link of the business/functional architecture to the technical/application architecture. The EC may want to recommend such an approach and, in this context, support participation in communities of enterprise architects. An example is the Association of Enterprise Architects193 or software/IT architects, as in the case of the UK open source software policy.
Emphasis on good software development practices. The UK open source software policy encourages the application of good software development practices, namely frequent releasing, fast bug fixing, configuration management, time-planning. The Italian Digital Team has transformed non-technical policy recommendations to more technical and therefore more precise and clear guidelines.
In addition, the ‘EC digital strategy’ specifically mentions agile software development among the set of ‘shared capabilities’194. The future open source software policy may draw the attention of internal open source software adopters to such widely accepted techniques. The policy may suggest specific techniques to open source software adopters or provide some guidance for choosing such techniques to meet the goals of the policy.
6. Security
Security of specific components of the open source software policy. In the past few years, open source software security gained importance and specific components of public policies target security issues. A component dedicated to security might be also added within the EC open source software strategy. Such a component could put emphasis on assuring security when adopting open source software, by prioritizing security tests. Specific security problems might be addressed by releasing guidelines similar to STIG (Security Technical Implementation Guide) by the US Department of Defense or the Security Considerations component in UK open source software policy. The French approach, suggesting opening the code when a product becomes obsolete, is also worth considering.
192How to create and manage solutions, https://joinup.ec.europa.eu/document/how-create-and-manage-solutions 193Association of Enterprise Architects, https://www.globalaea.org/ 194European Commission Digital Strategy, https://ec.europa.eu/info/sites/info/files/file_import/digitally-transformed_user- focused_data-driven_commission_en.pdf, pag 24
Study on open source software governance at the European Commission and selected other European Institutions Page 81
2.5.Recommendations on the current EC ‘Open source software strategy 2014- 2017’ From the above analysis, the following recommendations may be derived for the future EC open source software strategy. The recommendations may be either at a high-level, allowing enough flexibility in their application, or precise enough to ensure that specific actions will be taken to fulfil them. They may also be simply mentioned as generic principles and further elaborated later by implementation guidelines. Such new or enhanced strategy components may be discussed during the forthcoming interviews with internal EC staff.
Table 2 – Recommendation areas
Area Recommendations
Clearly re-state and further emphasize EC strong commitment to open source software adoption Emphasis internally
Denote any organizational actions that could help the application of the strategy, by creating one or more specialized units, with predetermined roles and responsibilities. Organize them around a central Organisation open source software Office, comprising technical, legal, and community competences, as a one-stop- shop contact point for all internal open source software questions by EC units
Re-emphasize the need for collaboration within the entire open source software ecosystem (communities, centres of competence, research institutions, private companies). Create and nurture Collaboration an internal EC open source software community, by using both virtual (e.g., mailing list, newsletters, social media) and in-person communication means (e.g., weekly meetings, internal hackathons, early conferences)
Emphasize the role of a central repository for EC public code. The component may identify a Tool placeholder for EC open source software artefacts and may specify any services and tools that will be offered to its users
Emphasize the need for measuring open source software adoption among the EC and selected EU Institutions. This component may be combined with the previous one on central repository and may specify the mechanisms and measures for quantifying open source software adoption. Extreme care Measurement must be taken to avoid misunderstandings, most importantly avoiding the impression that such approach will be used to assess productivity. Rather, it should be clearly presented as a mean to support open source software adopters
Provide further guidance on the use of open source software licenses. Consider producing or adopting tools that either provide expert assistance to internal/external licensers or algorithmic determination Licensing of the superseding license in externally furnished open source software components or applications. This recommendation is already partially implemented through the Joinup License Assistant
Further specify development practices that may help effective open source software adoption. Such Supporting component may be followed by an additional guideline naming development practices explicitly (i.e., practices configuration management, bug fixing, technical architecture, agile methods, application of specific tools)
Emphasize the contribution of the strategy to openness in general and the relationship with other openness concepts. Anticipate the formal recognition of open source software champions, either at Openness individual or team level. Anticipate the formation of an EC community of open source software adopters, referring potentially to organization aspects and events
Study on open source software governance at the European Commission and selected other European Institutions Page 82
Add a component on security to emphasize this aspect of open source software usage. Consider establishing a security-centric culture in open source software development and use, by Security proposing/introducing/enforcing specific approaches to build security features in the software developed
In addition to the above recommendations, we report here the actions proposed by a recent study by French and German researchers195, which are in line with what outlined above. In the ‘All of Iceland's public services moving towards open source196’ published on OSOR it is reported that this study recommends:
‘Helping enterprises use open source software as an economic strategy and grasp the opportunities for co- production. Learning from US experiences with integrating open source into working business models; Enhancing communication within the open source software development community as well as with potential users, strengthening the knowledge base and sharing of best practices between enterprises; Supporting technologies that help find and use open source software; and EU institutions should become open source software users themselves, even more than they already are. This would provide relevant use cases, ensure long-term support, and secure high-level quality control’.
The former three recommendations are relevant to the external environment that is not covered in this study. However, they point to interesting directions for the EC open source software strategy, in particular: (a) collaboration and co-making with enterprises, (b) enhancement of the engagement with open source software communities and (c) support for the development of technologies and tools for managing open source software technical activities.
The latter is directed to EU Institutions and it is in line with the list of recommendations that emerged from the ‘Open source software worldwide study’. The need for strengthening the current strategy and the expected benefits are clearly stated.
195The economic and social impact of software & services on competitiveness and innovation, https://publications.europa.eu/en/publication-detail/-/publication/480eff53-0495-11e7-8a35-01aa75ed71a1 196All of Iceland's public administrations moving towards open source, https://joinup.ec.europa.eu/news/all-icelands-public-admin
Study on open source software governance at the European Commission and selected other European Institutions Page 83
3. Interviews with EC internal stakeholders
3.1.Objective The aim of this chapter is to provide an overview of the results of the interviews conducted with EC internal stakeholders. The outcomes will be further analysed in the next section. 3.2.Interviews overview Eighteen interviews have been conducted for this study with EC internal stakeholders, encompassing the DIGIT Director General, Directors, Heads of unit, developers and technical and project managers. Sixteen interviews have been held face-to-face, two have been held though video-conference.
The key points of discussion with the stakeholders have been the following:
Current open source software strategy 2014-2017: their familiarity with the current strategy, effectiveness, successes and achievements, roadblocks, challenges and issues;
Open source software adoption at European Commission: current adoption and opportunities and barriers of increased open source software adoption within the EC;
Role of open source software in the European Commission digital strategy: potential links with the new digital strategy;
Communities, intellectual propriety rights (IPR) and support: European Commission role vs open source software communities, challenges and opportunities of contribution to open source software communities, IPR implications of using/contributing open source software, technical support of open source software products;
Open source software and organisation: should open source software change and transform the EC and/or mind-set (making DIGIT an open source organisation), impact on corporate processes (Procurement/Finance/HR);
New open source software strategy: vision, areas on which the new strategy should be focused.
We collected and elaborated the input from the interviews and the main highlights have been summarised in the hereunder table:
Area of discussion Main highlights
The EC current strategy has been effective and has served very well its original purpose, ensuring a level playing field for open source software and doing very well what needed especially with Current open source software strategy projects’ execution; 2014-2017 it preserves partnerships with vendors and encourages to experiment open source software; it gives at least a “frame” to sporadic initiatives
Study on open source software governance at the European Commission and selected other European Institutions Page 84
Area of discussion Main highlights
The open source software should be adopted progressively inside the organisation: collaboration between DGs is needed cultural and governance issues for open source software adoption Open source software adoption at inside the organisation. Changing in the culture is needed: open European Commission the project and the code in order to provide the possibility to contribute to it need to find a good mix in make or buy decision (customise and contribute vs. buy)
Open source software can clearly support the development of the Role of open source software in the EC Digital strategy. European Commission digital strategy create a direct Link to Digital strategy and Tallinn Declaration
In order to build new communities, necessity to invest in a big campaign for promoting open source software solutions inside and outside the organisation interesting opportunity would be the delivery of “Proof-of- Communities, intellectual propriety rights Concepts” by open source software communities (IPR) and support IPR is obsolete current legal/contractual rules are not effective (e.g. IPR-related issues of contractors of the EC) necessity to have a clear guidance for Managing open source software Licenses, Legal Aspects, IPR
Low security of open source software need to modernise for both internal and external reasons areas like HR, Budgets/Finance, Document Management necessity to transform the EC into an “open source software organisation” agile methodologies should be brought on a higher level rather than development necessity to promote open collaboration Open source software and organisation necessity to invest in the organisation of events, such as hackathons necessity to emphasise need for open source software awareness among staff, training needs necessity to adapt Procurement Processes to include open source software adoption, support and management risks necessity to re-define EC Product Management, including open source software
Study on open source software governance at the European Commission and selected other European Institutions Page 85
Area of discussion Main highlights
Make the new strategy easier than the previous one avoid lock-in effect (no vendor dependence) focus on legacy system modernisation invest in transparency use champions (influencers) for the open source software promotion New open source software strategy achieve a strong collaboration and cooperation in order to have a “quick-win”, promote open source cooperation and co-creation and agile development processes adopting open source software mentality: reaching a PRO and enthusiastic mind-set moving towards an “open” mentality the future strategy has to change and/or reinforce and address legal and contractual rules
Study on open source software governance at the European Commission and selected other European Institutions Page 86
4. Analysis and recommendations for evolution of the open source software strategy of the European Commission
4.1.Objective and scope The objective of this chapter is to deliver final recommendations for the evolution of the open source software strategy, based on inputs from the study of worldwide open source policy and initiatives, the analysis of the current EC open source strategy and of its implementation, and from the interviews conducted with EC stakeholders.
The study presented in paragraph 1.2 has produced useful information on the state of the art of open source software policies and initiatives worldwide. The analysis of the EC open source software strategy 2014-2017 has compared it with major current trends of six benchmark organizations (Governments of UK, France, Italy, and USA, Google and the Municipality of Athens) and provided some preliminary findings and recommendations. A set of interviews has allowed gathering the opinions of many EC stakeholders on various aspects of the current open source software strategy (level of adoption, successes and failures, role of open source software at the EC, communities’ involvement, legal issues and organization) and their vision of the new EC open source software strategy.
Building on the outcome of the above analyses, in the following paragraphs we will describe the main actions that the EC should follow when outlining the new strategy. We then detail each action into specific recommendations and provide in tabular form a summary of the main benefits and goals of each recommendation and supporting evidence from benchmark organizations study and interviews. 4.2.Recommendations: Analysis, Clustering and highlights In this section we outline the recommendations for the future open source software strategy and their justifications. We have grouped them around seven main common actions. The same clustering proposed below could be used to divide the strategy into sections of components that have a common theme.
Table 3 – Main actions
ID Main actions
1 Emphasise usage and benefits of open source
2 Create an open source dedicated entity that fosters and measures strategy adoption
3 Improve Procurement and Product Management processes
4 Establish an open culture
5 Collaborate with communities/open source software ecosystem
6 Manage legal/license/IPR issues
7 Enhance and develop the technical Infrastructure
1. Emphasise usage and benefits of open source
In the first section of the strategy, the EC should:
Re-state and emphasise its commitment in pursuing the acquisition and deployment of open source software solutions
Study on open source software governance at the European Commission and selected other European Institutions Page 87
List the many benefits of open source software
Link the strategy to major EU political decisions
Present open source software as a public asset and therefore connect it implicitly with public investments and public use.
By repeating and vigorously presenting its commitment to increase the adoption of open source software, the EC will provide a clear message of continuity with previous versions of the strategy. The EC must show its firm and solid position in favour of supporting and promoting the adoption of open source software. In this respect, it would be beneficial if the EC reminded that open source software strategies started evolving since year 2000197 and described the way open source software is produced and delivered and how quality is achieved by communities and open source software supporting companies.
Highlighting the benefits of open source software (openness, transparency, interoperability, independence from vendors, quality, cost savings) will remind the readership of its importance and how the EC perceives open source software and openness in general, covering a communication gap that was observed by several internal stakeholders.
All four governments examined, as well as Google, adopted similar concepts in the communication of their open source software policies, giving clear messages in its favour and praising its benefits. The most recent versions of such policies include sharp wording and particularly strong statements in favour of open source software.
The EC open source software strategy should profit from two recent major developments that have been backed up by senior EU management levels, namely the Digital strategy and the Tallinn Declaration198. Although the Digital strategy only occasionally mentions open source software, it clearly supports concepts that are perfectly aligned with open source, such as agility and transparency. The Tallinn Declaration requires to ‘make more use of open source solutions’ in EU countries and invites the Commission ‘to consider strengthening the requirements for use of open source solutions and standards’ by 2020199.
The EC open source software strategy should define itself as an absolutely necessary step to implement both these European mandates, emphasising its requirements for open source software adoption. The time horizon of 2020 would then make the implementation of such requirements even more urgent. Such a stance was clearly proposed by several internal strategic level stakeholders. In addition, the strategy can mention the concept of digital autonomy and how it is strongly supported by the extensive adoption of open source200. In a recent development, the French Economic, Social and Environmental Council has produced on 13 March 2019 its own policy towards achieving digital sovereignty at a European level, by means of an increasing use of free and open source201.
Ultimately, the EC open source software strategy must consider adopting the ”public money, public code” concept that is becoming popular nowadays. Beyond the logical foundation of such a concept, the Tallinn Declaration mentions that open source software should be the choice ’when (re)building of ICT systems and
197A motto would help towards this direction, following the ‘Be open and use open source’ example of UK (e.g. ‘There is no way to OPEN SOURCE SOFTWARE, OPEN SOURCE SOFTWARE is the way’, paraphrasing Nelson Mandela). 198Tallinn Declaration, Ministerial Declaration on e-Government, https://ec.europa.eu/digital-single-market/en/news/ministerial- declaration-egovernment-tallinn-declaration 199 Tallinn Declaration, p. 6 200France’s economic council wants a greater European role for free software, https://joinup.ec.europa.eu/news/digital-sovereignty 201POUR UNE POLITIQUE DE SOUVERAINETÉ 2019-07 EUROPÉENNE DU NUMÉRIQUE, https://www.lecese.fr/sites/default/files/pdf/Fiches/2019/FI07_souverainete_numerique_europeenne.pdf
Study on open source software governance at the European Commission and selected other European Institutions Page 88
solutions takes place with EU funding’, clearly adopting the ”public money, public code” mentality. Going one step further, the EC open source software strategy might mention the need for more open source expressed by the Tallinn Declaration for the Member States’ public sectors and beyond. Interoperability among public sectors deserves a special reminder here.
At the same time, the open source software strategy must be as realistic as possible, avoiding the pitfalls of straightforward open source software adoption with no previous careful thinking and analysis. The open source software strategy should recommend adopting open Source solutions wherever possible but avoid mandating adoption everywhere. The recommended approach is to adopt “open source software by default“, requesting explicit motivations for the adoption of non-open source software solutions.
Regarding internally developed code, a similar approach may be followed: the strategy should advocate for releasing internally developed code as open source software by default, leaving a window open for keeping the code closed and requesting explicit motivations for the lack of open source software release, e.g., when sufficient evidence exists that opening could be harmful. A motto would also help towards this direction, like for example ”evolution, not revolution”.
To safeguard the above-mentioned aspects, the open source software strategy should request justification by software acquiring EC entities, be it open source software or proprietary software, for the real need to change products and/or processes that led them to make their decision. Beyond that, software acquirers will have to prove through sufficient analysis that (a) enough support is guaranteed for their chosen solution and (b) that the Total Cost of Ownership of the solution they adopt is bearable and at least comparable with that of other open source software/proprietary solutions.
The following table summarises the goals and benefits of this action.
Table 4 - Emphasise usage and benefits of open source – recommendations highlights
Id Recommendation Benefit(s) / Goal(s)
R1 Re-state and Emphasise EC Remind the audience of the importance of open source software Commitment and the commitment of the EC towards it and openness in general Ensure continuity with previous versions of the strategy Remind the audience of the longevity of the EC open source software strategies Promote open source software adoption Enhance perception of firmness and solidity in EC choices on open source
Study on open source software governance at the European Commission and selected other European Institutions Page 89
Id Recommendation Benefit(s) / Goal(s)
R2 Be Pragmatic: Avoid negative effects from open source software adoption to Do not impose the use of open source maximize ROI software Adopt open source software to address realistic needs Adopt open source software Increase the knowledge base about the costs of open source with care and when actually software adoption needed Increase the knowledge base of adoption and non-adoption cases Take into account Total Cost Avoid opening the code in specific cases (security) of Ownership / maintenance / Ensure a steady but safe trend towards open source software exit costs when adopting adoption open source software Avoid pitfalls Implement only when necessary Mitigate resistance to open source software adoption Open code when appropriate Reduce the negative impression to proprietary software vendors “Evolution, not Revolution” Maximize benefits Principle Provide strong reasoning when adopting open source software Build confidence in open source software Increase the number of open source software supporters within the EC
R3 Extend the usage of open source Help EU Institutions improve their IT and level of digital democracy through EU institutions, without (in terms of transparency) enforcing its adoption Avoid negative reactions Increase open source software adoption beyond the EC Achieve homogeneity between EC/EU Institutions Increase participation in EC open source software initiatives and projects
R4 Direct Link to Digital strategy and Establish a feeling of necessity for open source software adoption Tallinn Declaration: Promote open source software adoption Present the open source Mitigate resistance to open source software adoption software strategy as a means Foster strategy adoption for implementing the Digital strategy and fulfilling the Tallinn Declaration Provide links and mental associations to the Digital strategy principles and directives Emphasize the emerging concept of Digital Sovereignty
Study on open source software governance at the European Commission and selected other European Institutions Page 90
Id Recommendation Benefit(s) / Goal(s)
R5 Better Communication of open source Be explicit and increase awareness about open source software and software benefits, initiatives, delivery its benefits process: Reduce resistance Briefly describe the way open Emphasize the longevity of EC open source strategies and initiatives source software is produced and delivered and how quality is achieved Mention explicitly open source software benefits (in terms of transparency, independence, quality, cost savings) Mention previous, current and future open source software related initiatives
R6 Encourage open source software Increase open source software adoption beyond the EC public use among citizens, students Emphasize EC commitment to open source (and Member States for Increase open source software competences in EU interoperability): Increase participation in EC open source software initiatives and EC encourages open source projects software adoption among EU citizens Help achieving the goals of ISA2 programme Emphasize open source software adoption and awareness in education Encourage Member States to adopt open source software in general, especially as the only way for interoperability among EU public sectors
R7 “Public money, public code” principle: Send a clear message in favour of open source software and its link Adopt the principle and its with democracy reasoning Send a friendly message to open source software communities and Propose the principle to other stakeholders supporting the principles Member States Foster open source software adoption Increase visibility for EU funded software projects
2. Create an open source dedicated entity that fosters and measures strategy adoption
The EC needs to provide better support to open source software adopters at the organizational level. The strategy should anticipate the creation of one or more organizational entities with the specific role of supporting and monitoring the implementation of the strategy itself. A dedicated unit would guarantee the
Study on open source software governance at the European Commission and selected other European Institutions Page 91
delivery of concrete results and help closing the gaps that emerged from the interviews with internal EC stakeholders (i.e., lack of communication of the EC ‘Open source software strategy 2014-2017’, lack of support for taking open source software related decisions, lack of information and facts about specific open source software solutions, lack of knowledge on how to manage open source software and resolve problems that emerged). The role of such an entity will become more specific in the following components of the strategy.
The entity may take one of the following forms:
Program Office unit within the EC. A natural choice would be DIGIT, but it could also be elsewhere, for example within a DG with particularly strong know-how in open source software. This approach has been adopted for example by France and Google.
Competence Centre, either in the form of a blended solution (one EC unit with external partners) or an external unit residing outside the EC, where support and monitoring is outsourced to an external public or private entity.
Working Group composed by individual partners, both EC units / employees and external stakeholders.
Although each option has its own pros and cons, we recommend adopting the Program Office option, as it would best fit the current need of increasing the effectiveness of the strategy by allowing for more control and guidance over open source software adoption. Such solution has already been implemented with positive results by large public and private organizations.
A Working Group could be a “softer” and more agile solution; in this sense, it has been proposed by internal stakeholders during the interviews.
A second important aspect is the need for measuring open source software adoption within the EC. During our interviews with internal EC stakeholders, uncertainty over the degree of success of the current strategy emerged. Different interviewees produced contradicting opinions, caused by the lack of concrete empirical evidence. In addition, certain interviewees called for more ‘precision’. This issue is more related to the organization and management of the open source software endeavour in the EC rather than a technical one.
Introducing KPIs/metrics for open source adoption and measurement mechanisms will allow a ’management by metrics’ approach.
The entire set of KPIs/metrics needs not being anticipated at the time of the open source software strategy release, as there are many different measurement approaches202 and potential candidate metrics, including the currently proposed open source software Maturity Index. The exact KPIs/metrics may be negotiated with the relevant DGs and/or EU Institutions. The dedicated entity may undertake the role of coordinating their development, providing relevant know-how.
Quantification of activities would provide the basis for building a measurement database, helping the dedicated entity in its adoption assessment role. In addition, measurements would help identify individuals or teams that excel in open source software adoption and allow their designation as ’open source software Champions’.
202An example is TAM, the Technology Acceptance Model
Study on open source software governance at the European Commission and selected other European Institutions Page 92
To avoid any negative effects, the strategy should strongly emphasise that measurements will be used to identify problematic areas to be able to provide further support, rather than measuring the productivity of individuals or units in adopting open source software.
The US policy has established an explicit measurement and monitoring mechanism, while the French government has proposed a specific amount of investment returned to open source software projects by agencies adopting them. France also provides the example of ’territoires libres’ for distinguished areas of open source software adoption.
The following table summarises the goals and benefits of this action.
Table 5 - Create an open source Organizational Entity - Recommendations highlights
Id Recommendation Benefit(s) / Goal(s)
R8 Anticipate the creation of an open Send a clear message for EC commitment source software dedicated Provide consultation for open source software adoption (when to organizational entity in the form of: adopt, whether it is an option or necessity in specific cases, how to Program Office: an perform cost benefit analysis) organizational unit within Leverage on OSOR content EC (DIGIT or elsewhere) Maintain the central code repository Competence Centre: it may Maintain the KPIs/Metrics for open source software adoption be outside EC (outsourced to a public or private entity) Ensure that operational needs consider the functionality offered by open source software solutions to avoid ‘gold plating’requirements Working Group: can involve individual partners both EC Maintain the open source software catalogue units/employees and Provide technical support for selected, already adopted open source external stakeholders software solutions Monitor and report EC open source software strategy implementation levels Exchange information and know-how on best practices in open source software adoption within the EC (potentially EU Institutions as well) Organize events focusing on specific EC open source software issues Propose initiatives fostering open source software adoption
Study on open source software governance at the European Commission and selected other European Institutions Page 93
Id Recommendation Benefit(s) / Goal(s)
R9 Measure open source software Send a clear message both externally and internally that open source Adoption: software adoption will be monitored throughout the implementation Introduce the use of of the strategy KPIs/metrics of adoption Avoid the feeling of being monitored for productivity purposes Emphasize that among EC staff measurements will be used Increase the control over the activities implementing the strategy to identify problematic Quantify open source software adoption and provide data for areas not problematic statistical analysis and improvement of the current open source people software maturity index Introduce the concept of Provide hard evidence to the dedicated unit on the implementation open source software of the strategy and the emerging issues Champions at a personal or Reward open source adoption efforts unit level within EC
3. Improve Procurement and Product Management Processes
The following recommendations aim at improving EC processes to better reflect the open source software strategy and ensure that other recommendations are facilitated and implemented effectively. Certain aspects of such recommendations are already present in the current version of the strategy, but they need to become clearer and more succinct in the new one.
The first recommendation is to adapt the procurement processes to make open source software adoption easier and allow more external providers to include open source software in their offerings. Initially, the strategy may refer to existing procurement practices that enable open source software adoption. In particular, the strategy may remind the readership that procurement of open source software is already possible through subcontracting, as procuring companies are entitled to subcontract open source software provisioning to collaborating SMEs. The strategy may also emphasise the increased role of the procurement personnel in the new processes.
Next, the strategy should envision a procurement process that will further facilitate open source software adoption. The strategy must repeat EU support to SMEs and foresee an increased role of SMEs in the future implementations of open source software within EC or EU institutions. SMEs could be encouraged to participate in EC software procurement, e.g. by registering and using the EU e-tendering platform203. To implement a clear procurement process that favours fair use of open source software, the strategy should:
Introduce the concept of multi-annual budgeting, allowing EC units to calculate multi-year exit costs from proprietary, lock-in situations towards open source software, multi-vendor solutions.
Ensure that open source software will be considered in all cases of procurement, with the EC organizational support (through the dedicated entity). This means that in all cases a software market analysis will be requested, and such analysis must consider explicitly suitable open source software
203EU e-Tendering site: https://etendering.ted.europa.eu
Study on open source software governance at the European Commission and selected other European Institutions Page 94
market offerings. The dedicated entity will provide and maintain information on existing open source software market through its software catalogue.
Ensure that no proprietary software is acquired when the offering by the open source software market can cover the requirements of the acquiring units. This means that some control must be exercised over the software requirements to avoid ’gold plating’204 that may lead to the exclusion of both open source software and proprietary offerings. For such purposes the requirements may be screened by the dedicated open source entity and suggestions may be given to the acquiring units to avoid gold plating.
State a clear preference for open source software when all other factors are equal. In case that differences between open source software and proprietary offerings are minimal (in terms of cost and quality) open source software must also be preferred for its inherent benefits. Such a recommendation is a straightforward implementation of the Digital strategy205.
Promise that enough resources will be made available for the additional effort needed to allow direct procurement by SMEs.
On the other hand, the strategy should safeguard the concept of evolution, not revolution towards open source software, by ensuring that:
Adoption benefits counterbalance exit cost. Open source software adoption is justifiable only when a change in the IT architecture is really needed and when it offers significantly better solutions than the proprietary software already in use.
Support, risks and costs be carefully examined and assessed in the case of proprietary software. The dedicated entity can significantly assist in this respect, both by providing models and know-how on how costs and risks calculation/estimation and by maintaining a knowledge base consisting of past open source software acquisition cases.
Procurement processes are affected by the policies of all four governments examined. The proposed recommendations are tailored to the specific characteristics of the EC and are heavily influenced by the information and opinions collected during the interviews with internal stakeholders.
As a second process-related recommendation, the strategy may redefine/re-establish an EC Product Management process, with specific care for open source software solutions. Whether acquired from the market or developed internally, open source software product planning, forecasting and deployment needs to be managed. Product management will reduce the problems that have been identified during the interviews with internal stakeholders, in particular the lack of visibility of the installed versions of open source software components.
In this respect, the strategy can call for a new edition of the EC Product Management Process. The EC Product Management process will assure EC open source software adopters that open source software products will be properly managed and will provide hard evidence to the dedicated entity on the implementation of the strategy and potentially emerging issues. The dedicated open source entity could be the product owner/manager of open source software products installed in multiple sites within EC DGs and EU institutions. Acquiring units may be the owners/managers of open source software solutions they adopt
204Gold Plating in this context means adding unintentionally extra features or functions to a piece of software that are not really necessary, potentially leading to the exclusion of otherwise valid candidate solutions 205‘...Open-source solutions will be preferred when equivalent in functionalities, total cost and cybersecurity...’, p. 7 in https://ec.europa.eu/info/sites/info/files/strategy/decision-making_process/documents/ec_digitalstrategy_en.pdf
Study on open source software governance at the European Commission and selected other European Institutions Page 95
individually. Internally produced open source software products should be owned/managed by the development internal EC units.
There is no sufficient information on product management among the six organizations examined, therefore this recommendation is based solely on evidence from the interviews conducted with EC stakeholders.
The following table summarises the benefits and goals of this action.
Table 6 - Improve Processes - Recommendations highlights
Id Recommendation Benefit(s) / Goal(s)
R10 Adapt Procurement Processes to include Send a clear message for EC commitment to open source software open source software adoption, support Ensure that no proprietary software is acquired when the offering and risks management: by the open source software market can cover the needs. Refer to the existing Ensure that EC procurement staff is not blamed in any way for the procurement practice that reported reduced open source software adoption within EC enables open source software Ensure that adequate support will be provided by the dedicated adoption unit Envision a procurement Ensure that open source software is adopted only when a change process that will further is needed and only when it offers significantly better solutions facilitate open source software than proprietary software adoption Facilitate open source software adoption by allowing for multi- Anticipate the increased role of annual budgeting and direct procurement by SMEs SMEs in the procurement of open source software solutions Reduce vendor lock-in to EC and beyond Provide inputs to the EC knowledge base of open source software Encourage SMEs to use the adoption cases current EU facilities for e- tendering Introduce the concept of multi- annual budgeting Ensure that open source software be considered in all cases, with the support of the dedicated unit Ensure that open source software support, risks and costs will be equally treated as in the case of proprietary software State clear preference to open source software when all things are equal
R11 Re-define EC Product Revive the product management concept within the EC Management, including open Make sure that product management will consider open source source software software characteristics.
Study on open source software governance at the European Commission and selected other European Institutions Page 96
Id Recommendation Benefit(s) / Goal(s)
Reassure EC open source software adopters that open source software products will be properly managed Provide hard evidence to the Programme Office/Competence Centre on the implementation of the strategy and the emerging issues
4. Establish an Open Culture
Open source software may be seen as one component of a generic tendency towards public commons and openness. The new EC open source software strategy should take profit of this fact to achieve its goals, drawing the attention of both EC employees and external stakeholders. To this end it is recommended that the strategy integrates open source software-related activities within an open culture and mind-set that the EC wants to establish and foster among its employees.
Taking profit of the Digital strategy content and recommendations, the strategy must promote an open mind- set, re-stating EC tendency towards open standards, even when proprietary solutions are used. The strategy needs to emphasise the concepts of reuse and sharing, collaboration, co-creation and innovation, reminding its readers that the aforementioned concepts are inherent to open source software. Open source may be presented as an example of strong, effective and ultimately successful example of co-creation. Following the open source paradigm, co-creation may be proposed as a major approach for actually improving all EC processes and achieve higher performance levels.
Open standards deserve special attention as they are the means for achieving interoperability among systems developed by different vendors and with different technologies. The worldwide analysis has shown that open initiatives start from establishing the use of open standards and then proceed with favouring open source adoption. Open source policies are inevitably combined with the use of open standards. This has been highlighted in the current version of the EC open source strategy. However, EC interviewees have pointed out that open standards are not prevailing everywhere, especially in office automation. The new strategy must explicitly repeat its preference for open standards and request their adoption in all application areas.
Moreover, the strategy may draw the attention to the common characteristics between open source software and agility, mentioning the notions of common code ownership, incremental delivery, focus on people, response to change and emerging teams206. In addition, the relationship between open source software and further software development techniques that are becoming consistently more popular, namely inner sourcing and DevOps, should be mentioned, to further emphasise how natural the choice is for more open source software within the EC.
Inner sourcing deserves special attention, as it was shown during the interviews that it is becoming a popular approach among EC developers. Inner sourcing produces several benefits of open source (among them code transparency, common code ownership, increased quality, developer motivation). The strategy may point to
206Agile Manifesto, https://agilemanifesto.org/
Study on open source software governance at the European Commission and selected other European Institutions Page 97
inner sourcing as a best practice and seek to promote it as the standard way of developing software within EC.
In this context, the strategy may also emphasise the need for a holistic, enterprise-wide approach when considering the adoption of open source software, explicitly mentioned by the Digital Strategy207. As all these cultural aspects refer to all levels of EC personnel, the strategy is the right place to encourage all staff levels to actively participate in the new landscape with their efforts and ideas.
In the same vein, the strategy can position open source software within other openness and transparency initiatives that are currently drawing the attention of the broad audience in Europe and beyond, and sit at the core of the Digital Strategy. In particular, the open source software strategy should state that open source software is in line with the notions of open Data and open Government. It should also emphasise that open source software is a key component of Transparency.
Finally, it is mandatory that the EC actively trains staff personnel on how to deal with open source software at all levels. The strategy must recognize that handling open source software necessitates specific information, knowledge and skills. The strategy may recognize that there is a lack of knowledge of open source software principles and features among EC personnel and that such a gap may be a potential barrier to its adoption. The strategy should promise to use any available means for increasing the levels of knowledge of open source software, by:
Insisting in informing EC personnel on new developments in the open source software ecosystem to guarantee sufficient levels of awareness
Caring for the development of open source software related skills. Knowing how to initiate, coordinate, evaluate or participate in an open source software project needs to become part of the professional skills of EC DG staff.
The cultural aspect is particularly strong in the cases of all six organizations examined in the worldwide analysis of open source strategies. The strategies of the four governments seek to establish an open culture (through the adoption of open source, open standards, open data practices). It is interesting to note that an open culture was the single most enabling factor for open source adoption in the case of the Municipality of Athens, a public organization that has not declared publicly a strong tendency towards open source software. Open culture and mind-set have also been advocated by many internal EC interviewees. Moreover, the above recommendations are strongly supported by the Digital strategy. Training on open source software comes as a natural consequence if the involvement of the EC staff in open source software is to become mainstream activity.
The following table summarises the benefits and goals of this action.
207EC digital strategy 2018, p.26, https://ec.europa.eu/info/sites/info/files/strategy/decision-making_process/ documents/ec_digitalstrategy_en.pdf
Study on open source software governance at the European Commission and selected other European Institutions Page 98
Table 7 - Establish an Open Culture – Recommendations highlights
Id Recommendation Benefit(s) / Goal(s)
R12 Promote an open Culture. More State the need for an open culture in everything, not merely specifically: software development or use Promote open standards Re-emphasise the need for using open standards, even when Promote co-creation proprietary solutions are used Promote Innovation Describe the need for collaborating, co-making, innovating and how open source software facilitates these Combine open source software with SW development methods Re-state the agile principles behind Digital strategy and the need encouraged by the Digital for modern, cooperative approaches to developing software Strategy (agile methods, inner sourcing, DevOps) Refer to the need for an Ensure that a holistic view is taken when adopting open source enterprise architecture software approach Ultimately, encourage bottom layers to become change drivers
R13 Position open source software within Place open source software adoption into the big picture of open other openness initiatives data, open government and open budgets Present synergies between open initiatives and how they will help establishing a transparent EC
R14 Emphasize the need for open source Recognize that there is a lack of knowledge of open source software awareness and training needs software principles and features among EC personnel among staff Identify this gap as one potential barrier for open source software adoption Commit to sufficient training of EC staff for coping with any open source software adoption needs
5. Collaborate with Communities/open source software Ecosystem
The community aspect is one of the strongest attributes of open source software projects. Open source software has created a vast and extremely dynamic ecosystem, with interacting components consisting of projects, communities, private companies, public/NGO organizations, research and education institutions or agglomerations of such components in the form of associations interested in open source software. The new strategy should remind the readers of this fact and proceed with detailing how the EC will become an eminent member of an active participation in the open source software ecosystem and take profit from it. A primary goal of this component of the strategy would be also to help the EC further improve its image among external open source software participants.
Initially, the strategy should acknowledge the value of open source software communities and express a strong interest in the participation in, collaboration with, and investment on the open source software ecosystem. The strategy needs to urge EC staff, both IT personnel and end users, to contribute to the open source software communities and projects of interest. Any kind of contribution would be valuable (bug reports, participation in support forums, contributing patches, becoming active developers/maintainers). The opportunities for learning ways of work, technical implementations and new technologies while working with
Study on open source software governance at the European Commission and selected other European Institutions Page 99
members of a community or by merely inspecting open source software artefacts, may be also mentioned as direct benefits for EC staff. The strategy must also recognize the eminent role of European SMEs that offer services over open source software products and anticipate an increased collaboration with them (see also the recommendation on procurement).
Next, the strategy should praise the benefits of organizing joint in-person events such as hackathons, conferences, and workshops with members (individuals or groups) of the open source software ecosystem. The strategy can anticipate the intensification of such events in order to achieve its goals. In addition, the strategy will promise to continue informing Europe on the outcomes and achievements of such events to increase visibility.
To facilitate the participation of EC permanent staff in the open source software ecosystem, the strategy should guarantee that such activity (work with communities, participation in community regular meetings or events) will be permitted by default. It needs to be formally recognized as part of the personnel allowed tasks and be declared in individual work timesheets. Moreover, the hiring of external open source software participants on a case by case basis may be anticipated, to mitigate problems related to lack of know-how or shortcomings in manpower.
The community aspect is prevalent in all four government organizations examined and Google. All these organizations encourage collaboration and reuse of assets among the organization staff and participation in open source software projects. In the case of France, an ad hoc community, namely Blue Hats, has been created in 2018 to promote openness and collaborate on it. France is also anticipating an increased role of SMEs in projects related to cybersecurity. In the case of the Municipality of Athens, although no explicit policy for open source software exists, collaboration with external stakeholders and participation in community activities is also quite evident. The need for formally recognizing EC staff participation in open source software ecosystem activities was raised during the internal interviews.
The following table summarises the benefits and goals of this action.
Table 8 - Collaborate with Communities/open source software Ecosystem – Recommendations highlights
Id Recommendation Benefit(s) / Goal(s)
R15 Collaborate with and invest in open State clearly the benefits and the need for collaborating with the source software Ecosystem: components of the rich open source software ecosystem (open Collaborate with open source source software volunteer communities and projects, open software communities source software organizations, associations of open source software companies, competence centres, any open source Collaborate with open source software related professional, research or educational entity) software supporting SMEs Emphasize the need for officially recognized involvement of EC Anticipate an intensification of staff in open source software communities and projects events related to open source software and open Emphasize the need for more joint events, including conferences collaboration and hackathons, and dissemination of EC open source software initiatives Improve the opinion of open source software communities regarding EC stance on open source software
Study on open source software governance at the European Commission and selected other European Institutions Page 100
Id Recommendation Benefit(s) / Goal(s)
R16 Clarify and regulate EC contribution to Facilitate justification for EC staff involvement in external open open source software Projects source software activities Foresee the hiring of open source software participants for implementing specific tasks in open source software projects of interest for the EC Consider creating an ‘Open Fund’ account that will gather potential monetary contributions by EC units for supporting selected open source projects of special interest
6. Manage Legal/License/IPR Issues
All government organizations examined provide guidance about open source software licenses. However, there is no clear and consistent recommendation towards primarily using one type of license. France has its own open license, but it does not demand its use everywhere. In the case of the US, it is advised to accompany open source software code releases with an ‘intent’ document, clarifying the purpose and scope of opening the code.
Our recommendation is that the strategy must be flexible when dealing with open source software licensing, by considering the use of both EUPL and the generic, popular open source software licenses.
The strategy needs to reconfirm the need and importance of open source software licensing. In addition, the strategy may acknowledge the problems that the multitude of existing open source software licenses may create to open source software adopters. The readers may then be reminded of EUPL and the benefits of license homogeneity across Europe that it offers for open source software produced within EC. The strategy must allow some freedom in choosing other popular open source software licenses when releasing open source software code. For externally furnished open source software code the strategy should refer to the dedicated entity for providing guidance whenever open source software adopters need support for license or IPRs in general. In this respect, the dedicated EC open source entity needs to (a) be adequately staffed, and (b) maintain detailed licensing information within the open source software catalogue it will maintain. Following the example of France, the strategy may also call for handling hybrid licenses with extreme care, as they convey the risk of vendor lock-in.
The following table summarises the benefits and goals of this action.
Study on open source software governance at the European Commission and selected other European Institutions Page 101
Table 9 - Manage Legal/License/IPR Issues – Recommendations highlight
Id Recommendation Benefit(s) / Goal(s)
R17 Provide guidance for managing open State the need for appropriately licensing open source software source software Licenses, legal aspects, produced by the EC IPR: Mention the usefulness of EUPL for uniform treatment of EC open Refer to the importance of source software licenses open licenses Allow the use of open source software licenses when deemed Refer to the complexity of open appropriate source software licenses and Remind the consultation support that will be offered by the open the need for coping with them source software dedicated unit and the open source software catalogue Avoid the complications and risks of open source software licenses
7. Enhance and develop the technical infrastructure
The implementation of a successful open source strategy will be greatly facilitated by providing EC staff with an appropriate technical infrastructure. Mentioning specific technical activities and support systems will make the strategy appear more specific, convincing and pragmatic.
Initially, the strategy should refer to the need for a central code repository, combined with the existing observatory. The strategy may refer to the benefits of a repository (GitHub or GitLab like) that would facilitate the adoption of standard open source software practices. Such practices include collaborative software development, issue tracking, following projects and developers and awareness of important project activities (in particular code commits, bug fixings). Moreover, the repository will facilitate the involvement of external open source software participants in EC software projects.
Adopting a central code repository approach will allow the provisioning of advanced services to EC open source software adopters, such as the Insight facility of GitHub for measuring project activities. Hosting the EC code together with other major open source software community and government projects will allow more visibility for new code releases and will enforce the aspect of being an active member organization of the open source software ecosystem. The observatory may be seen as the communication vehicle of the proposed central code repository, intended to reach a broader audience than an open source software repository.
All six organizations examined have adopted a central code repository approach and used GitHub for such purpose. We recommend hosting the EC code on any major open source development platform due to the need of reaching out to the developer community that is primarily there nowadays. However, we also recommend making sure that the code is periodically archived in independent repositories, run by either the EC or other projects. Independent archiving will help achieving the digital sovereignty aspect mentioned above.
The strategy should also envision a website that lists all open source software products released by the EC and all EC code contributions to non-EC open source software products. We have evidence of almost all large institutions (public or private) doing so to promote their images of good citizens of the open source software ecosystem.
Study on open source software governance at the European Commission and selected other European Institutions Page 102
Security deserves a separate component in the new strategy. The strategy should remind and emphasise the ever-increasing importance of cybersecurity and that open source software adoption is affected by this aspect too. The strategy may praise the benefits of the transparency of externally furnished open source software solutions and that independent security audits are facilitated when the code is open. As an example, the Census project of the Core Infrastructure Initiative aims at providing a list of open source projects that are at risk208. At the same time, it should allow EC DevSecOps developers the freedom to choose whether and when opening their code.
The strategy should also commit itself that open source software adoption will adhere to the guidelines stemming from the 2017 EU Cybersecurity Act209 and its renewal in 2018210. The strategy needs to urge open source software adopters to be extremely careful with security issues and work toward fast bug fixing, as no piece of software is really immune from cyberattacks. To this end, the role of the EC open source dedicated entity may be reminded here, for offering know-how related to (a) known security problems of open source software solutions, (b) fast communication of open source software security issues discovered, and (c) levels of risks associated with specific open source software solutions, through the open source software catalogue it will maintain.
All four government policies examined had security-related components in their most recent releases as reported in the open source software use worldwide section of this study. Security of open source software has been traditionally one of the most debatable issues. It has been also a major concern of the internal stakeholders interviewed.
In addition, the need for a central, instrumented open source software tool inventory / catalogue should be emphasised by the strategy. This catalogue will provide open source software adopters with a valuable informative tool reporting:
Available open source software business or infrastructure solutions
Their salient characteristics, including reported and perceived risks and security issues
A knowledge base of case studies of adoption or rebuttal, both externally and internally
Their level of support, the supporting entities and levels of internal/external user satisfaction
Licensing, and
Any other useful information, such as studies and academic research results.
Again, the role of the EC dedicated entity needs to be emphasised here, given the multitude of available open source software products to consider and the dynamics of the open source software ecosystem that lead to a constant change of the pieces of information contained in such an inventory.
France has released its own list of open source software solutions that have been somehow validated. The strategy may aim at a more ambitious, continuously updated open source software inventory, because of the change dynamics mentioned above. The inventory would facilitate the product management process outlined before and could take profit from the central code repository, by obtaining data from the activities
208The Census project of the LINUX foundation, https://www.coreinfrastructure.org/programs/census-project/ 209State of the Union 2017 - Cybersecurity: Commission scales up EU's response to cyber-attacks, http://europa.eu/rapid/press- release_IP-17-3193_en.htm 210Cybersecurity Act 2018, https://ec.europa.eu/commission/news/cybersecurity-act-2018-dec-11_en
Study on open source software governance at the European Commission and selected other European Institutions Page 103
around hosted projects. The absolute need and importance of such a tool has been pinpointed by several internal interviewees.
The following table summarises the benefits and goals of this action.
Table 10 - Enhance and develop the technical infrastructure – Recommendations highlights
Id Recommendation Benefit(s) / Goal(s)
R18 Create a central code repository: Provide higher visibility to EC open source software projects State the need for a central Facilitate the exchange of know-how among EC open source code repository that will software internal and external participants facilitate the community aspect Provide more advanced services to EC open source software users of EC open source software adoption Clarify the role of OSOR in this respect
R19 Emphasize security: Emphasize the contribution of open source software to Point to open source software transparent and secure generic software solutions for security solutions At the same time allow for closed code in specific instances to Allow for non-open EC open safeguard EC operation source software code for Emphasize the need for fast and efficient defect removal in EC security reasons open source software Anticipate the contribution of the PO/CC as a consulting group in security issues when adopting open source software Pinpoint the importance of the open source software catalogue for reporting risk and security classification of available open source software solutions
R20 Develop central, instrumented open Describe the necessity for an open source software tool / source software tool inventory / software inventory catalogue Describe contents (open source software features, support info) Refer to the guidance provided by the dedicated unit for when to adopt open source software, adoption processes, license issues Obtain open source software usage awareness (where open source software is used within EC)
4.3.Recommendations: supporting evidence The following table reports supporting evidence for each recommendation, originating both from the worldwide analysis and the interviews performed with the EC stakeholders.
Study on open source software governance at the European Commission and selected other European Institutions Page 104
Table 11 - Recommendations and their support (Organization analysis, Interviews)
Id Recommendation Sources
R1 Re-state and Emphasize EC Commitment Findings from UK, France, Italy, US, Google and interviews internal EC stakeholders
R2 Be Pragmatic Findings from UK, France and interviews internal EC stakeholders
R3 Extend to EU Institutions, without Interviews internal EC stakeholders enforcing open source software adoption
R4 Direct Link to Digital strategy and Tallinn Interviews internal EC stakeholders Declaration
R5 Better Communication of open source Interviews internal EC stakeholders software Benefits, Initiatives, Delivery Process
R6 Encourage open source software Public Interviews internal EC stakeholders Use among Citizens, Students (and Member States for interoperability)
R7 Public money, public code principle Interviews internal EC stakeholders
R8 Anticipate the creation of an open Findings from UK, France, Google and interviews internal EC source software Program Office (PO) / stakeholders Competence Centre (CC) / Working Group (WG)
R9 Measure open source software Findings from France, US and interviews internal EC stakeholders Adoption
R10 Adapt Procurement Processes Inte r views internal EC stakeholders to include open source software adoption, support and manager risks
R11 Re-define EC Product Management, Interviews internal EC stakeholders including open source software
R12 Promote an open Culture Findings from UK and interviews internal EC stakeholders
R13 Open source software within other Findings from all countries in scope of the study Openness Initiatives
R14 Emphasize need for open source Interviews internal EC stakeholders software awareness among staff, training needs
Study on open source software governance at the European Commission and selected other European Institutions Page 105
Id Recommendation Sources
R15 Collaborate with and Invest in open Findings from all countries in scope of the study and interviews source software Ecosystem internal EC stakeholders
R16 Clarify and Regulate EC Contribution to Interviews internal EC stakeholders open source software Projects
R17 Guidance for Managing open source Findings from UK, France, US, Italy, Google and interviews internal software Licenses, Legal Aspects, IPR EC stakeholders
R18 Central Code Repository Findings from UK, France, US, Italy, Google and interviews internal EC stakeholders
R19 Emphasize Security Findings from UK, France, US and Interviews internal EC stakeholders
R20 Central, Instrumented open source Findings from France and interviews internal EC stakeholders software Tool Inventory/Catalogue
Study on open source software governance at the European Commission and selected other European Institutions Page 106
5. Interviews with stakeholders from other participating EU institutions
5.1.Objective The aim of this chapter is to provide an overview of the results of the interviews conducted with stakeholders from other EU institutions (or “EC external stakeholders”). The outcomes will be further analysed in the next section. 5.2.Interviews overviews Seven interviews with EC external stakeholders have been conducted for the present study. The interviewed organisations have been selected due to their advanced status in the implementation of open source software policies. The panel of interviewees is composed of six stakeholders from public institutions and one from a private company, as reported in the tables below.
Public Institution
European Centre for the Development of Vocational Training (CEDEFOP)
Italian Digital Team
European Chemicals agency (ECHA)
European Securities and Markets Authority (ESMA)
European Parliament
Council of the European Union
Private company
ENGIE
The key areas of discussion dealt with the stakeholders are the following:
Current Open Source Software Strategy (2014-2017), with a particular focus on the familiarity with the “Open Source Software Strategy 2014-2017” of the European Commission, its main principles and if the strategy helped the organisation in the promotion of open source software;
Open source software adoption in the organisation with a particular focus on:
. the level of open source software adoption inside the organisation;
. the opportunities for and barriers to increasing open source software adoption with the organisation;
Study on open source software governance at the European Commission and selected other European Institutions Page 107
. the initiatives put in place in the organisation in order to implement / spread an open source software mind-set;
. the measure and way by which the organisation works (or not) in an open / horizontal environment;
. how the corporate processes (procurement, HR, legal) are impacted from the adoption of open source software and practices;
Organisation involving with a particular focus on the following items:
. if the organisation is willing to be involved by the EC in activities that might help it to achieve its goals, and how;
. if the organisation is willing to adopt open source software produced internally within the EC;
. if the organisation is willing to participate in an open source software community around a solution implemented internally in the EC;
Vision and Future strategy with a particular focus on:
. the expectations towards the EC in regards to open source software;
. the specific areas on what the new EC open source software strategy should be focused;
. the suggestions for improving the current EC strategy and the changes needed to the EC open source software strategy.
The hereunder table summarises the main highlights drawn based on the input from the interviews.
Area of discussion Main highlights
Current open source software strategy Not all external stakeholders are fully aware of the EC open (2014-2017) source software strategy 2014-2017;
The level of adoption of open source software is quite high among the organisations interviewed; Not all the organisations interviewed have a governance over the use of open source software (e.g. group knowledge, security governance, guidelines); Among others, the main opportunity for a higher adoption of open source software is the increase in the level of maturity of Open source software adoption in the open source software solutions; organisation The main barriers identified to the open source software adoption are the following: o migration costs to other solutions; o mind-set changes in the organisation culture; o licence management not clearly defined Almost all the interviewees have put in place initiatives in their organisations in order to implement / spread an open source software mind-set;
Study on open source software governance at the European Commission and selected other European Institutions Page 108
Almost all the interviewees work in an open / horizontal management environment; Corporate processes need special support in order to change the way of working, especially for the management of IT procurement and IT security; Almost all the interviewees are willing to collaborate with EC in Organisation involving the development of new open source software strategy; A majority of interviewees use CEF building blocks;
Focus on the improvement of open source software rules, tools and communities; Adoption at European level of a unique standard like Public Code in order to gather all the public SW; Invest on interoperability and building blocks that can be used anytime by public administrations; Vision and future strategy Simplify the funding process; The EC should provide support to manage open source software once implemented; The EC should provide more clarity on the legal and financial aspects of inner source and open source; The EC should provide more clarity on the security and monitoring aspects of open source adoption.
Study on open source software governance at the European Commission and selected other European Institutions Page 109
6. Analysis and recommendations on the feasibility of arriving with a single open source software policy for EU institutions
6.1.Introduction This chapter contains a feasibility study for the extension of the EC open source software strategy to other EU institutions, followed by related recommendations. The term ‘EU institutions’ refers to institutions and bodies of the European Union. The study builds upon the results of the surveys and interviews with EU institutions staff regarding their current use of open source software and their vision for the future.
Firstly, a feasibility study is presented. The study considers the positive signals received during the open source worldwide analysis and the positive stance of the EC staff during the interviews with internal EC stakeholders. These encouraging inputs are further corroborated by the findings of the interviews with other EU institutions staff. The study argues that implementing the recommendations proposed in Chapter 4 will greatly assist the extension of open source software strategy to other EU institutions as well. The study concludes that it is feasible to extend the EC open source software strategy to other EU institutions, provided that care is taken to propose them a down-to-earth approach. The same concept emerged from the study on the EC open source software strategy and it was implemented through a dedicated set of recommendations211.
The chapter proceeds with analysing strengths and weaknesses of the extension proposed. Strengths are mainly based on the worldwide trend for a friendlier attitude towards open source software and the positive reception of the idea by the EU institution staff. Weaknesses are the same aspects that pester any open source software adoption project and the fact that the EC will need to support and monitor a new and far wider adoption effort compared with applying the strategy to the EC units alone.
Conclusions are provided at the end of the chapter, recommending cautionary measures to cope with anticipated issues regarding the extension of the Strategy. 6.2.Feasibility Study This section considers the pros and cons for the extension of the EC open source software strategy to EU institutions. The EU institutions212 considered in scope for this study include three main institutions, such as the European Parliament, the Council of the European Union and the European Commission itself, and miscellaneous other institutions, including specialised agencies and decentralised bodies. The complete list of EU institutions is:
European Parliament;
European Council;
Council of the European Union;
European Commission;
Court of Justice of the European Union (CJEU);
European Central Bank (ECB);
211 See paragraph 4.2, “Recommendations: Analysis, Clustering and highlights” 212 List of EU Institutions, as of July 2019, https://europa.eu/european-union/about-eu/institutions-bodies_en
Study on open source software governance at the European Commission and selected other European Institutions Page 110
European Court of Auditors (ECA);
European External Action Service (EEAS);
European Economic and Social Committee (EESC);
European Committee of the Regions (CoR);
European Investment Bank (EIB);
European Ombudsman;
European Data Protection Supervisor (EDPS);
Interinstitutional bodies (Publications Office, European Personnel Selection Office, European School of Administration);
a host of specialised agencies and decentralised bodies.
6.2.1.Factors favouring the extension of the open source software strategy to EU institutions
While analysing open source software worldwide, we were able to identify a positive trend towards open source software adoption. A list of strong enabling factors was provided in Chapter 1213. Actually, in the case of EU institutions, the release and implementation of a new EC open source software strategy is the strongest factor alone. The recommendations outlined in Chapter 4 aim at creating the conditions that would foster the adoption of open source software within the EC. Adoption of the recommendations and their implementation through the future EC open source software strategy will provide an ideal context for open source adoption also by the EU institutions. In particular:
Announcing and implementing a new, bold EC open source software strategy will send a strong signal in favour of open source software adoption to all EU institutions, encouraging them to take part in this endeavour;
An open source software strategy will provide a ready-to-use framework for adopting open source software; it is indeed unlikely that any EU institution would proceed in defining its own open source software strategy;
Open source software enthusiasts have been identified over various EU institutions; such individuals would eagerly act as open source champions, encouraging their colleagues to adopt open source;
Communities that will be forged through the EC open source software strategy could help EU institutions and/or develop and maintain open code of their interest;
The implementation of a Program Office in EC may offer to EU institutions the support they need for successfully adopting open source; if such Program Office extends its support to EU institutions it will also be able to monitor and measure their own degree of open source software adoption; in addition,
213 See paragraphs 1.3.4, Successful open source software adoption approaches”, and 1.5 “Findings from Organisation Analysis”
Study on open source software governance at the European Commission and selected other European Institutions Page 111
if the EC open source software strategy supports existing or new competence or research centres, EU institutions will also be able to take profit of their services and results;
As mentioned before in this study, there is a generally favouring environment due to other, broader policies that call for more transparency, agility and openness; such policies are probably more visible and respected by EU institutions compared with the current EC open source software strategy; linking the new strategy to broader policies will facilitate its adoption by EU institutions.
6.2.2.Factors/Risks threatening the extension of the open source software strategy to EU institutions
Such factors are identical to those that threaten any open source software adoption initiative, and have been already pinpointed in Chapter 1. Most of them are expected to be addressed by the strategy itself or by the activity of the ICT staff of the EU institutions. The most critical risks, along with risk mitigation elements, are:
Poor implementation results: inability to produce quickly positive results through open source software adoption may discourage some EU institutions and jeopardise the whole project. The Program Office, expected to support the new EC open source software strategy, will help achieving concrete and meaningful results within a reasonable time frame.
No ownership of the open source software projects: while this is a real threat, hopefully open source software champions might be found within any EU institution. In the case of the interview with CEDEFOP, it was more than evident that the interviewee would eagerly undertake such a role.
Program Office staffing: an additional issue may be related to the workload of the proposed Program Office. Including so many additional units and potential open source users to the ‘clients’ list’ of the Program Office greatly increases resources requirements. More resources will be needed in terms of number of necessary staff to cope with the increased amount of requests and additional expertise for those open source products that interest the EU institutions. As an example, the EU Parliament might be interested in e-voting systems, while CEDEFOP for competency profiling systems. This issue may compromise the entire idea of the strategy extension and it is advised to staff the Program Office accordingly (see recommendations later).
Resistance to open source software adoption: the activity of the Program Office will be crucial in helping to overcome this issue through guidance and support.
Strong dependence on commercial software vendors: heavy investments made with specific software vendors may prevent the implementation of Open Source Software solutions.
Lack of support from open source software vendors: while this is a critical issue for every broad open source software initiative, the Program Office is expected to provide knowledge of what open source software solutions are adequately supported and by whom.
Lack of sufficient funding: EU institution management needs to be aware of potential investments needed to implement migration to or adoption of open source software. It is recommended to inform in detail the necessary activities and tools to implement successfully an organization-wide open source software adoption project.
A number of minor threats exists as well. While they may be important in cases of isolated open source software adoption initiatives, the implementation of the recommended EC open source software strategy will help alleviate them. Such minor threats are:
Study on open source software governance at the European Commission and selected other European Institutions Page 112
License and legal framework issues: they are supposed to be resolved through the Program Office consultancy, according to the relative EC open source software strategy components.
No architecture enterprise mind-set: it is expected that ICT departments of the EU institutions do have such a mind-set and will be able to integrate smoothly new open source software solutions in their ICT architectures. In one interview this was straightforward as the interviewees mentioned that, although they do not use enterprise architecture tools, they do have an enterprise architecture vision.
Different open source software adoption approaches: this issue will be easily addressed by adopting the EC open source software strategy for all EU institutions. Actually, this is a strong aspect of the strategy extension rather than a weak one.
Unrealistic expectations from open source software: such risk will be dealt again through consultation with Program Office and transfer of experiences from EC internal units.
Lack of continuity in open source software management: the roles of open source software responsible and/or champions will help alleviate this problem in case it materializes. 6.3.Recommendations In this section specific recommendations are provided in view of arriving at a single open source software strategy for EU institutions. In the context of this study, this section should be considered a continuation of Chapter 4. In that chapter, the extension of the EC open source software strategy to EU institutions was anticipated as Recommendation R3, “Extend the usage of open source through EU institutions, without enforcing its adoption”.
Such recommendation was mainly based on the opinions collected during the internal EC stakeholder interviews. Following the considerations presented up to now, we are now able to complete the framework of this recommendation. The rightmost column of the table below provides the goals and benefits of Recommendation R3 and were already presented in Chapter 4. The last benefit, related to increased participation, concerns the increased EU task-force that will be created through the extension, providing positive feedback to the implementation of the new EC open source software strategy.
Id Recommendation Benefit(s) / Goal(s)
R3 Extend the usage of open source through EU Help EU Institutions improve their IT and level of institutions, without enforcing its adoption: digital democracy (in terms of transparency) Avoid negative reactions Ensure that the Program Office is staffed Increase open source software adoption beyond the and prepared adequately EC Communicate clearly the content of the Achieve homogeneity between EC/EU Institutions strategy to EU institution management and Increase participation in EC open source software staff initiatives and projects Communicate widely this decision, including presentations at open source software communities’ events Engage EU institution staff in EU community activities
Study on open source software governance at the European Commission and selected other European Institutions Page 113
The sub-recommendations aim at mitigating the risks that were presented in the previous section:
The Program Office should be staffed with personnel dedicated to EU institutions. EU institution specific open source software solutions should be present in the inventory and EU institution specific requirements should be taken into account while designing the central repository. In plain words, the Program Office should possess all necessary manpower, knowledge and tools to support the extension of the strategy.
During our interviews with EU institution staff it was discovered that they were not adequately informed of the current EC open source software strategy. They were not aware of its existence at all or they did not know its whereabouts. Extending the new EC open source software strategy to them necessitates a round of dissemination events and presentations at the EU institution sites. It is suggested to present the strategy at ICTAC, the EU Agencies ICT Advisory Committee Meeting214.
The open source software communities need to be informed both on the new EC open source software strategy and its extension beyond the EC to achieve a positive impression worldwide and attract the attention of open source software participants to the forthcoming open source software adoption activities throughout EU.
Finally, the personnel of EU institutions need to be invited and included in all community activities to become active, equal level participants in the new EC open source software strategy efforts. 6.4.Conclusions In this chapter the possibility to extend the new EC open source software strategy to EU institutions was examined. Threats and benefits of this option were presented and briefly discussed. It was argued that the release of a new strategy greatly facilitates the extension to EU institutions and reduces the possibility of occurrence of implementation risks. Therefore, it is recommended to proceed with the extension, taking three concrete steps or sub-recommendations to ensure the success of this initiative.
214 EU Agencies ICT Advisory Committee Meeting (ICTAC33), https://www.cedefop.europa.eu/en/events-and-projects/events/33rd- ictac-eu-agencies-ict-advisory-committee-meeting-ictac33
Study on open source software governance at the European Commission and selected other European Institutions Page 114
7. Conclusions and lessons learned
7.1.Summary of the study and high-level overview of the findings and recommendations This chapter summarizes the salient features of the open source software policies worldwide, the trends in open source software adoption and what has been observed to lead to success or failures, as described in previous chapters. It reviews the most insightful opinions collected during the interviews and the lessons learned from open source software adoption within the EC and EU institutions up to now.
In addition, this chapter outlines the main recommendations for the evolution of the open source software strategy of the European Commission. Starting from the review of the current open source strategy, it highlights the most important topics to address in the new one, and it finally assesses the feasibility of arriving with a single open source software policy for EU.
The conclusions coming from the different phases of the current study can be clustered in four different areas of improvement for the future EC open source software strategy:
Awareness and Culture. This area focusses on enhancing open source software use and adoption through both communication and commitment. It highlights the importance of changing and improving the general customs and beliefs related to open source software use;
Role of Guidance. This area addresses how to enhance open source software adoption, by giving practices, strategies and insights over the main issues related to this topic;
Points of reference. This area provides advice on entities that can could promote and ensure support of open source software adoption;
Collaboration. This area focusses on working together with the open source software communities and ecosystem, on collaborating with them in the production of researches and products and on investing on their development.
Hereafter the list of the main recommendations that emerged from the study, divided in the four different areas.
Study on open source software governance at the European Commission and selected other European Institutions Page 115
Areas Findings and Recommendations
Main Findings It has emerged that there are significant barriers to open source software adoption in public services, hereafter an example of some of the principal obstacles to source software adoption in public services identified during the study: o The absence of an enterprise or technical architecture mind-set o The presence of unrealistic expectations from open source software o The lack of continuity in management in opens source software adoption o The absence of ownership over open source software initiatives It is important that the organization shows a high level of commitment in open source software adoption and its dissemination. All kinds of ICT innovation projects need strong central or high-level management commitment, and open source software adoption is no exception to this rule. It is therefore important to emphasise in the EC open source software strategy the necessity to have a strong commitment of the higher-level of the organization in the increase of internal adoption. It is important to focus on the other areas related to the concept of openness, in order to lean a wider visibility of the strengths of open source software adoption. The new EC open source software strategy should sponsor openness in general and Awareness and emphasize the relationship with other openness concepts. Culture It is important to give the right focus on funding, because open source software adoption is not costless It is necessary to sponsor a bottom-up adoption of open source software at all public service levels and the open source software reuse not only among the public services of the same country, but also among public services within the EU. It was found that it is important to emphasize, in the EC open source software strategy, the role of a central repository for EC public code and the related benefits. It was found that it is important to add a component on security in the EC open source software strategy to emphasize this aspect of open source software usage. It is important to establish a security-centric culture in open source software development and use. Recommendations The EC should emphasise the usage and the benefits of open source, highlighting the EC commitment. It should also confirm the intention of extending the usage of open source software through EU institutions. The EC should focus on establishing an open culture, promoting open standards, co-creation, innovation and positioning open source software within other openness initiatives.
Study on open source software governance at the European Commission and selected other European Institutions Page 116
Areas Findings and Recommendations
Main Findings It has emerged that open source software policies achieve better results when a combination of the following factors is in place: o An established legal framework o A nationwide favourable digital strategy o A mechanism of monitoring the adoption of opens source software o A synergy between open and transparency policy There are significant barriers to open source software adoption in public services; it is therefore necessary to pay attention to the presence of different design and implementation approaches used among different open source software initiatives. An important driver of success is the implementation of metrics of open source software adoption. In the EC open source software strategy, measurement of open source adoption among the EC and selected EU Institutions should be implemented. It is important to provide further guidance on the use of open source software licenses in the EC open source software strategy, in order to support open source Role of Guidance software adoption. Establishing supporting practices and specifying development practices contributes to effective open source software adoption in the EC open source software strategy. Recommendations The EC should release a new open source software strategy in order to facilitates the extension to EU institutions of open source software adoption and reduce the possibility of occurrence of implementation risk. The EC should provide guidance on the management of open source software licenses, legal aspects and IPR. The EC should enhance and develop the technical infrastructure that supports open source software adoption (create a central code repository, emphasize security, develop central, instrumented open source software tool inventory / catalogue). The EC should improve Procurement and Product Management processes, adapting them to include open source software adoption.
Study on open source software governance at the European Commission and selected other European Institutions Page 117
Areas Findings and Recommendations
Main Findings It was found that open source software policies produce best results when there is the presence of competence, excellence or research centres that support open source software initiatives that may be established at various levels of public services, educational, or research institutions. It was found that it is important to add on the EC open source software strategy the creation of one or more specialized units around a central open source software Office, with predetermined roles and responsibilities. Points of reference It is important to ensure that the Program Office is staffed and prepared. adequately Recommendations The EC should create an open source dedicated entity that fosters and measures strategy adoption (Program Office, Competence Centre, Working Group). The EC should extend the usage of open source through EU institutions, without enforcing its adoption.
Main Findings It was found that there are significant barriers to open source software adoption in public services, so it is necessary to pay attention to: o The strong dependence on vendor/lock in o The lack of founding or vendors It is important to build a strong collaboration with the communities at local and national level. Leverage on existing open source software communities is of Collaboration paramount importance. It was found that it is important to add on the EU open source software strategy the theme of the collaboration within the entire open source software ecosystem and the creation of an internal EC open source software community. Recommendations The EC should collaborate with and invest in communities/open source software ecosystem and clarify and regulate EC contribution to open source software Projects.
7.2.Lessons learned This chapter contains the lessons learned during the different phases or the study that can be useful for the set-up and management of future projects.
Hereafter a table summarising the main highlights of the principal insights collected.
Study on open source software governance at the European Commission and selected other European Institutions Page 118
Key points Main highlights
The execution of the interviews, the online survey and the face to face meetings and workshops allowed to analyse the data collection process implemented how to optimize improve it for future processes: It is necessary to schedule the interviews with adequate advance, in order to allow for traveling arrangements and interviewee preparation. It is necessary to agree beforehand a preliminary interview guide to be used as basis for the conduction of interviews. Without a single and solid interview guide, shared with all the How to optimize the data collection process players, it would be difficult to organize the answers and the reports collected. The interview guide may follow a multiple answer structure, in order to allow the quantitative measurement of the interviews results. The organisation of a workshop with representatives of open source software communities may be a better way engaging other stakeholders instead sending out an online survey that did not have the expected response rate.
The interviews with Directors and Operational resources allowed to validate preliminary findings and recommendations about the implementation of a top-down vision vs a bottom up one, through the analysis of the quality of the information obtained from the different interviews: Pros The interviews with the Directors allowed to provide a high level view and the main directions for the development of the Interviews with Directors and new open source software strategy (high vision) Operational resources The interviews with operational resources allowed to deeply understand how they work for the coding of open source software (operational vision) Cons The interviews only with operational resources could have been misleading for the current study, because the lack of awareness of the current EC open source software strategy
Study on open source software governance at the European Commission and selected other European Institutions Page 119
Key points Main highlights
The survey and the interviews with the internal and external stakeholders showed differences between their levels of involvement and collaboration: The internal stakeholders, from directors, head of units, project managers and developers, showed high engagement Level of involvement of external towards the current study stakeholders The open source software communities showed a lack of communication and involvement (only two answers to the EU survey). This was likely caused by an insufficient awareness campaign and the current low level of collaboration with the open source software communities
The results of the study allowed to analyse the project management process implemented and to study how to optimize that process: It is necessary to agree beforehand, or to set expectations, on the extensiveness of the benchmark/study (e.g. level of detail, How to improve the project management aspect of the study references, period of analysis, …) The weekly meeting proved to be useful to the correct approach and conclusion of the study. It may be improved by adding a first person mid-study touch point
Study on open source software governance at the European Commission and selected other European Institutions Page 120
8. Appendix
8.1. Bibliography
Association of Enterprise Architects, https://www.globalaea.org/
Interview with Alja Isakovic of Europe Code Week on opensource.com, https://opensource.com/life/14/10/interview-alja-isakovic-europe-code-week
Commission announces bug bounty awards, https://joinup.ec.europa.eu/news/eur-3000-eur-25000
Web page assisting users in choosing a license, https://choosealicense.com/, https://choosealicense.com/appendix/
Open Source Software Governance at the European Commission study, Deloitte, 2014
European Commission Digital Strategy, https://ec.europa.eu/info/publications/EC-Digital-Strategy_en
DG Research and Innovation, Strategic Plan 2016-2020, https://ec.europa.eu/info/sites/info/files/strategic- plan-2016-2020-dg-rtd_march2016_en.pdf https://publications.europa.eu/en/publication-detail/-/publication/480eff53-0495-11e7-8a35- 01aa75ed71a1
EC ‘Open Source Software Strategy 2014-2017’, https://ec.europa.eu/info/departments/informatics/open- source-software-strategy_en#opensourcesoftwarestrategy
‘EC Open Source Strategy’ History, https://ec.europa.eu/info/open-source-strategy-history_en
Europe Code Week, https://codeweek.eu/
EU-FOSSA Pilot Study, https://joinup.ec.europa.eu/document/project-deliveries
European Public License v1.2, 2017, https://joinup.ec.europa.eu/sites/default/files/custom- page/attachment/eupl_v1.2_en.pdf
An open source license compliance software system and toolkit, https://www.fossology.org/
Digital Economy Law, https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000801164&dateTexte=&categorieLi en=id
As of 7 Feb 2019, Google opens the source code of its ClusterFuzz testing tool, https://github.com/google/clusterfuzz-tools
New European Interoperability Framework, https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf
Joinup License Assistant white paper, https://joinup.ec.europa.eu/sites/default/files/document/2019- 02/Joinup%20Licensing%20Assistant%20-%20White%20Paper_v1.01.pdf
JOINUP2019, https://joinup.ec.europa.eu/
Georgia M. Kapitsaki, Frederik Kramer, Nikolaos D. Tselikas: Automating the license compatibility process in open source software with SPDX. Journal of Systems and Software 131: 386-401(2017)
Interim evaluation of the programme on interoperability solutions for administrations, businesses and citizens (ISA2)
Study on open source software governance at the European Commission and selected other European Institutions Page 121
https://ec.europa.eu/info/law/better-regulation/initiatives/ares-2018-2768206/public-consultation_en
EC study recommends that policies emphasise open source, OSOR news, by Gijs Hillenius, https://joinup.ec.europa.eu/news/ec-study-recommends-poli
OSOR, Open Source Repository, https://joinup.ec.europa.eu/collection/open-source-observatory-osor
Reuse Initiative be Free Software Foundation Europe, https://reuse.software/
RGI 2009 – Référence Général d’Intéropérabilité https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=?cidTexte=JORFTEXT000021254225&dateTexte=& oldAction=rechJO&categorieLien=id
RGI 2016– Référence Général d’Intéropérabilité, https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=8A644E92C98962BDE82219C596F728FC.tpdila19 v_2?cidTexte=JORFTEXT000032438896&dateTexte=&oldAction=rechJO&categorieLien=id&idJO=JORFCONT 000032438891
EC Open Source Software Inventory, https://joinup.ec.europa.eu/sites/default/files/inline- files/DLV%20WP3%20-%2002_Inventories%20tools%20selection_published.pdf
UK ICT Strategy published on 30 March 2011, https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/85968 /uk-government-government-ict-strategy_0.pdf
The economic and social impact of software & services on competitiveness and innovation https://publications.europa.eu/en/publication-detail/-/publication/480eff53-0495-11e7-8a35- 01aa75ed71a1
Study on open source software governance at the European Commission and selected other European Institutions Page 122
Study on open source software governance at the European Commission and selected other European Institutions Page 123