Perspectives on the Shared Source Initiative
by Stephen R. Walli
03/24/2005
http://www.onlamp.com/lpt/a/5730
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.
Stephen R. Walli is vice president of open source development strategy at
Optaros, Inc.
You are a subscribed member of the infowarrior list. Visit
www.infowarrior.org for list information or to unsubscribe. This message
may be redistributed freely in its entirety. Any and all copyrights
appearing in list messages are maintained by their respective owners.
