11 ms·

Red Hat is pretty good at being Red Hat

152 points by ridruejo 9y ago

organsnyder 9y ago
My company (20,000+ employees) just started an engagement with Red Hat this week. We went with them for exactly what the article describes: open source software, packaged in an enterprise (i.e. expensive) fashion to make it palatable. We could have implemented these tools ourselves, but the executives appreciate the support contract and training, and I'm already seeing how we can benefit from the consultants' knowledge and clout. Red Hat is making a very strong play in the microservices/container space. Openshift is a pretty dang good k8s distro, and they're also doing a lot in the API space (especially with 3scale).
- snaky 9y ago
  That's funny how things are done in big shops. It's pretty much okay to spend a good six digit sum for some tool done by 3rd party, but just impossible to pay 100x less to someone in-house who could add a couple of features into existing in-house software on a weekend.
  - jptman 9y ago
    Often times, if the work is critical enough, you could argue paying the 3rd party with a track record, insurance or a strict contract for delivery, support is the logical choice. Sure someone in-house could do it, but if they screw up or create something that bites you down the line, is it going to end up costing more. The cynical way to interpret this behavior though is the old "No one got fired for buying IBM". Paying a big name outside company is the safe choice because you can always blame them, but if you decided to go with the in house guy, there's no one else to blame.
  - mandevil 9y ago
    This is not how paid software development works (beyond maybe stealth mode/no customers start-ups- if you have no money then you do what you have to). If you have a going business, the trade-off is totally in favor of paying someone not at your company to do this sort of thing. All up, even a new grad (= the cheapest you will find) in $NotSeattleOrSVButStillUS costs your company about one hundred fifty thousand dollars a year (more in SV or Seattle). You could have one of them spend several months coming up to speed on how to fix weird device driver issues necessary to get the latest kernel patches to run on your DB server, which costs you minimum 50k and gives you tremendous risk (what happens if a necessary security patch comes out while she is on vacation? If you train two people that's twice the costs.) Or you pay someone else to worry about that. Red Hat will charge you 2k for patches for a year for a standard server and if it doesn't work, will fix it. If writing OS network stacks are a part of your company's core mission, go ahead and do it. If the one sentence description of where your companies money comes from doesn't mention anything in kernel land, having programmers spin up on that is a waste of their time and your money. You cut RH a check and get your programmers to write you something that does bring in money, because every minute they spend porting in patches is a minute they aren't earning you money. As a side note, if your business plans for your developers to be working on a weekend you work for a terrible business and all the employees should leave and go to a place where they aren't exploited.
  - jacques_chester 9y ago
    > but just impossible to pay 100x less to someone in-house who could add a couple of features into existing in-house software on a weekend. They don't spend more money for fun. They do it because they've had experiences of many on-a-weekend projects become critical-path nightmares. Owning your own bespoke platform is a giant money hole. The arguments in favour of doing so are plug interchangeable with "let's write our own operating system kernel / database / programming language / HTTP server / CPU architecture / web framework". I also think it's a bit rude to assume that Red Hat has hundreds of brilliant engineers just phoning it in. I work for Pivotal and we are flat. out. every. day. writing this stuff, because it turns out that this stuff is a lot harder than it looks from the outside. And the reason it looks easier is because we did the hard work for you.
    - cat199 9y ago
      > They don't spend more money for fun. They do it because they've had experiences of many on-a-weekend projects become critical-path nightmares. yet strangely these sorts of straw-man organizations adamantly refuse to open source any such projects even if they have nothing to do with their business because of the perceived loss of intellectual property value..
      - jacques_chester 9y ago
        Because strangely, it's really expensive to audit your code, it's really expensive to get sued if you flub it, it's expensive to replace all the bits you can't opensource and it buys you approximately nothing in return except a comment on Hacker News accusing you of some ulterior motive.
      - zzzeek 9y ago
        if you're a business with capital-M-Money, and you put "hello world" up on github, if someone wipes out their machine running it they're going to sue you. Doesn't matter what license you put on it, you're going to need the lawyers and they cost more money than you would have theoretically gained by putting your crappy "hello world" with the accidental "rm -fr" command in it up on github.
  - organsnyder 9y ago
    You got downvoted for the hyperbole, but there's a lot of truth to this, in my experience. I don't think this is limited to big shops, either. There is a psychological phenomenon where people tend to place more value on things that have cost them more; I've experienced this myself when I've purchased a new vehicle—all of a sudden, it's the best vehicle on the market (it must have been, since I made the decision to buy it). The same thing happens with large business contracts. As an in-house employee, it is incredibly frustrating when a vendor is automatically more credible than me, even though I've spent years building knowledge of my own company's business and systems. But I have experienced this both at my current 20,000+ employee enterprise, and a previous company where there were 5 employees.
- oso2k 9y ago
  Thanks for this. Makes sure such feedback gets back to your TSM, SDM, PM, etc. Email, CSat, or otherwise. We at Red Hat REALLY, REALLY appreciate all feedback. It is how we improve our services and products.
- OneTimePaddy 9y ago
  Im sceptic none the less- usually buying into enterprise software, they try to lock there customers into a walled garden, where they are the sole provider of upgrades, new software and tailored products. I have yet to see the enterprise software, that takes the step back like steam did and provides a plattform for cutomers to trade sofware additions.
  - kiriakasis 9y ago
    I think this comment is misleading; in many situation i believe you can upgrade to upstream if you want, simply you lose RH tech support. In steam case they are not the one taking the blame when a game crashes (they take a image damage if they have too many unplayable games and they are getting criticism for it as of now for various reason) but the developer is expected to produce a game working on all platform it support as-is
StillBored 9y ago
I've been hearing the "boring" comment a lot lately, and I totally agree. I don't want the exciting filesystem (btrfs which just took me for a ride), or the exciting programming language/library that will strand me in 6 months with multiple man-years of work. No, what I want is boring. That means everything works as I expect it too, and it doesn't create drama every few months when the cool kids decide that the old way of doing things isn't cool and rewrite a library i've based my application on or change the syntax of the compiler so my code doesn't work. A few years ago, I started challenging people at work when they were trying to pull in the latest language/library/toolkit, with a simple question. "How does that help our customers". Sure, I got plenty of the 2/3rd order arguments about how making the dev team happy/more productive would result in better feature development/etc. But I've seen these kinds of changes enough to know that usually these 2nd order affects are crushed by the unseen problems that _ALWAYS_ seem to crop up after your already committed to that new technology. Its truly rare to have a new technology that is so much better than the last that the cost of switching pays for itself. That doesn't mean it doesn't happen, it just means that the immature crap everyone is yammering about is likely not that technology. Give it a couple years and if it turns out to still be around (and people are still actively switching to it) then its probably good. This mindset has produced a long list of "successful" products that pay the bills and make people happy without making a lot of noise and crashing/burning regularly. Bottom line, I will take the old "cruddy" technology with the long list of known problems, to the new cool one with the long list of unknown problems. At least part of that seems to be what RH provides for the opensource community. The old guys that actually fix the bugs, rather than switching to some cool new product.
- SkyMarshal 9y ago
  Agreed. I would add a second question to your first: What are the risks of implementing this into production? Get them thinking as a matter of habit about both of those in tandem - what's the customer benefit, and what are the risks of doing it, and does the former justify the latter? Also, all programmers have a burning desire to build stuff from scratch, which is part of what's driving yours to incorporate cool new stuff like this at a risk to your revenue. No can do. But it may be worth exploring side or 20% projects specifically dedicated to building stuff from scratch. Get their itch scratched on non-revenue projects that serve as potential useful on-the-job training and tech evaluation, while possibly getting something of value out of it.
breser 9y ago
OpenShift is a fork of Kubernetes. Case in point. OpenShift has functionality called a Route. That isn't in Kubernetes. Kubernetes of course went and added something similar called ingress. This means that anytime Kubernetes does a release that RedHat has to manage merging all those changes in with their local changes that aren't part of their project. This is exactly the same sort of thing that RedHat does with their Linux kernels. It's exactly why you RHEL has been such a terrible platform to run Docker on. Because RedHat is only pulling in some of the upstream changes into their kernels rather than upgrading everything. This sort of merging is slow, error prone and costly. If you use anything that they've added that isn't in the upstream it creates vendor lock-in. Sure OpenShift's Route code is open source, but you can't take that to any other vendor without building everything yourself. Want that new feature in the latest Kubernetes release, you better be prepared to wait. As time goes on it will become harder and harder for them to maintain this fork. If OpenShift doesn't become the dominate Kubernetes distribution then RedHat may lose interest in it and then you'll lose your maintenance of that fork. For that matter, if RedHat loses the maintainers as employees they may lose their ability to maintain this fork. It's my opinion that anyone buying OpenShift is playing with fire. The fact that RedHat has failed to get their modifications integrated upstream and have to maintain themselves is a massive failure on their part. This sort of thing was understandable in the past, but we really should expect more of them now.
- wstrange 9y ago
  My understanding is that OpenShift is more of a superset of k8s vs. a fork. I don't think the situation is going to be as bad as you are implying.
  - breser 9y ago
    A fork can imply many things, but all supersets are forks. I realize that RedHat doesn't like calling OpenShift a fork, but it fundamentally is. The only people that will maintain their additional functionality is RedHat themselves. If you manage to avoid all of their added functionality then you can avoid the vendor lock in. But you can't avoid the delays in getting upstream features/bug fixes. If Kubernetes was super stable and you weren't likely to want any of that stuff I would agree it probably wouldn't be a big deal. But it's not. Significant improvements are coming in every single release. RedHat is managing a decent pace in keeping up with Kubernetes for now. But all that it takes to upset that apple cart is for something to get added in a way that breaks their additional functionality. If RedHat doesn't have the clout to get their improvements in upstream, why should I presume they have the clout to avoid their additions won't be broken by other changes?
throw2016 9y ago
Redhat might be doing well but many open source projects clearly aren't. There are routine SOS posted here about projects in dire straits. So how much of this revenue does downstream see? Something as critical as Gnupg was recently in trouble and got funding from Stripe and Facebook. Companies like Redhat acquire projects or hire project leads for influence but few really seem to 'support' open source. Docker is a VC funded company that was entirely built on open source and has made many acquisitions so they had the money but how much support did they give the LXC project, Overlayfs, Aufs and all the other open source projects they use/used? Github uses Redis but let alone support they never even bothered to tell the author. Do they even support Git in any meaningful way? If open source is used to provide free software to startups who them promptly forget about it we will get more SOS and interesting projects will dry up. We will then be left with companies like Redhat and others building open source software requiring large teams which cannot be easily replicated by the open source model.
- StillBored 9y ago
  Redhat supports the community by providing tons of maintainers/maintenance of projects. So, they may not support $PROJECT with dollars, but for a few thousand projects they base their business on, they provide hundreds of thousands of dollars in year in engineering time fixing bugs, or updating things which are bothering their customers. Particularly on all the unsexy portions of the OS that everyone else has moved on from.
  - smarterclayton 9y ago
    Who do you think maintains overlayfs and user namespaces for containers? Red Hat :)
  - throw2016 9y ago
    'Maintenance' sounds like a takeover without compensation. Surely with $3 billion in revenues Redhat should have a open source fund to sustain people whose code they use? Shouldn't some money find its way back to all the open source projects?
jacques_chester 9y ago
I work for Pivotal as an engineer. Red Hat was my first distro, back in '97. I'm grateful. I wasn't around for the discussion about why Cloud Foundry originally standardised on Ubuntu, but if you're Red Hat, you're hardly going to bet on that. Red Hat's lifeblood is RHEL, anything which threatens it is existential. And PaaSes threaten RHEL, unless Red Hat controls their own. Red Hat deserve credit for making a big bet on Kubernetes so early on, when the picture was by no means clear. It's definitely put them well in the hunt against us as k8s picked up momentum. I think Openshift 3 plays to their historical strength, which is in packaging upstream and supporting or feeding back to the upstream. The article mentions Kubo. We're adding PKS (based on Kubo), jointly developed with Google (Kubernetes, Kubo) and VMWare (Harbor, NSX). In Labs, from the balanced product team up to the C-suite, we can transform the way you build software. A lot of companies come to us to learn how to thrive in the world of disruption. So it would've been downright silly not to spot one happening to us and ... uh ... pivot. (Disclaimer: Nothing in my comments should be seen as official comment by someone who decides anything of any consequence. Not forward-looking. Consult your lawyer, doctor, dentist and gardner before taking this comment as medication.)
strooper 9y ago
Redhat is technically doing the enterprises a big favor by adding support on top of tested open source technologies and making the applications enterprise ready. Redhat (IBM, and so on) is also doing open source community a big favor by making the open source technologies ready to compete with the closed source enterprise application providers, such as- Oracle, Microsoft and so on. If it is about packaging open source for profit, then Redhat has a lot to learn from Google. There is nothing that comes close to Android OS and Google's strategy to make the use of the term "open source" practically vague.
monkchips 9y ago
as author of the original post above, i am gratified by the quality of the commentary. thanks all!

152 points by ridruejo 9y ago

My company (20,000+ employees) just started an engagement with Red Hat this week. We went with them for exactly what the article describes: open source software, packaged in an enterprise (i.e. expensive) fashion to make it palatable. We could have implemented these tools ourselves, but the executives appreciate the support contract and training, and I'm already seeing how we can benefit from the consultants' knowledge and clout. Red Hat is making a very strong play in the microservices/container space. Openshift is a pretty dang good k8s distro, and they're also doing a lot in the API space (especially with 3scale).

snaky 9y ago
That's funny how things are done in big shops. It's pretty much okay to spend a good six digit sum for some tool done by 3rd party, but just impossible to pay 100x less to someone in-house who could add a couple of features into existing in-house software on a weekend.
- jptman 9y ago
  Often times, if the work is critical enough, you could argue paying the 3rd party with a track record, insurance or a strict contract for delivery, support is the logical choice. Sure someone in-house could do it, but if they screw up or create something that bites you down the line, is it going to end up costing more. The cynical way to interpret this behavior though is the old "No one got fired for buying IBM". Paying a big name outside company is the safe choice because you can always blame them, but if you decided to go with the in house guy, there's no one else to blame.
- mandevil 9y ago
  This is not how paid software development works (beyond maybe stealth mode/no customers start-ups- if you have no money then you do what you have to). If you have a going business, the trade-off is totally in favor of paying someone not at your company to do this sort of thing. All up, even a new grad (= the cheapest you will find) in $NotSeattleOrSVButStillUS costs your company about one hundred fifty thousand dollars a year (more in SV or Seattle). You could have one of them spend several months coming up to speed on how to fix weird device driver issues necessary to get the latest kernel patches to run on your DB server, which costs you minimum 50k and gives you tremendous risk (what happens if a necessary security patch comes out while she is on vacation? If you train two people that's twice the costs.) Or you pay someone else to worry about that. Red Hat will charge you 2k for patches for a year for a standard server and if it doesn't work, will fix it. If writing OS network stacks are a part of your company's core mission, go ahead and do it. If the one sentence description of where your companies money comes from doesn't mention anything in kernel land, having programmers spin up on that is a waste of their time and your money. You cut RH a check and get your programmers to write you something that does bring in money, because every minute they spend porting in patches is a minute they aren't earning you money. As a side note, if your business plans for your developers to be working on a weekend you work for a terrible business and all the employees should leave and go to a place where they aren't exploited.
- jacques_chester 9y ago
  > but just impossible to pay 100x less to someone in-house who could add a couple of features into existing in-house software on a weekend. They don't spend more money for fun. They do it because they've had experiences of many on-a-weekend projects become critical-path nightmares. Owning your own bespoke platform is a giant money hole. The arguments in favour of doing so are plug interchangeable with "let's write our own operating system kernel / database / programming language / HTTP server / CPU architecture / web framework". I also think it's a bit rude to assume that Red Hat has hundreds of brilliant engineers just phoning it in. I work for Pivotal and we are flat. out. every. day. writing this stuff, because it turns out that this stuff is a lot harder than it looks from the outside. And the reason it looks easier is because we did the hard work for you.
  - cat199 9y ago
    > They don't spend more money for fun. They do it because they've had experiences of many on-a-weekend projects become critical-path nightmares. yet strangely these sorts of straw-man organizations adamantly refuse to open source any such projects even if they have nothing to do with their business because of the perceived loss of intellectual property value..
    - jacques_chester 9y ago
      Because strangely, it's really expensive to audit your code, it's really expensive to get sued if you flub it, it's expensive to replace all the bits you can't opensource and it buys you approximately nothing in return except a comment on Hacker News accusing you of some ulterior motive.
    - zzzeek 9y ago
      if you're a business with capital-M-Money, and you put "hello world" up on github, if someone wipes out their machine running it they're going to sue you. Doesn't matter what license you put on it, you're going to need the lawyers and they cost more money than you would have theoretically gained by putting your crappy "hello world" with the accidental "rm -fr" command in it up on github.
- organsnyder 9y ago
  You got downvoted for the hyperbole, but there's a lot of truth to this, in my experience. I don't think this is limited to big shops, either. There is a psychological phenomenon where people tend to place more value on things that have cost them more; I've experienced this myself when I've purchased a new vehicle—all of a sudden, it's the best vehicle on the market (it must have been, since I made the decision to buy it). The same thing happens with large business contracts. As an in-house employee, it is incredibly frustrating when a vendor is automatically more credible than me, even though I've spent years building knowledge of my own company's business and systems. But I have experienced this both at my current 20,000+ employee enterprise, and a previous company where there were 5 employees.
oso2k 9y ago
Thanks for this. Makes sure such feedback gets back to your TSM, SDM, PM, etc. Email, CSat, or otherwise. We at Red Hat REALLY, REALLY appreciate all feedback. It is how we improve our services and products.
OneTimePaddy 9y ago
Im sceptic none the less- usually buying into enterprise software, they try to lock there customers into a walled garden, where they are the sole provider of upgrades, new software and tailored products. I have yet to see the enterprise software, that takes the step back like steam did and provides a plattform for cutomers to trade sofware additions.
- kiriakasis 9y ago
  I think this comment is misleading; in many situation i believe you can upgrade to upstream if you want, simply you lose RH tech support. In steam case they are not the one taking the blame when a game crashes (they take a image damage if they have too many unplayable games and they are getting criticism for it as of now for various reason) but the developer is expected to produce a game working on all platform it support as-is

StillBored 9y ago

I've been hearing the "boring" comment a lot lately, and I totally agree. I don't want the exciting filesystem (btrfs which just took me for a ride), or the exciting programming language/library that will strand me in 6 months with multiple man-years of work. No, what I want is boring. That means everything works as I expect it too, and it doesn't create drama every few months when the cool kids decide that the old way of doing things isn't cool and rewrite a library i've based my application on or change the syntax of the compiler so my code doesn't work. A few years ago, I started challenging people at work when they were trying to pull in the latest language/library/toolkit, with a simple question. "How does that help our customers". Sure, I got plenty of the 2/3rd order arguments about how making the dev team happy/more productive would result in better feature development/etc. But I've seen these kinds of changes enough to know that usually these 2nd order affects are crushed by the unseen problems that _ALWAYS_ seem to crop up after your already committed to that new technology. Its truly rare to have a new technology that is so much better than the last that the cost of switching pays for itself. That doesn't mean it doesn't happen, it just means that the immature crap everyone is yammering about is likely not that technology. Give it a couple years and if it turns out to still be around (and people are still actively switching to it) then its probably good. This mindset has produced a long list of "successful" products that pay the bills and make people happy without making a lot of noise and crashing/burning regularly. Bottom line, I will take the old "cruddy" technology with the long list of known problems, to the new cool one with the long list of unknown problems. At least part of that seems to be what RH provides for the opensource community. The old guys that actually fix the bugs, rather than switching to some cool new product.

SkyMarshal 9y ago
Agreed. I would add a second question to your first: What are the risks of implementing this into production? Get them thinking as a matter of habit about both of those in tandem - what's the customer benefit, and what are the risks of doing it, and does the former justify the latter? Also, all programmers have a burning desire to build stuff from scratch, which is part of what's driving yours to incorporate cool new stuff like this at a risk to your revenue. No can do. But it may be worth exploring side or 20% projects specifically dedicated to building stuff from scratch. Get their itch scratched on non-revenue projects that serve as potential useful on-the-job training and tech evaluation, while possibly getting something of value out of it.

breser 9y ago

OpenShift is a fork of Kubernetes. Case in point. OpenShift has functionality called a Route. That isn't in Kubernetes. Kubernetes of course went and added something similar called ingress. This means that anytime Kubernetes does a release that RedHat has to manage merging all those changes in with their local changes that aren't part of their project. This is exactly the same sort of thing that RedHat does with their Linux kernels. It's exactly why you RHEL has been such a terrible platform to run Docker on. Because RedHat is only pulling in some of the upstream changes into their kernels rather than upgrading everything. This sort of merging is slow, error prone and costly. If you use anything that they've added that isn't in the upstream it creates vendor lock-in. Sure OpenShift's Route code is open source, but you can't take that to any other vendor without building everything yourself. Want that new feature in the latest Kubernetes release, you better be prepared to wait. As time goes on it will become harder and harder for them to maintain this fork. If OpenShift doesn't become the dominate Kubernetes distribution then RedHat may lose interest in it and then you'll lose your maintenance of that fork. For that matter, if RedHat loses the maintainers as employees they may lose their ability to maintain this fork. It's my opinion that anyone buying OpenShift is playing with fire. The fact that RedHat has failed to get their modifications integrated upstream and have to maintain themselves is a massive failure on their part. This sort of thing was understandable in the past, but we really should expect more of them now.

wstrange 9y ago
My understanding is that OpenShift is more of a superset of k8s vs. a fork. I don't think the situation is going to be as bad as you are implying.
- breser 9y ago
  A fork can imply many things, but all supersets are forks. I realize that RedHat doesn't like calling OpenShift a fork, but it fundamentally is. The only people that will maintain their additional functionality is RedHat themselves. If you manage to avoid all of their added functionality then you can avoid the vendor lock in. But you can't avoid the delays in getting upstream features/bug fixes. If Kubernetes was super stable and you weren't likely to want any of that stuff I would agree it probably wouldn't be a big deal. But it's not. Significant improvements are coming in every single release. RedHat is managing a decent pace in keeping up with Kubernetes for now. But all that it takes to upset that apple cart is for something to get added in a way that breaks their additional functionality. If RedHat doesn't have the clout to get their improvements in upstream, why should I presume they have the clout to avoid their additions won't be broken by other changes?

throw2016 9y ago

Redhat might be doing well but many open source projects clearly aren't. There are routine SOS posted here about projects in dire straits. So how much of this revenue does downstream see? Something as critical as Gnupg was recently in trouble and got funding from Stripe and Facebook. Companies like Redhat acquire projects or hire project leads for influence but few really seem to 'support' open source. Docker is a VC funded company that was entirely built on open source and has made many acquisitions so they had the money but how much support did they give the LXC project, Overlayfs, Aufs and all the other open source projects they use/used? Github uses Redis but let alone support they never even bothered to tell the author. Do they even support Git in any meaningful way? If open source is used to provide free software to startups who them promptly forget about it we will get more SOS and interesting projects will dry up. We will then be left with companies like Redhat and others building open source software requiring large teams which cannot be easily replicated by the open source model.

StillBored 9y ago
Redhat supports the community by providing tons of maintainers/maintenance of projects. So, they may not support $PROJECT with dollars, but for a few thousand projects they base their business on, they provide hundreds of thousands of dollars in year in engineering time fixing bugs, or updating things which are bothering their customers. Particularly on all the unsexy portions of the OS that everyone else has moved on from.
- smarterclayton 9y ago
  Who do you think maintains overlayfs and user namespaces for containers? Red Hat :)
- throw2016 9y ago
  'Maintenance' sounds like a takeover without compensation. Surely with $3 billion in revenues Redhat should have a open source fund to sustain people whose code they use? Shouldn't some money find its way back to all the open source projects?

jacques_chester 9y ago

I work for Pivotal as an engineer. Red Hat was my first distro, back in '97. I'm grateful. I wasn't around for the discussion about why Cloud Foundry originally standardised on Ubuntu, but if you're Red Hat, you're hardly going to bet on that. Red Hat's lifeblood is RHEL, anything which threatens it is existential. And PaaSes threaten RHEL, unless Red Hat controls their own. Red Hat deserve credit for making a big bet on Kubernetes so early on, when the picture was by no means clear. It's definitely put them well in the hunt against us as k8s picked up momentum. I think Openshift 3 plays to their historical strength, which is in packaging upstream and supporting or feeding back to the upstream. The article mentions Kubo. We're adding PKS (based on Kubo), jointly developed with Google (Kubernetes, Kubo) and VMWare (Harbor, NSX). In Labs, from the balanced product team up to the C-suite, we can transform the way you build software. A lot of companies come to us to learn how to thrive in the world of disruption. So it would've been downright silly not to spot one happening to us and ... uh ... pivot. (Disclaimer: Nothing in my comments should be seen as official comment by someone who decides anything of any consequence. Not forward-looking. Consult your lawyer, doctor, dentist and gardner before taking this comment as medication.)

strooper 9y ago

Redhat is technically doing the enterprises a big favor by adding support on top of tested open source technologies and making the applications enterprise ready. Redhat (IBM, and so on) is also doing open source community a big favor by making the open source technologies ready to compete with the closed source enterprise application providers, such as- Oracle, Microsoft and so on. If it is about packaging open source for profit, then Redhat has a lot to learn from Google. There is nothing that comes close to Android OS and Google's strategy to make the use of the term "open source" practically vague.

monkchips 9y ago

as author of the original post above, i am gratified by the quality of the commentary. thanks all!