Once More unto the Breach

If We've Won, Why Are We Still Explaining Open Source?

At the most recent Apple World Wide Developers Conference, Apple announced they would "open source the next version of its programming language Swift." This minimally means they will publish the source code to Swift using an OSI approved open source license. That's all really. Indeed, the last paragraph of Klint Finley's (@klintron) otherwise excellent article gets it wrong when it says, "But by moving programming languages and other core developer technology into the realm of open source, companies like Apple can provide some assurances that developers will be able to adopt these tools to their own needs without facing legal action." Not even a little bit true. The risks are all still there. Another company could still happily sue the living daylights out of anyone they believe to be infringing their property.

And it's not simply the community and legal basics people continue to misunderstand. There's still a surprising lack of understanding in companies big and small about the business and economic basics. John Mark Walker (@johnmark) recently completed a brilliant four-part series of posts outlining the basic "how to make money" with open source. The opening paragraph to the series begins:

"I never thought I’d have to write this article in 2015. By now, I thought it would be self-evident how to derive revenue from open source software platforms. But alas, no. Despite the fact that the success of open source software is unparalleled and dominates the global software industry, there are still far too many startups repeating the same mistakes from a thousand startups past. And there are still far too many larger companies that simply don't understand what it means to participate in, much less lead, an open source community."

I encourage you to find time to read all four posts [1][2][3][4]. While John Mark presently works at Red Hat, a company that deeply understands the business of open source, his experience goes back almost 20 years to when he worked at VA Linux. 

Companies are indeed contributing more and more to software licensed as open source. Google is building a community around Go and last year began a community around Kubernetes. Go is certainly an interesting language growing in popularity, but Kubernetes represents a decade of Google research and experience in deploying, managing and orchestrating application containers at a time when the industry at large is just catching up. Apple will launch Swift into the public eye. Even Microsoft has learned that they must engage differently with developers and has published .NET (for the second time) late last year. It is no longer about broadcast communities like MSDN.

Building community is where the work gets done for a company sharing assets and collaborating around software, and building community is hard work. There are lessons for Apple to learn and quickly. To build a community, it has to be blindingly easy to engage. The software needs to download and build to a known tested state on a known platform (ideally many) if you want developers to spend time. Otherwise your project becomes one more moribund collection of software thrown over the wall onto github or SourceForge that will frustrate developers and finally chase them away. There are a well known set of patterns and practices that work to enable and build successful communities. This isn't a secret.

And early communities are skittish fragile things. I was part of the original publishing of .NET under an academic research license. There are lessons here for Apple in how to get it "right". We published roughly a million lines of code for the C# compiler, Base Class libraries, and Common Language Run-time (and a complete platform abstraction layer, and a full test harness). Once a developer unpacked the source archive, it was a two [simple] line sequence to build and then test the components into a known state on Windows, Mac OS X, and FreeBSD. The two pages of documentation essentially told you how to do this small amount of work to get to a guaranteed known state, how to prove it running the sample code, and gave a brief discussion of the source tree so people could quickly begin to explore it. [There’s a good description of the original project on MSDN.]

Within 24 hours we received our first righteous patch. A simple 15 line change that provided a 10% boost in Just-in-Time compiler performance. And we politely thanked the contributor and explained we weren't accepting changes yet. Another 24 hours and we received the first solid bug fix. It was golden. It included additional tests for the test suite to prove it was fixed. And we politely thanked the contributor and explained we weren't accepting changes yet. And that was the last thing that was ever contributed. This was done with malice of forethought. And it was heartbreaking. The project was still successful for what it was -- a research platform for programming languages, but it never became a collaborative community around the platform itself. At the time, Microsoft was still very concerned (and conservatively hyper-cautious) about how close the academic code base was to the mainline .NET product space.

So I wish Apple well. It's great to see them participating more broadly in this particular space. They will have challenges in community building, getting the governance right, and thinking through how they want it to contribute to the business. Fortunately there are lots of excellent resources for them to use as they join the broader open source community. Maybe we’ll even see folks from Apple at this year’s Community Leadership Summit. Because as we all know, collaborative innovation is the new engagement mechanism.

882 Patents

So I'm confused. (Not an unusual state for me, I know.) From the Novell acquisition 8-K as referenced in Andy Updegrove's excellent indepth analysis of the deal so far:

The Patent Purchase Agreement provides that, upon the terms and subject to the conditions set forth in the Patent Purchase Agreement, Novell will sell to CPTN all of Novell’s right, title and interest in 882 patents (the “Assigned Patents”) for $450 million in cash (the “Patent Sale”).

N.B. I'm presuming "Assigned Patents" in the above quote refer to the 8-K, and not the USPTO terminology below.

Taking a quick look at what the USPTO has to say about patents Novell owns as assignee, we find:

• Patents with Novell as Assignee Name or Novell as Inventor Name: 467
• Patent Applications [published] with Novell as Assignee Name or Novell as Inventor Name: 290

So 757 patents and applications. Even adding Attachmate's patent portfolio (14 plus two applications) doesn't really make a difference. I don't know how many "unpublished" patent applications exist in the mix. I don't know if there are a pile of provisional filings that don't show up in the list. I don't know if there are patents outside of the USPTO that are different (unlikely) or overlap in different jurisdictions (in which case one wonders at the import of them if only ~100 were cross-filed. Even doing a search through the USPTO "Patent Assignment Database (Assignments on the Web)" only brings up 775 patents with Novell's name on them.

So to me (naively) it looks like Microsoft vacuumed up the Novell portfolio because it could. I find it more interesting that US$450M was paid for the portfolio. That's about a half million dollars per patent. That seems like a rather large premium when the average patent is supposedly worth about US$75K to file and maintain over its lifetime. (Investors should be curious.) I'm betting it has more to do with Microsoft having a lot of cash and needing to make the overall deal terms palatable to all the partners. So as Brian Proffitt pointed out, I'm not sure things are any more dire today than they were a week ago.

The CodePlex Foundation is now the OuterCurve Foundation

The CodePlex Foundation has re-branded itself to the OuterCurve Foundation. There continued to be confusion between the Foundation originally sponsored by Microsoft and the Microsoft forge site (codeplex.com). In June the Board decided it was time to rebrand the organization to clear up the confusion. [Most recently we were given credit for some excellent sponsor work the forge did in the open source community, so we knew the rebranding work was still necessary.]

We worked with a professional agency (Protobrand) and investigated a number of names that conveyed attributes we wanted to have associated with the Foundation. We wanted the name to support our efforts to build credibility for the Foundation within the open source community, and make the Foundation an attractive investment for additional sponsors. And of course we also had to find a name where we could own the urls. In the end we chose the OuterCurve Foundation. We hope it conveys our goal of helping the expanding universe of companies using open source to contribute to the communities they care about and to create their own.

A number of press articles have positioned us as "putting some distance between Microsoft and the Foundation" as the rationale for the rebrand, and I want to emphasize that the distance we're hoping to create is between the forge and the Foundation. We have an excellent working relationship with Microsoft as our founding sponsor. The Codeplex name was originally chosen as there was thought to be more affinity between the forge and the Foundation but it proved not to be so. Not every plan is flawless in its entirety.

The rebranding also coincides with our anniversary. The Foundation is now a year old. In that year, the interim Board put an initial governance structure in place, hired core staff (Paula and I) and we have accepted the creation of two galleries and a half dozen projects. More are on their way. The mission hasn't changed. The Outercurve Foundation exists to provide a software IP management process and project development governance to enable organizations to develop software collaboratively and encourage the growth of the open source software as a development methodology. It's an exciting time.

Some of the coverage:

• Dana Blankenhorn: CodePlex Foundation becomes OuterCurve
• Joab Jackson (NYTimes): CodePlex Foundation Called OuterCurve
• The Register: MS-backed CodePlex Foundation morphs into Outercurve [And no, Paula doesn't gush about things.]
• DJ and H-Online: CodePlex Foundation becomes Outercurve Foundation

Microsoft Failing Its Own OOXML Standard (ISO/IEC 29500)

I was dismayed this morning to see Andy Updegrove's write-up on Alex Brown's post on Microsoft failing it's own Office Open XML (OOXML) standard (formally known as ISO/IEC 29500). It is the second anniversary of the ballot resolution and approval of the standard. While Andy was reporting from the trenches through the final ballot resolution, Alex was responsible for the negotiations that allowed the standard to pass. Essentially Microsoft seems to be breaking the promises it made to the international standards community to get the standard through the process.

If Microsoft ship Office 2010 to handle only the Transitional variant of ISO/IEC 29500 they should expect to be roundly condemned for breaking faith with the International Standards community. This is not the format “approved by ISO/IEC”, it is the format that was rejected.

Unfortunately it's unclear what condemnation will bring. Even were the EU Commission to involve itself as Alex later suggests, it is unlikely that this would effect shareholder value in any meaningful way.

Alex also wonders at how such bad implementation can be allowed to happen:

So why — given the awareness Microsoft has at the top, at the bottom, and round the edges [for standards] — does it still manage to behave as it does? Something, perhaps, is wrong at the centre — some kind of corporate dysfunction caused by a failure of executive oversight.

It's nothing sinister I suspect. Cynically — it was nobody's job, and by that I mean no development manager or program management manager (or test manager for that matter) of any reasonable authority or seniority likely had it as a primary rewardable objective on their annual review. If the bugs were even filed, they were likely never deemed sufficiently important to fix during bug triage on the road to release-to-manufacturing. I saw bug triage meetings circa 1999 on the road to Windows 2000 where non-critical bugs that were effecting 10,000 beta customers were ignored because there were other bugs effecting 100,000 users. When you ship a product that has a consumer base of tens of millions, you learn different skills in the triage process. I suspect it's similar on the Office side of the company.

And Alex is completely correct, there would be no executive oversight pushing down from above on the Office development organization. The vice-president that published the open letter two-years ago making the promises has probably either (a.) moved on to other responsibilities, or (b.) assumed he had made the promise and someone else was to carry it out. It won't be on his review objectives either so he's still being well paid. So too with any other exec in the pipeline two-years ago. Even the standards team that worked so hard to get it through the ECMA and ISO processes will have moved on to other standards (and certainly wouldn't be so naive in the product-centricity of Microsoft to have accepted such an objective so far out of their control). The marketing team got its talking points two years ago. This is a cultural problem. The development teams within the company (i.e. the revenue generation engine) with a few exceptions in a few Web-related product teams just aren't tuned to deal with standards in a serious manner the way certain other vendors do.

Until there are serious lost sales to do with non-conformance from large government organizations, and the field organization starts to seriously yell, there will be no understanding in Redmond that it really mattered and that certain government officials may even have bet their careers on such promises. Even then, the first question in Redmond will [cynically] be, "How much do we sell to the Ministry of [Big Issues] in [Name-of-small-northern-European-country]?"

Alex finishes with the quote:

In short, we find ourselves at a crossroads, and it seems to me that without a change of direction the entire OOXML project is now surely heading for failure.

Failure indeed. I used the photograph at the top of the post two-years ago when I cynically predicted how this was going to go down over time. I summarized my opinions on the battle between ODF and OOXML and how Microsoft should have played the war as one of the examples in a standards primer I wrote around the same time. It will be interesting to watch how Microsoft responds to Alex's post. The world is indeed watching.

Open Source Software Economics in Pictures

Updated [22-Mar-2010]: Added a little text around the Ohloh javascript widget so Google Reader sees a URL to follow.

Recently, I've encountered several technologists that still don't understand open source software economics and got suitably cranky about "people giving away software for free" and "destroying the value of innovation". I thought it time to try to reach for an easier way to demonstrate what's happening in the industry in pictures.

Everyone is familiar with the idea of a normal "bell curve" distribution representing R&D investment over time. As a technology is better understood and a product succeeds in the marketplace, R&D investment increases, and over time as new technologies advance, the R&D investment in the original technology and product wanes. The integral represents the total R&D investment over time. The function can also represent the "knowledge" gained or the increase in the intellectual asset base.

Good companies develop and invest in new successive waves of sustaining technologies. So, looking at Microsoft's success with PC operating systems, DOS was replaced by a greater investment in a more innovative Windows, was replaced by a larger investment in a more innovative NT.

This also fits nicely with Christensen's original observations about incumbent companies being good at sustained innovations and well run companies knowing how to jump from technology to technology along a sustaining innovation path. This all makes sense when considering a single company's R&D investment. It applies equally well to Sun Microsystems when considering that the steeper slope of successive sustaining innovations was on the hardware side versus the slower (but not inconsiderable) investment from SunOS (a BSD variation) to Solaris.

The investment curve for projects like Linux and Apache, with lots of individual and corporate contributors, still looks like a bell curve, but the contributions might better be viewed as a stacked bar chart. Individual contributors invest to meet their specific needs. Because there is enormous overlap in their common needs, they all share the overall investment.

Individual contributors get enormous return on their investment. (One gives a few bug fixes to the Apache httpd team, and in return one gets an entire HTTP daemon.) Corporate contributors give for the same ROI. They get enormous return on their investment in technology they use in a product complement space or as a component in their overall solution to the customer. (Before someone takes issue with my Red Hat example above below, understand the "solution" in the customers mind was "UNIX-like servers on inexpensive 'PC' hardware" and not "Linux".)

Christensen was careful in subsequent work to point out that the disruption wasn't about technology but about business model. The disruption often started when someone assembled standard cheaper lower performing parts into a solution that solved a completely different need with a very different cost basis. The new solution begins its own sustaining innovation curve until the new technology can compete with the incumbent compared against the criteria about which the customer/consumer cares.

The disruptive business model isn't about Linux so much as the ability for corporations to do collaborative development at the component/complement level in a "frictionless" well-managed Internet-enabled community. (The original OSF/1 shared-development of a UNIX-like replacement failed: too few players, too much politics.) Linux is a much stronger disruptive business solution as a way to handle a particular sourcing problem.

It would be interesting to consider the difference between projects with enormous inbound code contribution (versus all the other strengths a well run community brings to the table) distributed across a wide group of players like we see in the Linux and Apache projects, versus projects managed more tightly by a company like MySQL was. Another interesting attribute of this collaborative business model to investigate is how contribution mutates over time. Christensen's work demonstrated that an incumbent gets in trouble when they begin to over-deliver on functionality for attributes their customers consider important. The customer can't absorb the sustaining technology innovation any faster and literally won't pay for it. The slope of the sustained innovation of the competing technology is sufficient to cross into the space covered by the incumbent's solution.

In a shared collaborative development environment, however, because the technology isn't being driven by a single corporate entity, the community of corporations collectively contributes to their own needs and the technology may (i) stabilize where it needs to stabilize, and/or (ii) be taken in new and interesting directions. There is less pressure (if any) to over-deliver with new innovation. The consumers are the developers, but it's a very broad community indeed. This is what I believe just happened with the MeeGo announcement and the combining of the Nokia Maemo and Intel Moblin projects. This is a great inflection point for Linux into the new mobile Internet device space.

One only need read the report from the Linux Foundation charting the growth statistics in the Linux kernel to understand the enormous value generation happening release-on-release, four times a year. Using the Ohloh rules-of-thumb of US$55,000 per person year one gets US$142M of value creation in the 2.6 Linux kernel. The fact that some business models have been destroyed (Sun), or threatened (Microsoft) doesn't mean there's not enormous ongoing value creation in the technology.

Ohloh value chart for Linux 2.6 kernel.

Neither is intellectual property being "destroyed". Again, this is a disruptive business model discussion. Intellectual property is a business choice made on how a company will protect certain intellectual assets as legal property. Which assets to protect, and how, and which property to defend is a business choice based on the cost model a business uses with respect to turning assets into value propositions customers will buy. When a group of companies chooses to collaboratively develop a technology complement/component, they're making a business model choice on how they will selfishly share certain intellectual assets. Nothing was destroyed along the way.

MeeGo: Nokia, Intel and the Future of the Mobile Internet Platform

This week Intel and Nokia announcement the merge of Intel's Moblin and Nokia's Maemo platforms into MeeGo, a single platform for mobile computing. This is a great announcement for a number of reasons.

Nokia demonstrated it's ability to participate within active open source communities as it developed and launched the N770 tablet as a consumer device and maemo as a computing platform several years ago. (The N770 pre-dates the iPhone.) This wasn't a cut and run on the Linux kernel to grab a fork then forever be stuck supporting it. This was an excellent demonstration to themselves that they could use an active royalty free OS and continue to share the development costs. Ari Jaaksi's report on the experience is enlightening. Nokia has since acquired TrollTech, released the Qt tool kit appropriately, (and then acquired Symbian Ltd. and released its handset OS software assets into the open source wild through the Symbian Foundation).

Intel developed and released Moblin over the past few years as a Linux distro for mobile computing. They carefully positioned it NOT for handsets, but for all the other cool mobile Internet devices in your life like tablets and in-vehicle systems. They could do lots of interesting device related work on the Linux kernel for things in which the mainstream Linux wasn't interested and still get the cost advantages from shared development for the platform as a whole. In a very short time it has become one of the more interesting Linux distributions from a hardware innovation perspective.

The positioning is key here. By focusing this on "mobile Internet devices" they avoid the whole iPhone versus Android debate, Windows Mobile has no comment to make, LiMo is still wandering in the wilderness, and Symbian isn't in a position to comment. All of those are thought of as handset operating systems. This is future forward and about the mobile Internet. And don't just think iTouch and tablets in the coffee shop. Think of your home as a wifi space. Microsoft and Apple continue to demonstrate that people DON'T want another PC in the living room for media management. So what are all the other devices you can imagine in your home that are NOT "computers" that could become the synchronization hub of your world's information and media.

• What about a wifi device suctioned to my refrigerator door where the shopping lists are kept and the family calendar at a glance (with reminders),
• or a device that looks like a VoIP phone with a wireless handset in a stand that also has the family phone book(s) in it, but synchronizes with your mobile phone handsets for calendars and contacts,
• or what if my "media centre" didn't look like a media centre at all, but was a tablet that talked to a black box shoved out of site behind the couch, but would also sync my mobile phone or Kindle or Nokia N900 Internet Tablet,
• or there was a small charging pad on the kitchen counter where keys and mobile phones and personal media players are dropped to sync across family calendars, contacts, and the latest episode of a show I'll watch or listen to on tomorrow's commute (while inductively charging my phone).
• What if all these devices could communicate with one another?

All of these imaginings will need an operating system. Microsoft may have made computing in the home ubiquitous in a PC-centric world, but no consumer OEM or ODM today will want to repeat history and watch all high margin profits go to a single software company via royalties. Maintaining individual forks of Linux isn't cost effective either. But sharing the value creation of a robust complete applications platform in an open source project free to all would certainly answer the call.

Microsoft Hyper-V and Hannah Montana Linux

For all my system administration friends and readers: John Kelbley is a system administrator and interop specialist hiding behind the title of Senior Technical Product Manager at Microsoft in the server team. He's also one of the authors of Windows Server 2008 Hyper-V: Insiders Guide to Microsoft's Hypervisor. John started blogging recently, and he hopes to cover the edges and missed documentation opportunities in the Hyper-V world for those living in a mixed interop sort of environment. Here's the entry on "Backup and Recovery of Non-Windows VMs on Hyper-V" (and the reason why Hannah Montana is in the post's title). Enjoy!

[In the name of full disclosure, John has been a client in the past for unrelated work.]

Open Source Business Tactics in One Slide

I recently found a slide I used six years ago to explain open source software in a business context to Jim Allchin back when I worked for Microsoft and Jim was executive VP of all Windows. My job was to develop an open source engagement model, working in a team called Platform Business Management, which reported directly to Jim. Jason Matusow was responsible for driving the Shared Source agenda, initially working in the Windows marketing team and later as an immediate peer in PBM. The meeting itself would have been sometime in June 2003 (so shortly after Sun's threatened injunction against Windows). I tried to ground the tactics in product practices Microsoft already well understood and with company examples pulled from other large multi-billion dollar corporations, i.e. while our shining open source company examples might have been Red Hat, MySQL, and JBoss, they were meaningless examples to Microsoft based on revenue size. The slide worked. Jim understood why Microsoft needed to adopt its own open source practices, and how we might start. [There were other slides in the presentation discussing options for engagement and contribution that are confidential.] The execution was another matter entirely within the software product executive culture of the company, and isn't relevant here.

There are a few things to consider as you read the slide and the notes I used to present additional material:

• The information density of the slide is normal at Microsoft (or was in my day) for exec presentations. It complemented a style of discussion that's come to be known as precision questioning. You simply don't have the discussion and decision making flow required if you're trying to drive a particular train of thought through a slide build and flow. This sort of info density is about presenting the maximum amount of related material visually and letting the exec drive the questions. It's amazingly effective if everyone understands the protocol.
• I've not changed any of the wording on the slide or the associated notes. [There's nothing confidential.] Some things may feel dated, and I've certainly evolved and expanded some of my thinking, but I still stand by what I wrote. There are few words I would change today and while I might pick more current examples, these ones were absolutely relevant at the time.

Here's the slide:

Here are the notes I used with the slide:

OSS Development Projects (technology buckets):

Bullet 1 and 3. Good developers develop good software. Good developers have discipline and process. They don’t know how not to have discipline. So version control, CM, design reviews, strong vision communication, automated build management, coding standards, automated test harnesses, bug tracking, peer code review, strong tool support. All understood and published for decades. None of this is attributable to OSS as a development methodology or licensing mechanism. You can think of this in the inverse: of the thousands of OSS projects hosted by SourceForge, why are so few (relatively speaking) noteworthy? (There's also a couple of good papers on how few people actually anchor the few key projects.)

Bullet 3. The projects in the OSS world that matter are anchored by good developers and they're developed using a UNIX development mentality. They have all been developed since the advent of "cheap" networking (at least between the universities and major corporations) through the Internet (email, netnews, and ftp). The Internet enabled the rise of OSS -- not the other way around -- and it was the low-friction medium through which people could share the software. Add a license that requires source code publication and permits libre use of the source code onto the UNIX component model and you have the techno-social movement.

Bullet 4. Examples: the individual contributor to Apache (gives “3” bug fixes but gets back 100s), versus Shell Int’l contributions in a team (code/$$) with management approval to Samba.org (while deeply protecting their own software assets), versus Sun contributing the accessibility features to the gnome desktop in return for a complete desktop for an advanced “UNIX” based desktop.

Bullet 4. People value the work they do differently in different contexts: think of a technical publications person using their writing skills to complete documentation at work, helping their child’s class room complete a writing project in a parent-child project, and writing a sonnet to someone they care for. Same skill set in all three situations, one for money, one as a contribution in community, one as an act of friendship. Or a program manager that spends time on a not-for-profit board in their community using the same skill set they use at work for money.

So what's next?

Applied OSS:

Bullet 3. Msft is an expert here. Publish specs to drive complement value add. Provide certification programs to ensure lots of service providers. Buy, integrate, and bundle. Etc.

OSS Becomes Big Business

Bullet 2. From IBM’s point of view in the product marketing space: every apache installation is a potential customer for Websphere. From a Linux perspective, they are driving home the message that OSS and Linux are the fulfillment of all “our” investments in open systems and open standards, using multiple congruent tactics of OSS participation, standards participation, and patent license management to control the AIX commoditization – which they publicly state is happening – then quickly qualify the remark to a 10 year time frame. With Eclipse, it’s no longer “buy” versus “build” versus “borrow”, it’s “share” to control the java development space and drive complement value add around their world.

Microsoft Starts Codeplex Foundation

Updated [14 Sep 2009, 15:50]: Added a pointer to Andy Updegrove's excellent analysis of his concerns with certain structural aspects of the Codeplex Foundation. It's analysis like this that will keep discussions in the first 100 days lively.

The Codeplex Foundation began on 10 September, 2009, with initial funding from Microsoft. It's mission simply stated "is to enable the exchange of code and understanding among software companies and open source communities."

Today that means:

The Codeplex Foundation provides a framework to facilitate the participation of commercial software developers in open source projects, either through intellectual property contributions to the foundation or through time volunteered under the auspices of the foundation to enable development work on open source projects. The Codeplex Foundation also provides a channel of communication from the open source community back to Foundation partners and other commercial software companies, advancing the dialog between commercial software companies and open source communities.

There's an excellent mini-presentation and voice-over interview with Sam Ramji, the foundation's interim president on SlideShare:

Introducing The CodePlex Foundation

View more presentations from CodePlexFoundation.

The foundation has an interim board of directors (that includes Miguel de Icaza) to take it through the next 100 days, and an advisory board that includes an experience group of people from both outside Microsoft (e.g. Larry Augustin, Aaron Fulkerson, Robert Gobeille, Monty Widenius) and Microsoft employees that continue to do good work in the open source community (Phil Haack, Scott Hanselman, John Lam, Jim Newkirk).

I've agreed to participate as an advisor as well. I believe this is an important step for Microsoft. While there is obvious benefit to Microsoft to continue to participate and develop the open source world with respect to its core revenue streams, there is a lot that can be learned from developing such a foundation in and of itself (as IBM discovered in its own time). There is a gap in the discussion between commercial developers wanting to do more in the open source community and this organization may be in the right position to help foster that discussion. Over time I hope to work with the board and the advisors and contribute as I best can to build that organization.

There's good coverage on a number of channels, some from advisors explaining what they see is the opportunity, some from the press and analysts asking good questions about the future of the foundation:

• Matt Aslett's 451Group commentary.
• Scott Hanselman's (Advisor) blog post.
• Miguel de Icaza's (Director) blog post.
• Bill Staples (Director) blog post.
• Peter Galli's Port25 blog post.
• OpenSource Magazine reportage.
• eWeek article from Daryl Taft.
• InfoWorld article by Paul Krill.
• PCWorld article from Elizabeth Montalbano.
• Andy Updegrove's analysis of the structural aspects of the new foundation.

Microsoft and the Release of Linux Drivers Under the GPL

Microsoft announced that it is releasing a collection of software drivers under the GPLv2 to better enable Linux to run as a first class citizen on their Hyper-V technology. Matt Aslett and Stephen O'Grady provide excellent commentary [as always] and I won't rehash their discussion here.

This is a significant move by Microsoft.

It isn't the first time Microsoft contributed code under the GPL. In the early part of the decade (~2000) the Interix team contributed a reasonable amount of code to the gcc compiler suite that was accepted. We assigned rights of ownership to a Microsoft asset to the FSF as needed. We published the sources as the license required. But that was a different time and a different climate and the last thing Microsoft wanted to do was admit they were contributing to a free software project outside their walls, or that they were shipping software covered by the GPL in a Microsoft product.

Neither is it the first time they've shared their own code. Rob Mensching has been running the Wix project since 2003. That's a project started on SourceForge using a non-Microsoft license (the IBM Common Public License) using a software tool base that is still in significant use inside Microsoft for delivering products.

But then things appeared to shut down from a code perspective. Much of the past five or six years has been Microsoft contributing anything but code. Money to Apache or Eclipse, providing a site where others can contribute code, ensuring third parties make arm's length contributions rather than Microsoft staff, and esoteric contributions such as requesting approval for licenses from the OSI. Their messaging remains guarded. The "position paper" released in March co-incident with the Open Source Business Conference had the same move-to-the-middle ambiguous messages and excuses that began in ~2002 with the Shared Source Initiative. [Misquoting a study to try to demonstrate open source software is still rough and only developer friendly doesn't win them points either.]

The current Linux contribution is significant. It's a significant quantity of code. It's an attempt at direct participation in a major mainstream open source software project to meet business objectives. It should be encouraged. It's an opportunity for the Linux community to embrace-and-extend Microsoft.

As Stephen O'Grady observes at the end of his commentary:

"Microsoft is, this week’s contribution notwithstanding, still holding open source at arms length, in contrast to an IBM who embraces it strategically in certain areas in service of a larger strategy.

But while it is not a conversion, it is important news, a welcome development, and a job well done for those involved. "