7 ms·

If someone forks CE and adds features missing in CE but present in EE, will GitLab accuse them of looking at the EE code and violating the license? Will that ac

by bau5 11y ago

If someone forks CE and adds features missing in CE but present in EE, will GitLab accuse them of looking at the EE code and violating the license? Will that accusation stick? It will be interesting to see. BTW I hate the open core model. http://en.wikipedia.org/wiki/Open_core http://en.wikipedia.org/wiki/Open_core

sytse 11y ago
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.
- akerl_ 11y ago
  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
  - sytse 11y ago
    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.
    - geofft 11y ago
      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.
      - sytse 11y ago
        Thanks Geoffrey, I appreciate the kind words.
    - Sephr 11y ago
      > 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?
      - sytse 11y ago
        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/796455 http://feedback.gitlab.com/forums/176466-general/status/7964... By the way, some people in the core team https://about.gitlab.com/core-team/ https://about.gitlab.com/core-team/ do not work for GitLab the company.
        bau5 11y ago
        > By the way, some people in the core team https://about.gitlab.com/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.
  - bau5 11y ago
    > 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.
    - sytse 11y ago
      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.
      - bau5 11y ago
        Note what Sephr said. The open source product is limited by the proprietary product's business model.
        sytse 11y ago
        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.

by bau5 11y ago

sytse 11y ago

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.

akerl_ 11y ago
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
- sytse 11y ago
  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.
  - geofft 11y ago
    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.
    - sytse 11y ago
      Thanks Geoffrey, I appreciate the kind words.
  - Sephr 11y ago
    > 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?
    - sytse 11y ago
      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/796455 http://feedback.gitlab.com/forums/176466-general/status/7964... By the way, some people in the core team https://about.gitlab.com/core-team/ https://about.gitlab.com/core-team/ do not work for GitLab the company.
      - bau5 11y ago
        > By the way, some people in the core team https://about.gitlab.com/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.
- bau5 11y ago
  > 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.
  - sytse 11y ago
    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.
    - bau5 11y ago
      Note what Sephr said. The open source product is limited by the proprietary product's business model.
      - sytse 11y ago
        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.