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:
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!
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.
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.
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).
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.
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.