Perforce embraces OSS – in part

I’m always amazed about how much IT is still a fashion industry—once upon a time, you couldn’t get fired for buying IBM; lately, you can’t go wrong with Open Source Software (OSS). Whatever happened to working out what your specific needs are and buying a product that matches your needs, whatever its source? And, always remember that the lifetime cost of software includes a lot more than the acquisition cost and that Open Source Software isn’t licence free—you had better read that licence, in case some lawyer decides to enforce it.

That said, OSS has advantages in terms of innovation and quality control—if it is properly managed. Which means that I like it when a commercial software vendor such as Perforce engages with, say, Git—and don’t overlook the value of Perforce’s Swarm collaboration tools to Git users. For instance, pre-commit Code Review, which now integrates with Parasoft static code analysis.

So, I was interested to talk with Mark Warren, Perforce‘s EMEA Marketing Director, about its decision to Open Source some of its IP. There are always potential issues when a commercial company embraces OSS—there can be a cultural mismatch between commercial and OSS developers and an issue of trust between customer and vendor. Customers can start to ask “Is my vendor going to give up the commercial delivery cycles and QA I’m used to”, or “can a commercial vendor truly espouse the OSS way?”. These may well not be real problems in practice, but if people believe they might be, trust can break down.

Which means that I was quite pleased to find that Perforce seems to have its potential OSS cultural issues under control. I have always been pleased with the intellectual thinking behind Perforce, but, perhaps, a little concerned, in the past, about its ability to get this over to potential customers (in addition to preaching to the converted, in its customer-base). Now, I think any communication problems are well-past.

To start with, I think its attempts to accommodate Git and keep what is good about Git, while addressing its issues, is entirely genuine. Of course, Perforce is addressing the sort of customer—and developer—where losing the odd version or achieving an inconsistent repository really does matter, because of the potential cost to the business (it isn’t just something one can work around, because the temporary loss of a business service doesn’t really matter).

Having engaged, reasonably successfully, with Git and the more serious Git-using developers, this provides a good cultural basis for giving some of its IP to the OSS movement. Perforce has lots of good (if less than fashionable) IP, such as P4Win and P4Web, which some customers still use and like, and which it still supports. It can’t, however, afford to develop it further—and giving it to the OSS movement lets its customers develop it for themselves, if they need to. Talking to Mark, it seems clear that Perforce isn’t simply dumping its legacy into OSS and washing its hands of it.

OSS supports innovation too. I was shown a Perforce-Jenkins integration, which seems like a neat idea to me, and is being developed as OSS—Perforce may put the scripts into its installers or may provide links to the Jenkins community download site. Perforce seems to be taking an active part in its OSS community and there are Perforce developers there on their own initiative—someone is even developing an OSS screen-saver, so the community must be healthy!

Of course, the enterprise OSS issue is support and, at present, Perforce’s support organisation prioritises paying customers but can cope with OSS support too, in a reasonable time. That might not be possible in future, if OSS takes off, and I was pleased to see that Perforce is anticipating any issues by, for example, recruiting ‘active developers’ to provide a focus for developing proper OSS community support around Perforce OSS.

I like the OSS approach a lot; as long as it is seen as more than an opportunity to get software without paying for it and cadging support from OSS developers without giving anything back (an OSS anti-pattern that still isn’t entirely unknown). Nevertheless, commercial software still has a place and I was also interested when Mark showed me a Forester Total Economic Impact (TEI) report documenting a very positive cost/benefit analysis around replacing older configuration management solutions with Perforce.

You can read this for yourself here, but I was a cynical journalist in a previous life and I’d just like to add my caveats to the list Forrester includes in its report. I think that quoting “582% ROI”, for example, simply lends a rather spurious degree of authenticity to the findings, which is a pity, as the analysis mostly makes sense, to me. The report relates to a fictitious company based on actual Perforce customers and you’d almost certainly get a different ROI figure if you chose different companies or even if you interviewed different people in the chosen companies—although this isn’t really a problem, as Perforce can offer a personalised report for any customer that wants to see what scores it might get. The Forrester TEI methodology is well-established and respected.

Nevertheless, I think the real importance of a report like this is that it gives a Perforce customer a pointer to the sort of cost benefit analysis it should be doing around its own specific Configuration Management implementation, not simply during acquisition, but afterwards—to demonstrate the continuing benefits of ownership, probably in a DevOps context. When Shirley Lacy and I reviewed, in essence, “what works and what doesn’t” for Configuration Management, one issue that practitioners at a CMSG conference noted was the necessity for tangible but easy-to-produce metrics and APIs. Configuration Management is doomed to failure without continuing top management supports and, trust me, “trust me, configuration management is really working for us, honest” won’t often cut it. At some level, you should be looking at the sort of analysis Forrester did and trying to produce something similar for your own management (the book already quoted has some guidelines on choosing KPIs).

As it happens. Perforce captures a lot of data around its processes and provides some useful analysis tools. What is perhaps missing is a management dashboard with pre-envisaged patterns that practitioners can use to populate the dashboard with the sort of APIs that show, on a continuing basis, that configuration management is actually good for you and your development processes—in terms of reducing business issues originating from configuration management failures. Now, perhaps that’s a nice OSS project for someone…

Putting this another way, I think that developers (in the widest sense) should have the Freedom to use the best tools for their job (whether OSS or commercial), subject to (informed and two-way) Trust between development technicians and the business, which is supported by Actionable Insights drawn from analytics applied to the actual data in the process. If this fails, developers get told, from on high, to use something, which they naturally resist using properly; which leads to business failures, which can then easily be attributed to soon-to-be-redundant developers…. Worse, is it unthinkable that even a good and effective configuration management team could be disbanded simply because top management doesn’t realise that it does anything useful for the business?