chris horn's blog

This month is the 10^th anniversary of the IONA IPO n Nasdaq. I can remember vividly being asked by a smart Harvard MBA during the roadshow: “are you guys trying to be a Microsoft or an Oracle ?” Very presumptuous I thought, but the core of the question was our go-to-market strategy for our middleware technology.

Until the IPO, we had had a shrink-wrapped package approach, enabling inbound telesales in IONA and a number of regional distribution channel partners – the “Microsoft approach”. We believed we had introduced a new leverage point into the industry: apparently, nobody had thought about shrink-wrapping middleware before – up until us, middleware had been an enterprise sale with a large amount of systems integrator involvement.

The MBA’s question was whether we would, after the IPO, build a more conventional enterprise field sales force – the “Oracle approach”, and attempt to increase our average selling price beyond its then current sub 10,000USD level.

I had thought about this business strategy issue at length. The stock answer to the question was – audaciously – “both!” It was my belief that we were seeding the enterprise market with a low cost, packaged Trojan horse. However, having seeded opportunities in our customer base, there could well be an opportunity to up-sell additional enterprise products to the basic platform. Some IONAians may remember my BMW theme: “we first sell them a 3-series over the phone, but later they’ll want a 5 or even 7 series which they will want to buy from us face to face. And they must be all part of the same brand” (and as an aside, BMW didn’t yet have a 1 series back in the 90s).

So that’s what we did. We built a field organization after the IPO to sell our high end products, and continued to use the telesales operation to prime the pump. Some MBA types and business faculty now call this “ambidextrous” I think (see for example O’Reilly/Tushman; Celly/Han/Nia; Organizational Science. Another aside: Charles O’Reilly is one of the faculty on the Enterprise Ireland Leadership for Growth programme).

Sometime later, I had the privilege of being invited to join Sanjay Vaswani’s Centre for Corporate Innovation (CCI), which is a number of chapters of CEOs of high technology companies, most of them public, across the US. I believe I was the first European CEO to join. Each quarterly meeting typically consists of a roundtable discussion, followed by a presentation and discussion led by a guest speaker. At one such event, Clayton Christiansen spoke to us about his then latest book “The Innovators Dilemma” – I’m sure you’ve read it. As I listened, I realized that our approach at IONA followed Christiansen’s model: we disrupted the incumbent market from below by a low-cost high-value displacement, and then introduced add-ons as we focused on the enterprise. Shrink wrapped middleware was our successful attack on the incumbents. Christiansen’s general observation and warning was that a company had to be wary of itself being displaced from below by a new entrant – i.e. a company had to continue to be ambidextrous. I was sufficiently and perhaps naively confident that our ability to innovate and “eat our own dog food” would protect us. In retrospect, we were late catching an emerging technology wave in the late 90s – but that’s another story for another blog entry sometime.

Roll on to today. Is open source the weapon to displace incumbent enterprise software by disruption from below ? Is IONA today a closed source enterprise software company, or an open source aggressor ? I guess, as before, the audacious answer is: “Both!”.

Let me explain. I believe that enterprise customers – Fortune 2000 and federal – seek vendors whose competence and sustainability they can trust, to understand and deliver mission critical systems. The full cost of enterprise software is naturally not only the actual license cost but also the investments needed to integrate it with other corporate applications and enterprise data. There is the cost of staff training, not only for the user screens, menus, features and functions, but also for the training of the IT operations staff so as to ensure smooth and efficient operations, and no critical outages. Before making all these investments, a customer wants to ensure that the solution is likely to be valid for some considerable time, while still being maintained and evolved as needs dictate.

In general, risks arise if the system becomes uniquely tailored for that particular customer. Forking of the product source code base by the vendor – a separate derivative version of the source code for each customer – is dangerous, and makes the vendor vulnerable to unviable maintenance costs and skills shortages. It is even worse, of course, should the vendor, or an acquirer of the vendor, drop the product line, or even go out of business completely. A source code escrow account, negotiated at the time of the product commitment, and triggered by a dramatic change in the vendor’s business, is sometimes used to mitigate risk of vendor viability. Nevertheless, very few customers are comfortable with the prospect of having to adopt a substantial foreign code base as a result of a nuclear meltdown.

An enterprise customer in general seeks a vendor who understands the customer’s industry and specific business. The vendor has either verifiably delivered similar solutions before or, if the customer is prepared to be an early adopter, is willing to extend and modify the product – without forking the code base – and work with the customer to deliver competitive business value, despite the risks involved. The professionalism and competence of the sales engagement, particularly the comprehension of the solution by the pre-sales team, are thus vital to establish trust and reassurance.

How does open source play in this arena ? Naked open source – source code downloaded from an internet repository – is usually of little value in an enterprise, except for low value routine commodity utilities such as document format converters. However a number of software vendors package open source with service such as product distribution, maintenance, support and training. Comparatively few of these companies currently have a field organization which is capable of professional sales engagement to rigorously define and commit to the likely business value.

Forking of the source code base is as fraught with risk as it is with a closed source vendor, and clearly should be discouraged and avoided. Having multiple distinct copies of the same open source technology is not helpful. However in my view, the bigger risk is the loss of talented committers to the code base. Although the source code is open and available to all, in most open source projects in practice there is in each case a small number of committers who do the real work. If those committers stop maintaining and extending that code base, then the project quickly stagnates. A committer may stop because of a change in her job responsibilities or the pressure of the day job. But more likely, a committer may stop on a particular project because she feels she has learnt enough from that project, and there is a more exciting new project and new technology starting elsewhere in the open source community.

In my experience, enterprise customers are always keen to understand a vendor’s product roadmap. An appreciation of what likely new releases, with what additional functionality, over the next couple of years, help reassure that the vendor is committed and has a vision for its competitive development, but also help the customer to plan with respect to internal projects and priorities. However, it is in general quite rare to be presented with a road map for an open source project, going out over a couple of years or so, because in general there is no long term responsibility for the project.

In some, but certainly not all, open source projects, the legal ownership of the intellectual property can be opaque. Sometimes, projects include components which were partially supported by the public funds, and jurisdictions can have different perspectives – for example many European Union funded projects typically have an expectation, as a first call, of commercial exploitation. Sometimes, projects include dependencies, or even “cut’n’paste” of code originating from other projects or even from text books. Sometimes projects are forks of others. And sometimes, a closed source vendor will cast doubt on the legitimacy of some open source, as most recently Steve Ballmer did as a result of the Novell partnership. These factors tend to cause enterprise customers, particularly those publicly quoted and under the current regulatory environment of Sarbennes-Oxley and 404, to reflect on the appropriate use of some open source. I am aware of enterprises which proactively take steps to purge open source from their organisations unless there are legally enforceable contracts in place from a vendor warrantying the ownership and responsibility of the associated source code.

Where does this all leave enterprise customers and open source ? Enterprises with a strong technical capability will occasionally embrace open source and assume responsibility for maintenance and extension themselves if necessary. Occasionally, an enterprise will contribute its own open source efforts to work with the community at large. But most enterprises, to the extent that they have a development organization at all, prefer to dedicate their internal resources to helping their business units gain competitive differentiation and advantage.

Now, I hope I haven’t left you with the impression that I reject open source for the enterprise. My emphasis is rather what an open source project should do if it is to be successful in the enterprise. And those thoughts are driving the current “ambidextrous” strategy of IONA, with both our closed source Artix product, and our open source Celtix project. In particular, the commercial investment in Celtix by IONA provides a reasonable guarantee of long term commitment; a product roadmap and direction; a supply of skilled committers; clear legal and IP ownership, with contracts as enforceable as those for closed source; consulting and training services; and the option, should you want it, of commercial grade maintenance and enterprise support – including a free 30day trial period of support. We are also building community support for Celtix initially by contribution to ObjectWeb and subsequently contributing to Apache’s CXF project. Other open source initiatives are also considering Celtix at this time.

Why does IONA provide both open source and closed source forms of similar technology ? Artix has certain enterprise features, including for example support for high end and mainframe technologies, which are currently absent from Celtix. It is an application of the old 80/20 rule: 80% of the customers will use 20% of the potential of the technology – and by implication 20% will need at least 80%. Celtix and Artix play to each segment. And one further consequence is that we are seeing some early adopters of Celtix move on to also subsequently adopt Artix. To re-emphasise above: “we first sell them a 1-series or 3-series over the internet, but later they’ll want a 5 or even 7 series which they will want to buy from us face to face. And they are all part of the same brand”.