5 ms·

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 GitLa

by lxn 6y 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 6y 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 6y 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 6y 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 6y 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 6y 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 6y 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 6y ago
    The alternative is GitLab not being able to hire developers to actually build GitLab since the "kindly ask to please pay"-model doesn't really work very well. "The community" is often vastly overrated anyway IMHO. Patches are always good, of course, but people who actually consistently invest time in a project are exceedingly rare. You can't build a product based on sporadic patches. Besides, a lot of the time "the community" is just users (people with no contributions) complaining you're not doing stuff right. Unless you have a viable (preferable proven) model that allows GitLab to hire developers and keep everything 100% open source, it seems to me this is the best and most balanced option. To the best of my knowledge, such a model doesn't really exist. I continue to be surprised at the hesitancy (or even outright hostility) whenever someone tries to make an economically viable open source product, which usually involves things not being 100% open source because turns out, that's the only way to make things viable. "90% open source" is a hell of a lot better than 0% open source in my book.
    - cycloptic 6y ago
      The oldest viable and proven business model where you can keep 100% open source, is to sell support contracts and warranties. This model is harder for your average SaaS company to pull off but provides much better ROI if you can actually do it.
      - Carpetsmoker 6y ago
        It only works well if you have a decent amount of large enterprise customers (like RedHat); I don't think it will work out well for GitLab, which is mostly aimed at small-to-medium businesses. I don't think it's viable for most projects (otherwise they would be using it). Even if it is viable, you're usually leaving a lot of money on the table, and even Red Hat – the poster child of this model – does stuff like releasing updates to paying customers first.
        cycloptic 6y ago
        You are always leaving money on the table. The choice of business model is only a decision of whose table you are going to leave it on. The downsides of the open core model have already been mentioned here. I am not suggesting that GitLab change their business model, I don't have any opinion about what they should do. But I will say that releasing updates to paying customers first is still consistent with being 100% open source, as long as those updates are still released to them under an open source license.
  - nhumrich 6y ago
    Open source projects get all "paid" features for free.
    - chabad360 6y ago
      That's for gitlab.com, not GitLab CE.
      - mroche 6y ago
        Gold (GL hosted) and Ultimate (self hosted) are available to educational institutions and open source projects. Check the pricing FAQ’s. This has been a thing since Microsoft acquired GitHub. https://about.gitlab.com/blog/2018/06/05/gitlab-ultimate-and-gold-free-for-education-and-open-source/ https://about.gitlab.com/blog/2018/06/05/gitlab-ultimate-and...
spankalee 6y 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 6y 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 6y 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 6y 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 6y ago
    >reaction of :+1: is usually sufficient If I remember correctly, you don't actually get notified of any +1 reaction.
thayne 6y 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.

by lxn 6y ago

Carpetsmoker 6y 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 6y 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 6y 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 6y 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 6y 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 6y 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 6y ago
  The alternative is GitLab not being able to hire developers to actually build GitLab since the "kindly ask to please pay"-model doesn't really work very well. "The community" is often vastly overrated anyway IMHO. Patches are always good, of course, but people who actually consistently invest time in a project are exceedingly rare. You can't build a product based on sporadic patches. Besides, a lot of the time "the community" is just users (people with no contributions) complaining you're not doing stuff right. Unless you have a viable (preferable proven) model that allows GitLab to hire developers and keep everything 100% open source, it seems to me this is the best and most balanced option. To the best of my knowledge, such a model doesn't really exist. I continue to be surprised at the hesitancy (or even outright hostility) whenever someone tries to make an economically viable open source product, which usually involves things not being 100% open source because turns out, that's the only way to make things viable. "90% open source" is a hell of a lot better than 0% open source in my book.
  - cycloptic 6y ago
    The oldest viable and proven business model where you can keep 100% open source, is to sell support contracts and warranties. This model is harder for your average SaaS company to pull off but provides much better ROI if you can actually do it.
    - Carpetsmoker 6y ago
      It only works well if you have a decent amount of large enterprise customers (like RedHat); I don't think it will work out well for GitLab, which is mostly aimed at small-to-medium businesses. I don't think it's viable for most projects (otherwise they would be using it). Even if it is viable, you're usually leaving a lot of money on the table, and even Red Hat – the poster child of this model – does stuff like releasing updates to paying customers first.
      - cycloptic 6y ago
        You are always leaving money on the table. The choice of business model is only a decision of whose table you are going to leave it on. The downsides of the open core model have already been mentioned here. I am not suggesting that GitLab change their business model, I don't have any opinion about what they should do. But I will say that releasing updates to paying customers first is still consistent with being 100% open source, as long as those updates are still released to them under an open source license.
- nhumrich 6y ago
  Open source projects get all "paid" features for free.
  - chabad360 6y ago
    That's for gitlab.com, not GitLab CE.
    - mroche 6y ago
      Gold (GL hosted) and Ultimate (self hosted) are available to educational institutions and open source projects. Check the pricing FAQ’s. This has been a thing since Microsoft acquired GitHub. https://about.gitlab.com/blog/2018/06/05/gitlab-ultimate-and-gold-free-for-education-and-open-source/ https://about.gitlab.com/blog/2018/06/05/gitlab-ultimate-and...

spankalee 6y 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 6y 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 6y 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 6y 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 6y ago
  >reaction of :+1: is usually sufficient If I remember correctly, you don't actually get notified of any +1 reaction.

thayne 6y 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.