# Enabling OSS Usage Through Procurement Projects: How Can Lock-in Effects Be Avoided?

Björn Lundell, Jonas Gamalielsson, Simon Butler, Christoffer Brax, Tomas Persson, Anders Mattsson, Tomas Gustavsson, Jonas Feist, Jonas Öberg

<figure><img src="image_1.png" /></figure>

## To cite this version:

Björn Lundell, Jonas Gamalielsson, Simon Butler, Christoffer Brax, Tomas Persson, et al. Enabling OSS Usage Through Procurement Projects: How Can Lock-in Effects Be Avoided?. 17th IFIP International Conference on Open Source Systems (OSS), May 2021, Lathi/virtual event, Finland. pp.16-27, 10.1007/978-3-030-75251-4_2. hal-03254056

HAL Id: hal-03254056

https://inria.hal.science/hal-03254056

Submitted on 8 Jun 2021

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Enabling OSS usage through procurement projects: How can lock-in effects be avoided?

Björn Lundell<fnref n="1" />, Jonas Gamalielsson<fnref n="1" />, Simon Butler<fnref n="1" />, Christoffer Brax<fnref n="2" />, Tomas Persson<fnref n="3" />, Anders Mattsson<fnref n="4" />, Tomas Gustavsson<fnref n="5" />, Jonas Feist<fnref n="6" />, Jonas Öberg<fnref n="7" />

**Abstract.** Formulation of mandatory requirements in procurement projects has significant influence on opportunities for development and deployment of Open Source Software (OSS). The paper contributes insights on a widespread practice amongst public procurement projects which causes problematic lock-in effects and thereby inhibits opportunities for use of OSS solutions. Through a systematic investigation of 30 randomly selected procurement projects in the software domain the paper highlights illustrative examples of mandatory requirements which cause lock-in and presents five recommendations for how requirements instead should be formulated in order to avoid causing lock-in. Findings show significant lock-in caused by current procurement practices with a stark preference for proprietary software and SaaS solutions amongst procuring organisations.

**Keywords:** Open source software projects, procurement projects, IT-standards, open standards, lock-in effects.

# 1 Introduction

Investigations of a large number of IT procurement projects have identified widespread practices amongst public sector organisations that cause different lock-in effects which in turn inhibit Open Source Software (OSS) usage [29]. Further, it is far from uncommon that procurement projects express mandatory requirements which refer to specific IT standards that prevent implementation in OSS projects [17, 25,

<footnote n="1">¹ University of Skövde, Skövde, Sweden,</footnote>

<footnote>{jonas.gamalielsson,bjorn.lundell,simon.butler}@his.se</footnote>

<footnote n="2">² Combitech AB, Skövde, Sweden,</footnote>

<footnote>christoffer.brax@combitech.se</footnote>

<footnote n="3">³ Digitalist Sweden AB, Stockholm, Sweden,</footnote>

<footnote>tomas.persson@digitalistgroup.com</footnote>

<footnote n="4">⁴ Husqvarna AB, Huskvarna, Sweden,</footnote>

<footnote>anders.mattsson@husqvarnagroup.com</footnote>

<footnote n="5">⁵ PrimeKey Solutions AB, Solna, Sweden,</footnote>

<footnote>tomas.gustavsson@primekey.com</footnote>

<footnote n="6">⁶ RedBridge AB, Stockholm, Sweden,</footnote>

<footnote>jfeist@redbridge.se</footnote>

<footnote n="7">⁷ Scania CV AB, Södertälje, Sweden,</footnote>

<footnote>jonas.oberg@scania.com</footnote>
29]. In turn, if an organisation expresses a requirement for an IT standard which in-
hibits implementation and use of OSS such a practice causes lock-in that inhibits
competition. As stated by Katz [23]: “Lock-in has been recognized as distorting the
market process, creating unfair monopolies for the participants.”

With increased adoption and use of proprietary licenced Software as a Service (SaaS) solutions, researchers and policy makers have recognised lock-in effects as a significant concern [19, 20, 33]. For example, the GAIA-X initiative states that lock-in effects “can be of a technical-functional kind (dependence on the specific features of certain providers); they can arise from contractual agreements (e.g. license models and penalty costs), but also result from a high, customer-specific degree of personalisation, from familiarisation effects, or from the sheer data volume that is to be migrated.” [19]

Amongst policy recommendations for an organisation that seeks to avoid lock-in related to usage of a SaaS solution, the importance of conduct of a careful review of all contract terms for the solution has been stressed with a recommendation to avoid accepting terms which allow the provider of the solution to unilaterally change contract terms and ensuring availability of an effective exit strategy [13]. Further, concerning procurement of software applications it has been recommended that “compatibility with proprietary technologies should be explicitly excluded from public procurement criteria and replaced by interoperability with products from multiple vendors.” [21]

The *overarching goal* of the study is to illuminate how current practice in pro-
curement projects impacts on opportunities for development and deployment of OSS
that implement IT standards. The study investigates the following research questions:

**RQ1:** How do public sector organisations express mandatory requirements on development and deployment of software which impact on opportunities for use of OSS?

**RQ2:** How are requirements on IT-standards expressed in public procurement projects and how should they be modified in order to avoid lock-in effects and allow for strategic use of OSS?

## 2 On lock-in effects in the software domain

Related to different technologies several studies have addressed different types of lock-in effects [1, 5, 16]. For example, previous research shows that ‘historical events’ can lead to lock-in [1]. One historical example being touch typing that ‘gave rise to three features of the evolving production system which were crucially important in causing QWERTY to become “locked in” as the dominant keyboard arrangement. These features were technical interrelatedness, economies of scale, and quasi-irreversibility of investment.’ [5]

OSS projects and IT standards, and in particular the role of OSS for implementing
standards, have been recognised as important enablers for addressing lock-in effects.
For example, outcomes from an EU study claim that contributing “to OSS is per-
ceived as a strategy to prevent proprietary software solutions, which might create a
vendor lock-in and consequently closes markets instead of opening them” [2]. Further, the study stresses that when an organisation contributes its own code of high quality to OSS such work practices are perceived as a contribution to a common good and that such work practices also promote the own organisation’s autonomy and control of its own software development [2].

Policy makers in different countries have presented a number of policy recommendations related to use of IT standards [31, 34, 35, 36, 32, 6, 7, 8, 9, 10, 12]. Further, the EU has presented a catalogue of ICT standards which are recommended for use in 20 different European countries [9, 12]. Several of the standards included in these recommendations allow for implementation in OSS as they fulfil the definition of an open standard which is presented by the European Interoperability Framework version 1.0 [6]. For example, all standards included in the recommendation presented in Sweden are open IT standards [32], whereas research shows that some standards recommended for use in some other countries (e.g. the JPEG 2000 standard and several MPEG-standards) are closed standards which inhibit implementation in OSS [27]. Further, all framework contracts for public procurement projects established by the Swedish National Procurement Services (a governmental agency) at Kammarkollegiet [32] require that any reference to a standard in a mandatory requirement in a procurement project must conform to the EU definition of an open standard [6]. Requirements for open standards with the same [31] or similar [34, 35, 36] definition have been included in national policy established in other countries in order to allow for use of OSS and promote software interoperability.

## 3 Research approach

The study addresses how current practice in procurement projects impacts on opportunities for development and deployment of OSS that implement IT standards through investigation of 30 randomly selected procurement projects undertaken by Swedish municipalities in 2019. The investigation considered procurement projects that have been publicly announced in Tenders Electronic Daily (an EU public procurement service) if it included at least one of the two Common Procurement Vocabulary (CPV) codes (in divisions 48 and 72) for ‘software package and information systems’ and ‘IT services: consulting, software development, Internet and support’.

Central government has limited influence on Swedish municipalities’ public procurement projects as municipalities have significant autonomy with respect to conduct of public procurement. The vast majority (94%) of the 290 Swedish municipalities have fewer than 100,000 citizens and the median sized municipality has approximately 16,000 citizens. Hence, many public procurement projects are undertaken by rather small, independent municipalities, even though many challenges related to digitalisation and IT are very similar amongst municipalities.

For each investigated procurement project, we reviewed tender documents and analysed each mandatory requirement with a view to identify any explicit (or implicit) reference to IT standards which may impact on opportunities for a potential supplier to provide a bid which includes an OSS solution. The coding of documentation from
each procurement project was conducted in a manner which follows Glaser's ideas on open coding [24]. We specifically considered the formulation of each mandatory requirement which may cause any (intentional or unintentional) lock-in and thereby also restrict competition as an unintended consequence for the procuring organisation by inhibiting some potential suppliers from submitting bids.

Amongst the 30 investigated public procurement projects we found that documentation from the vast majority of the selected procurement projects refer to a range of different technologies and explicitly refer to specific proprietary software. For example, amongst procurement projects municipalities request solutions, such as: a student administration system and learning platform for public schools; a scheduling system for public schools; an IT-solution for digital tests; a document and case management system with an e-archive solution; a system for health and social care; a video conference system with support for e-voting; a system for distribution of invoices; a debt collection system; a cloud based web platform for a website; a Customer support system; a HR and salary system; consultants for software development related to Geographical Information Systems (GIS); and a GIS-system.

For a selected set of the problematic mandatory requirements, as identified from the outcome of our analysis of each mandatory requirement, we present five recommendations for improved (alternative) formulations of the mandatory requirements which we claim will significantly improve the situation and (most likely) avoid problematic lock-in effects. The evolved recommendations are grounded in a comprehensive analysis of current practice concerning expression of mandatory requirements in procurement projects and supplemented by a literature analysis which informed the formulation of each recommendation. The formulation of the recommendation also benefited from that several authors of this study have extensive prior experiences and insights from analysis of, and direct involvement in procurement projects in different roles, including previous research which has analysed and contributed to procurement projects.

## 4 Results

This section presents results concerning how public sector organisations express mandatory requirements on development and deployment of software which impact on opportunities for use of OSS (subsection 4.1). Thereafter, the section presents results concerning how mandatory requirements expressed in public procurement projects cause lock-in effects which impact on opportunities for strategic use of OSS (subsection 4.2). Specifically, illustrative examples of how mandatory requirements that cause lock-in effects are expressed in procurement projects are presented, together with suggested modified alternative formulations for expressing each requirement in order to avoid lock-in and allow for strategic use of OSS.
## 4.1 Development and deployment of software impacting on opportunities for OSS usage

Software development projects can provide software under a number of different conditions, including terms which fulfil the Open Source Definition (OSD) that have been recognised as OSS licences by the Open Source Initiative (OSI). Further, software provided under other terms is often referred to as proprietary software (and sometimes closed source software). Software can be deployed in a number of different ways, for example through internal deployment which may involve installation and use of a software application on a local computer (on premise). Further, a software application which is deployed and installed on a server that is controlled by some external organisation may provide the application as a public SaaS solution. In this latter scenario the procuring organisation typically uses the externally deployed public SaaS solution via a web browser.

A conceptualisation of four principal ways for **development of software** (open or closed) and **deployment of software** (internal or external) is presented in Figure 1. From the perspective of the procuring organisation, development of software which is provided as OSS may be internally deployed (lower left quadrant of Figure 1) or be externally deployed (lower right quadrant of Figure 1). Similarly, development of software which is provided as proprietary software may be internally deployed (upper left quadrant of Figure 1) or be externally deployed (upper right quadrant of Figure 1). To further clarify the conceptualisation, illustrative examples of software applications of each type are presented in Figure 1. From the perspective of a procuring organisation it should be noted that several OSS projects develop and provide OSS (e.g. Nextcloud) which can be deployed both internally and externally. For example, the SaaS solution Nextcloud can be provided to the procuring organisation through internal deployment (e.g. Nextcloud can be internally used by the procuring organisation through provision by the organisation's own IT department). Further, Nextcloud can also be provided to the procuring organisation through deployment by an external organisation as a public SaaS solution (e.g. Nextcloud can be provided by a global company).

<figure><img src="image_3.png" /><figcaption>**Figure 1.** Conceptualising four principal ways for development and deployment of software</figcaption></figure>

Concerning **development of software** applications, procurement projects express stark preference for proprietary software solutions. The vast majority (90%) of the investigated projects express one or several mandatory requirements which discriminate against provision of OSS solutions. We find a widespread practice of explicitly (or implicitly) referring to specific vendors, specific proprietary software applications
which are provided and controlled by specific companies. Further, we also find a
widespread practice amongst procurement projects to include mandatory requirements
which request compatibility (instead of interoperability) with specific technologies.
For example, procurement projects include compatibility requirements with reference
to one (or several) of the following: AD (Active Directory), EPIserver DXC (a cloud
based CMS solution), iPad, Microsoft Office 365, Oracle DB, and Stratsys (a cloud
based strategic planning solution). In addition, several projects express mandatory
requirements which request integration with proprietary software applications and
technology. For example, amongst analysed projects we find mandatory requirements
for integration with one (or several) of the following: iipax (a proprietary e-archiving
solution), Microsoft BizTalk 2016, Phoniro's locking solution (for Senior Care),
Sharepoint, Stratsys, and TEIS (an integration platform server). Overall, we find that
such procurement practices inhibit opportunities for potential suppliers to offer OSS
solutions.

The remaining (10%) procurement projects lack explicitly expressed mandatory
requirements related to software. One of these remaining procurement projects (which
requested an administrative system for primary schools, expressed only (high-level)
functionality requirements. In another procurement projects (requesting a system for
invoice distribution), the procurement project made reference to several proprietary
software applications from which data should be processed by the procured applica-
tion (and based on the limited information provided it is unclear if it is possible for a
potential supplier to offer a bid for an OSS solution). Further, in yet another case, the
procuring organisation expressed requirements for IT consultants which are focused
on one specific global provider.

Concerning ***deployment of software*** applications, we find that almost half (47%) of the analysed procurement projects do not express any requirements for how a procured application shall be deployed. Further, amongst the procurement projects which express requirements for how a procured software application shall be deployed we find a clear preference for deployment of the procured application in an external organisation as a cloud or SaaS solution.

Specifically, amongst the analysed procurement projects we find that more than
one out of three (37%) projects include a mandatory requirement which expresses that
the software application must be deployed as a cloud or a SaaS solution in an external
organisation (e.g. expressed as that the system ‘shall be provided as a cloud solution’
or as ‘the application shall be of the type SaaS solution’ with the requirement that the
operation shall be included), whereas only one out of ten (10%) require that the soft-
ware application must be internally deployed in the procuring organisation as an on
premise solution (e.g. expressed as the ‘system shall be installed locally’). Hence,
amongst (almost half of) the procurement projects which actually express a require-
ment for how the procured software application shall be deployed we find a clear
preference for deployment of the procured application as a cloud or SaaS solution at
an external organisation.

In addition, some (7%) of the analysed procurement projects require that a pro-
cured software application must be both internally and externally deployed. This im-
plies that for those projects the procured application will be both internally provided
in the procuring organisation and also as a cloud or a SaaS solution that is provided
by an external organisation.

Almost all procurement projects which procure a SaaS solution do not consider li-
censing and legal aspects (including the GDPR) when expressing mandatory require-
ments concerning processing and maintenance of the procuring organisation’s data.
This is despite procuring a SaaS solution which, when used, will process personal
data. Only one procurement project requires that maintenance and processing of per-
sonal data must take place in the EU/EES by a legal entity which is represented in the
EU/EES. However, none of the procurement projects express any mandatory re-
quirements related to applicable laws for contracting parties (e.g. if a procuring organ-
isation requires that all parties involved with the data processing are bound by Swed-
dish law) and under which law (e.g. only Swedish and EU law) data processing are
allowed to take place when a procured SaaS solution is used (e.g. if processing of
personal data in certain third countries are disallowed).

## 4.2 Requirements on IT standards impacting on lock-in effects

Some procurement projects make reference to open standards and open formats when expressing mandatory requirements. For example, we find one procurement project which requires that all integration between IT systems use open standards and another project expressing a mandatory requirement for ‘open and standardised formats’ related to provision of personal data in connection with a future exit from a procured SaaS solution. Further, several procurement projects refer to specific IT standards when expressing mandatory requirements. Several projects refer to specific IT standards (e.g. ODF, PNG, PDF/A-1, XML, HTML5, and CSV) which comply with the definition of open standard [6, 32]. However, there are several projects which refer (in some cases in a somewhat unclear way) to specific IT standards and file formats (e.g. MPEG, MPEG4, DWG, PDF/A-2, and Microsoft formats) that do not constitute open standards [6].

Amongst analysed procurement projects which include explicitly expressed mandatory requirements related to software we find many implicit and indirect references (in many cases referenced via specific implementations in software) to a range of different IT standards. Amongst implicit references to specific IT standards we find many projects which include mandatory requirements expressed by reference to specific file format standards through its filename extension, such as: ‘docx’, ‘dwg’, ‘jpeg’, ‘png’, and ‘mpeg4’. Further, amongst indirect references to specific IT standards expressed via implementation of the standards in specifically referenced software applications (including several SaaS solutions) we find several unclear mandatory requirements.

Several procurement projects include mandatory requirements which refer to spe-
cific proprietary technologies that by some procuring organisations are perceived as
'standards' even though these are not recognised by any standards setting organisa-
tion. In many cases such proprietary technologies are controlled by a specific compa-
ny, such as for example 'AD' (Active Directory, a directory service developed for
Microsoft Windows). On the other hand, we also find some procurement projects
which refer to OSS projects (e.g. Apache Tomcat and LibreOffice) and projects which
express a mandatory requirement for the availability of OSS that can interpret files
that need to be maintained and processed by a procuring organisation.

Many procurement projects express mandatory requirements with reference to spe-
cific implementations in software. For example, one project expressed a mandatory
requirement which required ‘PDF from Raindance’ (based on the information provid-
ed by this procurement project it is unclear how, and which version of the PDF file
format is used by this specific SaaS solution for creation of PDF files). Similarly,
another project expressed that support for exporting data from the procured applica-
tion ‘to the Google docs format’ in a mandatory requirement (without providing any
details concerning how ‘the’ technical specification for the format used internally by
the SaaS solution is actually specified and implemented). Further, several procure-
ment projects express (in many cases rather vaguely formulated) mandatory require-
ments that request integration and compatibility with the file formats used by ‘iWork’,
‘Office 365’, and ‘MS Office’.

Overall, from analysis of all mandatory requirements expressed in the investigated
procurement projects, we observe stark confusion related to the difference between
software application on the one hand, and IT standards (and file formats) on the other.
Some procurement projects include mandatory requirements which make explicit
references to formal standards. For example, one project referred to a withdrawn
standard (ISO/IEC 10646:2003) when expressing a mandatory requirement. In this
case, we note that several successive editions of the standard (i.e. ISO/IEC
10646:2011, ISO/IEC 10646:2012 and ISO/IEC 10646:2014) have also been with-
drawn and that the fifth edition of this standard (ISO/IEC 10646:2017) is under re-
view.

Based on our analysis of the investigated procurement projects we present five ac-
tionable recommendations for preventing lock-in effects for any procuring organisa-
tion that expresses mandatory requirements in procurement projects.

**First,** a procuring organisation needs to express requirements for interoperability with open IT standards (instead of compatibility with a specific proprietary technology which is controlled by a single provider). We find that if an organisation expresses a requirement for compatibility with a specific proprietary software application such practice contributes to lock-in. There is strong support for this recommendation in EU law and previous studies [17, 21, 25, 29, 33].

**Second,** a procuring organisation needs to express requirements for open IT stand-
ards (instead of closed IT standards) in order to avoid lock-in. There is strong support
for this recommendation in previous research [2, 10, 19, 25, 26] and reports from
policy makers at different levels [6, 8, 9, 34, 35, 36]. Further, if an organisation ex-
presses a requirement for a closed IT standard, it may (for both legal and technical
reasons) be impossible to implement this standard in OSS [27].

**Third,** a procuring organisation should express requirements for an IT standard on-
ly if it has been implemented by one or several OSS projects. If sustainable OSS pro-
jects faithfully implement a specific IT standard in OSS this minimise the risk for
being unable to interpret digital assets previously created in the specific IT standard.
We find that if there is no publicly available OSS implementation for a specific IT
standard this imposes significant risks for lock-in, and it may be a sign that there are
technical and legal issues with the standard itself. There are many technical, legal and
business related challenges which impact on the possibility to develop software appli-
cations which conform to technical specifications of specific IT standards [2, 4, 11,
19, 21, 26, 27, 30].

**Fourth**, a procuring organisation needs to avoid expressing requirements for spe-
cific proprietary software applications that cause problematic lock-in for the procur-
ing organisations. There is strong support for this recommendation in Swedish and
EU law [25]. We find that if an organisation expresses a requirement for a proprietary
licenced software application this imposes risks for the procuring organisation (e.g.
risks related to long-term maintenance and reuse of digital assets created through use
of the procured software application) which need to be carefully considered in each
case.

**Fifth**, a procuring organisation needs to develop an effective exit strategy which allows for abandoning the procured software application (and in particular if the application is deployed as a SaaS solution provided by an external organisation) on short notice with preserved data and digital assets which can be reused in open file formats. There is strong support for this recommendation in policy recommendations [13] and previous research [28]. For example, one of the policy recommendations included in a checklist presented by eSam states: "Is there a strategy that allows or abandoning the cloud service in the future (an exit plan)? [13]. Further, lock-in and availability of an effective exit strategy is considered as one of the "top concerns with the cloud" [22]. We find that if an organisation expresses a requirement without considering the possibility to undertake an effective exit from day one, this imposes risks for the procuring organisation which need to be carefully considered in each case.

**5 Discussion and conclusions**

Based on analysis of the mandatory requirements expressed in the investigated pro-
curement projects, we find widespread lack of clarity and significant scope for im-
provement related to expressing competition neutral, relevant and unambiguous man-
datory requirements amongst procuring organisations. For example, several procure-
ment projects have confused specific software applications with specific IT standards
when expressing mandatory requirements. Further, many projects have expressed
mandatory requirements without having understood the fundamental difference be-
tween a technical specification of a specific IT standard which is implemented in a
specific software application (that is provided by a software project), and the same
specification (of the same IT standard) as documented in a standard document (that is
provided by a standard setting organisation, e.g. ISO). When comparing to previous
studies undertaken in the Swedish context which have identified problematic pro-
curement practices that cause lock-in [25, 29] we find that previously identified prob-
lematic practices remain and even have become even more problematic. We conjec-
ture that this, at least partly, may be explained by an increased proportion of problem-
atic mandatory requirements expressed in relation to procurement of SaaS solutions.
Related to the evolved recommendations for preventing lock-in when undertaking procurement projects, we find that providers of SaaS solutions may cause a range of lock-in challenges for a customer which consequently may need to recover its externally maintained data on short notice, perhaps due to that the provider decides to change the contract terms or in case of serious problems for the provider which leads to a discontinued solution. For example, we note that a cloud solution provider gave its customers “two weeks to get their data back” [3]

For these reasons it may be unsurprising that a number of policy recommendations which seek to address these, and related, challenges have been presented over the years. For example, eSam (a collaboration between 29 central government agencies and the Swedish Association of Local Authorities and Regions, which represents all 290 Swedish municipalities [15]) has presented recommendations related to use of cloud and SaaS solutions, including a legal analysis [14] in addition to its checklist which contains recommendations to an organisation related to procurement of cloud solutions [13].

Further, an analysis undertaken by Swedish legal experts argues that, under normal conditions, it is unlawful for a Swedish public sector organisation to enter into a contract with a supplier, for example for procurement and use of a SaaS solution, in cases where any foreign law may impact the public sector organisation's ability to ensure official tasks are performed according to Swedish law [18]. Further, this may, inter alia, concern data processing and official duties to ensure information is preserved in data formats suitable for archival purposes, or that rules governing public access to information and secrecy are in fact observed so that information can not improperly be given to a third party such as a foreign government. The authors argue that it would in these cases be in contravention of the obligation in the Swedish legal order, for authorities to give rules in a foreign jurisdiction precedence over the Swedish legal order [18]. Based on these arguments, we find that this should be the case regardless of whether the authority enters into a contract directly with an international cloud service provider, or whether the authority enters into a contract with a Swedish SaaS provider which in turn relies on an international IaaS provider, as the same fundamental issue can persist in either case.

In conclusion, based on analysis of all mandatory requirements in the investigated procurement projects we find a widespread practice amongst procuring organisations to include explicit references to specific proprietary technologies and IT standards which do not comply with the EU definition of an open standard that is also used by the National Procurement Services in Sweden. Consequently, to avoid lock-in effects and promote software interoperability we find that procuring organisations need to promote use of open IT standards which can be (and already are) implemented in OSS by sustainable OSS projects. For reasons of sustainable digitalisation, we find improved public procurement practices to be critical for avoiding an unintentional discrimination against development and deployment of effective OSS solutions.
# 6 Acknowledgements

This research has been financially supported by the Swedish Knowledge Foundation (KK-stiftelsen) and participating partner organisations in the SUDO project. The authors are grateful for the stimulating collaboration and support from colleagues and partner organisations.

# References

1. Arthur, B.: Competing Technologies, Increasing Returns, and Lock-In by Historical Events, The Economic Journal 99(394), 116-131 (1989)

2. Blind, K., Böhm, M.: The Relationship Between Open Source Software and Standard Setting, Thumm, N. (ed.) EUR 29867 EN, JRC (Joint Research Centre) Science for Policy Report, Publications Office of the European Union, Luxembourg, 2019, ISBN 978-92-76-11593-9 (2019)

3. Butler, B.: Gartner analyst's advice to customers of shuttering Nirvanix: PANIC!, Cloud Chronicles, Network World, 18 September (2013)

4. Butler, S., Gamalielsson, J., Lundell, B., Brax, C., Mattsson, A., Gustavsson, T., Feist, J., Lönroth, E.: Maintaining Interoperability in Open Source Software: A Case Study of the Apache PDFBox Project, Journal of Systems and Software 159, January (2020)

5. David, P. A.: Clio and the Economics of QWERTY, The American Economic Review 75(2), 332-337 (1985)

6. EC: European Interoperability Framework for pan-European eGovernment Services, Version 1.0, European Commission, ISBN 92-894-8389-X (2004)

7. EC: Against lock-in: building open ICT systems by making better use of standards in public procurement, Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of Regions, European Commission, COM(2013) 455 final, 25 June (2013a)

8. EC: Guide for the procurement of standards-based ICT - Elements of Good Practice, Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of Regions, European Commission, SWD(2013) 224 final, 25 June (Accompanying the document: 'Against lock-in: building open ICT systems by making better use of standards in public procurement', COM(2013) 455 final) (2013b)

9. EC: Commission Recommendation (EU) 2017/1805 of 3 October 2017 on the professionalisation of public procurement - Building an architecture for the professionalisation of public procurement, Official Journal of the European Union, L259/28, 3 October (2017)

10. EC: OPEN SOURCE SOFTWARE STRATEGY 2020 - 2023: Think Open, Communication to the Commission, European Commission, Communication, COM(2020) 7149 final, 21 October (2020)

11. Egyedi, T.: Standard-compliant, but incompatible?!, Computer Standards & Interfaces 29(6), 605-613 (2007)

12. EU: Online catalogue of ICT standard for procurement, European Commission, 6 November (2017) https://joinup.ec.europa.eu/community/european13b) catalogue (Accessed 6 November 2017)
13. eSam: Checklista inför beslut om molntjänster i offentlig sektor, 31 October (2018a), Available at: http://www.esamverka.se/stod-och-vagledning/rekommendationer-och-checklistor/checklista-infor-beslut-om-molntjänster-i-offentlig-sektor.html

14. eSam: Rättsligt uttalande om röjande och molntjänster, VER 2018:57, eSam, 23 October (2018b)

15. eSam: www.esamverka.se/om-esam/om-esam.html (2021)

16. Farrell, J., Klemperer, P.: Coordination and lock-in: Competition with switching costs and network effects, In Armstrong, M., Porter, R. (eds.) Handbook of Industrial Organization, Volume 3, Elsevier, pp. 1967-2072 (2007)

17. FLOSS: Open Source Software in the Public Sector: Policy within the European Union, FLOSS Final Report - Part 2b, Free/Libre Open Source Software: Survey and Study, Berlecon Research, Berlin, June (2002)

18. Furberg, P., Westberg, M.: Måste myndigheter följa lagarna? Om utkontraktering och legalitet i digital miljö, Juridisk tidskrift, No. 2, pp. 406-417 (2020/21)

19. GAIA: Project GAIA-X: A Federated Data Infrastructure as the Cradle of a Vibrant European Ecosystem, Federal Ministry for Economic Affairs and Energy (BMWi), Berlin, October (2019) https://www.bmwi.de/Redaktion/EN/Publikationen/Digitale-Welt/project-gaia-x.html

20. GAIA: GAIA-X: Technical Architecture, Release - June 2020, Federal Ministry for Economic Affairs and Energy (BMWi), Berlin, June, https://www.bmwi.de/Redaktion/EN/Publikationen/gaia-x-technical-architecture.pdf?__blob=publicationFile&v=5 (2020)

21. Ghosh, R. A.: Open Standards and Interoperability Report: An Economic Basis for Open Standards, Deliverable D4, MERIT, University of Maastricht, December (2005)

22. Hon, W. K., Millard, C., Walden, I.: Negotiating Cloud Contracts: Looking at Clouds from Both Sides Now, Stanford Technology Law Review 16(1), 79-129 (2012)

23. Katz, A.: Google, APIs and the Law. Use, Reuse and Lock-In, In Lopez-Tarruella, A. (ed.) Google and the Law: Empirical Approaches to Legal Aspects of Knowledge-Economy Business Models, T.M.C. Asser Press, The Hague, ISBN 978-90-6704-845-3, pp. 287-301 (2012)

24. Lings, B., Lundell, B.: On the adaptation of grounded theory procedures: insights from the evolution of the 2G method, Information, Technology & People 18(3), 196-211 (2005)

25. Lundell, B.: e-Governance in public sector ICT procurement: what is shaping practice in Sweden?, European Journal of ePractice 12(6), 66-78 (2011). http://web.archive.org/web/20110429011729/http://www.epractice.eu/files/European%20Journal%20epractice%20Volume%2012_6.pdf

26. Lundell, B., Gamalielsson, J., Katz, A.: On implementation of Open Standards in software: To what extent can ISO standards be implemented in open source software?, International Journal of Standardization Research 13(1), 47-73 (2015)

27. Lundell, B., Gamalielsson, J., Katz, A.: Implementing IT Standards in Software: Challenges and Recommendations for Organisations Planning Software Development Covering IT Standards, European Journal of Law and Technology 10(2) (2019) https://ejlt.org/index.php/ejlt/article/view/709/

28. Lundell, B., Gamalielsson, J., Katz, A.: Addressing lock-in effects in the public sector: how can organisations deploy a SaaS solution while maintaining control of their digital assets?, In Virkar, S. et al. (eds.) CEUR Workshop Proceedings: EGOV-CeDEM-ePart 2020, vol. 2797, ISSN 1613-0073, pp. 289-296 (2020). http://ceur-ws.org/Vol-2797/paper28.pdf
29. Lundell, B., Gamalielsson, J., Tengblad, S.: IT-standarder, inlåsning och konkurrens: En analys av policy och praktik inom svensk förvaltning, Uppdragsforskningsrapport 2016:2, Konkurrensverket (the Swedish Competition Authority), ISSN: 1652-8089, (in Swedish, with an executive summary in English) (2016)

30. Lundell, B., Gamalielsson, J., Tengblad, S., Hooshyar Yousefi, B., Fischer, T., Johansson, G., Rodung, R., Mattsson, A., Oppmark, J., Gustavsson, T., Feist, J., Landemoo, S., Lö-nroth, E.: Addressing lock-in, interoperability, and long-term maintenance challenges through Open Source: How can companies strategically use Open Source?, In Balaguer et al. (eds.) The 13th International Conference on Open Source Systems (OSS 2017), IFIP AICT 496, Springer, pp. 80-88 (2017)

31. NOC: The Netherlands in Open Connection: An action plan for the use of Open Standards and Open Source Software in the public and semi-public sector, The Ministry of Economic Affairs, The Hague, November (2007)

32. NPS: Open IT-standards, National Procurement Services, Kammarkollegiet, 7 March, Dnr 96-38-2014, https://www.avropa.se/globalassets/dokument/open-it-standards.pdf (2016)

33. NPS: Förstudierapport Webbaserat kontorsstöd, National Procurement Services, Kammar-kollegiet, Dnr 23.2-6283-18, 22 February, (in Swedish, with a summary in English)
https://www.avropa.se/globalassets/forstudierapporter-vt--it/forstudierapport-webbaserat-kontorsstod2.pdf (2019)

34. UK: Open Standards Principles: For software interoperability, data and document formats in government IT specifications, HM Government, 7 September, https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_d ata/file/459074/Open-Standards-Principles-2012.pdf (2012)

35. UK: Open Standards Principles, GOV.UK, 7 September, https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/459075/Ope nStandardsPrinciples2015.pdf (2015)

36. UK: Open Standards Principles, UK.GOV, 5 April, https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_d ata/file/697195/Open_Standards_Principles_2018.odt (2018)