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[Call: +55 21 2516 2954] <#>
www.akretion.com <http://www.akretion.com/>
_______________________________________________
Mailing-List: OpenERP Partners
Post to: partners@xxxxxxxxxxx
Unsubscribe: mailto:partners-request@xxxxxxxxxxx?subject=unsubscribe
Options: https://mailman.openerp.com/mailman/options/partners
