How to explain to client that you can't give them some of the source

Question

We have a number of AS/Flex components that we've built over time and improved upon. They've been turned into components so they can be reused in different projects and save us time. So you can think of them as part of an in-house framework of sorts.

We're now realizing that it doesn't make sense to release the source code for these components to the various clients as part of the project, because technically this code isn't really owned by the clients.

So my question

• When a client comes to you, how do you explain to them that you can't give them the full source code for those components. The client doesn't understand the difference, he just expects you to give them all the code for the site that he paid you to do. He doesn't understand that this code has taken you a lot longer to write than what he's paying for his site. But since he doesn't understand, he would get turned off and thinks you're ripping him off or something.

• How do you handle this situation? What do you tell clients upfront? Do you advertise it on your site from the very beginning? How do you handle their objections so they still hire you?

• As a side question, how often do you give AS and Flex source code to your clients? In the case when the code doesn't have any in-house components that you reuse in several projects, and in the case when it does have in-house components.

I'd also like to hear from people who've worked at creative agencies since they're most likely have run into that issue already.

Answer 1

I'd explain to my client how the world works. I'd use examples, analogies and metaphors.

This isn't a software-development issue, this applies to all products. Some things are sold as black-box, and some things are sold as a clear-box containing black-boxes inside it.

Lets say you wish to buy a house. You pay the engineer and the architect for their work, and you gain the documents they produce. These documents contain information that relies on other pieces of information, which you do not gain. For example, the engineer may use huge steel bars in his plans. The engineer's specifications determine the qualities that each steel bar must have, but they do not specify how the steel bars are created. Buying house plans doesn't buy you the plans for creating the house's building blocks. With softwre it is pretty much the same: you don't get the source code for the .NET framework when you buy a .NET application "with sourcecode included". What you do get is the .NET documentation, specifying how to work with the framework (and not specifying how the framework does what it does).

The amount of examples is actually endless, because - as stated above - this is the way the world works.

Build your own analogies to fit your scenario. Explain to your customer where the infrastructure ends and his owned solution begins.

quoo is right about the need to specify these in the contract. The contract is the legal backbone of the deal. But i'd like to emphasise the fact that pointing at the contract should be a last resort. If you can give your client a reasonable explanation such that lets the client understand why things are the way they are, you won't need to wave the contract (which speficies only the way things are, without the motivation, explanation, etc.).