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?"
In any contract work I have ever done, I have made sure that I own the copyright, and give the client a perpetual license for the resulting programs.
If the customer insists on owning the IP, then there is a great reason to raise your rates.
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.
You'd do better to leave them well commented code with a few backups. Leaving it up to the OSS community and expecting them to produce something useful to your client (i.e. you're getting paid to serve them, not the OSS community) is a gamble at best. Not a dig on them, they're just not looking out for your client.
So lots of comments and documentation are what you would produce if you truly have your client's best interests at heart.
i've never coded a piece of software in my life, let alone opensourced one, but i can tell you right now the single major objection or concern you will face.
The dialouge will go something like this:
Coder: Let's open source this after you pay me to write it.
Buyer: Wait. So once we pay you to produce this for us, you want us to let you open source it, in effect giving it away for free?
Coder: Yeah. It's neat. Information wants to be free.
Buyer: But you want to be paid.
Coder: Yeah, I gots ta get paid.
Buyer: They don't require computer science majors to take economics, do they?
Seriously here. A buyer who is paying to get a custom piece of software made for them will be very very reluctant to let the rest of the world have that software for free once they have it. Especially if they have competitors. Especially if that software is mission critical at all.
In summary, best of luck. But perhaps opensource idealism should get a bit more used to taking a back seat to harsh economic reality.
*ends post, dons flame proof suit*
--Use this space for notes--
and make sure your source doesn't either in case it should reveal "interesting" information about their systems, environment, transactions, etc.
If I were paying someone to write code for my business I would want it as customized to my needs as possible while making it modular for further enhancement. What I would not want is for the entire open source community to know what network OS, database version, hardware, etc. I am using since that would reveal too much useful information to potential intruders.
Tell them that by allow you to open-source it, they will no longer be dependent on you for maintenance; they can hire anybody to do any revisions. Remind them that without this move, the IP will still be yours and they will have to negotiate with you for improvements and further development, and that if they want the IP themselves, that will mean a cost increase for them.
As a second, less important, benefit you can mention that there is a possibility that others will pick it up for use in their projects, and those improvements will benefit them without it costing them anything at all.
When they ask why they should pay you to write it in the first place if you're just going to turn around and open it, point out that without a developer under contract to write it, it won't be written at all in the first place. Emphasize that the open sourcing is about the maintenance of the software after it's been written, not about a different model for the development.
/Janne
Trust the Computer. The Computer is your friend.
Next, you'd have to show me that releasing the code would not open me to any liability nor to any security breach. Saying that "more eyes see more bugs" is not an answer either, because I'd still have to pay someone to integrate fixes or, at least, re-install on my system each time an eye found a bug.
Finally, you'd have to show me that I couldn't profitably sell this as a product - probably not a big deal, as software doesn't appear to be your customer's area of expertise, but small businesses live and die on cash flow and, if I can keep it proprietary, not do anything to support it, and still charge money for it (i.e., the Microsoft strategy :-), I'd still do it...
That is all.
While this may seem like an attractive idea, the ethos of open source is the free exchange of ideas. This ideal would be damaged by tricking a company into signing a deal that would open source software which they paid for. This would not only engender a possible court battle when the company wishes to enforce its rights but would also ensure that the company would be less willing to discuss/implement open source solutions in the future. If you cannot convince a company of the benefits of open source, then you must bow to their wishes, after all, they are paying you. Just another side note, if you are a member of the ACM the kind of conduct you suggest would most likely be against the ethical guidelines.
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.
Why do you feel compelled to persuade the customer to open source the software you intend to deliver?
... Sorry, I take option 3 -- I have enough hassles in my life.
1) Moral objection -- then do or do not (sorry Yoda). You may choose to express you moral view or not to client depending on whether proseltyzing is worth the effort/benefit ratio. If you fail to persuade, do you turn down the job?, if not, see point 3
2) Don't want to support -- then don't support, let customer know this, and why (at least if they ask). If you feel OSS makes a different in support, see point 3.
3) Anticipated benefit to customer -- explain your view of benefit, let customer choose.
4) Want to use exising OSS, see #3
If all you want is additional bullet points for #3, I'm sure you'll get plenty of opinions on slashdot. But, I would recommend sticking to things I believe in and understand (preferably have experience with) when making the case for OSS.
Hmm, point 3 seems to be pretty important. Give the customer a rational (or emotional) basis for making a decision. And let them make a decision. It's their money, their project, not yours. Of course, if its a moral issue with you, don't violate your morals. Don't come crying to anyone if you have to sacrifce though, high morality requires that you be consistent and be willing to accept the sacrifice it may involve.
My life is complicated enough without having to convert others. Matters of religion, politics, etc. are very similar to the arguments we coders get into -- We believe strongly in what we believe, for waht we believe to be good reasons, others believe just as strongly differently. You may convince some, other's you just make mad.
I may believe it's worth arguing religion (save their soul, or save the waste of their time/beliefe in myths, not saying which i follow). Politics -- you get morality and economics. But coding
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.
Really.
This is fairly common in contracting actually.
IN many kinds of contracting at that.
For instance.. construction. Often when you hire someone to come in and renovate your building, they do up blueprints of the finished design.
Generally they own these prints, not you. Sure, you were paying them along the way, but that was for labor and a result, not everything in between.
Just the same, if you pay me to write you some software, you do not own everything I think about in the meantime by default.
The terms of who owns what IP has to be set out in the contract, otherwise it's far too ambiguous.
If a company comes to you with a deisgn and they just want someone to implement, odds are they aren't going to let you keep the copyright. On the other hand, if they are merely paying you to deliver a solution, then copyright can stay with you.
It really boils down to what they want.
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.
If the client agrees to make the work open source, then their competitors will be able to use it at no cost. How is that in your client's interest after they paid you to develop it?
What makes you think that the open source community has any interest in supporting the custom application that your client is paying you to write?
Your client will already own the code, so they can give it to whomever they want. Why would it be in their interest to obligate themselves to give it to any more people than absolutely necessary?
I've been doing software consulting for 20+ years and, forgive me for being blunt, but you sound like some kid on one of his first consulting jobs. You seem to have this naive view that you can write code, throw it over the wall, and run. You can -- once or twice. Then the word will get around that you don't support your clients and the work will dry up.
If you want to participate in the open source movement, do it on your own time. What you're trying to do is like someone who volunteers with Meals On Wheels and then expects to make the delivery runs while he's on the clock at his job.
> 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.
- The contractor owns everything; customer gets license to a binary
- The contractor owns everything; customer gets license to binaries and the source code under some circumstances (such as contractor unavailability)
- The contractor owns everything; customer gets license to use and modify binary or source for any internal purpose
- The contractor owns everything; customer gets an unlimited but non-exclusive rights to binary or source.
- The contractor owns everything, but agrees on limitations on reuse or redistribution; customer gets some license from above
- The contractor owns nothing; it's a work for hire, since the customer contracted for the work rather than a service
- The contractor owns nothing, but the customer grants certain rights to the contractor, such as limited reuse of modules.
- Ownership is mixed, with some parts retained by either sides.
It sounds like what you need to do is agree with your customer what their expectation is on licensing, and get that in the contract. For example, if you own the work but agree not to disclose certain modules dealing with business process, it's clear to both sides what you can and can not disclose later. That may mean reuse on other contracts, provision to their competitors, or release to the general public.In general, the more restrictive the customer rights to work performed, the higher the rates.