How to "Open Source" Custom, Contract Software? 392
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 should own the code (Score:4, Interesting)
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.
ala Big Corporate Mofos (Score:2, Interesting)
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.
Re:and further... (Score:2, Interesting)
Businesses understand money (Score:3, Interesting)
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.
It's a WHO YOU ARE question (Score:4, Interesting)
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.
Standing on the shoulders of giants (Score:5, Interesting)
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
It depends. (Score:3, Interesting)
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.
Actually (Score:5, Interesting)
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.
Re:and further... (Score:2, Interesting)
What's the problem? (Score:2, Interesting)
I had a client ask me to do a piece of software. I said right in the contract that I owned the rights to it. I GPL'd it and it morphed into MIMEDefang, which is a far better product now than it was when I originally delivered it.
I'm working on another piece of software which has certain proprietary and competitive features. After a lot of back-and-forth with the client, we've agreed that I can GPL parts of it (called "core infrastructure code") while giving up rights to other parts (the "non-core code.")
Sounds like (Score:3, Interesting)
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.
Sell them your service ... (Score:3, Interesting)
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.
Re:Open sourcing it buys the client and yourself n (Score:5, Interesting)
> 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.
This IS slashdot, right? (Score:3, Interesting)
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.
We WIN bids due to the GPL. (Score:3, Interesting)
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.
Contracting (Score:2, Interesting)
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.
Depends on your deal. (Score:3, Interesting)
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.
I've done this (Score:3, Interesting)
No Benefits to OSS'ing this - Even ESR Says So (Score:3, Interesting)
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.