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

3 of 372 comments (clear)

  1. Standing on the shoulders of giants by teambpsi · · Score: 5, Interesting

    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.
  2. Actually by Srin+Tuar · · Score: 5, Interesting
    Its pretty standard practice to keep ownership of the code you produce on contract. Typically, its so you can reuse bits for different jobs.


    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.

  3. Re:Open sourcing it buys the client and yourself n by Xzzy · · Score: 5, Interesting

    > Leaving it up to the OSS community and expecting
    > 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. ;) Letting people do whatever the heck they want with the code.