The shackles of IP taint

or
How it’s easier to drink the Kool-Aid™
if it’s the only drink you’re allowed to have.
The problem: If you, as a developer, introduce intellectual property into Microsoft’s distributable software portfolio¹, and the ownership of that intellectual property is under dispute, Microsoft may come under (additional) threat of lawsuit.

The “solution”: Make the policy such that Microsoft employees have no way of copying any external IP—make it against the rules to read Open Source code by default, even outside of their job.² To a lesser extent, except for specific competitive reviews, even using alternative products (esp., if it’s a development product) is frowned upon lest you absorb possible IP in the visible framework code.

The ramifications for your average Microsoft software group aren’t that problematic. They’re generally consuming the Windows OS (Microsoft), using the Visual Studio tools to build their project (Microsoft), and the majority of the analysis and testing tools are Microsoft. Furthermore, if you don’t understand an API’s MSDN documentation, you can just load the symbols and debug right into it and find out for yourself what is going on (or going wrong).

But it does mean that you are limited to what the “state of the art” is to what the Microsoft-available solutions are, and furthermore to not really know what you’re missing.³

As soon as you get on the fringe, the all-Microsoft strategy starts to slip. As a MacBU developer and now as a CLR developer working at least part time on the Macintosh CoreCLR, very little is in-house. Trying to track down something in a closed-source Apple product is just as bad as Apple trying to track something down in our closed-source products, so we get a taste of what it’s like to be a third party. But even when it’s open source, we still can’t download it and look at it. Even if it would be expedient to do so to figure out what our (mis)use of it was. Even when the documentation is sketchy or ambiguous.

So as it stands, we rely heavily on ADC. We can’t peer into the code, but they can and give us hints, or code samples. And obviously, they go and fix bugs we report in their software, as well as in the family of open source projects that are released with Mac OS X. Which leaves us back again working in our own sandbox.

It sometimes takes years for external ideas and outstanding tools to penetrate into Microsoft, and it seems to me, almost entirely through people who are new industry or college hires, bringing in their previous backgrounds (taint notwithstanding⁴) with, generally, open source community. The rest of us have to work hard (and run a rather annoying gauntlet) to keep from relaxing into navel-gazing.
--
¹As opposed to in-house tools that are not distributed.
²Unless it can be demonstrated that there are sufficient business reasons to justify the expense of having the legal team review the licensing, and incur the additional risk to Microsoft.
³On the other hand, we also have the problem that there are usually many different (sometimes nigh identical) solutions to the same problem that aren’t well publicized and thus proliferate.
⁴If a new hire made significant contributions to an open source product, then they’d be barred from working on any Microsoft product that would be of similar ilk, presuming that that would be the IP they might leak from external sources into the MS codebase. Unfortunately, there’s no good mechanism to determine what the overlap is, so it’s just a matter of how much risk the dev managers and legal team think they’d incur.