Once More unto the Breach

Unshakeable MySQL

Matt Aslett interviewed Mårten Mickos (MySQL CEO) and during the interview, Mårten admitted that Oracle is hinting that they will release "Unbreakable MySQL" and essentially offer support for MySQL more cheaply.  If Oracle is actually considering this, then they still really really don't get it: 

• As bad an idea as "Unbreakable Linux" might be, it is at least a product complement to Oracle's own product.  "Unbreakable MySQL" is a competing product, and not even Oracle's applications business would benefit from a "less expensive database" unless Oracle actually wants to move all its applications to MySQL and completely destroy their Oracle database business.
• The actual MySQL Network offering is much more than mere support, so Oracle would be offering an inferior product, instead of a competing product.  This is not about offering an Oracle-tuned Red Hat Linux.  If I had to choose between Oracle and MySQL, I know which set of engineers I would want supporting my MySQL Cluster high-availability environment. 
• With today's announcement they are even more price competitive than they've ever been.

MySQL actually made two announcements today.  MySQL has recorded their best year ever in their 11 year history:

• They've seen record growth in enterprise subscriptions and incredible marque customers. 
• They've released new technology around high-availability clusters and their pluggable architecture.
• Their community of users continues to grow as strongly, feeding their customer base. 

Zack Urlocker (MySQL VP Marketing) started the week with a post on disruptive business models in general, and followed up today with a post on MySQL's own business model and its inventiveness.  MySQL AB is a company that deeply understands that open source software is an excellent business tool, and how to best apply it.  They understand that the software and its source code are a great customer engagement mechanism, and that the product they sell to solve customer problems is much more than just the database software. 

Congratulations, Mårten, Zack, and the rest of the great team at MySQL AB.  Well done!

There is NOTHING Wrong with the IETF IPR Policy

David Berlind reported that Larry Rosen has sent a letter to the IETF raising concerns  "regarding the formalization of a policy that paves the way for patented technologies to become IETF standards."

We went through this debate two years ago when OASIS revised their IPR policy.  These are GOOD policies.  A salient quote from that two year old post:

The customer of a standards organization is its members. The standards organization is a market oriented discussion forum where like-minded expert and experienced participants come together to agree on a specification that will enable multiple implementations of something.  In a perfect world it expands the overall market for a technology by creating a commodity of one component of that technology market.  This is why there are so many different standards organizations spanning the multifaceted marketplace.  If you're a member of OASIS, then join the discussion, debate the question, and vote.  If you're not a member, you aren't a customer, and you don't actually have a say.  That is the way standards works.

Most of the people that develop standards are vendors.  Consumers want standards because they understand successful standards have multiple implementations, and that will mean competition.  But they typically have little to do with developing the standards because they have neither the technology expertise nor the inclination.  They don't care what the standard is, but they do care that it exists. 

The customers of the actual standard are its implementors, but the key here is that interested implementors participate.  This is no different than the community of interest involved in a free or open source software project. 

The engineers and developers in standards organizations are generally funded by vendors and universities and these organizations are intellectual property owners. 

Larry raises his concerns with RFC3978. The more interesting document is RFC3979 ("Intellectual Property Rights in IETF Technology").  There are a couple of key quotes reflecting the extreme sanity of the group of people that have successfully delivered (and continue to deliver) the standards that enable people to read this post.  The most interesting sections are:

• 4.1  No Determination of Reasonable and Non-discriminatory Terms
• 6.5  What Licensing Information to Detail in a Disclosure
• 8.   Evaluating Alternative Technologies in IETF Working Groups

I've included the full sections below for reference.  These are eminently reasonable rules for the engineers and developers that come together to develop the standards that define our on-line life.  They reflect the reality of the marketplace, and the deep experience this organization has through 20+ years of developing these critical standards.

Standards do not happen in a vacuum.  They happen in processes that are under the microscope to ensure fair play and participation during their development, and to ensure sufficient transparency to prevent vendor collusion.  They happen in a marketplace of vendors competing for customers at a point when the technology has matured and can best be abstracted.   

Some of these participants have intellectual property.  (Some of those same intellectual property holders are free and open source software contributors.)  If you prevent them from participating through onerous rules, then two things happen and neither is good. 

First, you lose critical engineering experience and expertise and the resulting standard (therefore all its implementations) will be poorer for it.  Second, you force them to sit outside waiting for the standard to land such that they can tax it.   Having them in the standards working group negotiating in transparent conversations is a much better situation for everyone involved.

Pax. 

The interesting bits of RFC3979:

4.1.  No Determination of Reasonable and Non-discriminatory Terms

   The IESG will not make any explicit determination that the assurance
   of reasonable and non-discriminatory terms or any other terms for the
   use of an Implementing Technology has been fulfilled in practice.  It
   will instead apply the normal requirements for the advancement of
   Internet Standards.  If the two unrelated implementations of the
   specification that are required to advance from Proposed Standard to
   Draft Standard have been produced by different organizations or
   individuals, or if the "significant implementation and successful
   operational experience" required to advance from Draft Standard to
   Standard has been achieved, the IESG will presume that the terms are
   reasonable and to some degree non-discriminatory.  (See RFC 2026,
   Section 4.1.3.) Note that this also applies to the case where
   multiple implementers have concluded that no licensing is required.
   This presumption may be challenged at any time, including during the
   Last-Call period by sending email to the IESG.

6.5.  What Licensing Information to Detail in a Disclosure

   Since IPR disclosures will be used by IETF working groups during
   their evaluation of alternative technical solutions, it is helpful if
   an IPR disclosure includes information about licensing of the IPR in
   case Implementing Technologies require a license.  Specifically, it
   is helpful to indicate whether, upon approval by the IESG for
   publication as RFCs of the relevant IETF specification(s), all
   persons will be able to obtain the right to implement, use,
   distribute and exercise other rights with respect to an Implementing
   Technology a) under a royalty-free and otherwise reasonable and non-
   discriminatory license, or b) under a license that contains
   reasonable and non-discriminatory terms and conditions, including a
   reasonable royalty or other payment, or c) without the need to obtain
   a license from the IPR holder.

   The inclusion of licensing information in IPR disclosures is not
   mandatory but it is encouraged so that the working groups will have
   as much information as they can during their deliberations.  If the
   inclusion of licensing information in an IPR disclosure would
   significantly delay its submission it is quite reasonable to submit a
   disclosure without licensing information and then submit a new
   disclosure when the licensing information becomes available.

8.  Evaluating Alternative Technologies in IETF Working Groups

   In general, IETF working groups prefer technologies with no known IPR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.

   Over the last few years the IETF has adopted stricter requirements
   for some security technologies.  It has become common to have a
   mandatory-to-implement security technology in IETF technology
   specifications.  This is to ensure that there will be at least one
   common security technology present in all implementations of such a
   specification that can be used in all cases.  This does not limit the
   specification from including other security technologies, the use of
   which could be negotiated between implementations.  An IETF consensus
   has developed that no mandatory-to-implement security technology can
   be specified in an IETF specification unless it has no known IPR
   claims against it or a royalty-free license is available to
   implementers of the specification unless there is a very good reason
   to do so.  This limitation does not extend to other security
   technologies in the same specification if they are not listed as
   mandatory-to-implement.

   It should also be noted that the absence of IPR disclosures is not
   the same thing as the knowledge that there will be no IPR claims in
   the future.  People or organizations not currently involved in the
   IETF or people or organizations that discover IPR they feel to be
   relevant in their patent portfolios can make IPR disclosures at any
   time.

   It should also be noted that the validity and enforceability of any
   IPR may be challenged for legitimate reasons, and the mere existence
   of an IPR disclosure should not automatically be taken to mean that
   the disclosed IPR is valid or enforceable.  Although the IETF can
   make no actual determination of validity, enforceability or
   applicability of any particular IPR claim, it is reasonable that a
   working group will take into account on their own opinions of the
   validity, enforceability or applicability of Intellectual Property
   Rights in their evaluation of alternative technologies. 

 

Repeating History: The OSDL and Free Standards Group Merge

[Update (2007 Jan 25, 20:35):  Stephen O'Grady and I are generally complementary in our thinking, but more aligned.  Here's his excellent analysis. I think I'm showing my age.]

Monday saw the announcement of the creation of the Linux Foundation by merging the Open Source Development Lab (OSDL) with the Free Standards Group (FSG).  Jim Zemlin, the executive director of the FSG is now executive director of the entire organization.  The news link is here.  The interesting thing here is that we are watching history repeat itself in this technology generation. 

In 1984, the BISON group (Bull, ICL, Siemens, Olivetti, Nixdorf) evolved into X/Open. It's purpose was to be a specification and certification organization supporting applications portability around the European UNIX system vendors.  Over time the X/Open Portability Guide (XPG) was born, aligned with the ISO/IEEE POSIX standards, and evolved into the Single UNIX Specification and the UNIX branding program in 1995. 

[The IEEE POSIX work started in 1985, delivered the first standard for applications portability in 1988, and then began forwarding work into ISO for subsequent standardization in 1990 and 1992, and onwards.  Remember the UNIX standardization efforts, lovingly referred to as the "UNIX Wars" were about standardizing the mini-computer away from DEC.]

In 1988, Sun and AT&T began discussions as the Archer Group about an aligned UNIX offering.  (The Archer Group became UNIX International.)  This provoked DEC, IBM, DG, Siemens, Apollo, Nixdorf and HP to form the Open Systems Foundation (OSF).  They quickly adopted their own specification for applications portability on UNIX, which also immediately aligned with the POSIX standards.  [I'm sure rumours that "OSF" stood for "Oppose Sun Forever" weren't true.]

The more interesting aspect of the OSF, however, was their desire to deliver a shared operating system, and OSF/1 was launched.  DEC later used OSF/1 as the core of a future release of Ultrix, and IBM having contributed technology from AIX to help build OSF/1 also back ported parts of the technology into AIX. 

All of the OSF vendors differentiated the platform offerings on things other than the operating system.  It was a perfectly reasonable thing to collaborate and share the engineering costs of the kernel development. 

Eventually UNIX International collapsed, and even Sun joined the OSF.  There was substantial overlap in the membership of the two organizations over time, and some members started acquiring other members.   

So we had two organizations with substantially the same vendor members spending big sponsorship dollars to each organization each year.  One was a specification and branding (certification) organization, and the other was developing a shared operating system kernel. Each organization was a not-for-profit. 

In 1996, the two organizations were re-organized and thrust together to form the Open Group (TOG).  DEC had collapsed by then -- UNIX had won.  It was a more efficient way at that time to manage the costs of complementary programs. 

Each organization was formed for a very specific market purpose.  Over time, the purposes broadened, but eventually the sponsoring members of each came to re-focus the organizations on the core expertise and value proposition they had each started.  Once the market need changed, they were streamlined further into one organization by their respective overlapping members. 

Eventually OSF/1 faded away.  Hardware architectures were evolving and the costs were commoditizing.  PC-based hardware was going "up market" into the server space.  This meant Microsoft was evolving their desktop juggernaut into NT and into the server world. 

Linux was maturing to the point where there really could be a single royalty free kernel.  Every vendor had one, so to speak.  The Linux Standards Base (LSB) was formed in 1999 as a grass roots effort to support -- wait for it -- applications binary portability.  It too centered on the mature standards work that is still maintained as the ISO/IEEE/TOG Single UNIX Specification (with the original ISO POSIX work at its core).  It evolved into the Free Standards Group, with the classic list of vendors sponsoring it, and the certification and branding programs have developed.  During this period the OSDL was created as a hub for the kernel development by the [substantially] same list of vendors. 

I have long teased friends at the OSDL that they are the OSF of this technology generation.  (For the most part, the vendor list hasn't changed all that much at the core.)  And with this week's news we've come full circle.  There is nothing particularly sinister in the overlap histories.  It's just how maturing technology markets evolve and standardize. 

Jim Zemlin will certainly have his work cut out for him, just as Allen Brown did when he moved from managing director of X/Open to COO of TOG.  The specification and branding side of the house is never sexy, but it's incredibly important.  The linux kernel development housed at the OSDL is much better evolved in this technology generation than the OSF/1 experiment or the unwieldy tree of UNIX distros.  The organizational missions align nicely. 

Congratulations, Mr. Zemlin!

Start-up Mechanics: Not Every Idea Works for Everyone ....

I left Optaros in September to co-found a new start-up after some initial planning.  The idea has been steadily evolving over the past few months.  The definition has sharpened, based on some experimentation, and the co-founders and contributors are excited and passionate about it. (It's a very cool idea.)

Unfortunately, it is now something that doesn't fit particularly well with my background or passion.  The co-founders and I discussed this at length going into the Holidays, and we all felt it was best for me to transition out of such a key founding role as CTO.  (I've laughed with friends that only I could design myself out of a CTO role.)  I'll remain an adviser on the Advisory Board.

So with the New Year comes a job hunt.  (I'm even considering consulting again.)
It's all good.

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

I've posted my basic deck on free and open source software economics, standards, and IP.  This is what I use as the starting point for any education I do.  It was last used in Beijing in November, 2006.  A friend kindly translated it into Chinese.  I'm happy to host any other translations people care to provide.  If you send email to me, I'll send you the original .odp file.  All I ask is that you translate directly, and that you claim your work as the translator on the cover slide. As always, distributed under a Creative Commons license.

• Open Source Software, and Standards, and IP in One Lesson (English, PDF 562.5K)
• 开放源代码软件, 标准, 与知识产权 (Chinese, PDF 694.2 K)

开放源代码软件, 标准, 与知识产权

A friend at Sun Microsystems (Dr. Dennis Ding) kindly translated my presentation that I used on a couple of occasions in Beijing last November into Chinese.  Here are the first couple of slides.

内容

• 阐述自由和开放源代码软件（FOSS）、标准和知识产权之间的经济关系
• FOSS在经济学意义上没有任何神秘之处——规则没有改变，但是准则可能有所不同

认识开放源代码软件

• 只是一种软件
• 只是一种经济现象
• 只是一种商业模式
• 只是一种软件许可方式

在开发高质量软件、建立社区、协作或软件许可方面并没有“新”的地方

开放源代码软件, 标准, 与知识产权 (PDF 694.2K)
"Open Source Software, and Standards, and IP in One Lesson" in English (PDF 562.5K)

Conformance and Certification: The ODF Standard and Microsoft's Office Open XML Specification

Excellent posts are appearing over the past 10 days on interesting and apparent contradictions in the Microsoft Office Open XML specification, their related patent promise, and the resulting effects on the ISO standards process.   (All are listed at the end of this post.)

Indeed, ECMA perhaps should be a little embarrassed that they passed the specification in ballot if such contradictions exist, but at 4000+ pages, one perhaps can be a little forgiving.  (Hopefully they evolve their process to adjust in the future for such outrageously large submissions from their members.)

I've pointed out elsewhere:

• Standards exist to enable and encourage multiple implementations, regardless of the forum in which they are created.  They benefit the consumer.  A vendor specification, regardless of whether it has gone through a formal standards process exists to encourage multiple add-ons to a single implementation, i.e. it benefits the vendor.
• Microsoft chose the most expensive worst possible way to deal with the ODF standard, and they will ultimately lose the battle because the standard with the most implementations historically wins in the marketplace. 

That said, huge concern and uncertainty exists for what's going to happen going forward with respect to ISO and Microsoft's ECMA specification, and the future of ODF. 

I'm going to take a slightly different view here.  ECMA has already approved the specification.  One can imagine that the Microsoft marketing and standards engines are in full gear, and Microsoft execs, Office spokespeople, and field account execs are faithfully espousing:

• "Microsoft Office 2007 is standards compliant.  ECMA International is a recognized international standards organization, with participation from IBM, HP, Intel, Adobe, and dozens of other companies."  [Subtext: It must be a good standard for all our partners and competitors to have passed it in a fair-minded international standards process.]
• "Indeed, ECMA International has submitted the standard to ISO for fast track approval as an international standard, and the process will complete in 2007."  [Subtext:  It's so good, that they have recommended it for FAST track at the world's premier standards body.]
  

I would be surprised if Microsoft's Massachusetts team isn't already lobbying to have the new "standard" included in the ITD reference architecture alongside ODF.   Regardless of the merit of ISO accepting the document, however, buyers will be staring the nasty rhetorical beast in the teeth.  So what is a procuring organization to do?

Historically at the federal level in the United States, the National Institute of Standards and Technology (NIST) developed Federal Information Procurement Standards (FIPS). These FIPS contained the description of a standard (perhaps developed elsewhere like ANSI or ISO), and what it would take to use that standard in federal government procurements.  The FIPS would also outline any certification testing requirements that NIST felt were warranted, and indeed for U.S. government procurement NIST [wisely] continued to put its money where its mouth was and developed the test suites that were used.  This was back in the days when the head of NIST was a civil servant instead of a presidential appointment, and the organization thereafter devolved into politics and destroyed many of these "boring" testing programs.

But it was an excellent example of a working model to solve concerns here. 

Standards organizations are best designed to develop specifications into consensus oriented standards.  They serve implementors directly.  They serve the marketplace indirectly by laying the specification foundation for producing lots of implementations. 

It is up to the parts of the marketplace that [economically] care about true conformance to define the certification process that fits the situation.   It could be the procuring side of the marketplace (as with the historical NIST programs), or the implementing side of the marketplace (as with the X/Open-Opengroup certification programs). 

So supporters of ODF (and by this I mean implementors) need to choose the organization that best represents their needs, and deliver a proper certification process.

The ODF Alliance is a likely candidate for at least defining the certification criteria and being the keeper of the certification "brand" so to speak.  Its recognized purpose is to promote the use of the standard, and document its use to support procurement.  Perhaps the Opengroup has a role to play because it has the pre-built infrastructure to support testing and certification on behalf of the ODF Alliance. 

OASIS is excused -- it's the standards development organization.  At best, it defines the conformance criteria for its specification.  Remember, the marketplace needs to take appropriate economic responsibility for certifying that conformance. 

As long as the certifying organization doesn't lose sight of the goal, i.e. as long as it doesn't think certification is a Big Revenue Generator, then the numerous products and online services supporting ODF will be able to quickly demonstrate conformance and certify.  This gives procurement agents their first tool: a recognized brand to specify in their requests for proposals (RFP).  The certification brand becomes an easy short-hand for "that document format standards thing with many implementations."

Microsoft can easily replicate this, and indeed will need so to do to even be perceived to be on a par with the ODF certification world.  It won't matter that there may be truck-sized defects in their rapidly created certification process.  It likewise won't matter if they actually fail to maintain their ability to certify. [They cut the specification into ECMA before they finished the product.  Trust me -- it will have drifted.]  It won't even matter if their certification process is superior!  There will only ever be one implementation that can certify.  It will also be difficult to create the same perceived arms length distance from their certification process that ECMA gave them from the specification.   And it still won't matter. 

Bidders can certainly offer Microsoft Office 2007 plus its conversion tools to meet the ODF certification requirements of the RFP.  But it will have to stand against all the other native solutions for price, performance, and ease of use. 

Likewise, Microsoft or their partners could lobby to get the MOOX "standard" and its needed certification process onto the RFP, BUT the procurement agents now have a second tool.  They have the ability to require that any document format standard on the RFP must support a certification process with at least N certified implementations available at the time of the RFP. 

That will become the industry norm to meet in this space. 

"Standards" with only one implementation aren't.  The buying side of the marketplace has always recognized this and chosen the standard with multiple implementations over the specification with only a single implementation.  The ODF world has the ability to demonstrate this message in a way that meets the needs of customers, and the demonstration through a branded certification is much more powerful than unaligned vendor rhetoric. 

Go get 'em.

Links:

• Andy Updegrove's excellent analysis of the contradictions and their effect on the ISO standards process. 
• Sam Hiser analysis and discussion on the contradictions in the Microsoft patent license. 
• Bob Sutor covers the technical specification contradictions with links to the relevant places.
• Groklaw has indepth coverage to set the context of Microsoft's promises.  It is tempting to take this as simple Microsoft bashing, but the deeper problem this post emphasizes is the problems a vendor faces in the marketplace once trust has been broken.  There are good links throughout. 
• Rob Weir really kicked it all off when he start going deep on the technical contradictions in the Microsoft specification. 

A New Microsoft Open Source Software Strategy: A Bigger Thought Experiment

[Update (17-Jan-2007, 21:22 PDT): Miguel de Icaza reminded me that the mono class libraries are licensed using the MIT X11 license, not the GPL, and that has allowed a lot of proprietary, embedded use that would not have otherwise happened.  Corrected.]

Last week I offered up a thought experiment around Microsoft SQL Server and where it might lead.  It has provoked fascinating discussions in the background, including this translation into Hebrew. 

I thought I'd lay out the "rest" of the Thought Experiment.  Here are other big ways Microsoft could use free and open source software as a business tool. 

Publish Sharepoint as Open Source Software
There are a huge number of content and document management systems in the open source world today.  Standards are beginning to show up.  This means several things:

• The market has reached a point where the tightly integrated product is no longer the best performing (economically speaking), and no longer capturing the integration premium.
• The big expensive systems are now exactly that -- big expensive systems. 
• The market has reached a point where customers expect prices to drop, so are calling for standards.

No amount of innovation will change this market.  Indeed trying to charge an innovation premium for such integrated innovation exacerbates the situation.  "Good enough" solutions that are cheaper open up a world of document/content sharing opportunities to customers that have never been able to enjoy such productivity before now.  So:

1. Publish Microsoft Sharepoint server as open source software.  It's a good document sharing system.  Make it a completely drop dead simple binary package to use.   It runs on Windows.  Recognize that Sharepoint is a complement to both the Windows core revenue stream AND the Office [other] core revenue stream, and both of those products have incredible challenges ahead of them. 
2. Publish it under the GPLv2.  This will cause all the historical closed source companies with product in the space to stay away. 
3. Create the Microsoft Sharepoint Server Network product, similar to the suggested SQL Server Network product.  Again -- experiment with the pricing on the license. 
4. MySQL talks about the fact that their historical conversion rate of customer from users was about 1:1000.  JBoss talked about a conversion rate closer to 3%.  (This is likely due to the difference in technology/customer base, or possibly the history of when JBoss came on stream in relation to MySQL.)  Regardless, you want every department, work group, not-for-profit, school group, hobbyist group, church, synagogue, mosque, etc. dropping down document shares for free.  There are 40 million installed MySQL databases in the world.  Ask yourself why there wouldn't be just as many document shares?  Do the conversion math AND recognize that every large organization IT shop will freak out when they realize the company is running on "unsupported" document shares installed everywhere.
5. Organizations in non-G8 economies now have the opportunity to install a "free" "professionally built" document share.  Let them.  Those economies are all coming on stream and they will have money to pay for the support network offering.  Better for future Microsoft revenue streams that they're learning Sharepoint on Windows than using the alternatives and then having to fight a migration problem in the sales cycle.
6. Someone is going to attempt to port it to Linux.  It may even be easy.  But with the efforts to make Windows servers more manageable for small business finally coming to fruition, ask yourself whether or not Sharepoint on Linux is going to be really a threat (performance, portability, Linux-manageability).  Remember how you run YOUR Sharepoint community is YOUR business. 
7. All previous points about trademark, alternative additional licensing, and hiring still apply.

Remember when Microsoft's slogan was simple and meaningful:  "A PC on every desk and in every Home. "  Home servers are coming on stream.  Recognize that consumers don't want "a home server."  But a riff on "A Document Share in every Work Group and in every Home" might be interesting considering all the photographs, music, and soon-to-be TV shows and movies that will need to be stored.   Start buying shares in disk technology companies again.   

Developers: Part 1 -- Engage with Eclipse
[For Microsoft readers -- please take a deep breath and put DOWN the chainsaw.]
There are several things that need to be considered here.  Not all of them are pretty.

• There are a growing number of users of Eclipse on Windows.  They aren't paying for Visual Studio.  They probably aren't programming in C# against the .NET run-time.
• Visual Studio is just an IDE.  The real technology value in Visual Studio is the core language technology (the compilers and CLR i.e. garbage collection, the JIT, etc.), not the configurable menu options.  How many coloured text editors does the world really need?  (Yes, I expect this to provoke the modern day equivalent of the ubiquitous and inescapable vi versus emacs flame war.  Get over it.)
• There's a reason the WORLD has moved to open source development tools.  All the proven ways of building better software faster involve ALL people on the development team regardless of title/role have access to ALL the tools.  Having expensive per seat tools where only certain people get access to certain tools isn't just false savings, but it's engineering inefficient.  Adequate tools for all beat best-of-breed tools for a few.  Once again, the innovation premium can't be easily sustained any more. 

The goal is to get more developers on C#/.NET and to provide a better solution for the running applications on Windows.  So:

1. Engage with the Eclipse Foundation.  Put the Visual Studio IDE in maintenance mode.  Contribute some of the IDE bits that are "better" than some of the Eclipse bits as the olive branch. 
2. Resurrect the Shared Source CLI (aka Rotor).  It is a simplified working C# environment for Windows (and historically Mac OS X and FreeBSD).  Integrate into Eclipse.
3. Release the interesting Visual Studio and Rotor 2.0 bits under the Eclipse Public License.  This license does NOT mix with the GPL under which the Mono project is distributed.  (The mono class libraries are released under the MIT X11 license.)
   
4. Maintain the core C#/CLR technology and all Windows extended class libraries as the value add licensed package.  Indeed, the agreements with Intel and AMD may prevent some of this technology ever being published in source code form because it is so close to the hardware.  Use that to your advantage. 
5. Re-purpose the academic/training materials (of which there is an abundance) to capture C# developer mind share. 
6. Re-purpose (initially) the engineering resources that will free up to developing all the OTHER necessary classes that the Java world have that enable so many applications to be created in the Java world.  Many Java programmers in the enterprise will admit that they like C# better, but are clear that they can work faster in Java because all the classes and frameworks already exist in the problem domain in which they're working, i.e., while C# may be actually faster in which to develop code, application development is faster in Java.  Recognize this is because IBM and Sun won their ISV population by giving them the resources to rewrite/migrate the historical C++ class libraries to Java.  You will need to do the same to gain C# acceptance. 

This is the first part of the developer program.  It's about winning C# programmers already on the platform, and about engineering efficiency at several levels.  Now for the next step. 

Developers: Part 2 -- Engage with Mono
You have just explained to the world that you're in a IP cross license with Novell.  Let's make it real in a way customers in the enterprise can understand.  Again, recognize a number of things:

• LAMP continues to gain ground.  So what you didn't lose to Java because of the perception of Java as a multi-platform environment, you ARE losing now to LAMP.  Customers want at least a belief in multi-platform programming environments even when they choose just one platform.  LAMP is also code for Ruby on Rails for the purposes of this discussion.  AJAX is NOT interesting when the first canonical example in every book is how to tell the difference between IE and every other browser on the planet. 
• Maintaining a PR strategy around Mono as a "science experiment" anchors the belief in customers' minds that if they're going to hedge their bets for the future, they had better choose Java for "heavy lifting" and LAMP otherwise.  You are currently drinking your own bath water. 

So again in the spirit of engaging with developers (i.e. customers developing platform complement value) to solve problems better in a C#/.NET world (and here .NET means Windows by definition):

1. Engage with the Mono community.  Offer the (Rotor) ECMA Base Class library code as an olive branch so there is one true library source base.  Do it on the following condition: that the Mono community has to maintain a rigorous rights assignment process similar to the Free Software Foundation process, such that you can still take back the code and know from whence it came. 
2. License the (Rotor) ECMA Base Class library code under the GPLv2 MIT X11 so it is compatible with the rest of the Mono Base Class Library.  This does NOT contradict the above licensing using the Eclipse Public License.  It's Microsoft property.  You can license it as many ways to as many people as many times as you like.  So just like the Perl/PHP/Python community, license this particular bit under both licenses. 
3. Contribute some amount of work to improving Mono on UNIX/Linux.  This is NOT anathema.  While Mono runs on Windows, you really want the ultimate Windows C#/CLI experience to be .NET.  But you need enterprise customers to understand that Mono is real. 
4. The web world is defined by a set of publicly developed publicly available standard network protocols.  Microsoft implements them (mostly).  For the underlying web service world that is just now coming on stream in SOA, there is likely still head room in the market where the tightly integrated solution outperforms the componentized solutions.  On Windows, the combination of .NET CLR+IIS may still offer a much better solution (technologically AND financially) to hosted web services than your competitors.

Franchise Windows into China
[For Microsoft readers -- please stop hyperventilating and rolling your eyes and think about this in real economic terms.]
This one is actually a little subtle.  It doesn't look like an open source play.  But it addresses a different aspect of the "competitive problem" with open source from the Microsoft perspective.  There are a couple of things to consider:

• Linux adoption is an easy decision as an interesting platform base for development in a developing economy.  It's free as in speech and free as in beer.  This means one isn't shipping hard capital out of a small company, and hard currency out of the local economy for the privilege of working on Windows.  It doesn't matter if Windows is "better".  It's an finance/economics problem, not a technology/innovation problem.  (That means it needs a financial solution.)
• The magnitude of the Chinese economy both in scope and in advancement make shipping that much hard currency out of the economy a non-starter.  It's a macro economic problem as well as a micro economic problem.  Most G8 marketeers see the scope and think they just need to localize the product and its advertising, because obviously their technology will be valued the same in China.  The middle class culture and business culture developing in China is NOT the same as their equivalents in a G8 country.  You can't assume the economics is the same. 
  

As a platform on which to innovate, (and I said that carefully,) Linux wins every time in China.  Microsoft needs to disrupt the economic problem it has created for itself.  There is no fine tuning here.  So:

1. Franchise Windows into China.
2. Structure the license to protect the Windows brand and the Windows app compatibility programs and brands.
3. Invest in a joint venture primarily owned in China.  Create it as a secondary Microsoft stock class.  (I do NOT actually know what I'm talking about here.  Better stock specialists than I can probably describe the real steps to accomplishing this here).  The intent is to create a class of Microsoft stock that is highly attractive to existing shareholders/investors, and also leaves substantial capital in the Chinese economy.  This will get the Chinese government on board.  This will give investors/shareholders choices in what mix of Microsoft stock to own. 
   
4. Structure the license with respect to regions/localization over a set of milestones and dates to not savage the Windows revenue stream too quickly when China starts exporting technology.
5. Get out of the way and let the Dragon go. The technology graduate rate is phenomenal.  They are open source friendly.  Ensure they're C#/.NET programmers that understand your platform. 
   

This of course presumes Microsoft is developing the "next" operating system.  They have a demonstrated ability to develop ubiquitous platform technology that is well tested, packaged, supported and maintained across an enormous breadth of hardware platforms.  This is actually where they shine when it comes to shear scope of software engineering delivery. 

Forget the Home Media Server as a "Windows" machine.  You've had a simpler home server in the living room for 5 years now, which is already zero administration with an arguably elegant design.  It just needed a wireless loop and a bigger disk.  Indeed, I've never seen a pop-up in the middle of an XBox game telling me I needed the latest security update, which apparently plagues Media Center Edition owners that spent more money for a "bigger PC" in their living room.  It doesn't matter how elegant the new "home server" looks -- that pop-up event is a deal breaker for a consumer. 

If Gates is serious about the coming robotics wave, then use all that pent-up R&D intellect and go build the next great embeddable platform.  Ensure it's wildly friendly to C#/CLR programmers.  By then you may even have the depth and breadth of open source software experience to involve the community. 

Conclusions
These are big programs with potentially big impact on Microsoft.  There are all manner of other programs that could be started, from Kim Cameron's work, to improving Microsoft Exchange firewall capabilities by integrating with many of the best of breed open source solutions out there.   There is an incredibly rich portfolio of software assets inside Microsoft, that will NEVER be released as multi-billion dollar revenue streams, that could be used to engage Microsoft customers and developers in open source communities.

Re-invention is necessary.  IBM did it.  Sun is doing it.  No point waiting until you hurt as badly as they did to begin. 

The cultural upheaval would be enormous, and require enormous training and education across engineering and marketing.  The PR and customer coup would also require enormous work to ensure the executive could explain it in simple sound bites to keep investors from panicking.  That would also require [consistent and coherent] executive sponsorship at the highest levels.  In the end it's just a thought experiment. But as I said last week, it's a GREAT thought experiment. 

Run wild; run free. 

Microsoft and MySQL: A Thought Experiment

[Update (18-Jan-2007, 15:47 PDT): This article was translated into Hebrew.  I also continue the thought experiment here.]

I was interviewed by Scott Mace for Open Source Conversations on Monday morning.  In one part of the conversation, I created a thought experiment on some of the more creative things Microsoft could be doing with open source software to customer and business benefit.  This idea is way outside the box, but then that's exactly where they need to be at this point in history.  (As I said earlier: culture comes from the top, and if you expect your employees to get outside the box then you need to be their first.) 

I thought I would explain the experiment more carefully here, as I sometimes get going in conversation and I have no idea how coherent it may come across "live".  I can also better fill in some of the details.

Microsoft needs to start to explore open source software business processes better than the minor experiments they have done to date.  Steve Ballmer also wants to license the company's intellectual property.  So here's a way to do that using free software as the hook. 

1. Start by releasing the source code for SQL Server.  This is an opportunity to use an important but not critical product revenue stream.  [Yes, I do understand the revenue growth SQL Server 2005 represented — Microsoft readers need to keep reading and stop the knee jerk response.] 
2. Repackage the present product licensing into a subscription for SQL Server Network^TM, similar to the subscription-based support, maintenance, tuning offerings from Red Hat Network and MySQL Network. 
3. The key understanding here is that today the value of SQL Server to the customer ISN'T the source code, but rather the solution it provides. The value Microsoft provides isn't the source code, but all the testing, packaging, support and maintenance.  You don't NEED to drop the price of SQL Server Network below the existing price for the shrink wrap binaries.  Experiment.  Explore the conversation with key customers. 
   
4. Use the GPLv2 as the license.  GPLv3 is unproven (although I have confidence it will be great if still a bit controversial when it's delivered).  This is business conservative.  You can bet IBM DB2 engineers and Oracle engineers won't be looking at the code any time soon for [stark-raving shrieking] fear of product taint.
5. Construct a patent grant that allows any patents in the space to be used royalty free for database related work released under the GPLv2.  This enables the software to flow within the database community under the GPL appropriately.  The GPL actually becomes the brake on the technology slipping outside of the database arena.  Microsoft is still able to license this technology anyway it chooses in other arenas, or to people trying to "close" the source. 
6. Someone in a developing economy is going to promise Blue Hat SQL Server the next day.  There are several responses to this.  First, if you were betting your business data on SQL Server, would you buy support from Blue Hat or Microsoft — the people that actually develop and test it?  Second, understand that MySQL AB (the company) doesn't seem to be worried to much about "clones" — ask yourself why.  Third, Microsoft still controls the trademark.  Fourth, understand that the developing economy wasn't interested in shipping a lot of hard currency out of the economy for the privilege of using SQL Server anyway.  They were going to use Postgres or MySQL.  At least you're back in the game here, preparing for a future developed economy. 
7. It's an awesome way to find new SQL Server developers.  You will see changes and bug fixes.  Yes, the ratios of brilliance to cruft involve orders of magnitude, but there is no time-line for when good things arrive.  We've seen brilliance arrive in the first 24 hours on other projects.  This is a much better way to find future talent than interviewing.  It's certainly how MySQL has grown its development team. Managing the inbound contribution flow is easier than you think legally. 

Now this is where it gets interesting.  At some point, in the next 24 months, someone is going to try a "mashup" of MySQL and SQL Server.  There will be some SQL Server algorithm or function that's just plain too interesting to NOT try to use in MySQL.  Depending upon what it is, MySQL has a pluggable architecture that encourages such experimentation.   A large part of the MySQL install base lives on Windows. 

The licenses for such an experiment are compatible. 

But MySQL has an interesting portion of its business that depends upon its ability to license MySQL using something other than the GPL.  For this DB mashup to be anything other than an interesting unsupported experiment, MySQL would need to be able to license that code from Microsoft. 

MySQL has an excellent history and track record of licensing technology.  This situation would be no different.  If anything, it's Microsoft that would be under the gun to demonstrate it has the ability to boldly license where it has never licensed before now.  But intellectual property licensing it is, and it's enabled by free and open source software.

Of course, the reverse could also happen.  And Microsoft too licenses in all manner of intellectual property.  Again, the mashup is highly uninteresting unless Microsoft had sufficient rights to the MySQL bits to package as a product.  Makes you think.  There are lots of opportunities here.  It's good for customers.  It's good for shareholders. 

Based on current open source culture at Microsoft, I see at least six show stoppers in the seven items listed above.  That's why it's just a thought experiment.  But you have to admit, it's a great thought experiment. 

Optaros Publishes its Open Source Catalogue

[Update 23 July, 2007: Optaros has relaunched the catalog as an online resource.]

Optaros has published its first Open Source Catalogue.  It includes 262 projects and was developed over the past year as the developer/consultants installed and used the components for clients and their own work internally.  They have made best efforts to rate them according to functionality (in an enterprise context), maturity, available support, community vibrancy, and "enterprise readiness". 

This of course sparked a certain amount of immediate controversy as some felt their project got short shrift, but as is stated in the catagolue:

While Optaros took great care in consolidating this catalogue and applied multiple cycles of feedback and quality assurance, it is still possible that some information is presented in an incomplete or even inaccurate way.  Also different people might have different opinions or different experiences. 

Optaros is open and ready to accept feedback and additional input for improvements.  For this an email address is provided: OSS-Catalogue@optaros.com. Please use this email for sending us your feedback and ideas.

It's a great first effort to try to provide a starting point for enterprise IT people to learn about free and open source software, with lots of educational material in the front.  It will be interesting to track this document over time.  It (as all Optaros white papers and reports) is published under a Creative Commons Attribution 2.5 license.   

Disclaimer: I worked for Optaros from Feb 2005 through Sept 2006 as vice-president, open source development strategy.