Why Did We Write the CodePlex Client?

I want to answer some speculation about what motivated our team to write the CodePlex source control client.

When we chose Team Foundation Server as our source control system, we knew that there would be big reactions to our choice. We knew there would be a decent number of people who wanted the tight Visual Studio integration provided by Team Explorer. For many developers in the Windows space, the Team Explorer GUI is a natural extension of the source control systems they're used to using.

Additionally, though, we heard from a contingent of users who were accustomed to the tools provided by other open source community sites. The biggest difference is support for offline use. Team Explorer builds in a lot of assumptions about working online. Since TFS was designed primarily to support enterprise development on LANs, this seems like a reasonable requirement. When trying to use TFS in the distributed world of open source development, the lack of an offline story can become significant.

We wanted to provide the offline experience for that contingent of users, while preserving the tight integration with Visual Studio for the rest of our users. By developing directly against the TFS web service APIs, we were able to write an offline client that behaved similarly to those available with other environments. The command line version is just our starting point, but we think it hits the critical mass of features to start allowing people to experience TFS source control offline.

Was it six months well spent? I’m sure our customers will let us know. :)

Tags: CodePlex Client, CodePlex, cpc