TFS Vs. Open Source tools
time to read 8 min | 1525 words

This is getting fun, another reply from Roy in our discussion about TFS vs the other alternatives.

Regarding my last post, Oren (Ayende) points out that regarding TFS's features, he can either find a match for them in open source land, or he doesn't really care about them.

What bugs me is whether, assuming you can find and create such a solution out of a package of open source applications working together that operate with the same level of integration as TFS, can you still handle the things that matter to the organization using your solution.

I believe that I can, and we have been doing this for the last several projects that we built. Roy lists some interesting points about choosing the development stack:

Maintainability: Granted, it's not easy to maintain a TFS installation, but it sure as hell just as hard if not harder to maintain a full range of open source tools, each one from a different publisher, different versions and compatibilities, documentation and support services (if at all).

About 6 months ago I had a go at installing and configuring Trac for Wiki/Issue tracking. It took me a few days to grok the way it works, but we have been using it ever since. The last time that I had to administer it was three months ago, when we had to open a new project, and it tooks three minutes on the phone to deal with that.

There is a reason why I keep coming back to Zero Friction. That is what I get from my stack of OSS tools. They are there, and they are working, I use them when I need their services, at all other times, they don't get in my way.

TFS gets in my way, I accidently clicked on the Team Explorer band on the right side and it hung VS until it connected to the server and did something that is of absolutely no interest to me at the time. Annoying in the extreme, shove me out of the zone, and makes me feels out of control. Controlling Your Environment Makes You Happy!

Learning curve: I have no doubt that 9 times out of 10, it is harder to get up to speed on an open source product than a commercial one (there are always exceptions). Double that by the number of different products you are using and see what you get. Usually the documentation is not as good, and the support contract (if exists) is very poor as well. The efforts to maintain the source code and create your own version might actually be higher than what you are trying to save. And no, I don't think it will still be less that the cost of a commercial product (TFS or otherwise)

I am probably in no position to disagree (biased), but I still disagree. I could come up with a few examples, but they would fall into the exceptions clause, so I would just say that it is usually rare to maintain forked version for a long period of time, and usually not necessary. OSS usually has better solutions for this (well defined extension points, for instance).

In fact, I can say that synergy between OSS projects can cause some really sweet results. I have profiling and tracing for NHibernate built on top of log4net, and the NHibernate Search deal is really sweet. That said, I am using a lot of commerical tools because they are better/easier then a comparable OSS project. My reasons may be different, though. I am using SQL Server because Management Studio is a nice UI (although I wish it would still some features from PL/SQL Developers), WCF because it has good UI for logging, etc.

Ease of use: Usually I find that Open source products tend to be less usable than commercial ones. Money does matter. Yes, there are always exceptions. Actually, Eclipse is an IDE I find more usable than VS.NET. But then again, Eclipse's community is funded as far as I know. Money matters.

No argument here. The final coat of paint care make a lot of difference, and it usually takes some money to really get all those nooks and cranies.

That said, there is another element of ease of use that should be considered, and that is the simplicity of the architecture, the assumptions being made about the amount of time that is going to be invested in it, etc. The Entity Framework (to take an example at random) can afford to be complex and ungainly, because they can cover the ugly stuff with pretty designer, an OSS project is usually not at liberty to do so, and as a result, would arrive at a much simpler solution to the same problems.

If you found subversion to be working too slow for you, what are the odds you'd go hack the code for yourself to get a better version? then update it with every new drop? what would be the cost of that?

I don't think that Subversion being slow is the case here, but I will answer anyway.

I know C and C++, so yes, I would. I wouldn't need to update it with every new drop, I would submit the patch to the core team, and then have it there forever.

What is the cost of that vs. a commerical product (which is not slow in theory only)? Well, 0 for the software, and some high amount for spending time hacking at the source to make it faster. What is the cost for doing the same with commercial product? Some initial high amount (although probably less than than the hacking would be), then contiual bleeding of time as a result of problems that I can't fix. But you know that this comparision is flawed, because Subversion is not working too slow for me (and it is known to scale much better than TFS).

It's quite easy to say "I'm not using this because of X,Y,Z". It's quite a different story to say "I know it has it's problems, but looking at the bigger picture I owe it to myself to see if I can find a way to work with it despite of the shortcomings"

And it is another story yet again when to say, "I know a different solution, which can give me all that I need/want, so I don't have to deal with those shortcoming." The bigger picture as I see it is that I get everything that I want, and don't have to waste my time on patching holes in the tools that I use. Tools should be transperant, not road blocks.

But slamming on a tool just because some parts of it are not the fastest is just wrong. The Source control is still one of the strongest ones I've seen in terms of features. discounting it would mean underestimating a product that actually has much value.

Let me put it in the simplest terms that I can, TFS puts me out of the zone. That is simply unacceptable, period. If I need to be aware of "Don't go near the Team Explorer Tab, it will hung VS for 5 seconds", I am not in the zone. If I am not in the zone, I rarely get to code well. Beyond that, the source control in TFS doesn't offers anything that I haven't seen before, not in terms of features, and not in terms of the UI for them.

Tweet Share Share 5 comments
Tags: