[CentOS-devel] Vote of Confidence

On Sat, Jan 2, 2021 at 8:50 AM orkcu via CentOS-devel
<centos-devel at centos.org> wrote:
> I don't think CentOS (or any other clone/rebuild) was ever a Bazaar, it can not be if the goal is to be a good clone/rebuild.
> Since the very beginning the control was in a handful of people, very tight, and I remember one crisis when the founder didn't want (was unable/unavailable) to release control of dns domain, sign keys and few other main components that now you complain RedHat don't want to release

I think you are right. The original intent, and the announcements and
documentation for the project suggested something greater, but the
reality turned out to be difficulty in delegation and scale. This is a
common problem for volunteer or non-profit organizations. It doesn't
matter if you have 3000 people willing to work on your project for
free, if you can't effectively assign them work to do. It's worse if
you can't even scale beyond a small number like "3", as these 3
eventually move on, and there is no succession plan, resulting in the
project failing.

For many of us - I think we had a naive trust that this would be
figured out, and we would be invited when the time came to invite us.
However, it didn't happen, and in 2014, Red Hat offered to take the
reins. It's not that Red Hat set out to destroy the community - it is
only that Red Hat has a conflict of interest, and it is really
difficult for this conflict of interest to not eventually result in
favouring certain self-interest outcomes over other non self-interest
outcomes, and this is exactly what is happening in 2021. In effect, it
was an inevitable conclusion. It was even predicted by several people
in 2014.

A similar thing is playing out in Rocky right now, however, there is a
great deal of accumulated know-how, access to resources, and sober
reflection on what went wrong leading up to 2014 and 2020. 3000+
people willing to work for free, but probably only 70 will be able to
directly contribute, and initially the number will be a lot fewer as
the initial setup takes place. This is why I say that Rocky is what
CentOS should have been in 2014. We all know it wasn't. Now there is a
chance to fix this. It could be a very good thing.

> I don't like CentOS to evolve to Stream, I agree there is a need of a cheap RHEL's quality distribution, and I think all the arguments given so far at the end (in the very bottom) it is about cost (money), from the people complaining about the end because we are losing a very good distro that was free/gratis, from RedHat it is about moving the money to a direction that might provide better benefits for the company.
> If RedHat would offer its RHEL with a minimum price (20? 50? 100?) for self support and then charge for a ticket a good amount of money ( like 200? 500?), that might work for a lot of people who are complaining now, I think we all understand that everyone need to have an income to feed its needs, even the small shops that are trying to save in (software) costs as much as possible.

If Red Hat had agreed to this in 2016 and 2017 when I was asking for a
reasonable solution to our problem, the company I work for would still
be a Red Hat only shop. This was an opportunity missed then, and I
believe it will be an opportunity missed when the new plans are
announced. I don't believe the new subscription plans will be enough
to make them an attractive option, and after the stumble with CentOS,
even a good subscription plan that might meet some use cases will be
frowned upon as a result of this debacle.

> Bottom line, I don't think we ever had a community built OS in CentOS, we had people of the community assisting in testing and QA, but not even that was open to the public. I might be wrong but I think even before 2014 we had builders that were not (much) active in mailing list or IRC, and that is OK, each person have different strengths.

I don't think you are wrong. Healthy communities need to prioritize
delegation and scalability. It means investing specific effort in
ensuring that people of different skills and capabilities can
successfully contribute to the project.

-- 
Mark Mielke <mark.mielke at gmail.com>