Every one of those copies has to be maintained, and since they are copies, each one has to be handled independently. You could argue that the savings in development offset the additional costs of maintenance, but if you did, you would be arguing for the wrong side. When you consider that, over the full lifecycle of any given piece of software, anywhere from 75 to 95 percent of the total cost of ownership is expended in production maintenance and operation, it isn't hard to figure out that the key to cost containment is not founded on reducing development costs at the expense of increased ongoing system maintenance.

In fact, quite the opposite is true: to contain total system costs, spend more on development to reduce the need for future maintenance.

Cloning programs and systems is not software reuse
When you clone a software module to create another for your own purposes, you are in effect reusing some portion of the original product. You are not, however, practicing software reuse as the term is generally understood. True software reuse occurs at the object level, not at the source level.

In order to fully reuse a software component, you need to be able to execute it again and again, not compile it again and again. By its very nature, cloning involves handling the work product, and once you alter a proven software artifact, it is no longer a proven software artifact. Every time you clone something, you create an untested component that introduces a new opportunity for failure (aka maintenance!). On the other hand, every time you reuse a software artifact as is, you are validating its functionality.

Cloning, therefore, reduces reliability while true software reuse increases reliability. This is a very important consideration, particularly since the amount of required maintenance effort for any given application system is directly proportional to its reliability (if it doesn't break, you don't have to fix it!).

Don't clone it -- share it
Sharing may be easier said than done, but it is definitely possible, and in fact, quite desirable. When you have similar-but-different requirements, the first thing you need to do is separate the similar from the different. Dealing with the similar is easy. If it is, in fact, doing the same things, then just use the same component. That's just basic software reuse as it was intended. For the different, there is a little more work involved.

The first thing you need to look at for those things that are different is why they are different. Is there a valid reason why one has to work one way and the other another? Maybe there is an opportunity here to start doing things consistently and share the same approach. Like a pesky little kid, you always have to be asking that question: why, why, why?

In fact, for just about everything in which you get involved, if you always try to find the root answers to the following three questions, you will be amazed at how that changes your approach to whatever the problem happens to be: