Hacker News Reader

Comment by sytse | Hacker News Reader

Open core is a double edge sword, but we try to enlarge the advantages (resources to do release management, fix bugs, upgrade dependencies, investigate security reports) and minimize the downsides (no artificial limits in CE, no crippleware).

Looking at the EE code is fine but you can't use the code. So merge requests that add EE code into CE will not be accepted.

View on HN

The point being made above seems to be "Releasing the source for EE poisons dev efforts", because if I fork CE and add code that does something EE adds, GitLab might claim that I "stole" code from EE, or looked at EE and was tainted with knowledge from EE code.

Even if I hadn't copied code from EE, the claim could be made and would be destructive to the ability of community members to fork and improve the open source codebase

I expect that in most cases we'll be able to tell from the code. In cases where we can't tell we assume that people made it themselves. We are releasing the code to make EE easier to work with (having private repos and docker images is hard). We did not want to make it harder to contribute EE features to CE. If people are worried about poisoning please let me know. Merging EE functions into CE has always been at the discretion of the core team, we don't need any excuses.

That is super cool. Thank you for demonstrating that it's possible to be a CEO of a successful, community-friendly proprietary version-control company without turning into Larry McVoy.

Thanks Geoffrey, I appreciate the kind words.

> Merging EE functions into CE has always been at the discretion of the core team

If someone independently implements all of the EE functions without looking at or using the EE code, will the core team reject the patch due to the fact that it would give a reason for customers to stop paying for EE? Is there any scenario where the core team would accept such a patch?

We advise people to submit one function at a time, this speeds up the process and makes it easier to incorporate feedback. If there is a high quality merge request for an EE feature we'll probably merge it. We hope that instead of duplicating work that has been done most people will focus their efforts on the 180 features marked accepting merge requests http://feedback.gitlab.com/forums/176466-general/status/7964... By the way, some people in the core team https://about.gitlab.com/core-team/ do not work for GitLab the company.

> By the way, some people in the core team https://about.gitlab.com/core-team/ do not work for GitLab the company.

And this is why I think that Open Core software unfairly appropriates peoples' work.

Why do you think that? The non GitLab employees in the core team want to see a great and successful open source product and that is what is happening. The code they contribute stays open source. Ask them how they feel about it, I would be surprised if they would feel the company unfairly appropriates their work. Do you think Open Core can work if done right or do you think it always is a bad thing?

> tainted with knowledge from EE code

Yes this is exactly what I was getting at. Thank you for putting it more succinctly.

It's a real downside.

It is a downside but you can avoid it by not looking at the EE code you plan to contribute. Looking at the EE code is optional, it won't be needed to contribute to CE. The GitLab company will solve any merge conflicts that arise.

Note what Sephr said. The open source product is limited by the proprietary product's business model.

I responded to Sephr's comment. We think the open source project is better because of our open core business model. More than 80% of the company development efforts go into open source code. Many people contribute new features, but the work to make installation easy, release management, fixing bugs and performance regressions, investigating security reports and updating dependencies is for the most part done by GitLab the company. I recognize that the open core model requires a careful balance. But I think it is working very well for GitLab and is one of the reasons GitLab became more popular than the 100% open source alternatives.

Reply on news.ycombinator.com