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?"

Just make sure you own the IP

[rfreynol]

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.

Open Source Policies

[Bouncings]

I've done only very limited contract work and at that, it wasn't Open Source. I think it really depends on the client, as the people I was working with hired me specifically because they were a Windows firm and didn't want to bother themselves with some Unix stuff that came their way from an existing client. For them, of course, it would have been impossible. But I can speak in regard to how some companies would react in general.

If you're working with a firm that's more familiar with the a community or is part of a larger scientific community, it's another matter. Some firms view releasing open source software as almost a promotional effort and you might egg them to develop an "open source policy" to satify their concerns.

Board of director types have bazaar stigmas and FUD like "won't we have to support it," "won't it give away our business model," and so on. You can address those questions by suggested an OSS policy. The policy basically comes down to how and when they'll open source software. For example, they won't open source software that would be directly useful to their compeditors. When they do, putting the employee email addresses won't be allowed, as it will burden them with emails. Open Source projects shall be included on another website, etc etc etc.

But they will be more warm to a policy than simply deciding to open source things adhoc -- so if you give them a policy to address their concerns, you might have better luck.

And of course if your Philip Greenspun [greenspun.com] good, you can TELL them it'll be Open Source. :)

2 cents.

Re:Emphasize the benefits

[Joseph Vigneau]

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.

No, since they have the source, they will provide it to the "anybody" you mention to fix/enhance/etc. I've been that "anybody" many, many times.

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.

This is just not true. They paid for your time, they own the source. You however, can go off and reimplement it at your next client... Remember, you didn't just get paid for some text files, you got paid to transform a set of requirements into a tested solution... This includes testing, debugging, looking on #dumbass for help, etc.

I've done this in the past

[mossmann]

sample language:

The software will include Open Source components for which neither CLIENT nor CONSULTANT will hold exclusive copyright. CLIENT will be granted an unlimited license to use the software. The right to resell the software will be granted but will be restricted by the terms of the GNU General Public License (http://www.gnu.org/) and/or other Open Source Initiative approved licenses (http://www.opensource.org/).

This particular case was for a project which I knew would include some custom code in addition to some pre-existing open source components, but you could apply the same idea to 100% new code.

How about extending an existing OSS Project?

[Fapestniegd]

How about instead of writing something from scratch, and open sourcing it; you find an existing OSS Project and extend it to do what your customer needs? There is a better chance it will be maintained when you are done with it, because it is already being maintained. If we all did this we would have a few enterprise level Apps that kick ass instead of a bazillion that are half written.

But please don't bother open sourcing anything if you (or no one else) plans to maintain it.

There are enough dead projects out there already. Don't add to the graveyard.

Re:Actually

[SideEffects]

Standard practice to keep ownership?? Out of the 16 years I've been writing software I've been contracting all but 4 of them. Only once have I every not had to sign an agreement that stated that the company I was contracting for did not retain full ownership of what I produced.

So the question is "How do you get around this?" I'd love to know, because from the contracts I've had (mostly large telco's) it was either sign the paper or I don't get the work.

Re:Emphasize the benefits

[stubear]

I'm not sure how software code works but as a graphic designer I most certainly own the copyright to my work unless otherwise stated in the contract. Contract does not mean work for hire. If it did then the company would be responsible for paying me benefits as top of my fee.

If I design a logo for a company I state up front in the contract what they can do with the logo. For instance if they were going to just use the logo on a web site I would charge accordingly. However, if this logo is to become the company's entire identity system I charge a dfferent, more lucrative (for me) fee. I can't turn around and sell this logo to another company but as I own the copyrights to the logo, I can include it in my portfolio without the company's approval.

Re:Actually

[NutscrapeSucks]

I've been doing this for a while and in something like 90% of the cases the client proactively demands ownership of the code. And it's Work For Hire, so that makes sense.

This can get tricky because you might want to use some of it for in house code libraries and the like, and in some cases they have objected to using any pre-existing code and/or using any of "their" code for future projects. Yes, this affects the price, and yes you should get a contract signed that covers all of this.

Furthermore, there's the matter of good business sense. Even if you do own copyright, giving away what you just sold to your clients competitors doesn't sound like a good idea. It causes ill feelings when a developer is selling a app they were paid to write -- much worse if they just posted it on their website.

If I were a business..

[Anonymous Coward]

I wouldn't be open sourcing random projects under the GPL. Why should I pay for development, why should my stockholders pay, when ultimately, our competition will say, "Hey! That's neat!" and snag it for free? Corporations don't like feeding free cash to their competition, and this is pretty much the equivalent.

But then, that's assuming my imaginary corporation (We'll call it Taco Corp) has the resources to say, "No, thanks." and shove the development onto in-house coders.

Even if Taco Corp didn't have those resources, I'm all but certain that they could find someone who would agree to their terms.

And, in truth, this is all FUD, but FUD that is not often rectified. By shoving the program under the GPL, I'm not obligated to release the source code. If the program is ultimately being used in-house, the only binaries being distributed are with the company - and they'll most likely have the source anyway. (And I assume this is what we're talking about - in house programs. I can't see why a company would be outsourcing coders for a product they're going to sell!)

There are benefits to this sort of thing. When the program ultimately falls into disuse, the corporation can gain some flag waving from the open source crowd by easily releasing the source and binaries to the public. The company has no use for it at this point, so where's the harm there? They'd just delete it anyway, but instead, they toss it to a foaming community that will shout "Taco Corp ROCKS!". Free publicity/good deeds and whatnot. ;)

Even if they make severe additions to the code, and the final program is still in use, they can, AFAIK, release an earlier version to the public provided they're not shipping out binaries of the changes they've made.

Let's face it; we are foaming lunatics. We have to be - we have to support companies who even toy with the idea of releasing the source to products. We have to show them that they can gain from the good PR they'll get from doing things like this.

While it seems like they're getting the lion's share, in the end, we win.

Recap of some of the above

[Jay Carlson]

I know I'm tempting moderator retribution but let me summarize some of what I see above:

• 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.

You do _not_ open source truly custom work,

[hashhead]

The short answer is you don't. Open sourcing works great for generalized systems, the 'more eyeballs' maxim only holds when there are more eyeballs, and you only get them when the system is generalized enough to be of interest to anyone besides you and your client. True custom work should only contain your client's business logic (and maybe design) which as mentioned in other posts above is not a good thing to open source for security and business IP reasons.

I myself do custom work for small businesses for a living. I'm a Java guy who's into open source, here's how I typically work:

• Gather requirements duh. You gotta find out what they really need, obviously. Not always clear, but that's part of the job - translating their requirements on a business level into concrete development action.
• Sell the Client on pre-existing OSS frameworks In my case, server-side web development w/ Java, this almost always includes Tomcat [apache.org]. Not GPL'd, but hey, certainly better than the other, proprietary crap. Lately I've been doing more involved projects, so I've been pushing JBoss [jboss.org] as well, which _is_ GPL'd and frankly fantastic as well. I try and run these on Linux w/ Apache if possible. I find this is not a hard sell - the main points being no licensing costs for them, more stable tools than the proprietary solutions, etc. These are also popular well-known systems which always makes business types feel better than unknown sketchy things.
• Use pre-existing OSS libraries for the general parts For me this means class libraries - if I need logging I use log4J, if I need XML processing I use Xerces, etc. (well bad examples since they're APL, not GPL, but you get the point). I also make this clear to the client, they usually like the idea as it saves development time and thus their money. I also let them know that any code I write to improve these libraries goes back to the project and is not the ownership of the client. This is also not a hard sell - my client doesn't care about owning parts of a logging system, it's not his business. This is how I get to contribute to OSS on the client's dime.
• Write the custom bits Given the above, all that's left is business logic and design. For me this means incorporating the client's business logic in a bunch of servlets of EJBs, and their front end design into a JSP page or an XSLT template. I typically give them full IP ownership of this - yes, I charge a higher rate b/c of this, and frankly this shit is useless to me outside of the current project anyway.

Bottom line: if what you're coding for your client has general value and is thus worth open-sourcing, you're probably reinventing the wheel which pegs you as a beginner in this business.

Re:NO you don't - Actually you do, if you're scum.

[Rary]

This is decided by how you establish the relationship between yourself and your client. If you are being hired to write code, you are the client's employee, and everything you create while under his employ belongs to him, not you. He should, in that case, be paying you for your time. If he is simply buying a product from you, then you should set a price, probably fixed, regardless of the time it takes you, and then that is the price for the product. In that case, the code belongs to you, and you license the product to him. Now, you have every right to open the source after selling it to him. However, to do so would make you a complete scumbag, and if I were the client, I'd kick your sorry ass for doing it. :)

He thinks he's buying a product from you, not subsidizing your personal open source development. I'm curious, how do you feel that this will be in his best interests? His best interest would be for you to become his hire, develop the product, and walk away leaving all your work in his posession.