openerp-community team mailing list archive

[Ovnicraft <ovnicraft@xxxxxxxxx>]

On Mon, Oct 15, 2012 at 3:25 AM, Fabien Pinckaers <fp@xxxxxxxxxxx> wrote:

> Hello Nhomar,
>
> Thanks for your feedback. My comments bellow.
>
> > Said this i proceed to describe our conclusions, because are a little
> > hard and i want to be sure it is all taken in the correct way, BUILD
> > TOGHETHER THE BEST ERP IN THE WORLD.
>
> You are right, this is the only thing that matters.
>
> All our decisions are based on what we think is the best path to achieve
> the best product ever. We sometimes do mistakes, but I think we proved
> our direction is good. (especially if you compare to all others open
> source players)
>
> Some decisions may be good to improve the product (and, thus, for future
> customers) but not as good for existing customers/partners. This is
> where we may have conflicts. OpenERP SA focus on building a great
> product but, in some situations, some community members may have reasons
> to not evolve and protect their existing situation as the change as a
> cost. (in terms of money, time or personal convictions...)
>
> Some example:
>   - doing an evolution of OpenERP which is not backward compatible: it's
>     good for OpenERP when it's a strong evolution, but it's bad for
>     partners that developed modules based on the old model
>   - stop maintaining some bad modules while refocusing to clean most
>     used one. It's good for the product as the most used module will
>     achieve a higher quality but not good for existing customers that
>     where using the modules we do not maintain anymore.
>
> We try to limit these situations (by remaining backward compatible when
> we can) but sometimes it's not possible. Sometimes, we have to make a
> decision.
>
> To limit the disagreement of the changes due to evolution, we invested a
> lot in the OpenERP Enterprise service that helps maintaining OpenERP for
> existing customers (migrations, bugfixes, 4.5 years of warranty, ...) so
> that they are less subject to errors for the change.
>
> As an example, we will still continue to maintain the v6.0 GTK client
> for 3 years as it's guaranteed for our OpenERP Enterprise customers.
>
> > 1.- Fork GTK client is just an option if some points are covered:
> >     a.- OpenERP is agreed in develop propagating the context in all them
> > 200 modules.
> >     b.- OpenERP is agreed with this Fork.
> >     c.- We have some kind of secure way to offer commercial support
> > between community memebrs will be in charge.
> >     d.- OpenERP mantain a minimal backguard compatibility in future not
> > developing gtk client, developing @THinking@ in the existency of this
> fork.
>
> b. Of course, we agree. We will not be against a community effort.  (but
> we will not waste time on it too)
>
> In my opinion, that would be a very big mistake and waste of time. I
> seriously doubt that the community has the time to support this huge
> development and I am pretty sure that if you go into that direction, the
> GTK project will be dead in max 18 months. It's far better to join our
> efforts to make something better rather than splitting our efforts (have
> a look at what happened to Adempiere, they have 4 clients and the
> project is nearly dead as none of them was good enough)
>
> Community and partners should have better priorities like the
> localisation in all countries, porting best modules to v7.0, ...
>
> d. We will not do that. If we decided to drop the GTK client, it's
> because it became an obstacle to the evolution of OpenERP. We want
> OpenERP to evolve quickly in order to be extremely competitive on the
> market and to disrupt the ERP landscape. As I said, our priority is to
> build the best product ever, and we don't want to put obstacles to brake
> this.
>
> So, if you fork the GTK client, you should be ready to adapt everything
> by yourself and not rely on us for this as we will only focus on
> improving OpenERP.
>
>
> > 2.- From a Commercial PoV, i think we are chetting with this decition to
> > our customers, in the last Partner Days, Fabien explicitly said they
> > will not stop mantain GTK client, in 6 month he change his mind, What
> > will i say to my customers? that they will need invest X thousand dollar
> > in re-train +1000 users? if i was SaP it should be for me a good news,
> > but we are not, this kind of moves are the ones make us move from
> > privative to Open solutions 12 years ago.
>
> I apologize as I changed my mind during the v7.0 development. I changed
> my mind because it's better for OpenERP.
>
> The problem with v7.0 is that the required effort is much more than just
> maintaining the GTK client. I was ready to maintain the GTK but OpenERP
> evolved so much in v7.0 that the effort is not just maintaining it. In
> order to make it clean, it requires a full evolution which is a much
> higher effort.
>
> As we don't have unlimited resources, we had to choose between two
> solutions:
>   - develop two client which are both half clean
>   - focus on one client but make it super clean
> We chose the second option. (and I hope the community will follow as
> it's better to join our efforts rather than splitting it)
>
> Don't forget that we continue to maintain GTK for your v6.0 customers.
>
> Also, the GTK/Rich technology started to become a strong constraint that
> slow down the evolution of OpenERP:
>   - Available open source libs are very limited in Python/GTK compared
>     to javascript (gantt charts, many2many_tags, kanban, OAUth
>     authentification, LinkedIn API, ...)
>   - The GTK client is based on a quite old code base and requires a
>     complete rewrite to make it clean.
>   - Modularity is key for OpenERP. Having modules for the UI is not
>     just an extra feature. Don't forget that the success of OpenERP is
>     due to his modularity; we need the same power for the UI to ensure
>     the success of OpenERP in the long term.
>
>
> > 3.- From the technical PoV, is really hard mantain both clients, but
> > this is basically because the leak of openess in some dev process and
> > the leak of SQA, i mean, Today, we have process that don't pass
> > correctly the context (Unique way to work with both clients), and it
> > brings a lot of problems, other thing is, the leak of central processing
> > related to workflows, a lot of thing are hard written and avoid a real
> > centralized part with the business objects, but BTW other history
> problem.
>
> The complexity is in the changes, not in the openness.
>
> The main issue is that OpenERP still need to evolve quickly to reach a
> much higher quality. I understand that these changes are complex for the
> contributors. But these changes are also critical for the success of
> OpenERP in the long term.
>
> If OpenERP is today the best ERP ever, that's because we evolved very
> quickly. We need to maintain this rythm to transform the ERP landscape.
>
> > 4.- I think one of our BEST approach is the fact of have 2 Official
> > CLIENTS, that allow customers have the good part of both worlds (desktop
> > and Web), today all our cleints use both clients, because they are good
> > for @different things@.
>
> Yes, this is today. But tomorrow, everyone will use and prefer the web
> client as it is much better.
>
> Seriously, I do not see any advantage on the GTK client that can not be
> done easily in the web one. May be today it's not perfect but it's just
> a matter of weeks/months.
>
>
> > 5.- About Backguard Compatibility, at least today, we have 2 years to
> > migrate customers to 7.0, it must not be done tomorrow, we have 2 years
> > to convince them that Web is better, BUT, @fabien read very well, This
> > desition is TAKING OFF 50% of usability of OpenERP, 50% of useability,
> > already supported by an OpW, im not talking about community, Our
> > cutomers bought an OPW for Security, Migration and Stability, not to
> > lose 50% of funcionability, and then we must send our Salesman and
> > ourself to convince them that Web is Good. IMHO They Buy Support and
> > Warranty for 2 clients NOT ONE, How do i discuss this argument my
> > friend? (already said by 2 of my customers).
>
> I bet your customers will ask to use the web client as it's simply much
> better in every aspects.
>
> > 6.- About the agument "We prefer mantain 1 very well than 2 bad", Ok, Im
> > agreed, and i respect this Point of view, but the real situation is that
> > you dont have 1 very well, because, the real fact is that we dont have a
> > lot of funcinalities that we had in v6.1
>
> I don't think so. Some feature may be missing but they are easily
> developed as a module. (like tabs)
>
> > I think we need some features ABSOLUTLY NECESARIES in V7.0 if desition
> > is taken to be able to deploy correctly transition.
> > 1.- Menus ala admin menu (Already in v6.1) we use A LOT this feature:
> > http://drupal.org/files/images/Administration-menu.png
> > 2.- Copy and paste to use tree information on a spreadsheet, it can be
> > solve easyly if we include this feature (not with excel with direct csv).
> > You can implement freely as you think is te correct way, but it can
> > replace the copy-paste just neede to quickly pass to excel y/0 OO.
> >
> http://planet.domsense.com/en/2012/06/openerp-how-to-export-current-tree-view-to-xls-use-web_export_view/
> > 3.- Print Screen in PDF, Priority 1.
> > 4.- Print Workflow in PDF, Priority 1.
> > 5.- I have a question: how do replace the easy way you pass with @Tab@
> > key without loss layout in web?, this is important too!
> > 6.- ShortCuts, Priority 1.
> > 7.- MultiTabs. PLEASE dont ask me develop by myself, i have already this
> > in GTK and is your desition take off.
> > 8.- Test the posibility of use ALL the web client without mouse. When it
> > should be possible, you will think IT IS READY!, after impossible, think
> > in people loading thousand of records per day, not just in new ones that
> > will learn quickly.
> > 9.- If you decide just not mantain, create yourselve the fork and put a
> > copy with openerp-gtk-drivers permisions to make it official, give us
> > the power, but i think it is a bad move.
>
> 1. This is very easy in web. (but requires a bigger develoment in GTK)
> 2. probably a 100 lines patch/module for the web client
> 3. The printscreen is better in web as it works for everything now,
>    including form views. It uses an @media css through the native
>    printing of the browser. You can also implement the old printscreen
>    which is probably a 100 lines patch/module for the web client
> 4. Already implemented in the debug mode
> 5. don't understand your question; tabs are the same in web and GTK ?
> 6. Already implemented
> 7. We made breadcrum which is an alternative. If you need tabs, a
>    module is just 100 lines of code.
> 8. Shortcuts are quite easy to implement in web
>
> So, I don't see any reason why we need a GTK. Porting those features to
> the web is probably a 10 days effort while making the GTK evolve is
> probably a 30 man*months effort.
>


Hello @Fabien, in Gnuthink we are totally agree to just support Web, but as
i wrote in a mail before, please we need a better technical documentation,
if Partners & community get this everything will be easiest. Its more fast
include a new developer to read doc instead read the code (thinking in
time), so partners and community needs start to migrate modules.

For all partners an community, we can does better Web development, from
company side is more fast get web developers instead gtk developers and
grow faster.

Best regards,

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



-- 
Cristian Salamea
@ovnicraft