Reflections on Open Sources 2.0 - Port 25: The Open Source Community at Microsoft

Reflections on Open Sources 2.0 by admin on May 24, 2006 01:57PM

I'm reading Open Sources 2.0 right now. It's a well-composed book of short essays by founders and luminaries of the Open Source movement - people like Chris DiBona, Ian Murdock, Matt Asay, and Danese Cooper, to name just a few.

So far I've read essays by Mitchell Baker (Mozilla), Chris DiBona (Google/Slashdot), Jeremy Allison (Samba), Ben Laurie (Apache), and Michael Olson (Sleepycat).

They are all well-written and insightful. The most consistent conclusion that the essays I've read so far is that where development is concerned, Open Source development is not that different from commercial software development - similar (although usually more rapid) lifecycles, requirements and bug tracking. Key differences that the various authors cite are greater passion and willingness by open source developers to go beyond "working hours" to solve problems, and the general lack of interest in writing documentation as opposed to coding. This short summary unfortunately trivializes the excellent essays and I encourage you to buy the book and read them yourselves.

I believe that Mitchell Baker's essay in particular offers the most powerful lessons for proprietary & commercial software development companies on how to adapt their practices into shipping open source software. In the Mozilla project, Mitchell was at the forefront of the wrenching practical and emotional shifts required from both AOL/Netscape management and the open source contributors to the project.

Interestingly, Ben Laurie attacks the idea that "many eyes make all bugs shallow", one of the key claims about open source software quality. I myself have been a fan of this idea, and I was surprised to see him dispute it. To put his statements in context, however, Ben is specifically discussing security flaws, which he defines as being of a different class of problem from a standard "bug" or software defect. His point is that it takes deep expertise and hours of dedicated effort to find security flaws, and that most eyes cannot see them.

The most provocative essay I've read so far is by Michael Olson, who discusses the concept of a "dual licensing" model in detail. In short, dual licensing is a commercial Open Source software (COSS) approach that uses the GPL to convert full ownership of software IP into a self-sustaining open source community, while selling a proprietary license of the same source to proprietary vendors. The proprietary license grants the buyer more rights, including no reciprocity - not needing to release their own product under the GPL. This way, paying customers get the benefit of the open source product while retaining much stronger IP protection for themselves. Michael's summary of this balanced model is that the licensing & technology combination must be designed so that "Open source users experience only pleasure in their use of the software" while causing enough pain (Michael's word) to enough customers to make the business of selling proprietary licenses profitable.

This comes to mind most strongly to me because of some of the debates I've seen in the comments on Port 25. Some readers believe that any commercialization of open source software is downright wrong, and a violation of the principles of Open Source. Other readers seem quite willing to allow developers of open source software to make a living from their work. I think this may be an irresolvable dispute - a clash of ideals between Open Source as a movement and open source as a development, marketing, and commoditization model.

So far I've read essays by Mitchell Baker (Mozilla), Chris DiBona (Google/Slashdot), Jeremy Allison (Samba), Ben Laurie (Apache), and Michael Olson (Sleepycat).

Email Digg It! Del.icio.us SlashDot It!

Comments RSS

danese said:

Glad you're liking the book. We meant it to be accessible to many and an accurate examination of the expansion of Free and Open Source software, six years after the phenomenon was first identified in Open Sources 1.0.

Thanks for the endorsement!

Danese

posted at 02:37PM 05/24/2006
einhverfr said:

Funny, even when I was at Microsoft, I argued that the many eyes argument was problematic. Open source software is often of better quality than its closed source counterparts, but this is not always the case. Security is one particular example but it is neither unique nor is it because of special requirements necessary to find the bugs.

The real problem is that bug-free does not necessarily equal high quality or secure. A huge program running in the kernel is secure in the same way our airports are secure-- one incident and the whole thing goes down until the incident can be taken care of... This was my main objection to TUX (the kernel-level web server). I mean, do you *really* want a security problem in your web server to be able to exploit Ring 0?

Instead, software is usually high quality and secure by virtue of design and how it handles bugs, not the fact that it has none. A web server running as a part of the kernel might be *nearly* bug free but it is nowhere as secure as a more buggy server running under a very limited user account. Similarly, a bug-free program that inhibits workflow will be disfavored over a well-designed but more buggy but better designed application. This latter reason is why MySQL has a larger userbase today than PostgreSQL (though now the tide may be turning).

The argument that to many eyes, all bugs are shallow might be true, but it tells you very little about software quality. Bug counts are just one small aspect of software quality.

Note that I am *not* a fan of the design of most Microsoft software. However, I think that this is largely irrelevant to the open source debate (I don't think that if the software was made open source that the design issues would go away any faster).

I will post later on dual licensing models and why I think they are a bad idea.

Best Wishes,
Chris Travers
Metatron Technology Consulting

posted at 03:53PM 05/24/2006
einhverfr said:

I am not a fan of dual licensing models, and your summary of the essay here illustrates why. There are exceptions and companies that have done a good job of providing discrete boundaries around what they own (Sleepycat and Digium being the two that come to mind).

However, these licenses can be very problematic too, especially where the boundaries are later changed. MySQL AB, for example, changed the licensing of their client libraries to the GPL in order to get more people to purchase licenses. When they did so, they turned MySQL from being a discrete product to one that had a virally applicable license. Their web site even said at one point that if one connected to MySQL over something like ODBC, one was still bound by the GPL unless one supported MySQL as one database among many (which, due to MySQL taking liberties with the ANSI standards was very difficult to say the least). While I am not a lawyer, their argument does make sense to me (linking may be indicative of derivation but it doesn't seem definitive to me).

However, leaving aside issues of discrete components, legal threats, conflicts of interes, etc, there is another reason to favor fully open source projects over hybrid models, especially where an open source project is managed by a non-profit group such as a multi-company core development team or a nonprofit foundation. Such open source projects provide greater opportunities for community involvement because there is no requirement to either assign ownership or provide a very permissive license to the company that releases the software. Usually people don't contribute in these cases, and the development pace and quality suffer as a result.

Best Wishes,
Chris Travers
Metatron Technology Consulting

posted at 04:04PM 05/24/2006
Sam Ramji said:

Danese - thank you! From the chapters I've read so far you've succeeded in your goal. Very cool to have you come by Port 25.

Sam

posted at 11:06PM 05/24/2006
Wesley Parish said:

The reason why I've argued for dual licensing with Microsoft's own products, is Microsoft senior management is not likely to listen otherwise.

There are a lot of problems with dual licensing, among them the one of accepting code check-ins from other people. Once there's a policy of accepting from the general public, you don't have the same control over your code as you formerly did. Of course, you can do as the FSF and MySQL do, and require contributors to assign copyright; but that may not always work.

Of course, if the code is "out there" and bug fixes, contributions, etc, get neither acknowledgement or acceptance, you may find the people doing the work may simply decide to take the code and their contributions and make do without you. That is why we have FreeBSD, NetBSD, OpenBSD, DragonflyBSD, etc.

What I suggest is deciding what projects are sufficiently "central" to make some form of continued interest or control by Microsoft highly important, and license those under the Microsoft Community License; license the others (minor projects, etc) under the Microsoft Permissive License; and for those products you still wish to draw an income from, offer a dual licensing deal. And make sure that the rights and obligations of contributors are well understood, before accepting contributions.

posted at 10:43AM 05/26/2006
Port 25 said:

I am compiling a list and analysis of all the analogies and metaphors that have been used to characterize open source software development and its social, technical, and business implications. I think it is unlikely this will be the next DaVinci Code-style

posted at 03:13PM 10/12/2006