5 ms·

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

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

Invictus0 4y ago
> 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.
- bussierem 4y ago
  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.
- mindslight 4y ago
  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?
- buran77 4y ago
  > 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.
parasense 4y ago
> 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-enterprise-linux 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.

Invictus0 4y ago

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

bussierem 4y ago
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.
mindslight 4y ago
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?
buran77 4y ago
> 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.

parasense 4y ago

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