European Open Source Procurement Guidelines: How Do you Like Them?

Talking about Alfresco’s business strategy I happened to mention that the European open source observatory released guidelines for open source procurement.

The OSOR guideline draws on the extensive analysis conducted by the Dutch government’s OSOSS in 2005, followed by a guide published later by the successor organization to the OSOSS program (Netherlands Open in Verbinding).

The OSOR procurement guideline describe two ways of acquiring open source software: downloading or procurement through a public contract. The difference between the two approaches is mostly about the knowledge and effort needed to search and select the most appropriate OSS.

As part of the acquisition process, downloading software comes after all the steps described above, i.e. the determination of requirements, and is simply an alternative to the step of publishing a tender for the supply of software. It is not proposed here as an alternative to the process of managed, well justified and monitored software acquisition.

The original NOiv report stressed the importance of extensive product selection and investigation of the underlying open-source community (emphasis is mine).

Such an orientation can involve an examination of the origin and popularity of the open-source software, which indicates the number of interested parties involved. For example, the guarantees built into the open-source project to prevent copyright infringements can be determined. It is also important to establish who is offering the software and which well-known parties are affiliated with the software project. The government will also need to look at the community built around the open-source software.

The government therefore has an obligation to investigate in that context, especially when the software is offered free of change.

Open source governance is a must, and ensuring sustainability of government ICT demand answering important questions about independence (i.e. avoiding lock-in) and flexibility (i.e. easeness of customization).

The OSOR draft makes general assumptions:

[..] selection criteria that have traditionally been used to ensure the sustainability of software by ensuring the sustainability of the original vendors (e.g. capital, turnover or size requirements) may not be as important and can be reduced for the procurement of open source software. If, for instance, the original vendor goes bankrupt, users can lose all their investments in that vendor’s proprietary software. If the software is open source, the user can find another vendor to support the software with no legal or technical obstacles.

Open source is not a panacea. Different architectures of partecipation, types of communities and code modularity along with the vendors’ approach to source code development affect independence and flexibility.

Open source vendors’ business strategies enable OSS acquisition by download, but not necessarily support the open source version. Sometimes partners or simply third-parties do that, sometimes not. Open Source vendors are not created equal, nor should they be.

Stefane Fermigier, Founder and chairman of the European open source ECM player Nuxeo that just announced its highest quarter, commenting the draft guideline says:

Nuxeo and many fellow French open source entrepreneurs believe that for the European administrations to reap the benefits of open source software, they need to clarify their procurement procedure and level the playing field so as to enable OSS vendors and system integrators to compete with incumbent, sometimes monopolistic, companies. The work that has been done by OSOR is an important step in this direction. It needs to be completed quickly, and adapted as local policies and guidelines at the national level. We will very soon ask collectively the French government to move forward in this direction as part of a set of remedies against the current economic crisis we will be proposing.

Nuxeo welcomes the OSOR approach. And you?