What Source Control tool do you use? And more on TFS Vs. Open Source tools
| | 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: - 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).
- 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)
- 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.
- 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 do realize that many of my points here are actually related to the Open source thing as a whole, but it does matter when the product and solution you are trying to install is to be delivered in an organization with lots of things at stake. I think that even in small groups VSTS can win out over OSS solutions by pure integration, but usability wise it may still be lacking.
There are always workarounds for this kind of thing (like using TestDriven.NET when running tests in VSTS IDE), so what I think I'm saying is, well, don't discount something just because one thing is not perfect. If you do, it (in this case) is purely a matter of individual preference. Just like I hate editing XML files. At an organizational level I do realize that to get the good you sometimes need to get a little bad, and find ways to minimize it.
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 no, I don't advise you to drop source control integration, but learn to live with it to accept the other benefits. I agree that taking source control or work items out of the picture it becomes a much less relevant product. that's why I think working with all of them is the only way you will find true value in such a product.
As a pragmatist, I don't necessarily use products just because they are Microsoft oriented. I do believe in the best tool for the job. I have no problem acknowledging TFS's problems as well as its advantages, while still looking at many other tools to see if they fit the job better. I didn't see anything that really comes close, with all the hiccups it does have.
Working with a tool like CI Factory or TFS Integrator is always something I'm looking at because they bring value to places where TFS is lacking. 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.