I believe it has come time to lay out some thoughts on the different EL(Enterprise Linux) distros and the communities that surround them.
The EL words
I have been using Linux off and on for a number of years (It is actually coming close to 20!) and have seen it mature over those years. I have also used various Free and Open Source operating systems as well as proprietary systems. One of the the most remarkable things has been to see the widespread adoption of Linux in the Enterprise space.
I believe that Linux could have happily remained as a hobbyist dream and enjoyed a long life of fruitful innovation. Of course this is idle speculation that has in many ways past us by.
As companies begin to adopt products they have certain expectations for the products they employ, regardless of the associated cost. In some ways they have greater flexibility than the home hobbyist since they have coffers to reach in and pay for more stable and reliable systems. While offering money helps motivate further production and development of systems, is a great means of advancing systems and attracting developers, it doesn’t solve everything. Investment of money does tend to set higher expectations.
Some of the higher expectations that are set with adoption of a system in the enterprise are things such as:
- Reliability
- Stability
- Timely and Productive Bug Resolution
- Proactive Development
- Regular Updates
There have been a number of Linux Distributions over the years that have all strived for these goals. Some of them more productively then others.
The current crop of Enterprise level distributions are:
- Red Hat Enterprise Linux
- Oracle Enterprise Linux
- SUSE Enterprise Linux
- Ubuntu
- CentOS
I am sure there are others but those are the most common ones that I hear of working with people from enterprise environments.
Give and Ye Shall Receive
Of the previously listed distributions both Oracle Enterprise Linux and CentOS are based upon Red Hat Enterprise Linux. While they may be the most prominent they are most certainly not the only ones.
Why has one distribution become so popular and been rebuilt by so many?
We could look at the market share and assume that it is simply a matter of dominance in the market place. It might be the fruits of long and hard efforts to promote their brand and create an effective training and certification process.
I suspect that all of these items play a varying roles in the “success” of Red Hat and the RHEL clones. I also think that one of the big differences is how readily accessible the source code is for the users. You may have noticed that there isn’t a rebuild of the SUSE system running around out there.
Red Hat is a very open company and publishes source code to a publicly available ftp site where anyone can grab the source RPM packages.
What did they ever do for you?
Red Hat is a very different company in this sense. There have been a few packages that they haven’t released the source code for, or have taken their time (i.e. RHN Satellite Server released as Spacewalk), but they don’t restrict access to updates in source code form. It is very possible for you to get the demo version of RHEL and keep it up to date by building your own updated RPMs wth the source RPMs from the ftp site.
These packages are available and people can rebuild these packages and come up with a rebuild of a RHEL system from Tip to Tail. And the world has certainly done it. The number of systems out there that do a rebuild of RHEL is pretty impressive and they keep coming.
But what does this do for Red Hat?
Its a gateway into their support and contract services. They know that once they gain a foothold into your enterprise they will have an ongoing customer. Even if their potential customer is using something other then actual RHEL they will eventually join the fold.
From the perspective of RHEL this is a good long term strategy. They are essentially giving away their product, even when it is a rebuild, that will get their foot in the door.
There may not be a need for support for your print server but there will be for your data center.
So as discussed Red Hat has good reason to let rebuilds be encouraged. There is also the fact that good rebuild projects feed back through bug reports and help improve their product.
Let the Rebuilds Begin!
Since there are good reasons for Red Hat to be accommodating of rebuilds, why not just one? Why doesn’t everyone just work on a single project?
Many of the rebuilds have focused on rebuilding for a particular reason. Each has adopted a different model for its administration. While these projects all rebuild Red Hat they can be very different under the covers.
While I have been a big supporter of CentOS in the past, recent events have brought to light the underlying administrative model of CentOS. Following these events there were questions and unhappy answers.
During this unhappy period there was a moment of reflection. A lot of users were unhappy with the delay that it took to get to CentOS 6. The reaction from the CentOS builders and their supports was along the lines of “You will get it when you get it and if you want it faster build it yourself.”.
Towards the ends of the 200+ day wait that it took to build CentOS 6 many people, including myself, began to wonder if there wasn’t a different approach that could be taken.
Enter the GoOSe
GoOSe Enterprise Linux isn’t much different from CentOS in the ultimate product. It will be a rebuild of RHEL and the updates that are released. While almost the same there are some key differences.
The community is probably one of the biggest of the differences. Where CentOS has a small group of builders (6 the last time I checked) that are responsible for building and producing the product, GoOSe is very community oriented. From day one GoOSe has worked to build a meritocracy amongst its users.
GoOSe is meant to be built by the community for the community.
For those that want to be involved in building packages for release there is a path established and helping hands to guide users from an initial contributor to being one of the system builders. As the number of builders grow there is going to be a reduced lag in build time. It also “debusifies” the project.
Debusification is the process of removing reliance on a single or small group of individuals.
Another big difference is that GoOSe wants to be reproducible. You should be able to take the tools and the knowledge provided and rebuild GoOSe or even RHEL, using the provided tools. There is no interest in hiding the build process. Even the build tools that have been created for the project are available for updates and modification.
While GoOSe is still in the early stages it has some great potential.
- Mike
Websites:
http://planet.gooseproject.org
http://github.com/gooseproject
http://www.schwarz.eu/oss/wiki/2011/07/the-downfall-of-centos
http://lists.centos.org/pipermail/centos-devel/2011-March/007101.html
Notice:
2011.09.29.13:09MDT: Minor grammatical corrections and rephrasing.
