March 2013 Roadmap:
For a long time I have avoided writing a roadmap, the problem with a classic roadmap is the perception and expectations of the reader.¶

A roadmap implies that there are deadlines, and that tasks are resolved and completed at a specific time with community contributors following and working on each roadmap task one by one, however, this is not always the case; some tasks can be done in parallel, whilst other tasks and objectives have to wait until previous tasks are completed, before they start.

But in our case it’s completely different, when I started with VirtueMart with Sören as leader, the team expectations were based differently, the moment we tried to do it the conventional way, the enthusiasm and motivation of all involved quickly dropped to the detriment of the project, the reason for this is that VirtueMart is a free project, and people want to work on their own ideas, which motivates them (or pays for their time).

However when we hoped to complete a task at a specific point, we found this is not always possible as contributors and members needs and goals change, and this in turn results in community demands for another feature, that we are not yet working on, 3rd party developers cannot always jump into the breach, because they thought, we will add it to the core soon, and then on the other hand, we have tasks scheduled in the future, when suddenly someone posted the snippet to the forum.

Whilst it is excellent that the community solve problems and create features for their customer and then distribute it to the core, this makes the roadmap very fluid and hard to be specific to dates, also this means people are not following the roadmap, as their contributions are inspired for other reasons and when contributed, change the roadmap constantly, so a roadmap must be considered more of an estimation, a vision.

In conclusion it is right that people understand VirtueMart to have a fluid roadmap which lets people know what is coming and a rough estimation of time and what they can expect in the future.

3rd party developers should also know that we usually do not implement plugins and features which already exist as an extension, and is reasonable priced. This helps the community in a number of ways, firstly by allowing us to develop other areas of the core and secondly, we take care that we do not destroy the business of our partners and contributing developers. If you have a question about this please contact us to find out if we developing something you are working on.

Already done for VirtueMart 3
- rewriting of customfields
- reduced sql for customfields ( drops by 80%).
- rework of the cart, lesser redirects, lesser session memory, more secure
- compatibility with joomla 3.3
- enhanced userfields, remove of the tos checkbox, exchange against new userfield (required in cart)
- Fallback for multilingual store to the main language
- Product pattern examples (sell your T-shirt, sell your mp3, sell your book, ...)
- compatibility with joomla 3.4
- separate shopperfield language keys in an own file
- more layouts to choose for example multiadd of childs
- FE product editing / creating new
- fixed stocking (when shopper buy simultan)
- merge of the stockable plugin and the dynamic childs. (is now Multivariant)

Planned
- customfields, option to set a param per product or per customfield prototype
- price settings per view
- Pluginsystem (BC)
- xml exporters for tax

- List of VirtueMart extensions in the AIO component for installation/updating/3rd party licenses.
- Auto resizing main image, with watermark
- enhanced image chooser (multi upload)
- option to display a sign for a minus or not

VirtueMart 4
- bridge for Wordpress
- rewrite of the calculator using rules as objects