Slashdot Mirror
How to "Open Source" Custom, Contract Software?
customWorks asks: "I've been approached to write a piece of custom software for a small business owner with the promise of autonomy in its design and implementation. I do not intend to stick around for incremental development after I've delivered it, and so I feel strongly that open sourcing the software would be prudent for the both myself and prospective client. That said, I still expect to be paid for the developing the software. The issue of course is over convincing the client of the benefit of giving away the source to something they've just paid to have developed. I'd like to know if any of you who've done similar contract work have had experience (success?) in presenting an argument for open sourcing the end product? What were the major concerns/misperceptions that you had to overcome in making the case for open source?"
The client is paying you for your time in developing an application. For that money, they should get at least:
1) The binaries
2) documentation
3) support
If you can't give them support, the ethical thing
to do would be to let them know, and give them the
source code so that they can have someone else
maintain it. But THEY should choose whether to
open source the code or not. They paid for it. It's their decision, not yours.
In this case, you could make open sourcing the program part of the development contract. Just squeeze it in there inconspicuously. Much like so many EULA's we've seen.
Or say that the custom app will be based on your own technologies so that you can open source say the main engine, and not give out proprietary stuff, such as database data.
The actual labor required to develop something GPL'ed doesn't have to be free! Does it?
Present the potential customer a list they can choose from like this:
If they take the software with a non-exclusive license, you still own the copyright and are free to release it under GPL or whatever other terms you like.
I've worked for companies that have paid HP and IBM hundreds of thousands of dollars to have features placed in products. Never, ever, was there even a question who owned the source. HP and IBM.
But I've been in this guys position. Small companies are control freaks. They aren't willing to pay the money that a larger client is, they don't understand the debug cycle, they are usually more of a hassle to deal with, and to make it that much more irriting they want to own the IP.
Stick it to them straight. You'll provide them the solution, and the source, you own the IP and will do whatever you want. Don't be rude, but be prepared to walk.
The contract jobs I'm doing lately, I'm plugging in as much open source as I possibly can, and then essentially charge the client for the "glue" code that puts it all together.
;)
;)
Most business problems have been "solved" in one way or another elsewhere -- extol the virtures of sourcing in something that they will be able to get support for, using the old "if i get hit by a bus" scare tactic
Otherwise, through good architecture, you can compartmentalize the proprietary bits to a few files, thus allowing them to have something of their own at the end of the day.
And again, BE OPEN UP FRONT -- you are probably not in a position to identify on your own what the client may or may not consider proprietary -- lots of businesses have "grey-matter" or "raw experience" when it comes to processes and methods that are not obvious to their competitors.
But basically we get a lot of mileage becase I stand on the shoulders of giants everyday!
and remember, work = force * distance
Old age and treachery almost always overcome youth and skill.
Are they paying for him to deliver a solution, or are they paying him specifically to develop code for them. There is a difference.
If they are paying the hourly cost of development, then it is absurd, even rude, to expect them to let you keep the copyright.
On the other hand, if they are simply paying you a flat fee for a solution, and it is up to you how you attain that solution, then it's another story. You can write the code and license it to them and keep it yourself.
You almost always give the client an Unlimited Non-Exclusive license to the stuff, but you certainly dont give away what you can sell.
If a client adamantly wants exclusive rights to whatever you produce, then you certainly raise the rates. And if you bring any preexisting code in an the product, which you will always do, you have to be clear that they dont get exclusive rights to that as well.
A common practice in industry is to keep source code of custom apps in escrow, with the understanding that if the original developers go out of business or stop supporting their software, the source code is released to the customer.
you don't know the difference between contracters and employees. Generally IP to software written by salaried employees is owned by the company, but software written by contracters usually isn't, for a pretty simple reason.
IP to software is useless to a company that isn't planning to resell or profit directly from the software. Companies that hire contracters are usually looking for specific peices of software that will perform a specialized function, so they wouldn't have much use for the software IP, only for the software itself. Perhaps some contracters do hand over the IP rights as well, but most certainly don't.
I'm sorry, but you are trying to say that the guy doesn't know much about "real companies", when it actually seems he would be more justified in drawing that conclusion about you, if indeed your post was not a troll.
Cedric Balthazar Rotherwood
Sun Certified Programmer for the Java Platform +
System Admin. for Solaris
not the code. Develop the code under GPL/Open Source. Then charge them to implement it on their system.
Re-organize it so they are paying for your support and service while you are paying to write the program.
Frankly that is what you are trying to do anyway. You want them to pay you for your services not for your code or you wouldn't have even considered open sourcing your SW.
-- Mean People Suck
> Leaving it up to the OSS community and expecting
;) Letting people do whatever the heck they want with the code.
> them to produce something useful to your client
There are many more reasons to open source something than to sit back and let people hack at your code while you just absorb the patches, you know.
Sometimes the code is dead to you. But you make it available just in case someone else wants to use it. Sometimes a hack you made would serve as a great example to help teach someone else. Sometimes it tackles a problem in a totally new way that someone would just love to incorporate into their program.
I make a habit of tarballing everything I write and tossing it up on my website. I don't clean up the code, I don't turn it into a distribution.. I just let the people have the code because it serves no purpose to let it rot on my HD. Has anyone ever sent me a thank you email? No. But watching my http logs, once in a while someone does download something, and it feels cool to know that someone somewhere might be learning something from it.
THAT's what open source is about.
First, base your project on an existing Open Source project. Show the client how much value s/he gets from starting with the project(s), not limited to the fact that others have reviewed the code.
Second, once the client sees that h(i|er)s project will benefit and that the total project will cost less, explain the need for continuous updates and maintenance. Explain how costly it will be to maintain that work totally and solely in house.
Then, propose a solution to 'leverage' the Open Source community to assist with the project by releasing the changes, with the client's approval, back to the project. Explain the benefit of many eyes and many users perfecting the codebase.
This is exactly what I and a colleague have done with a very properietary-minded client. Now he's onboard for releasing the modifications and enhancements we will create back into the project community. Actually, he's excited to do this.
The way to your client's heart is through the bottom line.
-- @rjamestaylor on Ello
All our bid specify that the cusom software is GPL'es and it's help us squish the competition after we explain the benefits to them:
1) If we die, then they arn't left up a creek without a paddle.
2) Their data can be easily migrated over to a new peice of software if need be.
3) They can extend the program if they later decide that we suck.
It wins contracts, and we don't low-ball our bids.
Aside: Never low-ball a bid, it looks syspicious and makes the prospect nervous.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
I contracted for years to several companies, developing custom solutions for them, and never once did I have to give them the source code (lucky, they were a pack of twats!). IP rests with the developer unless the contract specifies it belongs to the company who hire you. They have a clear right to the binaries, but access to the source code is up for negotiation.
What is the point of open sourcing the code? Put it in escrow if the company requires that, or negotiate code release into the contract if they want that, but make them pay for it. Remmember, it is always more expensive to contract someone to produce reusable code for you, than it is to have a system built.
All those moments will be lost in time, like tears in rain.
I have written software for clients, anything from simple shell scripts to large web applications.
Typically, If I intend for the software to be OpenSource, then I only charge for the installation of the software.. and not the development of it. I will normally charge for the installation of opensource software which I did not create, why should I not charge for the installation of software which I have created?
I have worked for some clients who have requested, at the completion of the software.. for it to become Opensource, for the sole reason that the software meets their minimum requirements.. but would like continued support after the end of my contract.
If you have any doubts, discuss it with your employer/contractee.
The last several big jobs I've done, I've agreed in advance with the customer that the software produced would be released under my copyright under BSD license. I've had no trouble getting big corporate customers to agree to this. The next negotiation, I shall try to get them to agree to GPL. It has some benefits for the customer: it guarantees that they have access to the codebase in perpetuity, whatever happens to me.
I'm old enough to remember when discussions on Slashdot were well informed.
In The Cathedral and the Bazaar, Raymond mentions a case where he spoke with a small company about some peculiar software they used for their product.
The company asked him if OSS'ing their software would be beneficial. His reply was "no", since the software had a somewhat limited application outside the context of this company.
The situation cited in the article sounds similar to the one ESR mentions, so I would have to say "Nay" here.
-PS. The story was in his book, The Cathedral and the Bazaar, so I am not certain if it exists in the online white paper of the same name.