There are a lot of discussions happening about forming public sector OSPOs. One question is how to define, or design, a public sector OSPO, and how the concept differs from a private sector OSPO. The distinction is not always clear, and there are sectors, such as academia, where the mixing of public and private is quite deep-rooted. But there do seem to be some general trends and these should be of interest to anyone thinking about the planning of a public sector OSPO. (OSOR also has a page of general information about OSPOs.)
The following table is a simplification, but it's hopefully useful before going into the details.
| Private sector | Public sector | |
|---|---|---|
| Motive | Profit | Public approval |
| Concerns | Competition factors | Efficiency & effectiveness |
| Priorities | Show their value, take credit, keep users | Show good governance |
| Obligations | Need to stand out, focus on innovation | Priority on stability, inclusion, availability |
| Legal situation | Multiple legal jurisdictions | Single legal jurisdiction, but higher expectations to know and apply the laws |
| Constraints | Competition law & cooperation | Investments can't distort market |
| Information level | Often quite confident in their awareness of existing discussions | Sometimes concerned about topics, such as certain details of licensing, that the wider FOSS considers to be a more-or-less finished discussion |
| Geography | International | Single geographic area |
| Structure | Single hierarchy | Hierarchy (or federation) of hierarchies |
| Labelling | Happy to use the name OSPO | Sometimes concerned about expectations of fulfilling all OSPO tasks |
These can be grouped into motivations, legal analysis, and practicalities.
Motivations
Looking at the first four rows, in certain ways, an OSPO's work can be less complicated in the public sector. While companies might be concerned whether publishing their software will benefit a competitor, public entities can share information and software without this worry. If other regions also benefit, that's not a problem.
Public entities are also free from the obligation to retain users, which is one less thing to worry about. The flip side of this is that public sector entities, because they are the exclusive provider of government services, have an obligation to move forward carefully. This is particularly true for choices of technologies, because citizens don't have the option of moving to a different provider if the digital services aren't good enough. This can mean that creating new structures such as an OSPO can be a slower process.
Legal analysis
The private sector is obviously serious about legal obligations, but they can sometimes take a risk-based approach. The public sector, according to people working in this domain, often brings a heavier expectation of knowing all the details of the applicable legal frameworks and how they apply. As the author of legislation, the public sector is also reluctant to be seen as not compliant.
It has also often come up, and maybe it's related to the previous point, that public sector OSPOs sometimes raise legal questions which the private sector sees as more-or-less settled. Licensing is one example. Sometimes questions are raised by the public sector and it can be hard to find documentation because most users of FOSS assume that the answer is general knowledge. A better organisation of legal documentation, including for issues that many might see as "old", could be useful.
Finally, the issue of competition law. In the private sector, companies may have to check before entering into certain types of cooperation with other companies. In the public sector there's no such issue. There is the issue that public funding should not distort the market, but this is not absolute and recent case law in the Netherlands endorsed the publication of government-funded software as free and open source software.
Practicalities
The final three rows cover practical issues.
In a company structure, someone higher up in the hierarchy can often take broad decisions for those below about software policy or calling a meeting. In the public sector there often issues of regional or local autonomy. For geography, the public sector has fewer complications since the entities will usually be physically closer and on the same transport network, which makes meetings easier.
On naming, we asked various people doing OSPO-like work in the public sector why they don't use the term "OSPO", and a common answer was that they're only doing some of the things that an OSPO can do, so they don't want to create the expectation that they do all the tasks of an OSPO. When looking for examples of OSPOs in the public sector, it must be kept in mind that some don't use the name.