Entries Tagged 'Business strategies' ↓

Back to the future of commercial open source

It’s been tempting to write a post about open source licensing trends and how they relate to commercial business strategies, given ongoing interest in our previous posts about the relative decline of the GPL.

Every time I start to write a post though I realise that I’d just be repeating myself, most notably The future of commercial open source business strategies from December 2011, but also Control and Community – and the future of commercial open source strategies from late 2010.

You can trace the origins of the theories and research in those posts back to The golden age of open source? in August 2010, and even further to Commercial open source business strategies in 2009 and beyond from early 2009.

That post in particular contains the core elements about why we believed we were at a tipping point with regards to commercial open source strategies, prompting the shift from vendor-led strategies that emphasised control via copyleft licenses, to community-led strategies that emphasised collaboration via permissive licenses.

The one aspect that those posts didn’t cover is what happens after this shift. That is a question that has recently been addressed by Simon Phipps, who predicts that the pendulum will swing to the centre and weak-copyleft licenses and specifically the recently released MPLv2.

While I don’t dispute the logic of that prediction, I can see nothing in the data that we have previously collected and analysed that indicates a shift to weak-copyleft. As you can see, while there was a strong shift from vendors towards non-copyleft licenses from 2007 onwards, we have seen no such shift with regards to weak-copyleft.

Which is not to say that it won’t happen – just that we see no evidence of it right now, and that we would have to see an enormous swing towards weak-copyleft licenses in the next couple of years. It will be interesting to see whether the release of MPLv2 will be the event that triggers that swing.

The future of commercial open source business strategies

The reason we are confident that the comparative decline in the use of the GNU GPL family of licenses and the increasing significance of complementary vendors in relation to funding for open source software-related vendors will continue is due to the analysis of our database of more than 400 open source software-related vendors, past and present.

We previously used the database to analyze the engagement of vendors with open source projects for our Control and Community report, plotting the strategies used by the vendors against the year in which they first began to engage with open source projects to get an approximate view of open source-related strategy changes over time.

For example, we found that the engagement of vendors with projects that used strong copyleft licenses peaked in 2006, while the engagement of vendors with projects using non-copyleft licenses had been rising steadily since 2002.

Analysis of our updated database shows that the the number of new vendors engaging with open source projects in each year has risen steadily in recent years, from 26 in 2008 to 44 in 2011. However, as noted last week, we have also seen a shift towards ‘complementary vendors’ – those that are dependent on open source software to build their products and services, even though those products and services may not themselves be open source.

2010 was the first year in which we saw more complementary vendors engage with open source projects than open source specialist, and that trend accelerated in 2011.

As previously explained, complementary vendors were responsible for over 30% of open source software-related funding raised in 2011, and we should expect that proportion to remain high given that over 57% of the vendors engaging with open source in 2011 were complementary vendors.

We have also seen that complementary vendors are more likely to engage with projects with non-copyleft licenses (38% of complementary vendors have engaged with projects with non-copyleft licenses, compared to 24% that have engaged with projects with strong copyleft licenses).

If we look at all 400+ vendors in our database in terms of open source software license preference, the trend towards new vendors engaging with non-copyleft licenses is clear.

There has been a strong shift from vendors towards non-copyleft licenses in recent years, accelerated in 2011 by the likes of Apache Hadoop and OpenStack in particular. This does not mean that the number of projects using strong copyleft licensing has decreased (although as we previously saw the proportion of projects using the GPL family of licenses has declined).

It is indicative, we believe, of the shift away from specialist open source vendors using vendor-led projects and strong copyleft licenses towards multi-vendor collaborative projects and proprietary implementations of open source code, however.

This trend should not really surprise anyone. For some time we have seen open source becoming part of the fabric of modern software development and licensing strategies, rather than a competitive differentiator. Back in 2009 we predicted the increased importance of business strategies that relied on vendor-led development communities, rather than projects dominated by a single vendor.

We called this “open source 4.0” and later suggested that it might be considered the golden age of open source, based on our belief that vendors had learned that they stand to gain more from collaborating on open source projects and differentiating at another stage in the software stack than they do from attempting to control open source projects.

Updating the results of our analysis to the end of 2011 and 400+ vendors indicates that, from the perspective of the commercial adoption of open source business strategies at least, we were not far off.

Some might not consider the proliferation of multi-vendor open source communities and proprietary distributions of open source software as the peak of achievement for open source. Each is of course entitled to come to their own conclusions about the implications.

Our perspective, as always, is that open source methodologies present a potentially disruptive, and also valuable, asset that complements the way both vendors and enterprise IT organizations conduct their businesses.

Our analysis indicates, however, that open source methodologies are increasingly being employed by ‘complementary vendors’ with a leaning towards more permissive licensing.

VC funding for open source – existential question time

I tweeted last week that VC funding for open source related vendors was up 95% in Q3, driving by significant investment in ‘big data’ related vendors.

In calculating that percentage I had overlooked an important deal, however: one that re-writes the record books and raises existential questions about investment in ‘open source related vendors’.

There has always been a question mark over the term ‘open source vendor’. That is why I started using the term ‘open source-related vendors’ as more accurate term to describe the collective group of vendors that we see depending on open source software to drive revenue.

In particular, ‘open source-related vendors’ reflects the fact that many vendors are dependent on open source software to build their products and services, even though those products and services may not themselves be open source.

One such vendor is Opera Solutions, http://operasolutions.com/ which has based its data analytics platform on a number of open source components including Talend,. Kettle, memcached and Apache Hadoop. Opera’s software is not itself open source, however, which led by to initially omit the company’s series A funding round from my calculations for Q3.

How significant an omission was this? Pretty significant, given that Opera raised no less than $84m. Include that deal, and funding for open source-related vendors increased not by 95% to $159.2m, but by 197% to $243.2m, which is the largest single quarter for funding for open source-related vendors ever.

We have previously included funding rounds for vendors that depend on open source software despite producing closed software – Karmasphere, which raised $6m in Q3 is another – but it is the size of Opera’s funding round that highlights the existential problem in defining a vendor as ‘open source related’.

Whereas it was previously pretty easy to identify open source-related vendors, as we see more and more closed source vendors and service providers building on open source foundations, it becomes increasingly clear that the bounds of ‘open source-related’ are almost limitless.

It is not so much a matter of when do you start counting, but when do you stop.

Vendor-led community projects? Don’t forget your hat

Brian Proffitt asked an interesting question last week with regards to the OpenStack project: ‘can a commercial vendor lead a project as openly as a foundation?’

It’s an interesting question, and one that is particularly prescient given the observed re-balancing of control and community.

In fact. we’ve previously cited OpenStack as an example of this shift towards community, given that it was designed to be more open than the alternative and the organisations behind it specifically chose distributed copyright ownership and a non-copyleft license, as well as a promise of openness in order to shift the balance away from vendor control towards community.

The project has not been without its controversial moments, but we have been bullish about the project’s success given that Rackspace does not plan any commercial licensing or products to generate revenue from OpenStack (although it is offering services and support for OpenStack via Rackspace Cloud Builders).

Additionally, while the common perception of vendor-led projects would suggest that there is a disjoint between vendor-control and collaborative development, there are clear examples of community projects led by a single commercial interest.

One of the primary examples of this is the Fedora Project, sponsored by Red Hat but maintained and driven by the community. While the Fedora Project has not been without tension, I think most people would agree that by and large it has successfully balanced control and community.

Fedora is also an interesting example given Brian’s question about whether a foundation is required to protect the independence of an open source project.

Red Hat announced in 2005 that it was to set up an independent Fedora Foundation, only to change its mind less than a year later.

One of the reasons behind the change of heart had to do with the complexity of setting up an independent 501(c)3 nonprofit organization – in particular the need to raise one third of its funding from public sources within four years.

Given the resources Red Hat commits to the project it was thought to be impractical that one third of Red Hat’s commitment could be raised from the public. For example, it was estimated that the Fedora Foundation would need to raise $750k a year to cover bandwidth costs alone.

This highlights something important about open source foundations: it is a lot easier to demand one than it is to set one up, whatever the theoretical advantages might be.

Going Open, Going Closed: best practices and lessons learned

The 451 Group’s CAOS practice last week published its latest long format report: Going Open, Going Closed.

The report is the latest in a series from the 451 CAOS practice examining the impact of open source on business strategies. As previously indicated, it takes a look at a number of vendors that have successfully ‘gone open’, including WANdisco, JetBrains, SAP, Intuit, and VMware.

It also tracks the progress (or lack thereof) of the vendors profiled in our 2007 Going Open report, including Covalent, Hyperic, Ingres, Intalio, Jaspersoft, Laszlo Systems, Openclovis and Qlusters.

Finally, it also takes a look at vendors that have walked away from, or at least decreased their engagement with, open source licensing and development projects, investigating the reasons why they failed to gain the expected benefits from open source – or open source failed to meet their requirements.

The vendors that fall under this category include Calpont, GroundWork, KnowledgeTree, Symbian and SnapLogic. To be clear with regard to the report’s title , we would consider all of the following vendors to still be ‘open’ to some degree. As the report explains, however, they are not as open as, perhaps, they once were.

The report also includes more in-depth analysis of themes discussed in recent blog posts, such as the decline of ‘open source’ as an identifying differentiator, and the commercial open source window of opportunity, as well as a list of the best practices for software vendors considering an open source move and the lessons learned from those vendors that have had less successful engagements with open source licensing.

Our key findings:

  • The trend of closed source companies adopting open source software licensing and development methods has continued apace since our previous report.
  • Contrary to our initial expectations, however, there have been relatively few business-model shifts in the years following the publication of that report.
  • At the same time, there has been an explosion in the amount of M&A activity involving open-source-related vendors.
  • There is also a small but growing list of vendors that have backed away from open source licensing and development strategies, opting instead for ‘shared source,’ ‘freemium’ or SaaS-based approaches.
  • The fact that closed source vendors are not dependent on directly monetizing open source software gives them the freedom to relax control and encourage community through more permissive strategies.
  • Going open is not an either/or option for most companies, but a matter of applying the benefits of open source to their advantage while retaining an established closed source business, where appropriate.
  • While early approaches to going open were based on new vendors exploiting licensing to disrupt the existing market, we have also seen the emergence of approaches that involve incumbent vendors maintaining the status quo and avoiding disruption.
  • Shifting an entire business model to take advantage of open source licensing and development is a difficult process that is not to be taken lightly.
  • By comparison, it is easier for existing vendors to acquire vendor-led open source projects, engage with an existing foundation, or encourage open source development that complements their closed source software.
  • Open source is not a panacea. This is true of closed source vendors trying to reinvigorate a distressed product, but also of specialist vendors building a business around an open source project.
  • Strategies for ‘going open’ have become more nuanced as both closed source vendors and open source specialists have come to better understand the benefits and limitations of open source.

The overall conclusion is that ‘going open’ is a complicated and difficult process that requires concerted effort and an understanding of best practices, as well as the lessons learned from companies ‘going closed.’ Overall, the report presents an impartial overview of the strengths and weaknesses of open source strategies, the successes to replicate and the mistakes to avoid.

Eclipse illustrates open source development diversity

One of the common myths about open source software is that it is developed by communities of individuals. It is a myth that continues to propagate despite multiple sources of data that show the depth and breadth of corporate contributions to open source software.

Communities come in many shapes and sizes, however, and corporate-dominated projects don’t necessarily mean a lack of community or collaborative development.

As we have highlighted on numerous occasions, we are seeing growing focus on corporate-led open source communities. A prime example would be the Eclipse Foundation, which is clearly dominated by corporate interests but encourages a community effort to work together to with a joint purpose – to deliver the Indigo release for example.

Dig a little deeper and it becomes clear that Eclipse is not so much a community but a set of set of projects with their own communities, however.

Forrester’s Jeffrey Hammond once described Eclipse as neither a Cathedral nor a Bazaar, but a Mall, in which each project is the equivalent of an individual store, with its own needs and commercial drivers, but with a shared infrastructure and common purpose.

This is an excellent analogy (which is why I have borrowed it) and is important in understanding the nature of corporate-led open source development. While we often think of Eclipse as being a collaborative community process at the mall level it is also important to look at the individual projects to understand the level of collaboration and community at the store level.

Thanks to a new set of Eclipse project landing pages designed by Wayne Beaton it is now a lot easier to visualize the nature of each project. Using the project metadata and Google Charts APIs Wayne has been able to generate charts showing the level of company activity in individual projects for the last three months.

The results provide an indication of the level of collaboration in each project, and show that the projects differ considerably. To illustrate, below is a chart I have created from this data highlighting the vendors contributing to 22 Eclipse projects.

The sample is fairly random – it’s the first 22 projects and sub-projects from the alphabetical listing on the old Eclipse project page for which data was available. They are listed below in order of the number of active contributors, from 23 (e4) to 1 (Jetty downward).

The chart illustrates that the Eclipse Foundation includes both collaborative projects and those that are dominated by a single participant.

The dominant colour (not surprisingly) is blue, representing IBM, while Actuate (red) is also well represented. As can be seen by the amount of dark green, however, individuals are prominent in many Eclipse projects as well – dominating the Eclipse Communications Framework and GMT projects for example.

What this chart really illustrates, therefore, is the way in which the Eclipse Foundation is a microcosm of the wider open source ecosystem, comprising a blend of vendor-dominated projects, vendor-led collaborative communities, and communities of individual developers.

It would be fascinating to get similar data for other open source foundations – the Apache Software Foundation projects, for example.

Further thoughts on the decline of ‘open source’ as a competitive differentiator

This week’s post on the decreased use of the term ‘open source’ as an identifying differentiator in some companies’ marketing material generated a lot of attention and comment, with numerous industry watchers pitching in their perspectives on the reasons for the decline.

If you haven’t read the original post it might be worth doing so for context before continuing with this post.

Various explanations were offered, any and all of which I agree are partly responsible for the observed decline in our sample. Here’s a selection:

* These vendors are trying to drive the focus of potential users to the commercial version.

* It is happening because companies are focusing on functional value rather than licensing.

* For come companies open source is just a means to an end, while for others it is part of their DNA.

* The proliferation of open source software means that open source licensing is no longer a differentiator.

* Open source is not a business model, and never has been. It remains a differentiating development model.

* These companies are increasingly targeting business decision makers, rather than developers/users, and open source does not resonate as well with that audience.

* Open source remains a differentiator if a product is functionally competitive, but will not overcome a lack of functionality.

* The increased acceptance of open source means these vendors are in a better position to focus on other competitive differentiators.

* The vendors now have ambitions beyond “just” being the leading open source player in their sector.

* Some of these vendors are effectively admitting that their primary products are not aligned with open source/software freedom.

* Some of these companies were never truly open source companies in the first place. They tried to re-brand ‘open source’ and they failed.

While I agree with all of these to some extent, I also believe that the focus on the vendors in my admittedly small and unscientific sample has distracted attention away from the wider trend.

For instance, if we accept that the nine vendors changing their use of ‘open source’ did so because they in particular have matured/learned from experience/failed then we would expect most of the more recent market entrants to be going through the same learning curve/repeating the same mistake.

Let’s take a look at another small and unscientific sample of more recent commercial open source-related vendors (which means we are now dealing with a slightly larger unscientific sample)#:

While all of the vendors in our previous sample had, at some point used ‘open source’ as an identifying differentiator, only eight of this more recent sample have ever done so, and three of those quickly stopped doing so.

This suggests that the trend is not specific to the experiences of the companies in our first sample, but has more to do with the wider industry perception of open source as a competitive differentiator and the changing business strategies around open source software.

Macneil Shonle put it very nicely with his comment that “OSS was once “hot” and appeared to be taking over the world. Companies joined the bandwagon. Cooler heads prevail now.”

This is fundamentally what I have been saying since early 2009, such as this post, which included the first ever mention of Open Source 4.0 and this graphic illustration of the four ages of open source-related business strategies:

The concept of Open Source 4.0 was picked up again late last year in the run up to our Control and Community report, which included an update to the language used to describe the four ages, as well as the opportunity to group the 300 vendors assessed in that report into three groups representing the three vendor-related ages.

Updating the graphic above to include the new language and remove Open Source 1.0 – Traditional Open Source, developed by communities of individuals – we get the following:

Which explains, in theory, why we might be seeing a decline in ‘open source’ as a competitive differentiator: the growth of vendor-dominated open source projects has slowed while the growth of multi-vendor open source and proprietary distributors is accelerating. We have moved beyond the era of the ‘open source vendor’.

That’s the theory anyway. Having recently updated the results of our analysis to the end of 2010 and 321 vendors, we can also see what is happening in practice:

So I wasn’t far off…

#Of course there is still an inherent bias in our sample. The only way to avoid that would be to look at all 320+ companies we cover but – believe it or not – I have better things to do.

The decline of ‘open source’ as an identifying differentiator

I’ve been examining the trend of open source-related vendors disengaging from open source development and licensing as part of my research for the next CAOS research report.

One of the things that I have observed in relation to open source-related business strategies in recent months is the decreased use of the term ‘open source’ as an identifying differentiator in some companies’ marketing material, either to describe the company or its software.

The way in which a company identifies itself in the opening lines of a press release may not necessarily describe accurately what the company does, but it is a clear indicator of how the company wants to be perceived.

It seemed to me that a significant number of high profile open source-related vendors had stopped using the term open source as an identifying differentiator.

The list below represents a small and unscientific sample, but these are among the highest profile open source-related vendors, so the fact that half of them have dropped ‘open source’ as an identifying differentiator in the last 12 months (and another two long before that) is not insignificant.

Whether it is because open source has become so in-grained in the industry that it is no longer a primary differentiator or because the vendor in question has become less focused on open source is another question, however.

Certainly Jaspersoft remains committed to an open source strategy despite discarding its ‘open source’ identifier as long ago as 2008, while Cloudera has never used the term in its description as far as I am aware but is clearly committed to an open source-related strategy – it chooses instead to focus on its relationship with Apache Hadoop.

Another vendor worth assessing in greater detail is SugarCRM. The company has increased the number and nature of closed source editions of its customer relationship management software in recent years, and dropped its use of open source as an identifying differentiator in November 2010.

However, the company continues to see the SugarCRM community edition as a significant differentiator in the market, enabling it to reach an estimated 800,000 end users and punch above its weight in terms of profile.

While the company’s commercial focus is on the various closed source editions, many of its channel partners, which deliver the vast majority of SugarCRM’s revenue, have based their offerings around Community Edition, and SugarCRM has taken steps to encourage greater community engagement with the open source version, moving it from an internal forge to GitHub twelve months ago.

Just because a company no longer uses the term ‘open source’ as an identifier does not necessarily indicate that the company is moving away from open source. However, the fact that so many of these vendors have dropped the term open source from their descriptions does indicate that open source is decreasingly seen as a differentiator and a term that vendors choose to identify themselves with.

Another indicator of decreased emphasis on open source is a delay in updating the open source code base. The table below therefore includes details on both the date of the last open source update (according to the relevant forge data) and the date of the last use of open source as a differentiating identifier.

Two of the companies below will be profiled in detail in our forthcoming report, which examines in much greater detail the relationship between vendors and open source licensing and development, as examples of companies that have decreased their engagement with open source as their business strategies have matured.

You can probably guess which two…

If you tolerate this… the commercial open source window of opportunity

One of the ‘things I wrote down during OSBC’ was this statement from Benchmark EIR, Rob Bearden:

“Misalignment between a business model and the community’s tolerance point will never be accepted. This will manifest itself in multiple distributions.”

At first glance the statement may seem obvious to anyone who has studied open source-related business strategies or communities, but I believe provides the context for further understanding the complexities of balancing the needs of a business for control and the needs of a community for openness.

As the following graphic demonstrates, the statement suggests that there is a window of opportunity within which the control point of the vendor, and the tolerance point of the community must be closely aligned:

Any relationship between the company’s business model and the community’s tolerance level that falls outside that window is going to result in problems.

Most obviously, if the business seeks to exert more control than the community will tolerate – as Rob describes – that will result in a relationship that falls in the red zone, in which the business strategy is too closed, from the perspective of the community.

You only have to look at what has happened with Hudson/Jenkins and OpenOffice.org/LibreOffice to see that situation playing itself out.

It also indicates that if the business exerts less control than the community will tolerate, that will result in a relationship that falls into the green zone, in which the business strategy isn’t closed enough, from the perspective of the company.

It could be argued that the failure of many companies to generate the conversion of community users to paying customers is the result of a failure to match a paying product/service to the community’s tolerance point.

The graphics below also demonstrate the schisms that can occur if

a) a company suddenly exerts more control that the community is willing to tolerate

or b) the community’s tolerance level suddenly diminishes.

As we have seen with regard to MySQL, the latter can occur when a change of ownership highlights the potential implications of control points that might previously have been tolerated.

Finally, the statement also implies something else that is very interesting in the context of some research I have been doing recently on companies disengaging from open source: that if the community is tolerant enough, then harmony can also be achieved where the vendor is exerting high levels of control.

However, I believe that it is likely that there are also thresholds, a level of vendor control that a developer community will never tolerate (a user community might be different) and a level of community intolerance that a vendor will never engage with.

My contention is, therefore, is that in practice the window of opportunity would look more like this:

The 451 Take on the Future of Open Source

As previously mentioned, The 451 Group was very pleased to be able to participate in this year’s Future of Open Source Survey. We believe that the results provide critical insight into the wants and needs of end users that will help shape the evolution of vendor business strategies designed to meet the long-term needs of the industry.

The 451 Group’s research has previously shown that the benefits of open source software are many and varied and The Future of Open Source Survey highlights the fact that multiple factors are driving the increased adoption of open source software, including freedom from vendor lock-in, greater flexibility and lower cost.

As part of our involvement in the survey we have produced a report providing our perspective on the results and what they mean for the industry. The report is available to 451 Group clients here, and is also available to non-clients here. The report is free, although you will need to complete a short form to receive the report, which will also give you the opportunity to trial additional 451 Group research.

Red Hat: one in a billion

It looks like it’s time again to ponder on Red Hat’s ability to (nearly) make $1bn in annual revenue and wonder why open source has not produced more billion dollar success stories.

Matt Asay doubts whether there will ever be another pure play open source company with $1bn in revenues. I would go further and state categorically that there will not be.

I have already discussed why that might be the case, in terms of the diverging strategies of pure-play open source and hybrid source, so I won’t go into that again in this post.

Instead I wanted to look specifically at Red Hat and how it was able, and was allowed, to grow to the point where it is on the brink of that $1bn revenue barrier. Red Hat’s strategy was covered extensively in our recent Control and Community report. Some excerpts from that report:

“Red Hat’s position has been achieved thanks to its ability to dominate the market for Linux subscriptions by virtue of its brand status. This in turn has been achieved by having a strong product, good customer support and a commitment to community-led development that has enabled the company to balance its own economic interests with the diverse interests of its community of users and developers…

“Clearly Red Hat has made enough impact among revenue-influencing users to generate significant profits from Linux, as well as its other open source software assets, but maintaining that influence is another factor for open source distributors. Even in those cases where a user does feel the need for a support contract or subscription, the longer they use the software, the less likely they are to require support for non-mission-critical deployments…

“The answer, for open source distributors, is to ensure that they are delivering more value than simply saving time, and Red Hat has led the field in delivering additional ongoing value in its RHEL subscriptions, including the Red Hat Network systems management software…

“Perhaps the biggest problem facing open source distributors, however, is the commoditizing impact of open source software, and the fact that they are attempting to generate revenue at a stage of the value chain that has been commoditized with that very product. Red Hat’s Whitehurst put this into perspective when he described how in order to generate $5bn in revenue, Red Hat would need to displace software that currently costs $50bn…

“That the open source distributor approach will survive is not in dispute. We also do not doubt that Red Hat will be able to maintain its position as the leading open source distributor for as long as it remains independent.”

The point about Red Hat’s independence is a critical one, and explains why I stated above that Red Hat “was allowed” to grow to its current position. Clearly avoiding being acquired is integral to that (and it remains the case that Red Hat could be acquired before it even hits $1bn).

What is particularly interesting about Red Hat is how important its independence was to other companies that have also generated significant revenue from Linux. Returning to Control and Community:

“In his 2003 book The Innovator’s Solution, Clayton Christensen noted that when one stage of the value chain becomes commoditized, the ability to earn attractive profits from proprietary products emerges at an adjacent stage in the value chain. In that context, it can be observed that the biggest beneficiaries of the adoption of Linux were not the Linux distributors, but rather server vendors including IBM, Hewlett-Packard and Dell, which exploited interest in Linux and industry-standard server and processor architectures to rapidly displace Sun Microsystems’ more expensive Unix and Sparc machines.”

The fact is that it was in the best interests of IBM, Hewlett-Packard, Dell and others – including software vendors such as Oracle – *not* to acquire Red Hat. Nobody wanted to repeat the mistake of having multiple competing flavours of Unix. The fact that Red Hat was independent was part of what enabled IBM et al to be successful in positioning their Linux-based products as (to borrow a phrase) “not Unix”.

It was Red Hat’s innovative business strategy that made it the leading Linux distributor, but it was the rest of the industry’s need for an independent commercial Linux partner that elevated it to another level.

Could we see another open source vendor elevated to a similar level of importance in the future? It is entirely possible, but unless is there is a repeat of the requirement to keep the vendor in question independent any successful OSS pure-play will simply be acquired.

The success of Red Hat is based on the conflation of such a large number of factors (not all which have been addressed here), that I don’t think it will happen again.

It’s also worth thinking about whether that requirement to keep Red Hat independent still exists today. But that’s another matter…

OpenStack: balancing control and community

“the trends appear to be moving away from control and back toward community and collaborative development, which is why The 451 Group has advised that established vendors that rely on controlling open source development projects need to evaluate how they might be able to transition to more collaborative development practices and permissive licensing”
The 451 Group: Control and Community, November 2010

Shifting from control to community is not easy. Recent weeks have provided a number of examples of how the demand for collaborative development from the community can outpace corporate strategy.

A prime example would be the reaction to Google’s decision to withhold the code for Honeycomb until it deems it to be ready for wider distribution.

While Eric Raymond had cautioned against over-reacting to this news, Stephen Walli meanwhile also provided a timely reminder of retaining too much control can be damaging, specifically how it played a part in the decline of the Symbian Foundation.

If that wasn’t enough, Rick Clark also published his concerns about the OpenStack project and whether Rackspace has overstepped the mark in trying to control the project rather than influence it.

OpenStack is a benchmark in the shift away from control seen in the past few years, since the project was itself born out of a desire to shift the balance towards community-led development.

As we wrote in Control and Community:

“NASA… was formerly using Eucalyptus’ open source cloud platform, but in July created the alternative OpenStack project with Rackspace following a disagreement with Eucalyptus. The exact nature of that disagreement is itself a matter of dispute, but it is clear that it was related to the copyright attribution agreement used by Eucalyptus for external contributions to ensure that it was in a position to continue its open core licensing approach. It is no coincidence that the OpenStack project involves distributed copyright ownership and a non-copyleft license, designed to ensure that the core software will remain open source while providing all participants with equal opportunities to create closed source derivatives and complementary products and services.”

Quite how equal the opportunities for participants are was drawn into question by Rackspace’s recent acquisition of Anso Labs and the launch of its Cloud Builders business providing support and services for OpenStack deployments.

While this was unsettling for some it should not have been a surprise as Rackspace had made no secret of its desire to explore commercial support and services revenue opportunities, although it had stated that it has no desire to sell closed source variants.

As we wrote in July 2010:

“The vendor says it does not plan any commercial licensing or products from OpenStack. Its main focus is making cloud computing easier to consume and repeat, although it is anticipating that users will deploy the software on-premises to create their own on-ramp to the Rackspace cloud and is considering providing commercial support for on-premises implementations.”

Even so, the acquisition of Anso gave cause for concern. As Glyn Moody noted:

“Anso Labs held one of the four seats on the OpenStack governance board and three of the nine seats on the project oversight committee. The purchase of Anso by Rackspace means that Rackspace now dominate OpenStack’s governance, three to one, and project oversight, eight to one; the “one” in both cases being Citrix.”

And it is the governance of the project, rather than product or licensing plans, that have raised concern. Specifically, as Rick Clark explains:

“Basically, Rackspace made governance changes without talking to the development community or the sitting governance board. This is extremely problematic for the health of the project… The sad thing here, is that the governing body would have probably approved it with only minor changes. The changes are for the most part good, but the process shows a serious flaw in Rackspace’s thinking.”

As noted above, OpenStack was specifically designed to be more open than the alternative and the organisations behind it specifically chose distributed copyright ownership and a non-copyleft license, as well as a promise of openness in order to shift the balance away from vendor control towards community.

In the context of the wider shift away from control it is interesting to note that these steps are not considered enough and that the call has gone out for even less vendor influence and the creation of a non-profit foundation.

While it is tempting to suggest that Rackspace was not open enough in creating the OpenStack project, another viewpoint might suggest that the result of any level of openness is the demand from the community for more.

It is too easy to assume that in the balancing act between control and community the demand for control is exclusive to the vendor. The vendor is in a privileged position, and must recognise this and act accordingly.

However, we must also recognise that the community is often also seeking control, albeit with the aim of sharing that control between collaborating participants.

The balance between control and community is not simply a matter of balancing between the vendor and developers/users, but between all participants in any collaborative initiative.

When commercial open source goes bad

One of the primary proof-points of the success of open source has been its adoption by previously proprietary software vendors.

In February 2007 The 451 Group’s CAOS practice released its third report, Going Open, which examined the increasing adoption of open source licensing by traditionally-licensed software companies and captured the industry best-practices to ensure a successful transition from closed to open.

Four years is a long time in the software industry and in a few months we will publish a follow-up to Going Open, updating our analysis of the trends and best-practices and revisiting the vendors profiled in the report to see how they have fared following the transition to open source licensing.

As well as examining open source successes it is also important to consider those examples where open source licensing has not delivered the expected results, and the new report will also examine vendors that have “Gone Closed” and abandoned open source licensing efforts.

There are a few examples we are already aware of through our ongoing research. One analytic database vendor recently changed the license of its Community Edition project, abandoning the GNU GPL in favour of a license that would not meet the Open Source Definition (I won’t name them now since I haven’t given them the opportunity to explain themselves).

Another example involves a company set up by some prominent former employees of one of the big names in open source software. The first version was released using an open source license but was never updated, as the company focused all its attention on the closed source version instead.

Meanwhile one of the prominent “open source” systems management vendors appears to have removed all mention of its Community Edition software from its website, while the Community Edition itself has not been updated for 15 months. While the project is not officially “dead” it is, to say the least, “pining for the fjords” and the company in question could be said to be open source in name only.

We are sure there are plenty of other examples of companies that have launched an open source project or “Community Edition” only to later decide that maintaining the project was not in its best commercial interests. The question is, why did these companies fail to benefit from open source licensing, and what can commercial open source companies lean from their experiences.

If you have any examples of dead or “resting” open source projects, please let us know and we will investigate.

Please note, however, that in this instance we are not interested in companies that have simply gone “open core” or adopted copyright contribution agreements. As fascinating as those subjects are (and may well be contributing factors in the demise of a project) we are interested for this report primarily in the discontinued use of an open source license.

Nuxeo takes a foundational approach to growing community

One of the central arguments of our recent Control and Community report on open source business strategies was that many so-called open source vendors are failing to enjoy the full benefits of the open source development model by attempting to control their associated projects.

Specifically, we wrote:

“there is a clear trend back toward community-led development and collaboration, and our recommendation is that vendors that control open source projects need to transition toward more collaborative development in order to prove that they are more than just another software vendor that happens to release software using an open source license”

In that light it is interesting (not to mention validating) to see that Nuxeo has announced that it is going to contribute its Nuxeo Core to the Eclipse Foundation to form the “Eclipse Enterprise Content Repository” project.

If approved the proposal will see the creation of project to create a new Java content repository project leveraging CMIS as the main access protocol and API.

From a business strategy perspective, the proposal is designed to speed up content repository innovation by opening up the project for collaborative development and contribution from multiple interested parties.

As Nuxeo CEO Eric Barroca puts it: “We’ve got one main driver: innovation… By setting it free, we’d like to encourage the community to join and innovate in a vendor-neutral environment.”

The move will also create a clear split between what is now Nuxeo Core and Nuxeo’s value-added products and services, including Document Management, Digital Asset Management, and Case Management, and the Nuxeo Studio configuration and customization environment.

We have long argued that this is an approach that vendors who control open source projects should take to benefit from collaborative development and focus their own development effort on value-added products and services so it probably goes without saying that we see this as a positive move by Nuxeo.

It also fits with one of predicted trends (451 clients only) for open source in 2011, so on that basis we also expect and hope to see similar moves by other vendors during the rest of the year.

Who is profiting from open source?

It’s good to see Mark Hinkle has a new open source-related blog (The Fountainhead) although I was somewhat amused by his first post, Open source status report reveals good health and profits.

It wasn’t so much the relative health of open source, which is supported by his list of open source-related statistics, but the reference to profits. The only other mention of profit in the post is in the description of the “non-profit Mozilla Foundation”.

The relative profitability of open source-related software vendors has been on my mind recently. Having updated the database of open source-related vendors we use for our business strategy research I was left pondering how many of the 323 vendors listed are profitable.

January has seen the usual round of press releases from vendors claiming record performances, but conspicuous by its absence amid the claims of triple-digit revenue and bookings growth, tens and hundreds of new customers, and thousands of new downloads is any mention of profitability.

Ingres was a notably exception. Then there’s Red Hat, obviously, which recently reported net income of $26m on revenue of $236m and is well on its way to breaking $1bn in annual revenue.

I also recently got an update from Sourcesense CEO Marco Abis. While it’s fair to say that the company is nowhere near $1bn, Sourcesense is a great example of how you don’t need to be a venture-backed revenue-generating machine to be profitable (which it is).

And let’s not forget that profit should not be considered a dirty word when it comes to free and open source software. Generating profit enables increased funding of the development of free and open source software.

So consider this an open invitation for open source-related vendors – large and small – to declare their profitability in the comment section below. Don’t be shy. (To be clear, we don’t necessarily need to know how profitable you are, but if you are, why not shout about it).

Open source distributors beyond the Thunderdome

“Matt Aslett says only Red Hat can survive in a post-apocalyptic commoditzed wasteland”, comments Alan Shimel. I’m pretty sure I didn’t.

What I did do was describe the conundrum that I believe is discouraging venture capital investment in open source distributors.

Specifically, when we talk about “open source distributors” we are focused specifically on companies with a 100% open source software-licensing strategy and support model.

The term is not our own, but has been used by Dirk Riehle. He defines it as “a service company and/or distributor to provide services that allow for efficient operation of the project inside a customer enterprise”.

The definition does not include companies that have created their own open source projects, which we, like Dirk, call Single-Vendor Open Source. Those companies often combine open source licensing with a dual license/open core model, which are – as Alan points out – much more attractive to VCs.

Besides, as previously noted, we do not dispute that the open source distributor approach will survive, or suggest that Red Hat will be the last man standing. But we do question whether any other vendors will achieve or better the scale achieved by Red Hat.

Open source’s commodity conundrum

Matt Asay’s recent article in The Register If you open source an old market, are you doomed to fail? highlights the need for open source specialist vendors to innovate, as well as commoditize.

This is an issue that has been discussed regularly by CAOS practice – most recently in our Control and Community report into open source software-related business strategies.

This is how we discussed the issue in that report:

“Perhaps the biggest problem facing open source distributors… is the commoditizing impact of open source software, and the fact that they are attempting to generate revenue at a stage of the value chain that has been commoditized with that very product. Red Hat’s [CEO Jim] Whitehurst put this into perspective when he described how in order to generate $5bn in revenue, Red Hat would need to displace software that currently costs $50bn.

In his 2003 book The Innovator’s Solution, Clayton Christensen noted that when one stage of the value chain becomes commoditized, the ability to earn attractive profits from proprietary products emerges at an adjacent stage in the value chain. In that context, it can be observed that the biggest beneficiaries of the adoption of Linux were not the Linux distributors, but rather server vendors including IBM, Hewlett-Packard and Dell, which exploited interest in Linux and industry-standard server and processor architectures to rapidly displace Sun Microsystems’ more expensive Unix and Sparc machines.

Like many other application server vendors, IBM also enjoyed the benefits of widespread adoption of the Apache HTTP server, redistributing the software as part of its WebSphere Application Server, and enabling the company to build a revenue stream that was complementary to Apache HTTP. IBM repeated the trick in 2005 when it acquired Gluecode Software and adopted its distribution of Apache Geronimo as WebSphere Application Server Community Edition. While this approach of generating revenue from other products and services was common in the early stages of commercial open source… it has come to the fore in recent years as part of the multi-vendor open source approach…

That the open source distributor approach will survive is not in dispute. We also do not doubt that Red Hat will be able to maintain its position as the leading open source distributor for as long as it remains independent. The question is whether any other vendors will achieve or better the scale achieved by Red Hat. As covered in our 2009 report, Open to Investment, there is a case to be made that a 100% open source software-licensing strategy is incompatible with the demands and requirements of private investors, and that the template for future open source distributors is not the venture-backed high growth and profile of Red Hat, but smaller, more modest open source support, service and consulting providers.”

See also: Why there are no billion-dollar open source companies

Updated open source business strategy framework

We have had a couple of queries this week regarding the open source business strategy framework we have used for the last two years or so in our analysis of open source-related business strategies.

The framework has evolved over time based on changing strategies, our research, and feedback from clients (and non-clients), but the last publicly-available version of the framework (to which the query related) was only a work in progress.

Since there is interest in making wider use of this framework – we are pleased to have seen several OSS-related vendors using it to explain their strategy – the easiest thing to do is to publish it here.

To understand how we made use of the framework to analyse the open source-related strategies of 300 software vendors and subsidiaries, see our recently published Control and Community report.

The framework, and a brief explanation of terms, is below. Any comments, suggestions, gratefully received.

Software license
• Strong copyleft
Reciprocal licenses that ensure redistributed modifications and derived works based on or including the code must be made available under the same license. For example the GNU GPL and the Affero GPL.

• Weak-copyleft
Reciprocal licenses that enable integration with closed source software without the entire derived work having to be made available under the same license. For example the GNU Lesser GPL, the Eclipse Public License, the Mozilla Public License, the Common Development and Distribution License (CDDL).

• Non-copyleft
Permissive licenses that do not place restrictions on code usage, enabling it to be integrated with closed source software and the combined code to be distributed under a closed source license. For example BSD licenses, the X11/MIT license, the Apache License.

• No preference
The vendor commercializes software that combines or utilizes multiple open source software licenses and has no discernible preference.

Development model
• The Cathedral
The source code is available with each software release, but is developed privately by an exclusive group of developers.

• The Bazaar
The code is developed in public, with builds and updates constantly made available on a public forge available to anyone.

• Aggregate
The vendor commercializes software that utilizes a combination of publicly and privately developed software and has no discernible preference.

And separately:
• Community
The software is predominantly developed by a community

• Vendor
The software is predominantly developed by a vendor.

• Mixed
The vendor commercializes software that utilizes a combination of community- and vendor-developed software and has no discernible preference.

Copyright ownership
• Vendor
The copyright is owned by a single vendor.

• Foundation
The copyright is owned by a foundation.

• Distributed
Copyright ownership is distributed across the individual developers

• Withheld
The copyright is owned by another vendor.

Product licensing
• Single open source
The software and all associated features are available under a single open source license.

• Multiple open source
The software and all associated features are available using a combination of open source licenses.

• Dual licensing
The software is available using an open source license, or a closed source license.

• Open core
The core project is open source, but a version with additional functionality is available using a closed source license.

• Open complement
Complementary products and services are available using a closed source license.

• Open edge
The core product is closed source, but extensions and complementary features are open source.

• Open foundation
The core product is closed source, but is built on open source software.

• Open platform
Open source software has been used to create a platform for the delivery of software services and Web applications.

Revenue generator
• Closed source license
Either for a version of the full project, or a larger software package or hardware appliance based on the project, or for extensions to the open source core.

• Support subscription
An annual, repeatable support and service agreement.

• Value-add subscription
An annual, repeatable support and service agreement with additional features/functionality delivered as a service.

• Service/support
Ad hoc support calls, service, training and consulting contracts.

• Software services
Users pay to access and use the software via hosted or cloud services.

• Advertising
The software is free to use and is funded by associated advertising.

• Custom Development
Customers pay for the software to be customized to meet their specific requirements.

• Other Products and Services
The open source software is not used to directly generate revenue. Complementary products provide the revenue.

Reaction to Control and Community

We were pretty pleased with our recently published Control and Community report on open source-related business strategies, but then we are biased.

Fortunately some people have been good enough share their thoughts on the report, so you don’t have to take our word for it. Here’s some links to the reaction, along with a few choice quotes:

Ian Skerrett:
“I would definitely recommend reading the 451 Group research paper on Control and Community. It is really good and if your company is seriously looking at an open source strategy you need to read it and understand it.”
See also: here.

Henrik Ingo:
“It is great to see one of our analyst companies being so close to the pulse of the Open Source community, companies trying to understand the phenomenon of open source will certainly get value for their money by being a 451 Group customer.”
See also: here.

Roberto Galoppini:
“A must read for every vendor or organization willing to make consciuos decisions around its open source strategies”

Carlo Daffara:
“I can not remind anything from any analyst or researcher being as good as this.”

Simon Phipps:
“It’s an excellent report.”

Thanks all for their kind words. The report is freely available to CAOS subscribers, while non-clients can purchase it separately or apply for trial access. More details are available here.

In addition, Henrik mentioned that he found that the chart we used to illustrate the overall trend in business strategies (as seen here) has some information loss due to the chosen format.

That is true, but it is also by design since we chose that specific chart (having tried multiple other iterations) specifically to illustrate our conclusion. In hindsight, perhaps we should have included both that chart an another showing absolute numbers on the Y axis for context.

So here is the companion chart:

Copyright assignment – a little commercial perspective

Gather the pitchforks and light the torches. Hordes of marketing men are gathering, intent on invading the free and open source software village armed with copyright assignment policies and turning everyone into mindless corporate contributors. As Michael Meeks (via LWN.net) has warned there is “‘a sustained marketing drive coming’ to push the copyright-assignment agenda” As you read this very post, faceless marketing drones are calling your bosses, spreading pernicious lies about the necessity of copyright assignment policies.

Meanwhile, back in commercial reality, copyright assignment agreements have been a valid, albeit controversial, element of the open source software development for decades. They are used by vendors to protect their rights, some would argue unnecessarily, but are neither new nor growing in usage.

If anything, in fact, there is a growing realisation that the copyright assignment policies have a negative effect on community development and contributions, and that participant agreements and permissive licensing, which ensure more equal distribution of rights, are more successful in protecting the rights of both vendors and potential contributors.

We noted over a year ago that copyright control was increasingly being recognised as a core element in open source-related business strategies and added it to the list of categories against which we assessed 300 vendors for our recent Control and Community report.

The results of that research provide some interesting context for the ongoing debate about copyright assignment.

We asked 286 open source software users to express their preference for various copyright ownership options. We were not at all surprised to find that 47% expressed a preference for copyright owned by a foundation, compared to just 6% for copyright owned by a single vendor.

What did surprise us was that just 8% expressed a preference for copyright ownership distributed across the various contributors, since that is the model used for many of the most succesful open source projects, including the Linux kernel and the various Apache projects.

We must be careful not to read too much into this, however. Roberto Galoppini is not correct when he states that “respondents don’t like copyright ownership distributed across the various contributors”, but he is correct when he clarifies that “at least they like it no more than copyright owned by a single vendor”.

Apart from anything else, we must take into account the fact that 38% of respondents expressed no preference either way. This is a significant proportion of open source users who don’t care who owns the copyright to the software they are using. Perhaps this perspective may come back to haunt them, but we should not assume that this lack of preference is a vote against vendor-, distributed-, or foundational copyright ownership.

It is also worth noting that copyright ownership was given an average importance rating of 3.1 out of 5, making it the least important of our five factors influencing open source business strategies, according to open source users. Again, this perspective might be short-sighted, but it cannot simply be dismissed.

Another thing that cannot be ignored is the fact that vendor-owned copyright has been the dominant choice for open source-related vendors for the last ten years.

Our research showed that 50% of the 300 vendors assessed own the copyright to the related open source software project, compared with 28% that are involved with projects with distributed copyright ownership, and just 3% with foundational copyright ownership. The remaining 19% are involved with project for which copyright is owned by another vendor or organisation.

While there are valid issues to be raised about copyright assignment policies, it is a bit late to be raising the alarm.

In fact, our research indicates that the formation of vendors around projects for which the copyright is owned by that vendor has been in decline since 2005 (albeit with a slight increase in 2010). By comparison, the formation of vendors around projects with distributed copyright ownership has risen (albeit with a slight dip in 2006) since 2002.

There is no doubt that copyright assignment has its problems in restricting community contributions. Our research indicates that where a vendor owns the copyright for a project, only 29% use bazaar development and just 13% use community development.

That is, in part, why we believe we are seeing vendors re-assess their use of copyright assignment policies and why we have highlighted, as Simon Phipps has, the difference between copyright assignment and participant agreements.

Should developers and vendors alike be wary of copyright assignment agreements? Of course they should. Is there a calculated marketing campaign designed to convince the world of the necessity of copyright assignment? Of course there isn’t.