Once More unto the Breach

The CodePlex Foundation and the Free Software Foundation

The Free Software Foundation commented on the CodePlex Foundation existence on Monday. Presumably it was a slow news day at the FSF. Richard well describes his concerns and brings it all down to the standard list of concerns on software freedom, gently extending it out to all the additional freedoms that must be in place to say you truly completely support free software. He makes some conjectures based on his concerns and definitions, and finishes by rolling it back to warn people to stay focused on the FSF mandate on software freedom and avoiding Microsoft traps.

Sam Ramji (acting president of the CodePlex Foundation) posted commentary on Tuesday to correct a couple of FSF opinions, demonstrating he does understand that commercial software companies can thrive on free software and that the while some members of the board of directors and board of advisors may be Microsoft employees or ex-Microsoft (me), there remains breadth and depth in the bench of people participating initially that have real experience in the commercial free software world.

Once again we're having the Democracy versus Capitalism debate. Really, we need to move on. This is not a helpful debate. It started in the mid-1990s in the broader FOSS community itself. It unfortunately informed and fuelled Microsoft's messaging around Shared Source through the early part of this decade as they tried positioning everything on a linear spectrum with words like "free", "open", "commercial", and "proprietary". It doesn't work that way. It's the precursor to the Free and Open Source Software Business Model debate. It's about as useful.

The one nit I would pick with the FSF debate with respect to the CodePlex Foundation is when it opines about their definition of "proprietary software". The OED gives us a slightly better definition. Proprietary as an adjective means:

b. Of a product, esp. a drug or medicine: of which the manufacture or sale is restricted to a particular person or persons; (in later use) spec. marketed under and protected by patent or registered trade name.

It's about property. All our free and open source software licensing works because the software is someone's property covered by copyright. Proprietary software, however, actually would mean protected by patents and trademarks. So, Fedora, Linux, MySQL, Apache, and so too I believe "GNU Emacs". We need to get beyond the debate.

Stallman does say:

Someday we will be able to judge the organization by its actions (including its public relations).

I'm fairly sure the CodePlex Foundation will never live up to the FSF definition of software freedom purity, but I am looking forward to getting more organizations to contribute software and collaborate on development using free and open source licenses. And that's a pretty good thing.

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. "

The Microsoft versus TomTom Patent Debate is about the Mobile Internet not Linux

The Linux community is up in arms over Microsoft's filing a patent infringement suit against TomTom, the Dutch navigational unit manufacturer, determined to convey this as an opening move in the debate about what patents Linux does or doesn't infringe. This suit is very likely NOT about Linux. Let's look at the patents. From the complaint, Microsoft patents in the case (collectively, “the Microsoft patents-in-suit”):

• 6,175,789 (16 January, 2001) Vehicle computer system with open platform architecture
• 7,054,745 (30 May, 2006) Method and system for generating driving directions
• 6,704,032 (9 March, 2004) Methods and arrangements for interacting with controllable objects within a graphical user interface environment using various input mechanisms
• 7,117,286 (3 October, 2006) Portable computing device-integrated appliance
• 6,202,008 (13 March, 2001) Vehicle computer system with wireless internet connectivity
• 5,579,517 (26 November, 1996) Common name space for long and short filenames
• 5,758,352 (26 May, 1998) Common name space for long and short filenames
• 6,256,642 (3 July, 2001) Method and system for file system management using a flash-erasable, programmable, read-only memory

Also from the complaint, we have this statement (line 15):

6. Upon information and belief, Defendants are in the business of developing, manufacturing, and selling portable navigation computing devices and software for use on those devices, personal computers, PDAs, and smartphones (hereinafter known collectively as “Portable Navigation Devices and Software”).

This feels much more like positioning for location-based services and the coming mobile Internet war. Microsoft has been the "PC company" for a long time. It got there on the backs of a standardized PC "device". (In a Christensen economic world of a network of complements, Microsoft captured the innovation premium in the OS on commodity hardware.) That world is changing rapidly since Apple demonstrated what the mobile Internet can look like with the release of the iPhone. There has been a rush of delivering iPhone competitors to market since then. Nokia bought Navteq, then Symbian (the predominant mobile OS), to be released royalty free and as open source sometime in the future. Google released Google Maps with instructions to drive places, and then developed and released Android. There are considerably more handset devices on the planet than PCs [see note below]. This feels like a much bigger fight than the first shots in a Linux patent fight. This could have much bigger ramifications for Nokia (and the other handset manufacturers), Google, and Apple than Red Hat et al. These are the players that need to be naming themselves to this patent litigation suit.

Related commentary:

• Microsoft v. TomTom: Patent war, or no?, () Matt Asay's fine blog commentary
• Microsoft sues TomTom for alleged patent infringement, (25 February, 2009) by Ina Fried
• Has Microsoft's Patent War Against Linux Begun?, (25 February, 2009) Glyn Moody's commentary
• Beating the TomTom: Drums of War? (Not), (26 February, 2008) Andy Updegrove's excellent commentary
• Microsoft lawyer 'won't speculate' on Linux suits, (25 February, 2008) Ina Fried's CNET interview with Microsoft's Horatio Gutierrez, senior IP lawyer
• The Microsoft Press Release, (25 February, 2009)

Note: Communities Dominate Brands pointed out that there were 3.3 Billion mobile subscriptions in 2007 versus 900 Million PCs. Or to put this in better context:

Now as the phone handset makers like Nokia, Samsung, Motorola, SonyEricsson and LG ship over a billion phones annually (IDC, Jan 2007), we have a colossus of an industry of high tech pushing ever more powerful gadgets into our pockets. And yes, Nokia alone ships one million phones every day of the year, Saturdays, Sundays and Holidays included. For contrast note that the PC industry shipped 250 million new PCs in 2007, of which about 100 million are laptops (Computer Industry Almanac Jul 2007).

Building an Effective Commercial Open Source Strategy

Initmarketing partners Sandro Groganz and Roberto Galoppini taught a day long workshop entitled "Building an Effective Commercial Open Source Strategy" in Berlin at the Open Source in Mobile conference. I was unfortunately unable to attend (and I love Berlin), but I contributed to the materials. It is essentially our combined experience and expertise wrapped up into a one day how-to seminar.

Roberto has posted a great summary of his presentation on his blog.

Nokia and the Symbian Foundation Opportunity - Part II

The previous post looked at the Nokia acquisition of Symbian from the competitive perspective. Let's now look at the opportunities and challenges for Nokia and the new Symbian Foundation. Remember that assuming successful regulatory approval, there will be no Symbian Ltd. anymore. Nokia will need to manage the challenges that come with any acquisition. When you buy a company, you essentially acquire the assets (in this case the software), the intellectual capital of the employees, and the customers.

This acquisition is particularly interesting as key Symbian Ltd. shareholders and customers have banded together to deliver the primary software assets into a not-for-profit organization. There's a great white paper outlining the initial strategy on the currently minimalist Symbian Foundation site.

Essentially:

• Nokia will acquire the remaining shares of Symbian Ltd. that it doesn't already own.
• Symbian Ltd. employees become Nokia employees.
• Fujitsu, Motorola, Nokia, NTT DOCOMO, and Sony Ericsson (all Symbian Foundation board members with the exception of Fujitsu) will contribute SymbianOS, S60, UIQ, MOAP and related software and documentation assets to the newly formed foundation.
• The initial board directors will be AT&T, LG, Motorola, Nokia, NTT DOCOMO, Samsung Electronics, Sony Ericsson, STMicroelectronics, Texas Instruments and Vodafone.
• The foundation launches (expected in early 2009) and all the assets will be available to members under a royalty-free license.
• A new platform will be developed from SymbianOS and S60 with selected components of UIQ and MOAP. The first release of the unified Symbian Foundation platform is expected to be available during 2009. The platform will offer the means to build a complete mobile device while providing the tools to differentiate devices through tailoring of the user experience, applications and services.
• The new platform is to be backwards compatible with SymbianOS v9 and S60 3rd Edition.
• Platform assets will be made available as open source gradually over the next 2 years, with the intent to use the Eclipse Public License (EPL) 1.0, making the platform code available to all for free.

Most of this is fantastic news. The economics of code sharing, value preservation of the intellectual asset, and innovation capture will be delivered through the foundation with the primary stakeholders sharing the costs. This is a perfect example of the economics of shared development in this particular market space and "why open source software."

Organization and governance of the new Foundation will be key. The foundation is open to all and membership will cost US$1500. The primary board members will share all the operational costs. This seems a reasonable way to manage the cost — it's likely much cheaper than historical royalty payments and it scales well versus a fixed premium membership fee structure seen in other places. The white paper describes the functioning of the foundation based on the following structure.

As a side observation, it would behoove Intel to get involved early on, conceivably as a primary board member and share the costs. As the mobile world of phones and laptops converge, they should be investing beyond moblin.org. That is NOT to say that the mobile world will be a single class of devices in the future, but rather the space will overlap for some time and I would think Intel would want to participate as widely as possible.

So where are the edges that need to be carefully considered in the new Symbian Foundation?

• While the foundation is open to all, and the list of membership benefits is well defined today (in the white paper), one of the benefits reads: Right to access and modify foundation source code, and contribute code to the foundation. This needs to be rethought along the lines of how the Eclipse Foundation manages committers and contributors. The Symbian Foundation is deliberately cutting off unknown sources of contribution if they make it a membership benefit. There is no loss of control in encouraging (and vetting) contributions from as wide a population as possible. Putting gates around the community early, or discouraging contributors looks arrogant and risks the community's participation and growth at precisely the time when it is most needed. Microsoft certainly demonstrated how fast you could pour cold water on a community with the Rotor project. Motorola had its early Linux community vanish. Heavy-handed control and "we know best" attitudes hampered the early critical growth of the OpenSolaris community. Who knows what sources of innovation will be cut off (and will defect to other projects) with this gate in place.
• "Backwards compatibility" as an absolute goal. This is not a bad thing per se, but it feels like the backwards compatibility requirement exists to deal with a long delivery cycle — essentially asking developers to begin developing today for the open source platform delivery in two years and the promise that the investment will be protected. All complex dynamic software hits a point in its evolution where a re-write is required. (The Linux kernel rewrote the entire VM and scheduler after about 10 years of evolution with modern architectures.) Backwards compatibility becomes the challenge. But the opportunity forward MUST be bigger than the backwards compatibility option. It needs to be managed in the community, i.e. this is a community issue and a delivery time-line issue. Think of the opportunity that Microsoft took moving from the Windows world of the late nineties to the new world enabled by NT. Think of the enormous opportunity Apple took moving from Mac OS9 to Mac OSX. Think of developing a community of innovation forward like the Mozilla world and Eclipse.
• The whole two-year process feels like a traditional corporate engineering culture trying to manage change around a well established product space. This would be great if this was what Symbian Ltd. was to remain (but even then it risks being a dead-end overtaken by other solutions with the coming mobile Internet wave). When IBM began the Eclipse Project, they put safe IP structures around a software base, some simple governance and a road map in place, and got on with the work. Later, the Eclipse Foundation was created as a better way to manage the inbound innovation and growth under a well defined IP regime. Now, the Eclipse Foundation and Mozilla Corp. provide excellent blueprints for what the Symbian Foundation needs to be. Nokia already has the inhouse experience to build from those blueprints. Engineering cultural change is difficult but essential here. While one wouldn't expect Symbian Ltd. to release its core assets while awaiting regulatory approval, there have to be other complementary software assets internally available that could be released as early experiments to begin to get the IT structure in place and begin the cultural learning. Two years gives Android and LiMo and even Windows Mobile too much time to erode a community that should rightly be coming to the Symbian Foundation.

These are all key issues. Cultural change is hard in any acquisition. In this case it is doubly so for an engineering team used to delivering to a particular set of customer requirements now dropped into an open source world and needing to understand how open source works and customers and users differ, as well as for a business team used to driving platform revenue and profitability that need to consider now driving platform adoption as an end goal unto itself.

The Symbian Foundation is an opportunity not to simply re-invent the mobile phone platform, but to build the most innovative shared platform forward for the coming mobile Internet. Working with peer organizations like the Eclipse and Mozilla foundations, and arguably the Android project, a stable dynamic open source platform can be created that best suits the needs of customers and consumers for some time to come. Nokia's vision and foresight open up amazing possibilities. Here's wishing them speedy success.

Nokia and the Symbian Foundation Opportunity - Part I

Sixty days ago, Nokia announced it was buying the rest of Symbian Corp., and would then open source SymbianOS using the Eclipse Public License through a newly created Symbian Foundation. This is a great announcement. Stephen O'Grady did an excellent Redmonk Q&A analysis at the time. Nat Torkington also had cogent analysis on what it may mean with respect to Android. There was lots of other commentary, however, that wanted to portray this as a last ditch effort against Android, Linux and LiMo, and the coming wave of the iPhone. Let's step back for a moment.

This is a fantastic exit for Symbian. They're celebrating their 10th anniversary at the peak of their game with enormous market share, but there was going to be trouble on the horizon. If you saw the Symbian presentations of a couple of years ago, they all looked to China, India, and the other developing economies and assumed a proportionate claim of market share. But here's the rub — when you start talking a few dollars royalty per handset then royalties quickly fall into the billions of dollars when you consider "handsets for [India | China]". For a billion dollars, I can start thinking about other alternative operating systems and indeed that's what Symbian's primary shareholders began doing.

Motorola delivered the Ming phone into China on a cut-down Linux base. This was almost a year before the iPhone "happened" and for the Chinese market was arguably a much more useful "phone". (Full stylus input for Chinese characters — think about that and texting.) The Ming was the first 2MP pixel camera (with business-card-to-contacts-database software that worked with the camera), a media player, and came in a sleek package. This was likely just the beginning of the shift away from SymbianOS in emerging markets, especially considering there are Chinese companies working on cut-down Linux-for-mobile platforms as well.

The announcement was a great acquisition for Nokia. For on the order of two years of royalty payments to Symbian, they now own the whole asset, regardless of whether they share it. But Nokia too was considering how to best work in the open source community and using Linux as a base for around the N770/N800 series Internet tablets.

Let's look at the competitive landscape for a moment before looking at the enormous opportunity in front of Nokia and the Symbian Foundation.

The "Competitors"
The iPhone isn't competition for SymbianOS. The iPhone, true to Apple's history of profitability over market share and its cult of design and usability, is an amazing consumer experience. The complete Apple experience depends upon controlling the entire technology stack in a tightly integrated fashion. In Christensen economic models, the iPhone is a new class of product and will deliver more value to its customer target over the coming years through tight control and integration than can be delivered through standardized interfaces and components, and Apple will reap the margin benefits. That same focus on function and design also means Apple will never own 65% of the global market — it won't be producing $25 iPhones for Africa anytime soon. What Apple has demonstrated to the mobile industry with the iPhone is what the mobile web experience can be. They may have "only" sold a couple million units in their first year, but they are driving 65% of the web's mobile traffic on iPhones/iTouch devices (stat from Jason Grigsby's excellent OSCON presentation). The iPhone is an innovation example for Symbian, not a competitive threat.

Google's Android is interesting. Google wants to drive application development with Android that uses Google services to find ways to grow their ad revenue as the mobile web comes into its own. They are discovering the difficulties of delivering a handset OS — something around which the Symbian engineering team has a lot of experience. Since Google isn't actually a device company, this feels like an opportunity for each of them to explore their complementary spaces. Google application services running on a Symbian base would seem to be a win for Google and application developers trying to settle on a model while allowing Symbian to do what it does best and focus on developing a strong developer community. Since the Symbian Foundation will not be under a market competitive revenue gun, profit-centric competitive decisions are removed that might have historically put co-operating with Google at risk. Android should be an opportunity, and not a competitive threat.

LiMo was created to provide a common Linux fork for mobile. The mobile handset manufacturers have shared technology through Symbian Inc. for ten years. As the industry changed and the royalty became a problem, they all wrestled with Linux. They need a royalty free OS, but trying to integrate into the Linux community has been a source of frustration for quite some time. Things that are critically important to handset manufacturers aren't necessarily even interesting to the mainstream Linux community. Each handset manufacturer was forced to fork their own. Before Android (a company-centric platform from a non-device company) and before Symbian became open source, LiMo was likely the best opportunity for a shared royalty-free platform. The most damning thing for LiMo pre-Symbian was probably Nokia's proven ability to work in the open source community to develop the N770 without a fork. The Symbian Foundation use of the Eclipse Public License will also likely make handset manufacturers much more comfortable — the EPL IBM-lineage ensured that the hardware patent clause was still intact. So LiMo is not a competitive threat for Symbian, but the reverse is not so true.

Windows Mobile is not interesting. Microsoft has seen mobile computing coming for sometime, but there are several problems. First there's the royalty problem. Second there's the open source culture versus IP protection problem, both internally and from an external partner perspective. Lastly, there's a very subtle cultural problem. In the early days of mainframes and minicomputers, users thought in terms of a data record/transaction metaphor. The PC introduced users to a document metaphor for computing. The mobile phone space uses a communications metaphor. Microsoft thinks of the mobile phone space as a small powerful PC used to read Word documents to drive data revenues for the mobile network operators, and that's not the sort of mindset the handset manufacturers have. (Another startling statistic from Jason Grigsby's excellent OSCON presentation: 2007 SMS revenues were $100B, which is more than the Hollywood box office, DVD sales and rentals, the music industry, and video game sales combined.) So while Windows Mobile was interesting in a pre-Symbian Foundation world, it still only had a quarter of the deployment of SymbianOS, and now Symbian will be royalty free. So Windows Mobile is not a competitive threat for Symbian, but the new Symbian Foundation done right will definitely threaten Windows Mobile.

It was interesting to see almost no discussion over the past couple of months around Ubuntu Mobile Internet Device (MID) Edition or Intel's Mobile Linux project (moblin.org). Each of them are carefully not targeting the mobile phone space but are forward looking to "the mobile internet" using in-vehicle devices and netbooks as their examples. It will be interesting to see how this space evolves as the mobile phone grows up into the space, and the laptop/notebook space shrinks down.

Next we'll look at the opportunity in front of the Symbian Foundation: Nokia and the Symbian Foundation Opportunity - Part II

OSCON 2008: Open Source Software Economics, Standards, and IP in One Lesson

I was fortunate enough to give a talk at OSCON 2008 in Portland. I realized on Tuesday (the day before the talk) that my business tutorial slides that I normally use as a level set when consulting were just NOT going to cut it. Here are the OSCON slides:

Open Source Software Economics, Standards, and IP in One Lesson

view presentation (tags: oscon2008 ip ipr open source)

Developing a Standards Office for Google

I've been thinking about this since I published the Standards Primer a month ago. In the next two to five years, Google will be challenged by a technology standards effort that it will need to encourage or manage in its mission to organize the world’s information and make it universally accessible and useful. Such efforts cannot be erected quickly (as demonstrated most recently by Microsoft), and preparations for that day should begin in the near future. Google is also in a unique position to turn the standards development process on its head.

Here are a number of ideas for how Google can plan for the future in the most flexible and cost effective manner, and contribute a unique and valuable re-think of the standards development process. Well organized, a standards function can be an order of magnitude more effective at growing or defending a company’s business.

A Standards Office for Google

There are a set of strategic questions to be answered by a standards function at Google: What standards should be developed or encouraged to reduce the friction of organizing the world’s information and making it universally accessible and useful, or to open up new areas for growth? Is Android a reference implementation? An open source community? Does it require a standard? Are there micro-format standards that would make indexing web sites, libraries, or health records easier? What standards could others be planning that need to be managed because they threaten Google customer engagements or limit growth? Is a search results standard good or bad for business?

Google has a perceived public culture around serving customers, aggressively innovating, doing no evil, and having fun. These attributes should be celebrated equally loudly in their standards function which for most companies is portrayed as staid, conservative and dull.

As with all business functions, success in the standards function is a matter of organization, preparation and execution. To succeed, you need to:

• Have a strategic planning function that knows how best to recommend using the company assets to develop and respond to standards and standards-like programs and communities.
• Be able to find, organize, and educate potential participants and practitioners within Google quickly as the need arises.
• Be in a position to influence external participants and organizations through successive layers of trust, i.e. you need to be participating and be visible.

The following is the start of some considerations for a standards office at Google:

• Organize the standards office to be a small number of standards strategy staff. This group would have the responsibility for education, evaluation, organization and co-ordination, and forward strategy planning.
• Individual technical staff are generally the first group of people an organization discovers in their own ranks participating in standards. They are the first line of trust and influence. They are in the worst position when it comes to IP risk or reward. Standards practitioners often develop out of the initial group of standards participants. These practitioners are people that have an interest in the success of the standards efforts at a more organizational level and begin to see cross-standards influences.
• Educating participants and practitioners is key to ensure they know how to best get things done, protect the company’s investments, and how to keep others within the company informed of status. The standards office should be responsible for developing and delivering the educational materials.
• Organizing and co-ordinating the efforts of participants and practitioners is important if a company is to get the best return on the investment of having them involved. The initial participants are already building trust in their respective organizations. They are the front line and need to be supported in their roles.
• Google has offices in 27 countries. This is an opportunity to build trust with 27 national member bodies in ISO. Some countries have rules about participation (you need to attend so many of the past meetings to be eligible to vote for example). Some countries are more relevant than others, because they hold particular influence as well. But Google is in a great position to begin here.
• The standards team should be responsible for co-ordination with legal and corporate affairs and the business teams (product marketing and development) for standards-related efforts.
• The standards office should also be responsible for monitoring ongoing activities in the standards development world to watch for particular efforts that should be joined or managed.
• The standards office should develop forward thinking strategy in the standards space. Based on current products and future opportunities, what standards efforts might be undertaken at Google at what cost to best enable customers and users?

The investment need not be great. Google is in a great position to begin. But there are even more interesting ideas in the standards arena and Google is in a unique position to fulfill them.

Turning Standards on their Head

Taking a typical Google viewpoint of what could be done with infinite cycles, storage, and bandwidth when thinking about standards opens up new opportunities in the standards engagement space that come back to Google’s mission to organize the world’s information and make it universally accessible.

Developing interoperability standards is a labour intensive process. A working group meets to debate and discuss the nuts and bolts of the specification, but that act and its attendant work have lots of friction in the system:

• Meetings need to organize and track input documents, minutes, and output documents that pertain to the development of the specification that will become a standard.
• Specification development is often as complex as developing complex software, where a collection of document sources (text, markup+metadata, diagrams, tables), need to come together into a single known identifiable “printable” document that is easily available, indexed and searchable.
• Draft specifications need to be managed and balloted and the votes and comments from the balloting process need to be tallied, tracked and managed against document drafts.
• Interpretations (bug reports) need to be managed against published standards.
• Amendments need to be managed against the history and evolution of the standard specification.
• Many organizations develop software reference implementations for the specification, and the source code needs to be managed as a software project as well as against the specification (and its drafts).
• Some organizations develop test suites for conformance verification and validation against a standard, and again both the software itself needs to be managed, as well as the link to the specifications.

While different standards organizations exist to fulfill different missions, and so have different structures, policies, and practices, this lack of underlying consistency leads to a diverging base of information rather than a converging one. Regardless of the differing policies and practices of the standards development organizations, the friction in the system is common and causes lots of problems.

• Every working group and organization tackles these problems in their own ways, cobbling together the tools and processes that meet the standards development organization’s (SDO) policies and procedures. It is labour intensive, repetitive, and best practices seldom surface across diverse tools and organizations.
• History and knowledge are lost, both in process and content.
• Participation in the process is limited.
• Promulgation of the work can likewise be limited.
• The resulting specifications that become standards are generally not accessible and searchable in a consistent way.
• The quality of the specifications can suffer due to a lack of infrastructure and support.

In the end, regardless of policy and procedure tied to specific SDO, they all need the same basic toolset to support the process. Google has the building blocks in http://code.google.com and “Google Apps for your Domain” to develop http://standards.google.com providing the tool infrastructure and best practices to solve many of the friction problems faced by standards developers.

Regardless of an SDO’s policies and procedures, individual working groups can more easily deliver standards that meet the needs of the SDO and its constituencies in ways that would make the standards more discoverable, accessible, and useable. Using this as the opening olive branch, while developing a strategic standards office would put Google in an excellent position quickly.

Google is in an excellent position to begin their standards strategy function. The effort should be undertaken soon to provide the best most effective platform for success in this strategic area going forward.

A Standards Primer

Photo by Dauvit Alexander

I have recently had several long discussions about the motivations and machinations that surround the development of technology interoperability standards. Over the past few years, I've also captured a lot of ideas and experience on the blog. I pulled it all together into one place in the following paper, "Understanding Technology Standardization Efforts" (PDF 86.2K).

For the record, I was a long term participant in the POSIX and UNIX standardization efforts. I was a working group participant, balloted many pieces of the standards and their amendments, and participated in the management of the standards effort at the IEEE as both an inaugural member of the Project Management Committee and a voting member of the Sponsor Executive Committee. I was an international participant at ISO, as document editor, and participated on behalf of three different national body delegations (Canada, U.S., UK) over a number of years. I began my participation in 1989 as a customer (working for EDS with GM and the U.S. government as their primary POSIX-interested customers), but quickly ended up as a vendor, working for MKS developing a conforming POSIX.2 implementation that formed the basis of implementations from IBM, DEC, HP, UNISYS and Sun. In 1995, I put my money where my mouth was on the importance of applications portability, standards and the coming juggernaut of NT and co-founded Softway Systems, implementing the POSIX and UNIX standards on NT to enable UNIX applications to be directly migrated to the platform. A large amount of free and open source software was incorporated into the product. Softway Systems was acquired by Microsoft in 1999, and I worked there for five years. Over the years I've been in regular contact with people standardizing C#/CLI, the Linux Standards Base, and ODF.

Several friends and colleagues from the standards world have reviewed the paper and provided excellent comments. The paper is much better for it. All mistakes obviously remain my own.

Follow-up on Brad Smith Open Source Business Conference (OSBC) Keynote

It was indeed an interesting keynote. It was not as I had feared it would be. Brad Smith did an excellent job of engaging the audience, explaining the Microsoft position, and encouraging discussion. Smith focused a lot on the diversity in the market of business and licensing models, not claiming a financial high ground (which is a first), and emphasizing shared values (pride of creation of software and what we have collectively accomplished).

The panellists did a fine job, and the audience was also engaged. (It only felt like Smith was filibustering a little in the end, burning the clock, but then he'd had a long time in front of the audience at that point being on the receiving end of the Q&A.) The mini-survey off the previous blog post did correctly predict where most of the discussion was going to be on patents and Linux.

Key points for me:

• "I appreciate that respect for intellectual property is I believe a shared value across our industry." Smith made this statement midway through the panellist Q&A. This to my knowledge is the first public statement by a Microsoft executive that did not label the free and open source community as IP hostile. It is a significant public statement.
• Bottomley and Updegrove did actually catch Smith out in the Q&A. I wouldn't have thought it possible, considering Smith's background as a lawyer and public spokesperson for Microsoft. Smith claims Microsoft wants its property respected, and that patent licensing is not about the relatively small revenue. He was neatly and visibly cornered at one point (to audience chuckles) because the Linux community is willing to respect Microsoft's property and actively work on a solution that avoids it.
• Based on statements made in Sam Ramji's presentation the previous day, and in Brad's keynote and the answers to questions, Microsoft is trying to find solutions to the patent problems. This does not simply mean giving up the property from a Microsoft perspective, as enabling as this might be for the community at large. Smith is all too familiar with other large vendors chasing Microsoft for patent licensing revenues (and he used the Sun US$900M licensing settlement as an example on stage) to be able to understand why Microsoft should just roll over on the patents they allege Linux infringes. For Microsoft it seems it's difficult to take a step that does not appear to be reciprocal in nature.
• There was an interesting discussion about Cathedrals and Bazaars at one point. Smith (Microsoft) is very comfortable having discussions about Cathedrals having licensing discussions with other Cathedrals. But that analogy (historical, relevant, and useful as it has been) also limits their thinking. They seem to only think in terms of Microsoft as a cathedral that can license to other cathedrals. They believe they've enabled the Bazaar in recent licensing statements. It seems they are still trying to understand the actual ecosystem and have been perhaps using the wrong analogy as a lens. Maybe it's time to evolve the Cathedral and the Bazaar.

At one point Smith observed that what the world wants to see is deeds not words — but that words also matter because it sets the bar against which they will be judged. There was lots of interesting things said and debated over the 90 minutes. Smith has set a high very public bar against which Microsoft will be judged. I'm hoping IT Conversations gets this recording up soon so everyone can hear what was said. [My recording is noisy and missing the first few minutes.] Congratulations to Brad Smith, and the panellists (O'Grady, Updegrove, Bottomley, Shuttleworth) for an excellent session, and of course to Matt Asay for pulling it together.

Other commentary:

• Stephen O'Grady commentary
• Matt Asay's direct commentary
• Matt's other commentary