Nine years ago, I came to the U.S. to create Intalio and build what I called at the time a transactional workflow system. I was fresh out of school (and not yet graduated), had no money, no connections with investors, and no experience with enterprise software whatsoever. I and two other co-founders arrived in the Bay Area in July 1999, raised our seed round in August, and started building our product with a junior engineering team. Little did I know that it would take us almost a decade to turn the vision into reality. Today, we closed our last round of financing, successfully completing a company re-start that was initiated almost two years ago. Now is time to take this gem of a company to the next level, and I’d love to take you along for the ride.

The vision for Intalio was to build a next-generation platform that would support the development of enterprise applications in a process oriented way. Essentially, doing for processes what the Relational Database Management System (RDBMS) did for data. This analogy is the reason why we soon called our product a Business Process Management System (BPMS). While the analogy gets validated every day that passes by, history rarely repeats itself, and the Oracle of BPMS would likely look nothing like Oracle Corporation. We knew that back that then, and this is why we started with a radically different model for developing and selling our software: Open Source. Back in July 1999, Intalio initiated the development of what eventually became 7 of the Apache Software Foundation’s 56 top level projects, including well-known efforts like Geronimo and ODE, or lesser-known ones like Slide and Xalan.

When we started, every single line of code we developed was released under the very liberal Apache License, which gives the original code author very little protection in terms of intellectual property (compared to the GPL or LPGL for example). As we raised more and more VC money and had to develop a viable exit plan, we quickly realized that we could not build a sustainable business model as a software company while giving everything away under an Open Source license. We struggled with this challenge for a couple of years, and eventually went out of Open Source in 2002, selling our then-immature product through a traditional enterprise software licensing model. In the ensuing 2 years, we managed to sell perpetual licenses to 12 customers, while burning through massive amounts of cash (close to $30M). Eventually, we realized that such a model would not take us anywhere, and decided to return to our Open Source roots.

I served as CEO of Intalio between July 1999 and June 2002, moved to a non-operational role between June 2002 and October 2005, then took over as CEO again in October 2005. Immediately after, Intalio acquired FiveSight Technologies, which had developed the first Open Source BPEL engine, and relaunched with a new Commercial Open Source Model (which we call COSMO, more on this later) in the first quarter of 2006. In the next 18 months, we signed more than 500 new customers, went from 15 employees to over 50, and re-wrote our product entirely, while burning through less than $5M of our investors’ money. Based on our current operating model, we could be profitable today, but have decided to spend a bit more in order to grow faster, even though we’re doing it in a very disciplined manner — let’s try not to repeat the mistakes we made in the past.

To my predecessors’ credit though, their job was virtually impossible. Neither our product nor the market were ready to support the vision we had. On the product side, enterprise software used for mission-critical applications takes a long time to build, no matter how many engineers you can put to the job. On the market side, our timing was off by a good 5 years, and there is nothing you can do about poor timing beside calling it a day or waiting for your time to come. Because we so strongly believed in the vision, we went for the later, but didn’t fully realized it back then, which made it a bit more painful than it should be. That’s the way one gets to learn these things I guess…

When we did this transition back to Open Source 2 years ago, we knew that Open Source was the way to go, but we also knew that a pure Open Source business model would not fly for very long. As far as I can tell, no software company has been successful over an extended period of time (say more than 5 years) while releasing 100% of their code under an OSI-approved license and generating the kind of gross margins that software companies can produce (translation: without doing a lot of consulting on the side). No matter what their Open Source religion is, commercial Open Source companies always end up splitting their code base into an Open Source component and a commercial one, usually at the cost of alienating their communities of contributors and users. We knew that back then, and decided to adopt a model that we thought could be sustained over an extended period of time, for the benefit of our users, customers, and investors alike. We’re only 2 years into this journey, but as far as I can tell, it seems to be working. Here is how we laid it out.

At the bottom, about 80% of the code we write is licensed under a liberal Open Source license, either the Apache License or the Eclipse Public License. We donate our code to the Apache Software Foundation or the Eclipse Foundation, as well as the copyright that comes with it in the case of the ASF. We use these licenses instead of the GPL/LGPL so that our Open Source code can be used by anyone, with no strings attached. And we leverage these existing communities instead of building our own, because we think they’re much better at managing Open Source projects than we ever could be. When it comes to Open Source, we strongly believe that everybody should play by the same rules, on the most open playground possible.

In the middle, we integrate the Open Source components we’re leading the development of (Apache ODE, Eclipse STP BPMN Modeler) with many other Open Source components (mainly from Apache), and package them into what we call our Community Edition. This product is free, yet is not Open Source. Anyone can download it and use it, for development or production, without paying us anything, but it’s only available in binary form. There are two reasons for that: one, providing binaries certified for a limited set of platforms (Linux and Windows for the OS, MySQL for the database) makes it a lot easier for us to support our users on our community site, free of charge; two, it protects our intellectual property for components of the product we feel bring a clear competitive advantage on the market, like our BPMN to BPEL code generator for example. There are now more than 50,000 companies around the world using our Community Edition.

At the top, we add a lot of advanced features to our product that make it easier to use in a mission-critical production environment, like clustering for load-balancing and failover, support for other platforms (operating systems, databases, application servers, etc.), and many three-letter acronyms that only corporate users with significant IT budgets can really appreciate — BAM, BRE, DMS, or ESB to name a few. In a nutshell, if you need the product’s most advanced features (available in what we call our Enterprise Edition), you’re likely to have a budget for it (and all the things that go around it), and it’s only fair that you pay for it. But you’ll do so under very different terms than what you’ve been used to so far. This is where our business model as an enterprise software company differs from the one of our competitors.

First, our Enterprise Edition is licensed through yearly subscriptions rather than perpetual licenses, hence what you have to spend for it goes under the OPEX category, rather than CAPEX. For most corporate buyers, getting things under operating expenses is a lot easier than getting approval for capital expenditure, especially when the former is a small fraction of the later. And the worse the economy gets, the easier it gets…

Second, the yearly subscription for our Enterprise Edition is priced at roughly the same level as the yearly maintenance cost of comparable products from the likes of Oracle or TIBCO (our two main competitors). So while our product is not much cheaper to own on the long term, it’s a lot cheaper to buy initially.

Third, when customers subscribe to our Enterprise Edition, they get access to 100% of the product’s source code, with the right to modify it for internal use. While customers do not have the right to re-distribute the original source code, they do not have to give us their modifications either (as they would should our code be licensed under the GPL). We like to see that as a fair deal for both parties.

This last point might be the most important of all for customers. It used to be that buying a product from a large, established vendor was the best way to guarantee its long term availability and support. As the saying goes, nobody gets fired for buying IBM — or Oracle, or SAP, make your pick. Unfortunately, this is not true anymore. Siebel, PeopleSoft or BEA are all gone, and with them many products they sold to many customers. Tomorrow, even the largest companies could be acquired by private equity firms and their product portfolios reshuffled. Or one of these larger companies could buy a smaller one and discontinue an existing product that was made redundant through the acquisition, which is exactly what IBM did for a Document Management System (DMS) after they acquired FileNet. These things happen all the time, and are bound to happen more and more often. As far as we know, there is only one solution to this problem: access to source code and to a community that can maintain it.

The systems that are built by enterprise customers using our software are the kinds of things that tend to live on for a very long time, and their perennity is one of our customers’ primary concerns. Vast amounts of efforts, time, and money are spent building them, and long-term support for their underlying platform is an absolute requirement, which is nicely addressed by our model. Today, hundreds of companies around the world have access to our full source code, and can modify it to suit their needs. Should anything happen to Intalio, they would still preserve this right, and have access to thousands of developers who are familiar with the product and could support them. The same cannot be said about the products of our closed-source competitors, and this is a key advantage we have over them (beside having what we like to believe is a superior product).

That being said, access to source code is not enough to foster community-led contributions, and this is where our Demand Driven Development program (D3) kicks in. The little dirty secret of Open Source is that most projects receive very little contributions from the outside, and the more complex the software is, the less meaningful contributions it receives, unless you’re talking about mainstream technologies like an operating system’s kernel or a web server. Take a Relational Database Management System for example: most contributions to the MySQL codebase are made by employees of MySQL AB (now Sun Microsystems), and you find a similar status quo for Enterprise DB or Ingres. The same was true for JBoss — JBoss, Inc. ended up hiring most of its contributors. In other words, making your code available under an Open Source license won’t guarantee that you’ll get outside contributions, and in most cases, you won’t get any at all.

There are many reasons for this, but one we believe plays an increasingly critical role is the risk for patent infringement. The more complex your codebase, the fewer people will have the skillset required to make valuable contributions to it. Furthermore, these developers will tend to work for larger corporate organizations that have a lot to lose in a patent infringement case. And if your Open Source project requires contributors to sign a contributor agreement (as it should if you’re a Commercial Open Source company), it is very likely that these corporate organizations will prevent their employees to make any contributions at all. We’ve seen this scenario play out countless times over the past two years, especially with large financial services organizations and telecommunication service providers. So, how do you get your most sophisticated corporate users to contribute to your project, while protecting them from any legal exposure? You get contributions through something like our Demand Driven Development program.

When customers participate in D3 projects, their contributions are in the form of precise technical requirements rather than code, and this is what matters the most, for many people can write code, but only a few know what code to write, and how to write it. In some cases, we even contract back our D3 sponsors in order to receive code form them, but we do so under the terms of a solid Statement of Work, with full transfer of intellectual property rights, and we do not disclose such inbound contributions. In a nutshell, this code becomes ours, and we are the ones eventually making its donation to an Open Source project like Apache ODE or Eclipse STP, thereby shielding our contributor/sponsor from any legal exposure (and we add strong indemnification clauses for good measure). As of today, more than half of our overall engineering budget is covered by D3 projects that are directly funded by customers and partners.

When you combine our contributions to major Open Source projects for 80% of the code we write, access to 100% of the source code for our Enterprise Edition, and our innovative Demand Driven Development process, you get a model for Commercial Open Source (COSMO) that fosters community-led contributions, gives customers the long-term guarantees they need to use our software in a mission-critical environment, and grants Intalio a sustainable business model as a software company. Some might have issues with the fact that we call it Open Source, but quite frankly, we don’t know what else to call it. In fact, time might have come for the clear definition of a community-endorsed Commercial Open Source model, free of religious beliefs and partisan non-sense.

Re-inventing Intalio (or the overall business model for an enterprise software company) did not stop there though. Fixing engineering and product management is nice, but the business process that’s really broken in most enterprise software companies today is sales and marketing. According to a study conducted by Goldman Sachs a few years ago, publicly-traded software companies spend an average of $78 for selling $100 worth of perpetual licenses. In a nutshell, they’re only making 22 cents on the dollar for their software licenses initially, which is roughly equivalent to what they make afterwards on yearly support contracts (usually priced at 20% to 25% of licensing costs). In other words, software companies do not make any money selling software licenses, they make money selling support contracts. So if that is the case, why not let customers use the software for free, and charge them for support only? Lowering the initial barrier to adoption should help the vendor reduce its upfront marketing costs, thereby reducing its needs for capital, and revenues should eventually catch up to levels equivalent to what they would be with a traditional perpetual licensing model.

This approach is very appealing, and has been used by Commercial Open Source companies for a long time, but it eventually breaks when the Open Source software becomes stable enough and well documented, to the point where most users do not really need to buy support contracts. Essentially, customers need a compelling reason to buy these, and goodwill or wishful thinking are not enough. When Commercial Open Source companies realize this, they start changing their model, and usually end up crippling their Open Source software down to the point where it becomes unusable. This is not a sustainable model, and this is the reason why we came up with the layering we have today, with standalone Open Source projects, a free Community Edition with binaries only, and a commercial Enterprise Edition with full source code. While our conversion rates remain fairly low (1% of our users are customers), they’re going up, and the average Purchase Order went from $15K/Year two years ago to over $40K/Year today.

What’s nice about this model is that we do not need to do much marketing upstream. We’re spending about $5K/month on Google Adwords, and get more than 2,000 new organizations to start using our Community Edition in the same period. Downstream, we sell them training services by email and over the phone ($1,500/trainee for a two-days training session), then subscriptions for our Enterprise Edition over the phone. All sales are made by a single telesales representative and our trainers (called Process Experts). Intalio might be the first enteprise software company with over 500 paying customers, and not a single direct sales person. And we have no plans for hiring any in the foreseeable future. Talk about a lean and mean organization…

So here we are. Two years after we hit the reset button (while keeping most of our original investors to their pro-rata, more on this in a later post), Intalio has the largest user base of any BPM vendor, has the largest number of paying customers, and is growing faster than anyone else in the business. We have full-time employees in the United States, United Kingdom, France, Denmark, Ukraine, Singapore, India, China, Japan, Australia, Brazil, and Venezuela, with partners covering another 30 countries or so. We signed a global partnership with Satyam earlier this morning, and they’re building an Intalio practice with 30 dedicated resources in India, plus over 20 sales and pre-sales resources worldwide. This is Intalio 2.0 for you, and it’s only getting better…

What’s coming up next? Well, BPM 2.0 of course. We’ve been promoting this concept for more than two years now, and it’s time for a refresh. Our engineering team has been working on Intalio 6.0 (the product) around the clock, and it will be the first implementation of a BPM 2.0 ready Business Process Platform (BPP), with our new Business Activity Monitoring framework (BAM), integration with Alfresco and Liferay, Business Rules Engine (BRE) powered by JBoss Rules and a brand-new Eclipse-based graphical business rules editor, and our brand-new Rich Internet Application framework powered by TIBCO GI (very cool stuff). This release is coming out soon, and we’re already offering advanced training for it ($9.5K vs. $15K for 12 people if you register before September 30th). We’re also working on more Web 2.0 related stuff that will be announced at our Japan User Conference in a couple of weeks.

More on BPM 2.0 and Intalio 2.0 on this blog soon. Stay tuned…