Part of the problem in the software industry (and one that open source partially addresses) is that the business models fundamentally do not reflect economic realities.

Software is, to within a rounding error, a zero marginal cost good. This means that, once you’ve made one of a thing, the additional cost of another (the marginal cost) is zero. Most things benefit from economies of scale. If you make one bespoke widget, you have a bunch of costs in fabrication on top of the materials costs. If you build a factory to create widgets, the cost of the factory is big, but it’s amortised across all of the widgets you make. If you spend $1,000,000 building a factory and aim to sell 1,000,000 widgets, the factory cost contributes $1 to the cost of each widget. For simplicity, I’m going to lump all of the R&D effort involved in designing the widget and figuring out how to build it in the factory costs. They are slightly different classes of costs (they don’t scale with the rate of production, whereas if you want to make widgets twice as fast you will need a bigger and more expensive factory) but they’re broadly similar.

If you somehow increase your market and can now sell 10,000,000 widgets, the factory cost adds only $0.10 to each widget. The more you sell, the lower your fixed up-front costs are as a proportion of your total costs. As these go down (or are paid off by early profits, so the factory is now effectively free), other costs matter more. Factories aren’t magical replicators. You need to feed them with raw materials (or components). You need to pay people to operate them. You need to pay for maintenance and repairs on the factory itself.

Even after the cost of the factory and R&D are all paid for, there’s still a cost. If you’re selling widgets for $10, these costs may add up to $8/widget and, as the other costs are paid off your profit goes from $1/widget to $2/widget. The model where you build the factory as an investment and aim to recoup the money selling widgets makes sense to you, but also to your customers. They can view it as spending $8 on materials and operating costs and $2 renting a factory (which is far cheaper than the $1,000,000 to build their own).

Software does not work this way. The cost of writing software is high. It takes time and skill, and more time and skill to test it. If I wanted to write a word processor, for example, I’d need to hire a moderately large team (tens to hundreds of people, depending on my exact feature requirements) and it would take them a few years to ship the product. Once they have built it, creating a second copy costs (to a first approximation) nothing. If you have a bunch of users who want a word processor, I can sell it to you, and the cost to me is no different if you have one user or 10,000 users.

Business models that make sense for zero-marginal-cost goods are tricky. If it cost me $10,000,000 to make and I think I can sell it to 100,000 people, I can pick a price of $100/user. If you are buying it as an individual, that seems like a great deal: far lower than the cost of building it yourself. But if you are a company or government with 1,000,000 users, you could build it in house for a tenth the amount. Except you aren’t a software company, so maybe you don’t want to. And I really want that sale, so I can give you a discount.

And that’s where it starts to get weird. If I can guarantee 100,000 sales at $100 each, any additional sale I make at any (positive) price is profit. If you want 10,000,000 licenses, I can five you a great deal of only $500,000 and that’s still pure profit for me. Wonderful.

But, at some point, I’ve sold my word processor to everyone who wants a word processor, and I’m employing a team of people who are experts in word processors. Because I’m selling software as an immutable artefact, the obvious thing for me to do is figure out some new features people want and do a new version.

New versions are great because they cost you a lot less to make than the original (they are incremental changes) but would cost a new competitor more because they would have to start from scratch. Now, my total development cost is $15,000,000, but I’ve already paid for two thirds of that. I had to fix some technical debt, but a new competitor would have to spend $13,000,000 to reach the same feature set, so I can sell this as if it cost me as much to make as the first version and customers still think they have a good deal. And maybe you give existing customers a discount on an upgrade version, so they are even more likely to stick with you than go elsewhere.

Eventually though, I hit diminishing returns. You, the customer, look at version 47 and say ‘actually, I can’t think of a single feature introduced since version 42 that I use, why should I pay for the new version?’. And a big customer may think ‘I’ve been buying this for ages and version 23 was pretty much feature complete from my perspective, maybe I should pay someone else to build an equivalent of version 23 that I own and can add new features to if I need them’.

My incentive is to make the program big and complicated so that you don’t really believe you could create an equivalent. The more features, the better. Because someone probably needs them, and you need to be able to interoperate with them and so you can’t replace my product with something that isn’t exactly feature compatible.

To address these risks, I you need to keep adding features and convincing users that they want them. Spell checking, grammar checking, cloud syncing, AI, and so on. Some of them are actually useful, some I put marketing effort into so people are convinced they need them even if they don’t know why.

And, hey, if that fails, I can always make some changes to the file format so that old versions can’t open the new documents. Oh, sorry, your customers are using version 50 to send you purchase orders? I guess you’ll need to upgrade to be able to read them. Please talk to my sales team, I’m sure we can come to some arrangement.

And all the while, there’s an elephant in the room: bugs. Version 38 had a nasty parser bug that let someone who sent you a maliciously crafted file compromise your computer. Version 39 had one where if you made your company name bold, it would crash. And you do want these fixed.

And now we get to a really tricky problem. If I’d done the level of formal verification required to absolutely guarantee that none of these bugs existed, I’d have had to charge $10,000 for v1 and no one would have bought it. At the same time, you (quite reasonably) think you paid for your copy and so should expect bug fixes (and, especially, fixes for security issues): it was sold as a working product, even if the small print did have some disclaimers of liability.

So I propose a compromise. You buy the current version and I’ll give you free bug fixes for three years. But what bugs will I fix? That bug with crashes for bold on your company name is triggered on your corporate letterhead and nothing else. Engineer time to fix that will cost more than I made on sales to you. So maybe I don’t fix that one especially, but it turns out that v40 had refactored that code while adding a new feature and now the bug is gone. So now you need to buy the new version. Unfortunately, the new features also introduced some new bugs.

Okay, this clearly isn’t working. I have a new idea. I’ll sell you a subscription instead of a product. For $50/year, you are always running the latest version. This is good for me in two ways. First, I don’t have to maintain back-ports of bug fixes to old versions, I just have one supported version. Second, I have guaranteed revenue. It’s good for you because you can predict your spending well in advance.

But, again, at some point you are going to have spent more on the subscription than it would cost to have built the subset of the product that you need for yourself.

So my incentives are the same. I must make the app as big as possible so you don’t think you can replace it. I must tightly couple it to all of my other products, so you can’t replace just one bit. Sure, you could replace my word processor, but it talks a proprietary protocol to my cloud back end for collaborative editing, and that uses the same namespace as my file storage, so you lose that if you switch. And the collaboration is built around my proprietary account management system which you use to restrict access to people in your company (and specific people or groups).

I build plugin interfaces that make sure the plugin is subservient to my program, so other people can add value to my ecosystem but can’t become competitors, rather than allowing interoperability with peers where you can select the components you want and that might not include any of mine.

To maintain my business model of writing software for free and then charging you to use it, I must build things that are bad software engineering and user hostile.

A F/OSS system has none of those incentives, which is why it makes me so sad to see them copying these structures. A F/OSS platform could focus on lightweight interoperable components that users can compose in arbitrary ways. A system in which the cost of developing a new component for a specific use case is small enough that individual programmers can do it and other people can afford to pay a programmer to do it is great for a F/OSS ecosystem. Paying someone to add a feature to a massive monolith like LibreOffice is hard (not least because they must be able to upstream it, which requires time and effort from upstream maintainers, if you want to use it long term). Paying someone to write a component for a modular component system is much easier and doesn’t require anyone else to like it.

Component systems were popular in the early to mid ‘90s, but died out because they are hostile to the COTS business model. Microsoft realised that replacing Office with a set of COM components that composed to build arbitrary document classes was completely feasible, but paved the way for competitors to incrementally replace them and displace MS Office’s dominance. The trend has been in the opposite direction, towards walled-garden operating systems with siloed apps, each striving to become the legendary ‘everything app’.

F/OSS doesn’t need to copy this. It can build structures that proprietary software simply cannot replicate because they are directly incompatible with a rent-extraction model for funding development. And, in this world, licenses like the GPL are both unnecessary (someone wants to incorporate my component in a proprietary system? Go ahead, it won’t be competitive in my ecosystem) and harmful (in a system with a hundred individual components tightly collaborating, where my document includes a custom plugin that is a derived work of ten other plugins, what are my legal obligations if I send this document to my lawyer under attorney-client privilege?).