TFS vs. Open Source, the battle rages on

Caught a thread between Roy Osherove and Oren Eini that has gone back and forth a few times, all about Team Foundation Server and open source tools (and the deficencies Oren points out in TFS).

The discussion has been (mostly) centered around source control, however I think they're both missing on the main feature of TFS. That is extensibility.

Yes, other packages out there are extensible by nature (Subversion for example) but require coding, architectural changes, hooking into events, all of which are nice but systems like this were not designed for it. Was subversion really designed at the start to be extensible so I could maybe have my storage be in a relational database rather than the file system?

TFS by it's very nature was built around extensions. The Work Item itself is just a container, defined by the fields, rules, and relationships you create in the process template. There is no "default" Work Item. There is no concept of a "bug" or "feature" in TFS. It's just a Work Item and can be morphed into whatever you need it to be. Just look at the Conchago guys with Scrum for Team System, and how they turned Work Items into sprint and product backlog items and even through in a sprint retrospective item.

I was asked recently if we could modify the bug template so we could track the steps to reproduce. I said we could use the description field, but decided to build out a new type of Work Item (using Joel's very excellent Process Template Editor) so that you could create a work item (a bug) and add as many steps to reproduce and and expected behavior field for kickers. The entire process took me an hour (and that included about 15 minutes to grok the templates as I've never done this before).

I've tried these type of things on other systems and they're painful. Sure, some systems are quite helpful in adding new fields, changing the layout, etc. but none are things that you can add entire concepts that are new, not just net new (there is a difference). Could I crack open subversion to support a way to link checkins to an external feature list? Sure. Why would I when TFS has this already.

As for modifying open source systems to do your bidding, you enter into a fork scenario. Unless the system supports a plug-in pattern and you can just add a new assembly (like say oh the TFS policy sub-system) I really can't do much with a tool even if I have the source code, unless I want to run the risk of being in a maintenance nightmare from Hell scenario. Do I really want to do diffs of new relases of NUnit with my own code to support new extensions.

Luckily there are some open source systems that are built around an extensibility model but so is TFS. And while it might have deficiencies in various places I can plug in new features or introduce entirely new concepts to the repository so that I can make it match whatever business process I use.

Is the source control system in Team Foundation Server extensible or replaceable? No, but I'm willing to live with a few problems while we get to version 3.0.