The market figured out Gitlab’s secret
about.gitlab.com
about.gitlab.com
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.
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?
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.
[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_...
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)
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/
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.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.
I do wish them luck. Github/Microsoft should have a credible competitor.
https://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...
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 decision to fuse the two components (SCM and CI/CD) must have been quite a leap of faith. Wasn't aware of this.
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?
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.
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.
> Realizing the future of DevOps is a single application
Google already realized the value of coupling their version control to CI years ago
> 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.