Geeks With Blogs
Eric Matz

Since Mickey Gousset raised a good point in his comment on my previous TFS post, I've been looking into this further.  I was going to post my findings from the current licensing white paper, but Chris Menegay basically said what I was thinking.

Anyone editing data will require a CAL“  What exactly does that mean?  I hope they add clarification for (and exclude) API usage.  At TechEd '05 they showed a demo of Team System's collaboration capabilities.  In it, they talked about how easy it would be to have a "Feature Request" Work Item entered by an end-user via some interface (like a web portal or Outlook add-in) and have it go all the way through the development life cycle.  So...if I create that custom Work Item and enable a portion of my website to allow users to enter Feature Requests, do I need a CAL for each person?  I hope way would I be able to determine how many to buy, nor would it be cost effective.

My biggest concern is all the people internally that need to be able to enter/change Work Items.  They are not technical, so a very simplied interface is critical.  I've started looking at Team Plain, and I think it will do the trick as long as I can limit it to just Work Items.  However, I'm not sure my management will approve when I tell them it will cost $499 a pop to allow people to enter bugs via a web application.  They will tell me it's cheaper to leave the current system in place, even though it is pretty lousy and doesn't integrate well at all.

TFS is a fantastic product.  I can't remember the last 1.0 release of anything that has impressed me so much.  The source control aspects alone are probably sufficient for me to justify the spending, but I want to sell them on the Work Item tracking.  If Microsoft adds the ability to manage Work Items via the TFS SharePoint Portal and does not require a CAL for each user, THIS WILL BE A SLAM DUNK!

Posted on Saturday, February 18, 2006 10:43 AM | Back to top

Copyright © Eric Matz | Powered by: