Features from the xrg dungeons

This series of articles aims to guide you through a set of pending features for OpenERP. Some of them are experimental, some more mature, some need to contain their maturing process... (read more)

Monday, February 27, 2012

F3, a little closer

Conceived: 2009
Implemented: 2009-2011

An open-source project cannot live, nor thrive under a stubborn governance of a single vendor. No matter how nice the sales figures may be, the diminishing  community participation in OpenERP has always been a concern.

Plan A has been to convince the heads of OpenERP SA that open-source is their greatest asset, and would only remain so if they learnt to respect the open-source principles.

Now, we are at plan B, which is to evolve this project in a community-led governance model. So far (because I'm not a marketing guy), the name is "F3" as in "3rd feature branch".
Apart from a wide set of improvement patches that have been developed against 6.0 in the "pg84" and "pg84-next" branches (the 2nd feature branches), the goals of "F3" are, in short:
  • to have an open project, where all contributions will be treated equally (technically bad ones will still remain out!) and all contributors will be awarded for their effort
    Note: this means we could have more than one branch, different "series" of the project depending on debated decisions. It is nice to have plurality, rather than a SVN-style "trunk" and stick with bad decisions.
  • to remain compatible with previous codebase, respect the work all of us have done against previous versions. Also, respect our customers which have had wide installations and integrators that invested in them.
  • to have scheduled, predictable releases. A sane release cycle with feature windows, testing periods, release + integration hold-off time. Features shall be predefined, too.
  • to be stable. To be business-minded (ERP users expect a rock-solid system, not marketing fireworks).
  • to be frank. Open-source is supposed to be free of marketing b**hit. No demo-quality features, only ones that can really stand in production. If we have a bug, we admit it and fix it.
  • to be efficient. Both at the final product (pg84-next is already >40% faster than 6.0/6.1) and the way we develop it (right tools, debugging, tests, communication)
So far, some of you may have discovered the branches of "F3" series that are already out. That code is just the beginning, and a proof that this project is alive. More important are all these flags in my mailbox, "lost" commits that all of you had done against 6.0 and got ignored in the bzr series.

A set of design innovations and technical features of F3 is yet to be written (you know, documentation is that last task we tend to avoid :S ).

Why not Tryton? I get this question often. It has to do with the codebase, which departed from the Tiny API, back then, and would require major porting (and lack of features) from any current TinyERP/OpenERP installation. Still, their work and community model is highly appreciated.

In June 2010, in G-R, I said I would make OpenERP (6.0, then) a better product. My plain word is stronger than some who don't honor their promises (see: release date, features+support, payments).

Let the code speak for itself.