Application of the OSP

We now have the OSP out there and it has been applied to 35 web services specs and now the VHD spec. The question I have for readers on this blog (and your friends) is what should be next? Microsoft will not be applying the OSP in any sort of blanket policy across all specifications past, present, or future as that does not make sense from a business perspective. All organizations should take a sophisticated view of their IP assets and think deeply about what to hold close (for any number of reasons including revenue, strategic alliances, security, etc.) and what to be more transparent with. Then, within the transparency arena this is a wide spectrum of choices as to what steps you might take with those assets.

To provide some insight into our thinking, we are looking across our technology set to determine what approach will make sense on a per-technology basis. I have been encouraged with the progress around collaborative dev projects and the work happening at CodePlex (I'm still interested in the work I was part of for so long around Shared Source), and now I really like the steps we are taking with the open specification promise. If I think about what falls in the "key technology trends" buckets I put virtualization and web services squarely in the mix. So the OSP has been applied in those two critical areas. I'm working with a really bright group of folks who are looking at where else we might think about the OSP, but I'd prefer to have our process not be so insular. It is far healthier to have outside voices involved.

Next week we are hosting the first meeting of our Interoperability Executive Customer Council and I am very interested to hear the feedback from that group. But the community of people who are CIOs of multi-national corporations and large government agencies is small. Many of the folks who read my blog are very thoughtful around these topics. (I'm sure that you have a valuable opinion here Wesley) and I would like to include those ideas in our strategy sessions.

As you might assume, I'll give the prerequisite disclaimer that we won't necessarily take action with a given piece of feedback, but all of it will absolutely be part of our considerations.

Thanks in advance for the comments.

Comments (6)

  1. Scott says:

    Actually, the OSP includes 38 Web services specifications plus VHD.

  2. I just had a couple random things to mention this afternoon: ARCast – Office 2007 Open XML Format (Part

  3. Francis says:

    Microsoft has a lot of outdated standards that, in themselves, really aren’t worth anything to the company. However, that does not mean that there is no value in making them open. Nobody may use Word for DOS or Multiplan anymore, but that does not mean that data stored in those files will never be wanted.

    Why not post these standards, to the extent that documentation still exists, online, in a "Microsoft Historical Archive" of sorts? This would serve as a tribute to Microsoft products, an educational resource, and well as a how-to-guide for programmers, historians, and the like that need to open old files.

  4. jasonmatusow says:

    Thanks for the comment. To clarify, you are talking about MS releasing the documentation for the binary formats used in our old productivity apps?

    It is an intruiging suggestion, but I am sure that it is a) more complicated than it would seem, and b) more expensive than one would guess to prep the materials for release.

    I will talk to some of the folks in Office about this and see what comes of it. We have heard for a long time that data archival is critical and the role of formats in those scenarios is very important.

    Interesting, thanks again for the feedback.


  5. Francis says:

    Yes, I was primarily referring to those formats, but it could be any format where the quantity and importance of the information encoded in that format is considerable.

    A few ways to reduce the cost:

    – say the materials are unsupported

    – do not worry about materials being incomplete

    – if the information is only in printed form, do not digitize it, but post scanned images (with OCR text, like at

    I would think the greatest problem would be digging up the information in the first place and scrubbing/sanitizing it for public consumption.

  6. jasonmatusow says:

    Again, thanks for the comments and the suggestions. Old stuff would certainly be unsupported (as it is now), but the question of completeness is a big concern. For just about anyone other than us, it is reasonable to say that something is incomplete so the community should just deal with it. For us, that is usually not acceptable. That is not a complaint by me – just a reality.

    There is a more difficult problem, and that is of internal resources. In order to do back-catalogue work, you are inevitably taking away from the resources you have to do your current work.

    The other issue is one of copyright clearance. Many of our products have components that were licensed in over time. All comercial software providers are always in a buy-vs.-build decision matrix. The result is in going back to old components, we very often have to untangle some pretty sticky licensing issues (especially if the licensing org is no longer in business, etc.).

    We had a situation with source code in Windows for a government customer where they needed us to share some code with them that was not in our existing Shared Source premium source kit and we ended up having to execute a long-dormant option in a licensing agreement to meet the customer need.

    Anyway, these are our problems not yours. 🙂 I will take the feedback into our ongoing strategy sessions and we’ll see where it leads.

    Thanks again.


Skip to main content