JAX 2009: Open Source As Part of a Successful Product Strategy

(Disclaimer: this text was written while listening to the presentation – please be forgiving with errors that might result from both listening and writing)

Paul Clenahan is going to talk about taking an open source approach helped his company to build a successful business.  While waiting for his talk I wish him the best of luck because currently my colleague Jochen and I are the only attendees to the talk. My guess is that the wording “product strategy” sounds too much like a marketing event for a technical conference like the JAX. Paul is the vice president of product management at Actuate and hopefully has a better plan than to present just some marketing slides lest we need to give him feedback by leaving, too.

Paul announces to present a kind of case study about how Actuate profitted from open source and is himself a member of the BIRT committee at Eclipse. Actuate is a business intelligence company with around 100-140 million dollars turnaround. They position themselves as “the company behind the BIRT project”.

Initially he presented the following open source product strategy options:

• support for open source (platform, services)
• cost reduction using open source (bundling, SaaS provider, embedding). Bundling here means that some parts are free but you need to spend extra money to have an end to end solution reducing your net costs and hopefully thus becoming more attractive. Embedding is closely related in that your product either is embedded in an open source system or vice versa.
• development of open source (contribution, open source project, value added products). Contribution is the simplest model giving you the advantage of having access to a software more suitable for your needs. The next step is actively leading a project – Actuate did exactly this.

For Actuate this was an evolution of about 10 years from 2000 to 2009, starting with embedded open source and finally  becoming the BIRT project lead.

Strategy decisions were mostly influenced by the question about how the companies core competencies could be leveraged and allowed to keep the existing revenue streams while proceeding on the open source path. The base idea behind open source was to gain momentum and awareness and build a community of developers. Additionally Actuate hoped for a higher software quality due to more exposure.  The expectation – if well done – was to be able to sell add-ons to the then existing open source community. An important challenge was to also find the correct license – if people shall use your software, the license model must allow for this and encourage it.

Support and services today mostly are not only but still an important part of the new revenue stream. Additionally a mix of complementary products and new enterprise software would add more revenue. He then presented a lot of important detail issues:

• revenue generation choices (he recommended the papers of the 451 group): cost reduction by embedding, support and services because you are the expert, dual licensing (open source code available with a reciprocal / restricted license, MySQL was a good example for this; additionally a commercial more permissive license; this only works if you have complete ownership of all parts of the source code). Actuate did not use a dual license but rather the Eclipse license and is working primarily with a value-add/complementary product strategy. Other options are value-add products or commercial products targetting a small percentage of the open source users (usually the number will be very small), advertising (although advertising revenue usually is not interesting for enterprise software) or an exit strategy (being bought by others).
• Licensing choices (dual licensing, open-core, open-and-closed, single open source, assembled open source, closed). The open source must not be too restrictive lest the community will not catch on and not too open lest you hinder your revenue options. Additional questions include whether the license is good for IT organizations, ISVs and for extending the technology. Actuate thus chose an open-and-close license (Eclipse vs. value-add ons)
• What to Open Source? The open sourced must be useful enough to get traction. It should be as easy as possible to download and install as possible. Ease of use is one of the most critical success factors since otherwise potential users will walk away. Your technology should be an easy decision for the target market. First impressions are very very important but hard to get right. But be careful not to erode your revenue strategy. The balance between open features and commercial functions versus the license model (restrictive vs. permissive) is most important.
• Possible approaches to the project and the community: contribute to an existing project, create and lead a new project in an existing community or create something from scratch. Examples of existing initiatives are Apache, Eclipse, Sourceforge and many more. Generating awareness here is the most important factor. Actuate believed that creating its own community would not generate enough visibility and thus decided to join the Eclipse project (in August 2004).
• Understand the processes and governance of existing communities (e.g. the overhead the community will bring): Significant time may be required to understand the processes and work within the processes. The community may even introduce additional project requirements. Open source communities with a mentoring approach can be a great advantage.
• Shifting the development culture: Be transparent and non-proprietary, admit outsiders into QA and bug-tracking, invite and manage engineering contributions from all over the world and instill and enforce rigorous product management and development processes. This definitely requires a leap of faith due to the logistical and emotional adjustment required – especially since you will receive a lot more feedback. Additionally it takes time and effort to see the benefits.
• Development team and process: At a peak at Actuate 40-50 developers were working on the open source project and there was an aggressive development plan to quickly build momentum. Most of the contributions come from Actuate although some companies like IBM, Innovent Solutions and others also have contributed minor parts.
• Organizational alignment: Success should be defined very conservatively and the focus should be on long-term value. The model you define initially (for earning revenues) probably will undergo a number of iterations. In any case there are no guarantees and you have to go for a multi-year strategy. Sales teams specifically mjust understand this since sales teams usually are focussed on short-term revenue. Support for the community is very important – being an evangelist, monitoring and responding to forums, create “how tos” and tutorial content for the website, work with and write articles for 3rd party publications and web sites. You will not be found magically and need to spend quite a bit of ressources to that effort! Actuate has one dedicated person that does nothing but watch forums and respond to requests, write articles, etc. Additionally you need to nurture and grow a community web site for information exchange, sharing content, etc.

How did it work out? 6.5 million downloads to date (conservatively, really rising in 2007/2008), five major releases since the launch in 2004, the releases for a long time have commercial quality. Open source projects must be very good technology and solve real problems. The estimated user numbers for BIRT range between 250.000 and 500.000 users (a huge step upwards from about 10.000 users before going open source). 75% of the current BIRT users come from markets that traditionally have not been Actuate markets – the geographic spread is much larger than the previous north american bulk. The brand has been strengthened but brand awareness for Actuate could be much better – they are not that often related to BIRT itself. BIRT-related revenues have been about $8 million dollars in 2007 and about $15.4 million dollars in 2008. Competition can only be countered by adding more and more value because you can’t prevent others from taking more and better things on top of your software.

The old rule holds: “You will be more successful if you can build better software than other people”.

Cool presentation, very interesting points and good hints for getting more information. And Paul is a great and very lively presenter – it’s a lot of fun listening to him. For me this presentation has been yet another JAX highlight – a loss for many people that did not show up.