Estimating the real value of source code
Thursday, October 13, 2011 12:16:11 PM (GMT Daylight Time, UTC+01:00)
If you run a software development company of virtually any size, you've no doubt been asked/bullied at some point for the source code; sometimes it's even stipulated as a requirement of the contract.
At The Site Doctor we don't tend to quibble over the source code (especially not for standard websites at least) and that's mainly because we know that the value of what we do isn't in the files of code themselves; instead the value is in our knowledge of you, your product, your requirements and our past experiences in our respective areas of expertise.
Putting to one side for a moment the knowledge gap (this can be filled over time/with enough resources), depending on your future plans, getting access to the source may not be the holy grail you think it is. If you are actively developing your project on an on-going basis (you should be), consideration will need to be given to how you ensure your copy is up to date. We have systems to handle this (called source control) but you have to question whether the additional time required to learn and manage the various processes are of real benefit to you.
There are a few instances however where having access to the source code is definitely worth it. Have you for example got a contingency plan in place for if your supplier was to no longer exist? What would you do and how would you cope if the development company was no longer around? In these instances, having a copy of the source -or more importantly knowing how you can get access to the up-to-date copy is very important.
How can I quantify the worth of the source code to me?
As with many scenarios like this, there's not really a "one solution fits all" answer however after a little internal discussion we came up with the following:
| Value of Source | Considerations |
| High | - Was the system completely bespoke?
- Is it integral to your day-to-day operation?
- Is it your only source of income?
|
| Medium | - Although integral to your business, you have a copy of the software in a usable form and it doesn't change regularly.
- The system offers "standard" functionality which can be replicated with relative ease should it be required e.g. e-commerce functionality.
|
| Low | - The system is something generic, does not need to be changed
- You have control over the aspects that you need e.g. it's a website with a content management system
|
Is it worth getting the source code as a client?
Yes; but I would consider the message it's giving to your developers. If you ask for it at the beginning of the contract then there shouldn't be a problem but bringing it up after delivery might leave the developers wondering what your motive is (even if it is totally innocent).
Should I give the source code to my client?
Yes; unless you've clearly stipulated otherwise to the client from the start for some reason e.g. to reduce project costs. You should always write your code in a way that is readable to others anyway and knowing that you might at anytime be offering up the source code will encourage you to keep it that little bit leaner.
How do you handle source code with your clients?
To handle a scenario in which The Site Doctor no longer exists (whether it's because we've gone into administration or we're all hit by a meteor), we use Crisis Cover; an online information storage system that securely stores all the information our clients would need if we were no longer around. Crisis Cover then checks that we're still around and if not, distributes the information to the designated contacts.
If you've not already got some form of contingency plan in place I urge you to set something up now whether it's a service like Crisis Cover, Excel or paper!
In closing I would definitely promote the attitude we have at The Site Doctor in that it's better to build long-term partnerships but you should still have some disaster contingency plan in place.