This document explains the development process for OXID eShop so that third-party developers can better coordinate their efforts and cooperate with us on enhancing the eShop eCommerce system.
You will learn in this document
- How the development roadmap is created (i.e. what’s going to be implemented)
- What the steps towards a new release of OXID eShop look like
- How you can obtain the final results
Criteria for Decision-making
When developing software you have four factors to consider when deciding upon the roadmap for a new product version:
It’s like a self-contained system with four hydrostatic heads. If you press one down, some or all of the others go up to compensate. You can prioritize some, but you cannot prioritize all four factors. Let’s discuss each of these four factors
- Costs: There is currently a fixed team of programmers working on OXID eShop. Thus, costs are linearly connected to time. The more time it takes to implement something, the more expensive it becomes.
- Scope: If we add more features, it takes more time to implement them. Reducing features leads to an earlier release date.
- Time: Time is connected to scope and costs. We could add some more programmers to save time. Of course this doesn’t work perfectly. You cannot do a 1000 man day project with 1000 programmers in one day. This would increase costs by factor of 1000 without accomplishing any results after this one day.
- Quality: It’s possible to save some time by reducing quality. Simply not doing any tests is the quickest way to a release. Of course, nobody would trust a piece of software that is not tested at all.
So which of these four priorities do we want to focus on?
Costs are fixed for now. Time is always short and near zero and quality is not a subject we are willing to compromise on, so there is only one factor which is variable: scope. Selecting the right things to implement is an important task. Some criteria to consider:
- Best software quality is valuable for shop owners only if it helps to increase their turnover
- Implementing new stuff which nobody needs is waste of time and resources
- Having quick releases which do not offer valuable new inventions or improvements is worthless
Issues and Stakeholders
There are various types of development tasks as well as expectations from various stakeholders that we take into account when defining a new roadmap:
- Bug reports: Bugs are no subject of debate. They will always have very high priority and will be fixed continuously. We reserve a portion of the development team’s time every week for this.
- Feature requests: After bugs, we focus on feature requests, the most valuable source for community’s wishes. On each release we take the most wanted features and implement them into OXID eShop.
- Partners and end users: Our partners and their customer projects also tell us what’s needed out there. “Partners” in this context means solution partners as well as strategic partners such as Zend. Bringing their products together with ours to make the combination of them more than just their sum is our goal.
- Sales: Sales people and requests they collect give important jump-starts for further development, of course.
- Vendor: Still, OXID eShop is a vendor-driven product. This means on the long run we need to define the path it takes. Such strategic decisions will be made by OXID eSales and we will continue to invest in research and development.
Everything we start goes through this chain of stages:
- More detailed concept
Of course not all features are given equal time in each stage. Something like a new frontend needs much more time in each stage like a tiny one like base pictures.
Depending on the size and complexity of planned features, it might happen that some very important new request needs much longer to provide than smaller ones. Let’s take the above example of a new fronted versus base pictures. Even when both are started at the same time, the tiny one is ready to ship much earlier than the bigger one. So prioritizing just helps us decide when tasks are started, but not necessarily when they’re finished.
To understand our patch and update cycles, first let me define some terminology:
|Term||Sample version number|
An OXID eShop patch usually contains a number of bug fixes. Except for important bug fixes, we usually don’t do any template changes in patches. This makes your life much easier when patching an existing OXID eShop.
A minor release contains bug fixes and also new features; which usually come along with some template changes.
A major release contains bigger changes in architecture, back- or frontend or programming internals – or all of them.
In the future we will do approximately one major release per year and a minor release about 3 – 4 months later. Patches for the latest version of OXID eShop will be supplied monthly. As we’re basically able to release at any time, for patches it takes just the decision to release.
OXID eShop Version 5.0 will appear in 2012. Starting with version 6.0 major releases are scheduled to be released at the beginning of each year.
Regarding bugs, we have pretty few of them. Their number ranges below 100 usually – which is very few for this type of software. Sometimes – when great events cast their shadows before they might even increase.
As with previous version of OXID eShop you will continue to get a monthly patch that fixes known bugs for the current minor release. Extending our maintenance activities, from now on we will also supply patches for the previous version (X.X-1). But patches for previous versions will be released only when needed and not a regular basis. They will not contain any new or additional features.
As usual, you will have two possibilities to update: You can either download the full release or you can generate a cumulative package here. Just pick your current version and you will get one package that will automatically do a complete update to the newest version of OXID eShop for you.
OXID eShop is developed by using Scrum, test-driven development (TDD) and continuous integration (CI) in agile development methodology. There are many advantages to our internal working procedures. This enables OXID to release a patch at any time and automatically test the software. As a result of this automation, every release is fully tested and automatically built into a software package that simply pops out of this process.
Now that you know more about our release process, you can better understand how we prioritize new features, and what to expect in terms of updates to OXID eShop. If you would like to contribute code to our development, we strongly suggest first coding an extension and posting it at OXID eXchange.
By requests of the community, we introduced open beta tests for minor and major releases.
A beta is intended for the developers community and our solution partners to check out new upcoming features. Everybody is welcome to check beta releases for bugs and to report them in our bugtracker.
It is explicitly not intended for productive use! There will also be no update or patch packages from older versions of OXID eShop and no update or patch packages from a beta version to a newer or stable one.
Find more answers in the Beta Release FAQ.
You can learn more and ask questions about OXID development on our mailing lists.