Perspectives on the Shared Source Initiativeby Stephen R. Walli
Nat Torkington and I were discussing Microsoft's Shared Source Initiative not long ago. I left Microsoft in early December and had spent the last three years directly involved in various aspects of Shared Source work. The more we discussed his questions, the more we realized others probably shared the same questions. This article came from that realization.
Microsoft began pushing the idea of "shared source" a few years ago as a way to talk about source code sharing exercises they continue to develop in the face of open source software practices. The idea holds the premise that they will share the source code of their software appropriately with appropriate audiences. Free and open source software was happening all around them. They were certainly thinking about the phenomena all the way back to the original Halloween document in October 1998. After talking to many of their customers, they discovered that many Windows developers did want access to read code and debug against it, but not necessarily modify the code. There was even an early university program for academic access, but this early program was not particularly popular. By Spring 2001, Microsoft needed to have an active position on the open source phenomena, and thus launched the Shared Source Initiative.
I will not discuss the past executive miscommunication and misconception, or the marketing rhetoric, but will look at what Shared Source is and some of the challenges open source presents to a large publicly traded company.
First, recognize that Shared Source isn't one program with one license. Shared Source is an umbrella program for all source sharing programs from Microsoft. Any time Microsoft makes source code available through a program, it brands it as part of the Shared Source Initiative, the marketing machine has the message to deliver, and a new program ends up on the Microsoft Shared Source website. These licenses span the spectrum from very locked down, look-but-don't-touch licenses to licenses approved by the OSI, and everything in between.
Most people imagine Shared Source as an avenue to open sourcing Microsoft's key product assets and are disappointed when they see restrictive licenses and difficult eligibility requirements. It's easy to assume that clearly Microsoft doesn't "get it" with open source, or more deliberately is generating confusion in the marketplace. Microsoft has a breadth of software assets and artifacts. The sharing program eligibility and licensing reflects the value of the software asset to shareholders. On one end of this software spectrum are the narrow-eligibility, high-liability programs around the Windows and Office core revenue generating assets (e.g. Government Security Program, Enterprise Source License Program, etc.) There is tightly controlled access to the code, with restrictions on what people can do with it (often read or debug or limited modification without redistribution rights). The penalties for license breach are high.
These restricted "sharing" programs are tied to the core revenue generating products for the company. (Take a look at the recent quarterly SEC filing. Go to the last page on revenues. Add Client plus Server and Tools and compare that to the total.) The responsibility of the executives to shareholders kicks in pretty quickly. They must take a worst-case, conservative view of the risks (brand damage, legal, revenue stagnation, engineering costs). They must have some form of hard data to support the premise that the more they open the source code base then the more revenue will grow. With these key revenue generating software assets, the company is essentially caught between the shareholders and customer base.
Consider a thought experiment to see how opening Windows might go. Imagine Bill Gates wakes up tomorrow and decides Microsoft will share the code of the entire Windows code base under a truly freedom-loving open license. He has his epiphantastic moment (realizing that the actual Windows value proposition to the customer isn't perhaps the product source code itself, but the stability and Luddite-simple packaging), and he embraces open source completely and wants the benefits that may come from such a project. He recognizes the sea change and sends out his boat-turning memo within the corporation, and he begins to turn the very large ship that is Microsoft. There will be some legal costs to "opening" the third-party code. (The Windows code base also contains code from third parties that have a quid pro quo attitude about exposure of their source code.) There will be some pain in modifying Windows to be buildable by mere mortal developers. Still, he buys into the entire concept and begins the project of delivering Windows as free and open source software and to develop the community infrastructure around it that will make this great.
The customer base (consumers, partners, enterprises, and the OEM channel) will all find this fascinating. Many of them don't actually know about open source, and think it has something to do with "free," as in lunch. They may hesitate to buy the next version or choose to wait to buy some imaginary Blue Hat version that someone immediately offers to deliver "cheap" real-soon-now. Of course, a lot of enterprises will continue to buy Windows from the Windows company, but how much hesitation in buying will occur reflected in even a temporary downturn in revenue for a few quarters, while the company works out the kinks of open sourcing a product base of 50M+ lines of code? 10 percent? 12 percent? 15 percent? At what point does the market take action and do Microsoft's shareholders revolt? What does that do to Microsoft's abilities to act, or to its ability to hire and hold the talent in the company when the profitability starts to shift? When do the class action suits start? When does the board react? Where does the fiduciary responsibility of the executives lie?
None of these business problems have anything to do with the merits of open source, which will need to be measurable in terms of revenue growth and cost savings to a for-profit company. This is the sort of conservative worst-case analysis the executives in a for-profit corporation have to do concerning the core assets of the company.
They can't afford the risk to the brand of instability (or the perception of instability) of the Windows or Office products with their enterprise customers. The hardware compatibility list and application compatibility matrix are enormous. The cost of the regression cycle is huge. What happens to product stability once the code is in the wild? The Windows tree is not the Linux tree. The Windows tree is akin to an entire mainstream Linux distribution, except with a tightly integrated code base. (At least product stability drives piracy, rather than the potential loss of customer confidence that may arise when competing versions of Windows-like platforms appear.)
They can't afford the legal risk of an injunction on the core revenue generator of the corporation. Accepting contributions from developers into the code base has the perceived risk of intellectual property taint. What would an injunction on the core revenue-generating product mean to Microsoft while it struggles to evolve a community? While they live with the risk every day from their own developers, it is not a risk space they necessarily want to expand.
It's not that certain for-profit companies haven't successfully delivered a primary asset as open source. Both Red Hat and MySQL are growing companies (one public and one not yet). Both companies' primary software is open source--but they started from an open source base and grew forward, rather than starting from a closed binary product space and opening it up.
Put down the chainsaw, take a deep breath, and step back. It turns out there are other things Microsoft can release under more liberal--even OSI-approved--licenses as part of the Shared Source Initiative.
The Rest of the Microsoft Software World
When you think about Microsoft and software and open source (and Shared Source), don't think of this as strictly a mechanism for product code. The reality is that Microsoft has a breadth of source code assets and artifacts. The spectrum starts with complex code assets for the core revenue-generating products (Windows and Office), and the "minor" products (relatively speaking). Then there's the rest of the software artifacts of the corporation. At a glance there are:
- MCS (consulting) practice code
- MSDN sample code
- Software Development and Device Drive Kits
- Internal-tool code
- Experiments that may never see the light of day
- Research from MSR
Moving along the spectrum to look at other Shared Source programs, there are more open licensing terms, easier eligibility, and more interest in taking code back into the project. Experiments that appeared on GotDotNet workspaces had fairly open licenses associated with them along with the Shared Source branding.
The Rotor project was an early foot in the water. The basic difference between the Rotor license and the Berkeley license was that the Rotor license prevented commercial use. Rotor remains an interesting project for research and for providing a working implementation of the ECMA/ISO standards. The project turned away external code contributions when it was released, and there were brilliant contributions in the first few days after release, but the Rotor code base was still live within the .NET CLR code base that ships on Windows. (Go back to the previous discussion around injunction risk.) Shared Source experimentation continued.
The WiX Experiment
On the other end of Microsoft's software spectrum, there's internal tool code such as WiX. Microsoft released WiX available to all interested parties on SourceForge under the Common Public License in April 2004. WiX is actually an awesome example of exactly what open source projects can bring to Microsoft. WiX is (as Time magazine called it) "a relatively insignificant geekware tool." It is a command-line tool set allowing developers to reliably and repeatably generate a Microsoft Windows Installer package for their software deployment needs. It fits the professional developer's need for a recipe-driven, batch-oriented build tool. Many internal Microsoft teams used it.
After 328 days on SourceForge, the WiX project has on the order of 120,000 downloads. About two-thirds of the bugs logged have been fixed. A reasonable number of people have joined the project's community and assigned their property rights for their contributions to Microsoft as the legal sponsor and defender of the project. (I designed the original assignment process along the lines of the FSF policy. If it worked for them, it would likely work for Microsoft.) There has been a steady stream of email from Windows developers in the community that are simply happy users of the technology because it allows them to deliver better Windows packages. The transparency of the code and examples means they can see exactly how to accomplish installation tasks that previously were mysterious.
The core of the WiX community however is Rob Mensching and a half a dozen developers working predominantly on their own time. Windows development customers are happy and directly involved in the conversation with Microsoft employees. One stunning submission came from a developer that built a considerable tutorial on WiX. I did a quick page estimate and it looks like this developer gave the WiX project at least a month of his life.
Compare that to the investment to deliver the same functionality "for free" to customers in binary form as a feature of Visual Studio. First of all it would need a proper feature team. (This means developers, program management, testing, and at least part of a technical writer.) They would work full time on fixing bugs (most of which would need to be found by testing), internationalizing WiX, doing a complete security audit, documenting it (in Windows Help format of course), wrapping some form of GUI around it because it's Visual Studio, and so forth. Of course, this is a relatively insignificant geekware tool, which means the team would likely face reassignment somewhere during the delivery cycle to fix and deliver some other feature deemed more critical to the perceived needs of the customer, and WiX wouldn't ship for some time.
Compare the WiX open source world to even making the tool available for free as a binary download somewhere on MSDN, which wouldn't require the same level of investment, but it wouldn't foster the same level of engagement, either. No one would be fixing the bugs and contributing back. The transparency wouldn't exist for people to learn. It's unclear that the community leadership would even occur, because there'd be no direct conversation with like-minded developers around installation. As everyone knows in the open source world, without leadership, the community flounders.
Which is better for customers? Which is a smaller direct investment for Microsoft? Which conversation is real? WiX is a real community. Code is published, waivers and assignments happen, code is integrated, developers are happy, and the Windows development world is a better place because those developers can build better installers for deploying Windows applications. Making WiX hurts no revenue-generating products. Customers are happy, so shareholders are happy. The community leaders in each Microsoft-sponsored SourceForge community are sensitive to intellectual property concerns (both inbound and outbound). It's all good.
The Road Ahead
When I look at the rest of the software spectrum beyond the core products around which Microsoft can develop open source communities (branded as Shared Source, of course), I see huge opportunities for them to engage more directly with customers to continue to revitalize the Windows and Office product spaces. This is, of course, the antithesis of the way they have traditionally delivered packaged software through the channel, so it is fraught with corporate cultural pain and angst, and just a little trepidation with respect to perceived risk and impact to the margins on the core revenue products, even if those products aren't the direct target of such communities.
While the shades of grey around Shared Source versus open source may live on in marketing programs, and Microsoft executives will still occasionally frustrate many of us with rhetoric around indemnities and intellectual property, or "Get the Facts," the company has a unique position with the sheer breadth of software it owns from which to lead in the community at large rather than follow or fight. Its position also comes with some fairly ugly challenges, not just in the packaged binary culture within, but also in internal education to gain the advantages of shared communities without damaging the revenue stream, and on taking long-term executive steps when, as a publicly traded company, they are judged on short-term actions. Only time will tell if they are learning the right thing about open source development from their early experimentation.
Return to ONLamp.com.