I’m going to go through traditional software revenue models, break them down into broad categories and talk about some of the open source models and where Spice Labs fits into this. I’m not going to go into the minutiae of differences in open source licensing. For our purposes, we’re going to consider them to be equivalent even though they are obviously not. Similarly, I’m not going make any claim that my list of categories is exhaustive and some of these items are going to be obsolete or have otherwise fallen out of favor. This is fine - part of understanding where we are is understanding the past and where we came from.

There have been a number of software revenue models that are tied into business models. These have evolved over time depending on the needs or culture of the company or due to modeling that attempts to optimize revenue, distribution, or other goals.

I have worked at a number of companies that have used different categories or, in some cases some companies used combinations of different revenue models depending on the product.

Before I go into the categories, I want to touch on a very important point that can get lost: people within businesses make decisions to determine the revenue model. People can change that model too. I think it’s important to recognize that because part of a review of a product should absolutely include a review of the revenue model and the pricing model.

For example, I worked at a company that sold software components for other people to integrate into their own products or services. At one point, we decided to stop charging for one of our products. It was a bare-bones subset of our main product and it never really sold that well. It made sense to make it free as a goodwill gesture. In addition, the company had a Byzantine licensing scheme. Our customers tolerated it at best and hated it at worst. Our engineering team also hated it because any changes we made in the code had inevitable issues. At one point, our engineering manager would always ask the question, “can we just get rid of the licensing code entirely?”

Catgegories

Closed Categories

While these categories generally are applied to closed software, they may also exist in open source as well. Some of them, Up Front for example, don’t make sense in an open source model - why would you pay for the software when you can download the source for it and build it yourself?

• Freeware - This is obviously not a revenue model unless your model is 0. You give away the product. How do you make money? Volume. If there was a revenue model in this, it was because the freeware was used as the incentive to buy the hardware or it came bundled with the hardware. This was common for editing software that came with hardware. An example of this is when a video digitized hardware manufacturer includes a video editor. Sometimes the bundled software was a limited version of a higher end version in the hopes that you would upgrade to the higher end version.
• Shareware - This was common in the mid 80’s for independent publishers of software. The code was distributed either by early internet means (ftp or usenet) or by floppy disks given out or in floppy disks of shareware anthologies. The software usually came with a splash screen encouraging the user to donate a nominal amount for it. To some, this seems like a naive approach, yet a fair number of people did pretty well with this - certainly better than pizza money.
• Up Front - This can also be called “one and done” - you bought the software, usually on physical media, installed it and ran it. To prevent it from being handed out, the medium either had copy protection to prevent bit-wise copying from working or had a license key that was needed to unlock the software. This was not a perfect system because, for example, you could pass the media and key around your department and everyone gets a copy. From an enforcement side, each copy was watermarked with the key so you could tell that there was a breach in contract through an audit. I don’t know of a case where this happened. Adobe took an a couple approaches to this. One was to require that the media be present to use the software. Another was that the software routinely pinged the local area network to see how many copies were running and would terminate if the that number exceeded a reasonable default. There are, of course, ways to end-run this, but it worked well enough.
• Up Front + Support - In this case, the software costs a nominal fee up front and requires a support contract. You buy the software and install it and if you have problems, your support contract is a guarantee that help is available and updates are timely. In order for this model to be tenable, the company needs to have real expertise in their support department as well as active development and good communication between support and engineering (if they are even separate groups). At one company I worked at, junior engineers were often required to work in support first.
• Up Front + Royalty - This is similar to Up Front + Support in that you pay a nominal fee up front and you pay a royalty fee for every copy that gets deployed. This type of model works best if your product is a component or library that is integrated into your customer’s product. The downside to this is that customers tend to not like paying royalities since it’s a hassle and requires an audit mechanism. Compared to application deployments, there are usually far, far fewer server deployments, which means fewer opportunities for revenue, so server deployments usually cost more and customers aren’t happy about that.
• Try and Buy/Crippleware - For this model, you ship a complete product which has may have “advanced” features locked off or have functionaily that gets locked off after a grace period. This is a common tactic for small or independent publishers. Customers can try the product for a short period and purchase later. The downside to this is that if your product solves a specific problem then customers usually find it when looking for solutions to that problem and if it’s a one-off, they are likely to use it only until they have solved their problem. I worked at a place with a “30 days free” model and it was common to do follow-up sales calls and hear, “your tools were great - we solved our problem during the trial period and don’t need it anymore.”
• Up Front/Free + Add Ons/Updates - Here the core application is priced modestly (the up front costs may vary wildly) and you charge for specific add-on functionality or updates. Many games follow this model for the dreaded “in-app purchases” such as purchasing character skins or upgrades. It’s also the basis for most desktop software in the 90’s which when you bought a particular version, you were encouraged to upgrade to newer versions of the software, lured by either more features or advantageous pricing.
• Licensed/Recurring - This model is the core of SaaS where your customers pay to access your software. From a publisher’s point of view, this is terrific because the software lives on a server and it’s easier to ensure that your customer is abiding by the contract terms (account controlled, max concurrent users, etc), it’s easier to collect data on what features are being used the most, which can be used to inform improvements, and it’s easier to deploy updates, bug fixes, and security fixes. On the downside, individual customers typically don’t appreciate recurring fees as Adobe discovered with online versions of their creative suite. Licensing and recurring fees exist in non-SaaS software as well, but they require infrastructure to ensure compliance with the terms of the agreement. If you’ve ever had to install a license server on your LAN, you’ve encountered this.

As a final note with regards to closed software revenue models, in the past 15 years there has been a steady push for revenue models that feature recurring rather than one-time fees. At one company that was courting acquisition, one of the biggest criticisms was “not enough recurring revenue” which was an interesting take given that the company was successful and growing well.

Open Categories

Open Source software has a number of challenges in terms of building revenue. A lot of these challenges are centered around the notion that if the source code is open, why not just build it myself and go from there? This, of course, is a short-sighted view in that the actual cost is that unless you are actively maintaining the code, you have just accepted new technical debt and you will pay for that technical debt, it’s just a matter of when and how.

• Donation - These are projects that are supported by money donated by users. This is clearly a difficult revenue model as it goes counter to the typical handshake transaction. Instead of “you give me money, I give you product.” it’s “I give you product and maybe you’ll give me some money?” This is a hard model to sustain and larger projects work with this by starting a non-profit foundation which actively solicits donations. Examples include The Document Foundation and the Wikimedia Foundation.
• Support - In this model, the software is free and open, but if you need support, that costs money. Support can be forum access, talking to a support engineer, getting features or bug fixes put into the fast lane, custom builds for a specific platform or operating system, etc. While not as challenging as a donation model, it is still an uphill battle to get people to pay a fee to join forums or buying a support subscription. It also creates an inherent conflict of interest. When writing software, especially components, it is vital to also write documentation to explain how to use the software, otherwise engineers will be less willing to use the product. If your revenue depends on people not understanding your software, then where’s the incentive to write (good) documentation?
• Integration/Consulting Services/Customization - Integration means that you help your customers integrate your code into their product. The main reason for doing this is that you, the author of this code, are very familiar with the ins and outs and how it can fit into several different models. When faced with an integration challenge of code that is out of the organization’s wheelhouse, it looks like a slam dunk to pay the author of the code to integrate it instead of paying your own engineers to first learn the API, integrate it, make mistakes, reintegrate it, etc. This is hard to scale, hard to predict, and can typically only be done serially.
• Service + Secret Sauce - In this model, the main software is open and free, but not fully so. The main product usually is open/free, but key important behaviors are not. For example, Xamarin provided open source versions of the .NET tools and enabled the publishing of cross-platform apps to various app stores, but the keys parts that enabled that was closed source and that was what they charged for. They had several tiers of pricing that were scaled to the size of your shop. Xamarin was very successful using that model. The essence of the model is that you need to understand where the value lies in your code and make a decision as to how charging for that will affect your customers willingness to pay for it when there are some islands of closed source.

There are other ways that the “secret sauce” aspect plays in. One, which is part of Spice Labs, is to amass data and its relationships. This is where Artifact Dependency Graphs (ADGs) come in. We have used internal tools to mirror major code repositories and have built ADGs with Goat Rodeo and populated a database with that information. The barrier to entry to doing this is time and expertise. So this database is part of our “secret sauce”. The other part is that if you run Goat Rodeo either directly or indirectly with Surveyor, your ADGs can be uploaded with your Spice Pass for analysis against our existing database of ADGs. There are several important applications of this - one is to determine where you have code which exposes vulnerabilities. Some of these vulnerabilities are very likely to be hidden in dependencies of dependencies and some of them will be surprising. For example, in building ADGs of .NET assemblies, we found Java dependencies. So if you thought you were safe from the log4j vulnerability just because you’re a .NET shop, think again.

Of course since the data we’ve aggregated is in a database, it’s queryable. This is key for asking questions like, “how many packages are affected by this vulnerability?” We can also look at changes to your code over time. This is a great piece of information to feed into your burn-down charts because it shows how you are making progress towards your goals.

In addition to ADG relationships, another part of our “secret sauce” is doing both static and dynamic analysis of code. This is where things can get a little tenuous, but it boils down to trust. Our approach to trust is personal in that we look at how our systems work and ask the questions, “Would I trust this with my own code?” and if the answer is anything but a resounding “yes” then we ask the logical follow-on question: “How can I make this so I would trust it?” This is why when you run Surveyor, you are encouraged to run it in a Docker container without network connections. All the input and output is contained. The output, completely divorced from your code, is securely uploaded using your Spice Pass. We can do no further analysis without your say-so. Since our revenue model, Service + Secret Sauce, needs trust to function well, it behooves us to not only build that trust, but to maintain it as well. Having static analysis, dynamic analysis and ADG relationships lets you do integration across the datasets.

As I mentioned in the introduction, revenue models are a choice, and barring outside influences like government regulation, it is a choice that can always be revisited and revised. In revising the revenue model, you should always try to analyze the possible and probable outcomes of the changes. As a rule, changes to your revenue model should be delightful instead of bait-and-switch. Obviously, these are polar opposites and the types of changes don’t have to be one or the other. In an ideal world, changes in your revenue models will lead to fairness: quality software that does what it says on the box at a price that makes sense. I like the model that we’ve chosen at Spice Labs. It reflects our culture of trust and openness to the greatest degree possible without giving away the entire farm.