I am not sure I had ever read Gitlab's rationale for its business model outlined in this detail anywhere, and I found it fascinatingly similar to our own. I wanted to share that Canonical's 15-year experiment in business models has lead to similar conclusions: if you want to scale, you need to 1) to make it very clear why your customers should pay, and 2)take into account that buyers in general are less sophisticated in their decision making than we would hope for. I think the general move to freemium/open core models is recognition that other models are very high-risk.
I can't tell you how many times I have heard from a suit and tie buyer that they can't justify paying [that much] for open source, and even when you can answer that question in a compelling way, the message is diminished along the way to procurement. And that's erosion of margin.
You're right that there is an inherent conflict in freemium between the free version's feature set and the paid-for version, but that just means you need to weigh your options carefully along the way, and ideally come up with some simple to understand strategies/rules of thumb that your team can use when deciding where the products need to go.
Note also that it's not like other less controversial models aren't without conflicts of their own. For instance, support models set up a conflict with the quality of the product, because high quality, "It Just Works" products don't help users value support highly -- yes, even when the users are Fortune 100s, amazingly. Similarly, SAAS models are naturally incentivized to make the software complex, undocumented, hard to install and challenging to operate, lest the value proposition of the paid offering becomes convenience only, which is very hard to capture margin with for relatively low-volume B2B products.
In the end, I guess I'm saying that Gitlab's approach isn't necessarily easier; it's just much less risky and therefore scales much better.
Yeah, one of the important lessons here is: Buyers just aren't rational. Even multi-billion companies are driven by manager egos and biases and they will make dumb decisions based on prejudices.
Unfortunately, the Oracle/IBM marketing of "Opensource is trash" has proven to be very sticky so selling OSS to Enterprises companies can be a hugely uphill battle when managers think that OSS products are inherently low quality in comparison to highlghy priced "brand name" stuff. Giving them away for free with paid support is very contraproductive when your purchaser has this line of thinking - they just percieve this as "this product is so bad they need to give it away for free".
Note that I explicitly pointed out that you don't have to give it away for free - you can charge people for the source code and use a free/open source software license at the same time. It does prevent you from charging a subscription fee (or at least makes it ineffective), but you can also deny them access to updates unless they pay up. Sure, someone could stick the code online somewhere else, but now customers would have to trust some random third party to forward the legitimate code to them, and this third party has to compete with your established marketing funnel.
I can't tell you how many times I have heard from a suit and tie buyer that they can't justify paying [that much] for open source, and even when you can answer that question in a compelling way, the message is diminished along the way to procurement. And that's erosion of margin.
You're right that there is an inherent conflict in freemium between the free version's feature set and the paid-for version, but that just means you need to weigh your options carefully along the way, and ideally come up with some simple to understand strategies/rules of thumb that your team can use when deciding where the products need to go.
Note also that it's not like other less controversial models aren't without conflicts of their own. For instance, support models set up a conflict with the quality of the product, because high quality, "It Just Works" products don't help users value support highly -- yes, even when the users are Fortune 100s, amazingly. Similarly, SAAS models are naturally incentivized to make the software complex, undocumented, hard to install and challenging to operate, lest the value proposition of the paid offering becomes convenience only, which is very hard to capture margin with for relatively low-volume B2B products.
In the end, I guess I'm saying that Gitlab's approach isn't necessarily easier; it's just much less risky and therefore scales much better.