Yes, we actually started by making making Enterprise Edition actually open source. When we announced there would be a proprietary part of GitLab people mentioned that Wordpress plugins where able to make it work with an open source license. It was a comment on https://about.gitlab.com/releases/2013/08/22/introducing-git... but the comments there seem to have disappeared. So instead of making it proprietary we licensed it with an open source license but without offering a download, you had to pay to get access to the source code (this is similar to the Wordpress plugins and also not unlike Red Hat Enterprise Linux updates).
We were afraid that people would put up a mirror with the paid code, this didn't happen. But our customers told us that it was hard to justify paying for open source code, they got lots of questions from their managers. So we switched to making the additional features proprietary.
We tried charging for support but it is hard to make enough margin to be able to invest in the things we wanted (scalability, security, library upgrades, easy of use, etc.). People tended to cancel after they didn't use support for a year. I believe that most companies charging only for support are tempted to make the product harder to use to increase the need for support. More about the business models we tried can be found on https://about.gitlab.com/blog/2018/11/09/monetizing-and-bein...
https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/
Though it's definitely easier to go with the GitLab approach to monetization, I pointed out a lot of problems that these incentives set up. I'm not sure how you're going to avoid some of these problems. That being said, I imagine that it would be extremely difficult GitLab to change course so sharply at this point in its life.
To be clear, I recognize that GitLab EE, as a source-available distribution, is a measurable improvement over GitLab's closed-source offerings. I think GitLab is a valuable tool and an ecosystem without it is poorer than an ecosystem with (though, an ecosystem without SourceForge would be nice...). I hope that you guys are able to balance your incentives and stick around to provide a good service to the community, and I hope you keep it up with merging EE features into CE.
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.
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".
This is, unfortunately, a real problem. I've worked in huge companies that will happily shell out hundreds of thousands for Atlassian crap, but if you were to suggest paying less for a better product that could be got for free you'd be laughed out of the room. What's more likely is the fact that it's free would be used as its main selling point.
Free Gitlab got our bosses attention. Once they saw the value it added to the org. our managers started bringing up the Enterprise license. Not us techs, we were fine with the free version.
I agree with this. Many advocates of open source software continue to push the paid support option as a viable route for open source developers. But often the suggestion is made without thinking through the implications of such a proposal. And the idea of deliberately making a product complex or poorly documented in order to encourage paid support is inherently unattractive to any customer.
For solo developers or small developer teams, I can't think of anything less appealing that having to focus on paid support as the benchmark for financial success for their business.
A paid 'source available' option is one way to charge for the actual product and give your customers access to your source code (which can include provisions to modify the source code). This model may not be popular with open source advocates, but it provides a way for the developers to keep their focus on the product and on making it as easy as possible to use.
In fact this model isn't new. There is a long history of developer tools sold, not as open source, but with the source code available for modification and incorporation in to other products.
Off topic but while you are here I was wondering if gitlab would consider having the bot that tags issues as open for community contributors not tag issues on enterprise edition features since community members are unable to develop on these and it makes it hard to find issues that are actually open for the community to contribute to.