openerp-community team mailing list archive

[Antony Lesuisse <al@xxxxxxxxxxx>]

We plead guilty about not communicating enough about the developments going on 
at openerp. We prefer spending more time on fixing bugs and developing 
awesomefeatures :)

As you probably know, EVERYTHING we do is publicly available on launchpad and 
runbot.openerp.com but there are thousands of branches and it can be a maze 
for the layman.

We eat our own dog food as we use OpenERP project management A LOT, with 
kanban views, etherpad and openchatter. Every task contains the links to the 
different branches involved.

We use the following stages:
-Backlog (new ideas or wishes)
-Specification (Functional, technical and usability)
-Development
-Functional and usability Testing
-Code review and merge
-Communication and marketing (manifest update and changelog, blog posts)
-Deployment

Tasks are currently are split among 6 projects:

Three of them are persistent:
- Framework (ie apiculture, new BI matrix/graph)
- Usability and functional improvement (ie gamification, survey, mass mail, 
resource workday in base_action_rules, many many small improvement)
- Platform (our internal openerp, and saas cloud management)

Three of them are temporary (but they might last month or even years).
- Website (CMS e-commerce ...)
- Warehouse (new WMS)
- Point-of-sale (pos hardware + many improvement)

Some important tasks currently in the pipe, (you may ask me any question about 
then but please test it first on runbot)

http://runbot.openerp.com/ find the branch click the arrow next to connect -> 
"All addons"

new calendar + google sync (already merged)

server action and base_action_rule improvement (already merged)

google spreadsheet from openerp data (already merged)

gamification (already merged)

trunk-website-al (will be merged in the next days)
- website builder
- blog engine
- e-commerce
- eventbrite clone
- partner and reference directory
- our team page linked with hr
- job application page linked with hr.recruitment
- new e-mail template composer

trunk-new-graphview-ged (will be merged tomorrow)
- new graphview and multi-measure matrix
- read_group support for group_by granularity like create_date:month/day/week

trunk-quote-roller (will be merged very soon too)
- online quoting inspired by quoteroller

trunk-pos-ugly-but-fast (will be merged tomorrow)
- 100x speed improvement
- hardware support out of the box: printer scanner cashbox
- tablet and mobile support + many bugfixes

trunk-survey2-rim (ETA 1month)
- clone of serveymonkey based on old survey module and website builder

trunk-bs3-jke (ETA 3month)
- css to boostrap3 in webclient
- responsive design from small mobile phone to 4K screen

trunk-wms (ETA 2month)
- huge refactoring using quants
- fifo, lilfo
- many simplification and less code (like removal of some workflows)
- as powerful as SAP (we can now do every SAP use cases)

trunk-apiculture (ETA 3month)
- new api (new fields, no list of ids anymore, no more cr,uid,ids)
- onchange fixed

I know that there is common complaint about openerp NIH syndrome, but i think 
we were mostly right. But first let me share a 4 beliefs i have (and that i 
mostly share with Fabien) on which those decisions are taken. Those beliefs 
are not fixed (as i often change my mind, and he does too).

1. Value of integration in a software system

I don't consider here simple isolated tools but software system where 
different components and features are available.

Like Metcalfe's law i'd like to state the Lesuisse law1 (as i might state 
future laws :) saying that:

"the value of a software system is proportional to number of connected apps to 
the power of the level of integration"

Illustrated by a few software system that i love:

The classical unix toolset, a powerful system combining a lot of commands, but 
they are loosely integrated (only by unidirectional streams of bytes).

Debian distribution, huge number of apps, integration level varies among the 
different packages.

Integrated suite of software like Microsoft Office, Adobe suite, the number of 
apps is less but the integration level is higher.

I also like software where everything is provided inside and works out of the 
box in the functional perimeter, let's call them kitchen-sink software. (i 
cannot use emacs as an example because i don't know emacs). For example 
Blender, facebook, chrome, Ableton live...

Ableton Live is good example, before Live we used to spend our time 
downloading VSTi and VST effects, using different software for midi 
sequencing, sample tracking, instruments with different ui and many windows 
open. Live changed the game, everything is integrated and uses the same 
ui-control you can use midi generated parts, sampled parts, drum-kits and 
effects in seamless way.

I also like when software is generic or multi solution like:

linux - all architecture from embedded to NUMA top 500 computers, every driver
for every device in one source repository.
ffmpeg - all video and audio codec in a single codebase.
mess/mame - all emulators for every computing device ever made.
qemu - cpu translator/emulator for every combination and cpu src and cpu dest.

And of course ERP systems.

2. Internal integration vs. Heterogeneous integration

You may notice that some great programmers (fabrice bellard, john carmack, 
linux torvalds... there are many more) like to keep dependency list small. You 
may say they suffer from the NIH syndrome, but from their perspective it might 
make a lot of sense.

But first i would like to make a distinction between two ways of integration:

Internal integration is when you call a linked library or you copy code, ideas 
or patterns from an other system. They run in the same memory space 
communication is done by function calls using the same datamodels and types 
and they don't run asynchronously. You keep them under your executive control 
and make them abide your rules, design and architecture.

Heterogeneous integration happens when you interface an other system using a 
different platform, framework, datamodel or type system, when it's located on 
an other computer or simply in an other process on the same machine. Example 
microkernels vs kernels.

And this is hard, achievable but very hard, so the cost of such integration 
has to be balanced against internal integration even if it means duplication.

Especially when the protocols are complex. UDDI WSDL SOAP those three acronyms 
should suffice to inspire feeling of fear, revulsion and hate to any sane 
developer.

We also have to consider the user experience, a visible switch from one to 
system to an other is always a painful experience for a user.

We try to balance those aspect when we take a decision. I also think that 
duplication is not that bad, and that nothing in itself is complex (even 
advanced tools), usually it's the integration of those things that are 
complex. For example i've heard that john carmack always start his projects 
from scratch.

There are exception of course, things can be easier with HTTP and JSON as a 
common protocol and data type system. Sometimes we are forced to do it like 
rpc between the browser and server, or between postgresql and openerp.

Heterogeneous integration modules were always low quality because it requires 
a lot of work: webdav, document_ftp, caldav, import_sugarcrm, auth_openid, 
event_moodle... so we like to keep a minimum of it.

I also hate unnecessary dependencies, in practical terms i like to limit the 
dependencies the python libraries available in the latest Debian edition. We 
include some js libraries but i like to keep those as minimal as possible too.

3. KISS

4. Only fools and dead men don't change their minds.

The strategy of openerp is to provide efficiently the best integrated business 
application system, both for its end users and developers.

Antony Lesuisse
https://twitter.com/antonylesuisse