Again, some raw quotes and what I think I heard at Tech-Ed. This time about the community tech previews.

  • “ I love them”  
  • “I have no problems if they don’t run well, you disclaim them just fine”
  • “I prefer the downloads because I can still get them before the DVDs arrive”
  • “Even if they only run well enough to see 25% they are still worth it”
  • “The downloads are currently slow, but the MSDN download manager works well”
  • “I would be willing to install a separate download application that used bit torrent technology”
  • ”I would not be willing to pay for faster downloads”
  • “Bit Torrents would probably be faster”
  • “Could we get them more frequently?”
  • “Your one week scenario (Report a bug Monday, hear back by Tuesday, see that its fixed Thursday, and download the new build Friday to try it out) would be too fast for most customers. But I’d love to see you pull it off. “ 
  • “They are great to let us know what’s coming so we aren’t as surprised or disappointed when the final release comes out”

Of all the things gathered information on I probably got the least feedback on the topic of the Community Tech Previews for Visual Studio.  One item that is not captured in quotes is that it would be MUCH MUCH better if users could use the developer tools to target more stable frameworks.  Unfortunately our tools are tied to the framework at the moment. Eclipse was held up as an example of how any build of eclipse could easily be used for real development on existing projects that hit any version of the Java runtime. 

The second big pain point was on the issue of distribution.  We need a faster, more scalable, solution for users that want to play with our builds more frequently. Most people agreed that they would be willing to support a P2P distribution model, but not a pay-for download model that they perceive the current MSDN subscriber limitation as.  The third pain point is the install process. Its too long and old builds don't uninstall. 

In general people didn't mind if the builds were very broken IF they were able to identify what worked and didn't work before they went through the lengthy download/install process. 

There was laughing when I explained the one week bug report -> using a fixed build scenario, but in a good way I think.   I see that as a challenge.