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.<p>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.<p>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.<p>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.
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.<p>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).
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.<p>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.<p>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.<p>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.<p>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.<p>It's my opinion that anyone buying OpenShift is playing with fire.<p>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.
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?<p>Something as critical as Gnupg was recently in trouble and got funding from Stripe and Facebook.<p>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?<p>Github uses Redis but let alone support they never even bothered to tell the author. Do they even support Git in any meaningful way?<p>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.<p>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.
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.<p>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.
I work for Pivotal as an engineer.<p>Red Hat was my first distro, back in '97. I'm grateful.<p>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.<p>And PaaSes threaten RHEL, <i>unless</i> Red Hat controls their own.<p>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.<p>The article mentions Kubo. We're adding PKS (based on Kubo), jointly developed with Google (Kubernetes, Kubo) and VMWare (Harbor, NSX).<p>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.<p>So it would've been downright silly not to spot one happening to us and ... uh ... pivot.<p>(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.)