Hacker News Reader

Comment by sytse | Hacker News Reader

There are different types of features you can monetize with open core. The article talks about monetizing features that allow you to run it as a SaaS and the problems with that. At GitLab we opted to make those open: "The open source codebase will have all the features that are essential to running a large 'forge' with public and private repositories" https://about.gitlab.com/company/stewardship/#promises Instead we monetize features that managers and executives care more about https://about.gitlab.com/company/pricing/#buyer-based-open-c... This prevents the perverse incentives mentioned in the article.

View on HN

There a lots of features in gitlab that are closed source that I, as small, one man shop, would like to have. I do think gitlab does a much better job of balancing proprietary versus open source features than most open core products, but the incentive still seems to be there to keep useful features back.

One example is global cross-repo search. When looking for substrings on KDE or GNOME's Gitlab, I often want to use the global search bar, but there is no free full-text search across all repositories hosted there, and I have to rely on code search tools external from the code hosting site's UI, like KDE's https://lxr.kde.org/.

GitLab team member here.

You can make suggestions to move features between tiers, i.e. moving a paid feature to the free tier, by opening an issue following https://about.gitlab.com/company/pricing/#changing-tiers-and...

While I appreciate one can do this, it doesn't mean it will happen, and doesn't really answer the OPs question head on.

Which is, does GitLab intentionally evaluate certain features to be behind the paywall to boost sales?

Why wouldn't they? I guess I don't see why the question needs to be asked. There are more interesting questions to be asked about how GitLab makes such decisions.

If there's a feature that is mostly only valuable to pointy-haired bosses, then of course there will be people who want that feature to be available for free. But such a feature should be behind the paywall. It will end up funding features outside of the paywall, so the free users have a reason to be happy about it being behind the paywall.

Of course there will be lots of things in the middle, and people will disagree on every aspect of the evaluation. And people will argue that something should be free because it's good for the community when in fact they want it to be free because they don't want to pay for it. Such is the nature of the balancing act that GitLab signed up for, and I respect them for it.

It's a relatively new spin on the ancient balancing act of value creation vs value capture. TANSTAAFL

I think we're coming at it the same way, but I'm being more terse in my question line.

I am interested in how they arrive in those decisions and do revenue generation features / fixes get weighted differently than non, or are those types of tasks separate from their revenue potential or retention?

I think I'm just leaning on the OP for this context, but I should have added it.

The problem is, some think that these (and other) approaches are killing open source.

> If we normalize projects baiting developers with an open source license to gain traction and switching to a non-open source license to monopolize the returns on that traction, then the logical next step for investors will be skipping that first step entirely.

> And that, for the industry, is nothing but a dead end.

- redmonk.com/sogrady, https://archive.is/GN2Bd

You can absolutely use GitLab to the highest levels of productivity and effectiveness without paying a cent. It just tends to require more input and effort and results in tool sprawl if you want to recreate the GitLab EE experience for free. It's possible for many of the important features, and where it's not possible, it's usually not critical.

GitLab is, imo, one of the best examples of how to do paid open source. Especially because they've gone about it without the relicensing switch that many companies have attempted in order to "protect their business/product."

> If we normalize projects baiting developers with an open source license to gain traction […], then the logical next step for investors will be skipping that [bait] step entirely.

But where would traction come from, then? Switching to a proprietary license works well because they're baiting devs, if investors skip that step there's not as much to monopolise. Or am I misreading that paragraph?

Are you then incentivized to work on managerial features rather than core product features? The disincentive comes from the fact that profits aren’t tied to the quality of the product.

Reply on news.ycombinator.com