← Back to team overview

openerp-community team mailing list archive

Re: OpenERP: Partners Collaboration Model

 

I think Raphaël made a good resume of the AGPL principle even if it's supposed to be known (and respected) by all OpenERP partners (which is not always the case).

Now, beside that, and the fact that hence we cannot and should not directly sell the modules but publish freely the source code, i'm in favor of any initiative that could bring revenues and finance R&D of different partners in an easier way. So, selling and charging services on top of the module, but not the module itself.
Until now there was a clear difference between buying a licence to have a right to use a software and paying to get a service on a software. Main philosophy of OpenErp was to only pay a service and not a licence, and according to me it should still be the case.

With the arrival of the V7, and all its marketing "buzz" around it, i'm afraid that it's causing confusion for customers (but also partners). The principle of an "OpenERP apps" is great... but when we hear in the press some declaration like "now you pay to have more functionnalities"... we've to admit it's quite confusing for everybody.

This long (but very interesting) discussion between partners show that there is a big demand from the community to clarify things but also to put some tools or procedure in place to better collaborate and enrich the OpenERP modules/app list. I think it's the editor responsability to do it.

If OpenERP S.A. is reading this :-) --> You've done a great job, you're developing a huge partner's network around the world, you're selling a lot of direct and short term (immediate) revenues (partner fee, training, consulting, support, etc...). Don't you think now it's time to consolidate the current base and enhance the indirect revenues brought by the partners (mid-long term revenues) ?
OpenERP is missing a lot of important features, since v5, there were no real improvement in functionnalities itself because you said that it's up to partners to develop this; and you're partially right. Next step should be to organize the partners modules/app in such a way the quality can be controlled, the partner can get revenue (from service, not from licence) from its work and OpenERP itself can be enhanced to become the best ERP in the world (it's still your goal isn't it ?). Now everybody is working in its own corner, every partner (or even OpenERP S.A. itself) is re-inventing the wheel, and with so many partners we're everyday facing partners which are not playing the rules. Some partners are afraid to publish their work because their direct competitors could "stole" it and "re-sell" it to the same customer base; this is not the AGPL philosophy but i fully understand their point of view.

I'm still 100% convinced that making business is fully compatible with Open-Source, but i sometimes feel (probably wrongly) that OpenERP strategy is not always in line with this.

________________________________
From: raphael.valyi@xxxxxxxxxxxxxxx [raphael.valyi@xxxxxxxxxxxxxxx] On Behalf Of Raphaël Valyi [rvalyi@xxxxxxxxxxxx]
Sent: Wednesday, February 06, 2013 14:51
To: Arun Venkat
Cc: Luc De Meyer; Bertrand Hanot; Nabil Majoul; Serpent Consulting Services; openerp-community@xxxxxxxxxxxxxxxxxxx; Partners@xxxxxxxxxxx; all@xxxxxxxxxxxx
Subject: Re: OpenERP: [Openerp-community] Partners Collaboration Model

On Tue, Feb 5, 2013 at 6:38 AM, Arun Venkat <arun.venkat@xxxxxxxxxxxxxx<mailto:arun.venkat@xxxxxxxxxxxxxx>> wrote:
I differ from Bertrand’s view. My opinion is to make the product more viable for partners and OpenERP I feel we should take the Google/Android marketplace route. Let there be a marketplace of tested modules which can be purchased with source code and a % of the fee be paid to OpenERP towards product development. This would ensure the life of the product and a more competitive and beneficial model for partners and clients. What say?

Regards,
Arun KV.

Of course, point taken: funding module development with an open source AGPL license is really hard as roughly the software engineering costs the same cost but can be sold only once instead of n times, to n customers. Now, this difficulty to get a guaranteed returns from selling AGPL modules explains in part the lack of financial investment and hence the relative immaturity of many OpenERP module, even from the core, but I'm coming back to this point in a second part of the email.

So as the code itself as indeed to be possible to get for free, then what eventually is sold instead is may be a service a bit more expensive to factor out these development costs you faced upfront during the development.

But really this works just like a company investing X in sales and marketing. Then that companies has to recover these X spent on marketing inside its service/product margin, right?

With the open source model, you tend to cut these X in marketing and instead you spent them on free R&D to build open source. Then, if your open source is great, you get just as famous for it as you would get from some marketing. And then you recover it the same way from your margin over your services.

Really, proprietary software companies tend to smoke instead much more than 50%, sometimes even 80% into marketing and sales to trick the image about the true value of its product and a large part of it is also spent on protective measure to avoid people getting the sources or using without paying and also a large part is smoked in legal costs around the protection of their royalties over the code or over their patent.

The fact that only great open source tend to get promoted by opposition of the closed source market where money rules, is the very reason why open source product tend to result in a better quality: there is just less catch: solutions flows directly from the producer to the consumer; middle-man fat free.

You cannot wish to have both the advantage of open source without its catches. But really it tends to be a better world, well I'mean speaking about the true open source one ;-)

Completing what Alan Lords said about it, I would even say the end user of the module has even his own interest in publishing freely the source code of an AGPL module code to get it maintained in a more sustainable and cheaper by several parties instead of only one monopolistic one.
As a company, who wish to depend on only one supplier?

This is economical pressure to get the AGPL code published is even so pressing that the non publication of the module source code will automatically trigger high suspicions from all the community that the AGPL license is likely to not enforced:
"How what that company is not releasing its code publicly? How then do they get their audience then? They must be spending X on marketing, right? Wait a minute, if they spend X on marketing that they should also recover from their product margins, how the hell do they ensure that the sale of module that are free to redistribute cover both that marketing AND the R&D costs?"
I mean, it's elementary maths: the like-hood there is a catch instead is just to big to be treated with respect by the community.

By opposition, It would be instead so much simpler to at least state is boldly on the website that modules comes with its AGPL source code, that the absence of such mention raise a suspicion that is likely to result in a value destructive marketing from the rest of the community about the company behind the module.
Net benefit is negative and this is better this way.

And when you push the reasoning forward, at the end it's just makes more sense economically speaking to just publish the code and assume the open source model and assume that R&D cost in place of some marketing costs for instance. That's why the OpenERP world is kind of a bit binary: the open source guys and the others who don't play it by the rules.


An other thing that is binary really is the division between copyleft and non copyleft open source licenses. There are other license such as BSD/MIT or even LGPL where you can easily extend some open source product and sell it without having to enable your users to get and publish the code source freely.

There are even some open source ERP's with this apps model: for instance Openbravo.

So if you prefer the model where people can resale their extensions over a market place, you can very well opt for an ERP where you can do that instead, such as Openbravo.
There is also Tryton which  is GPL where you can build extensions in a SaaS but not publish them back. With OpenERP and its AGPL license this is not permitted: you can just not resell source code.


And this is just not about which model is the best or not. This is in fact mostly about that now that this is done this way this can not be changed back! thousands contributors contributed to the OpenERP eco-system over more than 8 years now because of the guarantee from the license that their effort will remain inside the open source community and will not be taken over by some dark investor power.

Many of these contributors even contributed patches and source code to the OpenERP core codebase and hence technically have rights upon that source code (no contributor agreement never said somebody had the right to change the contract under which that code was contributed which was GPL till 2009 and AGPL then).

And this isn't about the code of just the core anyway. To get OpenERP working and competitive, you are likely to require dozens of community modules among the hundreds of available. For instance your localization modules. And these modules are likely to be solely AGPL with no participation from OpenERP SA to it and no right to them to even say anything about the license in the hypothese they suddenly didn't like their AGPL license anymore.

Speking about the core of OpenERP, the transition from GPL to AGP during 2010 wasn't a big problem as basically with the AGPL the protections around the contributed code where in fact just extended to continue protect the open nature of the code even in the case of SaaS usage. These who didn't like that change could just start maintaining a GPL branch from that day and this is very much what the Tryton fork did for instance (remained GPL).

Now if you would like to change the license to enable not redistributing extensions, for instance transition from the AGPL back to the GPL or even some more liberal license such a MIT, then you would clash with the wish of the contributors who contributed to the code till date who may not agree with that move and would have not way to maintain a new branch that would prevent them from passing over their rights to see all the extensions of OpenERP published.

This is very well explained by the diagram on this page:
http://timreview.ca/article/416


But you, new comer, instead still have the choice to pick an other ERP if you don't like the licensing restriction OpenERP comes with.

Now, really each licensing scheme has its advantages and drawbacks. I'll not dissert upon that now, but just to illustrate that the permissive license enable paid extensions, or paid apps if you like (some may not ;-), let's see some product like Magento: it's a commercial success and one can resell Magento extensions. For instance: you could get an EBay connector for 60$ in Magento vs may be 2000$ in OpenERp wich would account for the development costs as nobody did it already. So the AGPL really makes it really difficult indeed to invest on the   software to extend its scope.

That being said, once these 2000$ will be covered in OpenERP, then you'll get the EBay connection for 0$ in OpenERP instead of 60$ in Magento. And this is like that already with hundreds of free OpenERP modules, including localizations for all around the world. Take OpenERP, the localization we built for Brazil is free AGPL, take Openbravo, the localization for Brazil is a closed source package from one single integrator (Disoft) putting a locking upon the product in the whole country (and believe me they don't sell it 60$ ;-).

Also strong copyleft or "viral" licenses such as GPL and AGPL tend to build systems that will never stop to be improved over the time and that are here to stay. Look at Linux, believe me there where many guys trying to get it re-licensed under permissive license and that failed to happen due to the fact that just like with OpenERP not all contributors agreed on that move. But see where Linux is today? it's in most of the cell phones, DVD players servers...

I mean the GNU tooling we have over Linux, just like OpenERP tend to favor reuse and rationalization of the libraries instead of its fragmentation among peculiar business interests. Take OpenERP, you have some community module depending in chain upon 10 other community modules. Take Magento, it's very rare to see a extension reuse an other extension as business interests will hardly match and drag the collaboration.

See where which ecosystem will be in ten years? Do you believe the Magento codebase will still be alive? I don't think so, I think it the commercial entity behind Magento may survive, but really all that extension codebase is much more likely to go the trash instead (at least this is my opinion). By opposition, it's very likely that in 10 years OpenERP or some forks of it will still be around and rocking with a codebase that will successfully pass all the transitions with the maximum possible reuse.

So really it's not that simple and it cannot be changed back anyway, if even if many wished, even if OpenERP SA or its new potential investors wished. And this is very much what makes this place a safer place to work with.


I hope I provided some clarifications about how the AGPL ecosystem OpenERP is part of works. And all this taken into account I agree very much with what Bertrand Hanot said and as others agreed with.
Feedback is welcome.


Best regards,


--
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi<http://twitter.com/#!/rvalyi>
+55 21 2516 2954[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1MAAA6mAAADqYAAAXb5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf5HBaK5RABmEEwQIvkpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG/V+c553w/54HnPDIiQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+bOMZdkjCoXiUzabvcAwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI27ysqzGQoggAsLa1A7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2QCWdASrpDAzJM5kMI8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7fzcYqr0ClVODl99+YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0PcjhrTLvMfUJsyKYUSeyWQ6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am5tLCYKA3t7eo2dG+1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMkdfykCQC0kSGUTo+Ajmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0mk+QfHMzV3WjcKH/4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LECFWq3XF6XRGA4HAptTsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube4GblQIAAAAASUVORK5CYII=]
www.akretion.com<http://www.akretion.com/>

[http://akretion.s3.amazonaws.com/assets/sign.png]



Follow ups

References