openerp-community team mailing list archive

[Fabien Pinckaers <fp@xxxxxxxxxxx>]

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.

-- 
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