Open source's disdain for enterprise

Open source's disdain for enterprise

Summary: Just because you can, doesn't mean you should. It's a simple lesson, one learned by most of us by the time we're twenty (OK, fifty).

TOPICS: Emerging Tech

Just because you can, doesn't mean you should. It's a simple lesson, one learned by most of us by the time we're twenty (OK, fifty). But it's lost on some very high profile open source efforts, which seem increasingly to think that the workers of the world don't deserve the benefits of decent software. If something can be changed, it should — and that's a fatal approach for enterprise IT.

It's not that open source software can't do enterprise-quality jobs: obviously, it can and it does. But the dynamics of managing the workplace IT environment are just as important as the capabilities of the technology within: if you can't support something, it's too dangerous to use.

For the enterprise, stability is the cornerstone of support. With each product, you learn how to secure it, your users learn how to use it, you make it part of your systems and you trust it as a component around which you build your digital working life. Something that changes a lot - or even a little - resets the whole process when you should be thinking about something else.

So why is stability a dirty word in some open source circles? Mozilla, for so long the movie star in open source's fight back against the dominance of the closed, is openly disdainful of enterprise's need for something they can fit and forget. Not something it wants to think about, says Mozilla. The consumer is king, and the consumer loves shiny and new. The roadmap — something else enterprises love, because it's actually useful — consists of "Make it better" followed by "Make it more betterer". Thanks for that.

Canonical, too, is febrile in its approach to user contentment. Although its programme of LTS — Long Term Support — editions of Ubuntu is welcome, with guaranteed support for three to five years, it has got into the habit of making such fundamental revisions to its mainstream releases that moving on at the end of an LTS period becomes a dangerously radical experience.

Which is not to say change is bad, nor that stability can't be overdone. Look how long it's taking to expunge the rancid corpse of Internet Explorer 6 from our lives, and what benefits we're getting from the Javascript wars. Nor is it compulsory to be nice to enterprise IT. But there is not much point in claiming to be a serious alternative to proprietary software if you won't take one of its major markets seriously. And even in these hard times most consumers are workers too: why deny them the good stuff for half their days?

Open source software designed for enterprise would look rather different. There are areas where rapid change must be possible: security, for example. Other areas need a different dynamic: drivers, protocols, package integration, all need to have the ability for change outside the major upgrade cycle. But user experience should be stable. Change should come through business need, not developer foible.

That calls for a different kind of lifecycle engineering altogether, one where the modularisation of components within a product is consciously aimed at easing the long-term support issues, and one where tools are created to explicitly deal with the contradictions of needing to evolve over time without losing the advantages of stability, familiarity and tested code.

Such an approach may not suit the revolutionaries who hate to leave a good thing alone. But it is in the nature of open source that it doesn't have to - if three or four major enterprises decided to get together to create their own distribution that precisely met their needs, they could. There is any number of solid, well-featured starting points they could adopt.

Open source isn't code and it isn't a catalogue of solutions: it's a way of thinking that gives the willing the ability to solve their problems in their own way. Enterprise deserves the best of that, and it's there for the taking.

Topic: Emerging Tech

Rupert Goodwins

About Rupert Goodwins

Rupert started off as a nerdy lad expecting to be an electronics engineer, but having tried it for a while discovered that journalism was more fun. He ended up on PC Magazine in the early '90s, before that evolved into ZDNet UK - and Rupert evolved with them into an online journalist.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • I agree with the point in that a knowledgeable staff should be on hand for migrating to open source software. It takes a learning curve and patience, and resources to use it. And yes, it is true that changes are made that are not necessarily due to business reasons, as you mention. If you apply this to GNU/Linux specifically, my advice is to use a more conservative distribution like Red Hat (or CentOS, the free Red Hat alternative). Releases are maintained for years, not months like more cutting edge distributions like Fedora. Also, upgrades are generally smooth going from version to version.

    With proprietary software, users are forced to follow along with how the software vendor sees things. If the software vendor chooses to drop support for a particular version, the users are not immediately forced to upgrade, but will eventually if they want to keep support. Open source gets around this problem as the source is available and older versions can be used and built upon for many years afterward.

    I still have access to systems that are running Red Hat Linux 7.1 (circa 2001). They still run just fine just as the day they were installed, and when we need new software installed on them it needs to be compiled for that platform (unless there are binary packages available which in this case there are at the DAG repository). This takes more knowledge than normal, but it can be done. And in 5 years from now, it can still be done. Nobody can force users of open source to use the software a certain way.
  • Hi

    wow @ Rupert & apexwm

    I liked reading both your posts.


    I'll throw this out there...

    I was talking to a guy a few months ago, who had build a heavy duty home network and he suggested to me, changing file system to obscure an one increased his security. well, that got me thinking... what if.. you could recompile a kernel (as per MOL on an unusual file system that could dish out http etc, and only be a direct access PC Server (access to the box itself). otherwise it does not take commands kind of thing.

    I'll admit I know nothing about coding, but a server designed to have a panel on the box and ONLY threw that panel can you be root, sounds sensible to me. Chip based security.

    and tie the whole thing up as a secure server?

    and @ Rupert, yeah enterprise is tricky, they (enterprise) want ten years out of you at least, and FOSS doesn't work that way with propriety. but hey, remember that bad old days, not so long ago? no drivers... the community coders having to do it themselves. but as WE (the FOSS community) come closer and closer to our goal of acceptance, we need to compromise. I feel this is factual, because if you can't play nice with the other companies you're either the bully or the outcast.. and we have already been the outcast...


  • I agree with your main point, Rupert. Another example is - believe it or not - Ubuntu Server. I installed a copy two years ago on a headless server and left it to run.

    From an enterprise perspective, no management required is the best kind of management. And the server in question didn't need management until I noticed that it could no longer update, remove and generally herd applications. Turns out this version is no longer supported, the repositories seem to have been moved, and I'm left with two choices: either do a fork-lift upgrade to another system, or painstakingly figure out where the repos have gone and re-insert their locations into the right files.

    So it's a fork-lift upgrade then, and the replacement won't be Ubuntu Server.
    Manek Dubash
  • I'm always surprised when people lump all "open source" projects together, as if that characteristic dominates everything and anything else.
    The PostgreSQL database project has long pursued a high quality, very stable release policy where the stability is much more important than the release date - although we have managed to release roughly annually for most of the last 10 years. We've done that because not-losing-data is probably the single most important thing for a database, and sorry doesn't cut it. We are well aware that attitude is not shared by some, which makes us even more insistent on differentiating ourselves against people that seem unaware of security, stability and robustness requirements for enterprise grade software.
    PostgreSQL project support is 5 years on all releases, longer with commercial options, with regular maintenance releases for security and others fixes throughout that time (Our oldest supported version, 8.2 (from 2006) has just hit its 21st maintenance release, for example).
    The new PostgreSQL 9.1 release will support synchronous replication, allowing very high levels of availability - yet applications written more than a decade ago still run happily against it.
    Don't let broad characterisations cloud your judgement on software choice. There is much good and bad in both commercial and open source software. Expensive doesn't mean better, and Free doesn't mean unstable or shoddy. The internet only exists because of the low-cost of ownership, open source software on which it runs.
    Simon Riggs
  • Based on the feedback to this post, my advice would be to choose the best GNU/Linux distribution for the purpose. For a server, a distribution like CentOS is better suited because it is supported and updated for years from its initial release date. For a desktop, other distributions like Ubuntu, Fedora, Red Hat, Suse, are better candidates because they contain more current software but have a shorter lifecycle. However, upgrades can be done along the way while preserving user data.
  • Think it's going to be FreeNAS or Nexenta for me...
    Manek Dubash
  • @rupert: Thank you for the excellent post. Deciding when to change is always difficult, having to evaluate the benefit/disruption formula. "Change through need" has a nice ring though, could almost be a mantra...

    @Simon Rigg puts his finger on it: "not-losing-data is probably the single most important thing for a database", which coupled with 'not-losing-time' is kind of applicable across the board.
    Jake Rayson
  • I would like to vote for ClearOS! A stripped down version of CentOS with a web-based admin system. Used to be called ClarkConnect.