Is a 100% Discount The Same As “Free”?

For the last year or two, I’ve been giving a talk at conferences around Europe about free software. It’s called “open source, open mind: the cost of free software”, there’s a couple of recordings of it up on Youtube if you want to check it out, and, like a lot of my conference talks, it’s a mix of history, case studies, and my own experiences working in tech.

One of the perennial challenges facing the craft of software development is that I think our industry has a tendency to attract people who like to create. I know dozens, probably hundreds, of people who became software developers because they enjoyed the activity of writing code, of sitting down and creating a solution to a problem. I don’t know anybody who got into tech because they enjoy reading code - most of us still don’t; reviewing code is way less fun than writing it. This tendency for software developers to ignore prior art because, well, gosh, it’s great fun reinventing the wheel over and over again - it’s one of the reasons I spend so much time talking about computer history. A few years back somebody was very excitedly telling me about something called a microSPA; a SPA is a single-page application, and a microSPA is a very small single-page application; an individually deployable unit containing HTML, JavaScript, CSS… that’s right, they’d reinvented the web page. And it only took twenty years.

I think it’s important to talk about the history of free software because I keep seeing the same patterns playing out, over and over again - and every time they do, somebody ends up burning time and brain cycles on solving a problem that we already solved, and I wonder what new and fascinating things they could have created instead.

I want to talk about two of these patterns in this video. First - let me know if this sounds familiar to you: somebody creates some free software. Free, as in, it doesn’t cost any money. It’s out there on the internet and you can download it and use it and even incorporate it into your work projects - projects that make your company money. And you do, whether that’s by installing a package from NuGet or npm, or connecting to some sort of online API, or cloning their github repo and building it yourself.

What you don’t see is the flipside of that. The person who created that library? They’re doing - and sharing - that work because at that point in their own life and career, that makes sense to them. Richard Stallman’s Free Software Foundation has popularised the idea that giving away your source code is some sort of lifelong ideological commitment, a fundamental part of somebody’s identity - but really, that’s not how any of this works. What normally happens is somebody’s working in some kind of agency or consultancy, they create a library which gets used internally across multiple projects for different clients, there’s a conversation about making the source code available - which, at that point, makes a lot of sense; clients get that code under a public license, it gives the agency something good to say to candidates when they’re recruiting, and maybe they’ll even get community contributions that add features or fix bugs. Everybody wins.

Then something changes. Somebody leaves. The agency gets acquired. For whatever reason, the people that used to maintain that project aren’t in a position to do that for free any more - and so the logical thing to do is what a lot of open source projects and packages have done in the last few years: to say to the consumers, the people and companies who are using that code to make money, “hey, in order for me to keep doing this, I’m going to need to get paid somehow. Seeing as donations haven’t worked, and consulting has pulled me away from working on it, I’m going to try charging for the software itself, so the next version won’t be free”.

This usually splits the community in two. In one camp are the ‘keyboard warriors’, the folks who like to express their outrage on social media; in the other camp are the people who understand software licensing, budgets, compliance - and the cost of replacing or rewriting something which already works. There may be some overlap, but from talking with maintainers who have done exactly this, most of the big corporate users will quietly sign up without making a lot of noise about it, and the people on Twitter and Reddit shouting about betrayal and open-source “rug pulls”… well, they were never going to pay for anything anyway.

There’s another factor in all this, of course. I think it’s absolutely right that companies that get substantial financial benefit from the use of free and open source software should contribute to the sustainability of those projects. I recently found a thread on X which linked to a bug filed on ffmpeg’s issue tracker in May 2023, which included this absolute barnstormer of a comment:

Hi, This is a high priority ticket and the FFmpeg version is currently used in a highly visible product in Microsoft. We have customers experience issues with Caption during Teams Live Event. Please help,  

Microsoft. Microsoft Teams. It would be nice to think that Microsoft Teams could come up with a more constructive way of engaging with the maintainers of ffmpeg than expecting a request for free support to be treated as a ‘high priority ticket’, but unfortunately this sort of interaction between large corporations and small open-source project teams isn’t remotely unusual.

We’re not all Microsoft, though… and that’s where the one-size-fits-all model breaks down pretty quickly. The sort of licensing fees that are a drop in the ocean to big tech companies could be a dealbreaker for a startup that’s just getting off the ground - and for projects which are themselves free-as-in-free-beer, for student and hobby projects; those projects are never going to be able to justify hundreds or thousands of dollars in license fees.

The problem is that the alternative to paying for a license tends to be “oh well, if we can’t use that one maybe we can just build our own”… which is rarely a good idea in terms of the quality of the software, but also, if you’re at an early stage startup or a small-to-medium business, you should be focusing on your mission, working on the features that are strategic differentiators for your product or service, not spending time building authentication and telemetry and data persistence and all the other stuff that’s already been solved over and over again.

Now, none of this is a new idea. The first project I know of that switched from a completely free license to something more restrictive was ServiceStack, which switched in 2014 from a BSD license to a hybrid commercial license. Their approach was interesting: free licenses for genuine solo projects, defined as anything where a single person was the sole author, contributor and copyright holder of all the code in that project. They offered free licenses for projects that in turn published their own code under a compatible open source license - and if you didn’t qualify for a free license? $299 per developer for small organisations - fewer than ten employees; $999 for large organisations. That was, and is, a per-developer, one-time, perpetual license - you get a year of maintenance and upgrades, and any new releases during that maintenance period, you can run those releases forever.

The company I was working for had half-a-dozen developers working with ServiceStack at the time, but we had over fifty employees, so for us upgrading from the BSD-licensed ServiceStack 3 to the new licensing model would have cost six thousand dollars. The budget meeting about that one didn’t get very far - and I get it; although we were using APIs for all kinds of internal stuff, they weren’t a key part of anything that actually generated revenue, and I didn’t know back then about accounting models like Cost of Delay, which might have given us a way to calculate the value of the time we saved by sticking with it instead of switching to a different framework or building our own.

ServiceStack is a really useful case study, because they did this ten years ago. With a whole load of high-profile projects switching their licensing over the last few years - IdentityServer, Redis, Terraform, and more recently AutoMapper and Mass Transit - there’s been a very predictable reaction; community backlash, a fork of the last version of that product that was published under an open license, and a lot of folks asking what happens next? Well, ServiceStack has gone from strength to strength, shipping a steady stream of new versions and features. It’s a solid, sustainable, commercially viable product. The community fork of the last BSD codebase? That was NServiceKit, which was very exciting for about six months before enthusiasm ran out. It’s now been a decade since the last commit. I assume because its creators realised what every fork will find out sooner or later: if you fork a free project because it’s going commercial, all the people who are happy to pay for licenses, support and maintenance will go with the upstream project, everybody who expects support and maintenance to be free will beat a path to your door, and you’ll be expected to maintain feature parity with the project you forked and do it all for free out of the goodness of your heart.

Now, one thing I think ServiceStack got wrong was to offer free licenses for small projects, defined as projects with fewer than 10 defined service operations, fewer than 10 mapped database tables, and a limit of 6000 requests per hour on their Redis client when running without a license, those kinds of restrictions. 

I applaud the objective here - hey, use our software while you’re getting started, and pay for it later once you need the extra scale. But I think those kinds of limitations in any kind of software aren’t a great idea, because they put a  financial roadblock in the way of what should be an architectural decision. Imagine you’re working on a project, you’ve got a team of five developers building a new feature and turns out the best way to deliver that feature is going to require mapping one more database table - except, oh crap, we already used our ten free tables. That eleventh table is going to cost you five thousand bucks - and meanwhile, if a billion-dollar Fortune 500 company is only using nine database tables, they’ll still qualify for free licensing.

There’s a bunch of different ways that other projects have approached this:. 

Duende’s Identity Server, an open source authentication framework for .NET, has a pricing model based on the number of client IDs you’re running - there’s a startup license that’s fifteen hundred dollars a year for up to five client IDs, then five hundred a year for each additional client ID up to fifteen, where it switches to the business license, nine thousand dollars for fifteen IDs, everything in the startup license, plus some additional features like automatic key management. They also have a community edition that’s free for companies with under $1 million of revenue and under $3M of capital.

Chris Patterson also seems to be going with something like this for MassTransit, with a free tier for organizations and nonprofits with up to $1 million of revenue or expenses

Just so we’re clear, a million dollars sounds like a lot of money - and yeah, to the vast majority of the people living on this planet, it’s a life-changing amount of money - but when you’re a tech start-up, a million bucks really doesn’t go very far. Hire some engineers, bring in the hardware and infrastructure for them to do their jobs, pay your lawyers, your insurance, your rent … and it’s gone.

I think this is why we’re seeing some projects raising that a bit higher. For example, Jimmy Bogard set the level for his community edition of AutoMapper to be free for companies up to $5 million of revenue and $10 million of capital. 

I think the original version of these various free offerings was Microsoft’s BizSpark programme way back in 2008, which provided free and heavily discounted access to Microsoft developer tools and Azure hosting to startups for the first two years of operation - the idea being, I assume, that within two years either the startup is generating enough revenue to pay for those services, or it’s done what most startups do and quietly shut down because it ran out of money; that programme has evolved over the years and today is called Microsoft for Startups, and - this being 2025 - offers free AI and Azure credits to companies which are just starting out.

Particular also just put out their version of this for NServiceBus, using the more generic term of “financials” to cover revenue, capital, and expenses. They set up this “sliding scale” which starts with the same 100% discount for organizations up to a million USD of financials, just like Duende and MassTransit; but when you go past that, you don’t start paying full price right away. Instead, the discount goes down just a bit to 90%, and passing two million it’s reduced to 80%, at three million it’s 60%, at four million it’s 20%, and only when you pass five million dollars you pay full price.

Now, full disclosure: I know a lot of the folks at Particular, we’ve collaborated on a few things over the years, they gave me a heads-up that they’d be announcing this, and they know what’s in this post ‘cos I sent them the draft before I published it, so this isn’t an unfiltered reaction piece… but in another way, it kinda is, because I think this is fantastic.

First of all, it’s an interesting new take on what everybody else has been doing. Second, it solves a real problem for growing companies - you’re not going to suddenly find out one day that your last quarter accounts have pushed you over a threshold and you’ve gone straight from zero to full cost. And third, for existing small businesses using NServiceBus, they’re about to get a nice discount on their NServiceBus bill.

Another detail I think is worth mentioning was that all of these projects excluded “priority” support from their free and discounted offerings - which I think is entirely justified. Good support takes time and expertise, meaning that it can usually only be done by the project maintainers - the very people whose time is stretched thin and are struggling to get to financial sustainability. That’s why I don’t think anybody who’s getting the benefits of fully-discounted licensing should expect to get the same degree of support as the organisations that are paying full price.

Point is, there are organisations with money - whether that’s revenue, assets, or investment - and not just the big brands, but the countless mid-sized banks, insurance companies, and even government entities. They can, and they should, be paying for the stuff they use. These are the last people who are going to complain about “rug pulls”. Professional developers in these contexts clearly explain to their bosses and clients, “so, this thing used to be free, and we used it a bunch, and from the next version it will cost this much. Replacing it with something else that’s free will take roughly this many hours. What do you want us to do?” A rational boss, or client, will tend to accept a reasonable license cost rather than incur the risk of a rip-and-replace; as Nick Chapsas said in a recent video:

You sort of should assume you take a risk by just using something that’s free out there. There’s no contract [covering] … what’s going to happen in the future.

But for all of those organisations that don’t have that kind of money; the startups, student projects, open source, small independent agencies, not to mention the large parts of the world where local market economies operate on an entirely different scale - these discounts can be just what they need to continue to build upon solid foundations, meaning they wouldn’t need to change anything when the open-source projects they use commercialize - so no “rug pull” here either.

A bunch of us have been talking about how we can take these things forward and enable more open-source projects to achieve sustainability. We’ve seen how standard OSS licenses like MIT and BSD have helped accelerate legal acceptance of open-source software, so we think some kind of standardization around commercial terms and discounts could be helpful. What exactly that would look like is still being discussed, but my hope is that by putting out this video describing some of these approaches, the next OSS maintainer will think to themselves, “yeah, I can do this too”. 

One final thing I’d like to add: I see occasional online comments about projects “going closed source”… well, that’s just not true. Every single one of the projects and companies I’ve mentioned in this video remains committed to sharing the full source code for all their products, so that developers who are relying on that code can download it, build it, step through it in the debugger if they need to - that’s a big part of “open source”; the ability to obtain the source code, study it, modify it if you need to, and even maintain your own fork of it if you don’t want to rely on the original vendor. All we’re saying here is that if you’re using these projects in a commercially significant context, you should expect to pay something towards their maintenance and future development - and if some sort of scalable discount model makes it easier to reach that point, I think that’s a good thing for everybody involved.