When you buy a piece of software, you’re buying more than bits and bytes of executable code. Someone in the company had to write the code you’re buying, test it, package it, and—most importantly—maintain it. As you’re using the software, the company from which you bought it is providing support services to its customers, squashing bugs, and working on the next version of the product. All this requires a steady source of income.
Subscription-based software is a monetization scheme which enables software companies to do exactly this. By paying a monthly fee for software, a software company can re-invest the income into the product, and provide more services as a going concern.
Consider the case of Cloudera, a software company providing big data and cloud computing infrastructure to business clients. The vast majority of Cloudera’s products are built under open-source licenses, meaning that after you put down this article, you can go to GitHub, check out their source code, compile it, and Bob’s your uncle! You can run the same graph database that Facebook uses to analyze connections between all its users! But would you really know what to do with it?
This knowledge mismatch powers companies like Cloudera, and provides a solid rationale for subscription-based software. Instead of hiring its own expensive experts, and take on the risk of building and maintaining Cloudera-like products, why not offload the duty to an open-core company? If the customer doesn’t want to use Cloudera’s services later, they are free to keep the product at the end. After all, everything is under an open-source license.
But this creates a severe disincentive for open-core companies to emerge, especially if they demand a lump-sum payment for the product? Why should I pay for something I get for free? Clearly, a subscription system needs to exist for the company to exist.
Subscription-based monetization schemes for software also improve the quality of the product. Again referring to the example of Cloudera, having a steady source of capital allows Cloudera to contribute to the open-source projects for which they provide services, giving back to the open-source software community in a big way. These are the guys squashing bugs, and contributing to new functionality in open-source products. The fact that I can incorporate their work into my code for free doesn’t hurt the company either. Who better to provide maintenance services for Apache Sqoop than the guys who wrote Apache Sqoop?
So subscription-based software monetization schemes are beneficial for enterprise companies, but what about for us consumers who aren’t channeling Moss from the IT Crowd? To discuss the benefits of subscription software, I think it is best to examine one of its biggest success stories, Microsoft Office.
MS Office is not released under an open-source license, but is instead owned by Microsoft. They don’t let mere mortals view, much less modify, the source code of their applications. After all, would you give away your special sauce to the world?
In a lump sum monetization scheme, you would pay for a version of MS Office, install it, and be done with it. If another version came out three years later, you would have to pay again for another “box” (I’m generalizing this term to include digitally-distributed media), and repeat the process. Not only is this inconvenient, but it also creates a problem for Microsoft as they feel greater pressure to be backwards-compatible. By offering MS Office 365 as a subscription-based product, Microsoft gains a steady source of income on the project, and can auto-update consumers to the latest version of MS Office. The suite is easier to justify from a business perspective, keeps its customers in the loop about the latest software changes, and allows customers to spread a $400 lump sum payment for MS Office into annual $100 payments over four years.
You would think that running a closed-source product as a subscription would mean creating dependency on Microsoft, but this is not the case. Since 2007, MS Word, Excel, and Powerpoint have switched to an open file format for writing documents. Unlike the .doc format, which wrote the word doc as a binary file, The new .docx format writes word documents as a zipped archive of XML files that can be inspected in any text editor. Furthermore, parsers for XML are readily available for the vast majority of programming languages, and the open-source community has responded with OpenOffice and LibreOffice in order to read and enable basic editing of XML files. Therefore, the dependency factor has been significantly reduced, and due to the subscription-based model, Microsoft continues to run MS office profitably.
The monetization scheme of a product is as much a design decision as any piece of code in the software. Indeed, the monetization scheme cannot simply factor in the product’s codebase, but must also factor in the support ecosystem, and the customer’s use case for the product. If products like enterprise databases and MS Office are provided as a service, should they not be priced as a service? If a customer is going to be using a piece of software continuously for the next 5 years in their undergraduate career and beyond, is it not time to examine making a longer-term commitment with the software company providing you with the tools to enable productivity? If people are still playing an MMO 11 years after its initial release, does it not make sense to use a subscription-based model to give the developer a steady source of income to provide the consumer with added value? As an engineering student, I am a firm believer in the idea of using the right tool for the right job, and if the use case justifies a subscription-based monetization scheme, why not use it?
Leave a Reply