Newsgroup: comp.software-eng

Karim Ratib wrote:
> A recurring problem we face at work is that of keeping up-to-date with
> open source applications, while customizing them to fit our clients'
> needs.
> 
> Our software delivery strategy is simple: given a customer need, find
> an open source Web application (or a mix of several ones) that most
> closely fits the need, then customize it into something the customer
> can use. Typically, this involves several changes to the original
> codebase:
> 
> 1. Graphic design and usability changes
> 2. Database model changes
> 3. Business logic additions
> 4. Workflow and security additions
> 5. Data migration and pre-population scripts
> 
> So what happens is that we fork a new branch of development on the
> system to suit the evolving needs of the customer, fix the bugs, add
> new functions, etc. while the original open source system is evolving
> outside of us, assumingly towards a more desirable state of
> correctness, functionality and reliability.
> 
> The problem is that to offer support and maintenance to the customer,
> we need to be able to update the system to the latest external stable
> release, in addition to executing customer-specific change requests.
> This is an error-prone and rework-full process, and we usually end up
> freezing the customer system at some snapshot of the external one,
> instead of upgrading it, to focus only on the customer-specific
> changes. In effect, we return to a closed-source development model at
> that point.
> 
> Is anyone here practicing that sort of development? Anybody cares to
> share their experiences or offer pointers? I feel Brad Appleton's
> configuration management pattern languages
> (http://www.cmcrossroads.com/bradapp/acme/) might help, but they're a
> mouthful and very abstract :-)

- Try to minimize the customer-specific changes.
- Avoid source code changes, concentrating your changes to configuration 
files that don't change between versions.
- Submit source code changes back to the corresponding open source 
project.  Hopefully in the next release you won't have to integrate them 
again.
- Try to change as few files as possible.
- Use environment variables to customize the makefiles for your and your 
customer's environment
- Use a version control system, like CVS.  Put the open source version 
in a "vendor branch", and commit your changes from that point onward. 
When a new version comes out, create a new vendor branch and apply to it 
the changes from the previous vendor branch to your current state.
- Select open-source systems that are mature and stable.  If a stable 
branch is actively maintained with security patches adopt that one, 
instead of a the bleeding edge development branch.
- Use open-source systems that are easy to configure and upgrade.  For 
example, FreeBSD comes with a mergemaster script that will merge new 
configuration files with their locally-applied changes.

I've used a mixture of those approaches over the years, and the outcome 
sometimes beats the upgrade path from some closed-source offerings.

-- 
Diomidis Spinellis
Code Quality: The Open Source Perspective (Addison-Wesley 2006)
http://www.spinellis.gr/codequality?cse

Unless otherwise expressly stated, all original material on this page created by Diomidis Spinellis is licensed under a Creative Commons Attribution-Share Alike 3.0 Greece License.