4 ms·

Gitlab looks more and more like SAP these days. That's not necessarily a bad thing, enterprises out there choose all-in-one solutions because they need tech tha

Gitlab looks more and more like SAP these days. That's not necessarily a bad thing, enterprises out there choose all-in-one solutions because they need tech that covers the most ground with the easiest budget allocation, POC efforts from internal buyers and streamlined consulting at the post-sale effort. But once in, Gitlab, differently from SAP or Salesforce, is customized from around instead of from within. Meaning, it's not a platform for DevOps, just a bunch of moving parts that you need to tie together. This leads to very fragmented installations, with CI/CD running partially from within repos (gitlab.yml), containers, runner environments, scripts and other dangling cables. I've seen more than one company build their own, horrid adhoc internal DevOps apps with extraneous UIs to help devs navigate different Gitlab CI/CD configurations. That's where Gitlab should be putting their efforts, in building a solid platform for dev and ops taking code to production instead of acquiring middle-of-the-road in-between tech like Peach Tech and Fuzzit, that add complexity to the core offering without checking many boxes for the clients seriously on the lookout for app/api testing. Focus on the platform, enabling integrated customization and implementation robustness while orchestrating the outside moving parts and a great plugin ecosystem. Then get that certification program going strong. Right now your competitor Github "are belong to" Microsoft, and MS, better or worse, sure can do the platform thing for the many sizes of businesses where the meat of your revenue is truly coming from.

factorialboy 6y ago
It might be a fallacy to compare GitLab with Salesforce or SAP. The user base is so different. Developers / engineers are a unique class of users who have high expectations but in their own distinct way. However GitLab's overall strategy and roadmap is being validated by every step GitHub takes off late. Quite an amazing reversal of roles. Back in the day, GitLab was the "open source copy" of GitHub. Now GitHub is following GitLab's footsteps with their Actions (pipelines) offering, and everything that comes with that (code analyzers, security, deployments etc.) GitHub still has much catching up to do though in some areas. Long term, competition is good for everyone. (Disclaimer: GitLab employee)
teruakohatu 6y ago
> Gitlab looks more and more like SAP these days. That's not necessarily a bad thing Unless you are talking about revenue or profit, then I don't think could you could give a worse insult > they need tech that covers the most ground with the easiest budget allocation I think this is the sales pitch of every software product. SAP does not come cheap, in terms of both software and the total cost of moving to SAP. Two classic examples of Lidl pouring 500 Euros into SAP and then walking away and Nike pouring $400 million into a SAP project that was such a disaster they lost $100 million in sales.
- ojosilva 6y ago
  Look, you're right, it wasn't meant as an insult but does sound like one since people perceive SAP as a mostly a bad thing even though it's a wildly successful company that has been solving serious ERP problems for 1000s of clients worldwide. I've actually met more people that say "thank god we finally got SAP in here" than people who not. It doesn't mean it's not a dreaded beast, but, think about it, it actually does do a thing or two for a lot of people. But, OTOH, this is what Gitlab pitches at their website: "A complete toolchain in one application". And "end-to-end platform", and, yes, "thousands of features" (it's literally on their front-page like it's a good thing!). > I think this is the sales pitch of every software product. Like SAP, but obviously on a different scale, Gitlab has invested heavy money in Gartner and Forrester analysts. And I've counted at least 40 logos they claim to replace in their huge feature tables. Only SAP/Salesforce-muscle apps typically claim ample and ambitious replacement targets, which are meant to mean "more bang for the buck" but typically mean "less bang and more buck". This heavy display of self-confidence is unprecedented in the DevOps space, where no single app is pitching to replace so many tools given the heterogeneous nature of dev and ops environments. So, I mean, this is very, very cocky marketing on their part, so maybe they do deserve to be called an SAP as in "SAP-the-big-bad-thing" adjective. So yes, they do look more and more like the SAP-equivalent in DevOps. Gitlab is NOT an ERP, so the size of implementations are in very different scales and orders of magnitude. However Gitlab is more of an enterprise software company than a cloud one and they probably have very high-growth targets as they have raised some serious money from serious investors, which means they probably need to follow a similar path to other platformy enterprise sw behemoths if they are true to the marketing on their front page.
orf 6y ago
I’m a Gitlab fanboy, but you’re right. We run a medium sized Gitlab instance and wanted to automate a bunch of tasks on it - like you should as a good adherent to DevOps principals. But Gitlab is actively hostile to you building automations on top of it. Every access token is tied to a Gitlab User and every user is charged X$ a month, regardless of if it’s a bot or not. So the end result of this is a single bot user with poorly scoped permissions that can only be configured by an administrator. Great. They are slowly moving forward with this epic[1] but the discussions around pricing are ridiculous. Don’t you _want_ people to build automations around Gitlab, as it makes it more entrenched in your org. Stop making it harder by effectively charging hundreds of dollars a year per bot user. Would love any comments you have on that @syste. 1. https://gitlab.com/groups/gitlab-org/-/epics/3559 https://gitlab.com/groups/gitlab-org/-/epics/3559
- rifelpet 6y ago
  They're addressing the lack of service accounts, targeted for 13.1: https://gitlab.com/gitlab-org/gitlab/-/issues/6883 https://gitlab.com/gitlab-org/gitlab/-/issues/6883
  - sytse 6y ago
    Yep, we want to charge only for people, not bots. Sorry it took a while to resolve this, it was complex.
    - orf 6y ago
      I’m really glad you’ve reached this decision, but I’m still not happy with being asked “why are these automation tasks costing us $XXX” per year during our last recent license license update. Until this epic is completed you are charging people full-seat price for automation users which, because of the poorly-scoped token permissions, require multiple “user” accounts to implement securely. An automation utility in no way delivers the same value as a full time developer and it really shook me to know that this is how you have historically valued bots. It runs counter to everything that you publicise.
brmgb 6y ago
> That's where Gitlab should be putting their efforts, in building a solid platform for dev and ops taking code to production instead of acquiring middle-of-the-road in-between tech like Peach Tech and Fuzzit, that add complexity to the core offering without checking many boxes for the clients seriously on the lookout for app/api testing. I will posit that Gitlab knows their own strategy better than you and that they don't acquire companies randomly. They didn't get where they are by randomly throwing darts at the board. It's not an either/or situation anyway. They most likely already have ressources allocated to the app/api testing part of their business. That's an avenue they have been pursuing for a long time. They must have a fairly solid idea of what their growth potential is there.
majkinetor 6y ago
You nailed it. I am personally guilty of creating all kinds of helper tools over GitLab CI/CD madness. This is exactly what is the problem with GitLab - too many features and high complexity and on the other hand, missing some fairly basic and important stuff. And then there is that kubernates fetish... :S I wonder every several weeks what is keeping me on it - is it just sunken cost of my team or there is something more...
- sytse 6y ago
  What are the top 3 basic and important things that GitLab could add?
  - majkinetor 6y ago
    1. running CI locally 2. issue relations in core 3. getting a repository file via curl easily (yeah, seriously)
    - mokha 6y ago
      1. It does take some effort to get the gitlab-runner to run locally but it is possible to use the shell runner. This does require that you connect the gitlab-runner to an instance of GitLab. If I understand correctly, I think you're asking for the ability to take a `.gitlab-ci.yml` file and run the job(s) locally from your shell without requiring it go through the gitlab-runner and connecting to a GitLab instance. Please correct me if I'm off. 2. I'm not sure I understand what this means. 3. I think this is already possible. E.g. `curl https://gitlab.com/gitlab-org/security-products/license-management/-/raw/master/LICENSE` https://gitlab.com/gitlab-org/security-products/license-mana.... Can you elaborate with a few more details on this?
      - majkinetor 6y ago
        1. a lot of effort and I never want to repeat that, ever 2. issue relations is when you connect issues to other issues (for example, Redmine has both sub-issues and related issues) 3. Can you try that when repo is authorized and let me know how it went ?
sytse 6y ago
Thanks for your thoughtful comment. “building a solid platform for dev and ops taking code to production” => great, that is a big focus for us! We already have invested a lot to make this easier, including environments, feature flags, and more. Our direction is on https://about.gitlab.com/direction/ops/#release https://about.gitlab.com/direction/ops/#release What is the top feature you would like to see?
- ojosilva 6y ago
  Hi Sid, there are 2 users already making their points on this thread on the precise core issue I've raised: they have to automate around Gitlab instead of from within. This is what real platforms are about, they give users the tools to customize and make the platform behave the way their org needs it. The great late Robert Stroud, ex Forrester analyst, was very adamant on how a DevOps platform should focus on weaving the so-called value chain, not replacing it.
mokha 6y ago
> That's where Gitlab should be putting their efforts, in building a solid platform for dev and ops taking code to production instead of acquiring middle-of-the-road in-between tech like Peach Tech and Fuzzit, that add complexity to the core offering without checking many boxes for the clients seriously on the lookout for app/api testing. IMO acquiring a small business does not shift focus away from other parts of the product. Peach Tech and Fuzzit now have the support of the rest of GitLab and that benefits everyone. I don't know the headcount of the two companies that were acquired but I would think this would be equivalent to spinning off a small team to focus on an area (fuzzing) that could add value to the greater software community. The idea that these companies were acquired to check a checkbox is disrespectful to the work that they were doing before the acquisition. When GitLab decided to give the `.gitlab-ci.yml` a try it was a risk. It seems to have paid off because others started to copy them. Introducing fuzzing to be part of the devops life cycle could be thought of the same way. > Focus on the platform, enabling integrated customization and implementation robustness while orchestrating the outside moving parts and a great plugin ecosystem. Then get that certification program going strong. Right now your competitor Github "are belong to" Microsoft, and MS, better or worse, sure can do the platform thing for the many sizes of businesses where the meat of your revenue is truly coming from. It sounds like you have some amazing ideas. Contribute them https://gitlab.com/gitlab-org/gitlab/-/issues/new https://gitlab.com/gitlab-org/gitlab/-/issues/new. The issue tracker isn't the equivalent of `/dev/null`. Community contribution is the core of GitLab. Everyone can contribute. GitHub might host a lot of open source but GitLab is open source.

factorialboy 6y ago

It might be a fallacy to compare GitLab with Salesforce or SAP. The user base is so different. Developers / engineers are a unique class of users who have high expectations but in their own distinct way. However GitLab's overall strategy and roadmap is being validated by every step GitHub takes off late. Quite an amazing reversal of roles. Back in the day, GitLab was the "open source copy" of GitHub. Now GitHub is following GitLab's footsteps with their Actions (pipelines) offering, and everything that comes with that (code analyzers, security, deployments etc.) GitHub still has much catching up to do though in some areas. Long term, competition is good for everyone. (Disclaimer: GitLab employee)

teruakohatu 6y ago

> Gitlab looks more and more like SAP these days. That's not necessarily a bad thing Unless you are talking about revenue or profit, then I don't think could you could give a worse insult > they need tech that covers the most ground with the easiest budget allocation I think this is the sales pitch of every software product. SAP does not come cheap, in terms of both software and the total cost of moving to SAP. Two classic examples of Lidl pouring 500 Euros into SAP and then walking away and Nike pouring $400 million into a SAP project that was such a disaster they lost $100 million in sales.

ojosilva 6y ago
Look, you're right, it wasn't meant as an insult but does sound like one since people perceive SAP as a mostly a bad thing even though it's a wildly successful company that has been solving serious ERP problems for 1000s of clients worldwide. I've actually met more people that say "thank god we finally got SAP in here" than people who not. It doesn't mean it's not a dreaded beast, but, think about it, it actually does do a thing or two for a lot of people. But, OTOH, this is what Gitlab pitches at their website: "A complete toolchain in one application". And "end-to-end platform", and, yes, "thousands of features" (it's literally on their front-page like it's a good thing!). > I think this is the sales pitch of every software product. Like SAP, but obviously on a different scale, Gitlab has invested heavy money in Gartner and Forrester analysts. And I've counted at least 40 logos they claim to replace in their huge feature tables. Only SAP/Salesforce-muscle apps typically claim ample and ambitious replacement targets, which are meant to mean "more bang for the buck" but typically mean "less bang and more buck". This heavy display of self-confidence is unprecedented in the DevOps space, where no single app is pitching to replace so many tools given the heterogeneous nature of dev and ops environments. So, I mean, this is very, very cocky marketing on their part, so maybe they do deserve to be called an SAP as in "SAP-the-big-bad-thing" adjective. So yes, they do look more and more like the SAP-equivalent in DevOps. Gitlab is NOT an ERP, so the size of implementations are in very different scales and orders of magnitude. However Gitlab is more of an enterprise software company than a cloud one and they probably have very high-growth targets as they have raised some serious money from serious investors, which means they probably need to follow a similar path to other platformy enterprise sw behemoths if they are true to the marketing on their front page.

orf 6y ago

I’m a Gitlab fanboy, but you’re right. We run a medium sized Gitlab instance and wanted to automate a bunch of tasks on it - like you should as a good adherent to DevOps principals. But Gitlab is actively hostile to you building automations on top of it. Every access token is tied to a Gitlab User and every user is charged X$ a month, regardless of if it’s a bot or not. So the end result of this is a single bot user with poorly scoped permissions that can only be configured by an administrator. Great. They are slowly moving forward with this epic[1] but the discussions around pricing are ridiculous. Don’t you _want_ people to build automations around Gitlab, as it makes it more entrenched in your org. Stop making it harder by effectively charging hundreds of dollars a year per bot user. Would love any comments you have on that @syste. 1. https://gitlab.com/groups/gitlab-org/-/epics/3559 https://gitlab.com/groups/gitlab-org/-/epics/3559

rifelpet 6y ago
They're addressing the lack of service accounts, targeted for 13.1: https://gitlab.com/gitlab-org/gitlab/-/issues/6883 https://gitlab.com/gitlab-org/gitlab/-/issues/6883
- sytse 6y ago
  Yep, we want to charge only for people, not bots. Sorry it took a while to resolve this, it was complex.
  - orf 6y ago
    I’m really glad you’ve reached this decision, but I’m still not happy with being asked “why are these automation tasks costing us $XXX” per year during our last recent license license update. Until this epic is completed you are charging people full-seat price for automation users which, because of the poorly-scoped token permissions, require multiple “user” accounts to implement securely. An automation utility in no way delivers the same value as a full time developer and it really shook me to know that this is how you have historically valued bots. It runs counter to everything that you publicise.

brmgb 6y ago

majkinetor 6y ago

You nailed it. I am personally guilty of creating all kinds of helper tools over GitLab CI/CD madness. This is exactly what is the problem with GitLab - too many features and high complexity and on the other hand, missing some fairly basic and important stuff. And then there is that kubernates fetish... :S I wonder every several weeks what is keeping me on it - is it just sunken cost of my team or there is something more...

sytse 6y ago
What are the top 3 basic and important things that GitLab could add?
- majkinetor 6y ago
  1. running CI locally 2. issue relations in core 3. getting a repository file via curl easily (yeah, seriously)
  - mokha 6y ago
    1. It does take some effort to get the gitlab-runner to run locally but it is possible to use the shell runner. This does require that you connect the gitlab-runner to an instance of GitLab. If I understand correctly, I think you're asking for the ability to take a `.gitlab-ci.yml` file and run the job(s) locally from your shell without requiring it go through the gitlab-runner and connecting to a GitLab instance. Please correct me if I'm off. 2. I'm not sure I understand what this means. 3. I think this is already possible. E.g. `curl https://gitlab.com/gitlab-org/security-products/license-management/-/raw/master/LICENSE` https://gitlab.com/gitlab-org/security-products/license-mana.... Can you elaborate with a few more details on this?
    - majkinetor 6y ago
      1. a lot of effort and I never want to repeat that, ever 2. issue relations is when you connect issues to other issues (for example, Redmine has both sub-issues and related issues) 3. Can you try that when repo is authorized and let me know how it went ?

sytse 6y ago

Thanks for your thoughtful comment. “building a solid platform for dev and ops taking code to production” => great, that is a big focus for us! We already have invested a lot to make this easier, including environments, feature flags, and more. Our direction is on https://about.gitlab.com/direction/ops/#release https://about.gitlab.com/direction/ops/#release What is the top feature you would like to see?

ojosilva 6y ago
Hi Sid, there are 2 users already making their points on this thread on the precise core issue I've raised: they have to automate around Gitlab instead of from within. This is what real platforms are about, they give users the tools to customize and make the platform behave the way their org needs it. The great late Robert Stroud, ex Forrester analyst, was very adamant on how a DevOps platform should focus on weaving the so-called value chain, not replacing it.

mokha 6y ago

> That's where Gitlab should be putting their efforts, in building a solid platform for dev and ops taking code to production instead of acquiring middle-of-the-road in-between tech like Peach Tech and Fuzzit, that add complexity to the core offering without checking many boxes for the clients seriously on the lookout for app/api testing. IMO acquiring a small business does not shift focus away from other parts of the product. Peach Tech and Fuzzit now have the support of the rest of GitLab and that benefits everyone. I don't know the headcount of the two companies that were acquired but I would think this would be equivalent to spinning off a small team to focus on an area (fuzzing) that could add value to the greater software community. The idea that these companies were acquired to check a checkbox is disrespectful to the work that they were doing before the acquisition. When GitLab decided to give the `.gitlab-ci.yml` a try it was a risk. It seems to have paid off because others started to copy them. Introducing fuzzing to be part of the devops life cycle could be thought of the same way. > Focus on the platform, enabling integrated customization and implementation robustness while orchestrating the outside moving parts and a great plugin ecosystem. Then get that certification program going strong. Right now your competitor Github "are belong to" Microsoft, and MS, better or worse, sure can do the platform thing for the many sizes of businesses where the meat of your revenue is truly coming from. It sounds like you have some amazing ideas. Contribute them https://gitlab.com/gitlab-org/gitlab/-/issues/new https://gitlab.com/gitlab-org/gitlab/-/issues/new. The issue tracker isn't the equivalent of `/dev/null`. Community contribution is the core of GitLab. Everyone can contribute. GitHub might host a lot of open source but GitLab is open source.