Red Hat Becomes First $2 Billion Open-Source Company (zdnet.com) 116
An anonymous reader quotes a report from ZDNet: Red Hat just became the first open-source company to make a cool 2 billion bucks. Not bad considering Red Hat became the first billion dollar Linux company only four years ago. Red Hat did it the old-fashioned way: They earned the money instead of playing upon the gullibility of venture capitalists. Red Hat's total revenue for its fourth quarter was $544 million. That's up 17 percent in U.S. dollars year-over-year, or 21 percent measured constant currency. Subscription revenue for the quarter was $480 million, up 18 percent in U.S. dollars year-over-year, or 22 percent measured in constant currency. Subscription revenue in the quarter was 88 percent of total revenue. Analysts estimated Red Hat would make $534 million. Looking ahead for its 2016 FY Red Hat expects to see between $2.380 billion to $2.420 billion. At this rate, Red Hat should easily become the first $3 billion open-source company.
While Red Hat's president and CEO Jim Whitehurst credits the "hybrid cloud infrastructures," Red Hat's subscription revenue can largely be ascribed to Red Hat's flagship product: Red Hat Enterprise Linux. Still, RHEL, which is now available on Microsoft Azure, is becoming a prominent cloud operating system.
While Red Hat's president and CEO Jim Whitehurst credits the "hybrid cloud infrastructures," Red Hat's subscription revenue can largely be ascribed to Red Hat's flagship product: Red Hat Enterprise Linux. Still, RHEL, which is now available on Microsoft Azure, is becoming a prominent cloud operating system.
Red Hat introduced systemd? (Score:2, Troll)
Any sense in that?
Re: (Score:3, Funny)
Spell it "SystemD" not "systemd"
That way it looks like an ASCII penis.
Re: (Score:2)
Re: (Score:2)
I thought it was the grade Lennart got on the project....
Re:Red Hat introduced systemd? (Score:5, Insightful)
Re: (Score:1)
As the 800-lb gorilla, they forced it via inertia. In the real world you don't just broadcast "change to this" and assume everything will follow, it never works. You don't use a hammer to move things, you use your weight to push things around.
Unless you're Microsoft or Oracle of course. They just simply squeeze your balls harder, no need for finesse.
Re: (Score:3)
Why? Debian doesn't source from Red Hat. You're saying that because Red Hat does it, EVERYONE has to? Come on!
Re: (Score:3, Informative)
They really did not. Especially not on Debian. Everyone had their say, publicly, and the majority of Debian maintainers chose systemd over sysvinit/OpenRC.
... Debian maintainers chose systemd... Why? (Score:2)
But why? Were there reasons other than good management? Was it difficult to ignore something Red Hat did?
They wanted something easy to maintain (Score:5, Informative)
The mailing list is public, go and check it. Alternately, this site [debian.org] was put together as a summary of the various positions and options. If I can characterize it, there was a strong desire to move away from sysvinit due to lack of features, bugs, and difficulty of maintenance. Systemd at the time was seen as the best of the alternatives, offering more features and easier maintenance, at the cost of compatibility with non-Linux systems.
Not that I have any great insight into the minds of developers, but I suspect that the decision might have gone otherwise if it were re-held today. I think there would be a stronger consensus against sysvinit, as even fewer people are interested in maintaining those scripts. OpenRC has had more time to mature, and as far as I know Upstart development has basically ended. Interestingly, OpenRC and systemd share a number of features, particularly in their heavy use of C libraries, for which OpenRC receives no criticism and systemd no end to criticism. Either way it looks like that, dependency resolution, cgroup support, and parallel startup have made everybody's minimum feature list. I'm sure it would have been an even more different story if cgroups/process tracking had been a part of sysvinit/POSIX to begin with, but as I understand they were mostly codifying existing practices rather than trying to actually create a good standard.
In any case, Debian moving away from sysvinit wasn't any more influenced by Red Hat than it was by Canonical. All options were on the table, and each of them had their proponents. There was somewhat more backlash against systemd than other options, but I don't think politics played much of a hand in the decision -- politics didn't have to maintain the code afterwards. And despite the popular clamor for sysvinit, most everyone else seems to have dropped it happily, so ignoring the populace seems to have been the right decision in that respect.
Re: (Score:2)
Re: (Score:2)
Upstart never had the contributors it needed. The Debian discussion/wiki I linked has a number of critiques. [debian.org] It solved little or no problems of sysvinit, introduced many of its own, and wasn't portable to other systems. Upstart had a head start on the other init replacements, and while social/political concerns may have contributed to its demise, its technical issues were what stood in the way of its success, and ultimately doomed it.
Re: (Score:2)
Re: (Score:2)
By that reasoning, Debian is using RPM for package management. In fact, having one generally used system for package management would be a good thing in itself.
Re: (Score:2)
Red Hat made the decision to go with systemd for their own operating system. They didn't "force" it on anyone else. If you're unhappy with Debian / whoever else's decision to use systemd you'd better to talk to those maintainers. Obviously they see value in it or they wouldn't be using it.
The Fedora community (which includes a number of Red Hat employees) made the decision. A not-insignificant chunk of the Red Hat Enterprise *users* are not happy about that, but by the time EL 7.1 came out and anyone really cared the decision was long-since past.
In regards to Debian (and other distros) this is the bandwagon effect (or slippery slope, if you prefer). Debian did it because Fedora was already doing it and resistance seemed futile. The remaining distros even moreso.
If the overall linux community
Re: (Score:2)
If you really feel that sysvinit was something that should be kept around, [a] you're in the substantial minority; even OpenRC is mostly written in C (check their GitHub page if you don't believe me), and [b] you're welcome to maintain it -- and you should, because no one else is willing to.
There's less point NOW, but that's due to the land grab that systemd's developers performed, not due to technical evaluation... and certainly not in the Fedora 15 days. Anyone who's ever been in a large, political org with management trying to gain control of systems and services in such a way that no one objects strenuously enough at any given step, but that makes them difficult to remove at the end, should be that pattern. Or anyone who's ever been a boiled frog.
There was some guy on here complaining that people didn't get enough use out of the actual sysv init's abilities (i.e. things provided by inittab). He was absolutely right. inittab does such a bad job of managing services that practically no one used it -- certainly not for anything important. So people rewrote init functionality into their own scripts. And then they duplicated it, for each script. Sometimes better than other times. For thirty years.
And... what exactly was wrong with that? A
Re: (Score:2)
My understanding is that Red Hat is strong enough that the company was able to force systemd on the Linux community, and did that because the unfinished, poorly documented systemd brings in more money for Red Hat support.
Then systemd should also be bringing in more money for those supporting Debian, SUSE, Ubuntu, etc., etc. The saner argument for REHLs success is that support costs are lower, not higher.
Re: (Score:2)
Re: (Score:1, Interesting)
Redhat's success really has little to do with open source, other than they could take advantage of the fact that someone else created the Linux kernel for them and they could build on that.
Redhat doesn't make money selling Linux. They make money selling support contracts. When you buy RHEL that's what you are actually paying for.
No different than buying the "Enterprise" version of Windows.
Re:"Open Source" (Score:4, Interesting)
Most Products and Services in the IT world are that way. Dell Computers are more expensive not because they are better, but rather because you get "Enterprise" support. Do not underestimate the power of "Enterprise Support" in the world of CIOs and Directors of IT. They have a distinct aversion to taking the blame for bad decisions, and that "Enterprise" label allows them to shift blame to the vendors.
When you build the solution yourself, and it doesn't work, you get the blame. When you have Dell or someone else "Enterprise" build it, and it doesn't work, you can blame the vendor. That difference is worth the price for the people that care.
Re: (Score:2)
Most Products and Services in the IT world are that way. Dell Computers are more expensive not because they are better, but rather because you get "Enterprise" support. Do not underestimate the power of "Enterprise Support" in the world of CIOs and Directors of IT. They have a distinct aversion to taking the blame for bad decisions, and that "Enterprise" label allows them to shift blame to the vendors.
Exactly right. There's an old saying in business: "When something goes wrong, there better be someone you can blame".
Re:"Open Source" (Score:4, Insightful)
As an actual Director of IT, aversion to taking the blame for things that are my responsibility has nothing to do with it.
I have a limited team of people to work with, and I have a lot of things to manage, including the phone system, the data center, our office network connections, security, desktop support, and the list goes on.
What I don't have the time to do is take my small team and build brand spanking new solutions myself. I pay someone to provide 4 hour support so that when my tired ass needs to show up in the data center at 4am, there is a disk or even a whole new box waiting for me that I know is going to work. And often a technician to put it in for me.
One time, I remember mentioning looking at the price tag for some service that would cost me $10K a year and thinking I could totally do that myself. I mentioned that to someone else and he pretty much said, there is no way that you can do that for ten thousand dollars if you actually add up the costs of building and maintaining that. He reminded me of a rule I have: Only do something yourself if you know you are the best person to do it. In the end, I might save $10K only to cause myself sleepless nights and reduce the availability of my systems.
Yes, people get ripped off all the time. You won't see me touch Oracle with a ten foot pole unless I absolutely, positively, need the high end features it provides. I will use an open source DB or a cheaper commercial one. But I will still throw down money for support, because they know this stuff better than I do and can get it to work faster than I can. That makes my company able to make money and the people at it able to do their jobs. Enterprise support is not something you buy just because of the label, but if they really do provide good Enterprise support, you put that shit on your budget and you don't look back.
Re:"Open Source" (Score:4, Interesting)
We recently bought a set of servers from ___, Enterprise VMWare destined servers, and the SSDs? LiteOn. Which failed to deliver the performance needed for the job. Flat out didn't work. Granted, the company _____ replaced the drives, eventually, after we proved they were not capable. The problem I have, is I would NEVER have spec'ed LiteOn Drives for anything even close to "Enterprise".
And in the end, we wasted nearly 4 Man Months of time trying to fix the problem.
And my boss, buys Enterprise, even when I can PROVE that they are exactly the same, off the shelf consumer products, for twice the price. Me, I would buy two for the price of "Enterprise" and keep one on the shelf as a Spare. Knowing where you can get the perfomance you need, at a price that isn't "Enterprise" often allows you to stretch your IT budget AND provide the support your organization needs.
I'll pay for support, I'll even pay a lot for support. But I won't pay for "Enterprise" that is only "consumer" with a new label.
Here is BACKBLAZE's article on Drives t hat kind of supports my view ... https://www.backblaze.com/blog... [backblaze.com]
Re:"Open Source" (Score:5, Informative)
Redhat's success really has little to do with open source, other than they could take advantage of the fact that someone else created the Linux kernel for them and they could build on that.
Who funds Linux development? [gcn.com] RedHat: 11.2%
Re: (Score:1)
That doesn't change the fact in the parents statement.
Yes, the do OSS.
OSS is not why they are a 2 billion dollar company.
They are a $2b because of their investments in other markets. They own a bunch of valuable stocks and bonds, they don't produce massive amounts of revenue.
Redhat has never been 'profitable' because of OSS. Their IPO allowed them to get a quick large injection of cash which they then used to buy other stocks and bonds, and those other stocks and bonds make them a fortune.
The OSS stuff is
Re: (Score:2)
Red Hat also received plenty of VC money, so I don't know why the summary brings that up ... and VC money is not "earnings", it is equity.
Good for them! (Score:3)
I've long switched to debian-based distributions, but I remember buying boxed distros in the 90s to help support the commercialization of Linux. I'm still waiting for LOTD*, but a win's a win.
Re: (Score:3, Interesting)
I'm not so nice: I switched to Ubuntu because, as much as I dislike their politics (Mir vs Wayland, Unity vs Gnome-3, etc.), they provide software *correctly*.
RHEL will suddenly break your shit mid-release. They won't ship an out-of-tree kernel module or a patch to a kernel driver to save your life, so good luck with RHEL 6 and Intel e1000e NICs (get the -lt kernel from ElRepo; but you can't remove RH Kernel or you break LSB, so have fun managing your bootloader as it keeps switching back to the broken
Re: (Score:3)
Your complaints seem to match my experience, though it might be that we use the system differently. Fedora was great for breaking changes, but RHEL (CentOS in my case) is generally rock solid. Yes, newer stuff can take a while to get supported.
The main reason I wanted to reply is that there is a fix for your problem with the kernel updates switching back to the default kernel. Unfortunately I'm not sure it's covered in the RH documentation, but if you were to change the value of the DEFAULTKERNEL setting in
Re: (Score:2)
And that's what I get for failing to proofread until after I submit. The first sentence should read "Your complaints don't seem to match my experience,...".
Re: (Score:2)
I've had RedHat break multiple subsystems during a point release. Once, they removed an entire configuration system (crmsh) and replaced it with a completely different configuration system. They outright removed the packages. I've seen them do major upgrades of sever software on a point release and put n the release notes that certain deprecated features are now non-features and your configuration won't work if you used them.
The weirdest one was when I upgraded httpd and Apache broke because you need
Re: (Score:2)
RHEL will suddenly break your shit mid-release. They won't ship an out-of-tree kernel module or a patch to a kernel driver to save your life, so good luck with RHEL 6 and Intel e1000e NICs (get the -lt kernel from ElRepo; but you can't remove RH Kernel or you break LSB, so have fun managing your bootloader as it keeps switching back to the broken one and then dropping network entirely on a kernel OOPS). They freeze the distro at a point release (6.7, 6.8, 6.9...) as they publish security patches, while ripping out some configuration subsystems and throwing in new ones (what has worked last week no longer works today, and you can freeze your release and not get further support!).
I never use RHEL-style distributions if I can avoid it.
Yeah, this doesn't match my experience at all either. Larger than "normal" changes do happen at the X.n, X.n+1, etc points, of course, but I've hardly ever had *anything* break that wasn't well documented in the notes and usually forced by some sort of outside issue. (Breaks if we change it, breaks if we don't change it.)
About the only thing that really comes to mind was the cluster manager software somewhere between 6.2 and 6.4. Virtually everything else I can think of back to the 4.1/4.2 days has been jus
Revenue != earnings (Score:2)
Re: (Score:2)
Payroll, capital assets, power bills, etc etc.
~15% margin is respectable, a *touch* on the lean side for the industry.
Re: (Score:2)
Re: (Score:2)
You can get the same software for free quite easily, and many people do. People pay to have it selected and packaged and supported by people they trust, and so what Red Hat provides is labor-intensive.
Re: (Score:3)
Would be interesting to know where the other $1.7B goes.
Lot's of highly paid employees. Lots of them. Far more than they actually need, and hence the $1.7 Billion in overhead.
Re: (Score:2)
I shit talk Microsoft all the time, never seen one of my posts go away.
"open source" (Score:2, Informative)
closing access to the security/bug repositories except to paying customers isn't the open source spirit. RedHat forgets who made them great, it was us in the 90s that could install and try it out, and became sold on it so we introduced it at work by buying the full support.
That's why a lot of us have tossed RH over the side at work now for alternatives. Using Fedora, an alternative distro that makes the users test rats for RH brain farts, is making us 2nd class citizens.
Re: (Score:2)
They are open source, but if you want to run big-R 'RedHat', you need a goofy rhn subscription/satellite to get updates and such, instead of it just working.
CentOS is a lot more *convenient* to use as a consequence. Of course there is a more steep promise associated with 'if I installed it from RHEL repoes, RH will answer about it. RH is a careful company that doesn't make such a promise lightly. It would rather not get caught unable to reasonably support software it was the authoritative download for.
Re: (Score:2)
You would have to build binaries yourself and hope you get the settings for compilation "correct"
worth noting the binaries are NOT identical between redhat and centos and scientific linux
http://community.redhat.com/ce... [redhat.com]
Re:"open source" (Score:5, Informative)
Re: (Score:2)
those lag behind redhat of course, CentOS a month for last release, SL two months
which isn't too bad compared to past
Re: (Score:2)
those lag behind redhat of course, CentOS a month for last release, SL two months
which isn't too bad compared to past
Speaking of the past, it hasn't been like that in forever. CentOS is usually same-day, sometimes a day or two later. The only exception is usually full-point releases, which might be a week or so if something drastic changed in the ISO building/installing process.
RHEL6 > CentOS 6 was a one-off issue, although it did prove that having two downstream distros (one varying, one trying to be a completely binary compatible rebuild) is a good thing.
Re: (Score:3)
The free version of RHEL is CentOS or Scientific Linux, not Fedora. Fedora is, as you note, a upstream, fast-moving, bleeding-edge, "test" OS. If that's not what you want then you're using the wrong thing.
CentOS was created without Redhat's help when Redhat discontinued and tried to kill the open source version of their product. The gave everyone fedora so they could technically be in compliance with the open source license but they had enough glue that was not open source so that centos and fedora had to jump thru a bunch of hoops to be usable at all. So, no, CentOS is not the officially sanctioned open source version of Redhat. Redhat tried (and luckily failed) to kill off the open source version of the
Re: (Score:2, Informative)
All of what you say is accurate, however, RH don't paywall the code, just the binaries. This is how CentOS and friends exist - RH publish the source RPMs to comply with the GPL, and from the beginning ensured everyone knew they were there. They also announced that if you wanted to use them to build your own products, you would have to strip out all of RH's logos and other IP (hence the "prominent North American Enterprise Linux vendor" of CentOS).
CentOS is now pretty tight with RH as well, as they've direct
Re: (Score:3)
Bullshit
There needs to be a mod option for "dumbass" but troll will do.
There is nothing in the GPL that demands that RH do anything other than what they are doing for RHEL.
You can paywall GPL code, idiot.
Fedora is the test version.
If RHEL is out of license compliance, Fedora would do nothing to solve that.
shh
I never said it wasn't within their rights nor did I say they are out of compliance. They release the source of the parts of their OS that they are required to do so. The average user is not going to have the skills nor desire to compile their own OS. Nothing that you said negates the fact that where previously they were releasing a free open source version of redhat in parallel with their commercial version, when they switched and no longer released a free open source version that the open source commun
Re: (Score:2)
Closing access to the security and bug repositories to all but paying customers is understandable in Redhat's case, and isn't a factor for my workplace dumping Redhat. We have a few reasons (in no particular order):
1) License tracking is license tracking, regardless of whether it's Redhat, Microsoft, or Oracle. The major appeal of Free (and Open Source) software is not having to report to anyone.
2) We don't use Redhat support for anything other than software updates. The few times we used Redhat support
Re: (Score:2)
not understandable at all when they're spitting in the face that made them a success. the money is for official redhat phone support, hot fixes, etc.
note the binaries are different between redhat and centos and scientific linux, the compilation environment isn't perfectly duplicated
oh well, we've removed hundreds of redhat at work. good luck with the empty suits when us tech people won't specify you, redhat. of course, you depend on the oracle and ibm wares that list supported distros, but realize even t
Re: (Score:2)
Unfortunately, the FedGov lurves its Red Hat. It also loves Windows too. Expect that the growth in government services will keep increasing the revenues of both companies for the foreseeable future.
Re: (Score:2)
well certain parts of the federal governments operations also have Scientific Linux (RH based free of cost), SLES (some supercomputers), and Cray Linux
Re: (Score:2)
I think part of it depends on what you are doing with your Red Hats, and what the expectation is. If you are running a bunch of internal servers for computing tasks or network tasks, I think that many Linuxes have serious strengths there, and a cost benefit analysis is a pretty big deal. At my work, we've been married to Solaris, and any Linux we use would have to have the blessing and backing of an entity like Red Hat- and hopefully we'll be switched soon.
Re: "open source" (Score:3)
1) License tracking is license tracking, regardless of whether it's Redhat, Microsoft, or Oracle. The major appeal of Free (and Open Source) software is not having to report to anyone.
It's not a licence, it's support. Depending on whether you have signed a contract that restricts you further (at your own choice) or not, you can install as many copies as you like (but you would need to do some work to get updates to more instances, like run reposync on an instance that has a subscription).
2) We don't use Redhat support for anything other than software updates. The few times we used Redhat support for problem solving, the support personnel knew less about the problem space than we did. This is typical of most paid support.
We, a linux-centric team within a big telco, also only use RH support for updates for the same reason (we can almost always resolve issues quicker than it would take to get a ticket escalated to soneone
Re: (Score:2)
The issue being that if you break it, you have no one to reasonably point the finger at. This is a big deal in most commercial settings.
I have seen first hand a user of open source software sing the praises, but ultimately couldn't find another company to support *precisely* what they were using, and had to scrap it and frankly have a much worse experience for lack of commercial support. It's a big deal. Whether it should be or not.
Re: (Score:2)
The issue being that if you break it, you have no one to reasonably point the finger at. This is a big deal in most commercial settings.
I have seen first hand a user of open source software sing the praises, but ultimately couldn't find another company to support *precisely* what they were using, and had to scrap it and frankly have a much worse experience for lack of commercial support. It's a big deal. Whether it should be or not.
CentOS for your development and cloud systems, RHEL for your "important" systems or where it scales directly with revenue generation.
A $300/box license fee per year for commercial support is trivial for large enterprise systems, where the server might be handling $50,000 of annually recurring revenue and probably cost over $10K to begin with.
CentOS and RHEL are functionally identically in everything not involving 'yum' and rhn deployment, and if you're doing anything at the scale of a couple of hundred serv
Re: (Score:2)
If you have a certain sized organization, you will find that paying for RHEL support is sort of silly. You literally have hundreds of SA's and developers on your staff, many of them experts, and some even contributors. At that point, you're *better* than their support.
However, that is only true for organizations over a certain size or competence level. There are a lot of small shops who run Linux who could use the help. There are also a lot of... less capable... large shops that could use the help too.
I
Re: (Score:2)
RHEL licensing fees are precisely why my organization is migrating to Windows.
A Windows SA Site license makes it cheaper to run Windows Servers than RHEL.
Depends on the number of servers. If you've got lots of Windows servers, then you'll be spending the money on extra system administrators.
RHT is a 13 billion dollar company... (Score:5, Interesting)
Generally, when you say 'an X dollar company', people are referring to market cap, or the aggregate consensus value believed in by your investors.
Re: (Score:1)
Generally, when you say 'an X dollar company', people are referring to market cap, or the aggregate consensus value believed in by your investors.
Red Hat was founded back in 1993, which means it took them twenty years on the up to the billion in revenue. The company was something like twenty years old when it made the first billion. Soon after Red Hat made second billion, so the question remains: how long will it take to get to its third? Among the others new control panels for Red Hat, there are some worthy: https://serversuit.com/communi [serversuit.com]... [serversuit.com]
RHAT IPO (Score:1)
Re: (Score:1)
I bought as much as I could. It was open to the public, however you had to have some involvement in the company. Even if you were just contributing to bugtrack you were in. I fully support that. Why should we let those that have no involvement make a bunch of money. My lesson is I learned the difference between a market order and a limit order when it was around $300/share. Don't worry, I made plenty.
Re: (Score:2)
It's a particular sort of statement. When they said '$2B company', that *usually* refers to market cap (which can indeed be exaggerated by unfounded confidence).
To refer to a '2B company' meaning 'company that pulled in 2B of revenue in a year, that's a bit different.
Hence the errant comparison of revenue to overvalued startup unicorns.
Re: (Score:2)