RealTime IT News

Jason Matusow, Microsoft Shared Source Initiative

Jason Matusow Windows is to Linux as Shared is to Open, right? If you're Jason Matusow, the director of Microsoft's Shared Source initiative, it's much more than complicated that.

And becoming even more so.

In April of 2004, Microsoft's "change from within" began when it released the Windows Installer XML (WiX) toolset to SourceForge, the largest repository of open source applications.

Then came Windows Template Library (WTL). By July of 2004, the two contributions were listed in the top 5 percent of the more than 80,000 active projects on the site. Things were looking up.

The next contribution to SourceForge was FlexWiki, which is an ASP.NET implementation of a wiki . And all on top of Microsoft's Shared Source initiative, too.

The Shared Source Initiative was established in 2001 in order to address broader customer interest and build on Microsoft's 1991 efforts to share Windows source code with academics.

Matusow recently sat down with internetnews.com to discuss the concepts and strategies of open source and Shared Source, as well as their respective roles in software development and business strategy.

Q: One of the things you talk about in your blog is the concept of open. You say that it means different things to different people. Do you think the OSI (Open Source Initiative) has the credibility to certify what is open and what isn't?

There's a great deal of discussion within the open source community on semantics, about what is open, what is free and what is shared. For me, within the concept of Shared Source, our motivation has primarily been to provide source code for technologies that address customer concerns.

Take the idea of a reference grant. Is that open source? No. That's why we call it Shared Source. I didn't want to get into a conversation of whether or not we were trying to be open or not.

Are we being more transparent? The answer is yes. At this point there are 450 organizations, representing a little over 1,000 engineers, that are actively looking at Windows source code through the Shared Source programs that focus on Windows. But they can't modify that code.

At the next level of licensing is permissive licensing. Of the 17 Shared Source programs we have offered today, I think seven or eight of them are in the family of permissive licensing.

In offering those programs, what you're doing is giving them the ability to see the source code, modify the source code, redistribute the source code, and even resell that code and build businesses around that code if they see fit.

The third category is the reciprocal licenses; the one that we have made use of is the common public license . That is the only OSI-approved license we have made use of within Shared Source.

The community of people we wanted to work with were Windows-based developers interested in collaborative development.

And frankly, for those three projects, known as WiX, Flexwiki, and WTL, we chose to put those up on SourceForge.

If you're going to put those up on SourceForge, it has to be an OSI-compliant license. Just to give you a sense of scope: There are about 1.5 million developers who have pulled source code through the program at this time. We're expecting Shared Source to continue to grow. It certainly has over the past four years. We started out with an announcement of six programs, and there's been a steady increase in the spectrum of technologies that are included, as well as the type of licensing that's included, based on the needs of customers, partners, governments, academics and individuals.

Q: What is Microsoft's overall vision for the Shared Source program?

We think of Shared Source along four key lines: supporting existing customers; encouraging new development; enabling academic and research usage; and creating business opportunities for our partners.

And source code can be pivotal in each of these categories. But it's going to be pivotal in a different way.

Q: For example?

How many people do you think modify Linux source code? [Today, not many.] But how many developers who are writing applications that are going to run on Linux might want to use that source code as a reference mechanism?

We share the source code of Windows 2000, XP, Windows Server 2003. In understanding the needs of the customer, it wasn't that they needed to modify source code. But they want that platform to behave in a consistent fashion.

If you go and read SAP's Web site, [the section] about running on Linux says you can only run on these versions of the distributions, and they give specific numbers. And it actually specifies the C libraries that can be used. And they say that if you deviate from these version numbers, your support contract with us is null and void.

Red Hat, IBM, HP, SuSE and Novell say if you modify the source code, our support contract with you is null and void. It has nothing to do with the source code license. It has to do with the normal commercial reality of running a production system.

If you want a service level agreement, and you want someone who's going to be there in X number of hours notice to help you -- and they're going to have any prayer of helping you -- then they have to know what source code's running in that environment.

It's not a religious decision. It's not because they're for or against open source. It's because as open source has become more commercialized, there are certain implications of that commercialization, and there are just realities of doing business.

Next page: The SourceForge experience, and addressing rumors of a Microsoft distribution of Linux