How Red Hat Can Recapture Developer Interest 232
snydeq writes: Developers are embracing a range of open source technologies, writes Matt Asay, virtually none of which are supported or sold by Red Hat, the purported open source leader. "Ask a CIO her choice to run mission-critical workloads, and her answer is a near immediate 'Red Hat.' Ask her developers what they prefer, however, and it's Ubuntu. Outside the operating system, according to AngelList data compiled by Leo Polovets, these developers go with MySQL, MongoDB, or PostgreSQL for their database; Chef or Puppet for configuration; and ElasticSearch or Solr for search. None of this technology is developed by Red Hat. Yet all of this technology is what the next generation of developers is using to build modern applications. Given that developers are the new kingmakers, Red Hat needs to get out in front of the developer freight train if it wants to remain relevant for the next 20 years, much less the next two."
IT departments, on the other hand... (Score:5, Interesting)
From working in Linux-based IT for nearly a decade now, IT departments get very frustrated by Red Hat's package management and the concept of needing both an Entitlement and various Channels to get updates; on the flip side of this summary is Ubuntu, which IT departments can't stand due to it's constant change and instable nature. Every IT department I've worked in and with seems to prefer administering and deploying Debian and battles with devs on Ubuntu and management on Red Hat.
Red Hat move too slowly (Score:5, Interesting)
The great benefit of Red Hat is that it's stable and supported for a very long time, like 20 years. They don't change anything major in a release, and releases are few and far between. This is great for 'Enterprise' stuff, but the web is moving quickly and package support for RHEL boxes isn't great.
Having said that, where I work we have lots of stuff on RHEL/CentOS, and more and more stuff on Ubuntu. The Ubuntu stuff keeps me awake at night - literally. It's always falling over. I have never experience a kernel like the one the Ubuntu team are putting are. It's absolutely atrocious. The biggest problem is that the software we need to use has better support for Ubuntu than RHEL, so we're stuck using a dire OS to run it on.
The RHEL and CentOS boxes we have are rock solid stable and have never really given us significant issues. I walk into the office and get a new Ubuntu problem every day.
(FWIW I use Debian for all my own stuff exclusively, so I know my way around Debian-derivatives - this isn't a configuration issue).
Re:No offense to Unbuntu but.... (Score:1, Interesting)
I would disagree with you. Despite the desktop-ness of Ubuntu, the distribution comes with a lot of things set up right. RedHat, on the other hand, assumes you're an idiot and treats you accordingly. Which of the two has rm aliased to 'rm -i' by default? RedHat. I'm not a fucking DOS user, I know that I want to delete something, this is supposed to be UNIX. Which of the two limits each username to 1024 threads/processes (ulimit -u)? RedHat again, a supposedly enterprise server distribution. Which one has /sbin only in the PATH of the root user? RedHat again. I don't want to fucking 'su' or do the full path to run ifconfig.
Plus, RedHat are the one pushing for new and untested systemd. That's another example of something you don't expect of a stable server distribution.
No, RedHat is not 'cool' or stable. They're fishing for consulting dollars, and they're trying to monopolize Linux mindshare by pushing systemd (themselves being the authors), and injecting it as a dependency everywhere else.
Development cycle (Score:5, Interesting)
Agile developers expect agile everything. Ubuntu happens to just be a happy compromise between agile and waterfall.
If you look at RHEL, it's 5-10 year old packages, kept alive by an enormous engineering team that backports fixes to old, dead software, which creates a huge pile of technical debt for any developer trying to use "modern", highly modular frameworks.
As far as developers go, In the Ruby, Python, and Node ecosystems, anything that's not the latest doesn't exist. They don't use the system package management, they use gem, pip, and npm. They really don't care about the underlying OS, until it gets in the way, and getting in the way is exactly what a decade-old OS does.
Just to throw out an example. Take some modern ruby on rails application, say Discourse. (discourse.org). Go download a tarball from github. Now try to make it work with nothing but software from the official RHEL repository. Let me know how that works out for you. After you tear out all your hair and skin trying to do that, try to get the pieces from 3rd party repos that will make that work. See how much you have to bring in as far as new libraries and new packages just to make it work. It's still a nightmare even with the 3rd party repos, and that RHEL support contract doesn't cover them - every single piece that's likely to break your application, is now outside of your support agreement, so your company is now wasting at least $799/year for support.
As soon as they start trying to develop on RHEL, the dirty hacks start. There are things missing - the versions of software that they need to make their dependancies work don't exist on RHEL. They end up in a kind of dependancy hell fighting with libraries that are a decade too old to compile their dependancies. One thing leads to another. Eventually, you recreate an entire current OS in /usr/local, or install one piece by piece from 3rd party repositories. At that point, it's not RHEL anymore. It might still say it's RHEL, but it's a bastardized system that looks more like an evil child of Gentoo and Fedora. (both of which are fine distributions by the way, just they aren't meant to crossbreed). The only thing you have left of RHEL at that point are the parts your application doesn't care about, which is probably not much.
Or, you can attempt to containerize with kvm, chroots, or lxc, which, while not breaking the underlying system as badly, means the application is really running on something other than RHEL.
If Red Hat wants developers back, they are going to have to be able to deliver a product with an agressive delivery schedule, maybe even a rolling release, and be able to deliver the kind of support to make operations feel good. That's a whole new territory, that nobody has touched yet, but if they are up to the challenge of keeping decade old software on life support, they are probably up to the challenge of an agile OS.
Re:Mission Critical ... Red Hat... LOL.. (Score:5, Interesting)
The whole point was that developers influence the choice of distro on the server
There must be cases where this is true. However, it's really unclear to me why most developers would care and why they would feel themselves qualified if they have competent sysadmins to work with.
When I've got my sysadmin hat on, most of the developers I work with are developing on Macs. They have no hangups about their code being deployed on EL systems in a big data center. Nobody is clamoring for a shelf full of MacPro tubes to deploy on.
When I've got my developer hat on, I usually write on a Fedora machine. But I'm not daft enough to try to run Fedora on a server and have to worry about the maintenance cycle. I put my configs in a puppet module that pushes the code out to whichever VM I'm going to run it on, regardless of the OS, hypervisor, hardware, or country that code is bound for.
If my code doesn't run on a particular distro, then my code is probably broken (or my devops is hosed).
Maybe there are some startups with a bunch of kids and one third-careeer CEO and they all tell him what's going to happen. Good for them, I guess. Someday a sysadmin might come in and help them fix their stack. Let's not speak of the failwhale.