What a strange post. Considering the timing, it seems like it must have been posted in response to GitHub's announcement of new CI/CD functionality (also on the HN front page):
Not sure the down-line developer community is the audience for the post (or at least, likely not the primary audience).
They took $100M in D round funding in last 2018 [1], so it's likely a victory lap to validate their investment, and also a "see, you should buy us" post for engineering managers buying their services.
And, that said, they aren't wrong. It's a solid model.
The argument for GitLab has always been that they are more feature-rich, the argument for GitHub has been that their uptime is >80% and their UX is excellent.
If GitHub achieves feature parity, GitLab is dead.
License model
GitLab is built on an open core model. That means there are two versions of GitLab: Community Edition and Enterprise Edition.
GitLab Community Edition is open source, with an MIT Expat license. GitLab Enterprise Edition is built on top of Community Edition: it uses the same core, but adds
additional features and functionality on top of that. This is under a proprietary license.
For both versions: All javascript code in GitLab is open source. All javascript code written by GitLab is under the same MIT license.
However, that core is REALLY BIG. I do not really miss any enterprise feature. I ordered enterprise edition only to support it and I never installed it.
Well a lot of enterprises care about things like user directories (LDAP) and the extra access control. Just because you don't need enterprise features doesn't mean that large enterprises (the target audience for Gitlab Enterprise) don't!
I'm not saying it isn't great stuff, it really is, but "it is all open source" is sort of a misnomer. It is open core.
I'm of the same opinion with Dave Neary on Open Core Software. He's a long time contributor to the GNOME Desktop Environment:
You are right in general. Most open core tools do not let anything enterprise like into community versions. However, Gitlab is somewhat different. For example is that it lets you have LDAP/AD integration in core version. Compare that to lets say Mattermost which doesn't.
And yes, I need enterprise stuff, I just don't need enterprise stuff currently in Gitlab. Looks to me those stuff are created for really big teams and really big multinational companies. My company is 1200+ employees big with IT having around 70 people, and in that context I don't miss anything.
Futhermore, some enterprise features finish in core after some time. I have never witnessed the opposite in Gitlab.
Then it's going to lose against the free gitlab, and the pricing page (https://about.gitlab.com/pricing/) that doesn't even have a "contact us for a price" option.
We use Gitlab for work because the self-hosted version is free. For small companies Github is a pretty steep unnecessary expense, and we appreciate control over our own servers. Unless Github makes a self-hosted version there isn't really a comparison for us.
To me Github is about the community. Lots of open source software and forks of that software, you can put your profile on your resume. Gitlab has more features and self-hosting; Github has a coding social network.
We run Gitlab on premise during last 4 years and I can't complain on those costs - updates are "click this button", backups are few hours work to have, there are no server maintenance whatsoever if you don't count runners and we didn't yet have catastrophic failure so I can't guess on that.
So far, price was next to nothing relative to mass of functionalities given in free version.
> recovering from backups in situations where your servers fail?
We are able to recover in a reasonable timeframe. We take occasional server snapshots, and in the case of the machine completely going dark we could spin up one of those snapshots, dist-upgrade, and apply our git / Gitlab back and be back to normal.
Your concerns are good concerns for big companies. For small companies who don't need 99.99% SLA, running git/Gitlab on your own server is tremendously more reasonable than Github's paid plans.
Every time github releases a feature this is the response. These posts are so pathetic. I’m surprised that they continue to play this angle. It’s a very polarizing way to address the community that will definitely continue to stir up us vs them mentality between GitHub and Gitlab users.
Not to heap it on...but ok who am I kidding I am heaping it on: I had a terrible interview experience with them.
Basically there was a period on HN where every other post was about stupid hiring practices and how absurd some code interviews were. Well Gitlab embodied all of them.
They phone interview quizzed me on several "gotcha" questions, and finally I was asked to describe Prototypical inheritance (JS), in which I was knowledgeable about and gave a very detailed and technical answer, in my own words (so not some memorized wikipedia answer), and basically what I got back from the recruiter was in essence, "Nope that's not what this piece of paper I have in front of me says the answer is" that is that although I had answered the question technically correctly, it wasn't the type of answer they were looking for.
Anyways, not salty about it anymore because it seems like I dodged a real bullet.
Yuck, the phone interview sounds like exactly why I didn't make it to the phone interview. I answered their 2 pre questions via web form... Very detailed answers although the questions were annoyingly vague on how much detail to include. Definitely qualified or even over qualified for the role and got a "not moving forward" with no explanation. Kindly asked for an explanation so I could improve and got so response. I'm leaning towards ageism because I have nearly 20 yrs experience.
Hi Liam, I think the comment captures the essence of what feedback I would have and I am not interested in providing anymore feedback, no offense I am busy, but appreciate your willingness to learn and grow, sounds like the company could have used a few more people like you at the time I interviewed (was 2 years ago now).
GitLab don't have to worry too much. Their uptime has been fine for us over the course of several years. And it's good that GitLab is around, so that we don't have to worry quite so much about Microsoft/GitHub messing around with the code in international projects. They have a great history[1] of co-operating with nefarious people. (And no, most people do not sign their commits and watering hole attacks are an obvious worry).
Gitlab is a fine service and I do prefer it to github. A few problems I have stem from the seemingly never ending security updates, almost weekly it seems. Patching at that cadence is a PITA. My other gripe comes from the company interview process which was very bro-ish, disappointing and off putting.
I use Gitlab CE and I certainly prefer it to GitHub. The interface just makes more sense to me as an operations-first guy. The CICD connections are great.
That said, I do SOME work in GitHub to stay familiar with it. And I've set up web gonna to push to lambdas, but I would probably hate that process if I wanted to clone a private repo and had to deal with the security there.
I hear Osborne is going to release a new computer soon. It's going to be much better than the current one, so why bother to buy what's on sale now?
Gerald Ratner says that some of the earrings his store stocks are as cheap as a prawn sandwich, and will last about as long. People are talking so... good for him, eh?
It's especially rich considering Gitlab is, or at least was, an almost identical clone of Github. Didn't they actually use Github's exact HTML at the beginning, including several instances of "GH" or "GitHub" as class names etc?
Some will continue to prefer a self-hosted GitLab instance over GitHub, but requiring at least 4GB of RAM [1] for a low traffic instance sounds like an aberration. There should be better ways to manage memory consumption, and a lean GitLab instance that we have full control over could still be their selling point over GitHub.
Giving away your core product for free is hardly a “selling” point. As open source is all about scratching your own itch, their itch isn’t lean software because that isn’t what they run in their company.
We agree 4GB is too much. We put a team together to get the memory usage down https://about.gitlab.com/handbook/engineering/development/en... They’re rolling Puma out as an application server on .com within weeks. After that is successful we’ll make that the default. That should save a lot. After that the memory team will keep improving it.
Hi this is Craig, the Engineering Manager for the Memory team. We're actively working on reducing the memory issues with GitLab. We are approaching this by responding to known issues and building out proactive tooling to inform developers of memory usage during the development cycle.
An untruth stated calmly doesn’t become true. A truth stated passionately doesn’t become false. This is at the heart of why most appeals to emotion are logical fallacies.
Having said that, people being emotional certainly goes a long way toward explaining why pleasant people are more likely to be listened to.
This seems like misdirection. Gitlab's largest problem is their record of operational incompetence. This will take some time to recover from. Personally, I won't use them for a least two more years, based on their data loss incident two years ago.
I do wish them luck. Github/Microsoft should have a credible competitor.
I think what GitLab really needs is what a lot of open source projects are lacking: popular community forks. Their product development benefits from the community's QA feedback, but there are no community forks (that I am aware of) that are taking GitLab CE in directions that gitlab-org won't go. IO did this for Node and everyone has benefitted.
I think GitHub's UX has caused new developers to lose true meaning of fork. When software doesn't work the way you want it to, you fork it, and if other people want it enough, they will merge it into their own forks and maybe some day it will get adopted upstream.
As more of the feature development goes into EE, there is less of a need to back port the latest changes. There are tons of workflow processes I would love to more tightly integrate with GitLab, but not all of them would make sense outside of my organization. Some of them can be hacked together with bots, but some of them require extending the core functionality and would probably require a fork.
> forking GitLab instead of contributing upstream
I think this is the problematic mindset. Meaningful contributions to upstream will follow useful forks.
> they all fell behind with upstream and couldn’t keep up to date anymore.
Code churn doesn't just slow down forks, it slows down core development.
Amazon was not the first online bookstore, nor is Apple first to market with their product features. Funny thing is, they made it sound like they pioneered the idea of:
> Realizing the future of DevOps is a single application
Google already realized the value of coupling their version control to CI years ago
All else aside, I realized that if you add hosting and assume dogfooding, GitLab's product is a platform made for building, configuring and running the platform you're building, maintaining and configuring... It feels Hofstadterian from several angles.
> Idera acquired Travis CI
This is disingenuous. That acquisition is not a validating example.
That aside, I don't feel a need to read in as much passive-aggressiveness as everyone commenting does. It's a bit of rivalry, sure.
Resource-usage aside, I was happy self-hosting GitLab for years.
> Well, if you don’t believe that it’s better for a user, at least believe it’s more efficient for us, because we only have to release one application instead of two. Efficiency is in our values.
Wow, this is some terrible reasoning. Efficiency and cardinality are orthogonal.
For a company of the size of Gitlab, releasing two apps instead of one shouldn't be much of a burden.
Now two different concerns' uptime and performance are coupled.
No wonder that Gitlab has an infamous track record when it comes to response times / uptime.
(more constructively: I'd point out that both end-users and GL developers could have an equally unified experience while the concerns remained separate. Good architecture makes it possible)
I ran a company that was in the GitHub marketplace and was a partner. At the GH partner day a few years ago they shared their view the world: their thinking was that it was preferable for devs to be able to use “best in class” tooling for CI, project management, etc, with gitHub’s version control at the center.
GitHub contrasted this with the “one stop shop” approach where you get all your Dev needs met with (presumably) inferior tools from a single vendor.
Because, the thinking went, how could one vendor do everything better than many vendors? Especially if you have sets of vendors focused on one tool in the Dev toolchain?
Between Projects, Actions, and CI/CD, it seems GItHub has indeed come around to the one stop shop view of the developer toolchain.
I guess each of those only has to be good enough and not best in class. And there are efficiencies to be gained for customers from an integrated approach.
> At the time I believed we needed to have tools that are composable and that could integrate with other tools, in line with the Unix philosophy. Kamil convinced me to think about the efficiencies of having a single application.
The Unix Philosophy is dead today, but I don't believe that's because of any inherent flaw in the principle of "composability". It's that we no longer have a good composition mechanism for the types of programs that people run.
In 1975 or 1985, you were running a command-line tool to process some data. (That kind of sucked, but whatever, that's what we had.) The idea of being able to pipe bytes from the output of one to the input of another is pure win. Fewer steps, no temp files, see results as they are completed -- and the cost is literally one character. No wonder it took off.
Today, the types of programs people run are native apps (which don't have an obvious I/O mechanism, apart from the filesystem, if that) and web pages (i.e., programs awkwardly split across my computer and some server in Virginia, speaking an ad-hoc protocol). Making them talk to each other takes a developer and a month.
I'd love to be able to have a web app, a word processor, my contact list, etc., talk to each other and easily and meaningfully pass data between them (and I'm working on software to do just that -- see my bio). Why can't I pipe my Facebook friends list straight to a spreadsheet, or a map?
They speak of the efficiencies of having a single application. It's more the lack of an efficient standardized way to combine different applications. Back when it was "type one character", the efficiency argument went the other way. We need to get back to where sharing data with every other program is the default.
The Julia language can solve all those composability problems you are having, much of the package ecosystem is very composable. It is currently focused on scientific computing, but it is a full general purpose language.
GitLab will automatically detect where in your codebase that vulnerability exists, update the dependency, and deliver it to your production environment.
Auto patching and deploying to production in an automated fashion sounds like a terrible idea. Do people actually do this?
Does it work for them?
Seems like marketing speak, and weirdly self-congratulatory in a not entirely correct way (reminds me of announcements made by Apple, in fact), but they're not wrong.
70 comments
[ 2.5 ms ] story [ 148 ms ] threadhttps://github.blog/2019-08-08-github-actions-now-supports-c...
But if so, it's quite a backhanded response – the post itself only mentions GitHub in passing.
They took $100M in D round funding in last 2018 [1], so it's likely a victory lap to validate their investment, and also a "see, you should buy us" post for engineering managers buying their services.
And, that said, they aren't wrong. It's a solid model.
[1] https://about.gitlab.com/2018/09/19/announcing-100m-series-d...
GitLab is under siege from GitHub.
The argument for GitLab has always been that they are more feature-rich, the argument for GitHub has been that their uptime is >80% and their UX is excellent.
If GitHub achieves feature parity, GitLab is dead.
We need more of both.
https://about.gitlab.com/pricing/self-managed/feature-compar...
https://about.gitlab.com/install/ce-or-ee/
https://opensource.org/osd-annotated
It is cool that they're source available, but that's still not the same. Putting a disclaimer that you work for gitlab would also be appreciated.
I'm not saying it isn't great stuff, it really is, but "it is all open source" is sort of a misnomer. It is open core.
I'm of the same opinion with Dave Neary on Open Core Software. He's a long time contributor to the GNOME Desktop Environment:
https://blogs.gnome.org/bolsh/2010/07/19/rotten-to-the-open-...
And yes, I need enterprise stuff, I just don't need enterprise stuff currently in Gitlab. Looks to me those stuff are created for really big teams and really big multinational companies. My company is 1200+ employees big with IT having around 70 people, and in that context I don't miss anything.
Futhermore, some enterprise features finish in core after some time. I have never witnessed the opposite in Gitlab.
Maybe, assuming GH matches them at the same price points per feature and including self-hosting as a feature.
To me Github is about the community. Lots of open source software and forks of that software, you can put your profile on your resume. Gitlab has more features and self-hosting; Github has a coding social network.
- maintaining and updating your servers
- updating the free software
- backups
- recovering from backups in situations where your servers fail?
I don't think you get that for free? If you consider those costs, the price tag for a hosted solutions becomes more and more reasonable.
So far, price was next to nothing relative to mass of functionalities given in free version.
sudo apt-get update && sudo apt-get dist-upgrade
> updating the free software
sudo apt-get update && sudo apt-get dist-upgrade
> backups
We setup a cronjob that backs up the server
> recovering from backups in situations where your servers fail?
We are able to recover in a reasonable timeframe. We take occasional server snapshots, and in the case of the machine completely going dark we could spin up one of those snapshots, dist-upgrade, and apply our git / Gitlab back and be back to normal.
Your concerns are good concerns for big companies. For small companies who don't need 99.99% SLA, running git/Gitlab on your own server is tremendously more reasonable than Github's paid plans.
The decision to fuse the two components (SCM and CI/CD) must have been quite a leap of faith. Wasn't aware of this.
Basically there was a period on HN where every other post was about stupid hiring practices and how absurd some code interviews were. Well Gitlab embodied all of them.
They phone interview quizzed me on several "gotcha" questions, and finally I was asked to describe Prototypical inheritance (JS), in which I was knowledgeable about and gave a very detailed and technical answer, in my own words (so not some memorized wikipedia answer), and basically what I got back from the recruiter was in essence, "Nope that's not what this piece of paper I have in front of me says the answer is" that is that although I had answered the question technically correctly, it wasn't the type of answer they were looking for.
Anyways, not salty about it anymore because it seems like I dodged a real bullet.
I am Liam a Recruiting Lead for Gitlab. I would be very keen to set up a time to talk through your interview experience.
1. https://news.ycombinator.com/item?id=20645964
That said, I do SOME work in GitHub to stay familiar with it. And I've set up web gonna to push to lambdas, but I would probably hate that process if I wanted to clone a private repo and had to deal with the security there.
I hear Osborne is going to release a new computer soon. It's going to be much better than the current one, so why bother to buy what's on sale now?
Gerald Ratner says that some of the earrings his store stocks are as cheap as a prawn sandwich, and will last about as long. People are talking so... good for him, eh?
[1] https://docs.gitlab.com/ce/install/requirements.html#memory
You can follow along with our efforts on this board: https://gitlab.com/groups/gitlab-org/-/boards/1143987?label_...
Having said that, people being emotional certainly goes a long way toward explaining why pleasant people are more likely to be listened to.
I do wish them luck. Github/Microsoft should have a credible competitor.
I think GitHub's UX has caused new developers to lose true meaning of fork. When software doesn't work the way you want it to, you fork it, and if other people want it enough, they will merge it into their own forks and maybe some day it will get adopted upstream.
Any examples of things you see that we at GitLab Inc. are not open to?
As more of the feature development goes into EE, there is less of a need to back port the latest changes. There are tons of workflow processes I would love to more tightly integrate with GitLab, but not all of them would make sense outside of my organization. Some of them can be hacked together with bots, but some of them require extending the core functionality and would probably require a fork.
> forking GitLab instead of contributing upstream
I think this is the problematic mindset. Meaningful contributions to upstream will follow useful forks.
> they all fell behind with upstream and couldn’t keep up to date anymore.
Code churn doesn't just slow down forks, it slows down core development.
> Realizing the future of DevOps is a single application
Google already realized the value of coupling their version control to CI years ago
Should GitHub dominate the market and gobble up competition, we all know how it goes for its parent company.
I'm happy with this competition.
> Idera acquired Travis CI
This is disingenuous. That acquisition is not a validating example.
That aside, I don't feel a need to read in as much passive-aggressiveness as everyone commenting does. It's a bit of rivalry, sure.
Resource-usage aside, I was happy self-hosting GitLab for years.
Wow, this is some terrible reasoning. Efficiency and cardinality are orthogonal.
For a company of the size of Gitlab, releasing two apps instead of one shouldn't be much of a burden.
Now two different concerns' uptime and performance are coupled.
No wonder that Gitlab has an infamous track record when it comes to response times / uptime.
(more constructively: I'd point out that both end-users and GL developers could have an equally unified experience while the concerns remained separate. Good architecture makes it possible)
I ran a company that was in the GitHub marketplace and was a partner. At the GH partner day a few years ago they shared their view the world: their thinking was that it was preferable for devs to be able to use “best in class” tooling for CI, project management, etc, with gitHub’s version control at the center.
GitHub contrasted this with the “one stop shop” approach where you get all your Dev needs met with (presumably) inferior tools from a single vendor.
Because, the thinking went, how could one vendor do everything better than many vendors? Especially if you have sets of vendors focused on one tool in the Dev toolchain?
Between Projects, Actions, and CI/CD, it seems GItHub has indeed come around to the one stop shop view of the developer toolchain.
I guess each of those only has to be good enough and not best in class. And there are efficiencies to be gained for customers from an integrated approach.
The Unix Philosophy is dead today, but I don't believe that's because of any inherent flaw in the principle of "composability". It's that we no longer have a good composition mechanism for the types of programs that people run.
In 1975 or 1985, you were running a command-line tool to process some data. (That kind of sucked, but whatever, that's what we had.) The idea of being able to pipe bytes from the output of one to the input of another is pure win. Fewer steps, no temp files, see results as they are completed -- and the cost is literally one character. No wonder it took off.
Today, the types of programs people run are native apps (which don't have an obvious I/O mechanism, apart from the filesystem, if that) and web pages (i.e., programs awkwardly split across my computer and some server in Virginia, speaking an ad-hoc protocol). Making them talk to each other takes a developer and a month.
I'd love to be able to have a web app, a word processor, my contact list, etc., talk to each other and easily and meaningfully pass data between them (and I'm working on software to do just that -- see my bio). Why can't I pipe my Facebook friends list straight to a spreadsheet, or a map?
They speak of the efficiencies of having a single application. It's more the lack of an efficient standardized way to combine different applications. Back when it was "type one character", the efficiency argument went the other way. We need to get back to where sharing data with every other program is the default.
Auto patching and deploying to production in an automated fashion sounds like a terrible idea. Do people actually do this? Does it work for them?