Will there ever be another Red Hat?(forbes.com)
forbes.com
Will there ever be another Red Hat?
http://www.forbes.com/sites/danwoods/2015/04/28/will-there-ever-be-another-red-hat/
63 コメント
> Red Hat will distribute improvements to the kernel in a predictable way for you.
I'd hope that means you just get read access to their linux.git if you're paying them.
If you're not paying them, in order to get access to the Red Hat 7 kernel source, there's git repo that houses a reference to a xz-compressed tarball that you download from another site which you piece back together to get a .src.rpm - inside of which is a the raw kernel.org source and a monolithic patch file.
I would also call that predictable (and thus, thankfully scriptable) process, but it's pretty convoluted. Actual git access to kernel source would be preferable.
I'd hope that means you just get read access to their linux.git if you're paying them.
If you're not paying them, in order to get access to the Red Hat 7 kernel source, there's git repo that houses a reference to a xz-compressed tarball that you download from another site which you piece back together to get a .src.rpm - inside of which is a the raw kernel.org source and a monolithic patch file.
I would also call that predictable (and thus, thankfully scriptable) process, but it's pretty convoluted. Actual git access to kernel source would be preferable.
I wasn't really thinking of source access because I don't think the vast majority of their customers need it. I was thinking more from an enterprise point of view where you're a large customer who wants confidence that Red Hat has done a bunch of testing and validation on new kernels for their particular environments.
The licensing model is another thing that is going to be a big issue as the world moves into the cloud.
So far, many of the big names in FOSS, such as MySQL, have been using GPL to their advantage. By forcing competitors to release their modifications under the same license, GPL grants the copyright owner an effective monopoly on proprietary features. RMS probably isn't very happy with this situation, but it works.
GPL, however, is nearly useless in the cloud. You can add features to a GPL program and offer it as a proprietary service running on your servers. Since you're not distributing the program itself, you don't need to open-source your changes! AGPL was designed to prevent that, but hardly anyone uses AGPL.
Moving in the other direction are LGPL, BSD, MIT, and a bunch of other "permissive" licenses that are getting ever more popular among the cutting edge of the tech scene. In an ideal world, this should lead to even more freedom and better tools for everyone. But we don't live in an ideal world.
RMS has a knack of saying seemingly outrageous things that turn out to be highly relevant 10-20 years later, so I wonder what consequences the current proliferation of easy-to-convert-to-proprietary-software licenses will have on the tech scene of the next generation. Will all the good features get locked into walled gardens, or will companies continue to see value in releasing code under a permissive license?
Today's FOSS culture didn't arise on its own. It owes its existence to a dedicated group of people, such as RMS, ESR, Linus, Red Hat, MySQL, etc. who provided a large and stable copyleft core for the rest of the ecosystem to revolve around. But if the cloud makes the copyleft core largely irrelevant, how will the rest of the ecosystem adjust? Will it even survive? I don't know.
So far, many of the big names in FOSS, such as MySQL, have been using GPL to their advantage. By forcing competitors to release their modifications under the same license, GPL grants the copyright owner an effective monopoly on proprietary features. RMS probably isn't very happy with this situation, but it works.
GPL, however, is nearly useless in the cloud. You can add features to a GPL program and offer it as a proprietary service running on your servers. Since you're not distributing the program itself, you don't need to open-source your changes! AGPL was designed to prevent that, but hardly anyone uses AGPL.
Moving in the other direction are LGPL, BSD, MIT, and a bunch of other "permissive" licenses that are getting ever more popular among the cutting edge of the tech scene. In an ideal world, this should lead to even more freedom and better tools for everyone. But we don't live in an ideal world.
RMS has a knack of saying seemingly outrageous things that turn out to be highly relevant 10-20 years later, so I wonder what consequences the current proliferation of easy-to-convert-to-proprietary-software licenses will have on the tech scene of the next generation. Will all the good features get locked into walled gardens, or will companies continue to see value in releasing code under a permissive license?
Today's FOSS culture didn't arise on its own. It owes its existence to a dedicated group of people, such as RMS, ESR, Linus, Red Hat, MySQL, etc. who provided a large and stable copyleft core for the rest of the ecosystem to revolve around. But if the cloud makes the copyleft core largely irrelevant, how will the rest of the ecosystem adjust? Will it even survive? I don't know.
"GPL, however, is nearly useless in the cloud."
Only as a commercial weapon (which was never the intent) - for other readers, MySQL is dual licensedm and it's possible to use it already without being subject to the GPL, obviously. There wasn't much pickup for Affero, all told. In many ways, it's nicer, because people who are not distributing apps are more likely to use GPL applications (though if they understand linkage, they shouldn't fear it anyway). License choices are not that important.
There are definitely ways to build proprietary application components without requiring GPL. (i.e. solutions around a GPL application that don't require directly extending the core of it with proprietary bits). Numerous examples.
The other model is basically building something that is a software consultancy / helpdesk / services org. And that's a lot of what Red Hat is.
Today, it seems many more projects are actually going full Apache. Because it's easy to extend something, it's not declining. It's accelerating.
If you make your own extensions to something and don't get them upstream, you lose the advantage of being able to consume easily what happens upstream. And that upstream development is increasingly funded by people who work at companies using those solutions - or selling them.
Cloud just makes everything to deploy faster and on even larger scale; being able to host something behind a .com in pre-widescale-cloud days was still a thing.
Only as a commercial weapon (which was never the intent) - for other readers, MySQL is dual licensedm and it's possible to use it already without being subject to the GPL, obviously. There wasn't much pickup for Affero, all told. In many ways, it's nicer, because people who are not distributing apps are more likely to use GPL applications (though if they understand linkage, they shouldn't fear it anyway). License choices are not that important.
There are definitely ways to build proprietary application components without requiring GPL. (i.e. solutions around a GPL application that don't require directly extending the core of it with proprietary bits). Numerous examples.
The other model is basically building something that is a software consultancy / helpdesk / services org. And that's a lot of what Red Hat is.
Today, it seems many more projects are actually going full Apache. Because it's easy to extend something, it's not declining. It's accelerating.
If you make your own extensions to something and don't get them upstream, you lose the advantage of being able to consume easily what happens upstream. And that upstream development is increasingly funded by people who work at companies using those solutions - or selling them.
Cloud just makes everything to deploy faster and on even larger scale; being able to host something behind a .com in pre-widescale-cloud days was still a thing.
I think the situation isn't quite that dire, based on a couple factors:
First, keeping your own private fork of a GPL library isn't all that easy an option if you also expect to be able to benefit from any further work done by the project's maintainers. By going that route you're committing to spending a lot of time and money on a lot of hairy merging.
Second, for most serious companies the open source libraries they rely on are not a part of their secret sauce. You're really not maintaining a whole lot of competitive advantage by closely holding that tweak to MySQL's query optimizer that lets your social office supply reviewing site respond to requests with 1% lower latency. Unless fractionally shorter response times is really what your company has going for it, of course. In which case it's probably doomed anyway.
I think these two factors in concert mean that it's generally much better for a business to contribute back than to try and maintain an internal fork.
Of course, businesses only contribute back to projects that they've decided to use in the first place. Using GPL code for your SASS product probably won't cause any immediate problems. It can still be a huge strategic misstep, though, because it does still limit your options for how you can pivot in the future. If you're a startup that could also mean a big drop in your value in the eyes of a potential suitor.
First, keeping your own private fork of a GPL library isn't all that easy an option if you also expect to be able to benefit from any further work done by the project's maintainers. By going that route you're committing to spending a lot of time and money on a lot of hairy merging.
Second, for most serious companies the open source libraries they rely on are not a part of their secret sauce. You're really not maintaining a whole lot of competitive advantage by closely holding that tweak to MySQL's query optimizer that lets your social office supply reviewing site respond to requests with 1% lower latency. Unless fractionally shorter response times is really what your company has going for it, of course. In which case it's probably doomed anyway.
I think these two factors in concert mean that it's generally much better for a business to contribute back than to try and maintain an internal fork.
Of course, businesses only contribute back to projects that they've decided to use in the first place. Using GPL code for your SASS product probably won't cause any immediate problems. It can still be a huge strategic misstep, though, because it does still limit your options for how you can pivot in the future. If you're a startup that could also mean a big drop in your value in the eyes of a potential suitor.
> Using GPL code ... can still be a huge strategic misstep ... that could also mean a big drop in your value in the eyes of a potential suitor.
Yes, I think this explains the dearth of GPL contributions from recent startups.
I didn't mean to imply that GPL was ever the perfect way to license code that you also intend to use commercially. It's mediocre at best for that purpose, and intentionally so. After all, why would RMS want to facilitate production of proprietaty software?
What is undeniable is that the cloud and the startup scene are leading a new trend in FOSS licensing. The recent Github statistics show more MIT/BSD/Apache licensed projects than ever before. This shift will have far-reaching consequences on the FOSS ecosystem in the long term, and I'm just not sure whether those consequences will be good or bad. We've got too many idealists and too many VC-chasers in the same room here ;)
Yes, I think this explains the dearth of GPL contributions from recent startups.
I didn't mean to imply that GPL was ever the perfect way to license code that you also intend to use commercially. It's mediocre at best for that purpose, and intentionally so. After all, why would RMS want to facilitate production of proprietaty software?
What is undeniable is that the cloud and the startup scene are leading a new trend in FOSS licensing. The recent Github statistics show more MIT/BSD/Apache licensed projects than ever before. This shift will have far-reaching consequences on the FOSS ecosystem in the long term, and I'm just not sure whether those consequences will be good or bad. We've got too many idealists and too many VC-chasers in the same room here ;)
I sure hope so, on a smaller scale. I fully plan to bite into Matlab's market with GNU Octave. Wish me luck, folks!
Good luck!
Anything that takes away from MatLab is good in my eyes. I have never had a good experience with it.
Granted, I've only ever used it for school, but it is always incredibly painful to work with. I like Octave much better.
Granted, I've only ever used it for school, but it is always incredibly painful to work with. I like Octave much better.
My biggest complaint about the uses I encountered in school is that it wasn't taught as a way to do things, it was taught as the way to do things.
It was never "here's what it means to do X, and here's how to do X in matlab", it was "to do X, do this in matlab".
It seems like one of those tools that fosters such thinking.
It was never "here's what it means to do X, and here's how to do X in matlab", it was "to do X, do this in matlab".
It seems like one of those tools that fosters such thinking.
Absolutely. My experience was that MatLab was used as a series of magic steps to accomplish what we were really after: analysis of physical systems.
The impression I get of MathWorks is that they would like to be the walled garden of engineering tools. Don't ask how it works, don't try to do it differently, just use these commands to do these certain things.
The impression I get of MathWorks is that they would like to be the walled garden of engineering tools. Don't ask how it works, don't try to do it differently, just use these commands to do these certain things.
GNU Octave is a great project.
Yet, the replacement for MatLab appears, at least to me, to be Python. The abundance of resources due to its general purposeness swamps Octave/MatLab's niche tailoring. Python is a mire flexible tool for STEM because it supports a broader array of applications.
Yet, the replacement for MatLab appears, at least to me, to be Python. The abundance of resources due to its general purposeness swamps Octave/MatLab's niche tailoring. Python is a mire flexible tool for STEM because it supports a broader array of applications.
Python does not replace the Matlab language itself. For as long as we have Matlab code, we will need Octave.
My hope is to make Octave as obsolete as Matlab itself, but so far neither is. Matlab is huge and Python has not unthroned it. It will take a combined effort to do so. Octave is but another contributor to this effort.
My hope is to make Octave as obsolete as Matlab itself, but so far neither is. Matlab is huge and Python has not unthroned it. It will take a combined effort to do so. Octave is but another contributor to this effort.
In that sense Linux doesn't replace other Operating Systems. But of course it does and that's the sense in which I used the word "replace". As with Windows and Linux, Python is used in lieu of MatLab frequently for new applications as the total number of applications grows.
MatLab is also often replaced by R these days.
MatLab is also often replaced by R these days.
Programming languages are not quite like operating systems (and even Linux has Wine). When you have a large codebase written in some language, you can't just easily throw it out and rewrite the whole thing in another language. Programming languages never really die out: COBOL is still used these days.
There is a lot of Matlab code out there, and it needs something to run in other than Matlab. That's why Octave is still important.
There is a lot of Matlab code out there, and it needs something to run in other than Matlab. That's why Octave is still important.
I didn't suggest Octave wasn't important as an alternative for MatLab. I stated my opinion that Python appears to be replacing MatLab in the niches where it dominates. If there is a new project, Python is likely to be a competitive alternative to MatLab or Octave.
You've heard of Julia?
http://julialang.org/
http://julialang.org/
To a first approximation based upon the number of times I have heard of Julia relative to the number of times I have heard of Python: nope, never heard of it.
Julia looks like a fine language. Just not being Python is enough for me to assume it's better than Python.
But I'm describing is's not ought's. If I was in charge of the ought's third graders would be learning J. I'm not. They aren't.
Julia looks like a fine language. Just not being Python is enough for me to assume it's better than Python.
But I'm describing is's not ought's. If I was in charge of the ought's third graders would be learning J. I'm not. They aren't.
Python is the clear winner. There are many other useful alternatives - another commenter mentioned Julia - but part of the reason Python wins is because it is so pervasive. It is easy to find examples and help online, and for scientists, getting results is the most important part, so anything to speed development is important.
That's a great idea! Good luck!
Oh wow, awesome to run into an Octave dev on here. Thanks for making such useful software!
Godspeed! I love to see FLOSS projects explicitly aiming to take market share from proprietary incumbents. Is anyone actively "selling" adoption of Octave? Presumably Matlab has a significant sales effort. At least there's https://gnu.org/software/octave/commercial-support.html a page too often missing from FLOSS project sites.
> Is anyone actively "selling" adoption of Octave?
Not quite. I am going try to to be the one doing that selling. I'm meeting someone today to discuss how to start that business.
Not quite. I am going try to to be the one doing that selling. I'm meeting someone today to discuss how to start that business.
There have already been two other Red Hats, and Red Hat bought them both: JBoss and Cygnus.
If there's ever another breakout in enterprise open source, Red Hat will buy that firm, too.
If there's ever another breakout in enterprise open source, Red Hat will buy that firm, too.
Red Hat will probably stay the biggest one, but there's a huuuuge room for applications in specific areas today that range far beyond the operating system.
In particular, I think Big Data and Open Networking are two of those areas.
Do they need to get as big as Red Hat is now? Defintely not.
Levine's (linked) comment that OSS companies can't execute on Product Management is incredibly short sighted, if done correctly, they have infinitely more data than their proprietary counterparts. But later on he seems to be saying that there can't be another people keeping it as "pure" ... well, no, Red Hat isn't really a product company. I'll get to that.
The first article itself doesn't seem to know what Red Hat really is either, saying "Red Hat has become a technology sommelier that selects the best of open source infrastructure and development software and organizes it into packages to solve enduring problems for enterprise computing.". It's more about support of base OS. Really. All the packaging stuff makes that possible, but the various products that Red Hat buys and sells are tiny in comparison.
Whether we like it or not, if you are building building-block software the expectation is now that these components be OSS. Proprietary software is generally viewed as acceptable in SaaS apps and end-user products, but is growing less acceptable in application substrates, programming languages, and the like.
Red Hat is doing well because of a lot of big (read: bank) customers needing expertise on kernel/hardware related issues, other companies will likely grow differently.
If people are asking for "another" Red Hat, what do they want? It's really a meaningless phrase in a way. I don't think they want Red Hat's various ancillary products, I think they mean something with the teeth of an operating system company.
Red Hat is great, and in many ways still is. There are many more interesting things to do instead. The comparison of thing-that-is-a-company-but-not-in-the-same-space with Red Hat is typical VC meaningless-ness question.
Maybe it's asking "can something get so big without being an OS company". I think it can, because the OS is largely a solved problem, and there is lots to be done is going to appear on top of it - but I'd also rather companies didn't try to get that big, and just concentrate on making one or two awesome things, and there being lots of awesome things.
In particular, I think Big Data and Open Networking are two of those areas.
Do they need to get as big as Red Hat is now? Defintely not.
Levine's (linked) comment that OSS companies can't execute on Product Management is incredibly short sighted, if done correctly, they have infinitely more data than their proprietary counterparts. But later on he seems to be saying that there can't be another people keeping it as "pure" ... well, no, Red Hat isn't really a product company. I'll get to that.
The first article itself doesn't seem to know what Red Hat really is either, saying "Red Hat has become a technology sommelier that selects the best of open source infrastructure and development software and organizes it into packages to solve enduring problems for enterprise computing.". It's more about support of base OS. Really. All the packaging stuff makes that possible, but the various products that Red Hat buys and sells are tiny in comparison.
Whether we like it or not, if you are building building-block software the expectation is now that these components be OSS. Proprietary software is generally viewed as acceptable in SaaS apps and end-user products, but is growing less acceptable in application substrates, programming languages, and the like.
Red Hat is doing well because of a lot of big (read: bank) customers needing expertise on kernel/hardware related issues, other companies will likely grow differently.
If people are asking for "another" Red Hat, what do they want? It's really a meaningless phrase in a way. I don't think they want Red Hat's various ancillary products, I think they mean something with the teeth of an operating system company.
Red Hat is great, and in many ways still is. There are many more interesting things to do instead. The comparison of thing-that-is-a-company-but-not-in-the-same-space with Red Hat is typical VC meaningless-ness question.
Maybe it's asking "can something get so big without being an OS company". I think it can, because the OS is largely a solved problem, and there is lots to be done is going to appear on top of it - but I'd also rather companies didn't try to get that big, and just concentrate on making one or two awesome things, and there being lots of awesome things.
Cloudera, Hortonworks, and Pivotal are shaping up to be possible contenders and most of the large players are pretty openly announcing that they're planning IPOs. Big Data platforms are a lot like OSes in how they'll schedule jobs and allocate resources for you across nodes. What's bothered me a lot about these stacks is how significant the overhead is and how little really technical work has gone into them like we had developing kernels from the 70s to even today. Most Big Data articles are... not exactly meant for developers while mostly engineers cared about OS design back even to the early 90s as Windows v. Macs v. OS/2 wars still were argued.
Probably not. Just like there has not been a new IBM, Microsoft, Google or Facebook. New things will dominate new areas, not compete with existing giants, until they're quite large already. Usually, at least.
SuSE seems to me pretty much like another Red Hat
Supercomputing aside, SUSE seems to always be playing second fiddle to Red Hat. Saying that SUSE is another Red Hat is like saying that AMD is another Intel; it's kinda true, but there's a quantitative difference that's more important than the qualitative similarities.
Interesting analogy--one wonders if Red Hat has engaged in anti-competitive measures in order to stifle their competition.
Like, you know, pushing for the adoption of weird and tricky things like systemd before they're ready.
Like, you know, pushing for the adoption of weird and tricky things like systemd before they're ready.
Really? Fedora is my first choice for desktop OS, worked for companies that RedHat was their first choice for server OS, hosted some of apps on OpenShift and currently I am setting up my Ghost installation, also on OpenShift.
Last time I used any of SuSE's products was about seven years ago (when I was 14), when I couldn't install Linux on my mother's PC and played around with their LiveCD from a magazine.
Last time I used any of SuSE's products was about seven years ago (when I was 14), when I couldn't install Linux on my mother's PC and played around with their LiveCD from a magazine.
You should really try SuSE again. I was a Fedora user too until I recently decided to try OpenSuSE and aside from a few quirks I think it's one of the best out of the box experiences I've had on Linux.
Main issues I had came down to knowledge of the OS. Their default software repos don't seem to have nearly as many programs as Fedora/Ubuntu, but by adding a few external repos you'll get all that back.
Main issues I had came down to knowledge of the OS. Their default software repos don't seem to have nearly as many programs as Fedora/Ubuntu, but by adding a few external repos you'll get all that back.
Fedora's my first choice as well, but it's clear that Ubuntu and SuSE are more popular with somebody: a lot of binaries are compiled for them instead of Fedora (different glibc's, different package names/dependencies). I don't know if Ubuntu's more popular with those specific developers, or if it's more popular with the customers of those projects, but it's more popular somewhere.
And of course there's Canonical, who is trying really hard to compete in the same market as Red Hat and SuSE.
But neither is even close to matching Red Hat's sheer size, profitability, and reputation.
But neither is even close to matching Red Hat's sheer size, profitability, and reputation.
That's quite interesting. As a nearly pure desktop user Canonical is everywhere, even making painful decisions in the community that others can't fight due to size differences, and only once or twice a year I'm reading Red Hat. Never thought of it as the big guy in the room.
To your anecdote, I hardly see Ubuntu mentioned in the enterprise space. Ubuntu is a little desktop player like Apple.
What does enterprise space mean exactly?
I ask because I know Google uses their own version of Ubuntu and while I was at Amazon we also used Ubuntu. Do these companies not count as enterprise? Most companies I've interviewed at also used Ubuntu. I guess I'm just wondering if this is unique to the software industry and whether or not that's included in "enterprise".
I ask because I know Google uses their own version of Ubuntu and while I was at Amazon we also used Ubuntu. Do these companies not count as enterprise? Most companies I've interviewed at also used Ubuntu. I guess I'm just wondering if this is unique to the software industry and whether or not that's included in "enterprise".
That's the best part about these words, they can mean whatever anyone wants them to mean.
Also, what I said really shouldn't be counted as any interesting data point. I was simply responding to someone who thought, based on what they heard, that Red Hat was not a big player.
Also, what I said really shouldn't be counted as any interesting data point. I was simply responding to someone who thought, based on what they heard, that Red Hat was not a big player.
Ubuntu's focus isn't really the traditional enterprise space, it's the cloud space, where it is doing very well.
SUSE is doing well and while not as large as Red Hat, continues to make valuable contributions to OSS across the board.
According to Wikipedia by employee count Red Hat (7500) is 10x the size of each of SUSE (750) and Canonical (700) but the SUSE and Canonical numbers cited are a few years out of date.
Anyone have more up to date numbers or other ways to characterize overall size or contribution to open source? Am also curious whether SUSE or Canonical do any public policy, perhaps just as a side effect of selling to governments. Red Hat apparently has a "Global Public Policy" department though there's little info about it on the web. In theory a larger entity can reap more benefits of policy activity including lobbying, so will do more of it.
Anyone have more up to date numbers or other ways to characterize overall size or contribution to open source? Am also curious whether SUSE or Canonical do any public policy, perhaps just as a side effect of selling to governments. Red Hat apparently has a "Global Public Policy" department though there's little info about it on the web. In theory a larger entity can reap more benefits of policy activity including lobbying, so will do more of it.
I don't have any good answers to that, sorry. I know that SUSE and Red Hat worked together on the live-kernel-patching stuff just shipping with kernel 4.0 and work together on a number of other open source projects as well.
There is no denying the size of Red Hat, and thus its influence. I'm just thankful there are other out there doing the good work as well.
There is no denying the size of Red Hat, and thus its influence. I'm just thankful there are other out there doing the good work as well.
Well, there will be another Red Hat, in the same sense that Apple and Samsung is another Kodak.
Isn't Microsoft slowly turning into another Red Hat?
They're slowly turning into another IBM.
It's a smaller market, but I'd consider 3D Robotics to be another RedHat. Arguably the most complex component in the drones is the flight controller, and both the hard and software that 3DR uses for their FC is open-sourced.
GitHub? But it's market is much smaller- just the 5% of computers that develop code. The vast majority just consume apps.
GitHub could extend their offerings to the broader market of distributed/collaborative content creation.
GitHub isn't open source, but maybe GitLab (ignoring that it wouldn't be totally analogous to Red Hat, which doesn't do "open core" with proprietary "enterprise" versions, though IIRC it did try that a couple times in past.)
Clearly Red Hat should buy GitLab and make it 100% open source. :)
Clearly Red Hat should buy GitLab and make it 100% open source. :)
Is Red Hat still primarily funded by US Military contracts? That's what worries me most.
Citation needed? I don't believe that was ever the "primary" case. They do have a lot of financial industry customers.
The usage of RHEL is public, but I don't know if the numbers are public. If I can dig them up I will. My sources are a few ex-RedHatters.
If true it's concerning because RH has a huge influence on everything in the base repo, so that reverberates out to the greater open source community. Not cool when you think about the possibilities of influence the US Military could affect.
If true it's concerning because RH has a huge influence on everything in the base repo, so that reverberates out to the greater open source community. Not cool when you think about the possibilities of influence the US Military could affect.
The US DoD influenced the development of the internet. Not sure it's all as black and white as easy absolutism demands.
"Not cool when you think about the possibilities of influence the US Military could affect."
I think it's pretty cool.
Much of the influence of the government on Linux has been positive, though they are not as involved now, SELinux is a fine example. Emphasis on security benefits all nations.
Another possible example might be getting to more reliable network communications.
I think it's pretty cool.
Much of the influence of the government on Linux has been positive, though they are not as involved now, SELinux is a fine example. Emphasis on security benefits all nations.
Another possible example might be getting to more reliable network communications.
The Navy uses IRC for ship to ship communications but they haven't solved netsplits yet :-)
I think Sonatype's doing for Java what Red Hat did for Linux.
This is a misunderstanding of how the development of Linux works. It's not a project in the conventional sense and never has been. Anyone can contribute as long as their code is good enough and solves a problem or adds a feature. But because the code is under the GPL, no-one can take others' work and make it proprietary. It creates a level playing field for customers because OS development is not their core business but rather just a cost of doing said business.
It's also a misunderstanding of the value Red Hat brought - and still brings - to enterprise software. A subscription buys you enterprise support, certification with third party vendors and the guarantee that Red Hat will distribute improvements to the kernel in a predictable way for you.