in reply to On Code Ownership

I charge per hour. So people pay for my time, not my code. Still, in general, I try to get in writing that the buyer is free to do with it whatever they want, but so am I. This usually doesn't work - most clients request that nothing be disclosed. That's fine with me too, but then it ends up more expensive for them, because I have to do everything from scratch.

The ultimate form of code-reuse, even if you get paid for it, is CPAN. DBIx::Simple started as part of a paid project. I discussed the possibility of opening its source with my client, and after hating it at first, he loved it when I explained that this would mean he'd get updates for free. It has worked out very well practically, but not financially. I got paid for the initial versions, but not after that, while it made almost all my other work much easier. When paid by the hour, that isn't an advantage :)

Whatever you do, discuss the options and make sure everything is in writing. Some of my early projects were all done with complete ignorance of the juridical aspects of programming, and that has bitten me many times already. It really is a problem if it is unclear who owns the code, especially when you code modularly and want to re-use prior work.

Again, modules are great when you look at practice, but they do lower income by much. I'm still looking for a good solution to this problem.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Replies are listed 'Best First'.
Re^2: On Code Ownership
by cbrandtbuffalo (Deacon) on Jun 18, 2005 at 13:52 UTC
    I tend to agree with [id://juerd] on this one. You're likely to use plenty of CPAN modules, and that code has been donated for free to everyone, as has Perl. That spirit seems to conflict a little with a hard line on who "owns" other code.

    If it were me, I'd push for make sure you can share any generic code that might be useful. I'm not talking about the business stuff that might reveal something, but some module that might come out of your effort.

    I don't work as a contractor, but we hire them where I work. Our agreements tend to be verbal, not written, but we've had a long-term relationship with one contractor. We would never try to re-sell code, so that isn't an issue. We've had the best relationship when we keep the code he's written, but he can take bits and pieces if it suits him--and he asks to make sure it is OK. In one case some code turned into a module and ended up on CPAN as well.

    The only restriction we've had to include is that we don't get mentioned specifically in any code or modules that are shared. The main reason here is we don't want to get hit with any potential liability if someone down the road used a module, had problems, and wanted to sue someone. This requirement comes from the higher-ups as a sort of condition for us playing in the open source sandbox and contributing back.

Re^2: On Code Ownership
by Tanktalus (Canon) on Jun 18, 2005 at 14:55 UTC
    I got paid for the initial versions, but not after that, while it made almost all my other work much easier. When paid by the hour, that isn't an advantage :)

    Not necessarily. Because you're reusing and thus cheaper, you may get more contracts. You may be able to command more money per hour as a "premium" for fast, reliable service. Depends on how you describe it to the client ("sell yourself"). You may be able to do both - command more per hour than your competitors, but still come in cheaper overall. And, with your spare time that you have in abundance, you can find more contracts. :-)

Re^2: On Code Ownership
by pboin (Deacon) on Jun 20, 2005 at 13:15 UTC

    As convenient as it is to work by the hour, that's the genesis of the problem with lowering income by using modules.

    It's more work upfront, but I think you should take a look at flat-rating. My preferred approach is something along the lines of "it will take X to dollars to make this, that and so-and-so headaches go away". It's to my benefit that I've invested the time into learning good toolsets. So as long as the customer gets what is good value *for them*, does it really matter how long it takes me to make the headache go away?

    (Or, raise your rates. Take attorneys for example: They read documents, and fill in boilerplates for a living and don't blink at charging $200-$400 for their time. That's all due to prior investments in education and creating the boilerplates (a.k.a. modules.)