We will definitely have to think about moving. This just makes no sense at all. At least there's a transition phase with 24$, but that's already stretching it. Yes, they are adding features nobody asked for like crazy, just to be able to check more boxes in some feature matrix. Meanwhile, absolute basic stuff is simply not working or buggy as hell. Whenever I encounter a new quirk, I usually google for it and almost always find some years-old issue that is rotting away. "Advanced" search is completely useless as you can't really search for code. The whole CI/CD stuff completely falls apart once you scale things up. Just creating the pipeline takes literally minutes. When running a pipeline, I have to reload 10 times until I finally see the job variables (at least that one will FINALLY be fixed in 15.9). No good overview of what runners are busy with, no priority on runners, although why am I complaining about stuff like that when you can't even FILTER JOBS BY NAME. And don't get me started on the self-hosting stuff...
There was a time when GitLab was superior to GitHub. This is clearly no longer the case. Not a good time to increase prices.
I've been a huge fan of Gitlab in the past, first for their open source nature and second because I felt it was a great product. Their CI stuff was miles ahead of everybody else and was a no brainer. Their main UX was (IMHO) a bit inferior to Github's, but once you learned it it was perfectly acceptable. It was sometimes very slow, but it was tolerable.
But I have to agree with you. The pricing is outrageous. It was already way over-priced, now it is just insane. They shot themselves in the foot hard by making you buy all the things instead of some a la carte (which made incremental adoption highly expensive), and it is impossible to make a business case for adopting Gitlab. In addition Gitlab has gotten slower and less usable.
I still have warm feelings for Gitlab so I hope they will hear this plea: Please, make your prices more competitive and reasonable and don't force an "all or nothing" scenario because you're gonna lose a lot more than you win.
They’re not an open source friendly company. They’re actively hostile to open source, even defaulting to providing you with a non open-source free version to self install, and making it hard to find the actual open source version.
And their management of the open source repo is also highly restrictive.
Which is their right. And maybe even the right thing to do, but what doesn’t make sense is giving them any brownie points for being “open source”.
> The pricing is outrageous. It was already way over-priced, now it is just insane. They shot themselves in the foot hard by making you buy all the things instead of some a la carte (which made incremental adoption highly expensive), and it is impossible to make a business case for adopting Gitlab. In addition Gitlab has gotten slower and less usable.
I've been a huge fan of GitLab for years as well, but this is the problem. Every place I've gone, I could never justify spending money for their paid version. And I so desperately wanted to! Some of that was the ridiculous "all users are paid even if they are just looking at the web GUI and not actually doing anything". But not all.
> Yes, they are adding features nobody asked for like crazy, just to be able to check more boxes in some feature matrix.
This.
If people want "DevOpsSec" then make it a feature or addon tier. I'm certainly in favor of more security and testing, but the few times I've reviewed this feature it doesn't work for our use case. We use external CI/CD services because Gitlab CI (and runners to some degree) don't do what we want. But now, we're forced to pay for this feature as if it helps us. Perhaps Gitlab can't imagine a company that doesn't build cloud connected software.
I moved our organization of hundreds of users from Bitbucket years ago after a week long internal API rate limit in Bitbucket's infrastructure crushed our CI/CD system and took them way too long to acknowledge and fix (of course it wasn't documented). I fear this is the build-up to a similar move again, and I dread it. At the time Gitlab was on a much more impressive trajectory then Github and hence motivated my decision, but this has changed and it's largely self inflicted wound for Gitlab.
Part that pains me the most is I championed the move to Gitlab and encouraged all the teams to double down on it over the years.
This is something I've thought about. We don't really have the resources and I'd rather pay Gitlab to manage this on a day to day.
If we did self host, it couldn't be Gitlab as I fear they'd pull the plug on these offerings as Atlassian is doing[0]. The incentives are there for them to offer self hosting in the short term to grow the customer base, but long term incentives push them to maximize profit via over priced managed services.
And this is the hard part: moving to another solution and self hosting is a ton of work.
Watching the other replies to see what self hosted solutions are most intriguing.
One thing I'm doing now is halting further development of moving things to Gitlab CI/CD so we can better control our future fate.
Not my experience at all, in a similarly sized premium on-prem GitLab. I git-push and the pipeline is running faster than I can get to my browser. Jobs queue basically instantly assuming you have enough runners for your workloads.
I have no experience with using the search. On both GL and GH I prefer to just pull the code and search with my preferred local tools.
Personally I find GitLab CI syntax better to work with than GitHub, particularly if using dependency-based versus using stage-based workflow.
The reason it is so slow for us is probably because we use a lot of external includes and trigger jobs. But as I said: the problems start once you scale things up. Then you also cannot just "pull the code" for a search, as we also have a lot of repositories.
We did an exhaustive comparison of GitLab vs GitHub, among a few other tools. We had a strong technical preference for GitLab. Performance of runners can be problematic at times but we still don't feel like GitHub is too competitive. However, a 50% price increase is LARGE. What are GitLab users doing to try and justify the cost? We have the ~800 seats and don't want to make a move to something else.
> Yes, they are adding features nobody asked for like crazy, just to be able to check more boxes in some feature matrix. Meanwhile, absolute basic stuff is simply not working or buggy as hell.
Ain't that the perfect description of GitLab. I love GitLab, and do still find it better than GitHub, but because of all the old annoyances, it's really hard to justify to others.
> "Advanced" search is completely useless as you can't really search for code.
@deng - thanks for the feedback. I am on the Product team for our Search service, code search is not where we would like it to be.
We are in-progress on swapping out the backend for code search from Elastic to Zoekt, which should provide a much more reliable and complete set of search results. You can read more about our plans for fixing code search here: https://about.gitlab.com/direction/global-search/code-search...
This is the key deliverable for the team, and we are making efficient progress. If you have feedback on our plans, we would love to hear it. The epic is here: https://gitlab.com/groups/gitlab-org/-/epics/9404
Other countries and languages are used to always put the unit after the value, including for currency. It's an easy minor mistake to make in English. Chill.
My son's math teacher have them putting it after. I explained that's not the traditional way, but since it's one of the first units they'll encounter, it's not a terrible idea pedagogically.
Interesting turn of events. For my team of about 10 users (5 just for access to wiki/issues) we recently moved to GitHub. When Gitlab first announced the price changes, annual billing and user restrictions on Gitlab.com we reluctantly went to self-hosted. Over time we got tired of the maintenance and the system was just slowly coming to a crawl. We switched to GitHub and we went from freeloaders on Gitlab to paying customers simply because they had a price appropriate tier for our team ($4/user vs. $19/user and now $29/user).
Actually we use LFS aggressively which can get pricey on GitHub but I’m happy to pay for usage rather than some arbitrary per user number. If I add a user who just needs access to issue board I have to pay $348 upfront with Gitlab! Multiply that by factors of 10 and the numbers creep up. Peanuts for an established business with revenue but not for a boot strapped venture or hobby project.
Personally, I'm willing to pay for it just to keep everything in one system.
Gitlab's aim seems to be to replace the mashup of multiple 3rd party systems into a central place for the company. The associated costs of each one of those systems, user management, etc that go with them adds up.
Plus, you have to consider any per-user pricing as part of your cost per employee. If you're paying somebody a salary who's accessing a system where they interact with the rest of the company...$29 is not a big deal when lumped in with the salary, benefits, taxes, etc.
If you're a few college students working in your spare time with no income, sure it's a problem. But even then Gitlab gives away plenty on the free tier and you can each setup a runner on your own laptops to avoid paying for CI minutes.
IMO, this pricing is very reasonable considering the variable quality of different integrated systems out there.
My sentiments exactly. Sure, on paper they offer capabilities to "replace" other 3p tooling, but you can't replace fully fleshed-out products with half-baked features. Take Jira for example. Gitlab markets itself as having "comprehensive" (the highest kind) comparability to Jira's team planning, portfolio management, and service desk capabilities.
I would be interested in knowing how Gitlab handles some of the functionality my team relies on every day with regard to task management:
Does Gitlab have an automation engine that can trigger a set of user-defined rules based on events like issue creation, comments, transitions, etc etc?
Does Gitlab allow users to define custom issue and request types, custom fields, custom validations, custom screens and workflows?
Can I link issues in Gitlab? Can I create issue-type hierarchies?
Do you think pricing based on features would be more reasonable for people that don’t currently have the need for the other 3rd party systems? I’ve heard that they don’t want to make pricing more complex but it does seem like a steep pricing if you only need say what GitHub offers for $4/user.
That’s interesting do you have more details about the runner farm? In my small scale experiment it was difficult to have so many available runners at all times. We run a monorepo and there are changes that will hit several apps that need testing. So for example opening a PR might need 40 runners. Meanwhile other devs might need 1 or 2, etc.
> Gitlab's aim seems to be to replace the mashup of multiple 3rd party systems into a central place for the company.
Outside of how we manage and release software, there are tons of small processes and projects that go on within an organization. Sometimes there are dedicated tools for these. Sometimes you pay for that, sometimes you don't. Sales, Support, IT Helpdesk, Marketing, Business Ops, HR, Admin... it runs the gamut.
Those things have nothing to do with code. You'll find folks using Jira, Trello, or any other "mashup of multiple 3rd party systems".
If GitLab or GitHub want to be "a central place for the company" that helps you eliminate that mashup, then they need to have a UX for people that are terrified by code listings and don't want to have to click through five things to get to the thing they care about.
So, really, GL and GH are good for your engineering organization, but they suck for the rest.
I've seen people maintain a static website with Jekyll and GitLab. It was about a math-adjacent research field and the system was quite nice for this use-case.
Definitely not worth a paying subscription though. IIRC a public lab was hosting and maintaining the instance for all their employees.
Yea but Github isn't competitive in all the SDLC stages like Gitlab. Gitlab is comprehensive platform for DevSecOps whereas Gitlab is more of a point solution that covers a few stages like SCM and CI/CD through GitHub actions which are complicated to use. Shops with excellent DevSecOps hygiene will still need to subscribe to multiple other point solution tools to get the same capabilities of Gitlab offered in a single platform for one price. Our shop saves money on OpEX using Gitlab after we cut the expense of lots of other tools and the overhead of maintaining them with consolidation into Gitlab.
I have been a big fan of gitlab and have definitely promoted its use in the organisations I have worked (putting a $ amount on it, I'm probably responsible for $30,000/y in their revenue, which doesn't sound like a lot now that I'm typing it out).
But honestly I'm extremely displeased with this. I guess nobody is ever happy to pay more, but gitlab was already more expensive than github.
More staggering is that there's no discount pricing for self-hosting your gitlab instance, so you may as well use Gitlab's resources on the SaaS platform, which is more expensive for gitlab themselves -- yes, annoyingly, storage over a certain volume is an additional cost, but you'd pay it anyway if you self-host, so whatever.
I know there's a lot of features that I don't use and that I begrudge paying for, just like everyone else (who probably have a different set of things), and I know the cost is probably trying to be just under the cost to switch away, but 52% for features I don't care about mostly is steep.
This is also the second increase in 2 years, even though marketing says otherwise, because "Starter" and "Bronze" no longer exists and was absurdly cheaper than Premium. ($4/u/m)
----
Look: Going from $4 to $29 per user in 2 years is terrifying as a person who is now writing checks on behalf of my company.
For context, Perforce is basically a market leader in Gamedev (and as a consequence using gitlab for me is a fight against normality) and it's considered "too expensive" (to the point google made their own) but a necessary evil because there's no alternative at $41,25/u/m
So my users who use gitlab and perforce (everyone using gitlab is also using perforce) is now going to be $70+.
If you are balking at the cost of hosting, give us a cheaper licensing plan for self-hosting. - the idea that CODEOWNERS, protected branches and approval rules is worth $29 per user (even if they're non-coders!) is just absurd.
Promoting Gitlab was the biggest mistake I made. Every team I promoted them to has been bitten time and again by their licensing, feature, and pricing changes.
Many other services I've promoted have also seen price changes, etc. but I've never felt genuinely frustrated with the changes in any of those like I have with Gitlab.
I mentioned this in the other thread, but the excuse vendors often use for not offering a self-hosting discount is that their support costs are often much higher for self-hosted customers. I've never been provided direct evidence of this, but that's what they say.
I'm a Support Engineer at GitLab, and based on my own experience that statement is definitely correct. There's entire classes of problems you simply don't have to deal with at all for SaaS customers.
I get into this argument inside my company, but as alternative point of view is that "hardening" the software for those 'I have seen some shit!' circumstances can be actually good for the overall health of the codebase and user experience. "It works on my machine" is all well and good until something goes off the rails (heh, so to speak), and if the software always assumes the happy path, debugging that is painful for an internal audience just as it is for external ones
Come to think of it, I would have though GitLab's fully-distributed workforce would make this true for you, too, since "I dunno what this error means, lemme just walk over to Jane's desk and ask" becomes expensive in that setup
I used to support a software package that could be self hosted or managed. The amount of work I had to do for managed customers was a 10th of the self hosted customers. We made way more money off the managed customers too!
There are two reasons that self-hosted is expensive, both having no relation to real costs.
1. If you are self-hosting, you have now segmented yourself into the customer category with the government, military, and large corporates concerned about security. This segment will pay more and so will be charged more. In an enterprise software company the vast majority of revenue comes from the larger customers vs many small customers, so these are the users that pricing gets optimised for.
2. Gitlab wants to be seen in the market as a SaaS company as subscription revenue is far preferable to licence revenue from a churn perspective, and also from a general trend perspective where self-hosted, hard to maintain solutions get replaced by cloud solutions.
> there's no discount pricing for self-hosting your gitlab instance, so you may as well use Gitlab's resources on the SaaS platform, which is more expensive for gitlab themselves
I think organizations that self-host aren't looking to save money so much as have more control.
I'm also unsure how much money Gitlab would save by not paying the SaaS costs. Yes, servers cost money, but it also costs money to make something available for self-hosting. When you're running SaaS, you can do continuous deployments and don't have to worry about cutting releases and the development slowdown that incurs. You don't have to do the same level of testing for SaaS because any issue can be much more quickly resolved since you control the deployment - you can even just ungate a small amount of traffic to new things to test them and make sure they're working well. With on-prem, there's likely a decent amount of work to be done making sure it works well in a lot of different environments, a lot of work testing various different things, and a lot of work supporting and debugging the on-prem deployments.
Plus, that doesn't even go into the cost of slowing down your development cycle or eliminating potential avenues for greater efficiency. For example, if you're a SaaS-only company, you can decide that a message broker from Google Cloud or AWS is going to save your developers a lot of time so they can focus on your core product. Instead, now you need people to run a Kafka cluster and you need a way to spin up a Kafka cluster for the on-prem deployments which isn't really why people are buying your product - or maybe the SaaS uses a message broker for things and you build the on-prem to just poll the database every minute; either way, you're having to do extra work. Instead of having people advancing your product, you have people spending time on learning how to launch Kafka clusters in lots of different on-prem environments and providing pluggable storage options instead of just S3.
As such, I'd argue that on-prem deployment is a feature that you're paying for rather than a way to save money. If you're deploying on-prem, you're paying Gitlab for all the work that goes into making the service something that can be stood up in an on-prem environment. I'm not saying that the price hike is good, but I think there are definitely costs in making a product that can be deployed for both on-prem and SaaS.
> As GitLab’s first price increase in more than five years
This seems... wrong. I swear that we were forced into a more expensive plan in the past couple of years; did they discontinue some middle plan that "Technically" means that this isn't a price increase?
Pretty shitty gaslighting, if (if!) that is the case.
I've been really impressed with gitea. What I'm most excited about though is their plans for federation. The idea of running my own gitea instance and being able to fork repos and make PRs with other instances really feels like what Git hosting services should be doing.
I couldn't really find this on their site, what's the difference between the two? Why did they fork, are there ideological differences or something? I'm not using gitea yet, but was considering it.
This is interesting - as I understand it gitea supports work flows from the github marketplace - and I had just made a note to try and figure out how the ruby/setup-ruby[1] action actually works/is implemented - and from the looks/claims here - I guess it should just work with gitea?
I'm a huge fan of Gitea but saying that GH Actions are supported is a bit of a stretch. Everybody asked for CI/CD so they started working on it and yes you can test it but nobody sane would use it in a production setting.
Try running act against their own act fork and watch it vomit. I first had contact with act trying to get VSCodium to build locally, since their build system is/was entirely GitHub Actions based. The "well, that didn't work" was horrific to troubleshoot
git clone https://gitea.com/gitea/act.git
cd act
make build
./dist/local/act -j lint -W .github/workflows/checks.yml --verbose workflow_dispatch
echo good luck
As far as "Github actions are supported", I seem to recall they're using "act" for that and this issue appears to match my recollection, as well as my experience with act being fine for hello-world but 100% absolutely not a replacement for a formal CI/CD system: https://github.com/go-gitea/gitea/issues/13539#issuecomment-...
I will concede I have not tried keeping up with their fork <https://gitea.com/gitea/act> so maybe they cured all its ills
> As GitLab’s first price increase in more than five years, this new pricing for GitLab Premium reflects the evolution of GitLab from source control and CI to the most comprehensive DevSecOps Platform. Over the past five years, GitLab Premium added more than 400 features, leading to improved cycle times, enhanced developer experience, and better collaboration for our customers
As a paying customer, I don't use many (most?) of those 400 new features. Meanwhile, stuff that could be game-changing for me like making gitlab-runner easier to deploy or local pipeline testing are being kicked down the road since forever. Search still sucks. There is no cheap licensing for read only, non developer folks.
That's it, I'm moving on. Luckly I have a whole year before renewing our licenses.
I agree. GitLab was arguably a better product for a while back when GitHub didn't even have integrated CI, but at this point most of the features they are adding just feel pointless to me. I primarily just want a place to store my code, track issues, and run automated tests.
GitLab was already a bit of a tricky sell due to most open source code being on Github, but now it is either $48 / year for Github or $348 for GitLab. The math just isn't mathing.
The ratio is on the order of 10:1 subscription vs. licensing (self-hosted?) and "other," according to their most recent QE report [0]. But I'm curious how many subscribers they have on the Enterprise $99/user plan. I wouldn't be surprised if it's a fairly low number of organizations (under 100), especially since those organizations have the option to self-host GitLab at much lower cost.
Pretty sure we're GitLab Ultimate customers for the security functionality, and we don't even use the issues/project functionality as we have Jira. And we're not a massive company.
I expect it's close, honestly. I dunno who's paying $100/month for what GitHub offers (but on a platform that all your devs already know) for $20/month...
I find it interesting that several companies are enacting policies to extract more revenue from customers in this economy via price increases or policy changes.
I feel that this may force customers who are looking to reduce cost leave respective platforms resulting in a negative impact on the revenue.
Isn’t the best strategy in an economic situation such as this to hold pricing and give one less reason for customers to drop off?
Its difficult to quantify a best strategy as there a many more variables at play than just what the customers can afford. There is usually a "sweet spot" for every type of customer that is a careful balance between price and amount of customers that maximizes profit. I'm doubtful that this price change will motivate more than 34% (1 - $19/$29) of their customer base to move elsewhere that would negate extra profits from price hike. Mostly due to the time required for customers to move elsewhere and the sunk investment of moving onto gitlab in the first place (a form of vendor lock in). There are also likely savings in other areas such as support that roughly scale with number of customers like sverhagen suggested.
From a financial perspective, it seems likely that gitlab will profit from this change. They may be able to profit more and mitigate hobbyist/very small business business loss by introducing another tier but gitlab is the only one that has enough information to determine if that is worthwhile from their perspective.
I'm sure they have spreadsheets and math to back this up, and I'm going to wager that they decided that less customers in a higher tier is beneficial. The smaller customer base is not only made up for by the higher prices, but also the lesser overall customer acquisition costs and the typical lower cost to support this smaller group of customers, lots of whom may have staff of their own to field some of the basic support questions, before hitting up GitLab's support team.
But it _does_ make me sad that there's just no step in-between. I don't need to be a complete free-loader, but you quickly exceed the 5-user limit of the Free plan, after which $12x12=$348 per user/year is a steep jump up, for which I wish (and have pleaded with them) there to be an intermediate option.
And this is when Microsoft swoops in at the executive level and starts offering massive 1/2 year volume discounts including freebees like GitHub. Easy sell... or so I've heard.
> Over the past five years, GitLab Premium added more than 400 features, leading to improved cycle times, enhanced developer experience, and better collaboration for our customers.
Great; now instead of half-baked box-checking features just pulling dev time away from making their features fully functional, they're also used to justify making the product half again as expensive. Now I wonder: Does GitLab actually believe that their features are 5-8x as valuable as GitHub, or is it just a cash grab?
Right. But the irony is, normally compared to how bungled Microsoft acquisitions are, it seems Github is allowed to continue mostly independent without a lot of oversight? At this point, though still skeptical, it seems to me that Github is not quite beholden to Microsoft and is actually innovating and adding new value.
I totally jumped to Gitlab when the acquisition happened and recommended it to everyone. But now I'm back to thinking Github is the best choice.
The biggest thing for me was free private repositories, which I believe Gitlab forced Github to put into place due to competition. Github has been on its way back up in my evaluation ever sense.
There's only a couple of missing features (for me, anyway) if you self host compared to the premium licensed self-hosted version (which, insanely, is the same price as the SaaS product!):
* CODEOWNERS
EDIT: Not true anymore! -- ~ * Protected branches (IE; preventing people committing to master/main) ~
* Approval Rules in merge requests
* Merge trains (auto-merging if another merge request depends on another).
Not trying to excuse the behavior but from what I've heard talking to other SaaS vendors... self-hosted is often priced similarly to the SaaS offering because even though the hosting costs are paid by the customer the support costs are often much higher.
I'm sure the hosting costs are a rounding error for Gitlab for the vast majority of ("cloud") customers. Knowing how big some repos are, storage is probably their biggest cost... and, coincidentally enough, they charge for that a la carte!
I did a quick Slack bot that messages a channel with open merge requests every morning. I really wanted to show the approval status, too, just as a reminder for someone to go "oh, that's approved, I should go merge".
But the entire approval-related API fields are deliberately removed on free tier, not just the web UI "require approval" functionality. I found this to be pretty heavy handed, especially for a self-hosted instance.
Gitea had issues a few years back with mirroring many repositories at once, deadlocking and remaining that way until it was reinstalled, essentially. It led me to believe it's not the most stable software but I would imagine it's improved quite a lot over the years.
It is extremely simple and easy to set up, though, and works well as both a private as well as a publicly hosted instance out of the box, depending on how you configure it.
Actions are mostly still in beta with 1.19, disabled by default.
In general, one big thing that's been mentioned is that our actions don't currently support things like services (among other things), so while they are good for a quick CI, they aren't quite ready to replace a full CI system yet.
Thank you - just set up some simple tests leveraging postgres - so I guess we can't jump to gitea w/actions just yet. Still, I'd never had guessed the feature-gap was this close. Exciting!
How do people like sourcehut.org for open source projects? For startups? For established "enterprise"?
I overall like GitLab for startups, especially since I can do my own flavor of Kanban with the scoped labels feature of their Premium account. So I'm leaning towards also moving my personal open source to gitlab.com, just to simplify. I would've already moved, but gitlab.com's CloudFlare setup is blocking my Firefox. And a couple times now GitLab has changed the pricing dramatically, and I won't like surprises like that after I've invested many hours to move there.
Now that I think of it, that's maybe not a terribly bad idea for some open source projects in which I want a little friction to submitting patches. (Because, for those projects, I actually dislike patches. It's usually more work for me to review for design and code quality than to make the changes myself, if they were good changes at all).
And there's the mess when people are driven by email notifications for Git repo changes/events that they then access in a Web UI. It's great for wasting people's time, and people also end up with piles of Git repo emails that they casually archive/delete, potentially missing things, due to DRY violation and because there's more steps between looking at the email and going to the Web UI to handle things.
But when you just want random people to be able to log into a Web site and interact with whatever computer-mediated workflow there, telling people to use old-school email is maybe counterproductive.
Personal anecdote: I recently looked at the Gitlab pricing / model, in particular for on-premise hosting, as we came across Gitlab booth at a show. I wasn't very happy with our solution so an alternative would have been really welcome. I was so confused by the many redirects and feature lists on the page that we decided to ask a representative there to explain it to us instead. If I remember correctly the outcome was that if we host it ourselves we pay 100$/person/month.
What surprised me was how surprised the representative was that there is absolutely no way I would be able to convince the CFO to go from 0 to 100$/person a month for a bit of convenience. Apparently, quote: There are many who are happy to pay that. - WHO AND WHY?
Granted we are a large company but we went from GitLab's Premium to the Ultimate. The Ultimate was the $100/month per. We found the aggregate cost of the solutions, maintenance, infra, time, etc., that made up what Ultimate offered was far in excess of we were going to have to do. BTW, they will likely negotiate with you if you like the capability but not the cost. Per the other users comment, if its self hosted, Gitlab should be more flexible with the pricing. My 2 cents. :)
Gitlab's pull request functionality is inferior to both Github and Teams. We use them because their Kanban is nice and they're a bit more "one stop shop" than Github, but this pricing change doesn't make sense for us.
I don't work for GL but I'd be interested to hear what you think makes the GL pull request functionality inferior (my guess is you're going to say the number of "actions" available that target the GH API but it's just a guess)
Typing out 85 review comments and having them swallowed by a 500 response because the frontend thought that of course XHRs are always 200 OK, why wouldn't they be? is indescribably infuriating
It "saves" them in that they are persisted on the server (as best I can tell) but the sequence is
1. POST /review/temp
1. POST /review/temp
# all done, submit the batch
1. POST /review/submit <- 500 Oops we sorrwweee
# now every comment is gone
I don't recall this second whether the actual sequence is "POST" followed by "DELETE /review/temp" meaning this is 100% a JS bug or whether it's "POST" and the controller for submit nukes the temp version, making it a ruby bug
And yes, "extremely pissed" isn't strong enough but ... put it on the list of the other 48,000 issues, I guess
Thank you for your suggestion. I don't want to locally clone every project and then checkout every branch of MRs assigned to me just to work around their XHR issues
If I had more energy, I'd try that on some big MR to just to find out whether their stupid extension also just assumes all XHRs are 200 OK. That'd be some icing on the cake
Did you notice Github's improvements to "projects" over the past couple years?
I feel like they missed doing a big announcement, cause it was like gradually implemented as a "beta" and then slowly filled in. But it's much better kanban now. Might still not be as good as gitlab's, I couldn't say.
Free tiers have already been reduced. There are already new ways to make $$$ e.g. the faster runners. What justifies the price increase? Sure you have new features but you also have better scaling from more customers.
Meanwhile is this a hint for Github to also increase prices? Hm.
It was already $228 / year for GitLab vs $48 / year for Github. This rate hike raises it to $348 vs $48. I don't think anyone at Github is currently too worried about prices.
The pricing of Gitlab already got pretty insane on the upper tiers for a large business. I regret ever advocating for them with how expensive they are becoming.
For me it was less the increase in price, what was bad enough, and more the shifting of functionality to higher tiers and basically the evisceration of the open source version.
I would instantly subscribe if there was a 10$ subscription per month. I don't need all of the premium features. A simple Basic+ with more speed and storage would already be a fine deal.
Out of curiosity, have you looked at some of the other hosted copies of GitLab? They have "marketplace" listings in AWS, Azure, and GCP, and I'd bet other cloud providers have a similar "click button, get GitLab" setup. This train of thought presupposes that the $10 you want to pay is to have someone else run the compute, "s3", database, and runners for you, versus "self-hosting"
I bet I'm going to regret sticking my nose into this, but:
If one thinks of the money GitLab is being paid as compensation for domain expertise, then accepting community implementations sounds fine. Someone took the time to implement a feature they found valuable, distributed under the MIT license, and GitLab didn't have to spend sprint points on implementing it, only on reviewing it for applicability across the supported use cases, congratulations: free code
A reasonable counter-argument would be that GitLab needs ongoing money to do ongoing ownership over any such contributed feature, but that's true of every one of their MRs, enterprise feature or not
Rarely do you pay based on actual cost, everything has price discrimination, loss leaders etc.
Look at BMW's heated seat subscription, those who want them are subsidising the cost of fitting the unused parts for those who don't. But if that cost is low enough relative to their income, they don't care.
It would cost Tinder next to nothing to give everyone unlimited super-likes, but they make a lot more money charging for them than they would charging everyone a flat fee (network effect++ / ladies' night for the 21st century).
I'm not sure I like where all this will end up but - GitLab are hardly the worst offenders.
Those comparisons are not apples-apples since BMW and Tinder do not publish their source code under MIT licenses and invite contributions from their users. There is no self-hosted Tinder that serves as the competing "if you don't like our pricing, then start your own MyGitLabHosting.com"
I hear you about "not the actual cost," but in software engineering -- to say nothing of SaaS offerings -- pinning down the actual cost per byte served or committed is incredibly hard
Maybe GitLab is trying to see how much they can tighten the thumb screws before LONG STANDING advocates like me jump ship, and I'm sure the switching cost of a lot of their customers makes it akin to ransom, but for others they have deep enough pockets that they'd eat the switching cost out of spite and those fish may be big enough to swing their stock price the other way
They're not really open source, they're open core which is a little different. Sure, their core's license is open source compatible, but their philosophy is definitely more about stratifying between free and paid.
I didn't say Gitlab is an open source company, which is a very specific term with a very specific meaning.
Does a mission statement starting with "Since the beginning, we've been firm believers in remote work, open source, DevOps, and iteration" mean they're focused on open source or not?
It's strange how you're asking questions to make your point instead of just stating your point outright. I initially thought you genuinely didn't know so I answered you, not knowing you were simply being sarcastic instead.
And my point which you seem to have missed is, it never matters what anyone or any organization says, the only thing that matters is what they do, therefore assume and act accordingly
Is it surprising? They increased the price of their primary product by 30% - so it should follow that their revenue should also increase by some similar factor (modulo whatever percentage of revenue is from CI minutes or the other plans which didn't increase in price, like - notably - the enterprise plan which is still $99).
Based on their last Quarterly Earnings report [0], it looks like subscription revenue is on the order of 10:1 compared to other revenue.
Even if they lose 30% of their premium customers as a result of this change, they still come out ahead on revenue (and even further ahead on earnings, given the smaller userbase needed to maintain that revenue).
Not great for new premium user acquisition though.
I have raised this issue internally and we will contact our vendor to work with them on having those IPs removed from the block list.
Those IPs are only in use by us, so blocks targeting other Cloudflare properties should not have affected our IP.
Well that is a cloudflare ip address. These IPs get used by an enourmous amount of different websites. Blocking cloudflare IP adresses is very useless, it will block access to many other sites and the page that they wanted to block has probably another IP address by now/for someone on the other side of the world.
Premium is already expensive considering that GitHub enterprise is $40/user/month and has many more features.
I’ve been following a number of open tickets and certain things I consider pretty basic features aren’t possible at the moment. You can’t block merges that aren’t up to date with the target branch, and merge trains are “too clever” a way of doing that. You can’t block people from being able to reveal secrets in the CI system.
I have often wondered why people use things like Jira, Gitlab, Confluence etc when there are better, simpler, cleaner, and more stable alternatives are available. I always assumed it must be that these are much cheaper than the alternative. Or a compliance need to install things and keep data on your own infrastructure.
gitlab is pretty nice mostly because of the CI system and runners, the groupings of things, the permissions (deploy tokens etc;) and the way it handles merge requests.
Jira is used mostly because it's "okay" at doing things the agile way, it's impressive how few things actually have the concept of a backlog or sprints (Asana for instance has neither despite costing 4x as much).
I can't honestly find a decent replacement for confluence that would allow non-techs to also write documents. :\
I would hate myself for saying all this 4 years ago, but unfortunately I am now in a position where I have the ability to inflict my personal tool choices on people and these are the least bad options sadly.
PM for Bitbucket pipelines here, my team of ~20 owns that feature E2W, would genuinely love to chat, share some stuff we're working on, and get feedback/thoughts.
Ping me if you're open to chatting emunday@atlassian.com
I'm glad you're working on BB. We switched to GitHub a year ago and are happy with it, but with a slightly better UI and more reliable/advanced CI/CD features, I might not have been able to justify the switch.
Bitbucket used to fall over for monorepos. Sometimes it would fall into a death spiral, sometimes it would attribute PRs and commits to the wrong engineers (!!!) Not sure if that's still the case, but it was awful working with it.
Don't even get me started on the dumpster fire that is Jira.
We 100% have had issues with larger repo's in the past while we were still hosted on a stand-alone data centre. Since finishing our migration to AWS ~12 months ago, all stability and performance metrics are substantially improved.
Full disclosure, we do still have some work to do in terms of supporting very large repo's (>10GB non-LFS) - but those scenarios are still handled relatively gracefully.
Just an FYI - we (Bitbucket cloud) recently shipped changes to the PR experience (rebuilt the PR diffing algorithm) which has increased the speed by ~95%.
100% aware we still have a way to go on performance, but we're literally orders of magnitude faster than even 12 months ago, with another order of magnitude on the cards this year, especially for larger customers (250+ users).
Can you please share why you don’t have a file list on a left panel (like in IntelliJ, Windows Explorer or even Bitbucket DC) while reviewing PRs? Do stats show that people prefer to be shown a long diff with a tiny tab on the top-right that shows the list of files?
Wouldn’t that be a UX worth improving? (For us, we’ve attempted the move 3 times, but developers keep rejecting BBCloud because of the annoying UI - mostly the missing treeview to navigate files).
To be 100% honest - I don't have an answer for you on that. My teams focus primarily on CI/CD and the new extensibility tooling we're building (allowing customers to basically add their own features specific to their use-cases, like the plugin system for Server, but simpler).
If you shoot me an email I can connect you with the PM who manages the PR experience directly - they're doing a lot of design work in this space and would be really keen to talk.
You still don't have basic features like Syntax Highlighting in Diffs.
Yes yes, you are promising it soon in an Experimental Labs release, but it's been 11 years. It's laughable and who knows if that will tank performance again.
You had a solid PR tool on bitbucket server and somehow took that and made it 100x worse on Bitbucket Cloud. The File picker and the way you navigated between files with keyboard shortcuts were GREAT.
Bitbucket Cloud is just a copy of a really old version of the Github PR viewer, but with a lot more problems and no updates.
GitLab has probably 5x as many features as Bitbucket. For example you still need a ticketing system with Bitbucket (Jira), but not with Gitlab since its issues system is self contained.
I use Bitbucket at $job. They do have CI/CD now, it's called Bitbucket Pipelines. It's not bad, not great. For better or worse, I always measure version control hosting against GitHub which is still the king in my opinion. There are so many little things that GH has which BB doesn't. When you add them all together, it's easy to see why you'd want to switch to GH or something similar.
Examples:
GH lets you write comments/feedback on a PR and then submit it (sort of like staging the comments) in one fell swoop. With BB, each comment triggers a notification to the PR author.
GH has draft PRs. Debatable how useful these are, but people definitely like them on GH and that's not an option on BB.
GH has built-in support for Mermaid in markdown, BB doesn't and won't ever.
GH Actions generally seem more flexible. BB, for example, doesn't let you call a custom "Pipe" when using your own Mac OS runner in BB Pipelines — something you need to do if you want to build Apple projects — which is just a strange and frustrating limitation.
There are so many other things. In general, BB is just slow and janky as almost all Atlassian products are. Every time you click to complete or submit something, you just experience slowness.
I'd switch to GH in a minute if we could, but our team already uses so much other Atlassian crap that we're kind of stuck with it at the moment.
I'm using BitBucket at work and it seems like it's no longer "one comment - one notification". When adding the comment to the PR there's "Start review" button, so and at the end you just click "Finish review" and everything goes as one notification.
PM for Bitbucket pipelines here, my team of ~20 owns that feature E2W, would genuinely love to chat, share some stuff we're working on, and get feedback/thoughts.
Ping me if you're open to chatting emunday@atlassian.com
I use it (old self hosted and cloud. Also GitLab and GitHub on a regular basis.)
BitBucket is ok.
It doesn’t have nearly the same feature set as the others. You have to bring on more of the Atlassian ecosystem to get those. The integrations with stuff like Jira and Confluence are solid of course.
The features is does have are well implemented I feel. For example, the PR review UI is great. It is almost as good as GitHub’s and worlds better than GitLab’s. It has great access control that is probably a better fit for enterprise environments than the competition (another area where GitLab is lacking IME).
BitBucket added CI/CD. I’ve used it only for one project. It got the job done, but was worse than the others.
PM for Bitbucket pipelines here, my team of ~20 owns that feature E2W, would genuinely love to chat, share some stuff we're working on, and get feedback/thoughts.
Ping me if you're open to chatting emunday@atlassian.com
We use Bitbucket Cloud. About 250 repositories, 50-ish with CI/CD functionality. It is sloooow. In 2022 there were more than a few outages. Very annoying. And this year so far I had issues onboarding a new colleague due to invitation emails not being sent out.
Other than that it's cheap by itself, but count in developer hours spent just waiting, and it's suddenly not so cheap after all.
PM for Bitbucket pipelines here, my team of ~20 owns that feature E2W, would genuinely love to chat, share some stuff we're working on, and get feedback/thoughts.
Ping me if you're open to chatting emunday@atlassian.com
PM for Bitbucket pipelines here, my team of ~20 owns that feature E2W, would genuinely love to chat, share some stuff we're working on, and get feedback/thoughts.
Ping me if you're open to chatting emunday@atlassian.com
We will definitely have to think about moving. This just makes no sense at all. At least there's a transition phase with 24$, but that's already stretching it. Yes, they are adding features nobody asked for like crazy, just to be able to check more boxes in some feature matrix. Meanwhile, absolute basic stuff is simply not working or buggy as hell. Whenever I encounter a new quirk, I usually google for it and almost always find some years-old issue that is rotting away. "Advanced" search is completely useless as you can't really search for code. The whole CI/CD stuff completely falls apart once you scale things up. Just creating the pipeline takes literally minutes. When running a pipeline, I have to reload 10 times until I finally see the job variables (at least that one will FINALLY be fixed in 15.9). No good overview of what runners are busy with, no priority on runners, although why am I complaining about stuff like that when you can't even FILTER JOBS BY NAME. And don't get me started on the self-hosting stuff...
There was a time when GitLab was superior to GitHub. This is clearly no longer the case. Not a good time to increase prices.