9 ms·

All not very relevant. They keep the core business features (like merge request approval) carefully out of the OSS edition. And they haven't fixed the pricing f

by 2ion 7y ago

All not very relevant. They keep the core business features (like merge request approval) carefully out of the OSS edition. And they haven't fixed the pricing for their premium offering either.

lxn 7y ago
Relevant is subjective. Merge request approval is not something a single contributor needs for example. You can still get it by paying for it. In the end GitLab is a business, someone needs to pay something. As developer who runs a GitLab server for personal projects I don't miss any paid features.
- Carpetsmoker 7y ago
  Rather makes sense, because for many open source projects with a single or handful or contributors it's not a very important feature, but for larger teams (i.e. companies) it is, which ensures they pay their fair share while still keeping the product available for free for most of us.
  - m4rtink 7y ago
    Still, having any features that are propritary and thus off-limits to contributors does not create a good community atmosphere. Say as an example that Debian, which has a big user of GitLab wanted this feature, so the Debian project contributors create all the patches & submit them for inclusion in the open source part of GitLab. Normally, a project would welcome any (presumably) well written patches like this. But with open core project this creates an instant conflict of interest. Either GitLab takes such patches, loosing their proprietary edition exclusive feature & possibly even compatibility with their closed source implementation of it. Or they reject the patches, presumably loosing a lot of goodwill with the community and forcing Debian to maintain those patches for ever in their own fork of GitLab. All in all, I don't see open core companies like something to invest ones contributor time to due to this & more importantly like something to use and make you open source project to depend on.
    - rpaik 7y ago
      Everyone can actually contribute to both GitLab Community and Enterprise Editions. This query will actually show you a partial list of Community Contributions to EE that have already been merged: https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=Community%20contribution&label_name[]=Enterprise%20Edition https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=... The Enterprise Edition is under a different license but the source code is open and available to everyone.
      - cycloptic 7y ago
        Just a request, can you please not say "the source is open" without clarification? That seems to imply it's open source when it actually isn't, and the "different license" is actually a proprietary license. A more accurate way to say it would be "the source code is available to the public, but with some proprietary restrictions" or something like that. Otherwise you will just have to clarify later and you risk leading into nonsensical conversations like "well it's not open source but the source code is open."
        rpaik 7y ago
        You're correct and apologies for the confusion. I didn't mean to imply that EE is open source. It is proprietary and source available. I was actually more concerned about the comment that EE is "off-limits" to contributors and wanted to set the record straight.
        m4rtink 7y ago
        AFAIK many company employees can quite easily contribute to projects under an OSI approved license, while contributing to projects requiring CLA is generally much harder & requires clearing the given CLA with the legal department. And I'm afraid contributing to a "source available" project that is not even open source will be even harder.
    - Carpetsmoker 7y ago
- spankalee 7y ago
  Merge request approval isn't in the open source version? That's a huge missing feature. I don't see how that fits into the pricing scheme outlined in the post either, unless they consider the maintainers of a project to be managers?
  - nhumrich 7y ago
    "approval" isnt really needed at all unless there are compliance requirements. A comment or reaction of :+1: is usually sufficient. Two years ago, github itself didn't even have approvals on pull requests. So yes, I think it aligns well with a feature managers need, not individual contributors.
    - spankalee 7y ago
      +1 is ok, but it's not the same as concrete approval bit. GitHub was late to add it, but that doesn't mean it wasn't a glaringly missing feature from GitHub before then. Other open-source system like Gerrit and Phabricator have had approvals since their inception, I believe. edit, just to say: I really don't get the manager tie in to approvals. I've never worked on a team where approvals were done by managers. It's always other team members, and especially required when you have code owners of different parts of the codebase.
      - nixgeek 7y ago
        Point being made ain’t that managers approve merges, it’s that the feature is generally something you may want to enforce formal peer review once your team grows beyond 5-6 people. In contrast like SAST and DAST is far more common to be a requirement in large enterprises and that’s in the much more expensive tier as a result.
    - Hamuko 7y ago
      >reaction of :+1: is usually sufficient If I remember correctly, you don't actually get notified of any +1 reaction.
- thayne 7y ago
  > Merge request approval is not something a single contributor needs But then, is Gitlab something a single contributor for a private repository anyway? I'm sure there are use cases, but for most individuals working on a private repo, gitlab is probably overkill.
pknopf 7y ago
What? They've been talking about opening that up forever. I can't believe they didn't.
- deleted 7y ago
  [deleted]
CameronNemo 7y ago
Package registry is pretty important for my organization. We need to do builds with jndi and other similar java libraries. We deployed Nexus OSS because we did not want to pay for GitLab Premium.

by 2ion 7y ago

All not very relevant. They keep the core business features (like merge request approval) carefully out of the OSS edition. And they haven't fixed the pricing for their premium offering either.

lxn 7y ago

Relevant is subjective. Merge request approval is not something a single contributor needs for example. You can still get it by paying for it. In the end GitLab is a business, someone needs to pay something. As developer who runs a GitLab server for personal projects I don't miss any paid features.

Carpetsmoker 7y ago
Rather makes sense, because for many open source projects with a single or handful or contributors it's not a very important feature, but for larger teams (i.e. companies) it is, which ensures they pay their fair share while still keeping the product available for free for most of us.
- m4rtink 7y ago
  Still, having any features that are propritary and thus off-limits to contributors does not create a good community atmosphere. Say as an example that Debian, which has a big user of GitLab wanted this feature, so the Debian project contributors create all the patches & submit them for inclusion in the open source part of GitLab. Normally, a project would welcome any (presumably) well written patches like this. But with open core project this creates an instant conflict of interest. Either GitLab takes such patches, loosing their proprietary edition exclusive feature & possibly even compatibility with their closed source implementation of it. Or they reject the patches, presumably loosing a lot of goodwill with the community and forcing Debian to maintain those patches for ever in their own fork of GitLab. All in all, I don't see open core companies like something to invest ones contributor time to due to this & more importantly like something to use and make you open source project to depend on.
  - rpaik 7y ago
    Everyone can actually contribute to both GitLab Community and Enterprise Editions. This query will actually show you a partial list of Community Contributions to EE that have already been merged: https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=Community%20contribution&label_name[]=Enterprise%20Edition https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=... The Enterprise Edition is under a different license but the source code is open and available to everyone.
    - cycloptic 7y ago
      Just a request, can you please not say "the source is open" without clarification? That seems to imply it's open source when it actually isn't, and the "different license" is actually a proprietary license. A more accurate way to say it would be "the source code is available to the public, but with some proprietary restrictions" or something like that. Otherwise you will just have to clarify later and you risk leading into nonsensical conversations like "well it's not open source but the source code is open."
      - rpaik 7y ago
        You're correct and apologies for the confusion. I didn't mean to imply that EE is open source. It is proprietary and source available. I was actually more concerned about the comment that EE is "off-limits" to contributors and wanted to set the record straight.
        m4rtink 7y ago
        AFAIK many company employees can quite easily contribute to projects under an OSI approved license, while contributing to projects requiring CLA is generally much harder & requires clearing the given CLA with the legal department. And I'm afraid contributing to a "source available" project that is not even open source will be even harder.
  - Carpetsmoker 7y ago
spankalee 7y ago
Merge request approval isn't in the open source version? That's a huge missing feature. I don't see how that fits into the pricing scheme outlined in the post either, unless they consider the maintainers of a project to be managers?
- nhumrich 7y ago
  "approval" isnt really needed at all unless there are compliance requirements. A comment or reaction of :+1: is usually sufficient. Two years ago, github itself didn't even have approvals on pull requests. So yes, I think it aligns well with a feature managers need, not individual contributors.
  - spankalee 7y ago
    +1 is ok, but it's not the same as concrete approval bit. GitHub was late to add it, but that doesn't mean it wasn't a glaringly missing feature from GitHub before then. Other open-source system like Gerrit and Phabricator have had approvals since their inception, I believe. edit, just to say: I really don't get the manager tie in to approvals. I've never worked on a team where approvals were done by managers. It's always other team members, and especially required when you have code owners of different parts of the codebase.
    - nixgeek 7y ago
      Point being made ain’t that managers approve merges, it’s that the feature is generally something you may want to enforce formal peer review once your team grows beyond 5-6 people. In contrast like SAST and DAST is far more common to be a requirement in large enterprises and that’s in the much more expensive tier as a result.
  - Hamuko 7y ago
    >reaction of :+1: is usually sufficient If I remember correctly, you don't actually get notified of any +1 reaction.
thayne 7y ago
> Merge request approval is not something a single contributor needs But then, is Gitlab something a single contributor for a private repository anyway? I'm sure there are use cases, but for most individuals working on a private repo, gitlab is probably overkill.

pknopf 7y ago

What? They've been talking about opening that up forever. I can't believe they didn't.

deleted 7y ago
[deleted]

CameronNemo 7y ago

Package registry is pretty important for my organization. We need to do builds with jndi and other similar java libraries. We deployed Nexus OSS because we did not want to pay for GitLab Premium.