Tomorrow I meet with a couple members of the MS Legal team to talk about the various issues that surround our current and future planned community endeavors.  Here is a brain dump of my current thoughts that I look forward to looking at after I'm re-educated tomorrow.  In the end we'd like to have some easy to understand advice for MS people participating in the community.

Blogging Disclaimers

Some Microsofties are now including disclaimer text at the end of each posting in addition to linking to a disclaimer on the sidebar.  A long internal thread went around where “best practice” guidance was given from a member of the legal team that included inserting the disclaimer into every entry as well as in any comment we leave on other blogs.  Some people feel pretty strongly that this will kill blogging, be impossible to enforce, and that it is just plain silly to add the disclaimer text to a blog comment when all you might be saying is “Great post, I agree”. 

Since I do most of my blog reading through an RSS reader I can actually see a good argument being made for inserting the disclaimer text with each post.  I honestly don't know what the disclaimers are, if they exist, for a majority of the blogs I read because I don't ever go to the webpage where the blog is displayed.  Maybe someday this information will be included in the RSS feed and the Comment API will let me know what the privacy policy is for information I send in, but today these things do not exist so it would appear to complicate the issue. 

On the other hand it's easy to go overboard on the disclaimers.  I was once told, when posting to newsgroups, to include the disclaimer text at the bottom AND TOP of every post.  After all, what good is the disclaimer if a user reads half of my post, take my advice, loses a million dollars in productivity, and then reads my disclaimer?

From a purely non-legal perspective I would also have to call BS on the standard disclaimer text.

“These postings are provided "AS IS" with no warranties, and confers no rights. The content of this site contains my own personal opinions and does not represent my employer's view in anyway.”

I have no problem with the first sentence, but the second would bother me a bit.  What represents a company better than the collective values and opinions of its employees that are expressed through their blogs.  It would be fun (read as: probably not so fun) to see if this worked the other way.  Since the disclaimer text attempts to drive a separation between an employees action on his/her blog and an employer... what would happen if I discover the next killer app through a discussion on my blog and decide to start my own company to profit from that idea?  It would seem the disclaimer text would make this plausible where it would not be if the conversation had taken place on an internal distribution list.

I wonder if it would be possible to have some sort of loose registration required for customers to read a blog post on MSDN for the first time?  Maybe we should just make the disclaimer and TOS a static part of the RSS feed for everyone by default as well as placing the text at the bottom of every blog page on the web site as well.  As far as disclaimers in comments are concerned, that's just pure silliness IMO.

The Daily Eula

So we'd like to turn on the ability for customers to install any build of the product they want by exposing the daily drop.  Apparently every release is required to go through a privacy review so that any potential privacy issues can be disclosed in the Eula text on product install.  I never knew anyone read that stuff.  Regardless this poses an interesting challenge.  Strangely enough it becomes an impossible task to know what is turned on, working, or not yet included in each daily build when the product being built is worked on by thousands of people.  I sort of imagine it like a Stuart Smalley daily affirmation:

“Hi, I'm Visual studio, I am fun to use. Because I'm good enough, I'm smart enough and doggone it, developers like me. Well, not every developer. But that's their problem. And your problem. Okay, I'm sorry, this is not my best build... and I may have collected information without telling you... but that's OK“

The IP Leakage

Another concern with releasing daily builds is the potential for IP leakage.  As I understand it we may lose the rights to a design or patent filing if we simply give out builds with the IP largely unprotected.  Personally, a recent quote from the Church of the Customer blog sums it up for me. 

“Napsterizing your knowledge among clients and prospects is trust-building, and trust inspires evangelism. Unless you have stumbled upon the formula for predicting the future, your knowledge is of inconsequential future value if kept largely to yourself.“

This combined with the fact that Visual Studio itself is not a huge money maker for MS leads me to think there isn't really much worth he hassle of protecting.  This stance gets a little fuzzier, of course, when you include builds of the framework that is distributed with products beyond VS. 

Conversations that Lead to Features

It's been put simply that one community goal for Microsoft employees could simply be “have regular quality conversations with your customers“.  I've personally been told we are getting pretty good at it.  Unfortunately this brings up the concern that we could be sued for using an idea that was derived from a conversation with a customer.  This fear alone is enough to prevent some groups from opening up more to the public in a more intimate fashion.  For some reason I'm now imagining Microsoft shirts for the next PDC that include the disclaimer text... on the front and back. :-) The more we talk to customers the bigger the worry becomes.

P2P Community Drop Distribution

Yes, we do like the idea of using bittorent to share the latest builds and I would love to see it become a reality.  I wonder if it probably wouldn't have raised as many eyebrows if we had billed it as “Distributed Community Drop Distribution“ rather than a P2P distribution method.  I think P2P tends to send the wrong signals to lawyers.  Game companies have been doing it for a while.  I see no reason why we shouldn't start.  People are doing it anyway. I was able to find a torrent link for the latest preview.  We might as well make it official. IMO this “art“ is something we want to enable customers to try quickly and easily rather than maintain strict control of.  On the downside MS does not offer a torrent technology solution and there is always some paranoia around telling customers they have to download some third party software in order to participate.  I mean, at that point, haven't we lost control of the experience?  Aren't we Microsoft?  Shouldn't we own the end to end customer experience when it comes to our products? 

Biography Disclaimers

To use an expression I once heard “You have so many you could throw a wet cat by it's tail and it would probably land on disclaimer text“.  I don't condone throwing cats... I'm not even sure why the cat has to be wet... come to think of it... I think the person I heard this from might be a little crazy. Anyway, if you read the disclaimer on my biography you'll notice the text “Due to the volume of e-mails we receive, Microsoft, including the individual listed above, may not be able respond to your e-mail because we are a bunch of lazy slackers that would rather blog all day and beg to get on the Halo 2 beta than finish Visual Studio 2005 or answer your mail.“  OK, so I threw in the last bit about being lazy.  Several of us have joked that we should set OOF mails with this text for internal people to read.  Is it right to have such a disclaimer?  It seems a little rude?  Maybe it should just be a counter on the number of mails currently sitting in my inbox.  “Now serving...“.  Anyway, it's just another example of the tensions and fears created when you start asking people to open up more with customer.  I think I've yet to get one mail from my biography.  No SPAM, product feedback, or inquiries from recruiters. I guess I had better not lose my job. 

Samples, Powertoys, Open Source, and Setting Expectations

There are still a lot of tools and code that we use internally that should be shared with the developer community.  I want to make it easy for teams and individuals to publish this stuff in a way that customers can benefit, they can be comfortable with releasing the source, and the proper support expectations have been set. 

So there you have it.  My current thoughts as I watch the Red Sox lose to the A's.  Disclaimer: I think watching the Red Sox has a negative effect on my sarcasm and positive thinking abilities.