Jason Matusow told the Wednesday morning keynote audience at EuroOSCON that his "role at Microsoft for the past five years has been to look very carefully at open source and interpret it back to a company whose primary motivation is to build software that it's going to sell commercially. That's not evil, that's not wrong, it's the way we choose to do business. It's also, of course, the model for about 70,000 other companies out there today."
One of the challenges in this setting is to decide when to give source code away when this code might let competitors see what you're working on and where you are heading. Matusow says that Microsoft views the licensing of source code as a way of "enabling your customers to do more, giving developers a chance to work with complementary technologies." He says that 90 percent of the 80 Shared Source code projects at Microsoft are released under a license that says "look at the code, modify the code, redistribute the code, build a business around the code. You don't owe us anything back for doing so." Microsoft still plans to sell the big products like Windows, Visual Studio, and Office while also identifying technologies within those products for which it makes sense to the company to release the code, enabling developers to do new things on these platforms.
According to Matusow, open source projects tend to have the same basic composition. At the top are one to three developers who do a little more than half of the work on the project. These are the maintainers who provide the architectural direction, make the hard decisions, and lead the community. Microsoft has internal teams who work in an open source way within the walled garden, but Matusow observes that the composition of teams within Microsoft mirrors those he observes outside of Microsoft. He also adds that if these maintainers "are good at leading the community, they'll stay in that position."
The next level down are the committers. These are people who volunteer for one reason or another. They tend to come to the project on their own and end up earning rights to commit. There tend to be 8 to 12 developers at this level who together provide a little less than half of the workload. Matusow pointed out that in Linux the top 12 developers produce 84 percent of the work. At the base of the pyramid is the community. Pretty much regardless of the size of this group, Matusow estimates that they contribute less than 10 percent of the workload.
Matusow said that the way to interest a community is with a well-defined problem set. The community won't tend to come to an ambiguous problem or one running off in many seemingly random directions. Also, in order to attract a community, "the code has to be fairly mature at the start of a project or people don't understand where it's going." He feels that architecturally, modularity helps the community find the pieces to work on that they are interested in and identify ways to participate quickly.
Matusow said that the environment in which a contributor works is important but stressed that the license for the project is also critical. Licensing can become messy when you are trying to determine whether code covered by different licenses can be combined. He contends that most developers don't care about the licenses behind the code.
He explained the balance that commercial vendors such as Microsoft face. "As open source commercializes it does decrease in openness. Not out of a nefarious intent but out of the fact that a customer's value of things, like predictability, is going to drive certain behavior. So a certain contract that says 'you can't modify source code' isn't about being against open source, it's about saying 'I want to be able to deliver you additional value and if I send you a patch automatically and you've changed the source code, I may blow up your environment.' On the other hand, companies like Microsoft need to learn that open source can deliver additional value and we need to figure out a way to increase our openness."
Before announcing the new licenses, Matusow said that licensing is difficult because source code, even open source code, is property. He observed that the expansion of the number of licenses has been a problem at Microsoft within the Shared Source community just as it has been in the open source community. "Every time I have another product group that comes to me and says 'I want to release code', there's a lawyer behind them saying 'and I have a new term that I want to add.'" Matusow says that this situation is not good because developers need predictable terms to work within. He showed a slide showing more than 1,000 different licenses covering different parts of Linux to illustrate his point.
The plan at Microsoft is to use three templates for licenses for Shared code. The first is the Microsoft Permissive License, which is based on the BSD license. Microsoft has released eight new starter kits under this permissive license. The second is the Microsoft Community License, which is based on the Mozilla model requiring that you contribute back changes to specific files. The third is the Microsoft Reference License, which is a non-open source style license to cover code that Microsoft wants to share with its base of developers, but not with potential competitors. This is a look-but-don't-modify license.
Daniel H. Steinberg is the editor for the new series of Mac Developer titles for the Pragmatic Programmers. He writes feature articles for Apple's ADC web site and is a regular contributor to Mac Devcenter. He has presented at Apple's Worldwide Developer Conference, MacWorld, MacHack and other Mac developer conferences.
Return to the O'Reilly Network
Copyright © 2009 O'Reilly Media, Inc.