Archive for the ‘the451’ Category

Please break our open source business strategy model

Март 25th, 2010

Last week I presented “From support services to software services – the evolution of open source business strategies” at the OSBC event in San Francisco.

The presentation was effectively a work in progress update on our research into the various strategies employed by technology vendors to generate revenue from open source software.

It included a partial explanation of my theory that those strategies do not exist in isolation, but are steps on an evolutionary process, and also introduced our model for visualizing the core elements of an open source-related business strategy.

I provided a number of examples of how the model could be used to compare the strategies of various open source businesses. Here, for example, is the visualization of MySQL’s strategy.

I was pleased with the response to the presentation, not least the number of people who asked us to send them the slide so they could fill it in for their company and send it back to us.

This is definitely something we would like to do in the future but before we do I would like to ensure we have dealt with any problems related to the model. For now I would be more interested in hearing from companies that feel their strategy is NOT covered by the model.

As Jack Repenning has pointed out, the model does not offer the granularity to express some of the nuances of the various “open complement “ strategies where open source code is not monetized directly but via complementary products (and in my own presentation I had to go beyond the model to discuss “open inside” – building proprietary products on open foundations, and “open edge” – using open source to drive innovation on top of a closed platform).

My initial feeling is that there will always be a level of detail that cannot be expressed in a simplified model such as this, although if I can build them in I will.

The development model category also needs some tinkering, not least to cover “gated community” approaches.

Additionally, of course, the model is not great when it comes to multi-product companies (although multiple models can be used to explain a larger strategy).

So anyway, if you think your company does not fit our model, do please tell us how. To help you understand how the model works, here’s a quick user guide and glossary of terms.

Revenue triggers:
These are the things that paying customers actually pay money for (apart from advertising which is an indirect relationship). They should be pretty self-explanatory. When we refer to “support services” we mean support, training, consulting, implementation services etc. “Software services” refers to SaaS and cloud delivery. Vendors can have multiple revenue triggers for a single product.

Software license:

For the purposes of this exercise we are interested in whether the company has a preference for permissive or reciprocal licensing for the underlying open source project, or uses both.

End user licensing:
What licensing strategy is applied to the product that customers pay for (as opposed to the project that it is based on)? It could be the same open source license (single open source) or a combination of open source licenses (assembled open source). It could be that the same code is available using open source and commercial licenses (dual licensing) or that commercial extensions are available (open core). Alternatively, a vendor may not monetize the open source project itself, but offer complementary software or hardware products (open complement), or may turn the open source code into a fully proprietary product (closed). Pick one.

Development model:

This requires a two-part response. Is the open source code developed in public, in private, or a combination of the two (public/private)? Pick one.
Is the development effort dominated my employees of a vendor, or the result of true community collaboration, or an aggregate of multiple projects? Pick one.

Copyright:
Who owns the copyright for the open source code? Is it the vendor in question, a foundation, a distributed collection of companies/individuals, or another company (withheld)? Normally this would be a matter of picking one of the four options, although if a portion of the copyright is withheld, that could be used along with one of the other three.

Do your worst.


PlanetMySQL Voting: Vote UP / Vote DOWN

Save MySQL would not spare open source M&A

Январь 12th, 2010

A recent pitch from the folks opposing Oracle’s ownership of MySQL via acquisition of Sun Microsystems got me thinking. The plea, ‘Oracle can have Sun, but not MySQL’ may make sense to some, but to me it speaks to the irony of closing out Oracle or any company or anyone from open source. Upon further reflection and given 2010 is off to a roaring pace of M&A, I also began to wonder what the impact of the ‘Save MySQL’ campaign could be on open source in M&A, particularly if it was to successfully derail the acquisition or somehow decouple MySQL from Sun under Oracle?

What would it mean to carve out the open source projects, components, teams and support from companies involved in mergers and acquisitions over the last few years?

Would Citrix have still bought XenSource if Xen were cut out or somehow separated in any way shape or form from the deal? Would it have paid $500m?

Would Nokia have bought Trolltech and Qt for $153m?

More recently, would VMware have purchsed SpringSource for $420m if some or any of SpringSource’s open source projects, developers or holdings — including its own acquisitions Covalent and Hyperic — were not included?

Oh yeah, would we even be here with MySQL owned by Sun Microsystems if Sun were prevented from fully acquiring the project, code and company despite spending $1 billion two years ago?

Some degree of concern about Oracle’s potential ownership of MySQL or any ownership of open source projects and code is certainly warrented and prudent, but I don’t believe the fear that punctuates the message of the ‘Save MySQL’ campaign makes much sense. This is particularly so in light of the past deals listed here and others where the market has required continued investment and support of open source and provided continued revenue and benefits from open source.

While some of these scenarios may be admittedly implausible, I believe that separating out open source components, parts, projects and subsidiaries from vendors could certainly serve to dull the shine of open source software assets and vendors amid M&A valuations, prospects and strategy.


PlanetMySQL Voting: Vote UP / Vote DOWN