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?"
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--
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 disagree with this. It depends entirely on the contract he makes with the client at the project's inception. If the agreement is that he supplies neither source code nor support, that's the ethical result. After all, I have no right to that copy of windows that came with my computer -- the license says so, even though I (indrectly) paid for microsoft to make it. Yes, contract work is a somewhat different situation, but the same principal applies. If he can convince the client to let him put it under some Free license, there's nothing unethical about that, and more power to him.
As a side note, putting it under a Free license (GPL, BSDL, whatever) doesn't necessarily mean he's going to release the source to the general public, or even at all. With the GPL, he only has to give the source to anyone to whom he supplies the binaries.
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
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.
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.