openerp-community team mailing list archive

[Georges Racinet <gracinet@xxxxxxxxx>]

Hello Fabien, some thoughts which I hope you'll find to be constructive.

Sorry, this is a bit long, and convoluted but I can summarize it as a
plea for deeper
cooperation and volunteering myself to common efforts in the packaging /
deployment area (ideally in the form of sprints).


On 05/30/2014 08:09 PM, Fabien Pinckaers wrote:
> No, nothing change in our strategic focus. Check the blog about the
> announcement: https://www.odoo.com/blog/1/post/156#blog-end We do 82%
> of our turnover with partners that are mostly targeting mid-size and
> big companies. We do also have small companies in the SaaS offer, but
> that's not the main focus;

Then, maybe is this a good time to work in a more tightened way with the
partners that express needs [6] in packaging / deployment which are
typical of this segment ? More on this below…

(...) skipping discussion on front / e-commerce and the switch to Odoo
brand (...)

> The great thing about open source is that every one is free to do
> whatever he wants. If you want to stick to your own version 6.1 fork,
> that's fine.

As a side remark, this is what we have to do anyway sooner of later for
those clients that are wary of upgrades, and this goes far beyond the
world of OpenERP (saw that with any piece of complex software).

> Freedom is what makes open source what it is.
>
>
> But why don't you develop your improvements as community modules,
> instead of hacking the core and maintaining a branch that is not
> compatible with the official release?

At Anybox, we're doing both modules to alter core functionalities and
divergent [1] forks,
the latter because some stuff is more maintainable as a small diff
managed by a DVCS [4] than as a module that has to copy hundreds of line
of code to change one tiny local behaviour that we know would not pass
the OCB criteria and would end up in lengthy sterile debates in the
mainline that we can't afford. It's true that consumers can be
screaming… sometimes in despair.

Getting back to the dev-ops, since it has somehow become my speciality,
there are lots of shortcomings about that in the current state of the
software. I'm under the impression that many things are done in the sake
of simplicity of initial deployments, and to support the "apps" model,
and have *no problem* agreeing that this is crucial for adoption. But
mid-size to enterprise or large administration, maintainance and
exploitation in these contexts often require a different class of tools,
which should not be impaired in the process.

> Every time I saw someone doing a fork not compatible with the official
> release, this led to high frustrations after a few years. (for partners
> and customers) And it often starts with a blog like yours: criticising
> the official release to promote your own branch of development.
>
> So, please think about it twice. Check if you can port your
> customizations as modules.
> The new web client allows to do everything as a module. So, it should be
> feasible without too much effort. Your contributions would be much more
> valued if they were available as community modules.

I believe that encouraging modules for core improvements as you just did
above is a bit contradictory with some opinions you expressed in the
past or some requests that got ignored.

I also believe that this created lots of frustration in the community,
that maybe you underestimated. As a result, you get screaming instead of
proper, constructive feedback. Worse, sometimes legitimate, reasonable
requests get voiced by screaming fools first, and I know what my
reaction to them would be.

It's natural that a successful free software gets uses that are
different from its originators way of thinking. It's healthy to
incorporate or at least try not to impair such developments. Really good
things can come of it, as the environment changes fast.

With such tools as the buildout recipe, we can [2] isolate the hacks
needed to circumvent most of these packaging inconveniences, but it'd be
better for everyone (not only buildout users) if we could cooperate a
bit more on packaging topics and related issues. Just imagine how much
energy we spend that
does not benefit OpenERP/Odoo [5] in a direct manner ? Yes, some things
will always stay external,
it's just so much better if we can agree on it, get the minimal entry
points to build them, and issue clear statements.

There's probably not so much to be done to accommodate whatever your
priorities are with the wishes of the community. Coordination can make
both compatible rather easily, and everyone happier at the end of the day.

I believe that working physically together can't be fully replaced by
pull requests. What can you do of a pull request that changes some
bootstraping stuff without prior, serene concertation ?

Hence if you'd hosted a sprint on packaging & deployment, geared towards
the flexibility and safety that partners such as Anybox need, I'd come
flying ! [3] I don't know the people working on installation by pip
(hope to have interesting discussions with them next week) but I suppose
they would be interested as well. I realize this is requesting precious
developer time on your part, but we'd devote some of ours too.

I sincerely think that this would really help Odoo to thrive

Hope to have a chance to talk with you next week

Regards,

[1] compatibility is a relative concept. Is a conflicting branch really
incompatible ? Depends how much and how obscure
[2] not saying that we did in all aspects, I'm merely thinking of what
more we could bring with it
[3] loved the one on unit tests
[4] We have thorough CI bots merging from upstream. A merge conflict
would be in itself an early alert, and of course nothing replaces a
carefully thought unit test.
[5] For the record, I have no problem with Odoo myself, just also
thinking of the installed OpenERP base that needs maintainance today,
tomorrow and maybe the day after again.
[6] some of these needs can be related to environments that are forced
on us.

-- 
Georges Racinet
Anybox SAS, http://anybox.fr
Bureau: 09 72 39 50 97 / 09 72 39 13 06
Portable: 06 51 32 07 27
GPG: 0x33AB0A35, sur serveurs publics