In this post, I elaborate on options of open source business software providers based on my experience with Compiere. This is from the perspective of an open source vendor/provider - and with the assumption that you are looking for an income stream. This is a bit different from the interests of businesses using open source products for income. In the first part of the series, I outlined the development of the open source business model of Compiere, in the second one the dynamics of open source contribution I experienced.
The fundamental promise of open source is vendor independence, that you can use and modify the the product ... assuming you have the skills and time.
From an commercial open source provider point of view (i.e. you want/need to create income), the fundamental challenge is that users have no obligation to “give back”. This giving back might include contributing product enhancements, helping others or donations.
In addition to providers and users there is a third group: intermediaries, who help end users use the product in exchange for payment. Also here no obligation to give back.
A challenge for commercial open source vendors is that - if the project provides true vendor Independence - despite best intensions, in tough times payments to the open source vendor are in danger of becoming discretionary.
After open sourcing your product, your income options are reduced. Here are the usual options:
Service basedA provider has the legal rights to the product over and above the Open Source license (i.e. you “own” the product). If you are not the provider, you options are reduced. The usual options for contributors and third parties are consulting, maybe support and hosting and depending on the license, charging for product extensions.
If the product does not have a provider, due to abandonment or fork, the options are much easier. The contributors are now all peers. For these type of projects (e.g. Adempiere), it is much easier to receive contributions. The challenge of these projects include conflicting interests of the contributors, the proliferation of the scope and loss of focus as well as consistency.
One option is that one contributor decides to become the quasi-provider (e.g. Openbravo after forking Compiere). Alternatively, an organization is created to coordinate the efforts and is funded by users and contributors (e.g. Apache foundation). These quasi-providers concentrate on maintenance and development. The challenge for the foundations is sufficient funding.
If a commercial company decides to become the quasi-provider (e.g. Openbravo), they are still bound by the original license (in this case MPL) even though the product evolved. Openbravo claims that they have the full IP, but the product evolved from Compiere approach and architecture and even if they changed every single line of code, it is still a derivative and bound to the MPL.
First consideration is under what license you want to accept contributions. The standard contribution terms are that the provider gets full intellectual property (IP) usage rights. That is especially important for original (non-forked) project providers.
If you have the full IP, you can offer commercial licenses. The importance today is probably diminished as companies become used to Open Source and GPL products for products you just want to use. A commercial license is not so important for MPL based products (like Adempiere), but is certainly an issue for GPL products if you want to extend/modify them.
Sponsored development is a classic income option, i.e. to speed up the availability of certain functionality a user sponsors it. The usual challenge is to maintain the scope of the product and differentiate it from customizations.
Assuming you want to build a thriving community, all other income options create potential conflicts with the community.
If the open source product is the “core” for your product add-on, I still think that it is a viable option, despite the recent “Open Core” discussion. The challenge here is the clean line between the open core and the add-on. The OpenCore critique is that it is hard to draw the line - and I agree if you look at products like SugarCRM, where the community plays catch-up with the functional scope of the professional “add-on” edition.
Creating a partner channel is a popular option. Partners pay for the privilege and receive more information and better support than the community. To build up a reliable distribution channel is in the interest of every commercial entity, but for an open source vendor, you must provide incentives for distributors of your product to sign on as a partner. That creates two communities: the “open source” one and your partners. As soon as Compiere created the partner options, partners complained about the perceived lack of competitive advantage compared with non-partners and pushed for restrictions and requested exclusive territories.
Offering consulting is I think an essential requirement for open source product providers. But that creates a conflict with partners as that is the premier income for partners. In 2007 I started pushing to build an consulting organization in Compiere for two main reasons. As a vendor, you need to build competence - that includes the full implementation life cycle for an ERP product. This is the also the basis to be able help partners to build their practice - and for that you need to have first hand experience. The second reason is to get direct exposure to customer needs, procedures and environment. I think this early direct feedback is essential to set the right priorities - often development organizations are “shielded” by support and consulting. Other motivations to build up consulting is the ability to bail out partners when projects went bad - and revenue. The danger is that the development organization turns into an consulting organization and drives priorities in a different direction, especially as it is easier to grow revenue with consulting than with products. My main point is that the organization must have consulting competency in order to better help the partner channel. One of the reasons for the decline of Compiere in my opinion is that this competency did not exist.
Offering commercial support is usually a core strategy business of open source vendors. This offering then competes with the free open source support forums. The main reason for companies to request this is privacy and guaranteed response. Even though commercial companies have thriving user support forums (like SAP or Salesforce), the main benefit for companies is that it could expedite the process to get a patch. Another reason people like access to support is that they don’t need to search in the support forum.
Offering commercial maintenance is another traditional open source vendor offering. This includes patches, new (stable) releases and the migration to the new version. As version migration is not trivial in ERP. Compiere offered that as a core commercial offering. This introduces a dependency on the vendor, which is in contrast to the idea of vendor independence of open source. Consequently partners tried to build similar functionality and migration was one of the first projects in Adempiere. Often “stable/tested releases” are marketed by open source vendors and in the case of Compiere, also from Partners. That is usually an attractive proposition, although the stable release was usually a recent daily open source release build.
Today, hosting becomes more important and open source vendors add that to their offering. The effort required today is quite low, especially if the product is easy to install and multi-tenant. Nevertheless, Compiere abstained from hosting as that was seen as competing with partners.
In conclusion, looking for an income stream as an open source vendor always results in some sort of conflict with the community. So, you have to pick the community you want to “offend”. Your choices are:
As no one is interested in “offending” end users, the question is how to deal with intermediaries. An ERP product is rarely implemented by the end user directly, they search for help of consultants, especially for the more technical parts like interfaces, but often also for improving the business process aspect. So, consultants (= intermediaries) are a crucial part of the success of business application products.
As an open source vendor, you don’t like the situation that people who benefit do not give back. There are two main licenses trying to prevent this: The GNU Affero GPL (http://www.gnu.org/licenses/agpl-3.0.html) and the Common Public Attribution License (http://www.opensource.org/licenses/cpal_1.0). Ideally there would be an open source license with contribution clause. The latter is a bit of a challenge as one does not want to force users to publish perceived competitive advantages.
My main personal suggestions of areas to consider (note that I currently have no affiliations with Consona)
* To foster contributions, change the license to Affero GPL or CPAL (or a combination of the two with a contribution clause)
* To enable contributions painlessly, provide a contribution friendly environment - namely
Fact:
People only contribute, if they cannot monetize the work.
You provide a free product/contribution in exchange for free publicity / marketing.
Well after venting a bit - actually it was not easy to contribute code to Compiere. Main reason was that there was only one source repository line - no branches - and if there was a fix required, it was done in the main code.
The motivation for this was my mantra of a single version. One of the challenges of ERP vendors is supporting many old versions as customers are hesitant to move to the newest version. For an open source project that is unsustainable, so for me the current version must be easy to migrate to - and for that has to be absolutely stable. This imperative resulted in high productivity and VERY stable daily builds as that was the patch delivery mechanism.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.
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.
Inbound Marketing
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.
Conclusion
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.
The Compiere troublemaker and Adempiere leader "red1" (Redhuan D Oon - @red1Oon) resigned: "I have quit as 'leader of ADempiere' . I have enough after nearly 4 years of battles. Anyway the legend is born. It shall have to die now." I have to say that it is not too surprising. The Compiere fork Adempiere had pure monetary motivations (despite singing the "open source song") and it did not work out for the community.
In my upcoming blog series, I will elaborate on the motivation for the Adempiere guys to fork and why they failed. Due to the recent purchase of Compiere, I had quite a few discussions with people interested in a revival of Open Source ERP. Maybe Consona sees that as an option too.
Open Source ERP has a future. The "competing" open source products are quite weak compared with Compiere - maybe it is time for a new start where the objective is to create a great product to compete against the commercial ERP applications and frameworks. The open source community also became more mature - with little support for "troublemakers" and the need for technical and business leaders.
I am in the process of creating a very detailed three part blog about Compiere history and potential future:
It will take me a few days to complete it and receive/include some feedback and validation I requested.
Subscribe here to get the complete Compiere story with its highs and lows directly from the source ... I promise that there will be a few surprises.