Here at Perforce Plaza the lunchroom is buzzing with this topic. In response to those of you fishing for an official response, please allow us to interpose a "company line" into the usually unsullied Perforce User forum:

Making The P4Win GUI Open Source

This is an excellent idea, and we will do this. Just give us some time to straighten our sweaters.

We plan on making all our clients apps open source: the Windows GUI, the upcoming web interface, and the IDE plugins. They are all built upon the Perforce Client API (see below).

Our Public Depot was intended to be a clearing house for our open source projects. But so far, our open source plan has had to take a position behind customer support and product stability. We're getting closer, though.

A Perforce Client in Java/Python/Perl

The Perforce client isn't huge, so this is possible. But no, it wouldn't offload our platform support workload. It merely changes "edit/build everywhere/test everywhere" to "edit/build once/test everywhere". If we are going to support a portable client, we have to test it where it is to be used. And once we have our hands on a platform, our first test is to port our client there anyway.

A Public API, not a Public Protocol

The Perforce API is public, but its implementation and the underlying protocol are not.

The issue here is support, not competitive advantage. Publishing the protocol would hamstring future changes, because in addition to our known releases of clients and servers, we'd also have to consider any customer's program built from the protocol spec. It is possible to document a protocol well enough that it remains extensible and interoperable, but it is hard, certainly a lot harder than having a captive set of known implementations.

Any user of the protocol requires an implementation of the protocol machine and the minimal set of services required by the protocol, like reading and writing client workspace files.

The Perforce Client API is exactly that implementation -- just what you need to make the protocol work -- and that is what we support. It's just easier than supporting the protocol itself.

The API is available at www.perforce.com/perforce/loadsupp.html.

Now back to the regularly scheduled program.

Christopher