We are programmers, not businesspeople. But around us, programmers are learning to run businesses, extracting money from the value that they create, and avoiding FOSS burnout in the process. Becoming a businessperson involves a learning curve, but marrying programming ability with business skills can pay off big time, both for maintainers and their users. So what are these companies doing?
In this post, I will explain and demystify the economics that underpin the success of many software companies. Why would someone pay for software? How can software earn money? Will FOSS eat my lunch? These are questions that I will answer in this post.
Let's jump right in.
Building software is expensive, and the initial cost is especially high. Once initial development has concluded and you transition to maintenance (adding features, fixing bugs, and improving performance), costs fall but don't completely disappear. Your customers would like to avoid paying this big up-front cost, and are generally happy paying a small fraction periodically. You, in turn, sell to many customers, and recoup your costs in time. Fundamentally, successful software companies seek to amortize their large initial investment over two things: customers and time.
This is a win for your customers, because they pay a tiny fraction of what it would cost to build and maintain it themselves. They save a lot of money. It is a win for you, because you are able to make back the initial investment, and then some, in the course of time.
Let's take a simple example. Say it costs $20k (or the equivalent of your time) to build the first working version of your software. You charge $100 a month to each customer. This is below even the likely monthly cost of maintenance (one developer hour).
In this example, if you have even just 16 customers, you're already bringing in $20k a year. This is a great return on your investment. If you have 85 customers, you're bringing in more than $100k a year, which is likely enough to sustain your existence.
This is a no-brainer for your customer in multiple ways. Your customer pays a small fraction of what it would cost them to build it themselves (payback time for up-front investment is 16 years). Your customer also does not need to hire, train, or retain expertise related to your library. Your customer can also call on you to fix any bugs that appear, and also appeal to you to build related features. This is all worth a lot of money to your customers.
Fundamentally, this is a great trade for all involved. Everyone is happy at the end of the day. Your customer is happy to pay you, you are happy to accept their money. This kind of win-win situation is crucial to creating a great business.
A good business, just like a medieval castle, needs a moat. A moat is a defensive structure, consisting of a deep, wide trench dug around the perimeter, filled with water. So what does your moat consist of in software? In other words, what is making it difficult for someone to compete with you?
Many things, as it turns out.
There is the building cost. $20k (at a minimum) is a lot of money to invest in building a software library. And that might have gone up in the course of time, as you have added more features and refined the software. Now it might be $40k minimum just to compete.
You also have customer lock-in. This comes in many forms. One is that your customers have now built their software to interface with the specific APIs of your library, and changing this will cost them money. Another is that you might have signed long contracts with your customers (eg, for a discount), and this effectively takes them off the market for a period of time.
When you surveyed the market, you saw an empty field. Nobody was offering a solution to the problem you were trying to solve. Now you are an established player, so when potential new entrants are surveying the market, they won't see an empty field, they will see you. You didn't have to compete with anyone, but new entrants must compete with you. This means that a new entrant may end up being rewarded with zero customers for his trouble.
A common source of libraries is people building solutions to their own problems, and then extracting that into a library. That might have been how you built your library. But now your library exists, so many will simply take your solution and call it a day. This means it's a lot less likely that someone will invent a competing library in the process of solving their own problem.
That's a lot for potential competitors to overcome, and this has the effect of limiting the potential for new competitors to appear. And indeed, if we look around, we see many niches that are occupied by a single company. These factors will ensure that this largely continues to be the norm. This doesn't mean that you don't have to stay on your toes, however. If you lose sight of new developments in the field, or get too greedy on pricing, you can still lose your customers to an upstart competitor. But far from being vulnerable to attack, if you keep the above points in mind, you will be able to maintain a strong defensive position for your software business.
Maybe. See: BitKeeper vs Git. But also maybe not. See: Sidekiq, iText, Oban, or the many other commercially successful projects that have stood the test of time.
I interview commercially successful software library authors for the website, and I always ask a variation on the question: “why haven't FOSS alternatives been able to compete?”. The answers I get are illuminating:
Your enterprise has a few important advantages over FOSS competitors. You have time and resources to compete with FOSS on features and polish. Paid projects also offer a guarantee of continuity that FOSS projects simply can not. Burnout is a very real thing in the FOSS world, and it has claimed many a project.
It is easy to imagine that it could be hard to compete with free. But the price on the sticker doesn't tell the whole story, and if your software can save a company more money, or solve a problem better than your FOSS competition, you can definitely compete with free. In fact, all of the examples I have mentioned above have FOSS competitors.
I hope this post has helped you understand the factors that have lead to successful software businesses around us. It is easy to imagine, I think, that lightning never strikes twice, or that these people must have had some magical insights that we are incapable of reproducing, but the reality is that if you make something that is useful to someone else (which, to be fair, is not easy), then you can make money from that. And not only that, it will be better for everyone involved if you do. FOSS burnout is a big problem, costing businesses all over the world a lot of money, and nobody benefits from a scenario like that.
In a future blog post, I will discuss the history of software licenses, as this is another crucial element that you need to get right when you are designing a software company. And click here to read about the nuts and bolts of selling your software online and why you should consider using Code Code Ship.
