First of all, let me say that it is good to reflect on the roadmap again. This should be done at regular intervals. Secondly, I feel that this thread should have been initiated in the other mailing list. Though many may follow this mailing list, not all do. Discussions regarding vision and roadmap should involve all members of the community. Thirdly, I feel its a pity that many of the PMC and Committers don't jump to the gun to share their opinions, visions and insights regarding the future.
Apart/beyond the above I herewith share (some of) my thoughts on the more technical topics the roadmap for 2014 and beyond should address. I agree with Adrian and Jacques on the subject of CMS. Transformation of OFBiz to solutions like Drupal et al is not needed. However, these solutions have an evolved set of functionalities in order to integrate components/plug-ins/add-ons, whether they are in the area of themes or bespoke solutions like payment and shipment processors and others. If I am correct, solutions like the big-fish (by Nick Rosser and his team) , and the add-on manager (in Apache Extra - by the people of Nereide) are steps in that direction. Maybe we can learn from these and others and expand on them. *Re: slimdown* The path set in the recent past regarding slim down is a good path. This should be continued. But, slim down should not be about only focussing on the framework. More visibility on the website should be created regarding vision and roadmap. In the past also several apps/components/functions have been earmarked as eligible for slimdown roadmap, but little actions have been undertaken. I believe this has to do with fear. Fear that OFBiz is on a path of self-destruction (becoming a framework-only solution, as seen from the original viewpoint of the project), or - when not in a framework-only roadmap - that there will be a diminished ownership by the project. More communication regarding this issue should be undertaken. As for payment and shipment processors, these all should move from current place in applications (accounting and product) to hot-deployable components (per payment processor, per shipment processor).. This way, each processor can be selected and deployed when needed. It also creates more visibility regarding the flexibility of the system, due to the fact that there are plugins available that cater to customers/users specific needs. Plus it might attract new solution developers to build/maintain these optionals. But that requires more and unified communication. I recently undertook the endeavour to move the iDEAL payment processor from accounting to Apache Extra (see issues OFBIZ-5303<https://issues.apache.org/jira/browse/OFBIZ-5303> and OFBIZ-5443 <https://issues.apache.org/jira/browse/OFBIZ-5443>), and after evaluating the solution I came to conclusion that it is broken/malfunctioning in its current design. While it is a pity that it is as it is, and a shame that it was incorporated in accounting without due-diligence, it is good that it is moved (as part of slimdown). It improves the quality of the base component and makes the solution more accessible. When more specific solutions move this way, the better it is. Perceived quality of the total package is then less defined by the individual component/solution/function (depending of course on the viewpoint of the viewer). *Focus should (also) be on performance, scalability and configurability* Good performance increases the user experience. This involves both Above-the-Line (screen build up - client side) and Below-the-Line (data retrieval, logging, mail processing, etc - server side). Regarding AtL (Above-the-Line) this means leaving the concept that we should only have web 1.0 functionality in components and apply web 2.0 functionality more and more. Good performance also means minimizing the loops to include javascript functions in screens and forms. Think of the date and lookup renderers. Per line in overviews these functions are included whereas they could (and should) be in a javascript file and called from there. Of course, given the number of screens and forms in all the components this means a lot of work, but Rome wasn't built in one day either. Regarding BtL (Below-the-Line) this means more (better?) scalability functions, but also configurability of where and when functions and processes should be executed. Of course, this is related to multi-server setups and multi-tenancy implementations. This should also include deployability on external servers. This seems to be broken and outdated. Regarding configurability I see that we currently have over 1200 configurable properties in .properties files. Some of these are used for startup, some for development, some for deployment and some for testing. And there are overlapping situations. But the majority of the properties are to be used in production environment. In single (internal) organisation, single tenant (default) and single server setup this is ok as it works. But in a multi (internal) organisation, multi tenant and multi server setup this is inadequate. In such scenarios the default values on user, organisation and tenant level must also be set and act like in .properties files act like failovers Properties like accounting.payment.salesorder.autocreate, finaccount.decimals, java.naming.provider.url (for ldap configuration) and eventReminders.emailFromAddress, to name but a few . Though I haven't gone through the entire list extensively to date and Adrian stated in a comment regarding issue OFBIZ-5458<https://issues.apache.org/jira/browse/OFBIZ-5458> that several (property defined) values are retrieved from database as an override to the property definition, but where it is done is ambiguous and un-clear. In my opinion this should work as follows: 1. retrieve from user preference, with failing over to 2. retrieve from organisation preference/setup, with failing over to 3. retrieve from tenant preference/setup, with failing over to 4. retrieve from .property file I believe this should be taken up, thus ensuring that it get clearer where and when a value is retrieved. Ensuring also increase of quality and decrease of ambiguity. *Re: maintainability* Over the past year several add-ons have been included in Ant build functions to use Apache Ivy as the engine to download jars required by specific functions. E.g. for PostgreSQL Activemq, Cobertura and Sonar. This should be expanded more, as it lessens the burden on maintenance and size of svn checkouts and distributions. Given that always a build phase is required when having downloaded OFBiz, this build phase could retrieve the jar (and other) files required. Using Apache Ivy more, could also circumvent the licensing issues regarding external products, as none of the external products are actually included in distributions. *Re: integrateability* With regards to integration with other solutions I would like to see the uptake of a solution like Apache Shiro regarding authentication, authorization, etc. Especially related to multi-tenancy. In general, the pool of solutions in the Apache Marketspace (top level project, etc) is vast and I would say that there are plenty that could be integrated with. And we already re-use a lot of functionalities of other products. But this could go further. Regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com
