Who’s supporting your software?

Open Source Software (OSS) is starting to appear in the mainstream enterprise environment—actually, some banks have been using the OSS model for years, for software and interfaces used in inter-bank communications, for example, which is shared by many banks. Using OSS for key mission-critical developments isn’t more risky than relying on a proprietary software but it is, perhaps, differently risky—and the risks may be more visible. Visible risks are good as they are easier to manage—as long as you’re an organisation that, sensibly, believes in risk management rather than in shutting its eyes to the possibility of risk. We took the opportunity recently to discuss some of these issues with Brian Behlendorf, founder of CollabNet.

Most software acquisitions start off with enthusiasm for the “light path”, in which everything works properly. Eventually, however, success usually depends on how well the “dark path” is supported—how much useful help you can get when things go wrong.

With proprietary software, support is deceptively simple. If it goes wrong, the vendor (assuming you have a support contract or equivalent) fixes it. If it has an adequate support infrastructure. And provided, sometimes, that you accept changing the manual from “will do” to “won’t do” as an adequate fix.

With “professional OSS” from the likes of Red Hat/Jboss, CollabNet and the like, things are just about as simple. You pay for a support contract; if something goes wrong, your OSS support partner fixes it—and this OSS support partner can utilise the resources of the OSS community it supports and contributes to, if its own resources sometimes can’t deliver. In effect, you get support equivalent to that from a mega-company like IBM without all the possible implications of partnering with anything quite so powerful. According to Behlendorf, it works like this: “sometimes the solution to a bug isn’t obvious; it’s an error in design, or in conception of the use cases. In that case, the OSS vendor needs to work with the community collaboratively to address that issue. If the proposed change is large enough, the vendor can also work with its customers to understand the problem and prototype some solutions privately first, before bringing a really well-honed proposal to the OSS community. CollabNet took this approach when it worked with the Subversion community on a feature called ‘merge-tracking’, first by working with customers to understand the concept (many different features of other commercial tools were wrapped into that phrase) and then by presenting the idea to the community, and eventually leading the implementation of those ideas”.

But what can go wrong in the OSS support environment? It is well to look at the “dark side” and its consequences before anything does go wrong. There are some potential issues with OSS support and these mostly aren’t issues with OSS per se but issues with the ability of an enterprise to manage its OSS relationships. There are similar issues with managing relationships with proprietary software vendors of course, but you usually know who owns proprietary software and the first OSS issue proper is “who exactly is my OSS relationship with?”.

Is it with the OSS community as a whole; with the key sponsors of your particular piece of OSS; or with a single OSS supplier? If a piece of OSS is broken and you need a fix this week or you risk losing an important customer, who do you shout at? And are they under of any sort of real obligation to supply a fix?

Well, for a start, look at where your OSS came from—and check out the licence (OSS certainly isn’t license-free software). If you downloaded something from somewhere fairly random and it isn’t licensed for commercial use or you aren’t honouring the terms of your licence, then you have a problem. But if you have no control over what software runs in production and don’t check the associated licence obligations, then you probably have lots of problems; you just haven’t noticed some of them yet.

But let’s suppose your license is in order and the problem is with a piece of OSS with an OSS community on the Web. Will these nice OSS developers, working out of pure altruism, fix your bug? Almost certainly, eventually, because these developers have paying jobs in the software industry and they want stuff they’re associated with to work—they value their reputation. However, can you jump up and down and insist on them fixing it this week? Hardly.

OK, so this is OSS—you can just hire a contractor (or someone in the OSS community) to fix the bug in the source code for you. That’s fine, as a long stop, but it might be considered a high risk strategy, especially if you’re under time pressure. Unless, according to Behlendorf, “you want to create enduring solutions that will be accepted and long-term supported by the community—and not just the fastest hack”.

Many companies are therefore obtaining their OSS with a support contract from someone like Red Hat or CollabNet. So, if something breaks you get out your support contract and jump up and down with your OSS support partner. This can fix the problem just as efficiently as a conventional vendor would. This approach makes a lot of sense to us, especially as you get the support of a larger community although you probably do need to be aware of exactly how OSS collaboration works. According to Behlendorf again: “even a good OSS vendor with a stellar reputation shouldn’t expect that volunteers will do anything for them for free. The most it should expect from a properly functioning community is resistance to bad ideas and bad code. Any bugs reported by the OSS vendor should also come with a proposed patch to fix it; any proposal to add functions or change behaviour should come with a promise to bear the cost of implementation. Of course, additional help may show up, especially if it’s a bug that affects others or a feature others desire. But that should not be relied upon”.

Now what could go wrong with this last approach? Well, your software assets had better be under control, because your support partner is unlikely to support OSS it didn’t supply and you don’t have a support contract for. If your IT staff think that adopting an OSS strategy means that they can download software from just about anywhere and use it “ad lib” in production systems or production/development support, then you had better disabuse them of this idea fast. Or, at least, impress upon them that they’ll be expected to bear the costs of any defects or failures in the code, as if it were their own (some programmers may be happy with this, but it represents a risk the company must manage).

But there’s anther complication. Suppose you’ve simply bought software “built on top of OSS” from a vendor? Your support relationship is with that vendor. You can’t call on the OSS community (let alone OSS support vendors) directly. And if your supplier doesn’t contribute to the OSS community or pay for OSS support, then your supplier is on its own. You may have bought into its product on the strength of the community behind the OSS it is built on—but this strength is illusory if your supplier isn’t an active participant in this community (or isn’t using OSS in strict accord with its license).

As Behlendorf explains: “a company that simply uses open source software, but doesn’t wish to maintain it or have to know what’s going on “under the hood”, really should build a relationship with a corresponding OSS vendor—so that in the long run, its interests and needs are met, and represented to the core developer community”.

We think it unlikely that many companies will buy business systems without being very clear on the support issues. However, they may overlook support issues with the systems tools used by developers—who may well replace “official” tools with more agile, or fashionable, OSS equivalents—without necessarily telling management about this. And perhaps the controls which ensure that business systems support is well-governed aren’t applied so strictly in development—yet if your configuration management systems, say, fail because of a fault in OSS software underlying some of them, production systems could well be at risk. It’s all really a software asset management issue—if you don’t know what is running in your enterprise, what it is there for, where it comes from and who exactly is accountable for any defects, you can’t claim any sort of IT governance.

There are real benefits from using OSS but, as usual, you can only rely on achieving the benefits from a software strategy if you are a mature, well-managed organisation. Part of the precondition for getting benefit from OSS is that you’ve done proper “due diligence ” on the dark side in advance and, although this applies equally to proprietary software, those responsible for IT governance may not be as familiar with the OSS environment as they are with their familiar relationships with proprietary vendors.