← Back to team overview

openerp-community-leaders team mailing list archive

Re: [Openerp-community] Injustice, plagiarism and insult of community work

 

Hello Fabien,

Thank you very much for taking time out of your busy schedules to write back
to this community.

On Sun, May 16, 2010 at 1:25 PM, Fabien Pinckaers <fp@xxxxxxxxxxx> wrote:

> Hello,
>
> History of this module
> ----------------------
>
> 1. The smtpclient is a personal initiative of one our developer. It was
> not in our R&D backlog. I just discovered it a few days ago.
>
> 2. We reviewed the smtpclient module just after the publication of the
> blog and we decided to remove it from the addons as it was not clean
> enough.
>
> 3. So, the smtpclient will be removed from addons and be moved to
> addons-extra. The mailgateway module will be independant of the
> smtpclient module.
>
>
> Our internal policy
> -------------------
>
> At OpenERP sa, our policy is quite clear:
>
> * Promote every community's effort, even if we think the module is not
>  clean or useful enough for the official version.
> * If we reuse something from the community, we:
>    - keep the author in the module
>    - keep the copyright
>    - put greetings in the commit.
>  If one of our developer forget this during his work, we fix this as
>  soon as we get a notice from someone of the community.
> * It is not our policy at all to try to stole copyright.
>
> Please avoid launching trolls about this.
>
>
> I did not checked the code, but I don't think mga took code from
> poweremail module. Mga, can you confirm or not. If you get some code
> from poweremail, wan you change the copyright in your module ?
>
> The smtpclient module
> ---------------------
>
> I'd like to thanks the author of the smtpclient module.
>
> It's a good contribution to OpenERP (even if we think it's not ready to
> be ported to v6.0.) It adds several features and some companies may find
> the solution they need in this module.
>
> I don't think it's fair to criticise someone who contributes. (whether
> is's OpenERP SA, a personal initiative or someone from the community).
> Every contribution is a plus to OpenERP.
>
> You can blame OpenERP SA to have added this module in addons because you
> think it's not good enough. This is a mistake of us and we will remove
> it as soon as we have changed the mailgateway module to remove the
> dependency. It's in our backlog since a few days.
>
> Your attitude
> -------------
>
> I think your attitude is not open at all !
>
> It's not acceptable to blame someone that develop a new open source
> module. Every one is free to develop what he needs, this is what open
> source is all about.
>
> You may like the new development or not, but don't blame someone who
> contributes. It's sometime a good thing to have several modules that
> does the same thing. People will use the module that best fits their needs.
>

Anybody is free to develop what they want. But, opensource is also about
improving what is available not rebuilding whatever already exists. From the
design, approach and blog I had linked all were a clear duplication of the
community work on poweremail. It may be better to have alternatives from the
perspective of having multiple disto's of Linux, but IMHO not sure about
duplicates :(

I really appreciate if you could ensure that the new module is not a
duplicate in methodology, functionality and code.


> Our policy about duplication of Work
> ------------------------------------
>
> Our policy is to reuse what exists, if it's possible.
>
> But sometimes it's better to recode than to reuse. Here are some
> examples, which lead to great improvements in OpenERP:
>
> 1. Scenario
>
> * OpenERP had a test system based on asserts and .XML files.
> * C2C did not liked this and made a good contribution with OERPScenario
>  instead of using/improving the current OpenERP test system.
> * We thought the C2C system can not be integrated in the main branch so
>  we released an improved version of our initial data loading/test
>  system: YAML.
>
> Today, we have two good tests system in OpenERP: OpenERPScenario and YAML.
>
> I think it's very good to have alternatives, we must keep and promote
> both: and that's what we do.
>
> OpenERPScenario is a strong improvement to OpenERP. Even if we decided
> to not use it, for reasons I previously explained, we promote their
> contribution.
>
> This is exactly what open souce is all about: freedom to use what you
> want, freedom to redevelop what you don't like.
>
> 2. Report Engine
>
> * Reportlab had a report engine that produced PDF files based on .XML
> data. (RML2PDF) This was a great tool because, 10 years ago, every
> report engine where based on code, rather than data.
> * We decided to redevelop it because it was not open source. So we made
> trml2pdf, an open source alternative.
> * The community decided to add new report engine because RML has some
> limitations and we have about 4 new report engine in OpenERP: OO
> headless, mako, etc.
>
>
> Fortunately these two examples are exceptions. In the 500 modules of
> OpenERP, you have only a very few of them that overlaps. This is good
> because it's a waste of time to redevelop 2 times the same thing, even
> if sometimes it's required.
>
> It works in both ways. If the community do not like a module from
> OpenERP, you can redevelop an alternative for it. We will not blame you
> but promote your effort.
>
> So, please be open to this.
>
> About Quality certification
> ---------------------------
>
> > Is it because the community cannot pay for a community contribution
> > that the effort is duplicated?
>
> The quality certification is a service for customers, if they want their
> module to be checked and maintained in the long term. (migrations of
> versions, ...) It's not required and our goal is not to force people to
> pass it.
>
> If we think a module is good enough to be integrated in the official
> release, we take the certification at our charge. We already announced
> we will do it for several accounting modules and for poweremail.
>

Thank you for the official confirmation of this news. I express my gratitude
for the same.


>
> We made the review of poweremail for quality certification and including
> it in the next versions of OpenERP because it's clearly interesting
> features.
>
> In my first check, I think they are several things to change before
> being included in the official version.
>
> Some examples:
> * the name of the module must be changed. Something like: email_template
>  To compare, we will not name a module efficient_sale in the official
>  addons.
> * most menus must be changed according to v6.0 guidelines. It must be in
>  submenus of Tools, instead of defining a root menu.
> * we need the module to send template of emails, but we don't need the
>  reception of email. (pop/imap) Managing mailboxes is a different
>  behaviour and I prefer to have light modules.
> * Also, there is a good contribution from axelor for webmail which seems
>  more advanced for managing mailboxes. (reception of emails)
>
> If you allow, we can do the rework (and keep your copyright of course).
>

Fabien, thats the difference here. From, Day 1 the module branch has been
owned by the 'Open ERP Committers' - the most active group of community
members and Open ERP SA employees. I have absolutely no issue with any
changes AS LONG AS IT IS DISCUSSED WITH THE COMMUNITY WHICH DEVELOPED IT AND
USES IT. The policy on code changes is 'propose merge', its 'open for
peer-review' and after review it gets 'merged'. This allows to take full
benefit of the tacit and explicit knowledge wealth in the open erp community
rather than individuals like us or organisations (Compare open ERP SA with
the collective wisdom of the community).

But certainly, there should be no issues with any of these changes for
version 6.0 since nobody already uses this for 6.0.


>
> Conclusion
> ----------
>
> > When I conclude this mail, I am not sure if I will ever get a reply
> > for this mail from 'Open ERP SA'. But please remember that the more
> > you do this, the more the community moves away from you.
>
> Sharoon, please understand that:
>
> 1. It was not the intention of OpenERP to duplicate your work. It was a
> personal initiative of one of our employee and his intention was to
> improve the mailgateway which is a slightly different behaviour than
> poweremail. I don't know if he reused code from poweremail or not. But,
> you may like it or nto, a contribution is always good thing.
>

There is NO FACTOR OF MY PERSONAL LIKING. IMHO we expect Open ERP SA to play
the role of an editor. I think it is important for Open ERP SA to fix issues
of high importance like the numerous security holes, quality, pythonisation
rather than dedicating the efforts of critical workforce like your India
Director (as in this case) on developing something which is already there.
[BTW its only a suggestion and its none of my business how OpenERP SA should
organise and utilise itself]


>
> 2. If, one day, we reuse your code in one of our module, you should not
> criticise this. (unless we forget the copyright of course) This is how
> open source projects evolve.
>

You have all the right to use (with copyright) since every line of code is
covered by GPL3


> 3. If, one day, you reuse our code, we will not criticise you publicly.
> We think it's normal and we will probably promote your contribution.
>
>
> I understand nobody likes to have an alternative module to one of his
> work. But this is how open source works: having different alternatives
> for the same purpose, and the users use the ones they prefer.
>

I reiterate the fact that this has nothing to do with having an alternate
module if it is written at a better quality and implements better
functionality. In this case both are not there :(


>
> As an editor, we always prefer to reuse and promote the work of the
> community if it's possible.
>
> --
> Fabien Pinckaers
> CEO OpenERP
> Chaussée de Namur 40
> B-1367 Grand-Rosière
> Belgium
> Phone: +32.81.81.37.00
> Fax: +32.81.73.35.01
> Web: http://openerp.com
>



-- 
Sharoon Thomas
Business Analyst & Open Source ERP Consultant
CEO @ http://openlabs.co.in

References