[CentOS-devel] Before You Get Mad About The CentOS Stream Change, Think About…

Sat Dec 19 00:59:27 UTC 2020
Mark Mielke <mark.mielke at gmail.com>

On Fri, Dec 18, 2020 at 3:41 PM Japheth Cleaver <cleaver at terabithia.org> wrote:
> On 12/18/2020 11:18 AM, Mark Mielke wrote:
> > On Fri, Dec 18, 2020 at 2:04 PM Mike McGrath <mmcgrath at redhat.com> wrote:
> >> Just know that I mean it when I say, for those of you that are moving on.  We wish you luck, we understand, and we'll see you around.
> > I don't think you do understand. And that is the true tragedy here.
> It's clear from other emails that there is a massive amount of internal
> RedHat debate about this decision still going on. I sincerely hope a
> decision-maker can try to fix this situation before a point-of-no-return
> is reached. This scorched earth approach from a RedHat rep is absurd
> considering the relative size of the EL-derivatives vs paid support
> contracts in install footprint. Nobody wants to have to explain to a
> RedHat Vice President the realities of a F/OSS ecosystem when RedHat is
> the company that virtually codified the industry's best-practices on how
> to do it.
> More explicitly: Nobody wants an EL war; nobody wants to fork. Nobody
> wants more of a headache than we've already all had this year for
> reasons unrelated to Linux. But those things can happen, and it
> certainly wouldn't take $34B to do it.


The community is better equipped than ever to produce an un-encumbered
EL distribution. It would be a nuisance, it would be initially
approached with sadness and reluctance, and it would have
consequences, but the result might be a necessary next step in EL
history. Personally, I don't see why Red Hat would want this. I wish
Red Hat would listen and fix their subscription model to be compatible
with customer requirements, eliminating the need for another EL
distribution. I would be wary of challenging the EL community in this
way. There are thousands of extremely intelligent, well resourced, and
now motivated people to face such a challenge. Words like "feverish"
are misleading as it implies some sort of illness or weariness. If
necessary, this is an exciting challenge for this type of person. They
have basically been practicing how to do this for years now, and they
are being called upon to flex their considerable talents and resources
to solve a real problem that directly impacts their day-to-day life?
This is an invitation for greatness. This call is more like "hackers
of the world, unite!"

> This could have been "just" a question about a business decision -- one
> that would've been entirely (if painfully) understandable had it been a
> direct result of the IBM purchase. It could have been "just" a question
> of how much stability enabling yum-cron and CR/Stream in prod. actually
> removes.  Instead, this is turning into a four-alarm fire about whether
> RedHat the company has the self-awareness that we all assumed it did
> about the trust, deference, and good will it has received from others.

I think it would result in a different sentiment and choice of
language, but perhaps not a different result. I still like many people
at Red Hat, I still appreciate all they have done for the community,
and I still want to reward them for their efforts wherever possible.
If Red Hat offered compatible terms tomorrow, I would review them, and
consider reverting all of our decisions. However, this seems like an
unlikely outcome. I suspect Red Hat will announce a new "free" RHEL,
which continues to be encumbered in some problematic way, and we will
be back to where we started. Also, given the recent choice to shut
down CentOS 8, there would always be the threat that Red Hat would
shut down this new "free" RHEL subscription type. A level of trust has
been betrayed, that may never be restored. Ultimately, unless the
software is free in both source and binary form, we eventually have
this problem all over again.

The reality is that once Red Hat chose to stand firm behind their
subscription model with us, and once we invested in the effort to
essentially remove our dependencies on RHEL, we realized that we were
better off. Red Hat forced us to develop our own expertise, and now we
can choose deployment architectures based upon design requirements,
instead of subscription requirements. Given the same budget, we can
buy twice as much hardware without RHEL subscriptions, as with RHEL
subscriptions, which for a business with ballooning compute
requirements is a major win. And since many of our companies build our
own Linux distributions anyways (for example, we use Yocto to produce
many of our products), this is all familiar territory.

Mark Mielke <mark.mielke at gmail.com>