Welcome Guest | Sign In
LinuxInsider.com

CA's Ingres Challenge: Programming on Contingency

By Phil Albert
Aug 24, 2004 8:03 AM PT

Lawyers and programmers have a lot in common. Programmers write code and lawyers write legal documents. Both consider the issues, generate written work product, check it for bugs and then release the product. Both professions rely on libraries to avoid reinventing each aspect of the product.

CA's Ingres Challenge: Programming on Contingency

There are many other similarities. Like programmers, lawyers can get paid on fee arrangement. The client pays by the project or by the hour, and only once the work is done. In law, clients have another way to pay: the contingent arrangement.

With a contingent arrangement, lawyers are only paid if the matter ends favorably to the client. Contingent litigation for a plaintiff usually means the client obtains some judgment or settlement of value. With contingent transactional work, the legal team might agree to get paid only if the transaction is consummated.

The lawyers are typically paid out of the judgment awarded or the settlement obtained. The amount can be a percentage of the client's recovery or benefit obtained, but that need not be the case.

Ingres Million Dollar Challenge

The "Ingres Million Dollar Challenge" recently announced by Computer Associates (CA) has a lot in common with a contingent legal matter, and also some important differences.

The million dollar pool is divided into six prizes, ranging from $400,000 to $50,000. The prizes award the best tools for migrating from competing database platforms to CA's Ingres platform. For example, the developer that creates the best migration tool for moving data from the IBM DB2 Universal platform to the Ingres platform gets $300,000.

The panel of judges includes representatives from CA and the open-source community. Winners must agree to license their entries to all under the CA Trusted Open Source License (CATOSL) or an equivalent license that does not contain copyleft requirements.

Contingent Arrangements

When lawyers work on a fee basis, the client and lawyers agree on how to measure the work done, such as billing per hour or per project. The lawyers do the work and the client pays for it regardless of outcome.

In a legal contingency:

  • No matter how competently the work is done, if there is no benefit to the client, the lawyers do not get paid;

  • The lawyer's compensation, when it does happen, is expected to be more than if the payment was guaranteed up front; and

  • Someone other than the client or the lawyer decides whether the client gets a benefit.

    Lawyers generally agree to a contingent arrangement only if the lawyer can expect more fees in a contingent recovery than under a fee arrangement. Even the best lawyers cannot win all the time. They count on winning contingencies to pay enough to fund the ones they lose.

    Clients only shift the risk to the lawyer if there is an uncertain outcome, or if the client does not have the money to pay on a fee basis. If the outcome is certain and the client has the money, the client would be better off with a fee arrangement.

    Contingent arrangements are nearly always contingent on something beyond the control of the lawyers or the clients -- otherwise they would be misnamed. In the case of contingent litigation, the risk is that the court could rule against the client. Without this uncertainty, there is no risk to shift.

    Programming on Contingency

    Like a lawyer deciding whether to take on a contingent matter, programmers deciding whether to rise to the Ingres Challenge need to take a hard look at the project. Developing a migration tool for complex databases is not a three weekend job for four teenagers on home computers. It takes a considerable investment of time and money by skilled programmers.

    To compete for the $300,000 prize for a tool migrating IBM DB2 data to Ingres r3, for example, you'll need a system running IBM DB2 and Ingres r3 to test the migration tool.

    DB2 Everyplace Enterprise Edition lists at $15,000. Add in some hardware to run it all and you're looking at $25,000 before you even start. If you're a software development house running DB2, you might have the expertise, but you would still incur the cost of taking resources away from paying customers.

    You'll want to do some rough estimates to ensure the project makes economic sense. Remember, you are doing this for the prize money, not just for fun. Estimates vary, but let's go with a development cost of $3.00 per line of fully debugged code. You would have to come in at about 90,000 lines of code to stay at $300,000, less the cost of tools and hardware.

    Migration Code

    Let's assume CA and most experienced programmers can estimate, within an order of magnitude, how many lines of code a migration tool would take. If the IBM DB2 migration tool would take more than 90,000 lines, experienced programmers would not even start. Even if it can be done in less than 90,000 lines, you need to take into account the number of entries.

    For example, even if you're one of the best programmers, if there are four entries from teams at least as competent as yours, you each have less than a 25 percent chance of beating all the others. Therefore, it doesn't make economic sense to compete unless you can produce a winning tool in 20,000 lines or so.

    If a migration tool could be created in 20,000 lines, wouldn't CA do it themselves for an internal cost of $60,000, or contract it out for maybe $120,000?

    It really doesn't matter what numbers are used. If both sides accurately estimate the costs, a contingent payment needs to be more than a guaranteed payment. Thus, it would seem that CA is either overpaying or entrants are getting a bad deal. I assume that a successful company like CA has given this a lot of thought.

    Who wins?

    Migration tools will be great for CA, who can give them to the open-source community because it benefits not from owning them, but from their mere existence. Of course, CA also can decide to own the tools by improving them and taking the modifications private. CA deserves credit for creating a buzz and arguably being the first to come up with the idea, but it just doesn't add up for the programmers.

    Treating the "open-source community" as a free labor pool might be a short-term solution, but as anyone who has worked for charity or political groups can tell you, volunteers are much harder to manage than employees. Plus, open-source communities tend to talk to each other. And they seem to favor licenses with copyleft provisions, which irritates so many vendors of proprietary code.

    Perhaps CA will find a group of skilled database tools programmers that happen to be bad businesspeople, don't mind working for free, and agree that their work product can be taken proprietary. Perhaps a new business model will be created. In any event, I would not recommend betting your salary on the long-term implications of programming on contingency.


    Phil Albert, a LinuxInsider columnist, is a patent attorney and partner with the San Francisco office of the intellectual property law firm Townsend and Townsend and Crew LLP.


  • Facebook Twitter LinkedIn Google+ RSS
    How do you feel about shopping for your next new phone?
    I can't wait for the new iPhone.
    I'm eagerly awaiting the Galaxy Note 8.
    I enjoy shopping for a great bargain, not necessarily a new model.
    I dislike the phone shopping experience -- it's too confusing.
    Phones have become boring -- I wish I could get excited.
    Switching phones is monumentally inconvenient and annoying.