Blogs, Alpha Builds, Customer Community, and Legal Issues

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.  

Comments (18)

  1. Rolf says:

    >P2P Community Drop Distribution

    Why don’t do both? A drop can be downloaded on MSDN and is also available as a bittorrent? This would solve the problem of telling customers they have to download third-party software (they have the choice of downloading directly from MSDN). BTW: if someone are willing to install the previews with the warnings (reformatting harddrive might be needed, etc.), why worry about any third-party software? And who on earth would start a almost 3GB download directly from IE… one hiccup and you would have to start all over again!

    Or maybe only available on MSDN, but the EULA specifically allows you to share it through P2P?

    There are thousands of possibilities, but I think changing the EULA for the MSDN subscribers who have downloaded the preview to be able to share it would be a start, then you can watch the p2p networks for traffic and see how things are going before publishing the downloads directly from your servers to p2p networks.

  2. You are correct, it will be shared regardless. I did not download it, of course, but the PDC Longhorn release was online the weekend before the PDC started. The pirates had to wait a few days until it was released there and the product keys made their way to the net before they could install, but by the end of the PDC, Longhorn was everywhere.

    or so I heard.

    I am one of those poor folks who obey the rules. That means I was a Beta tester for Yukon Beta 1 but didn’t have access to Whidbey (think about that for a second).

  3. jledgard says:

    Rolf: I do think if we did it we would have to offer both. I’ll take up the idea of allowing our beta EULAs to allow sharing.

    Shannon: Do you have access to VS now? This is a problem we are working on addressing. If you still don’t have VS please contact me through e-mail and I’ll make sure you get the previews and alphas.

  4. Derek Curry says:

    Wow, what a bunch of wankery! It seems like MS-Legal™ is practicing make-work to justify their jobs.

    PS: You need a "Preview" button next to the "Submit" button.

  5. Preview button is a .Text feature and I believe Scott has it on his list of things to do. Of course he’s also asking for other developers to help him out a bit, for which I can’t blame him. (Now to just get free time.)

    Distribution of the materials to 3rd parties via BitTorrent is an excellent idea. I regularly seed/share Torrents off my host for smaller companies or mod teams. There’d be no reason to not do it for Microsoft as well. The only caveat I’ve found is that a host can be overwhelmed by scrape requests if the bandwidth isn’t sufficient once you get up around 400 or 500 peers.

    Obeying the rules stinks. I’ve got a PASS (November 2003) Preview copy of Whidbey and Longhorn, but I’d like to get the latest. Unfortunately my MSDN Universal ran out so I no longer have access so I have to sit and drool while reading articles in MSDN Magazine. : I refuse to be a hypocrite and steal from my own kind though, no matter the curiousity level. If you pirate a programming environment — what the heck?!

  6. jledgard says:

    Derek: I don’t want to cast them in a bad light. There are some legitamate concerns to be had.

    Brian: Thanks for the additional feedback about the Torrents.

  7. elliotv says:

    i believe the bittorrent idea would likely be killed off by some division of M$ since BT is an open source protocol/solution, and would hurt M$ argument to clients that open source solutions have a higher TCO than purchasing solutions developed inhouse. Unless M$ writes its own P2P client (which could be used for piracy, so that’s never going to happen), bittorrent cannot be used.

  8. jledgard says:

    Elliot: Don’t count us out just yet. I’d put money on us figuring something out.

  9. Josh, I do have Whidbey now, via DevDays. Thank you, though.

  10. jledgard says:

    Good to know. Thanks for the update!

  11. David Cumps says:

    A possibible idea for the disclaimer issue:

    Have a ‘Disclaimer’ area in .TEXT to put one in (which will be displayed on the side), so your site visitors can read it…


    Don’t include a disclaimer line on your site, but have an option in the admin section for a disclaimer line that would be added to each post, but only in the RSS feed (and add it nicely, like the footers of Hotmail email etc).

    That way, your blog doesn’t look ugly with all the disclaimers (and your visitors can see the side disclaimer), and the rss readers have the included disclaimer line in the rss feed

  12. Josh Ledgard says:

    Good ideas. I’ll pass them along.