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.

What are the available branch for testing OpenERP v8

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, lifo
• 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

What is the vision of OpenERP about integration and externalization of features?

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 Contact Elico Corp for your OpenERP project and migration to v8: contact@elico-corp.com