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.
Open Source basics
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.
The basic question: How do you want to make money?
After open sourcing your product, your income options are reduced. Here are the usual options:
Service based- Consulting
- Support, Maintanance
- Hosting
- Product add-on / extensions
- Sponsored develipment
- Legal (commercial license, hold harmless agreement)
Are you the real provider?
A 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.
Projects without providers
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.
You are the provider
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.
The balancing act
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:
- “Free riders” - people who do not want to pay, cannot pay or don’t need to pay. No offense is intended here, I am certainly a free rider of the Apache Web Server, Eclipse, etc. I’ll differentiate this community below.
- The actual end users - In the case of Compiere and many business applications, the end user is usually just interested that “it works” and that support and help is available fast, easy and cheap. End users are certainly vocal if things don’t work as expected. They often hold back with praise, but are happy to help and provide references when asked.
- Open Source Businesses - Companies/individuals who use open source products to make money, so intermediaries. They are the most vocal community. In contrast to end users, they are happy to praise the product (as it’s good for their business) and is the first to do so. In my experience with Compiere, I noticed that the intermediaries become more vocal as they tend to be “free riders”. The Compiere community, which produced more end user seats was far less vocal than the Adempiere community. If you introduce a partner channel - i.e. paying intermediaries, the others will stress your open source deficiencies (e.g. mandatory contribution clause for Openbravo - or lack of eagerly accepting contributions in the case of Compiere) and tend to fork the product if the interest is strong enough and the license allows. Note that quite a few vendors of business open source tend to not use an OSI approved open source license like Openbravo.
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.
License Options
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.
What could Consona do?
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
- no delay for code availability
- contribution process, e.g. certifications and using code reviews for more complex contributions and easy “here is a fix, look at it” code drops
- Define “framework” or “toolset” functionality, and commodity business functionality. The criteria would be that everyone is interested in improving it - to avoid holding back of contributions for differentiation
- Define areas of competition “premium functionality” (i.e. OpenCore with a realistic and sustainable line in the sand between collaboration and competition)
