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.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
If the contract with the client states that all the IP you create belongs to the customer for whatever he wanted to do with it, then there's little point forcing the customer to do something specific with it.
Either way, the customer will face the problem of later support and evolution. If he cannot get hands on you, he either has to hire someone for hard bucks, or he donates the stuff to the public and crosses his fingers that someone will take care of it. Which does not necessarily mean the necessary work is done then - this depends on how 'hot' that piece of software actually is. You might have problems making some 08-15 applet Open Source in the hope of getting volunteers.
--Ben
Use The Source, Luke!
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.
Depending on what you're attempting to develop, you may be able to develop the code faster using code fragments from other developers. Of course, if those bits of code were GPL'd, you'd be obligated to make your code available.
Depending on the scale of the project, and the odds that the code segments you need already exist, you have to determine how much time savings you'd have by researching previous GPL'd projects over writing it on your own.
Although many companies wish to retain the rights to software you write, there are very few people who don't re-use bits from project to project. [Hell, it'd be downright foolish not to use already written and tested code]. As such, on any programing project I take, although there might be an NDA, I still retain the right to re-use the code in any further projects. Otherwise, I run into the risk that my common code library will be locked down once it's in use in this project, and I'd rather not take the project.
[even if they paid me more than my going rate, I'd be worried about using knowledge that I got from the project towards another project, and getting sued.]
Build it, and they will come^Hplain.
I assume you told him the part about not supporting the software you write, correct? Open sourcing software is not the magic pixie dust you apply to a half assed job. Look through Sourceforge at all the abandoned projects -- the world is not interested in finshing the job.
I am not a number! I am a man! And don't you
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.
No offense, but this is one of the stupiest ideas I have ever heard. When you develop code for a client, the client then owns the code. Simple. If you cannot support your own code, at least they have it so they can give it to somebody else to support and maintain.
Remember though, that your name is going to be associated with that code for all future developers to see. You better take some time and carefully document everything you do. Your code is a personal reflection of you and your work ethic, so you don't want people to get the wrong idea.
Me thinks the guy just wanted to get on the front page of Slashdot, and he figured the phrase "open source" was a good way to do so.
There ain't no rules here; we're trying to accomplish something.
I have to say one thing about your notion - If I were the company thinking about hiring you to write the software, you wouldn't be far enough along to be asking this question.
I'd have fired you long ago because you won't continue to support your work. (Of course, writing an app so good it never NEEDS suport is another matter altogether.) It's completely ridiculous to assume that publishing the source under whatever open license will instantly give you an army of developers willing to continue to support and continue developing on the application for free.
Normally what you'd do is write the opensource app, and then a compnay would hire you to extend and support your own application inside of their project - in that case, then you could start talking with the compnay about whether the changes would be opensourced or not. In this case, you're turning the whole thing on its head.
Still, you may be right in that opensourcing the project would be a good idea for the company - but that is a decision that should be made INDEPENDENT of the development itself. The company should approach the decision with the assumption that the package is already developed, or even better AFTER the package IS developed. Most importantly, do not give this company any kind of false hope about what opensourcing the software will do. If you are a developer who actually runs any opensource projects, I don't really know why you would even think of recommending this so soon.
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
Remember, open source does not necessarily mean free as in beer or free as in speech. A lot of business software licenses allow purchasers of the software access to the source code, but it strictly forbids redistribution of the code. Such a license is open source yet not free as in beer and certainly not free as in speech.
Your best bet is to give the client the source code. You need to choose whether or not you want to retain rights to the source code, or give all rights to the client. Most contract programming jobs I've ever heard of require that the client not only gets the binaries and documentation (and sometimes training) but also the source code and complete rights to the source. That way, you don't depend on you for incrimental improvements. They can hire their own developers to do that if they have the source.
Honestly, if this is a custom job that is likely only of interest to the client (and perhaps the client's business competition), you are ripping them off by not giving them the source. But again, it's your job to choose whether or not you want to retain the copyright to the code for yourself, or give all rights to the client.
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.
Yeah, but that construction analogy isn't entirely applicable. Sure the architect/engineer etc own the copyright on the blueprints, but the customer owns the building.
Applying the analogy, that would be more like the programmer owning the copyrights to the specification and use cases etc, while the customer owns the software.
I would think that contract programming would be a 'work for hire' kinda deal.
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.
Your client could be convinced to open-source something if:
On the last point, they might agree if you can show the client that what you will be writing will indeed be picked up by some other people/companies. These other people would be interested in what you wrote because they would also need what you wrote, and the improvements made by others can provide a direct benefit to your client.
I realize that the logic is somewhat circular here. You have to prove it's good enough for everybody, and then everybody else would do something that's good enough for your client. Presumably then they would also need the technical expertise to actually use what you did.
The other problem is convincing the client that there is nothing proprietary to them in the software. If they hired you, it usually means they don't have enough in-house expertise to decide this, and their decision will be no.
If this gets open sourced, your name would be on it, and that means you would be on the hook to _everybody_. It does not absolve you of the responsibility of maintaining the software and defending your design decisions. In fact, it makes you more responsible.
I have worked with companies who thought about this long and hard, and typically did not do it. The exception was software that was end-of-life, with maintenance being cut, and the costs amortized. At that point, unless one of the points above applies, it can make sense because open-sourcing internal software is a hedge for maintenance provided several others start using it and work on it.
On the IP-side, the work you are doing is considered "work for hire." This means your client owns the IP, all of it. It's like being an architect: you draw plans, and if the client goes ahead with building the building they have full rights. Yes, your name is on it, yes, you have liability exposure, but they own the work, because they bought it from you. The only way to get around it is if the agreement between you and the company states clearly that you are giving them a license as opposed to performing work for hire. If you want to be really clear about what you're giving away, get a lawyer - your client likely has one too.
just my half-cent.
- - - Non Caffeine Drink or Drink Error
The client is paying you for your time in developing an application.
Not always. In my experience, there are several types of customers for contract programming:
one who wants a tool
one who wants a new product
Those interested in a tool aren't normally interested in the source code, other than as a form of support. Normally, they're not paying you for your time or for ownership of the source code. They want a tool to do a job and are willing to pay for it.
Many of them know enough to ask for the source code so they can get bugfixes if you happen to be run over by a doughnut wagon. Even in this case they usually don't want ownership of the source code--they just want a license to it.
Normally the people who want you to create (part of) a product are the ones who want you to relenquish the rights to the code. If so, make sure you charge them accordingly. After all, for my customers who buy a tool, I can use significant chunks of code I've used in many other projects. I can't use my subroutines for customers wanting exclusive rights, so not only do they pay for the extra time in reinventing wheels (or the purchase of third-party libraries to do tasks), they also get to pay for the exclusivity.
As an (admittedly ridiculous) example, suppose a secretary wanted a word processing program, but no word processing software exists yet. She could pay you to write one for her. She doesn't really want to sell word processors or anything, she just wants one to help her business. You could write one for her, and she could write you a check.
For that money, they should get at least:
1) The binaries
2) documentation
3) support
No argument there...
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.
Giving them support can come in many forms, one of which is making available the source code so they can get someone to fix it if you're unavailable.
But THEY should choose whether to open source the code or not. They paid for it. It's their decision, not yours.
cyber_spaz
"Time flies like an arrow, fruit flies like a banana" --Karl or Groucho, I forget...
If anyone has ever had to deal with a Lawyer you know what I mean. Call the man to chit chat for 15 mins and you get a bill in the mail for his $450/hr rate divided by 4. No kidding. Why should your time be worth anything less?
Don't give your software away and don't sign away your ideas if you can help it(i.e. IP). Every idea in your head is worth money to someone even though you may not realize it. Telling your client that you recommend giving this software away will make them feel insecure and they will also be reluctant to hire you again to maintain and extend the software. Also, If the software truly is 'unique' it is another feather in your hat that the next contracter DOESNT HAVE. Don't work yourself out of a job. Know the difference between what is work and what is your hobby.
Regards,
Peter
www.alphalinux.org
Why would the Open Source community be into it?
If it's useful, and people hear about it, they'll use it.
And since he's doing it for a client, it's got a headstart in that he will actually produce a working model, rather than one of those projects that never even gets to a beta version.
Why would the company open source it?
First, they need the product. They need a working tool, and it's not something that is currently available (to their knowledge). So they are going to develop it, regardless of Open Source support to begin with.
But, that's all they need. It's internal, so they aren't going to sell it to anyone else. They wouldn't be losing any income.
It will need maintenance. It may need small, ongoing maintenance forever - somethings are like that. It sounds like original developer may not be available.
If they opensource the product when it's been developed, they haven't lost anything, they still have the tool they wanted.
Meanwhile, on the principle maintenance costs just keep accumulating, and can add up to more than the cost of the original product over time (depends what it is of course), if it goes opensource, the maintenance costs get taken on by the other users as well.
The company benefits from any improvement or maintenance that other users make to the product, with no extra cost to them.
---- I've fallen, and I can't get up.
Uh...good for you. I can't stand "you are lucky" assholes, because it confuses hard work and talent with some magical "luck". i.e. We're "lucky" that we're in the developed world rather than some backwater shithole where people live in mud huts because they're too stupid or too lazy to strive for better, and they have 20 kids each ensuring a perpetual cycle of poverty in their craphole nation.
There are a tremendous number of employed, diligent, hard working, talented people in the tech industry right now: Hundreds upon hundreds of thousands of them. Just because you are having tough luck, don't confuse that and presume that everyone else is "lucky" because they aren't in your shoes.
Here's the easiest way to put the argument: sure it's harder for the attacker, but it's like using a Kryptonite lock and duct tape to attach your bike to the bike rack. Sure it's more secure, but not worth the effort. If you think you need the duct tape, maybe you should lock your bike in a better neighborhood and spend your time walking an extra 4 bocks or something instead of spending that same ammount of time attaching and cutting duct tape. In the same way, you should spend your time properly securing and maintaining all of your boxes, setting up proper cryptography, and enforcing strong passwords with proper limits on lifetimes. Try getting help setting up a firewall from MIT Network Security and they'll tell you to set up cron jobs to port scan your boxes and vulnerability scan your boxes instead. It's a bit extreme to discourage the use of firewalls, but I can definately see where thy're comming from. Just like Morris discouraging shadowed password files. md5 passwords and strongly enforced password complexity offer MUCH better seccurity than shadowed crypt password files.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
We are a custom software development shop using our own framework as a basis for delivering custom applications to customers.
We have an arrangement with our customers which works out very well for both of us. Once you factor in the incentives of both parties, this arrangement naturally leads to a happy situation for both parties.
We come into the relationship with a substantial framework, which we license to the customer under the GPL. As the relationship progresses, we build many components. Some of these components are specific to the customer's business process, and some are more generic. We retain all IP rights to the generic components, which we integrate into the framework and license back to the customer under the GPL. The customer retains all IP rights to code that is specific to their business process.
We maintain a code repository for each customer which contains their business specific code. These are typically workflow definitions, business specific data models, entry screens and reports, etc.
We also maintain a common repository for the framework, which contains all the reusable code (whatever we define to be reusable). We usually have a few projects going on at the same time, and this repository receives contributions from all of them.
The benefits of this arrangement for the customer are:
* Customer owns specific business process logic, UI elements, data models for their business, which means that they control their trade secrets and we can't go to their competitors and sell them the system they payed to custom build. In return, customer is solely responsible for paying someone (usually us) for maintaining and enhancing these components as their business changes.
* Customer does not have to pay to build a major system from scratch. They get a tested and tuned framework for free upon entering the contract, and only pay for customization, which is a process we excel at. In this fashion, we can deliver a return quickly and with minimal expenditure, since we don't have to build much infrastructure.
* Customer gains the benefit of framework enhancements for other customers. Over time, as contributions are made to the core framework, more and more reusable functionality is available to incorporate into our custom solutions. This has the effect of bringing sophisticated functionality into the customer's price range. In effect, all our customers indirectly share the cost of maintenance, tuning, and additional generic functionality.
* If we go out of business for some reason, the customers have all the source code they need to achieve continuity.
The benefits of this arrangement for us are:
* We gain a powerful framework that is tested and tuned across multiple production deployments.
* We can out-bid competitors who need to build things from scratch, who base their work on proprietary software which they cannot enhance or control, or who must recoup massive amounts of R&D , marketing expense, and capital risk.
* We spend our time solving unique business and technical problems, as opposed to re-coding functionality for multiple customers simply because we don't own IP.
* We spend very little time on maintenance because most of the difficult code is maintained in one place- application specific code is mostly declarative.
* We do not have to pressure customers to buy upgrades. We keep customers current as part of the development process.
We have been modestly successful using this model, and people who work with us, both developers and customers, are happy and getting good value.
Once caviat- our customers tend to be in a line of business other that software development, thus they care less about owning software IP than than do about streamlining their business processes.
Hopefully this will inspire some ideas.
Mike
Well, say I can use a lot of GPL code as a starting point for the customer's project.
In this way, I don't have to code everyting up from scratch or buy a lot of possibly expensive libraries and modules.
Or, I may have written a similar package in the past and can use that as a starting point.
There are many reasons why a client will pay me to do custom work for them and still be happy to let me GPL the result.
If you happen to not run into these situations, so be it, but others (at least I) do all the time.
A Nony Mouse
You are the author of the work and therefor have the copyright unless the you assign it to the client or unless it is a work for hire. Since your are not an employee, and it is not a collective work, etc. (See http://www.loc.gov/copyright/circs/circ09.pdf, warning: PDF) it is not a work for hire. So, in theory you can do anything that you want with it.
That said, you have an ethical obligation to work out a resolution with your client.
(Assigning it in the contract is also considered a work for hire.)
In theory, theory and practice are the same, in practice, they are not.
Those are all nice reasons for Open Source code. The problem is that none of them apply to a business that is about to pay thousands of dollars for a person to develop software tailored specifically for that business.
Compromise.
The client gets exclusive rights to the software for two years at which point the software becomes open source. This would manifest in the form of a clause in the contract stating such.
This would give the client room to breathe against competitors or enemies seeking to compromise their software, gain from their expense, etc. while still allowing for the continuation of the code in the open community. If the code is interesting enough to still be viable in two years then it will persist.
This is very similar to having someone license technology but instead of losing their rights to the tech they merely have to share with everyone else, though not any additional modifications they have made to the code in the meanwhile.
This would also mean that the code would have to be put into escrow in order to meet the requirements of the contract for both parties and as an insurance measure for both parties.' Escrow 'meaning that a 3rd party would have a copy of the original code and would release it into open source according to the contract despite any intentions of the two parties otherwise.
Seems like a lot of effort but if you think your code is important enough to the community at large then this would be worthwhile because of the checks and balances it imposes. The client would of course pay for everything.
A fool throws a stone into a well and a thousand sages can not remove it.