Oren pointed out that he would run away from TFS because it’s not a “zero friction tool”.

He does have some valid points, mostly about the length of time some of the source control actions might take, though personally I haven’t found this to be much of a problem. I'd usually say "stay clear of all-or-nothing recommendations" but Oren's is a special case because I know him and respect his opinion on many matters.

However, I think that Oren is making one big mistake: he's throwing the baby out with the bath water. Just because the source control is not as zero-friction as some open source alternatives, does not mean that TFS is not a valuable suite of tools, with more added value than most open source tools that I know of.

• The ability to associate a work item with a check-in action is very powerful in determining and reporting “delta” between failing builds
• Builds are also connected to checkin, and build history allows you to ‘drill down” to see all the source differences between the last success build and the current failing one
• The ability to use “workspaces”, which map current source control into local directories is powerful because it allows you to work concurrently on multiple versions of the same product, and switching between them in a couple of clicks from the IDE
• Powerful automated reporting
• Distributed and extensible build capabilities
• Task and bug management

I mean, Oren, c’mon! You don’t like a part of a part of team system – the source control aspect is not perfect for you, but what alternative do you have for a suite of tools that works together so powerfully?

Also, it’s still a version 1.0 product, and you know that version 3.0 is usually the one to remember, but as a version 1.0 product, and compared to most OSS tools (working together), VSTS gives me something that I find hard to get anywhere else – true collaboration.

There are parts of TFS that I personally still have problems with:

• The build management and maintenance could be far better. So I turn to 3^rd party tools and integrate them in to solve my problem.
• Unit Testing has some bugs and is generally slower. But it still works just fine and I’d use it in combination with other testing products to get what I need. I’m not even going to discuss how annoyed I am that unit testing is not part of all VS.NET SKUs
• Lacking ability to do GUI testing. 3^rd party tools again.
• Requirement management solution is not enough for some organizations. Again, 3^rd party tools if you need them

None of these means I’m giving up using VSTS when it makes sense, and for many organizations, it makes a lot of sense. Especially compared to what they currently have. Take an organization using ClearCase and have them move to VSTS Source Control, then ask them about zero friction. It’s a matter of perspective.

Giving up a full range of possibilities just because one of them is not perfect is kind of narrow minded – the total is greater than the sum of all of it’s parts in this case. A slower moving source control system is not enough justification for me. Being a perfectionist is problematic when talking about system tools. Realistic is much more likely to solve more problems.