A need for better OSS (Open Source Software) governance

I was at a BCS Configuration Management Specialist Group Open Source Software (OSS) workshop on “Just how do you manage Open Source Software in the Enterprise?” on Tuesday – and the answer seems to be, with some difficulty and the help of the right software.

According to Alan Morbey (Configuration Manager at the Met Office), left to themselves, developers will use tools such as Apache Maven and GitHub to pull code components (or libraries) from just about anywhere on the web into their builds, and this just isn’t good governance. Even assuming that the particular OSS components picked up actually work and don’t cause other people’s code to break, OSS code is not licence-free code—it comes with a licence, sometimes one that just might obligate you to freely release any code using it (and any intellectual property, IP, it contains) to the public domain. Of course, with OSS there’s no software vendor to send in the auditors (and I don’t really see doing that thing being part of, for instance, the ‘Apache Way’) but just suppose that one of your commercial competitors (or a predatory law firm) noticed that that your expensive flagship product used a library with a licence that compelled you to ‘open source’ it? I’ve been told that when Microsoft released some of its software as OSS it spent a year cleaning it up first (as an aside, that’s one reason why OSS is becoming popular—if you put your code into the public domain, you usually take its quality fairly seriously).

There are other governance issues associated with OSS, of course, so it needs to be subject to configuration management, just as any other software asset should be. You need to know what it is, who is using it, what version it’s at, and so on (so if it has a security exposure or a known issue, you can do something about it). Alan puts a whole range of products (not all OSS) around his developers’ Git code repositories in order to ensure defensible governance—such as Artifactory and Black Duck—and recognises the importance of educating his organisation in the importance of all this. His developers have to ‘buy in’ to OSS governance and his management has to appreciate the risks associated with poor governance.

I was talking about this before the meeting with Martin Callinan from Source Code Control Ltd. Martin is of the opinion that the SAM (Software Asset Management) community is too focussed on commercial software licence compliance. He thinks that OSS is becoming ever more important for government and commercial organisations and that it must be managed just as commercial software is. We now have a chance to get a grip on OSS governance while the issue is still manageable, he says.

Martin is selling software and services that he sees as being part of the solution, of course, but I must say that better management of OSS resonates with me. Part of the problem, I think, lies in a con-trick perpetrated (mainly in the past, it must be said) by software vendors on their customers. The vendors came up with complicated and opaque licensing schemes; made identifying software without ‘false positives’, using automated tools, difficult (because software IDs embedded in the code weren’t standardised); and became rather complacent about companies paying for shelfware. The vendors then (using the threat of audits and lawyers) made their customers pay for resolving a problem largely of the vendors’ own making. The net result has been that SAM in an organisation concentrates on licence compliance for products sold by companies known to send in the auditors and ignores OSS (and some commercial products) where this isn’t an issue.

This is a real governance issue—a short-sighted approach to SAM wastes IT resources and real money. If a licence isn’t being used, there is value in not paying for it, of course, and this is often used to justify SAM initiatives. But there might be even more more value, if the software is well-designed and addresses real business issues, in training staff better and increasing its use—even, perhaps, in buying more licenses (cost reduction is trumped by increasing business value—although the latter is often harder to put monetary value on). There are also governance issues associated with poor management of the sort of software-associated risks alluded to the above, at the start of this blog, of course.

Software is not an asset in quite the same way as a physical server is but it is a non-tangible asset that should provide business value (its value is more that the acquisition cost of buying the box it comes in) and, in a well-governed organisation, it must be managed. OSS is still software and should be within the scope of SAM and configuration management. SAM practitioners need to look at the bigger picture before it gets out of control.

In fact, I think the conventional licensing model may be on the way out, as software which meters its own usage and then charges by actual usage may be a more attractive option than paying for a license, which usually involves guessing what your usage s going to be. And, even physical assets such as servers are being supplied as less-tangible services, IaaS, with SLAs and rental charges to manage. Perhaps we should be thinking about re-inventing SAM as Services Asset Management with software as just a special kind of service!