Community mailing list archives

Re: Odoo v9 Community and Enterprise editions

Akretion, Raphael Valyi
- 05/10/2015 22:46:00
I also wanted to answer another point raised by Antony from Odoo:

so basically you are also telling us that the less bug there are, the less you can sell maintenance and this is a doomed strategy for you.

Well, I think you miss a point: the lest bug there are, THE LESS IT COST YOU TO SUPPORT YOUR CUSTOMERS, THE MORE YOU CAN SCALE. So you can very well mitigate the revenue by customer with the volume and I think this is exactly the kind of logical evolutions the market expects from the IT industry.

For instance at Akretion in Brazil, over the last 3 years, a project is costing us some 3x less time to implement because of all the progress made in the localization, in the core and also because of all the experience our team consolidated. Well a team of the same size now just has may be 5x more customers now so we actually improved despite we make less revenue by small/medium customer.

And Let me remember that per capita Akretion is producing more open source code (reviewed at the OCA) than Odoo SA and that globally the OCA is also producing a much larger volume code than Odoo SA. So don't tell us it doesn't scale, it does.

Also you seem to think that partners will be better on their market and will never buy you ANY service. Well I think this is wrong, if you do a service that partner would not do as good for the price, many partners would buy it from you. This is the market logic.
So for instance, Akretion could very well buy some hardware and host our customers in house. But we don't we pay Amazon, OVH and other providers because they do it better than us. We could do all our accounting in Brazil ourself like we do in France, but we don't we pay an externalized accounting company. And this is us Akretion doing that for 7 years with top notch engineers, imagine all the services you can still sell worldwide to the newer guys with less experience or less skills (but please don't fake they are better just because they need to buy you more expensive support).

If you were focusing on producing top notch services to your partners since the start they would buy it. So for instance you killed your CTP offer worldwide while it has somewhat some success. In that CTP program, we were ok to give you a margin (when it was moderate) to access your English core educational content from which we would build our own. We didn't reject it to do our own material from scratch, there was a room for sharing revenues and it wasn't that bad as long as you didn't try to make it fuel an exaggerated marketing and sales spendings we wouldn't even decide for us, aware of the limitations of an open source business model.

Probably you couldn't generate a lot of revenue like this. Probably. But does it matter? If you just adapted your scale and spendings to this reality instead of thinking you would be SAP in 3 years, you would do just well with this reality just like OCA editors are sustainable without claiming to revolution everything every year but still doing some pretty darn cool magic at their own scale.

I think this could be true at a much larger scale. Now if eventually partners were disappointed by the services they purchase from you or if they lack of trust in your volatile chaotic business moves, then yes, it's a bit late for several things. But hey, you at plenty of time and good advice to think about all that when it was still time...

And when Fabien tells us that only an extreme speed would save Odoo. Well sorry, I think you are mixing your own VC mortgage rates (or revenue growth targets more realistically) with the product strategy. I think if it stays open, even if the code develops 2x slower (and who said it will?), it will do absolutely well too.

My 2 cts again.

On Sun, May 10, 2015 at 9:58 PM, Antony Lesuisse <> wrote:
On 05/10/2015 02:08 PM, Sebastien Beau wrote:
> This is why the best OpenSource business model is to
> - sell service (support, development, maintenance)
> - using share funding for big "R&D"
> - ask for donation
> This model is totally viable, as the cost are really reduce (not need for big
> marketing investment, cost maintenance share with all the partner, shared code
> review, shared R&D...)

You could add - selling tee-shirts :)

Caveat, the following just reflect my personal opinion.

I dont believe it is a sustainable business model for a software editor.

Donation is the business model of charity and foundations, it could work for 
small projects but not for a product like Odoo, i recommend the following 
article about donation and open source

Crowdfunding can be effective to bootstrap new ideas or finance a specific 
developments but not for day-to-day development. The funding we got from the 
crowdfunding projects we did, didn't cover costs of the actual development.

Building a company just on those 2 revenue lines would be foolish and that's 
the reason none exists.

Now remains selling support, development and maintenance, that's what we did 
with Odoo till now, but with moderate success because it's a doomed strategy. 
This strategy can works for an ISV but not for a global and mainstream 
software editor.

- development: custom development conflict with a generic product vision, it 
defocus the company, and more importantly it's best done by local partners 
with various specific expertise, also pricing vary a lot. That's why there is 
so much value in the partner network and in the community.

- maintenance: the more buggy the software is the more value maintenance has. 
Each time we fix a bug we undermine the value proposition. And yet, we want to 
build a great and bug-free product. Of course maintenance should be part of 
the package, because customers needs to be insured about problems, and no 
software is fully bug free. But selling only maintenance is a commercial nonsense.

- support value also decrease with time, can be handled by a local partner and 
conflict with the product strategy (making the software simple and easy to use).

A software editor can only be successful (and thus a software can only 
succeed) if it can secure a stable revenue stream from a least a subset of its 
users. And remember, if you never pay anything, YOU are the product.

Nowadays the favorite model is to sell subscriptions and sometimes additional 
non recurring fees (usually for consultancy).

For a subscription model to work it needs to come with an exclusive added 
value, whatever the licence. For example RHEL and MariaDB subscriptions 
provides you an exclusive access to their certified binaries. RHEL can be 
labeled as a pure Open Source product because the exclusive stuff is only the 
binaries instead of additional software. This is a neat trick but it would not 
work for Odoo.

RHEL is an exception, all other open source products are financed by selling 
an exclusive superset with a clear value proposition example Redhat JBoss 
Enterprise vs JBoss community.

For Odoo to succeed and to become the leader in management solution, i'm 
convinced that it will need hundreds of man-years of the best people focused 
full time in creating the best software possible. It's not possible to ensure 
that future based on a fragile business model.

Choosing a strong business model is as important as choosing a strong 
technical framework and we need both to succeed.

For my own code my favorite license has always been MIT, because of its 
simplicity. OpenERP switched to AGPL around october 2009, and i can understand 
the reasons of that decision before including a CMS but not anymore.

In practice many people run closed source modules. i'm sure even Akretion does 
it, the Odoo servers of theirs customers are probably running on a public ip, 
i can visit the page (at least the login page) i'm thus entitled to ask for 
the source code of ALL modules. CMS worsened to problem.

I'm entitled to ask the source code of every module of every Odoo server 
listening on a public ip. Does akretion wish that ? (Akretion is just an 
example, it's valid for every partner).

No akertion doesnt want you to get all that code, they want to share SOME of 
it. AGPL makes no sense for a software that is modular, has to be customized 
for very specific use cases and is reachable on internet. That's the reason we 
had the private use exception.

Now LGPL (as opposed to plain GPL) will allow all people (Odoo SA, partners, 
everyone) to mix the opensource part with EULA protected modules. The term NDA 
(which means non diclosure agreement) was incorrectly used in the thread where 
it meant EULA (meaning an EULA that would restrict distribution only, yet to 
be written).

So, yes, if you choose to publish your modules under LGPL it will be possible 
for a proprietary module to override your method and extend your work. 
(Technically it would also be possible without linking to your code, by doing 
rpc calls or direct database access to avoid linking it's just much less 
convenient). I dont think that's evil. Most of you probably already runs very 
specific code with hardcoded data that you dont want to be public. We are just 
making that legal for every user.

The other consequence is that it officially create a market for proprietary 
modules, the market was already there, behind the scene, operating in a gray 
area. The LGPL move doesn't prevent people to publish their open source 
modules. It allow people to publish officially their proprietary one. Let me 
repeat this, everything that was possible before the change still is possible. 
It opens the ecosystem to new possibilities. Every author is free to choose 
the license of its module, whether or not it publishes it by himself or 
through an OCA repository.


Post to:

Raphaël Valyi
Founder and consultant
+55 21 3942-2434