Recently, Consona acquired Compiere. Is this a failure of Open Source business model? What decisions led to the current situation? In this first chapter of a three part blog series, I will provide some details and insight into the inner workings of commercial open source companies.
In the open source environment, many business models have been tried. In the Compiere environment (including the forks like Open Bravo and Adempiere) different models were put into practice. One of the crucial aspects in open source is inbound marketing. Long before inbound marketing became fashionable, the successful open source projects used this approach to gain momentum.
The blog concentrates on open source business (application) software with it's special challenges, but the lessons learned also apply to infrastructure and tool open source projects.
Evolution of the Compiere Business Model
In 1999 I started to create an ERP and CRM application from scratch. After building the better mousetrapand having the pilot site (sponsored by Goodyear Germany) in production in 2000 the question was how to make it a business success. In my time as Product manager for ERP in the European Headquarter of Unisys (London), I learned that technical brilliance and market success have no correlation.
At that time, Open Source became popular and I started thinking about if that avenue could be an option. In all software companies I knew, the license revenue sponsored the sales effort, whereas development was funded by maintenance revenue. I saw Open Source as the following “deal” – you don’t get license revenue, but for that you have no presales/sales costs and you get marketing and buzz for free.
Open Source: No License revenue in exchange for higher (marketing) visibility potential
In 2001, I open sourced Compiere; Next question was how to price the maintenance fee. Traditionally ERP companies charge 20% maintenance and due to high switching costs (and no alternatives), customers are “happy” to pay the yearly maintenance. With everything open source that is not an option, so my conclusion was to price it as insurance. You hope that you don’t need it, but it lets you sleep at night, so you pay for the maintenance even though you may not have to use it.
Interest in Compiere started to grow and created demand to learn more about Compiere and how to efficiently use it. So, Kathy Pink and I held our first training session in Bonn, Germany in December 2002. It was scheduled for 4 days and about 20 people signed up for it from Hong Kong, South Africa, Australia and Europe.
Training became a corner stone for Compiere – not just for the financial dimension, but primarily as paid presales. We now told people to sign up for the next quarterly training if they had product questions – alternatively they could invest the time to find it out themselves (for free). In my presales time for Oracle Applications, I noticed that people tend to like the application they had most exposure to (and understood best). So the 5 day training was the opportunity to sell them Compiere. We had a 80% plus success rate to up-sell training participants to a partner or customer subscription.
Our primary sales strategy was the Partner channel. Even though we had quite a few end-users (companies) signing up, we saw the growth through partners selling and implementing Compiere. Our proposal was simple: we provide the product and back end support and the partner does “the rest” – first level support and implementation. We wanted to avoid the typical channel conflicts between partners and the vendor.
Partners were quite happy with that arrangement. To sell Compiere, they had to persuade the customer that they should pay them, so they created very minor enhancements and told prospects that they need to use their services and their enhanced version of Compiere. As it was a trust-based system, some partners were a bit slow to pay for new installations or forgot to report a few users. One partner even bragged about 5 successful customer installations and openly refused to pay the maintenance they committed to in their partner contract (they became one of the Adempiere founders after we canceled their contract).
In 2006 we reached the 100 mark for paying partners and had about 240 paying customers (and estimated 600 non paying), so basically 2.4 installations per partner. It took partners about 6 months to complete their first installation. Then there was a “gap” as the first install was usually an easy sale and they created their (sales) strategy after experiencing the first success and gaining experience with the product.
So, Compiere was working fine for Partners, but we were a bit unhappy about receiving just a very minor part of the generated Compiere revenue. Nevertheless, we were profitable since 2003 – a big contrast compared with many other Open Source vendors. In 2005 we (Kathy and I) hired our first employee and generated $800k revenue.
The Business of Open Source
How to move forward? One alternative was venture capital money. VCs were calling us for a while (to learn about making money in Open Source). We started the first presentations in late February 2006 and closed the deal (in record time) in early May. We were able to choose between to offers with a pre-valuation of about $12 million. The main reasons for the valuation was the strength of the Compiere brand and the size of the partner channel for a relatively young product (by ERP standards).
So far, the Compiere business model was free product and generating revenue from services and maintenance. We wanted to change the lop-sided Compiere revenue distribution to get a fairer share of the pie. The first step was to switch the license from MPL to GPL to make signing up as a partner and paying support contracts more attractive. We also implemented the first controls to motivate timely and accurate customer/user reports by partners. Some partners did not like to pay and this created the motivation for the Adempiere fork. Adempiere claims that "Jorg does not accept contributions" was the cause of the fork, which is not correct. I'll cover the contribution issue in the second part of the blog series. All partners who refused to pay their fair share were among the Adempiere founders.
I was not too worried about the fork as I expected it would be similar to the first fork by Open Bravo. In both cases, the rate of innovation is/was quite low compared to Compiere.
The Hockey Stick bet
Venture Capitalists demand the “hockey stick” – so a significant growth in revenue after the initial investing (low growth) phase. My business model ensured a sure and steady growth by signing up partners and getting them as productive as possible. So the search began.
The first action was to increase the prices slightly, which only increased the number of partners to join Adempiere. That was not a loss, as they did not report their installations. The total revenue increased due to higher number of customers and slightly bigger deals.
The popular idea at that time was a professional (fee based) version in addition to the free product. I was not too enthusiastic about it – in order to promote your fee based product, you have to degrade the base product touting the difference as enterprise functionality. It also creates conflicts with the open source community. The emphasis of the company is on the professional version. In some projects the open source community accepts the professional version (e.g. providing a graphical user interface to the “command line” open source product). As the distinction is not that easy to draw in applications, it often ends up that the community contributes the functionality of the enterprise version (see SugarCRM). For Compiere, we came to the conclusion that a good distinction would be an improved web user interface as an alternative to the Swing based UI. (Later Don made the decision to also add Manufacturing functionality as closed source, but was not able to sell it)
Another idea was to “steal a channel”. At that point, Microsoft had some problems with their Dynamics partners and the idea was to "upgrade" the existing Compiere partners with more experienced ERP resellers. Early on, we had some partners who were also SAP and Oracle partners. They liked Compiere very much, but made the decision to drop it as they found it too challenging to manage the sales process with two different models and have a consistent message to their prospects. The other reason is the investment of partners in their vendor's technology. It takes time to train people, get certifications, etc. Even if they are not be too happy as a partner, the switching costs are very high and it takes time to build up the alternative product infrastructure and knowledge. If having the new and old products co-exist is difficult, the partner will switch only if absolutely necessary. My suggestion was to improve the partner training and provide significant sales support. This approach was regarded as too slow and long-term.
The VCs decided that it has to be their hockey stick version and so Don Klaiss got his chance. As there are many ways to Rome, I thought that there is a chance that this bet succeeds and would also benefit as a major shareholder. But, execution is everything.
Some “techies” believe that the better mousetrap will sell automatically. Even though it seemed that the early Compiere was not sold, I put significant effort into marketing and “creating buzz”. Don thought that the activities were amateurish and stopped all marketing activities. Well, my constant marketing activities might not have been ideal, but they produced results. Don kept wondering why visitor rates, etc. kept falling. Ironically, my marketing activities were exactly what is now touted as Inbound Marketing and I passed the Inbound Marketing University (IMU) certification test with honors without studying for it. I learned it over the last 5 years with Compiere by trial and error like other successful open source leaders. Inbound Marketing was certainly the "secret" of the Compiere success, but in 2006+ that was regarded as not professional by Don's initial marketing crew. They spent nearly a year just re-designing the web site and removing content which drove traffic. The marketing crew was later "upgraded", but also using traditional outbound marketing, they did not manage to recover the lost momentum. About year ago, Don fired most sales/marketing resources as they did not produce the immediate results he needed and again stopped any marketing activities. One can only wonder.
Know (and like) thy customers
To “upgrade” customers is a constant strive. In business 101 you learn, that the demand is defined by feature, price, availability (choice/competition). If you have some sales experience, you learn that the relationships are not linear. Who signs up for Open Source products? Well, people who are cost conscious and look for independence. To sell them licenses is a bit of a challenge. To understand Compiere customers better, Don visited partners and customers and told me afterwards “they are little people”. Well, it helps if you like your customers and unfortunately Don did not manage to recruit the customers he liked.
The partner “upgrade” initiative was also not a success. In board meetings Don proudly announced that he fired another batch of non-performing partners. Unfortunately the partner recruitment rate continued to drop from the average 5-10 new partners per quarter Kathy and I managed to achieve since the start - despite 4 dedicated sales people. Certainly no “stealing of channel” occurred and even though some of the newer partners had more ERP experience and signed up slightly bigger deals, it did not generate anything resembling the desired "hockey stick".
Training is an after-thought for traditional software companies, so Don stopped the promotion of trainings and his sales reps tried to answer the many questions people have regarding ERP systems. They did not understand that a $5k investment for training is a pretty qualified lead. Then to have 5+ days for people to become completely comfortable with the system - isn't that paid presales for the subscription? They still thought and acted in terms of license sale, even where there was no license to sell.
Compiere invested heavily in proprietary software. The first round of $6m was followed by another of the same size. Many partners liked the proprietary Web based UI, but there was unfortunately not that much interest for the proprietary business functionality.
Compiere certainly did not fail due to its technology. It failed due to lack of sales and marketing expertise, execution and the wrong bet to “upgrade” open source minded partners and customers to a traditional, commercial model. I think that the Commercial Open Source model is still valid, but Compiere overstepped the balance between proprietary and open product components.
I think the model to be successful in open source is still the original Compiere model of a free product and commercial support and services, but is unlikely to create the hockey stick VCs look for. It "just" creates a steady subscription based revenue stream.
Nevertheless, the Compiere product exists and is certainly superior in its market (= the primary motivation for Consona to invest in Compiere). This may be a good time to revitalize the momentum of Open Source ERP and Compiere. In the second part of this series I will cover the lessons learned from building (and losing) open source community support.