There are lots of different ways you can build software and the typical ways in which FOSS development and proprietary development are done are quite dramatically different.
In this article, I'm going to talk about what problems the typical FOSS method can face when open source products are integrated within enterprise environments. I will then go on to talk about two different companies, and how they address some of these issues.
Monolithic Releases
The trend in proprietary software development is to release relatively infrequently, but when you do, to provide a massive update. One of the most obvious examples here would be Microsoft and their development cycle with Windows.
It took them about 5 years to push out Vista following XP, and when they did, they had changed an awful lot between the releases. You could argue this example is a little extreme, but bear with me.
"Release early, release often"
Now contrast with the trend for free software/open source development. Ubuntu recently pushed out their Hardy Heron release. Ubuntu follows a 6-month release cycle, and apart from a minor blip pushing Dapper Drake back by two months a couple of years ago, they have kept to that well.
In contrast to the changes between XP and Vista, relatively little changes between Ubuntu releases.
This concept of 'release often, release early' that is so pervasive in the FOSS world has been written about in Eric S Raymond's The Cathedral and the Bazaar (very interesting read, if you're in to that sort of thing by the way).
Potential Problems for Enterprise Adoption
These frequent release cycles and constant wave of small changes to open source products can cause issues in the business environment.
Most businesses don't care what technological solution they're using to tackle a problem. All they want is something that works well, is efficient, is easy to fix when it breaks and is cheap. In most cases picking proprietary or FOSS isn't an idealogical decision, it will be based purely on how well that product meets these criteria.
The problem with the bazaar model here - i.e. the releasing early and often, is that it can become difficult to support in an enterprise environment.
As a business, you don't want to have to be constantly updating the product and potentially dealing with new features or things that might change. Change could break something that depends on that product, and getting people to do software updates and deal with potential problems those updates can cause is expensive.
Equally, though, not updating could leave you vulnerable to known security issues, for example, and could cause businesses more harm in the long run.
You can see at this point why businesses might stick with traditional proprietary software. They know how it works, when the releases will be and they know that there is always a single entity to go to for support with that product.
So how are these issues addressed to make FOSS a more attractive prospect for businesses? I'll look at two ways in which frequency of updates, and support and accountability, are dealt with, in both Red Hat and Canonical (who sponsor Ubuntu development).
Solutions - Red Hat
How this is often tackled in many environments within the FOSS community (and to a certain extent outside it) is by having two strands of a product - the stable and supported version, and the one being worked on, the development version.
Take Red Hat, for example. Back in 2004, Red Hat split their single Red Hat Linux distribution into these two strands.
Fedora would become the 'development' version. While it's stable enough to use for almost all purposes, Red Hat sell no support for it. It sometimes is used as a bit of a 'testing ground' for technologies that will later be integrated into their enterprise product. Updates come thick and fast, and you have the latest and greatest versions of packages as they come out.
Red Hat Enterprise Linux (RHEL) is generally one or two releases behind Fedora. While it integrates all the latest security fixes, it doesn't necessarily include the latest and greatest versions of software components.
Red Hat make their money by selling support contracts for RHEL. All their work for Fedora earns them very little if anything at all.
Businesses want support, though, if they are going to use a product. Its open source nature means that RHEL can be competitively priced and Red Hat's support packages mean businesses have the confidence to use their software.
Ubuntu
Ubuntu works a little differently.
Instead of two separate distributions, Ubuntu keeps a single strand which sort of goes half way between Fedora and RHEL. Security updates are delivered as soon as they are available, and quite a lot of software is the most recent version with the latest features.
After a release of Ubuntu, however, that package might not be upgraded with new features until the next release of the whole distro. This gives Ubuntu a greater level of stability and predictability than Fedora at times, but consequently can be less attractive to hardcore hobbyists who want the bleeding edge experience.
Commercial support is offered by Canonical, the parent company behind Ubuntu. Support timescales are limited, however, for each release of the distro.
Certain releases are designated with the Long Term Support (LTS) badge. LTS means that Canonical will provide support for that release for much longer, which makes the releases marked as LTS much more suitable for enterprise usage. They are also architected to focus more on stable, known versions of software than to be bleeding edge.
There is less of a visible marketing push towards getting Ubuntu in the enterprise, because of Canonical's differing commercial focus. However, the LTS releases combined with a suitable support package make for a good enterprise solution.
Red Hat vs Canonical - Support Approach Shootout
So what works best?
First of all, it is worth pointing out that Red Hat and Canonical are very different companies. Red Hat are very focused on the enterprise, while Canonical aims more towards the home desktop market (who are much less likely to be willing to buy support), so they make less of a push of their support services.
Having said that, personally I think Red Hat's approach works best. Hobbyists get to use Fedora, which gives them what they want - bleeding edge new technology, which they get to play with. The feedback from this group of users feeds into RHEL, which (hopefully) becomes a good product.
RHEL is now stable, tried and tested, and Red Hat can convince businesses that it is good, and that RH can provide that support backing for it.
With Ubuntu, I personally think that support feels like more of an afterthought than something built in to the core like with Red Hat. LTS releases perhaps don't feel distinct enough, and there is still quite a lot of stigma in the business world about using something that feels too 'free'; the belief that because you get what you pay for, free code must be rubbish.
Perhaps this lack of special branding and having a more visible 'price tag' hurts its perception by businesses from a marketing point of view.
Both ways do work, though, and these strategies do help Linux and open source products be more enterprise ready. All this clearly demonstrates how far the free software model has come since the early Unix hacker days. While as a methodology it does present its own unique challenges, it also brings rewards and allows for undercutting the competition.
