Author: Yogi Schulz
Intellectual Property is absorbing the blows as customers and systems development vendors wrestle to reach consensus on software value.
More and more systems development vendors are offering their customers re-usable components as a way to build custom applications better, faster, cheaper. What receives less airtime during the marketing spin cycle, is that the vendor expects to improve his Intellectual Property (IP; not to be confused with Internet Protocol) as a by-product of the project.
The customer will typically become formally aware of the vendor’s secondary objective of enhancing his IP when the software development agreement is presented. This IP aspect of development projects sets up a wrestling match the first time the project careens into a moment of difficulty (Don’t all projects?).
Moment of Difficulty
Shortly after the moment of difficulty, when the customer comes to realize that the project will take longer and cost more, the customer will say: “Look at all the new IP you’re taking away with you from this project.” Here the customer’s objective is to soften up the vendor for the request for a concession that comes next.
The vendor will reply with: “Look at all the valuable IP we’ve already contributed to your project.” Here the vendor’s objective is to remind the customer of the great deal that has already been received and that expecting further concessions is unreasonable.
Losing Sight of Best Interests
In this wrestling match over the value of IP, it’s easy for both parties to take a position that is not in their own best interests.
The customer, in an effort to push more of the mounting project costs onto the vendor, will try to paint an optimistic picture of the market value of the software that the vendor will have available to license at the end of the project. The vendor, who is often emotionally enthralled with his own software, may well agree to give up some current revenue in return for more future license fees later.
Well, there is no later. The next customer will insist on yet more features, whose cost will not be covered sufficiently by license fees from that customer.
A pushy position can backfire on the customer, if the vendor becomes too financially crippled, during this project or soon thereafter, to support the customer adequately.
As a way out, the vendor, painfully aware of the reality of software maintenance costs and the uncertainty of future license revenue, will dangle the idea of future royalties in front of the customer. In return for continued funding of the current project, the vendor promises to pay the customer a share of future license fees from other customers.
Well, again there is no later. Such royalties are rarely paid. Most of the royalty agreements contain enough loopholes that royalties are not due. {Then there’s the matter of new products. Are royalties due to the original customer, on new products that inevitably contain vestiges of code from the predecessor product?}
Stick to your Knitting
The best course of action is for both parties to stick to their knitting. The customer should concentrate on his own business plan and be the customer; not the investor in a software venture. The vendor should firmly communicate his IP value and diplomatically remind the customer that further vendor investment is foolhardy.
Pushing or cajoling the other party too far creates ugly outcomes for all concerned.
