Fog Creek Software
Discussion Board




Consultants who hold back the source code

I am negotiating for an end user type project, a payroll related system for a manufacturing company.

The last consultant (long gone) was a "Clipperhead" (Clipper was a DOS type xBase database language). My contact says that this guy didn't provide source code, only executables.

I knew some other guys who worked that way, more or less, from the mid 80s through the late 90s. The "consultant who holds back source code" was the standard model for end user consulting. You basically made yourself irreplaceable by not providing source code.

I always viewed this as irresponsible and arrogant. IE, a nice deal if you could get it. Say the consultant was injured/killed... the customer has paid for certain work... and loses the value of being able to move forward.

I asked one such guy about "source code escrow" and he laughed in my face. His clients, he said, would have absolutely no idea how to get the source nor what to do with it and he sure as hell wasn't going to pay for it. I thought he was underestimating the intelligence of his clients just a little bit. I did get a strong sense of "ha ha! My clients? Screw 'em if something happens to me".

I do understand the business reasons for withholding source code. They favor the consultant entirely.

EVERY end user type consultant that I knew 10 years ago worked this way. Now, I don't know one guy who operated that way who is still in business.

It seems to be an antiquated model for doing business.

Does it still exist? Anyone you know still do it?

PS: I'm not talking about working on other people's products or working for IT organizations that demand source code. I'm talking about working with end users who may not proactively request the source.

Bored Bystander
Tuesday, August 17, 2004

+++PS: I'm not talking about working on other people's products or working for IT organizations that demand source code. I'm talking about working with end users who may not proactively request the source. +++

If they don't proactively request the source, you probably ought give it to them anyway.  They are paying for the software, after all.  Just figure it into the price if you must.  If you don't offer it, and later the customer becomes more educated and realizes that most contractors DO provide source, you've burned a bridge.

muppet
Tuesday, August 17, 2004

I believe it's the client's right to have the source code.  I recently worked on a very large project in Java and Cold Fusion.  The client didn't ask me for the Java source code.  He may not have realized that he was entitled to it or that he might need it if he ever wished to modify it.  I delivered it to him once I had been fully compensated.  He was very impressed with my thoughtfullness and hired me for another project as a result. 

Neo
Tuesday, August 17, 2004

I didn't realize the majority provide source code without the explicit request for it.

There also has to be a distinction between a custom-coded project from scratch and something more like a custom-tailored, but pre-existing product.

Something else tricky about that... you can have source and still be legally bound NOT to modify/recompile it depending on the fine print. This is more evil I think.

I have seen the other side, and it is good
Tuesday, August 17, 2004

++Something else tricky about that... you can have source and still be legally bound NOT to modify/recompile it depending on the fine print. This is more evil I think. ++

I don't see how this is more evil than not providing the source at all, though it still sucks (but is useful for auditing for security, and the like).

It seems to me that unless you're customizing your existing product for a particular client, you ought to give the client the code.  If they're paying you to develop X from scratch, then X is theirs, not yours.

muppet
Tuesday, August 17, 2004

doesn't this happen every time you buy a shrink wrapped product?

Kenny
Tuesday, August 17, 2004

I always include in the initial qoutation/proposal a statement of ownership of the code.  If, for whatever reason I want to keep code closed (unlikely and only if I plan to integrate into a product offering sometime later) I'll offer escrow service at client's expense.  It is your responsibility as a good consultant to inform your client of his options and what the benefits / downside to each option are .... that's part of the "consulting" in "consultant"...

Just my $0.02.

<sigh/>
Tuesday, August 17, 2004

I think I've known and worked around a LOT of unprofessional hacks. The "secret source code" model seems to be characteristic of the earlier days of PCs and LANs when there was a certain mystique to being a computer consulting. The "fighting with .BAT files" era.

Typical profile of the sort that "withheld" source: no technology background, very defensive "self educated" attitude; worked only with character mode technologies exclusively (DOS, Unix/curses); lone wolf; everything homebrew.

The pattern seemed to be: maximize billings of unsophisticated customers by reinventing the wheel continuously.

And uncompetitive in the modern world. As I said, the three or four guys I knew that operated like this from mid 1980s through the mid to late 90s now are either employees of others or are in another line of work entirely.

The impression I got from these guys was that they didn't want anyone to see their code because it would be apparent how little there was to it.

Bored Bystander
Tuesday, August 17, 2004

If the contract states that the output of the contractor's labor is a "work made for hire" then the source code becomes the property of the client.

If there's no statement with respect to ownership the ownership is ambiguous and subject to litigation depending on jurisdiction (Note: Not a lawyer).

It's not terribly uncommon for consulting companies to retain ownership of source code created during an egagement with the provision that the resulting application is then licesned to the client in perpetuity. It's all in the fine print of their generic contract.

Smart clients insist on inclusion of the "work made for hire" clause, and then, if they don't really care about it, offer to trade away some of their exclusive ownership rights in exchange for a discount.

Tom

Tom
Tuesday, August 17, 2004

==>I always viewed this as irresponsible and arrogant

I couldn't agree more. I've never understood this model, other than for extortion and/or job-security purposes.

It's bullshit. It's unprofessional.

Sgt. Sausage
Tuesday, August 17, 2004

I should definitely have clarified that... it is evil, only if the consultant fails to disclose that tidbit. More evil, only because it also misleads the customer into believing they have 'useful' source.

It's been awhile since I was in the billable hours environment.

And not that I have any opinion on this one way or the other... but let's say I've developed some custom web app for Company ABC. I subsequently find that it could be tinkered with just a bit to make a worthwhile off-the-shelf sort of product.

Is it unethical for me to do that and sell it as such?

Something wicked this way comes
Tuesday, August 17, 2004

Tom posted while I was typing... I suppose if the contract included "work made for hire" it would be not onyl unethical but illegal.

Do you guys think it is otherwise ethical if no such stipulation is made?

I am Jack's contractual loophole
Tuesday, August 17, 2004

"doesn't this happen every time you buy a shrink wrapped product? "

The issue is whether you're selling a product or a service.  In the shrink-wrapped scenario, you're selling a product that others can use as-is, not a service.

In the consulting scenario, you are selling your ability to produce source code for them.  They retain the IP that you produce, as that's why they're paying you in the first place.

Elephant
Tuesday, August 17, 2004

If your contract states that you keep the source, and that it's your property, then you keep it. You can develop anything else you want with it.

If not, then the source is the client's property, and you can't do anything else with it.

Do whatever your contract stipulates.

Edward
Tuesday, August 17, 2004

++The issue is whether you're selling a product or a service.  In the shrink-wrapped scenario, you're selling a product that others can use as-is, not a service.

In the consulting scenario, you are selling your ability to produce source code for them.  They retain the IP that you produce, as that's why they're paying you in the first place. ++

how do you retain the IP without the source code?

imho, its all product.  one's just more specialised, that's why it costs more.  ie. the difference between a prototype automobile, and one that comes off the assembly line.

Kenny
Tuesday, August 17, 2004

"In the consulting scenario, you are selling your ability to produce source code for them.  They retain the IP that you produce, as that's why they're paying you in the first place.
"
In our experience, clients pay you in the first place for results.  No one cares about IP on a product that doesn't work ;)

We rarely give away IP, on the understanding that our expectation that we can sell the same product to another client lowers the profit margin we need to make to make development worthwhile.  Our clients are happy to pay for receiving a product that does what they asked and matches their needs.  They rarely want to pay to have exclusive use of the product. 

Phibian
Tuesday, August 17, 2004

I agree with all comments to the effect that anything contractually agreed with both party's conset is legal and binding.

I also agree that omission of important facts or issues may be grounds for dispute later.

What I have described is the practice of a certain breed of consultant that relies upon the naivete of their client to not provide any way for the client to move forward with work that the client presumably bought at considerable expense.

IE: it is "reasonable" for a client to expect that some other consultant could make changes in the first consultant's absense.

I hold that relying upon the client's ignorance and technical naivete' is unethical. But it was a widespread practice in certain circles in past years. I think as the general public has become better educated about what software "is", this practice has been on a dramatic decline.

Bored Bystander
Tuesday, August 17, 2004

To Phibian:

I agree with your philosophy. AS LONG AS THE CLIENT KNOWS EXACTLY WHAT THEY ARE GETTING. And as long as the client knows whether or not their future options are bounded for that deliverable or not. But I think you know that.

The reason I have heartburn with not releasing source code for custom work is that custom work is rarely tested to the extent that "real"  products are - after all, it's "limited production" for just one client. So the client may run into a snag or limitation after the consultant has long since left the scene.

I just think it's imperative to be "full disclosure" about these issues w/o killing the deal. 

Bored Bystander
Tuesday, August 17, 2004

It would probably be tough to keep a client from modifying the code if you gave them the source.  You could grant them a license only to use, but if the code is only used inside the company, you may never know if they have modified it.

However, you don't give away your right to re-use the source code just because you give someone else a copy of the source.  It is still your IP (unless you contractually assign the IP to someone or it is considered to be a work for hire).  Readers of a book can see the "source," but that doesn't mean that the author has given away his rights to his intellectual property.

IP guy
Tuesday, August 17, 2004

Ok, what about the following (real) scenario?

There's an existing product, very popular in my industry, that is a C++ desktop app.

Clients want to be able to modify its behavior either interactively or remotely, but there's no API.

We've developed, at our expense, and somewhat painfully, a  de facto API/Library using the Win32 API to modify/manage the application.  Each specific client case is different, but  the key is the use of the library.

So, if we take a contract that requires using our library, should we give the client the source code to that library? We have no problem giving them the source that doesn't use it, but that source is useless without our library.

In fact, we are upfront about this, we're perfectly willing to put it in escrow at their expense, or even deliver it if they agree to buy it separately or in exchange for something of value.

There's no way, however, that we would just give this away, and I wouldn't think this sort of situation would be uncommon.
   

Mongo
Tuesday, August 17, 2004

I agree with the sentiments of others who think that consultants hold onto the source code purely for reasons of self-preservation and job security but it would depend on the nature of the work.

I would have thought that whether or not the client gets the source code is all down to the wording of the contract and the type of work being performed. It would be incredibly deceptive to play on the ignorance of the customer but I'm sure it happens quite frequently.

In most situations where I've been in a consulting/contracting role, the source code has remained the property of the company I've been invoicing (although in those situations it was more of a hired-gun, get-it-done type of thing). If however you were building say, a billing system and you wanted to sell that product in the future to other customers then you'd probably specify in the contract that the client gets the runtime libraries and the IP (source code) remains the property of your company.

For peace of mind, an escrow arrangement would probably be important in case (heaven forbid) you get run over by a bus.

TheGeezer
Tuesday, August 17, 2004

Mongo,

No reason for you to give it away.

You can use the library as a competative advantage in your selling process (you can do it better and cheaper 'cause you've the technology).

If you use the library to build a solution for the client you can either do so "gratis" and charge a premium for the services you deliver, or use the library and charge the customer a licensing fee.

If you want the client to feel more secure, you can offer to escrow the source, for an additional fee, of course. Licensing the source code is also an option.

The common theme here is: don't do anything for free.

Tom

Tom
Tuesday, August 17, 2004

I conclude that there is no ethical problem.

Software contractors are only ethically responsible for providing advice when advice is specified as part of the contract.  They are only ethically responsible to provide source code if the contract says so explicitly.

Contractors are not ethically responsible for "negotiating both sides" of the contract.  It is each side's responsibility to understand what they want out of the contract and to negotiate a contract that is acceptable to them.  A contractor has no ethical responsibility to provide source code if the opposing party does not ask for or does not want source code.  He is also not ethically required to guard the interests of his client without a contract.

(There is naturally a strange situation where a contract is made for the contractor to provide advice and, upon signing the contract, the contractor says, "My advice is 'not to sign any more contracts like mine.'"  But it is still true that a contractor has no responsibility to ensure that the opposing party negotiates a good contract for itself.)

Sure, some people may provide source code without a contract, out of courtesy, a sense of professionalism or for some other reason.  But they are not ethically required to do so.

Daniel Howard
Tuesday, August 17, 2004

"It would be incredibly deceptive to play on the ignorance of the customer but I'm sure it happens quite frequently."

It seems to me that it is courteous but not an ethical imperative to inform an ignorant customer that he is ignorant and suggest that he get informed help.

Knowing its knowledge or lack thereof is each party's own ethical responsibility.

Daniel Howard
Tuesday, August 17, 2004

This works both ways. It is far more often the case that the customer plays on the ignorance of the consultant and so expects and takes the source code, whether it's been discussed or not.

Some consultants produce much better software than others, for many reasons. Typically they do much more work and have invested much more in their own learning and experience.

But they won't be paid more for that work, which is a big difference compared with other professions. Top medical specialists or lawyers earn 10 to 20 times the standard rates. Top software developers earn the standard rates or even lower rates. For one thing, software that works very well will require much less maintenance. It might be developed faster too.

The only fair way for good consultants to capitalise on their work in that case is to retain the source code so they can re-use the work for other customers. This also prevents other consultancies stealing the source code from the customers' premises and on-selling that work as a "service." This happens a lot.

JM
Tuesday, August 17, 2004

Leaving the source code with the client is somewhat useless if they re-format/recycle the disks the code came on. Yes, that happened to me. It got real nasty when the computer I developed on (at home) had a HD crash. I would rather leave copies with them, even if they are going to delete them.

Peter
Tuesday, August 17, 2004

The cuture in other countries make the developers much more paranoid and defensive about giving the source-code to their clients.

Some of the factors may be:
- generalized piracy
- weak laws and law enforcement
- lack of ethics and morals
- billing for making the program and for maintaining it (the job doesn't end after the first version is made)
- IT in the early stages, still.

Those are just a few of the factors that I can think of, but they are enough to represent the difference in cuture among countries.

But things are changing...

Dewd
Tuesday, August 17, 2004


I think a big part of the problem is billing on an hour rate vs. delivered value.

I think a lot of the people using scumball, re-invent-the-wheel-on-purpose-to-maximimize-billable-hours tactics would be amazed if they shifted to delivered value.

For instance:  Customer asks for X.  Scumball can do it in 5 hours, but claims 20 and asks for $50/hr or $1,000.  Customer Pays.  Scumball spends a lot of time 'tweaking' code this is not needed.

Now, think about this:  The customer accepted the $1,000 price tag.  That means the change is worth $1,000 to the customer.

The contractor could drop all pretense of time-billing and instead rely on functionality billing.  Assuming the yes/no decision is patently clear (IE Clear Specs, clear agreement, good relationship) the developer could just say "$1,000.00"

He could write the code in 5 hours and spend 15 more playing golf or something.  Instead, he wasted those 15 hours and probably feels bad about himself.

Recommend "Million Dollar Consulting" by Weiss to explain this.

JMHO ...

www.xndev.com (Matt H.)
Wednesday, August 18, 2004

I can't imagine a consulting arrangement that did not explictly address who owns what  source code, and also who gets the licenses to any third party tools used in the creation of the client's product.

I've had serveral clients who have been happy with a code escrow scheme, that in the event I die would let them get at the source but not redistribute it should I disappear or fail to provide support at an agreed on level.

Jim H
Thursday, August 19, 2004

*  Recent Topics

*  Fog Creek Home