@diminish - We have some stats related to security scanning which we cover in our security trends report (https://about.gitlab.com/blog/2020/04/02/security-trends-in-...). It is a very interesting read and would like to hear your feedback. We also did a survey of fuzzing usage the highlights are here (https://about.gitlab.com/direction/secure/fuzz-testing/fuzz-...). We are excited about bringing Peach Tech and Fuzzit into GitLab as we are going to be able to address a big pain point for adoption of fuzzing (integration into CI).
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.
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.
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.
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.
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...
3.1. Get a sane link to a build artifact (something like latest `master`). This can be worked around if you just publish them on Gitlab Pages, a nice solution now that they even have authentication.
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-mana.... Can you elaborate with a few more details on this?
1. Yes, I agree. This is something that I personally would like to improved.
2. Oh, I see. I don't have much experience with this one.
3. Got ya. So cURLing a raw file from a private repo. How would you like that to work?
3. I have a link to a file already (in a browser URL bar), let me use it with token or something easy (for example the way most RSS with auth are constructed so that you don't need to set up credentials when 'subscribing') instead of looking for project IDs and constructing path that GitLab can swallow as a query parameter, fighting all kind of nonsence in the process.
FYI, nobody I know did that in a minute (and minute is much for such task) and everybody was like _fuck this shit, I'll just clone entire repo to use a single file_, 15 minutes later.
> 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. 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.
> 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.
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.
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.
> 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.
That's cool, but I wish they'd polish the base experience a little bit first. As well as stop this 'everything on kubernetes' thing. Right now I need kubernetes for at least half of all Gitlab functionality, and I have no doubt this latest acquisition will be the same thing.
I doubt any of the existing GitLab (sast, container scanning, dependency scanning / gemnasium, etc.) security scans need Kubernetes cluster integration.
They are normal containerized Jobs, for which all you need is GitLab Runner with Docker executors.
@Aeolun - The acquisitions, once integrated, will work just like the other Secure scanners (e.g., SAST, DAST). They will be launched via CI runners within their own containers. As such, Kubernetes isn’t needed. @factorialboy is correct.
I have a genuine curiosity about GitLab as a business:
Are they actually growing much more in the mindset of developers since GitHub started doing some things right?
I have personally always wanted alternatives and GitLab* is a good one, but the reason I can not say they are a great one is because somehow* their story to me feels too much "against GitHub" than their own story.
GitHub made a lot of mess and eventually they undid some or just enough that they still retain the lion's share of public repos/projects. This matters a lot because community is great power, whoever holds it, holds key to future mindshare.
I want GitLab to be a larger part of the developers mindset everywhere, but I am not sure that is happening at the moment. Why not? If my assumptions are wrong, that is also acceptable to me, would like to see some signals.
My university asked me to install GitLab on a 32bit Dell Server made circa ~2002 while I was a teaching assistant, because we were conducting a hands-on class of reimplementing TCP/IP and IT wanted everything we were doing airgapped off the school network.
Unfortunately the omnibus package is 64bit-only so I had to build from source... which was pretty hard. But I was only able to do that after figuring out how to upgrade from Ubuntu 8.04 to 16.04 with the only input being a CD (not even DVD) drive. I don’t remember why OTA upgrade was failing, I think the version was too old. Managed to get Ubuntu 12.04 or something thinned down enough to fit on a CD. From which network upgrade worked.
Whole process took ~20 hours over a few days. Craziest install I’ve ever had to do... University would have saved a bunch of money if they had just bought us a new small 64Bit server. Ah well.
I installed it within 5 minutes locally. If anything, Gitlab is perfect to quickly set up code repositories in environments where on-prem is a hard requirement.
> This matters a lot because community is great power, whoever holds it, holds key to future mindshare.
Bitbucket and atlassian are still surviving despite not having any community presence on them. As long as bitbucket offers value(self hosting, CI, etc) and enterprises use them I think it'll be fine.
Most companies that I see using Bitbucket do so not because it's a good product but because it's usually cheap when you are already paying for JIRA and Confluence and because of the tight integration with those tools.
Thanks for asking. We don't comment on individual acquisitions beyond what is in the OP. For everyone else there reference our handbook page about acquisitions is on https://about.gitlab.com/handbook/acquisitions/
We won't necessarily open source all the acquired technology like we did with Gitter and RedHat does with every acquisition. We'll follow our buyer based open core model https://www.heavybit.com/library/video/commercial-open-sourc... Maybe the relevant product managers have more to say about the current plans.
@joiningnow123 - Thanks for the question. We plan to open source all the fuzzing engines built by Fuzzit. We also plan to open source Peach Tech's protocol fuzzer however this will be some time next year when we begin integrating it.
The biggest disadvantage of the buyer based open core model is can completely ignore what the buyer wants (ex: reporters not to be charged the same as developers, because that makes no sense).
This seems to be similar to GitHub adding automated code analysis and screening as well as detecting flaws in what would become the built artifacts like external APIs. In a sense they are delivering static analysis which used to cost a lot of money, time and dedicated manpower (i.e. HP Fortify).
It makes sense for those companies to expand beyond what they already have. Starting with version control systems, going on to Wikis, static websites, actions/automation, CI, artifact hosting. It will eventually contain the entire lifecycle it seems.
That’s funnier than the joke itself as I was scratching my head to understand the joke in
> It makes sense for those companies to expand beyond what they already have. Starting with version control systems, going on to Wikis, static websites, actions/automation, CI, artifact hosting. It will eventually contain the entire lifecycle it seems.
Because from what I understand wasn’t this the goal from early on? :)
On one hand yes, on the other hand there is a difference in making better products vs. enriching the product by buying other products and integrating them. On the other hand, there is no single 'right way' of course, and adding knowledge, people and IP via acquisition is a functional way to do that.
But people will inevitably compare products and with GitLab vs. GitHub it's an obvious one to make. I do get the feeling that since Microsoft bought GitHub they are accelerating their feature releases to be more in line with GitLab's speed.
We think that Fuzzing will grow in importance as security gets more focus in the software development process.