Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: The future of OCB → fork and consolidation
by+1 for Christophe number one point.
In our case we came from work with Drupal for several years; one of the most powerful concept on Drupal is the Distribution one.
Distributions are full copies of Drupal that include Drupal Core, along with additional software such as themes, modules, libraries, and installation profiles. That feature itself give community the power to create custom solutions that targets to a very specifically market and build a business around that work while keep collaborating with community.
At this moment what is preventing us like a community to follow
same model is that installing Odoo means you bring to your project
not only odoo base but also all other modules for god and for bad.
And, as Christophe said, many times it's a really bad idea to
relay on Odoo modules for provide a long term solution.
In the Drupal world is Aquia, the enterprise own by Drupal founder, who plays same role than Odoo SA for Odoo world. Aquia have developed its own Drupal distributions for work at big corporate projects while keeps cooperate with community to develop an stronger Drupal core. There have been several smaller enterprises that have developed other distributions and there are plenty of work for everyone.
Really I believe that if OCA takes the role to organize and leadership an Odoo base project that allow us create our own distribution, the community could explode as there is going to be more business opportunities for everyone.
My 2cents
I'm totally in favor of pushing forward the idea of a
replacement project, divergent branch, separate work, or fork,
name it as you want! I even think this work should have been
done at least one year ago. Below is my own vision, maybe
similar to what's Stefan is tasking about.
I feel like the current state is : we have a less and less
useful OCB branch, base on a less and less useful Odoo Community
stripped down version. If the community wants to offer a viable
open-source version, both for integrators and developpers, I
believe we need TWO things :
- First of all, we need a separation of the core
framework from the addons. History proves me that it is
dangerous and not durable to heavily extend the standard
addons for a given project. For many totally custom projects,
we can use only the framework and almost zero addons, then
accasionnally plug on the standard addons on a very limited
way, for example to handle invoicing or other common needs.
The fact is there are plenty of framework improvements in the community addons. For example :Sentry integration, PG LargeObject, colorpicker widget, boolean switch widget. I believe it's a pity to keep most of these addons as separate addons. They are lost in the wild. They are not very visible, often poorly documented, and mainly they are not available by default. Other possible improvements include a refactor or rewrite of the system of permissions, rôles, and groups (or a rename of groups as roles, what they really are since the beggining, and an implementation of real groups, in the common sense.). Another long lasting need: an alternative responsive web skin *by default*. Not as an addon!
So as a summary the community whould publish the framework alone, without any addons except the base ones, as it is very useful for itself, then fork it, and enrich it with all the improvements already found in community addons, with a strict and documented way of selecting the relevant ones. - Second optional(?) thing : as more and more addons are proprietary, the community tries to compensate the holes of the community version with community addons. I think the second work to do is to select all the most useful ones, and merge these community addons into the standard addons of the community version (OCX or whatever name), so that they are available by default, and that the whole can finally be considered a final product by itself, and not a limited subproduct.
I would be ok at least with only the first point, so that the
community can base its work on it by default. Then the second
point is actually optional : instead of a unique consolidated
set of addons, it could be done separately by many integrators
as separate distributions targeting specific usecases or
countries. IMO the most important part is to keep a unique and
improved underlying framework.
Christophe
Dear OCA collaborators, as a follow up to the lightning talk at the OCA codesprint today, let me expand on my ideas. The OCB project (https://github.com/oca/ocb) was created in a time when Odoo itself was a lot more unstable and many core bug fixes needed to be included in a production instance. It was a feast to collaborate with the OCA community to share the effort and enjoy the benefit of each other's fixes. Nowadays, there is a lot less interest in the project. Not a lot of PRs are proposed, mainly I feel because Odoo itself is a lot more stable, and smaller changes from the community are adopted more quickly in the core project. Meanwhile on OCB, not a lot of reviews are being posted either and some of the PRs that are still being proposed are not valid against the policy of stability, as they would create incompatibilities with Odoo (defined as: does a change allow the creation of community modules that are compatible with OCB but not with Odoo or the other way around). It thus seems that the OCB project outlived its usefulness. My suggestion would be to freeze the OCB project: no branch for 10 will be created, and no more merges will take place on the existing branches. We can still keep merging the upstream changes to the existing branches as a form of limited support. This would free up some resources for a replacement project. I would be very interested for the OCA to host a version of Odoo that does allow for more radical changes to the Odoo core. Currently, the ideas in the community on what could be improved in the Odoo core just get lost, because Odoo SA is not very open to them, and neither is OCB. I would like to see what the community members come up with, and see if this leads to a more vibrant project. Some restrictions would still apply of course. If an improvement could be made in a separate addon, there would be no reason to include it in the project. As a part of the project, we would have to think about managing dependencies, as it might be the case that community modules are created that are only compatible with this new version (or worse, when incompatibilities are introduced that break additional modules). We would also have to think about clearly documenting the changes and providing an upgrade path to later versions of the project. Please share your thoughts on the topic. Regards, Stefan -- Opener B.V. - Business solutions driven by open source collaboration Stefan Rijnhart - Consultant/developer mail: stefan@opener.am tel: +31 (0) 20 3090 139 web: https://opener.am
_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe
Reference
-
The future of OCB
by Stefan Rijnhart <stefan@opener.amsterdam> - 04/10/2016 15:52:06 - 0-
-
-
-
-
-
-
-
-
Re: The future of OCB
byClosingAp Open Source Integrators Europe, LDA, Daniel Reis- 19/10/2016 20:18:13 - 0 -
Re: The future of OCB
byClosingAp Open Source Integrators Europe, LDA, Daniel Reis- 11/10/2016 13:10:06 - 0
-
