Looking at the Slashdot comments, I saw some gems, but this one hits the
nail:

"One does have to wonder what is ACTUALLY going on here. Presumably Red Hat
wants to harness somehow all the energy around CentOS. One suspects the
installed CentOS base is vastly larger than the RHEL installed base, and
there is a whole lot of energy in unpaid peer support. Presumably Red Hat
is eyeing that energy enviously. For CentOS' part, it is much less clear
what they gain. Possibly Red Hat gave them an ultimatum, implying or
spelling out that they could make their life a living hell, by making it
very hard to recompile the source, perhaps as simply as threatening to
contaminate the source so thoroughly with Red Hat branding that it would be
impractical to "clean" it.

This is all guesswork, but it at least makes some degree of sense as a
possibility. Officially, there is absolutely no hint what the motivation is
on either side.

Likely the guys at Scientific Linux and the other RHEL clones, the ones
that apparently won't be under this new golden umbrella, will have some
ideas of substance about what is going on."

Now, what I was thinking about was trying to see if we could unify as many
of these EL spins as possible to produce a sort of "unified", independent
distribution. I remember that a friend, me, and some others were, a little
while back, trying to build a new EL clone called Ascendos to try and
counter CentOS's shortfalls at the time, and serve as a sort of generic
"base" distribution that could be used for re-spins, like (theoretically)
SL. Ironically, http://centos.org/variants/ this part seems to be treading
into that territory.

I have been trying to use the prospect of EL7 as a way to try and get
everyone back together on it, but this is a real game-changer we should
really discuss. Personally, I just think that we need less duplication in
this realm, but afaik SL is the 2nd most-popular EL re-spin behind CentOS
itself. Can you really call CentOS an EL re-spin anymore if CentOS is now
owned by Red Hat?


On Wed, Jan 8, 2014 at 9:03 AM, zxq9 <[log in to unmask]> wrote:

> On Wednesday 08 January 2014 14:48:21 David Sommerseth wrote:
> > On 08/01/14 01:33, Travis Heinstrom wrote:
> > > I think this is going to be interesting. CentOS has always been a RHEL
> > > clone, and I think Red Hat might try to kill the whole idea of a free
> > > "clone."
> >
> > That would be a stupid strategy.  Seriously.  If RH would manage to kill
> > CentOS, another CentOS variant, based on the same sources would pop up
> > as a replacement - or Scientific Linux would quickly gain even more
> > traction.  That is simply a core feature of open source projects (such
> > as CentOS).
> >
> > In addition, claiming that RH might try to kill a free clone, that
> > sounds more like traditional "closed source" thinking.  Which is not
> > even close to the values RH has:
> > <https://www.youtube.com/watch?v=ySyPIoyXJ-k>
>
> Working at a company that targets the RHEL platform as well as other
> distros
> which tend to have much more recent libraries and runtimes, I have to say
> it
> disambiguates a few things. For example, the argument to spend the effort
> maintaining dependencies (which are necessarily parallel and separate in
> many
> cases to system libs/runtimes/compilers) and package proper SELinux
> policies
> for our products is stronger now.
>
> Platform stability* and commonality is the main thing that Linux has
> historically lacked. I see this as one more way RH is trying to address
> that.
> Even if it is only going to marginally alleviate the issue in the minds of
> management, it'll at least spark some discussion at a few business software
> development houses.
>
> It also (and far more effectively) embraces/absorbs the 800-pound gorilla
> of
> free data center installs. It does this while marginalizing Oracle Linux as
> well as Oracle/IBM/HP/Microsoft/independent paid support offerings for
> CentOS.
> I can't imagine there isn't already a planned CentOS-to-RHEL or CentOS
> supported upgrade product. This sort of product will be the "obviously
> correct/safe" choice for an organization to make when it realizes that
> outside
> help is required to maintain a data center that has (for whatever reason)
> grown beyond the built-in management capability.
>
> [*"stability" in the development/investment risk<->reward sense, not in the
> sense of crash-happy systems.]
>