Open Source: Free as in Freedom, not free as in Free services

If you look at different open source companies, there are mainly two business models for an open source publisher: 1. 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. 2. Having 2 versions: an open source version and an "Enterprise Edition" that differ in some areas: Alfresco releases bugfixes only in the enterprise edition, MySQL has editions with different performances, Magento has more features in the Enterprise Edition. At OpenERP, we believe in open source, and we think there is 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 "Enterprise 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 the product. Today we can say that our business model is strong and allows us to support our vision: making Business Applications available for everyone, to sustain R&D and to satisfy customers. All of this while keeping our software and all the extra modules 100% free. So why should I pay for an 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 request maintenance services from OpenERP, you will have to buy the OpenERP Publisher's Warranty contract. This is necessary since the partners and the publisher have to get money for their services. No other industry can provide services for free. In addition OpenERP would not be able to continue improving the software. OpenERP SA 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 the maintenance and R&D the services to partners: to finance the service team (trainers, partner managers, pre-sales suppport, etc.) The first two lines of revenues are very sane, because each $ won through these services goes directly in the development of OpenERP, and will benefit to the community. Our business is in phase with our ideas. We consider the bugfix guarantee or the migration guarantee as a service. 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 a guarantee of 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 just to migrate 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 will not face 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. And we like this: 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 may opt for 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 you have the internal 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 we had to troubleshoot during weeks all the unexpected problems. It was a waste of time for the partner and for us (it's very difficult and timeconsuming 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 build continuous improvement. If we just sell or publish a migration script, we know we will be creating many frustrations. That's why we decided to do 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 consider 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 communities in order to make them understand OpenERP, how to contribute, etc. That's why we launched the Mementos, collaborative development platform, community managers working on launchpad with contributors, etc. In a few days, we will launch a series of interviews of contributors on the website in order to thank them for their contributions to OpenERP. But we are in 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 the activities which benefits the community as a whole and not individual contributors such as : communicating with the community at large before discussing with some 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 the needs of just a few release public source code and documentation instead of doing support to some individuals Why does the Community need Partners, Customers and the Publisher? Purely community-based ERP projects like Adempiere, GnuEnterprise and Ofbiz have built great communities but ultimatly 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 the others can't do in OpenERP. As an example, they are three types of developments in OpenERP: 1. Adding new features which create added value for the end-user 2. Improving the usability, the user interface which makes the software easier to learn 3. Improving the kernel: no direct value but simplify further developments Partners and customers will often contribute new features (1) because the customer is willing to pay for it to support his business needs. In this case the Publisher's main added value is to garantee 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 100 days to redevelop the UI where you can just pay 5 days to train your own users? It's the role of OpenERP to invest in such 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 the R&D team of OpenERP SA. The community usually does continuous improvements (lots of small improvements/features), whereas OpenERP SA works on big bang/rewrite from scratch (view views on all modules, replacing wizards by osv_memory, writing a bunch of automated tests, etc.) As a summary, to build a great product, you need: Customers: to finance the improvements (through services to partners for new features, 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 SA: to improve the product (mainly points 2 and 3)