If you look at different open source companies, there are mainly two business models for an open source publisher:
- Releasing a light and open source version of the product and selling closed-source modules with additional features. Some examples are SugarCRM, OpenBravo or Compiere.
- Having two versions: an open source version and an "Non Open Edition" that differ in some areas. Editors who do this include Alfresco who release bugfixes only in the non open edition; MySQL which offers different editions with different capabilities; and Magento which has more features in its Non Open Edition.
At OpenERP, we believe in open source and we think there's a third option: release everything we do for free.
So, for years, we have looked for alternative ways to finance the R&D while keeping our software fully open source. We never wanted the "Light Open Source Version" or the "Non Open Edition" model.
We have tried different models: getting money for implementation services, shared funding modules, etc. None of them was a real success for the community and for the product.
Today we can say that our business model is strong and allows us to support our vision: making business qpplications available for everyone, sustaining R&D and satisfying customers. We've done all of this while keeping our software and all the extra modules 100% free.
So why should I pay for open source software?
The software is free, but not the services (free as in freedom, not free as in free services).
If you need support services from a partner, you will have to buy a support contract. If you would like maintenance services from OpenERP, you will have to buy the OpenERP Publisher's Warranty contract.
This is necessary because the partners and publishers need money in order to support their services. No other industry can provide services for free. In addition, OpenERP would not be able to keep on improving the software.
OpenERP has only three sources of revenue to finance the development and maintenance of the OpenERP software:
- the Online offer: to finance hosting, maintenance and R&D of OpenERP
- the OpenERP Publisher's Warranty: to finance maintenance and R&D
- the services to partners: to finance the service team (trainers, partner managers, pre-sales suppport, etc.)
Our business is in line with our ideas.
We consider the bugfix guarantee and the migration guarantee to be services. You can still report a bug on Launchpad (our community platform) and we will try to fix it. But if you need to interact directly with us or if you need the guarantee of a response time, we need to charge for this service.
The same applies for migrations. Migrations in all ERP software are very complex. We do our best to simplify this in the OpenERP automated migration engine, but it remains a project in itself to migrate just one customer. So, we decided to include the migration service in the OpenERP Publisher's Warranty contract. This is also a way to make sure our partners and customers won't be faced with unexpected costs when we release a new version.
Do I have to buy services if I want to use OpenERP?
No. We guarantee through our AGPL License that everyone has the freedom to use the source code, and no one is bound to buy services from us or our partners.
If you want to do it yourself, we give you the source code, the documentation, and a community platform.
We make sure that you always have a choice. For customizing the software you can choose development services from an OpenERP partner or do it yourself. The same applies to bugfixing and migrations: you may either purchase OpenERP Publisher's Warranty, or if you feel that you have the resources, you can manage it yourself.
I often mention that partners deliver one2one services and activities (sales, implementation services, training, consultancy), while the Publisher delivers one2many activities (R&D, marketing, maintenance services).
Given that we publish improvements delivered under the OpenERP Publisher's Warranty, our paying services directly contribute to the quality of the software, and everyone benefits.
Why is migration a service? Doesn't it rely on simple scripts to develop and reuse?
It is not as simple as it seems. Our previous (v4.2) method was indeed to send a migration script to our partners, ask them to apply it and then, in the following weeks, all the unexpected problems were dealt with through troubleshooting.
It was a waste of time for the partner and for us (it's very difficult and time-consuming to debug migrations remotely, just based on an error log, without having access to the database). On average it took 7+ emails to complete the migration.
We think migrations are so complex that a script will fail most of the time (custom modules of the customer, custom environment, unchecked modules, different intermediary versions with a different schema, etc.) In order to deliver the quality service everyone is expecting, we have to control the quality, adapt the process for each customer and continuously make improvements.
If we just sell or publish a migration script, we know this will result in many frustrations. That's why we decided to carry out and control migrations ourselves. When we deliver the migrated database to the partner or the customer, we will have already fixed the issues ourselves and our quality control team will have tested the results.
What can I do if I don't want to rely on your services?
If you don't want to subscribe to an OpenERP Publisher's Warranty contract, you are free to manage it by yourself. The good thing about open source is that you are free to spend money or time doing it yourself.
If community members want to work on migrations scripts, we will of course welcome these contributions, but past experience has taught us that it might not be the most efficient way.
That's why we think that the publisher has to offer an extra guarantee service for customers that are willing to pay to avoid unexpected problems and costs.
How does OpenERP see the relationship with the community?
As the founder and CEO of OpenERP, I'm passionate about open source. My dream is to build the best enterprise management software and make it accessible to everyone.
OpenERP benefits a lot from its active community and their contributions. Our community is great and we value its work. So, we also have to help members of the community to understand OpenERP, how to contribute, etc. That's why we launched the Mementos, collaborative development platform, community managers working on launchpad with contributors, etc.
But we have a low-cost business model: we have limited resources, and can't pay people to do everything we'd like to. So we have to prioritize our activities, not focusing on ones that only benefit individual contributors, instead concentrating on ones which benefit the community as a whole such as:
- Communicating with the community at large before discussing with individuals
- Fixing bugs for everyone rather than supporting individuals that have questions on OpenERP (that's why we work more on Launchpad than on the OpenERP forum)
- Developing new features for everyone, not for the needs of just a few
- Releasing public source code and documentation instead of giving support to some individuals
Why does the community need the partners, the customers and the publisher?
Purely community-based ERP projects like Adempiere, GnuEnterprise and Ofbiz have built great communities but ultimately they have failed to build a great product.
I think the best way to build a great product is to have a healthy relationship between the partners, the customers, the community and the OpenERP publisher. Why? Because each party brings something different and unique to OpenERP.
As an example, there are three types of development in OpenERP:
- Adding new features which create added value for the end-user
- Improving the usability and the user interface which makes it easier to learn how to use the the software
- Improving the kernel: no direct value but simplifies further developments
Partners and customers will often contribute new features (1) because the customer is willing to pay for it to support their business needs. In this case the publisher's main added value is to guarantee the modules will comply with future evolutions of the software.
Regarding the second point, the customer will never want to pay for it. So, the partner will usually not work on these improvements. Who would pay for 100 days to redevelop the UI when you can just pay for 5 days to train your own users? It's OpenERP's role to invest in these types of improvements. This is why nearly all partner's contributions are new modules, not contributions in the web or GTK client.
For the third point, I would say the contributions are a mix of improvements made by the community and OpenERP's R&D team. The community usually carries out continuous improvements (lots of small improvements/features), whereas OpenERP works on big bang/rewrite from scratch (looking at views on all modules, replacing wizards by osv_memory, writing a bunch of automated tests, etc.)
So in summary, to build a great product, you need:
- Customers: to finance the improvements (through services to partners for new features and through OpenERP Publisher's Warranty for long term maintenance and evolution)
- Partners: to develop new features and support customers (mainly points 1 and 3)
- Community: to continuously improve the quality of the software by providing constant feedback and contributions
- OpenERP: to improve the product (mainly points 2 and 3)