Options to have your open-source software and sustain it too

I’m just off (another) call with a public official discussing their options for an open source future. The topic was the domain-specific software needed by any agency, institution, or government (not the generic office or infrastructure software). How to have software for managing health insurance, or school planning, or public transport to be open-source software? At present, it is a hodgepodge of sourced custom typically proprietary software. This particular person had developed open-source software by outsourcing it to a consulting firm and now the project funds were running out. How to make the software sustainable?

It is a common question, and I usually walk folks through their options. Not all options are practical for everyone; what works strongly depends on interests and capabilities, not to mention funding.

1. The simplest option, continuing current practice, is to pay consulting firms for developing open-source software that the public agency can then use. The agency manages the calls for tender and signs off on the results. It keeps paying from its IT budget for the software. Assuming the software is to be run on premise, operations of the open-source software has to be done by the agency’s IT department.
   
   The benefits of this approach are that vendor lock-in is reduced and that the threat of choosing an alternative consulting firm (than the incumbent) will keep costs in check. The downsides are that this approach makes quality control hard and hence the software is likely to be subpar. Also, the knowledge lock-in will lead to high switching costs, though probably less so than with closed-source software.
2. A better option is not just to receive open-source software as the artifact, but to turn development into a true open source project. Like in option 1, the agency puts out calls and consulting firms apply and receive the job. Rather than letting them work behind closed doors and dump some software onto openCode when they think the job is done, the contract requires a true open process, where the agency performs on-going quality control. In open source, on-going quality control is fairly easy: The agency reserves part of the budget for internal staff and this staff approves merge requests or rejects them if quality does not match expectations.
   
   The benefits are an open mostly self-documenting process that ensures quality and makes switching suppliers easier, which in turn keeps project costs in check. The internal developers working for the agency need to be of high quality, after all, they perform mostly quality assurance e.g. conformance with architecture and code quality requirements, in addition to contributing themselves. A downside of this approach is, like in option 1, that the agency has to cover all costs themselves.

Option 1 and 2 assumed that one agency is taking care of its own needs. However, the public sector is a prime example of many players that more or less need the same software functionality and who don’t compete: Hence the same agencies in different states should find it easy to collaborate and pool resources.

Of options 1 and 2, option 2 is the significantly better one. With pooled resources, it also becomes more viable. How to make folks join forces and pool resources?

3. For an open source community to thrive, all stakeholders need to believe that they are welcome and that their investment (time, effort, money) is safe. Open source foundations achieve this: They create a level playing field with defined rules that make it safe and easy to start or join an effort, knowing that clear rules and regulations make sure they won’t get screwed. Prime examples like the Linux Foundation and the Eclipse Foundation show us how to do it.
   
   The benefits of creating or joining an existing foundation are just that: It is much easier to join forces with like-minded agencies and collaboratively sponsor or quality-control or develop open-source software if the rules of engagement are clear. A downside is that like options 1 and 2 a foundation does not address the free-rider problem: Other agencies, always short on money, may simply decide to use the open-source software and not contribute at all.

One answer to the free-rider problem is to not license out using an open source license but to create a closed group of users. A new user has to pay in and help those who paid in before to recuperate some of their investment. This is not exactly an enlightened solution, but a workable one. The perfect is the enemy of the good and if you have to drag your brethren to the light kicking and screaming, so be it.

4. An alternative to leaving the path of open source is to add the dimension of operations through a service company owned by the foundation. Any user of open-source software has to ask themselves whether they want to operate the software themselves or whether they want some service company to run it for them, typically in the cloud. Unit economics then suggest that the commercially provided cloud operation will be a better deal than operating the software themselves, on-premise. This could drive the free-riders to subscribe to this service and an appropriate pricing structure can then rebalance and redistribute investments so that the lead investors don’t end up carrying all the weight.
   
   This service company could be wholly owned by the foundation, or it could be a separate commercial entity. The obvious benefit of this approach is that it can solve the free-rider gridlock problem. However, if the original agencies are heavy-handed and try to control costs too much, a downside of this approach will be that profits will be meager or non-existing and constant salary pressure will ensure that developers and operators will be of subpar quality.

Which brings me to the 5th and final option.

5. The final option is to allow for independent commercial entities that offer the software as a service to all agencies and whoever else. As independent (of the foundation) entities they can be driven by a for profit motive. Most certainly, they will not make everything open source and that is good and a necessity for this model to work. The obvious non-open-source component will be the operations software to operate the otherwise on-premise software with high quality of service in the cloud, as well as all associated technology and capabilities. The foundation has to provide a counterbalance to these companies, most notably to ensure that the basic single-tenant open-source software remains high quality and can be run on-premise by each agency themselves. This is to balance the scales and avoid vendor lock-in.
   
   The benefits of this model are clean high-quality single-tenant open-source software for the agency that ensures their independence and sovereignty, and one or more well-working companies acting with a for-profit motive but under such conditions that they can’t blackmail their customers (easily).

These five options aren’t independent of each other, and they are more like multiple dimensions that you can configure to your needs rather than an escalating sequence of steps of maturity. So I’ve stuck to the patterns of configuration that I have seen rather than build an overly complex model.

Here are a couple of foundations and companies in no particular order that match these options: openKONSEQUENZ, Open Logistics Foundation, Eclipse Foundation, HIS eG, DATEV eG.