1. Mailing Lists
  2. Contributors
  3. RE: New Repository for EBICS

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: New Repository for EBICS

Avatar

RE: New Repository for EBICS

by
Noviat sa/nv, Luc De Meyer.
- 30/05/2018 12:08:02

Daniel,

 

Of course I agree with this principle but the execution from a practical standpoint means adding a layer of complexity to refactor the current code so that it can work with multiple libs.

This means work (requiring resources & funding) for a less functional end result, hence a good chance that nobody will use the ‘less functional’ module and hence nobody will invest in getting it up to the same level as the more advanced one.

 

An alternative is to promote the current module via the OCA which I hope will result in a more widespread use than today.

Once a module has a widespread usage it will be easier to raise funds and resources to migrate to a full open solution.

 

I am not sure if aurelien dumaine (who already did some work in odoo on ebics) is following this discussion and what his idea is on the estimated workload (I think it’s a lot of work since the EBICS specs are complex, evolve constantly and there are many options/flavours  but I may be wrong). Is he still active within the community (the last update on his ebics module seems to be in 2015) ?

 

Regards,

Luc

 

From: Daniel Reis <dgreis@sapo.pt>
Sent: Wednesday, 30 May 2018 11:17
To: Contributors <contributors@odoo-community.org>
Subject: Re: New Repository for EBICS

 

Hi Luc,

I checked the license (http://www.joonis.de/fintech/license) and is it definitely is neither free nor open source.
It is definitely proprietary.

Building an Odoo set of modules on top of it, effectively locking them down to this particular vendor, is not appropriate for the OCA, and is not in line with the mission and bylaws.
Also, in practice it would mean that the Association is sponsoring Mr. Thimo Kraemer, at the expense of work from other open source contributors.

If I understand correctly, the reason for this dependency is because, while there are opensource alternatives, they cover "basic" features and the proprietary dependency provides relevant "advanced" features.

That path is can see to bring this work into the OCA is to break the repository in two.
The "basic" features would be under the OCA umbrella, and depend on open source libs only.
The "advanced" extensions, using proprietary libs, would live in a repository outside the OCA, but referenced in the OCA docs.
Ideally the open source libs would gradually evolve, allowing for features to gradually move from the "advanced" repo to the OCA "basic" repo.


Would this plan be reasonable?
 

--
Regards
Daniel

Reference