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