If you had a freemium business model, what feature should be openly sourced? I don’t claim to have the ultimate answer, but here are my thoughts and the heuristic that I came up with.
The open source freemium model
Let us think of a creator of some sort of application that is supposed to be openly sourced. Anyone can look at the code, improve it, build on it. So we have developers that may be attracted. But we also have users who are not interested in the itself code. And, let us be realistic, what most of the users want is to use the software for free. Period.
Now, as open source software grows in size and popularity, the creator will face more and more effort: People demand new features to be developed, other developers may contribute code, but that still needs to be reviewed and handled, infrastructure may need to be paid, etc. I recommend a talk by Dylan Beattie on that subject: “Open Source, Open Mind: The Cost of Free Software”
In a nutshell: The creator decides to apply a freemium business model. The software will remain openly sourced and free to use, but there also is a premium tier with benefits for paying customers. And the code for that premium tier will be closed source. You often see this approach in open-source software-as-a-service settings: You can still get the software including the common code for free and install it on your own infrastructure, or you pay the creator to host things for you and give you some extra benefits. And now things get interesting.
The creator is running a business, so they need to make their product/service attractive enough for people to pay for it. With every new feature that gets prioritized and developed, the creator needs to decide whether the feature is going to become available for anyone or only to paying customers. If everything was free, the business would collapse. If everything was premium, you’d not need to worry about open-sourcing anything to begin with.
Eventually – my ideas
On the one hand, a feature can either cause a low effort to implement (and run) or a high effort for the creator. Even if you don’t know how to code, it’s probably obvious to you that allowing the user to change the color of a button is rather “low effort”, while developing a visual editor for creating the layout of page is “high effort”. On the other hand, from a user’s perspective, a feature can either have “low expendability” if it is really essential to work with the software, or it can have “high expendability” if it is rather a nice-to-have that you could live without easily.
Note that it’s not obvious where low effort ends and where high effort starts. That will depend on the creator and their environment. Likewise, there is no objective boundary between low expendability and high expendability. That will vary from user to user, and that is where creators would perform market research or implement other ways to learn what their user base looks like.
The matrix
With the two dimensions effort and expendability we can draw ourselvses a two-by-two matrix – business administrators love these as tools for thinking or as heuristic support for decisions.
I tried to give a name to each quadrant of the matrix:
- Low effort and low expendability: A basic feature that is simple to implement and does not cause significant operating costs, yet it holds a high value for the users. A good example might by “Copy & Paste” for text. It’s super easy to add that, and I assume you’d hardly want to live without it in your text processor.
- Low effort and high expendability: A common feature that is simple to build, but does not necessarily hold a huge benefit for the user. Allowing to search and replace text with regular expressions may be such a feature. Most users will probably never miss it if it was not available.
- High effort and low expendability: A cornerstone feature that requires to put a lot of effort into making and feels rather essential if you wanted to use the software. In a text processor, this could be WYSIWYG support for adding and modifying images, tables and text boxes to the text. It’s not trivial to add, but most users would not want to live without it. Yes, I am aware that some claim that markdown should be enough for everyone 😉
- High effort and high expendability: A luxury feature that is costly to build, but user could live without even though it would make their lives more comfortable if they had it. For text processor, maybe a feature to analyze the document and add scientific citations with links to sources supporting the claim. Most people could live without. And I’d deem such a feature dangerous, but that’s a whole different story.
So, how does that matrix help?
If can channel our thinking. A creator could decide how to draw the boundaries between the quadrants and then put the feature into a quadrant that fits. And here’s what I’d learn from the quadrants.
A basic feature should be openly sourced. The user experience benefits tremendously and it’s simple to do. The software becomes much better, but it does not take a huge effort to do, so does not cost the creator much. A creator may be in trouble if their software consisted of basic features only, but then it may not be valuable enough to monetize long-term anyway.
In contrast, a luxury feature could remain closed-source. It costs the creator a lot to build and/or run and doesn’t discriminate the vast majority of users. They could live without, their experience is not impacted. But some users will gladly pay for the extra comfort that they can get.
Then we have the common feature. It is not essential for the general user, but it’s also simple to build and run. I’d argue to just open-source it for two reasons. One: It is unlikely that someone will decide to pay for the software just to have that feature. Two: If it does not require a high effort to build it, chances are that some developer will just take the code and add the feature in one way or the other – and the creator would be the bad guy withholding the goodies.
A cornerstone feature is more difficult to judge. It takes a lot of effort to bring it to life. A creator will want to get some return on their high investment. It feels understandable if someone decided to make this a paid premium and closed-source. I’d argue though that there are good arguments to open-source that feature, too. Users may churn if cornerstone functionality is paywalled; they may feel like 2nd class citizens and the creator’s reputation will suffer. Users then become more likely to keep their eyes open for alternatives. Also, adoption of the software may slow down, because a crucial feature is not available (for free). Ultimately, if your business runs on freemium, open-source the thing that wins trust, not the thing that makes money. It’s a marathon.
Please note that I am not judging software or people here if they take different routes than I’d have taken. I may disagree (a lot), but ultimately, I also firmly believe in “People who share their source code do not owe you anything” – again referring you to Dylan Beattie here.
Could you give an example?
Yes, or course. I made one about H5P, of course. And I managed to put that into an H5P exercise.
What are your thoughts?
Please let me know in the comments.