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 _______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
