Versioning, versioning everywhere

Perforce exemplifies the “conservative” approach of Christopher Seiwald (CEO and founder of Perforce Software)-do just one thing (version management) and do it really, really well. Don’t expand into ALM (Application Lifecycle Management) and don’t add features just because “featuritis” attracts attention in the comics. And, configuration management is a really big field all by itself-Seiwald quotes one of his partners from a quarter of a century ago: “everything is a configuration management problem”.

Well, I have some sympathy with that approach (a lot of sympathy, in fact) but there is a potential risk of being so conservative that you lose touch with a changing world. Thankfully, Seiwald seems to be aware of this and the changes that he announced in his Keynote at Perforce’s 2011 User Conference in San Francisco (see here), although fundamentally evolutionary in nature, are significant enough to be revolutionary in effect.

He hasn’t lost touch with his old mantra: “with Perforce, you never have to change, but you’d like to”. Basically, all of the Perforce its customers currently use and, presumably, love still works; but he is now talking about taking Perforce up a level and making it into a fundamental platform for enterprise computing. Which makes sense, if you believe (as I do) that good technology governance has to be built on the foundation of a solid configuration management process.

Seiwald is moving away from calling it configuration management, however. He prefers to talk about “versioning everything” (I wonder if I can sell him “pervasive versioning”) or “version management”. He thinks that the term “configuration management” has picked up a lot of baggage and frightens people (and especially programmers). This is probably true, and I have a lot of respect for Seiwald and his understanding of developers, but it still leaves me a little uneasy. “Configuration Management” (CM) is an accepted name for a process (with CM professionals, anyway), and the configuration management service or CMS is fundamental to the independent ITIL framework-so the term has real credentials. It is about managing the way in which the pieces of a complex system fit together and change on into the future, whereas “version control” is just a part of this, showing how some of the pieces in that complex system have changed over time and letting you restore them to a known past state.

People, I suspect, may well confuse “version management” with “version control” after all; and overlook the whole configuration management process and the relationships it maintains. However, since they already probably think that “version control” and a single CMDB (Configuration Management Database) product is all anyone could ever need, their understanding of the configuration management process probably won’t be any worse than it already is. So, perhaps it doesn’t really matter if you call it “version management”; whatever you call it, it’s about Process, not just about the tools that enable it or the CMDBs (there should probably be several, federated) that hold the data.

So, what is Perforce’s new Big Idea? Well, to me, it’s what Seiwald calls the Perforce Ecosystem (see conference slides here). I rather think that “versioning ecosystem” or “CM ecosystem” might be a better name; it isn’t fundamentally a single vendor thing but a way of thinking about managing your environment which Perforce fits in with particularly well. This Ecosystem is enabled by adding JavaScript and HTML to Perforce’s GUI and admin tools and using its Javascript API to support Perforce Web Services. I also note that Perforce is now working on supporting a federated repository which, implemented properly, will deliver the benefits of physically distributed data and logically centralised control, both at the same time; and is also extending into the Cloud. Now you can build your own applications and use Perforce Web Services to give them strong versioning underneath, neither re-inventing the wheel nor breaking any existing web-application infrastructure-and the proof-of-concept will be really easy to set up in a hosted environment.

According to Mark Warren (EMEA Product Marketing Manager, Perforce): “I think it’s important to think of it as two things-Perforce as a platform (a chance to coin a new acronym perhaps-PaaP!) where APIs and new web services allow us and 3rd parties to build innovative new solutions; Chronicle and Commons are examples. The Ecosystem starts with beefed up community discussion forums but will rapidly grow to include resource sharing (e.g. Admins publishing their tools or scripts) and to 3rd parties offering commercial tools and add-ons”. I’m also pleased to note that Warren mentions Perforce’s “intent to Open Source some of the work we’re doing in building on the platform so that others can see how we use it and inspire their innovation”.

Perforce is already used for a lot more than just managing software development. Pixar, for example, is using it to mange picture assets and for provisioning its desktops. Now, developers can extend Perforce into managing any assets they need to manage, without waiting for Perforce to implement any changes they need. And Seiwald talks about an Appstore, where such developers can sell their products, sharing a percentage of the revenue with other stakeholders (such as Perforce). If this takes off, Perforce will find itself in the happy position of taking a small percentage out of a large and ever-increasing pie. By letting go of Perforce, to an extent, in the Ecosystem, it generates a larger community people who are relying on Perforce-and even if the Ecosystem comes to include non-Perforce or OSS tools (as I think it might, if it really takes off), Perforce was there first and is best-positioned to supply its framework.

As I keep saying, everything needs version management-not just software. Perhaps a particular issue at the moment is web content; when the regulators come calling, they may want to see exactly what your website said when a customer complained, not what it says now, and they’ll want you to be confident (and with good reason) in the accuracy of what you’re telling them. Without strong version management, it’s hard to see how to make this work, so web application designers will want to build in version management-and now they can, without having to write it from scratch.

On the other hand, if you just want to use Web content without building an industrial-strength Web application, Perforce is developing a solution for this too-Chronicle (the user conference slides are here], a web content management system built on top of Perforce. But supposing you just want simple, online document management-but with versioning? Well Perforce is starting on a project it calls “The Commons”, which promises to provide “the simplest of access to Perforce for the simplest of uses” using its new web services-you will simply drag a document out of Perforce onto your desktop to work on it and then drag it back to Perforce when you’re finished. There’s not much published about this yet; according to Warren: “this is very much early concept stage at this stage but points out how we see “Version Everything” touching all business IT users and the kind of user experience that will be needed for non-technical staff. The only information we’ve published so far was in Christopher’s keynote”.

Chronicle and The Commons are being developed by Perforce, using its Ecosystem tools, so is the wider Perforce Ecosystem outside of Perforce just pie in the sky? No, the fundamentals underlying the Ecosystem are a reality today at the NYSE (New York Stock Exchange)-probably elsewhere too, but the NYSE will talk about it-probably because “everything we do [at the NYSE] is potentially audited or regulated”. So, the NYSE has built its internal systems, largely independently of Perforce, on Perforce as a platform (see conference slides here, videos to follow)-and I think that this is an exemplar of what others will want to do tomorrow.

All Perforce is now doing, with its new initiatives, is to make what the NYSE did easier. With the JavaScript API and Web Services APIs, its services are more accessible and easier for anyone to use; providing Perforce in the Cloud makes initial provisioning easier; it’s facilitating its “community” using social networking approaches; and it’s setting up an open market place, so people in the Ecosystem can themselves benefit from it.

I find this very exciting, because I feel that governance generally is all about “what you have, where it is, how it is configured, the history of how it got where it is; and where it is going”. Which implies that people will start wanting to apply version management far more widely than it currently is and, if Perforce’s Ecosystem provides a way to enable this, without Perforce (and its product roadmaps) becoming a potential bottleneck, then the future is rosy both for Perforce and for effective governance.

Of course, there is already an OSS version control ecosystem around Subversion but (without considering the relative merits of the tools) this has its own developer-focussed culture and may not be to the taste of many non-IT people with a need for version management. Warren has his own view on this, of course: “I think it’s worth considering the strengths of the Perforce server in being able to make innovation possible. The performance, scalability and focus on versioning all assets, not just source code, makes Perforce the ideal choice for our vision. Couple that with the investments we’re making in Streams (for simplified and managed workflow), Sandbox (for private local branches enabling high performance distributed development) and federated servers (keeping geographically dispersed teams collaborating at high speed) and the often uncertain future & roadmap of Subversion then I’d argue that the two can’t be compared in this way-but then of course I would say that!”

I think Perforce has a good chance of making its ecosystem work, partly because of the way Seiwald developed the ideas behind it and is managing the consequent changes within Perforce. He first identified the key question: “Given the trends, the question Perforce needs to answer is: What will it take for everything that needs versioning… to be versioned in Perforce?” Well, he says, “this was 2009-the loan crisis was in full swing, the economy was in a downturn, and our sales were, uh, flat (that was OK-in 2009 flat was the new up). We continued to be profitable and had no debt or pressure from venture capitalists… it was a downturn, and we had money, so we were ready to invest…”

Seiwald then started an internal process that began with Perforce’s Vice Presidents: “I challenged them to consider three things,

• identify a handful of ways to innovate in their area
• find out what it meant for their department to be #1 in what they do
• and, find out what it meant to them, for Perforce to be #1

The idea was to find the best and brightest innovations and ideas and bind them together into a single challenge to the entire company”.

Well, the proof of the pudding will be in the eating, but it seems to me to have resulted in an innovative approach to version management, very much up-to-date but still focussed on what Perforce does best-version management. And Seiwald has one further insight that bodes well for Perforce’s Ecosystem, that version management is more than just a technology thing-it has a human aspect. A tool can mark a version, a human being adds the all-important description that says why a particular version is important to that person-or to the organisation. When Seiwald talks about “versioning everywhere” he isn’t limiting “everywhere” to “everywhere in the IT group” (as some vendors might) he is talking about versioning as a fundamental part of the business process and business governance.