We use RHEL only on oracle databases primarily because we need the oracle support and oracle will simply drop the phone when they hear that you are not running on a certified OS.

But for everything else, I install Centos. If the software/developers tell me RHEL, I go back to them explaning that Centos is exactly RHEL without the Redhat support that I won't need/use anyway.

Sometimes it comes down to simply how you feel about the control of your own future.

Working directly with Red Hat puts you in an important position, a paying customer, with the people who are experts at getting problems fixed and new features included in upstream projects.

Red Hat is the catalyst between you as a customer and many thousands of upstreams, not just the Linux kernel. Take a look at some of the past and ongoing contributions that have come from Red Hat, some of which were influenced by customer requests:

http://fedoraproject.org/wiki/Red_Hat_contributions

When you use a rebuild of Enterprise Linux, you gain the same benefits flowing downstream that Red Hat customers gain, but you change the dynamics of how you can manage your relationship with the upstream.

Is your in-house support staff prepared to negotiate with upstream projects on your behalf? Work to get patches and features included in the code?

If they are, that is great; the world needs more corporations that are contributing from within their own IT staff. Again, though, when doing that, having a partner, such as Red Hat, to work with on negotiating through the upstream maze can be helpful.

People who work to produce Enterprise Linux rebuilds are in the same position with regard to how they can influence the upstream. If they are a paying customer, they can ask Red Hat for help. If not, they are welcome with everyone else to participate in the upstream project for RHEL, which also considers itself the upstream for CentOS, Scientific Linux, Whitebox Linux, and the myriad other rebuilds:

http://join.fedoraproject.org

For a long view on how and why this works, I encourage you to take 9 mins and 21 seconds to watch Michael Tiemann talk about "The Open Source Triple Play":

http://www.youtube.com/watch?v=ntzp8z14OXQ

http://www.redhat.com/magazine/001nov04/features/tripleplay/

I agree with Karsten Wade . However even if the inhouse staff is competent enough to push in features for the upstream, when it comes to getting those features backported to RHEL, you will have to be a RHEL customer. Also the flip side of using CentOS is patching the system with critical security erratas which come in Centos only after a RHEL minor release ( like RHEL5.1 , RHEL5.2 ) and for which you might have to wait for like 6 months. Same is the case with critical bug fixes for which you can get hotfixes if you are using RHEL. For all mission critical applications I would strongly recommend RHEL .

Cheatah wrote:

Should companies like hosting providers use RHEL or CentOS on their production machines?

Red Hat Enterprise Linux comes with official support from Red Hat, Inc. based on a SLA. But many companies have their own technical personnel and rarely require 3rd party support.

Should such companies use RHEL even though CentOS is built upon almost exactly the same code? Or should their customers choose? Large customers? Business-critical solutions? Governmental agencies?

My company mainains hundreds of servers, many running CentOS (migrated from FreeBSD), a few running Debian, but no servers actually running RHEL.

Under what circumstances should companies choose for Red Hat Enterprise Linux or CentOS?

I never use CentOS, if the requirement is to fully support it, 24/7, with <1% downtime. Very likely, I could fix any probs myself. But if not, it would mean my a$$. However, in reality, I use CentOS all the time, whenever possible, b/c it is easier to reinstall it, update it, and use get additional software for it. And I don't support a Ginormous Corporation of end-users. or NORAD.

Sometimes the customer has strict requirements about the accreditation of the software (USG) and you're stuck with RHEL, or even RHEL+SELINUX <shudder>.

I would add that I've never run across a CentOS problem/bug that was not also a RHEL problem/bug.