The Future Of CentOS

Home » CentOS » The Future Of CentOS
CentOS 31 Comments

Almost everyone here has probably read this by now. If so, move along, nothing new here. But just in case you haven’t, please take the time to read this.

Here it is, in their own words: what Redhat thinks of CentOS, and it’s plans for the future of CentOS.

Can you read between the lines? In this case, it isn’t very hard to do, IMHO.

31 thoughts on - The Future Of CentOS

  • It is what many of us feared.

    I never noticed any of the CentOS bosses stating they are on a CentOS
    board dominated by Red Hat employees.

    It is a de facto take-over of CentOS by Red Hat. CentOS Independence has been “sold” to Red Hat by the supposed guardians of CentOS.

    “The role of the Red Hat Enterprise Linux Developer Program is to provide participants with the tools and resources they need to develop on and for deployment on Red Hat Enterprise Linux; CentOS does not fit into this. ………

    “…. developing on CentOS does not guarantee that the resulting application will work on Red Hat Enterprise Linux.”

    So I was 100% correct when I wrote earlier

    “Am I mistaken in thinking, after reading recent postings, CentOS is slowly moving in a different direction to RHEL and the removal of useful and informative sub-version numbers is merely the first of many manifestations of the growing-gap, or eventual gulf, between “upstream”
    and CentOS ?”

    “Will CentOS versions eventually become incompatible, partially or wholly, with its parent’s RHEL versions ? I can understand why that would be commercially advantageous to RH.”

    This CentOS mailing list, just like the CentOS name and logo is the corporate property of Red Hat Inc. How much did Red Hat pay the guardians of the CentOS brand to sell-out the whole of CentOS to RH ?

    I do not know how this previously unpublished commercial take-over of CentOS will affect the running of our systems. Hopefully things will continue smoothly for everyone’s benefit. Perhaps a Fork will emerge.

    I wonder why this take-over was continually denied by CentOS bosses at the beginning.

    Probably to prevent effective forks, Red Hat will deliberately make it more difficult for the community to compile their sources and produce a workable distribution closely resembling RHEL. One thing is for sure, all the advantages of CentOS development will enrich RH whilst CentOS
    will lack all the advantages of RHEL.

    That is commercial business folks !

  • How about you elaborate on your theory?

    Publicly, and I believe honestly, Red Hat wanted to ensure the long-term health of the CentOS project. Many companies, when starting out, use CentOS because of it’s enterprise lineage and free-as-in-beer cost.

    Eventually, some of those companies will succeed and grow. Along the line, they will realize the value and ROI of switching to full enterprise support. Being on CentOS, it is then trivial for these companies to switch the RHEL proper.

    There is no grand conspiracy here. It is very much in Red Hat’s interests to keep CentOS healthy and thriving. Will CentOS change over time? Yes, of course. Every project, company (and people) need to change and adapt, or else they will fade into irrelevance.

  • If you and others believe this to be the case, then form an organization and fork CentOS. Or, do as CentOS did in the beginning and recompile the RHEL binaries to be binary-compatible and create your own OS.

    It is the open-source way, and I am not being sarcastic.

  • Exactly why I believe it will not come to be.

    SIGs/variants may, but CentOS base will stay very close. It would be very stupid of RH to do otherwise.

  • Then call it ROSIE, Red Hat Operating System Intentionally ….. I need a suitable word beginning with ‘E’ :-)

    Well, now everyone knows the future of CentOS.

  • I agree with your point that if RH is to commercially benefit from CentOS installations transferring to (or upgrading to) RH, then the base systems should not be radically different or even incompatible.

    The future is certain. To benefit from this free operating system, tolerate the RH control and desire to ensure CentOS and RHEL are not exactly the same (including incompatible version numbers) or get another operating system. It is that simple.

    Happy Easter to everyone.

  • Exactly, the core distro stays where it is – we add layered and enhanced options with low barriers to entry around it.

    yum install CentOS-release-gluster yum install gluster.

    makes for a much easier gluster onramp ( or ceph or openafs ).

    If you look at the projects we interface with, it will be clear that this is all in the interest of the regular established existing CentOS
    userbase – eg. now hosts the integration testing for libvirt upstream ( I suspect most people will agree that libvirt is something we all care about deeply ). Other projects I am working with to have them come test with CentOS are : OpenStack, theforeman, libguestfs, mariadb, PostgreSQL etc ( and we welcome others a well).

    Now if you look at the SIGs coming up and delivering content – it should again be pretty clear what sort of content we are facilitating here.

  • 100% with Digimer here.

    I think there are no conspiracy theories. IMO RedHat does not want nor does it afford to mess up CentOS.

    All this energy should be put into contributing towards to the project, testing, helping out community.


  • I think it inevitable that Red Hat will introduce some closed source packages for the its paying customers, and thus hinder parasitic Oracle, whilst continuing the development of the base system. This will probably not affect the majority of ‘standard’ CentOS users.

    We have a proven reliable *free* operating system produced by The CentOS
    Team, just as good as RHEL although RH is preventing CentOS certifying a comparison. The comparison between RH and CentOS versions is gradually being separated, but never-the-less we retain a professional operating system entirely free of licensing costs which satisfies our needs. And, as a bonus, it is not Windoze.

    If this had been explained at the beginning of the take-over of an operating system clone by the originating source (‘upstream’) which desired a de facto ‘fork’ to protect its commercial interests.

    Back to work on RH CentOS :-)

  • For the sake of perspective, even in the old Red Hat Linux boxed sets in
    1997 this was true. There was a whole CD of closed source stuff that you got in the boxed set that was never available for download. Things like WordPerfect for Linux, for starters. Sybase ASE was in one of the boxed set’s Linux Applications CDs (but I seem to remember it being a
    ‘limited’ or ‘personal’ edition).

    Harking back to 1998, here’s what is on that CD for Red Hat Linux 5.2:
    [lowen@dhcp-pool114 Red Hat Vendor Disc Oct 1998]$ ls -1
    Applix ARDI
    CASEMaker CodeForge Crosswinds Decosoft DigitalControls EST
    Fastlane Flame Herrin HKS
    InfoSpring JX
    Knowledge Knox Multisoft NetWin NExS
    Perforce README
    Shpink SpectraLogic Stalker SuSE
    Sybase Take5
    Visual WGS
    [lowen@dhcp-pool114 Red Hat Vendor Disc Oct 1998]$

    This is also true for RHEL, and has been for quite a while. There is a whole ‘Supplemental’ disc that has packages for which there is no source freely available, although the number of packages on that disc is relatively small, most of it being IBM Java for the 7.1 supplemental server disc.

    So it is nothing new to have closed source value-add in the Red Hat ecosystem.

  • Agreed, and I want to thank you specifically for the nux dextop repo, which is in my standard installed repo set for EL6 and EL7.

  • In the context of this discussion I would appreciate any feedback the list might have on this article I wrote for my new company.

    I for one welcome our Redhat overlords. I think they will provide better governance which should give CentOS better credibility as an Enterprise, community supported operating system.

  • Well, I used to agree. But when a bug report filed in December goes untouched entering April, which I don’t recall happening prior to RH
    subsuming the project, it takes away impetus to ever file one again from lowly end users like me I think.

    Crashes related to 6.6 update involving the way init is done and X is done seem, at least to me, serious enough to have warranted a look-see, at least, if there is still real concern for the (desktop?) community.

    Since I don’t feel it’s my place to tell others how to behave, this
    (lack of) response has me now looking for alternatives that are (maybe?)
    more reliable and responsive. Since I’ve transitioned to a user that just wants a reliable tool now, the 6.6 upgrade soured me big-time. Then having the bug report serve only to grow mold, rather than getting the
    (apparent) conflict twixt init, X, the (new?) init processes … looked at is sealing my decision to find a more reliable desktop distribution.

    Been UNIX (programming and user) since 1978, Linux since some early Slackware distributions, CentOS since 4.x. Will now be looking for something staying truer to the original UNIX concepts but full-featured and stable – may not be available, but I’ve got to at least look. You know, something that doesn’t bomb on a point release update because
    (inadequately tested/previewed and unnecessary/useless?) changes were thrown in. Add in the extra instance of Firefox that hogs a 6-core AMD
    processor (patch provided to the list earlier), stuff X-related running and trying to contact the free desktop org folks w/o any notification
    (shades of MS!), … I can’t speak for others, but changing much of anything in the init processes and having extra instances of application software started and running without user being ware (when these weren’t so common in the past?) seems significant and my thinking would be to save those for better testing, possible RFCs, and major releases.

    But I’m not a developer any more and don’t expect the rigor I used to apply still works in today’s world.

    MHO, in (partial) ignorance, Bill

  • It appears that you are the only one to have encountered this bug. Within any project, open source or proprietary; problems are usually prioritized according to the severity of the bug and the number of users that it affects.

  • Yep. I may be the only one that happens to use this in the way I do. But then I would expect at least a change to closed status with a reason to be given, based on past behavior?

    Regardless, if one is given the ability to switch run levels via the use of telinit and the like, shouldn’t one be able to rely on it operating properly?

    When one takes the time to run multiple tests demonstrating the problem, collect and make available the related files, post with “if more is needed or something wasn’t properly reported let me know”, wouldn’t one deserve at least a look-see and some sort of response or status change?
    That being in the “contribute to the community” spirit under discussion.

    The processes I go through that produced the bad results have been used by me since CentOS4.x, IIRC, and certainly through all of CentOS 5 and 6
    prior to 6.6.

    BTW, in acknowledgment of the CentOS folks, I realize they try to be
    100% compatible with RH, warts and all, so the occurrence of the problem is not really a CentOS group problem, per se, but a RH issue.


  • Once you asked for comments, here it goes:

    You are saying: “Currently is appears that there are two strong contenders for a Linux distribution. Ubuntu and Redhat Enterprise Linux/CentOS.”

    You seem to be overlooking Debian. Ubuntu (and many others) at some point were “clones of Debian”. One can argue Ubuntu stepped up (or aside) a lot since. Still…

    Just MHO.


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • This is very true. Maybe I should say “yum based systems” and “apt based systems” but I did not want to turn it into a technical article. Ill have a think about that.

  • There remain ClearOS and Scientific Linux. But, I am in no hurry to make any decision at the present time. I am not at all on-board with the “evil empire” takeover interpretation of recent events. I do not believe this to be the case.

    However, the golden rule holds that whoever pays the gold makes the rules. I do not think this situation will prove any different in the long run. When a “volunteer” board becomes dominated by a single commercial entity who pays employees to “volunteer” the long-term results are decisions that tend to favour that entity over all members. I have seen this happen first hand and our firm no long belongs to that particular national organisation in consequence.

    This is an interesting situation from a philosophical POV though. What are the ethics of attempting to monetize the intellectual property of others? What are the ethics of attempting to make use of the benefits that arise from that monetizing effort without paying for them?

  • If you guys have that much of a problem with CentOS/RedHat collaboration, why not just move on things like Debian, arch, Suse etc…

  • Some did move to other systems (even away from Linux totally; somehow many assume choices are Linux only). You will not hear them here anymore. I
    recognize them on other systems mail lists often. Some still comment
    (lightly), but not because all of them (us I might say) like to whine. No, just to provide feedback, which is courtesy actually as we gain nothing
    (but slaps: “you like to whine!”). Don’t get me wrong, significant split of my systems are and stay CentOS ;-)


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • If the *whole* truth had been told to the public (i.e. “us”) at the first mention of the RH take-over, including the divergence away from RH
    versions and the RH dominated management board controlling the now Red Hat owned CentOS product, then significant qualities of our time and energy could have been more usefully spent on other things.

    Reading about C7 problems and systemd, sysctrld etc., I now wish I never threw away (for recycling) my 1990’s purchase of a FreeBSD technical manual.

    Above all, I want stability in a product. Once I have learned increasing amounts of a product, I am adverse to replacing that knowledge with tomorrow’s new versions especially if – for me – those alleged
    “improvements” offer me no beneficial advantage.

    I like C5 and C6 and hope the BSDs systems are similar.

  • 2015-04-04 4:01 GMT+03:00 Francis Gerund :

    If this is a problem, just pick another RHEL clone like Scientific Linux ?

  • I thought I read on this List the intention of Scientific to base its future distribution on Red Hat’s CentOS product.

  • Well put. For a non-technical person, your brief clues them in to the differences between RHEL and CentOS. And the reason both coexist.

    I do however agree with Valeri in that you probably (c|s)hould mention Debian in there somewhere. I realize you left Debian out because there is no official “enterprise”
    support entity as there is with Ubuntu. So at that point, maybe it’s not worth mentioning Debian?

  • Surely a fair, balanced and proportionate investigation explores the functionality of all the systems before determining the result ?

    The web page begins “….. This article will make the business case for
    “Enterprise Linux” distributions like CentOS and RHEL.”

    That does seem biased because at that moment of restricting the result to ‘2 operating systems only’ no consideration of the alternatives have been made *AND* the comparison criteria remains unknown and undeclared.

    That methodology is not how a senior court judge would decide on an issue.


    Paul. England, EU. Je suis Charlie.

  • For what it is worth.

    If RedHat (or someone else) offered support contracts for CentOS aimed towards the more ‘self-help’ type ‘enterprises’ then we would likely participate.

    We not prepared to install and run one copy of RHELx simply to be able to report bugs and get a modest amount of help via online channels. The administrative burden is simply not worth it.

    However, if one could purchase a company-wide support policy for CentOS based on the number of points of contact at the subscriber’s end, regardless of the number of hosts running CentOS, then we would definitely be interested. Again, we are not interested in assuming the administrative burden of counting hosts on various VM platforms and physical units as they come and go simply to properly determine support fees. But restricting at our end who can report incidents and deal with the support contractors poses no significant difficulty at all.

    Just a thought.