I'm not sure how either of you bid on jobs, but I believe it is rather rare for a customer to grant a contract for creating a piece of custom software on anything other than a fixed price basis. We are discussing delivering a finished product to a customer, not providing contracted hours to a software development company.
You quote a certain price to deliver a specified result. The customer shops around for several quotes, and depends upon the existence of competition to get a reasonable price. The number of hours you put into the job is immaterial to the customer, as long as you deliver the specified product free of bugs and on time. You bear the risk of taking longer, and you reap the rewards of being done sooner.

If 90% of the program consists of code which was re-used from other projects, it doesn't make any difference whether it was code from your own previous projects or from someone else's or from commercial libraries. You're getting paid to either write the code, or to know where to get it. If you can do it with existing, tested code, I would rather have that than the new bugs that you created especially for this project.

However, the only way the scenario that was outlined in the previous messages could arise is if only one person were to know about the "free" code. Normal competition would drive the price down to the 110 hour mark, and anyone still bidding a price based on 1100 hours would soon go out of business.


--

************************
Michael Griffin
London, Ont. Canada
************************

 

Walt Boyes:
> > > If you write something, and you _know_ you can charge for 1100 hours
> > > of work, and because of the GPL or OSS, you can get away with doing
> > > 110 hours of coding, the fact is, the customer will find this out and
> > > understandably be irked.

Greg Goodman:
> I think the programming example above is flawed because it presumes that
> you're billing for hours instead of for a working system.

Yes, which is fairly rare.

> The beauty of a fixed-price contract is that the client knows up front
> what he's going to get and what it's going to cost him.

Yup - and a lot of it is by lowest bidder. It's unlikely that prices could stay 10x inflated for long.

> There is, in fact, a risk in seriously under-bidding projects, even if
> OSS would allow you to do it.
...
> I have seen clients turn down legitimate bids that were too far below the

It'd probably take several years of gentle bidding war to bring prices down by that large a factor.

Most likely, though, OSS won't bring 10x efficiencies, and certainly not all at once. For one thing, the bulk of most projects isn't programming but other stuff - meetings with the client, reports, specs, docs, insurance - none of it affected in the slightest by GPL.


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

Joe Jansen:
> > OSS is based on sharing and trust. I share my code with you, for free.
> > You take it, use it, and give it back. We are both ahead because now
> > the next time I need that peice of logic, it is improved by your usage.

Alex Pavloff:
> Actually, based on my conversation with Jiri, GPLed code is more like:

> I take your code, use it, and give it, _and all my code_, back to you.

Only code that you added to that same program - if it was a good fit to begin with, that might be a three-line bugfix, or a hundred line addition of a minor feature.

If you already have a bulk of your own software that you want to commingle with GPL code, then it's a different situation; you'll have to give away the entire commingled product. That's a large leap to take, and in that situation, you'll have to consider cost/benefit carefully.

If the bulk of the code you're going to end up using is under the GPL already, and your own contribution will be minor, then there's no contest.


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

Michael Griffin:
> I'm not sure how either of you bid on jobs, but I believe it is rather
> rare for a customer to grant a contract for creating a piece of custom
> software on anything other than a fixed price basis.

Yeah, well it wasn't my example, and I wasn't on my toes enough to point that out... You are right, of course.

> You quote a certain price to deliver a specified result. The customer
> shops around for several quotes, and depends upon the existence of
> competition to get a reasonable price.

Yup.

> However, the only way the scenario that was outlined in the previous
> messages could arise is if only one person were to know about the "free"
> code. Normal competition would drive the price down to the 110 hour mark,
> and anyone still bidding a price based on 1100 hours would soon go out of
> business.

Yes, that's the correct resolution of the dilemma.

The first person to notice the free code will get an advantage of being the first, but it's likely to be not as much as suggested above because at that stage the code won't be as developed. Indeed, if the free code develops gradually, most likely at least some people will start noticing it as soon as it crosses the cost/benefit threshold, at which point the overall benefit will still be small, and competitive prices will be able to follow the gradual accumulation of benefit without any problem.


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

> > I'm not sure how either of you bid on jobs, but I believe
> it is rather
> > rare for a customer to grant a contract for creating a
> piece of custom
> > software on anything other than a fixed price basis.
>
> Yeah, well it wasn't my example, and I wasn't on my toes
> enough to point
> that out... You are right, of course.

A lot of projects around here get bids of 'not to exceed'. The final bill is usually less, depending on how accurate the bid the bidder was on hours/materials, and how much he padded to bid to cover himself in case he underbid.

> > You quote a certain price to deliver a specified result.
> The customer
> > shops around for several quotes, and depends upon the existence of
> > competition to get a reasonable price.
>
> Yup.
>
> > However, the only way the scenario that was outlined in the previous
> > messages could arise is if only one person were to know
> about the "free"
> > code. Normal competition would drive the price down to the
> 110 hour mark,
> > and anyone still bidding a price based on 1100 hours would
> soon go out of
> > business.

This is also why reputation is important, and honest competent vendors get offered work that other people don't even get to bid.

Mark
Any opinions expressed in this message are not necessarily those of the company.

 

GPL or don't GPL, I don't really care! I'm just looking for a solution to my problem. I think some of you have touched on it, but here it is:

My company bids a lot of jobs that are similar on fixed bid. We bear the responsibility of completing the job, if we go over our estimate we eat it, if we are under our estimate we reap the rewards. In a competitive business like this sometimes you bid tighter than you might like in order to get the job. Therefore a certain percentage of the jobs are going to go over because of unforeseen details and tight bids.

THEREFORE, every integrator is looking for any advantage to cut down programming time. Code re-use, automated program generation tools, etc. are
all ways to cut down on programming time. Eventually the competitors may catch up, but the integrator will cross that bridge when he comes to it.

Re-use of code, or automated program generators, inherently means that at least chunks of every program look the same as the last program. Since in the absence of a contract, the integrator owns the code, there is no problem with that. The problem arises when the customer feels that HE owns the code, and decides to pursue a lawsuit because you are using the code elsewhere. Note
here that customers may not be aware that they don't own the code, and if they were they might stipulate that they do in their contracts.

I don't want to bid a job in which I have to estimate hours without code re-use, because in all likelihood I'm not going to get that bid. So I have to figure out a way to insure that I get to use my code over and over again. If GPL is the method by which I get that done, I'm for it.

Jason Greff
Instrument Control Systems

 

> Please don't misunderstand this as a putdown, but obviously you have never
had to deal with a legal issue. "Protection against lawsuits" is
> an oxymoron. The very best you can do is "pay" for liability insurance (the
"errors and omissions" kind) in perpetuity. <

How true! But then, why have any terms and conditions in a contract at all, since I can always hire a lawyer if I don't like the outcome, and I can't protect myself from having the same done unto me? Of course, the answer is that I can't prevent the lawsuit, but hopefully I can insure that I will win - provided I think the issue is worth defending instead of settling.

I think it is clear at this point that NO ONE reading this thread has any terms and conditions in their current agreements that cover this area, or if they do, they aren't talking. So my question is this: as an integrator, are you willing to go on indefinitely with things as they are? Or, having read the comments here, are you going to give some thought to putting some language in your future agreements?

Jason Greff
Instrument Control Systems

 

We maintain that any code developed belongs to usm the creators. We give the customer full permission to modify, enhance, or destroy the code. In the event that they have a problem due to their "enhancements" or whatever, we then
return to the last version of code we supplied, and install the enhancements desired by the customer. They, of course, have to pay for that.

We specifically state that the code can only be used on additional systems if installed by us. In general, the cost for this is minimal compared to the original creation of the code. In effect the customer owns the enhancements but we retain ownership (whatever that means) of the original code.

We have experimented with "software keys" to prevent the customer from cloning our software to additional systems but this seems to be more trouble than it is worth since there must be a certain openness to allow replacement of failing
CPUs or whatever.

The law here is somewhat nebulous concerning all of this but we have found it to be acceptable to the majority of our customers.