Hacker News Reader

Thanks for the detailed answer! I'm glad to hear that some thought has gone into this. For a direct comaprison of SourceHut's financial model with GitLab, see:

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 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.

> But our customers told us that it was hard to justify paying for open source code, they got lots of questions from their managers

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.

I can tell you from the point of view of a very large corporation who uses Gitlab internally. I think it's a good model.

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 believe that most companies charging only for support are tempted to make the product harder to use to increase the need for support."

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.

Thanks for the comment. Its always cool to see gitlab comments sharing insights that would be hidden by other companies.

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.

Thanks for asking. Right now we have one label accepting merge requests and then labels by tier. Does it work to filter on two labels? Or are we not consistent in labeling the tier? Another option would be to have an accepting merge request label per tier. But this might cause other problems, such as getting out of date when we change the tier before the feature is made.

I just had a look through some of the recent issues with the accepting merge request label and most of them refer to enterprise edition issues but only a small number have the label "enterprise edition". Many of them have other tags like "Category:Epics" but there seem to be a very large number of these EE edition labels making it not simple to just filter out enterprise edition features.

Thanks for pointing that out. I've also seen missing "enterprise edition" labels in some MRs and can make a request to GitLab team members not to forget about the enterprise label.

BTW: While this features get moved to the Open Source version, will they be made available to lower subscription tiers?

If people submit the code to do this I'm supportive. Feel free to ping me on Twitter when you have the code.

This answer has soo much value in it, thanks for sharing this.