Software development for software products shares all of the opportunities and challenges of software development in corporations with a few majors quirks all of its own.Â One of these is the issue of managing a code line for a single product while accommodating (or not) variations for specific customers.Â If you are working or have worked for a software product developer, you will be familiar with this problem. Essentially, the easiest, cheapest and most efficient way to maintain a software product is to have a single code line with all clients on the same, latest version.Â In this ideal model, any defects can be fixed in the single code base and provided to clients in the next maintenance release (maybe with a short-term patch to get over any short-term delay).Â This model is illustrate below: At the other extreme, different clients for a software product each have different versions of the software in production with differing levels of maintenance releases and patched loaded.Â Many of the clients have their own special customizations to the code some of which overlap with the core product code. A simple example of the challenges is illustrated below: Many software products will acknowledge more complicated scenarios than this.Â Over the years, managing these scenarios has been made slightly easier by more sophisticated configuration management software which manages code branches and code line re-mergers.Â That said, such systems still require a level of discipline comparable to the complexity they offer to manage and it is crucial to remember that some code branches just cannot be "automatically" re-merged. If it is so difficult to manage code branches, why do software product vendors allow or even facilitate the branching of the core product code line?Â The following drivers are all relevant:
- New software product releases of any kind require effort from the clients to acceptance test before loading intoÂ production.
- A big license deal requires some updates to the product that are needed before the next release will be ready so the software product vendor creates a custom version for the "special"client.Â When the next release comes out, the client is in the middle of configuration and implementation and does not want to take the new release.
- There is pressure on software product vendors to provide minimal patch fixes to a clients specific problems to avoid the need to load maintenance releases which fix every clients problems.
- All clients believe that they are unique and need changes to software products to reflect their specific operating methods (instead of changing their operating methods to suit the software).
- All clients understand the long-term costs of customizing software products and so strive to stay on the core product line without necessarily loading every release (Why load a new release if WE don't need the new functionality or bug fixes?).