This is the core of the issue. A user will genuinely come to the platform for those features and then is locked in. The lock in will sometimes even cost the user more than the value of the free stuff over the duration of the collaboration by virtue of not being easy to leave.

On the other hand the companies put in the freebies with the explicit intention of attracting a critical mass of users, and most of the times with the expectation that they will be removed once that target is reached. Then some creative "moral" accounting disregards that for those freebies the users also provided something of great value - they supported the platform in rising to wherever it rose. The platform may have extracted more value from the user than the user extracted from the platform. Each one of those free users probably brought a few more with them.

So while to a point I understand the "you didn't pay so you didn't lose anything" mantra, I'm also completely aware that this was part of the long term strategy of the company and it's like hooking a fish and thinking "why's the fish complaining, it got the bait for free". A more honest and transparent strategy would be to set the expectations from the start, people can choose to take the freebie for a time knowing that at a predefined point they will cost.

And the statement that "you don't like it build another one yourself" is very biased. From the ones being at the top of a mountain supported by users who have to pay to get out, to the ones who'd have to compete with the mountain when they can only start with a hill. It's what FB will tell you when you object to their questionable practices.

A fish is unable to leave, your point is merely that it's "not easy" to leave. If you're on Gitlab then it seems pretty easy to just download your code and make an account somewhere else.

As surprising as it may sound, I think more fish manage to wiggle away from the hook than are caught. Ask any fisherman. They wiggle away with a mouth full of blood, which is what the users who have to migrate from a lock-in situation figuratively do.

Let's turn the argument on its head: GitLab can still offer the features for free, it just chooses not to. And unlike the users they have full control over the situation. GitLab decided to pull the trigger and the users have to dodge and wiggle to get away with "only" superficial wounds. That's a shitty way to deal with the situation. They could have very well grandfathered the accounts with the freebies but instead they took advantage of the situation that people have a harder time leaving than they had coming, and the power imbalance this creates.

For people on Gitlab, your point about "downloading the code and moving on" really only applies to the simplest point of use on Gitlab. Anybody using Gitlab's CI/CD pipelines has everything in their repo(s) fully setup only for that, and not for other CI/CD offerings. Moving their stuff is often much much much more work than "just download your code", and sometimes with time/money constraints, completely infeasible in the short term.

Your comment brushes aside this dynamic, in favor of a naive model where users don't succumb to path dependence or local maxima. Why?

In the context of RHEL/CentOS examples, the situation is a bit more nuanced.

I believe Red Hat was already offering a generous free subscriptions for developers, and whatever stuff like folks running labs, or trying-before-buying. Then during the CentOS Stream drama they decided to expand the free-tier to straight allow smaller "production" users, which apparently (supposedly) represented the majority of the ballyhoo'd CentOS community.

https://developers.redhat.com/articles/faqs-no-cost-red-hat-...

But there were certainly large-scale CentOS deployments, who probably wouldn't qualify for the new "free-tier" terms, so perhaps they had legitimate grief? If a legitimate grief includes the right to complain for something they receive for free?

> On the other hand the companies put in the freebies with the explicit intention of attracting a critical mass of users, and most of the times with the expectation that they will be removed once that target is reached. Then some creative "moral" accounting disregards that for those freebies the users also provided something of great value - they supported the platform in rising to wherever it rose. The platform may have extracted more value from the user than the user extracted from the platform. Each one of those free users probably brought a few more with them.

And that's the nuanced part, at some point Red Hat quietly took over CentOS, paid for the copyrights, and started paying it's core team a nice salary to continue doing what they were doing. The rumor was the project was on the brink of ending, or something like that... due to not having any funding, the whole "free-tier not being profitable" problem being discussed here.

Apparently CentOS wasn't getting much in the way of donations, besides folks hosting mirrors, or donating old hardware, or sometimes even rackspace in a data-center for build-hosts used for RPM builds. Supposedly the CentOS community was really cheap, or attracted folks with those personality traits, alongside other folks who were there purportedly for the perception CentOS was extra extra stable, something along the lines of lagging behind RHEL, the thrash'n'churn would somehow be less impact. You might characterize those as the neck-beard "get off my lawn" crowd, and they are difficult to engage.

> So while to a point I understand the "you didn't pay so you didn't lose anything" mantra, I'm also completely aware that this was part of the long term strategy of the company and it's like hooking a fish and thinking "why's the fish complaining, it got the bait for free". A more honest and transparent strategy would be to set the expectations from the start, people can choose to take the freebie for a time knowing that at a predefined point they will cost.

The weird part is CentOS became the upstream for RHEL, and continues to exist, and is in many way a better choice (besides being free-tier) due to having fixes first, etc...

> And the statement that "you don't like it build another one yourself" is very biased. From the ones being at the top of a mountain supported by users who have to pay to get out, to the ones who'd have to compete with the mountain when they can only start with a hill. It's what FB will tell you when you object to their questionable practices.

But ultimately that's the point, By putting CentOS stream ahead of RHEL, the so-called black-box, or whatever Red Hat secret sauce for building enterprise Linux... was revealed to the whole world. Now, anybody can audit this work, reproduce the results; all the things... before then it was not so easy.

Subscription management of RHEL has always been an issue. There were ample ways of getting an evaluation set up or a free developer subscription but the backend work needed to get these done seemed insanely complex. I remember at some point hearing that for every free eval subscription an actual "sale" was recorded in the backend ERP (SAP?) system at Red Hat. That made quick drive-by downloads not feasible.

The developer subscription was a bit of a "hack" to extend and required you to go to an incognito window without cookies, authenticate to the developer portal which would then drop in the dev subscription into your Red Hat account. This was documented in https://developers.redhat.com/articles/faqs-no-cost-red-hat-... point 14. I cannot fathom what backend juggling necessitated this workflow.

For larger companies, managing subscription/entitlement keys was sometimes a hassle. I've heard of a handful of companies that paid for commercial RHEL subscriptions but most of the time just installed CentOS in prod as it was less of a hassle. There interesting thing here was that number of paid but unused RHEL subscriptions stayed mostly aligned with the number of machines in use. Other companies had RHEL in prod but CentOS in non-prod policies simply because it enabled quicker turnarounds and deployments.

The rumor that CentOS was on the brink of ending is something I find _very_ hard to believe. The CentOS project was a small group of people which - to the best of my knowledge - were all gainfully employed in the Linux/Admin space or sucessfully self employed as consultants and did the CentOS work in their free time as a hobby. For the consultants the CentOS connection might even have been a door opener. Bandwidth and hardware for mirrors, buildservers and webservers etc. were exclusively donations, as is very common for these projects. Even with a minimum of financial contributions or not even any at all, keeping such a project alive isn't difficult. After all, nobody is depending on the money for their livelyhoods and it's a hobby after all.

In the past there were times where drama hit CentOS-land. In 2009 LWN reported on the CentOS project founder disappearing a while ago and donations not reaching the project: https://lwn.net/Articles/345028/. That article seems to support my impression that financial contributions are not really relevant to the success of a project suhc as CentOS.

The issues with CentOS seemed more around life happening to people in control and then the project suffering: https://lwn.net/Articles/460791/ is an article from 2011 about package builds and pushes happening with delays. These issues however seemed to have been resolved some time later and delays seemed to be much less common. Interesting point: That article was contributed to LWN by the same author as the original post.

Now, considering these data points I wouldn't put a lot of faith into any rumors that CentOS was going to collapse and Red Hat came riding in to safe the day. I'd say it is much more likely that Red Hat had decided that RHEL was too restricted and fedora way to "fast and loose" to build an enterprise developer community around. Instead it might be a good idea to grab the CentOS and turn that into the development basis for ISVs, 3rd party commercial vendors and other open source projects. The Xen 4 CentOS project was a great example for this. Taking into account that a lot of these projects and special interest groups were announced shortly after the acquisition, I'd say this view isn't far from the truth.

At the end of the day, the moaning about a free alternative going away is kinda ridiculous I think. I know large users of CentOS (hundreds of thousands of machines) that had a look at CentOS stream, did talk a little bit about it amongst their different departments and decided that Stream is fine for them. If it is fine for these kind of shops, it can't be that bad.

And the honesty about alpha quality is refreshing. I usually find that someone being honest about that indicates that their idea of “alpha quality” is some distance better than what many claim to be “beta” or “release” quality!

And not tracking (assuming this doesn't change in future) means that once you do pay you aren't paying twice (once with money, once with letting yourself be stalked by commercial interests).

Self-hosted option too.

Duly added to my ever-growing list of things I'd like to investigate but might never find time for…

I could imagine what happen if gmail would suddenly become a paid platform with no free tier. Users would have to change very single account they got in the world that is tied to that email, and I know in some cases you might need to contact support (through email) or use a recovery password. A lot of peoples identity is tied to a free service, a "freebie" given by a for-profit company.

I fully agree that users have some outsized expectations on free infrastructure platforms, through I wouldn't blame that on the user. User's don't generally have much choice in what platform their bought products is built on top, but it is them that feel the effect first when the bottom layer is changed under their feet.

We still have some confused/entitled users despite this, who express astonishment that online services might require payment. We generally issue refunds to these users (and simultaneously terminate paid services).

I think we need to make a cultural shift back towards paying for the things we use, so that incentives are properly aligned and there's no need to get "creative" with monetizing users.

That is if everyone acted in good faith. There are lots of services that monetize users even if they pay and will keep doing so as their primary business model is greed.

You may start off paying a company that has good intentions but those good intentions rarely seem to last.

It can be challenging to figure out what is good intention, like GitLab offering free services... Or maybe Uber Eats offering free credits as long as you install their mobile app and provide your personal information.

I'd prefer to not give any money to someone unless I know for sure what I'm getting and that it is at a fair price.

This is why I only use Open Source, because if the SaaS company decides to change their pricing structure, I can always move to a different host or host it myself. Hence, I only ever used features on Gitlab that were in their Open Source core product. And why I am looking for an alternative that offers some of the features Gitlab has locked behind their proprietary offering.

But vendor lock-in is one of the perfect factors to considerate when monetizing these services, as are short notice periods, amount of work required for migration, and time pressure. I can imagine they have more impact on final price than things like value of service, SLAs and warranties. After analysis, Gitlab found that the current prices are the best balance between getting revenue and users migrating away.

I compare this with Photobucket: it was a free image hosting site that allowed hotlinking and ended up used everywhere. One of the largest group of users was the small scale online merchants, they hosted lots (lots!) of product photos there and hotlinked them to Amazon, eBay, etc. Then overnight they changed the free users features, disabled hotlinking and replaced the images with a placeholder, unless users paid for a subscription costing USD 400,00. The hosting and bandwidth cost were not the important factors: there was a very long tail and most images were loaded just once in forever. There was a lot of less expensive sites doing the same, but the incentive for paying was the amount of hotlinked images that needed to be changed manually in a very short notice -- and the small merchants had no time nor resources to do this quickly enough, before the lost sales pile up or their ads get reported for not featuring the images. So I can suppose a lot of them just paid up. This strategy would not have worked if accounts were grandfathered.

That's the reasoning for Gitlab (and Github, it's just a matter of time): how much effort would cost to migrate away and how the projects would be disrupted until it is finished? As git is distributed and users are technically versed and can automate migration of the centralized features, it's no wonder that it cost less the Photobucked. However, there must be factors pushing the price up: one that I can easily imagine is amount of Go projects that download dependencies from repos with URLs hardcoded in source. And all their cloned copies, packaged tarballs, etc.