Just got an email from GitLab about a group I'm part of that has more than five users. The docs linked says "For existing namespaces, this limit is being rolled out gradually. Impacted users are notified in GitLab.com at least 60 days before the limit is applied.", however upon checking the group in GitLab, we are greeted by a big red box stating "Your top-level group [group] is over the 5 user limit and has been placed in a read-only state."
Also got an email but interestingly the most populated group I'm a member of has 4 users in it including myself. It did mention that my "top-level" group has reached the 5-member limit but it references a numerical ID that doesn't match my user or any of the groups I'm member to.
The gradual roll out of this change started with a blog post[0] and included in-app notifications for the owners of impacted groups on GitLab.com.
If the group owner did not log in during the in-app notification period, they were then emailed (the email you received today) notifying that the group was impacted.
I don't know that it's a great plan to do a blogpost and in-app notification as the first round of reminders and email on the day of the change. Both the blogpost and in-app notification requires you to explicitly go on GitLab and see there's a problem. Maybe there's a reason to avoid it, but emailing from the get-go seems like it is the right move for transparency and not rug-pulling.
Wouldn’t it make more sense to email them before they were impacted instead of when they were impacted? What’s the point of gradual roll out that requires I read your blog etc. An email that says “You have 60 days to X” is a lot more effective than one that says “60 days ago we made a blog post letting you know, and now you’re f’d.”
Look they announced it publicly posted right in the back of the file cabinet in the basement behind the warning rabid tigers sign.
Here's a question for Gitlab: "Why did you require me to give you an email address to sign up?"
The answer to that question means there is no explaining why they didn't use it first, and followed up with at least a couple updates along the way. This is exactly what the address exists on thier db for.
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
> If the group owner did not log in during the in-app notification period, they were then emailed (the email you received today) notifying that the group was impacted.
I think there is a glitch in your mail or something else is going wrong. I'm currently not in any groups and still got an e-mail telling me that my top level group (starting with 5060) has reached the 5 members limit. Searching for the group also doesn't yield any results whatsoever.
i got an email that the limit in one of my groups is reached.
i just logged in and there is no indication of any limit.
i had to step through every group to find out where the limit was reached.
turns out that there was one group that had two sub groups which added up to 5 members. at the group overview this is listed as "two" (for the two subgroups). it would be very helpful if the group overview (https://gitlab.com/dashboard/groups) would list the total number of people as well as flag every group where the limit is reached or crossed.
but, you say the limit is 5 people. in this group there are exactly 5 people, yet the warning claims 'Your top-level group is over the 5 user limit and has been placed in a read-only state.'
how can that be? 5 is more than 5?
it doesn't matter in my case because this is an old project no longer worked on, so read only is fine, and there is no need to act, but i think you need to work on your system because i am sure there will be more cases like that.
lastly i want to add that while that limit is fine for small businesses, it is an absolute disaster for FOSS projects. FOSS projects don't have the funding to pay for your service, so they won't. their only option is to leave. if any of my projects get any traction then i have no choice but to go look for a more FOSS friendly service. i thought gitlab was that, i wanted to make a point against github and support their most likely competitor by drawing attention to you.
gitlab really does not gain anything by enforcing this limit for FOSS projects. FOSS projects often have many members that are not very active. a busy startup with 5 members probably creates the same activity and uses the same resources as a FOSS project with 50 members because most of those 50 members rarely contribute to the project.
or instead of limiting members, limit how often the more expensive resources are used. like limiting how often the CI is running.
i urge you to consider to allow a higher limit for groups that only have projects that use a FOSS license.
thanks, i wasn't aware of this. that's even more than i was looking for, except, the no commercial activity rule seems a bit limiting:
Not seek profit: An organization can accept donations to sustain its work, but it can’t seek to make a profit by selling services, by charging for enhancements or add-ons, or by other means.
so i can't sell services to sustain the project? there is a large difference between earning some money to help fund the project, making barely enough to be able to work on the project fulltime and actually making enough of a profit to afford commercial services.
if i am employed and work on a FOSS project on work time, then i am not selling any services, nor am i making a profit.
if i do exactly the same but as a contractor, then i am selling a service.
you may want to elaborate how you interpret and verify this rule.
also i'd rather have less free services but a more liberal allowance on commercial activity. like a regular free account but without the user limit.
user limits are very frustrating because they prevent me from managing all potential contributors, even if they are not very active.
I did receive an email too which just had a number mentioned that wasn’t even hyperlinked to anything. Turns out I am or was not part of any group ever.
This applies to the SaaS Gitlab ONLINE. This doesn't apply to Gitlab you install on your hardware.
I mean, online resources on other peoples' servers cost money.
A better law would be to forbid "free" offerings by companies. They all are fraudulent "free", since you pay a commercial entity with either money or data. And, corporate "free" rarely stays free.
(This also doesn't have to be a new law, but application of false and deceptive advertising relating to the FTC, around the term of "free".)
The real world is way more nuanced than this. Many "free" offerings are not monetization through ads or likewise, they are marketing strategies, and they're good for both company and consumers as they allow evaluation periods with no committment, and in some cases use the business/enterprise revenue to subsidize individual users, which benefits individual users.
Free offerings are a marketing expense via extended trial run. It is more productive for society to give away limited product offerings at little marginal cost than to put the equivalent into more advertising, salespeople, and influencer campaigns.
If I want to find out which git hosting to use, it would be great to try out Gitlab, GitHub, and Bitbucket first (and everyone else try them) so we could assess genuine product usefulness as a group rather than rely on Twitter ads or astroturfing here (no bearing on product)
You can excuse or justify it however you want. But it's still false and deceptive advertising to use "free" in situations like this.
To say some service is "Free" (for now) means you're paying something that isn't disclosed. Even if you're paying in time as beta-tester, you're still paying. And you're still paying in data.
Whereas, GitLab on-prem install is largely under MIT license, which is widely considered to be a very permissive license. I could see the FTC coming to similar agreement with that statement.
Demo is interesting, although it nearly always implies limited functionality and/or limited timeframe you can use the software, which may be misleading for some free tiers.
Freeware could be a good term, but wouldn't it still have the same nothing-is-free issue that GP brought up calling it "false and deceptive advertising"? The term certainly doesn't connote the "why" behind the offering
or they use "free" to nuke competitors from orbit, salt the ground to ensure nobody can get a dime for a decade in this industry, hoard all the expertise then increase your pricing by orders of magnitude like it happened with Google Maps.
We used to enforce monopoly regulations, and similar types of anticompetitive behaviors that kill swaths of markets. And that's exactly what happened with what you described with Google maps.
This scheme is basically dumping, where you (a company) lower the price of your good and then flood the market to kill all competitors. Then when they're good and dead, you jack up the prices to extortionate levels and sit back and get piles of money, from people with no choice.
The last big antitrust push we had was against Microsoft. And after the judge was replaced for improper communication during trial, MS and DoJ settled. Basically, was a huge case then "Oops nevermind".
I'm incredibly pleased about Microsoft's acquisition of Github, as I notice visible improvements every passing month. Considering Gitlab's pricing, I wonder why anyone would abandon GitHub Team or Enterprise plan in favor of Gitlab. Gitlab's costs are exorbitant, and they resemble Atlassian products, with an overwhelming number of features that are rarely used, cluttering the interface and diminishing the overall user experience.
I am not pleased with Microsoft. Yes, there have been some improvements. But GitHub Actions is very half baked, yet the bean counters at my company are asking "why do we pay for buildkite?". It feels like they are using the same playbook as MS Teams.
- You can't retry a failed action, be it manually in the UI or automatically under certain conditions.
- workflows have a pretty low limit for number of jobs - 250 or so. We already split our rspec tests across 300 parallel jobs.
- the UX is full of jank. If I click into an in-progress jobs I often can't see prior logs for the in-progress step until the step completes.
There are also some annoyances that aren't really half-baked, but annoying for Monorepos:
- workflows have to be defined under the .github folder. This means workflows can't be collocated with the code they relate to.
- workflows can't be generated dynamically. At best, you can dynamically trigger predefined workflows, but I don't think they get associated with the PR that triggered them. This makes patterns like dynamically dispatching workflows based on, say, a bazel query for affected rdeps more challenging, if not entirely infeasible.
You can retry failed jobs these days (for awhile now, at least a year? I can't remember).
Workflows can also be (sort of, depending on what you mean?) dynamically generated by using tojson and fromjson to feed the output of one job into a matrix.
Full disclosure, I work at Microsoft but nothing to do with GitHub.
One area is its reusability story. Last I looked you couldn't create reusable actions in the same repo you want to call them from, they have to be in an external repo. For quite a while, private reusable actions were an Enterprise-only feature, but that may have been lifted now. The ability to reuse particular jobs is also missing, and communication among jobs is limited to variables after the fact. You can only use success or failure states to trigger other jobs, you can't pass values.
> Last I looked you couldn't create reusable actions in the same repo you want to call them from, they have to be in an external repo.
I'm not sure if/when this changed, but you can definitely do this now.
> You can only use success or failure states to trigger other jobs, you can't pass values.
This is also not true: you can pipe environment variables to $GITHUB_OUTPUT which can be referenced by future jobs.
If anything, the main issue with GitHub Actions is that it's confusing, and the docs don't make it easy to understand how to do things at a high level.
Interesting, I'm _extremely_ happy with Github Actions. But I have pretty basic needs, admittedly.
You mention buildkite as something you think is a lot better than GH Actions. I'm curious if you've also used the Gitlab equivalent and can compare (I haven't, really).
I would not not say buildkite is better, per se. I'd say it's more mature and much more flexible. Buildkite is easily "programmable" in a way that GHA is not. That flexibility is important for advanced/large scale use cases.
IMO Gitlab's offering is far more comprehensive and can't really be an apples to apples comparison.
Plus, I greatly appreciate the transparency of many of the features that Gitlab sells around security outlining exactly which open source tools they use so that you can just go do it yourself on the CI pipeline. The real value for the premium security tier is when you have a team coordinating multiple projects.
I've seen Github try to upsell to enterprise with features that I can just install in a few minutes using the tools that Gitlab tells me about.
I dunno, gitlab looks more comprehensive if you just look at a checklist "do they have feature X, Y, Z?" but if you look at depth and quality of implementation a lot of their features fall apart. Even issues, which seem like one of the top 4 things they do (git, MRs, CI, issues) are fine for simple stuff but fall apart after that (Have you ever wanted to search for an issue based on something mentioned in a comment on it? Good luck!).
They're also buggy, and in my experience I keep hitting bugs that are long-tail and therefore never prioritized to actually fix.
Well said and matches my experience as well. A breadth of features but once you start actively using them in depth you find that the experience is not as polished.
Agreed - I'm working at a place that's switching from GitHub to GitLab because it's cheaper (or was when the project was started; maybe still is because GitLab can replace a couple of other tools as well). The checklist looks impressive but I find myself thinking "GitHub does this better" a lot of the time.
To be fair, this has changed considerably over the last 10 years.
GitLab was drastically cheaper, offering free private repos, and interesting features ahead of GitHub (although IMO always slightly less "sexy" than GitHub, using Ruby on Rails, etc.).
But at the time they gathered (1) serious funding money and (2) influx from MS-asylants their priorities started to change. But they were still the cheaper option for quite some time IIRC.
The pandemic and the associated gold-rush/growth in IT pushed the dynamics over the edge I think.
Now their position is not really that different from GitHub's, and I think it is kind of a preference thing.
I can do with both, but I kind of still like the appeal and UX in GitHub. GitLab will always be in my heart, just like ever "Underdog" (even if that was a long time ago).
I could further see myself immediately falling for a third alternative, if it was sexy/unique enough with drastically better UX, and I think that is not even too far fetched.
But there is the thing, GitHub is a platform, not (just) a tool. GitLab still managed to take ground - kudos! That would be the hard part.
It's actually fucking crazy how expensive GitLab is in comparison to GitHub.
Let's say we have 40 employees who code and 30 employees who create tickets, and we want to get all of the security scanning features that the platform has to offer.
For GitLab, we need the $99/user/month plan because the security features are only available in that subscription. Guest users are completely free, but they're extremely gimped when it comes to issues, so most likely you'll have to have most if not all of your non-coding employees at the $99/user/month tier. Final price is $6930/month (or $3960/month if you can really handle the gimped guests).
For GitHub, you need to pay $19.25/user/month plan for every user and $49/month for every person that commits code for the security features. So that's $1347.50/month for user accounts and $1960 for security features for a total of $3307.50/month.
GitHub is not even half what GitLab wants. It's even less than the gimped guest user experience that you can subject yourself to with GitLab.
I still use gitlab primarily because of the CI system. Still haven't found any competitors that are as easy to use and integrated as gitlab CI.
Github actions are still lagging far behind.
> The VSCode situation could be improved but isn't there VSCodium to remediate that?
That's a great example, actually, because they'd like you to think that VSCode is open source... but then if you actually use that you can't access a rather lot of the most useful extensions, which is a completely artificial limitation that appears to be there only to prevent people from actually using any fork.
VSCodium is specifically incompatible with Microsoft's proprietary extensions like SSH development, and now the official VS Code Python extension has now switched to a proprietary Pylance language server.
I also couldn't find sources to care to respond to him but I remember about some little terminal app which FOSS code was basically stolen by MS from the indie dev and then he was gaslighted about it. I can't find the source in reddit thanks to the going dark thing now lmao. Can't find it now, so maybe I hallucinated it better than some fine LLM's
If anyone else remembers this incident and can link to a source that'd be great for my sanity.
I do have a love-hate relationship with MS, but I don't love the fact that they own 80% of my stack (Yes, I know, my choice) between TypeScript, VSCode, NPM, Github, etc..
Also on VSCodium, it only fixes the telemetry bullshit, the custom LSP Plugins that microsoft keeps for themselves or whatever are not available there. so If you want to use for example copilot or other -microsoft official- plugins you can't do so on VSCodium
Also let's add the whole Github Copilot WhiteWashing non-FOSS proprietary code into anyone to steal. Basically breaking the current status quo in favour of the megacorps that can steal it all and respect no licenses
I think there's enough recent events pointed by other commenters to at least be able to say with certain grade of truth to it that Microsoft isn't the biggest friend of FOSS as much as they pretend to be with stuff like WSL or whatever
What surprises me is that the tech crowd is so ready to bend over for one of the worst companies on the planet in the software domain. These are the very same people that abused the legal system in every way that they could in order to slow down the adoption rate of open source. They are still doing this today but quietly, for instance by incentivizing municipalities and other government layers to use their software (for free if necessary) just to stop adoption of equivalent open source solutions.
I'm not trying to be difficult, but linking to a lengthy Wikipedia page is not an argument. From a quick glance a number are old, and a number are just non-issues (e.g. "Mono patent concerns", which was just some baseless FUD mentioned by Stallman once almost 15 years ago), but I didn't read the entire page. "Incentivizing municipalities and other government layers to use their software" could just be normal business practice (or something shady – much depends on the details).
One recent example would be to trample all over the rights of the open source contributors to github hosted repositories by using their code to incorporate it into Copilot, irrespective of the licensing details. I'm sure that counts for nothing in your book but for me taking open source and using it without attribution shows that MS hasn't changed one bit, they simply see FOSS as another resource to be monetized.
As far as incentivizing municipalities is concerned, they are currently in the docket for anti-trust violations just like they were in the past. Historically MS would swoop in on any governmental org in Europe that would successfully implement FOSS solutions instead of MS based stuff. Not to make money, but just to maintain dominance, another anti-trust play. And they never stopped doing that.
Their pricing update end of last year was one of the reasons we switched over to Github.
Other reasons were, that most external services had integration with Github but not with Gitlab, or that we didn't use many of the features Gitlab provided but charged for.
If they would provide some lite plans with custom feature addons, we might have kept it, but all in all there was not much difference between Gitlab and Github except for the pricing then
I've said it before and I agree with this comment. Their pricing structure is just too aggressive for smaller teams and I think they missed out on capturing a market segment. Maybe they determined it would be unprofitable to support small teams or something but I would have happily kept my team on GitLab if there was an ala carte or "lite" option like you suggested. Instead we also ended up on Github (as paying customers).
For small teams which were happy using the "free" tier, that's really the correct solution. Just self-host it and retain free-tier functionality.
That said, it looks like the premium features are $29/mo or $99/mo per user regardless if you self-host it or take advantage of their managed SaaS offering. It's somewhat bizarre - there's a lot of costs associated with managing this on-site but no discount for that. I presume they feel that extra overhead cost to the customer of self-hosting breaks even with the perceived or actual added security value of self-managed installations.
We actually did self-host the community edition for several months using the omnibus version (some features you still need a license for that is same price as hoested). After initial setup it worked okay and was mostly hands-off except for that the performance started to degrade slowly over time. After spending a few weeks digging into the internals and failing to solve the problem we felt that we were better off just switching to a hosted provider. In this case we switched to GitHub because the pricing was better for the features we needed.
Yup. If I could say something like "I'll pay $12/year for a public repo, but don't want a wiki, container ecosystem or bug tracker" that would be great. Heck, I would pay $36/year for that. But I'm not paying $29/month/user for all the features I'm not going to use.
SourceHut seems like it will someday be a competitor, but I'm frightened away by it's "alpha" state.
Maybe there's a market for something that's more ala-carte?
$12/year/repo? No, that is way too much. I would rather selfhost at that price point. With the number of repos I have that would be a ridiculous price. I don't use the wiki or the container registry so it is largely text file hosting at that point.
And of course, github is owned by microsoft, so at some point it'll probably be bundled into their Azure/Office/Microsoft 365 nonsense. Then it'll be a no brainer to buy it because you'll already be getting it whether you like it or not.
I don't know if I see that happening. They'd either have to either give it away for free as part of the bundle, or raise everyone's prices. The first would be bad for revenue and the other would cost them customers that don't care about Github.
$4 - per user, with some important additional features, including SSO and merge request approvals
$19 - for nearly all the features except very enterprise/security ones
€99 - for all festures.
—-
over the last 2 years they have dropped the $4 option and increased the $19 option.
so now there is a cliff; free for 5: $29 for everything.
Not sure why I would use gitlab over github if thats the up-front hill I will have to climb: for what its worth Perforce also has almost exactly this pricing model and has the games industry by the balls, but perforce has no real competitor.
fwiw I am a gitlab user for 10 years and have advocated for its use, the only reason I haven't migrated off at this point is the switching cost
I'm currently hosting a git repo on my home machine and it's used by me when I'm on the road and a few people I trust enough to have logins on my DMZ machine.
It seems there should be an easy way to use gitlab or github as a public read-only proxy to changes that are released on the private repo. And then going the other way, sucks up PRs from public sites and lovingly integrates them into the "real" repo on my home machine.
Yes. There are security ramifications. There are availability ramifications. I seems slightly to be trying to skirt GitLab's policies they're probably putting into effect to avoid going bankrupt. But the flip-side is I really don't need a wiki or a bug tracker or whatever else GitLab is working on. I would pay a small amount of cash to just get a public repo mirror.
And we all have different ideas about how to make this "easy". I don't mind running scripts on my local host, but would like to avoid polling the public repo to see if someone's posted a PR. I also don't want to have to run a script in a container on the public repo. So would love it if you could set the public repo to proxy PRs to a remote repo.
Just curious if anyone else has similar requirements. Maybe you have a corporate repo and want to mirror it to a public site like GitLab, GitHub or SourceHut. Maybe, like me, *you* just want a remote repo to stash your code but a public location so your home server doesn't melt down that one time someone slashdots your project.
It’s not that hard to setup. It’s a built-in feature in something like gitea. Or you can write a `git push` cron task or a server hook in git to keep the 2 in sync. GitHub is full of mirror repos. You can also disable issues, discussions, wiki, and pull requests if you don’t want to deal with that.
If you’re polling, you can use GitHub APIs. They are pretty well documented. If you want a turn-key solution, use gitea. Depending on how flexible you need it, gitea might cover your scenarios. But you can have actions in gitea as well that automate polling GitHub APIs for issues or comments or pull requests etc.
2) You can use "interaction limits" (in repository settings, under "moderation options") to limit repository interactions to collaborators. This can only be set for 6 months at a time, though, so you'll need to reactivate it periodically.
3) You can archive the project and unarchive it temporarily when making changes, disabling all activity on the fork.
Not just push mirrors but pull mirrors and push+pull mirrors. I frequently use the pull mirrors to backup repos that I don't trust to stay around (either because they might break a TOS or be right on the line, or i expect the author to not leave it around for some reason). It's definitely become one of my "must have" for any kind of local hosting stuff esp since the docker images make it basically painless to deploy.
Yeah. I don't want to set up docker. I just want the public server to mirror the PR by pushing it to my private server. Launching docker to diff the public mirror against the private server isn't completely out of the question. It just seems "inelegant." But I dislike it less than I dislike the idea of running a cron job on the private server to poll the public server.
Thanks for the suggestion, though. I may go ahead with something like this.
Thx for the response. That might be a solution. I fear that GitLab might notice me doing that and decide they don't like it. But definitely something to play around with. I'll look again on the site and see if I can see where you activate it; didn't see it first time around.
As someone who works at the Co -- If you are within the free usage limits, we are fine with you mirroring a repo on .com.
If you are hosting game binaries or Shrek the 3rd we might have some problems, but if you have a genuine source code project that shouldn't be a problem unless you become a DDoS target.
Lol. Yes. Thx for the reply. Definitely real code. I think the closest we come to "media" are a few open source fonts which we're using in accordance w/ the license.
I find their use of the word "subgroup" here to be annoying, because a subgroup under their semantics "inherits" members from the group it's included in, i.e. the cardinality of a subgroup is _larger_ than the cardinality of its parent.
> A five-user limit applies to newly created top-level namespaces with private visibility on GitLab SaaS
Any idea whether they'll eventually chip away at public-visibility open source projects?
"We're not Microsoft" might be GitLab's biggest remaining selling point. And the more savvy open source developers might care disproportionately about that. I'd think GitLab might be trying to lure open source, now that GitHub isn't the warm-fuzzy company that originally landed a lot of it, yet GitHub continues to be the de facto official provider for most major open source projects and ecosystems. Plus that has network effects for landing paying customers. Has GitLab given up on that?
BTW, I'm fine with GitLab charging for non-open-source commercial projects. If your startup has more than 5 users, you probably already have salaries in your burn rate, and GitLab is a relatively small cost, for a critical service. (See: TLC's "No Scrubs".) I've happily paid for GitLab in earlier-stage startups.
This bait-and-switch along with real uptime issues is why I left GitLab years ago. I have a personal rule of; "if there is a reasonable OSS alternative to a proprietary software, use it." Unfortunately they are not reasonable. I was even a a paying customer but they changed their pricing structure so many times and moved features around for different tiers I couldn't justify it as a business.
I've been happy moving back to GitHub post Microsoft acquisition. If I ever got fed up with GitHub I find Gitea to be refreshingly simple and does basically everything I need.
I do wish the best for GitLab though and am rooting for them. Any company that makes an OSS model work is one worth having hope for.
Question for Gitlab: Why did you collect an email address from the user in the first place? Why does it exist in your db?
Now explain why it was not used for it's only legitimate reason for existing in your posession, first, let alone followed up with a few updates as the deadline got closer.
You have a communication channel that not only is good for this, but exists for this exact sole purpose in the first place. If you aren't going to use it for that, then you have no legitimate reason to have it and I want you to delete it.
Surprisingly GitLab feels very dated. Their drive has been toward enterprise sales instead of product IMO. Nothing bad about that - but focus on product development at least as well.
We've also invested heavily in AI features including Code Suggestions which is free for all users while in beta. You can read more about the AI features in GitLab here: https://about.gitlab.com/solutions/ai/
It's UI infuriates me quite frequently, options, menus, projects all the useful things are hidden behind UI elements which requires to click constantly to reveal items. All of that while plenty of unused blank space is available on the screen, fucking dumb.
I've found them extremely unreliable both in my free account (every failure takes 1-2 mins away from my 50 minutes!) and in my employers paid subscription so we self run but run into issues with not being able to scale runners enough to meet developers demands.
Its also super annoying that you can't use your own docker containers hosted on ECR on public runners (no way to provide auth)
I don’t understand why anyone uses Gitlab anymore. In stark contrast to GitHub, it’s been an exercise in promising features which are then taken away from you, for years.
Gitlab is almost certainly the most unethical company I’ve ever seen.
IT tried to get us to migrate to Gitlab in a past life, it went absolutely nowhere. Gitlab is stupidly expensive and complicated for value that never realized.
Probably because it's a publicly traded company that needs to please its shareholder.
I honestly believe that what we are seeing is the realisation that money and growth isn't infinite and companies need to return to actually turn a profit, not just grow revenue. That's why we're seeing Reddit, Imgur, Gitlab, Meta, Twitter and others implement changes in rapid succession. It not even that I completely disagree with their choices, I just wonder why a dumb ass like myself who knows nothing of business was able to see broken business models years in advance, while Wall Street and Silicon Valley couldn't... Or did they just not care?
They came right out and told you: nobody cared if nine out of ten investments were a total loss, provided the one had enough juice to make up for it. And, "juice" is an extremely vague term here: it could mean profitability, but given that there was so much money sloshing around, usually it just meant that the stock price jumped enough for investors to cash out - but that stock price was not necessarily tied to any tangible performance, much of the time.
The real giveaway though, was the fact that stock dividends - you know, the thing that historically you buy stock for - are basically unheard of among all but the biggest companies in tech (and even unheard of among some of those). We have now an entire generation of leaders in tech for whom profitability has been this kind of abstract notion they didn't have to think about much, which explains why they all seem so ham-fisted now that they're being forced to.
Why have technology companies become so greedy all over the world these days? Is it because recession is putting pressure on their revenues or have they collectively decided that time to cash in has come now?
Money is no longer free and abundant. Simply turning free investment money into growth and possible future revenue is no longer an option for most companies. Boards and bean counters have collectively started pressuring everyone to focus on revenue asap.
It's because they are ultimately beholden to "shareholders" and "shareholders" nowadays expect continual growth. Not maintaining the "growth" will cause the share price to plummet and will eventually get the CEO fired. Furthermore, the high interest rates we have now are squeezing the hell out of margins, requiring these CEOs to look for turnips from which they can squeeze some blood.
So tldr, the greed is a result of systemic forces, corporate structure, interest rates/inflation, and numbers on a spreadsheet.
These systemic forces were always there since almost over a decade now but they always focused on growth, not revenue. Now, it's as if their cash flows are depleting and revenue is where they are focusing even at the cost of growth. Reddit is a classic example where they're not even caring about users leaving the platform and going elsewhere. They're perhaps realizing that those users are of no use to Reddit unless they can somehow turn them into revenue - which ironically those 3rd party apps seem to be doing better than Reddit itself!
Continual growth has been there for decades, what's new is a focus on this thing called "profits." Until recently the incentive structure has favored growth almost to the exclusion of anything else, at least until you got very big.
The reason so many companies are doing such a terrible job of it right now, is that frankly there aren't many c-levels in tech who are mentally equipped to think about their business that way, and even fewer who have ever been in a position where they had to. Reddit's the latest example of this: 18 years and never been profitable? And Huffman calls himself a libertarian? Good grief.
I'm glad of it. Our industry is filled with basically con-men who have no idea how to run a business profitably (or interest in doing so) but have made up for it by having the right phone numbers etc. It's good that they're being squeezed, because it creates room for people who want to run an honest business.
When will people just host their own GIT?? It’s open source and web hosting services are cheap enough now a days that all you need is a domain and an internet facing server (raspberry pi)with SELinux…
I wonder how many people even care that git is involved. I know my personal choice of GitHub has absolutely nothing to do with git. I would use it just as well if it had a different source control system. Indeed I used to use Mercurial and only switched because that's what GitHub demanded. I wasn't out looking for a git host.
Way to take my comment out of context…
Read the headline at least…it’s affecting users with free accounts. Obviously not a company and even if it was a company that small…I would never recommend “mission critical” code to be hosted in such way.
Okay fine, but replace "companies" with "people" and remove "mission critical" from my comment and the question still stands. Setting up and managing a Git repository on a Raspberry Pi in your own home is at least an order of magnitude more effort than creating a repository on GitHub or a similar service, and you miss out on all the non-Git-related benefits of using such a service.
A fork of what? If you run your own instance you have control over most of those features and limits. You can’t fork a service because what you’re getting from a service is not just the code. It’s the cheaper economy of scale operational aspects of it. It’s much cheaper to pay a SaaS provider, than to have someone on payroll that manages an open alternative of that SaaS for you. The SaaS provider can then introduce arbitrary plans and limits all they want. Do you want to start another company that resells Gitlab hosting that competes with Gitlab.com?
Last time I looked into Gitlab CE I decided not to go with it because there is no pull mirroring outside of their Premium offering, I would consider this a limit.
Limits are not features. There are no limits on number of users, number of repos, etc. etc. However, you're fairly obviously not getting any of the features that are in the paid tiers of gitlab's own offering. It's open core[1], rather than just open source.
