An Open Source licence grants the four rights over the code — to run it, study it, modify it and redistribute it — but it does not guarantee that anyone will maintain it over the years. The distinction is obvious to developers, and public administration meets it at the precise moment it moves from a decision in principle to running a system day after day.

Context

In Italy the legal framework has been explicit since 2005. The Digital Administration Code (Legislative Decree 7 March 2005, no. 82), in force since 1 January 2006, requires public bodies under article 68 to carry out a comparative assessment of the available solutions before acquiring software: the set includes the reuse of programmes already developed by other administrations and free or open-source software. The legislator states the reason: access to the source is the condition for reuse and for independence from any single supplier.

At European level the frame is the IDABC programme (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens), which produced, among other things, the OSOR.eu platform (Open Source Observatory and Repository): a registry and a collaborative environment for software produced by or for the public sector. In early 2010 OSOR hosts more than 135 projects published by administrations that make them reusable. IDABC closed on 31 December 2009 and is succeeded by ISA (Interoperability Solutions for European Public Administrations).

I write from Tuscany. T-OSSLab was set up in February 2008 under an agreement between the University of Pisa, the Province of Pisa and the Navacchio Technology Park, as a centre of competence on free software. Over these months it has run a survey on Open Source use in Tuscan municipalities and started a catalogue of the products public bodies actually use.

The problem

The recurring mistake is to treat adoption as a one-off event: a free application is chosen, installed, and the file is closed. But software is a living object. Dependency versions change, security updates ship, the body alters a process and needs one more field, a new statute imposes a different export layout.

The right to modify the code, on its own, solves none of these cases. They are solved by someone who can read that code, apply the patch, recompile, test the regression and put it back into production without interrupting service. In a small or mid-sized municipality this skill is not there in-house, and there is no reason it should be: it is not their trade.

This opens a distinction that the plain label “Open Source” hides. An application is free by licence yet, in practice, may turn out to be unmaintainable: when no one knows its architecture, when documentation is missing, when upstream there is a single developer who has stopped replying. The licence is a necessary condition for reuse; real maintainability is a different thing, and it rests on people.

The structure of support

The party that fills this gap is the specialist firm. Not as the supplier of a closed box, but as a party that takes on by contract a set of obligations the free code opens up without compelling anyone to discharge them. It is worth listing them in full, because this is where formal adoption parts ways with sustainable adoption.

  • Corrective and adaptive maintenance: applying upstream security patches, updating dependencies, adjusting to legislative change. This is the work that keeps the system running between one release and the next.
  • Integration: connecting the application to the records protocol, to payment systems, to the registries already in place. Almost no real installation stands on its own.
  • Contributing upstream: fixes useful to everyone go back to the original project, rather than sitting in a private fork that diverges a little more with each release. The case here is technical, not only ethical: a diverging fork is a debt that grows.
  • Training and transfer: the body’s staff learn to use and, where it makes sense, to look after the system, reducing dependence on any single supplier — precisely what a free licence lets them do and what a contract over closed software rules out.

A catalogue of supported Open Source products, like the one started in Tuscany, serves exactly this purpose. It is not a list of available software — any distribution already offers that — but a map of who, locally, guarantees the four items above for a given application.

The critical point

Sustainability is not bought with a licence, it is built with a market of skills. A plurality of firms able to work on the same code is the concrete guarantee that the supplier independence written into the premises of article 68 is real and not merely nominal. If only one party in the world can touch that source, the body depends on it as much as it would on a proprietary vendor — with one difference that is not small: the right to turn to someone else remains, at least on paper.

The practical consequence is that the comparative assessment the law requires should not stop at the licence and the features. It should weigh the state of the upstream community (one maintainer or thirty), the presence of several firms able to intervene, the release history. These are verifiable data: commit frequency, the number of distinct contributors and release cadence are public for any project hosted on a forge.

Implications

For public administration the choice criterion shifts from the product to its ecosystem. A free application with a single maintainer and no local supplier is, for a body that must guarantee continuity of service, more fragile than one with an active community and three firms able to support it, even at equal functionality.

For firms the sustainable model is continuing service, not the one-off sale of licences, which free code does not allow in any case. Contributing upstream, here, is an investment: keeping the version clients have installed close to the official one lowers the cost of every future update.

Limits

The above describes a mechanism, it does not guarantee an outcome. A market of local skills does not arise by decree and is not even across the territory: where specialist firms are missing, the option of turning to another supplier stays theoretical. Commit frequency measures activity, not code quality nor the reliability of whoever maintains it. And the Tuscan survey captures a regional sample at one moment in time: it serves to orient, not to generalise beyond its perimeter. These are points to verify case by case, not to take for granted.

The role of firms in supporting the Open Source adopted by the public sector is the subject of the talk noze brings to the T-OSSLab day in Pisa, documented in the related insight: https://www.noze.it/en/insights/tosslab-oss-companies-contribution/.

https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2005-03-07;82 http://www.osor.eu/ http://ec.europa.eu/idabc/ https://opensource.org/docs/osd http://www.tosslab.it

Cover image: Renzo Davoli during a talk at Linux Day 2010 in Bologna — photo by Davide Alberani, CC BY-SA 2.0 — https://commons.wikimedia.org/wiki/File:LinuxDay_2010_ERLUG_CNR_-_Renzo_Davoli.jpg