Sovereign Lumber

Two talks that stood out for me at 2024 Open Source Experience conference in December were by Emily Omier, with the software analogy to lumber and chairs, and by Jutta Horstmann on software sovereignty in Europe being more urgent than ever. These connected strongly in my mind, and hit at the essence of what’s missing in the open source ecosystem today.

Lumber and chairs

First the analogy, briefly:

• Software itself (code, which may be open-source) is like lumber. It’s a product, used to make other products for consumers.
• The product for consumers is more than code. It’s ready-to-use well-maintained software, which may includes nice packaging or installation help, support, services, seamless upgrades, SLAs, compliance contracts, customizations, white-glove onboarding, etc. That is analogous to chairs.

The talk went on to a point about publishing lumber and selling chairs, which may work for some businesses selling products based on open-source software.

During Q&A, a question came up about the lumber-and-chairs analogy. "Lumber decays; code does not. Doesn’t that make a difference?" Ah, but software does decay! In fact, faster than lumber. This is my first big takeaway, with a strong connection to the sovereignty talk.

European software sovereignty

Jutta Horstmann’s talk focused on politics. European governments depend on software to function, and the software comes from big American companies, such as Microsoft, Oracle, and Google. They are concerned that the U.S. will use this dependence for geopolitical leverage. They saw enough in Trump’s first term to see it as a matter of “when”, not “if”. In case not everyone was convinced, she also mentioned cases when these American software companies jacked up prices drastically, with major impact on budgets.

They are shaken, vulnerable, and they see it as vital for Europe to reduce this dependence. That’s where open-source comes in.

I can’t help but think of my own reasons to prefer open source software over the proprietary kind. It’s a matter of trust, independence, and yes — price.

Jutta heads Germany’s new Center for Digital Sovereignty of Public Administration (ZenDiS). ZenDiS now leads a project to provide a “sovereign workplace” for public servants that combines open-source software from several vendors.

One slide singled out the promising “openDesk 🫶 La Suite” collaboration. La Suite is the sovereign suite from the French DINUM (La Direction Interministérielle du Numérique), which takes a different approach, includes different software, but aims to solve the same problem.

In the lumber & chair analogy, it’s very clear that any sovereign suite will do most of the “chair” part on its own — in particular, host and operate the software for its government within their own country. They may pay the software creator for some services, but chairs aren’t the main value here. We need to talk about the software itself, the lumber.

Lumber is not free

As an open-source enthusiast, I like to point out how the best software turns out to be open-source. Look at Linux for server operating systems, Postgres or MySQL for databases, code editors, compilers, web development frameworks. So many examples.

And yet this is a bit of a lie. For software whose users are technical, many of the same users are capable and interested in contributing to it. Improving such software is directly beneficial to their job. Big companies often recognize this and hire core contributors. The open source model works great for such software. The community produces the lumber.

But the best end-user software — the kind for non-technical people — is… sadly… not open-source. Think of productivity tools, like documents, or spreadsheets, or videoconferencing. Its users can’t contribute to building it. The technical community capable of contributing is only a small fraction of its users, and usually much less motivated. For such software, there is a thriving "lumber and chairs" business: Microsoft Office, Google Workspace, Zoom, and dozens of other businesses for well-known popular products, and thousands for assorted consumer and B2B proprietary products.

Quality software for end users is not free lumber. It takes a serious investment to make such software, and — when it fits the need — brings plenty of customers who will pay. The money paid by customers for proprietary software pays back the investment, pays for maintaining and improving the products, and occasionally goes on to pay executives and investors, at scales we struggle to comprehend.

It doesn’t work to make such “lumber” free. Yes, there is open-source software in this category. It usually struggles to compete. Sometimes it has quality but lacks marketing or sales behind it, and languishes behind worse commercial options. The exceptions prove the rule: for instance, Firefox and Blender 3D. Both great products, but both are built primarily by paid engineers, rather than by a community; and the money comes mainly from big companies with non-open-source business models. (E.g. Firefox development is paid for mostly by Google, from having Google as the default search engine in Firefox.)

Neither is the "lumber" cheap. There have been efforts to build sovereign software suites by hiring some developers, and giving them the specs. It hasn't worked. Both DINUM and Zendis projects are now trying to build their suites around open-source software projects. But open-source projects are either struggling to be better than proprietary offerings, or struggling to survive, or both.

Decay

A big challenge with open-source software for end-users is that it decays, and sometimes fast.

A stable library may last for decades. For instance, LAPACK, for linear algebra, was written in Fortran in 1992 (with parts from well before then), and with its C bindings, it is still in active use. On the other hand, a browser, if not updated regularly, is an invitation to hackers. Firefox had 30+ releases over the last 12 months. Using a browser from a few months ago exposes you to security holes. Using a browser from a few years ago means that some websites will not work correctly (plus many security holes).

Software needs maintenance:

• Short time frame: urgent fixes such as security patches. They are important to develop and apply as quickly as possible, to reduce risk of attacks.
• Medium time frames: bug fixes and updates for interoperability with other systems. Software doesn’t exist in a vacuum. Particularly user-facing software often interfaces with other systems (at least OS or browser, and usually many other things). As the world around it changes, it must be someone’s job to keep up.
• Long time frames: improving the software to keep it competitive. Think new functionality, or working on mobile, or running in a private cloud, or integrating with the next hot thing everybody is asking for.

This is all the "lumber" part, not the "chairs" part. The software — the code itself, whether open-source or not — needs investment and it needs revenue, not only to make a return on investment, but also to stay healthy.

How to make (no) money

It’s been a long story to convince you that open-source software — at least the kind for non-technical audience — needs to make money.

Perhaps not all of you, but I know that at least some of you do need convincing. I myself would’ve needed convincing a few years ago. One reason is that there is a hard-to-dismiss beautiful idealistic idea about the FOSS ("free and open-source software") model: in the memorable phrase of Richard Stallman: “Think free as in free speech, not free beer”.

You may have even heard it said that it’s totally possible to make free and open-source software, and sell it. You may even know companies that do that.

And yet this is a bit of a lie. To be considered properly open-source by the community, software needs to have an OSI-approved license, in particular, satisfying the definition of “open source” here (https://opensource.org/osd). Let’s look at the main 3 points:

1. The license shall not restrict any party from selling or giving away the software as a component… [and] shall not require a royalty or other fee for such sale.
2. The program must include source code, and must allow distribution in source code as well as compiled form…
3. The license must allow modifications and derived works…

These are shared, not coincidentally, by the essential freedoms from Free Software Foundation.

Points 2 and 3 are about liberty. Point 1 is the liberty for others to give away the software for free.

In other words, it is both “free as in free speech” and also “free as in free beer”. Sure, you can charge for it, but everyone else is perfectly within their rights to give it away. So no, you can’t really charge for it.

For some software, like libraries that become part of other software, there is GPL license which is considered open-source by the community, but which imposes "copyleft" restrictions on redistribution. This can enable the creator to charge for offering the same software under a different license. However, this dual-licensing business model doesn't help the creator make money from their work when it comes to software for end-users.

And so companies that make end-user open-source software go through all kinds of contortions, and usually end up with non-open-source software. It may be proprietary features (aka “open-core”), or licenses that go under the name of “source available” because they give some freedom (like 2 and 3) but are not accepted by the community as “open-source”. Examples abound.

Sovereign lumber

The more you think about it, the more you might inch towards the same conclusion that’s been drawing me: why insist on the same open-source model for all software even though software can be so vastly different — in terms of what it is, who it's for, why it's used, who builds it, and who maintains it?

Why not accept as a community — for some software at least — the “liberty” part of open-source without the “free beer” part?

Well, that’s not good enough. Recall Jutta Horstmann’s talk on sovereignty: independence is what’s important. Yes, the access to the source code and the right to modify it give a measure of independence and trust, but if you have to pay for it, then the vendor has control. They can jerk up the price, and pull the rug from under you. That’s true even if all they control is a part of the software — some proprietary outside-the-open-core functionality, but that's exactly the piece that the vendor withheld from the open-source product to twist your sovereign arm into paying.

Can you pay but not be dependent? Maybe put price controls into the definition of “open-source license”? I know just enough economics to know nothing of this sort can work.

What we need is an arrangement that aligns incentives. It needs these properties:

1. Software creator can charge money, and the customer gets much more value when paying than when not paying.
2. Software comes with strong liberties, but not the liberty to give it away for free.
3. User can pull the plug, and continue using the software without paying the vendor, at a cost of a substantial but realistic effort.

The intended consequence of point 3 is that the vendor cannot get too greedy. As a founder of an open source company, it’s a painful one — investors may continue to prefer proprietary-software companies to invest into — but it’s at the heart of the compromise.

The intended consequence of point 2 is that software itself is monetizable (the lumber, not just the chairs). Without the liberty to give all of it away for free, it is not strictly FOSS ("free and open-source software"), and not OSI-compatible. To open-source enthusiasts, this is the painful one — they may continue to prefer strictly FOSS-licensed options — but this is also at the heart of the compromise.

The goal is to have an ecosystem of quality end-user software, which combines open-source values with development paid for by willing customers, and which wins over its proprietary rivals on quality, price, and the rights of the end-user.

What's very clear about open-source software is that its value comes primarily from the vibrant community behind it — community that shares enough core values to overcome its many disagreements. There is certainly more to say, and there are ideas that could work. I'd love to hear from you, the open-source community, to brew and refine these ideas together.

Please share your thoughts!