Fixing Software Economics

Sustainably Producing Public Goods

In economics, there is the concept of a public good; a product or service that is non-excludable and non-rivalrous. Non-excludable means that it is impractical to prevent people who do not pay for it from directly benefiting from it, and non-rivalrous means that one person using it does not diminish the ability for someone else to use it simultaneously.

These two properties together break many of the mechanisms that markets use to produce goods efficiently. If we cannot prevent access by those who do not pay for goods, we cannot prevent free-riders, and thus there is little incentive for anyone to pay despite the fact that everyone benefits.

Traditionally, economists have seen public goods as an uncommon edge case, that can usually be addressed with funding from governments and nonprofits, albeit with some drawbacks. IP and Patent law also serve as solutions to this problem when a centralized funding approach is less than ideal, though with a different set of advantages and disadvantages.

The classical example of a public good is an idea; it may require a lot of effort to create a good idea, but once it exists controlling its spread can be very hard. Ideally, we want good ideas to spread as much as possible, as they create more valuable the more people have access to them. On the other hand, the difficulty of controlling them means that it’s hard to compensate those who create these ideas for the effort it took to create them.

Today we have software. Software is, in a sense, just an idea. Perhaps “pattern” is a more apt term though. Simple patterns can be propagated via language, though there is a limit on how useful they can be. More complex problems often require more complex solutions, which require more complex patterns. Complex patterns can be propagated via language as well, but they are much more cumbersome and inconvenient due to their size. Writing made this much easier, though mass production of books wasn’t feasible until the mid 1400s.

Mass production of patterns creates opportunities for piracy, threatening the sustainability of pattern production. Luckily, physical media like books have the nice advantage that, with the addition of a mechanism like copyright law, production and distribution can be mostly controlled. Software started out on physical media, but aside from very large programs like videogames that are often still easier to transport via disks and cartridges (though increasingly less and less so), this is no longer the case.

Now, piracy isn’t completely bad; zero cost means that a pattern can be more widely distributed. There’s a very good reason why copyright law was designed to eventually expire and push ideas into the “public domain.” Regardless, we still need to properly compensate the original creator of the pattern.

In the case of software, this is especially true. Software may have bugs and security holes, and it is very important to make sure that the digital tools we use work properly. If we don’t compensate people for their work, we are limiting ourselves to low-quality, under-maintained software.

These concerns are not new.

Gamers have complained for years that the ability to continually update games created by the move away from physical media has resulted in buggier games.

In 2014, the Heartbleed bug in OpenSSL created a massive security vulnerability in one of the most widely used and critical pieces of infrastructure on the internet, and cost at least $500M to fix on short notice. This could have been avoided had OpenSSL been maintained by more than just a couple hobbyist developers receiving only $2,000 per year in donations.

As of the time of writing this, Mozilla, one of the largest companies focused primarily on open source, has just announced it is cutting 25% of its staff, causing many in the open source community to worry that this style of development is getting less and less feasible.

The software industry is moving into economic territory that we have little experience with, and few ideas on how to make work properly.

Finding Solutions

Solving this problem is tricky.

For example, the first solution many jump to is of course donations. Patreon! Github Sponsors! Bitcoin addresses in the README!

Let’s quick run some numbers though. Suppose we have a perfect, or at least pretty good donation system. One that makes it extremely convenient to throw money at all the projects you like. How much money would you expect the average programmer to donate?

Let’s say that figure is $1000/year. If we consider a standard wage for a full-time developer to be $100,000/year, then for every full-time open source developer, we’d need an average of 100 developers donating. This limits us to no more than 1% of all developers working full-time in open source. If people become extremely generous and donate a very large fraction of their income, or if we can talk most open source developers into working for far less than they could make elsewhere, we could bring that number up. Neither solution is really ideal, so we need a different solution.

One of the problems with donations is that it’s very easy to ignore them. If a payment isn’t strictly necessary, why put yourself through extra effort to spend a few extra dollars? Once you can get people to open their wallets however, it generally gets much easier to get them to be generous.

Compare Patreon to Bandcamp; it’s not uncommon for a youtuber with hundreds of thousands of subscribers to have only a couple hundred patrons on Patreon. Fans have to go out of their way if they actually want to support the youtube channel. On the other hand, Bandcamp provides musicians with a Pay-What-You-Want model that allows buyers to choose how much they pay, with a minimum set by the musicians. Bandcamp reports that more than half of purchases are above the minimum price. If someone already has their wallet out, it’s much easier to convince them to spend a little extra.

Another important thing to question is what exactly we want to monetize. Should projects get some fixed amount each month? Should funding be based on purchases of the software? Should it be based on a cut of profits made by those who use it? Should it be based on grants from governments, nonprofits, or the companies that stand to benefit from it? Should maintenance/updates be held for crowdfunded bounties/ransoms? These are all different ways to fund software, and they result in very different distributions of funding with different priorities.

We can go deeper. Should funds be distributed to just the regular developers, or to everyone who commits code? How should the value of each commit be calculated? Should small projects band together into funding pools to more evenly distribute funds? Should we do the same thing with software where it may be unclear to someone unfamiliar with technical details which projects deserve the most funding and when? How will improvements in formal verification, etc. change the maintenance requirements of software? Should software that’s sold on a per-unit basis include a “pay-it-forward” approach where users can pay into a pool to help those unable to pay for the software to get it for free?

A popularity-focused model might not be perfectly ideal. Look at command-line tools like grep. They’re very popular, but they don’t need much in terms of maintenance. If we chose to throw funding at them, it could be argued that those funds would be better invested elsewhere. There is the point that people who produce very valuable things should be rewarded well, as they’ve proven themselves capable of producing valuable things, and we’d prefer if they had plenty of resources to invest in other projects. At the same time, there’s a point (even if it’s very hard to pinpoint where exactly it is) where that money would be better spent elsewhere. Some people also just get really lucky.

I don’t think we can really expect a perfect solution, but a variety of solutions for different niches and situations is something that we should pursue. That’s the approach we take with software licenses; MIT, BSD, Apache, GPL2, GPL3, LGPL, WTFPL, and the rest all exist for good reasons. Perhaps future software distribution platforms may have a wide variety of templates for funding models in the same way we do licenses today.

Now is the time to have serious conversations about this, and more importantly to start building solutions.

The Consequence of Failing

I think the consequences of failing at this perhaps go beyond what most people would expect.

Where the money is in software development is directly drives what’s feasible and infeasible to build. Money is a feedback mechanism that tells people “do more of this!”. In theory this incentivizes progress, but sometimes a misalignment of incentives drives people elsewhere, and it’s our responsibility to realign these incentives the best we can in the most stable and sustainable way we can.

If you have a company building software, one solution to the funding problem is to run everything on your own servers. Sell services, not applications. This has many money-making advantages. You can charge a toll for usage, and can simply not provide the service to those who do not pay. You can justify that toll by pointing to your big, expensive servers. You can track everything everyone does and sell their personal information. You’ll make even more money doing that if you’re willing to sell that data to some really shady organizations. It may be unethical, but it lets you wipe out a lot of competition by giving away your service for “free”. You can go further and build network effects and addiction-inducing designs into everything to make it even harder for others to compete. When people complain, it’s a lot easier to lie about what your software does if it’s hiding on a private server that the public can’t independently audit.

I hope it’s not too controversial that this isn’t exactly an optimal solution. There are cases where a centralized service may be the best option, but we should be sure to judge whether the benefits really outweigh the costs, or if a better solution is possible.

Another recent example; there are those complaining about Apple taking a 30% cut of all transactions through their app store. Similar complaints have been targeted at a variety of other platforms too. BitTorrent and IPFS show us that centralized servers aren’t necessary for file hosting and sharing. It should certainly be possible to build a purely peer-to-peer online store that allows people to buy and sell digital goods without a middle man (aside from perhaps the payment processor, assuming they aren’t using a cryptocurrency). Of course, the market doesn’t currently incentivize this strongly; after all, while this would be very valuable to many people, where’s the incentive for those who build it?

Peer-to-Peer applications might not be ideal for every situation, but there are many cases where they have many advantages over the highly centralized services we currently see a lot of. Even in the cases where they introduce difficulties, they may still be at least worth investigating. Tracking the exact numbers of likes/dislikes/retweets/views/etc., on content might make social media harder to build, but it also might just incentivize us to build less quantitative social media platforms. Worst case scenario, it’s at least more options and competition for better software.

Then there’s the problem of software development tooling. This could be a whole, lengthy series of articles on its own.

This may be a controversial opinion, but I think that software development tooling — compilers, debuggers, IDEs, etc., have barely improved since the 1980s, if not earlier. You could perhaps even argue that there are very few widespread ideas newer than 1968.

While a full argument would probably be best for another time, I will make one point; Abstract Interpretation. Abstract Interpreters, for those unfamiliar, are tools designed to form sound approximations of undecideable problems. They are extremely powerful tools for automated detection of bugs in software, among many other things. Think of them like a debugger on steroids, though perhaps that’s not even giving them enough credit.

While used to a very limited extent for compiler optimization, they mostly have not left academia save for the occasional company that will sell you one for an arm and a leg and then some. They’re mostly used by companies writing software for cars, planes, medical devices, and other industries where bugs can easily cost lives. This is technology that could certainly find its way into a standard software developer’s toolkit, and would be extremely valuable. However, this is non-trivial software, and bugs in it can be costly (if there are bugs in the program telling you whether or not your program has bugs, what do you do?).

The problem is that developer tools, especially the most important tools like compilers, are almost always free. After all, if you build a programming language and try to charge money for it, many people will unwilling or unable to pay for it. Arguably the biggest factor that makes a language valuable isn’t the language itself, but the ecosystem around it. When you rely on the community around it to build such an ecosystem, any barrier to entry, especially a financial one, can seriously hinder any path to growth.

Simply put: free languages outcompete non-free languages.

If it were easier to actually build a business around building programming languages, I think there’d be far more innovation going on. Instead, we’re left with languages, IDEs, and debuggers that haven’t changed meaningfully in decades despite very promising work in academia. New approaches are needed.

Let’s Start Building

Rather than just speak about this, I’m putting effort in myself, and I encourage others to do the same.

Badger Labs, the startup I run with Will Pangman, is working on peer-to-peer software and experimental development tools. While we’re not quite ready to release anything quite yet, we are currently developing a very experimental new programming language, among other things. We plan to try out new funding models for our projects.

We also are working on releasing articles and podcasts, some of which will be free, and others will mostly serve to experiment with a variety of new funding models. Though the exact subjects will vary, many will be focused on discussing these problems in more detail. There is an awful lot I had to leave out of this article.

You can follow us and reach out at @BadgerLabs on Twitter if any of this sounds interesting to you. If you have any feedback, or ideas, or just want to have a conversation about software economics, please reach out!