Comment by buran77 | Hacker News Reader

Comment by buran77 | Hacker News Reader

Parent Full thread

> they do that knowing very well that there is a certain kind of lock-in

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.

> it's like hooking a fish and thinking "why's the fish complaining, it got the bait for free"

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.

A bit simplified on both parts -- a fish CAN leave too, and many do, by just ripping their mouth open to remove the hook by wriggling enough.

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.

Fish are most certainly able to leave. They "just" need to swim fast enough in the right direction to move back along the hook, and suffer a little damage from the barb. Likewise with users, along the convenience gradient and disrupting their usage. Companies most certainly acknowledge this - they turn up the heat gradually so users don't jump out of the pot.

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

> A fish is unable to leave

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.

> 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.

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.

I appreciate the nuanced view. Let me add a bit of color though and point out where the "rumors" are wrong.

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.

Reply on news.ycombinator.com