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 not...no 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!