The importance of Teamprise

A few months ago Microsoft's Gregg Boer was nice enough to fly in and spend a day with us discussing TFS. If I understood him right, one of his goals was to "not" develop a SCM solution for Microsoft, and Microsoft only. That is, TFS needs to be a product that helps company's outside of Microsoft solve problems. As a software company, my organization struggles with this as well. We get caught up developing software that works well for us, not necessary for the user base.

Any way, I took Gregg's comments to heart as we're using TFS in a business unit that develops all our products in Java. We don't need a SCM solution that is geared towards Visual Studio users. We need one for Java developers. Thus we leverage Teamprise for our RAD/Eclipse users and Linux desktop users. So far we've had pretty good success and great support from the vendor.

As much as Microsoft would like to see it, large companies are not going to use .NET exclusively. Sure we're going to use .NET, but we're also going to use other languages like Java, Python, or Perl. If TFS wants to compete with ClearCase or Perforce (which I think they should as TFS is positioning itself very competitively), then Microsoft needs to ensure vendors like Teamprise continue to offer cross platform solutions. I would go so far as to say, if it was not for Teamprise, our organization would have went with ClearCase/ClearQuest or Perforce (plus an additional workflow tool). Both of those tools provide our Java developers or Linux platform users, interfaces from their native environments, which was one of our top ten requirements.

In ending, we really like TFS and feel we made the right decision. But if it was not for Teamprise, we would be using a different SCM tool. That's how important Teamprise is to Microsoft.