Monthly Archives: January 2011

Considering Run Time and when to release source code

I remember once working on a project where the goal was to recreate some functionality that was provided by a custom-built database application. Unfortunately since that application was delivered to my employer in an executable form,  there was no way I could get in and inspect or modify the code. Owing to that experience I’ve favored providing the full source code mdb or accdb to my customer’s.

If a customer pays for a new database application by all means make the source code available however they want it.  Most organizations need the source code and should have it. Especially more sophisticated organizations with in-house programmers. Even if an organization has no programmer’s they can easily hire expertise.

Since I recently downloaded and installed the ms-access 2007 redistributable and ms-access developer extensions I’ve given the matter more thought.

As a developer, by delivering your product in runtime you ensure your work cannot be changed or modified by the customer. You can prevent the customer from self inflicted harm and ensure they use the version you intended.

Does the customer gain anything by only using a runtime copy? Yes, if they keep only a runtime version then they do not have the burden of maintaining and protecting the source code.

Think about it. If a customer wants to keep the source code, they must devote resources to securing it and storing it properly. Additionally, the source code is potentially kept in more than one location (developer’s office, customer’s office, backup storage location). The extra management costs of maintaining keys used in encryption must be considered.

This is why source code escrow agreements made between customers and software vendors are sometimes used. I once worked at an office that had this type of arrangement. The tapes of the source code were kept in a safe deposit box at a nearby bank. It was agreed that under some circumstances the customer could obtain this source code.

In such escrow arrangements, the developer or vendor provides a runtime version to the customer, but an escrow agent is hired to maintain a recent copy of the source code. In the event of some circumstances, such as the vendor going out of business the source code is released to the customer.

Why is this better? Well, for one,  the source code is only in one place and its easier to protect. Secondly, it reduces the chance of improper changes to the program because customers do not have the option of attempting to make changes to the application. Customers should not attempt such changes on their own unless they are very familiar with the workings of the program and are willing to accept the risk. The risk in terms of money spent and potential time lost should dissuade customers from attempting such changes. This is why having a runtime only version might well suit an organization; they are prevented from assuming such risks, in essence forcing them to place it safe.

In terms of best practices, what is a developer to do when you release the source code and how best to do it?

1. deliver encrypted source code using strong encryption

2. Agree the customer will not store the code in a usable form (except during testing, temporarily) and protect it

3. Clarify the source code should not be used as a running program

4. Customer should use only executables generated by the developer

5. In the event the developer no longer supports the application it is understood the customer may use the source code as needed.