We think that Fuzzing will grow in importance as security gets more focus in the software development process.
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.
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)
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 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.
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.
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...
2. issue relations in core
3. getting a repository file via curl easily (yeah, seriously)
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 ?
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.
1. This works but not nearly with all functionality.
2. Maybe an options to have related in core and more detailed relations like blocking in a paid version.
3. I’m surprised this isn’t possible already. Is this easy to contribute for anyone?
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.
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.
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.
“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
What is the top feature you would like to see?
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.
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.
They are normal containerized Jobs, for which all you need is GitLab Runner with Docker executors.
Glad to see the competition in the repository hosting space is strong. It’s benefiting every developer.
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.
* typo fixed
Those two things are pretty much what makes it better than other self hosted solutions.
If company X is paying 10 x (even low) salaries of USD 100K annual, do they want to save say $5K annual if developers do not want?
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.
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.
Every large enterprise that fell, stood once.
Are these soft landing acquisitions as described in your handbook? Also will the technology be open sourced like Gitter was?
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.
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.
One could argue that GitLab gets more and more mature but somehow still has Peach Fuzz.
> 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? :)
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.