Be sure to get a contract spelling out who owns what, whatever details you decide to accept.

By factoring the code into different files and modules, you can seperate widely applicable code from site-specific stuff. Try to retain ownership of the general code, and let them have the part that is specific to their site. Templates are very useful for that.

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.

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.

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. :-)

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

The question of code ownership should definitely come up before you begin any work, and putting it in a contract as Zaxo suggests is definitely a good idea. It's certainly ethical as long as you discuss it with the client beforehand, and it's a good business practice if the code you save proves worthwhile sometime down the road. On thing to keep in mind is that this is just another bargaining chip to be assigned a dollar value - how much is it worth to them to keep exclusive ownership of the code? What is the code worth to you?

Having done some similar work in the past, I'd say that the code can stay with the employer in exchange for you getting paid a bit extra than if the code had also gone with you. I've done a few projects in the past, and nearly every time when I get to the end of it I think "Hmmm. If I had just conceptualized my design in a slightly different way, this could have been much shorter/more powerful/easier to understand." While I expected this to happen less as I learned more things and matured as a programmer, it's actually happened more and more as my bag of tricks has grown. :)

Also, it's a very good idea to negotiate the right to put some of the code you write in your personal portfolio. As the linked thread demonstrates, those code samples can come in handy down the road.

I agree with most of what has been said by others.

What I would tend to aim for is:

• I own the code
• Paying the bill gets you a license to use the code in perpetuity
• That license includes the right to alter the code
• It doesn't give you the right to sell the code
• The data belongs to you

Hugo

I think these are good guidelines for code that you have developed and absorbed the costs of research and development. But if you are getting paid to write the code then I think common sense (and most contracts that you will have to sign to close the deal) says that the client owns the code, since they paid for the R&D.

I always agree to give ownership of code I develop specifically for clients to them, but I charge for maintenance. This works well, because the client does not feel like they paid for something they don't own, and because I wrote the code I am defacto the best choice for maintainer (I don't obfuscate on purpose to achieve this, as that would make it more difficult for me to maintain it).

Standard disclaimer: I'm not a lawyer, and I don't even pretend to be one (most of the time). These are just my personal feelings on the matter.

Is it ethical/good business practice to say that I want to own all of the code.

I would tend to look at it sort of like an independent contractor versus employee relationship. The simplest test is who owns the tools. In this case, the main tool is the computer (and also possibly the software). So, are you developing the code on someone else's computer, or on your own? If on yours, I think it wouldn't be too much to ask that you maintain the rights. If on their computer, it would make me slightly more uncomfortable with that.

Of course, no matter how you feel about that matter, you will have to make an agreement with the other party. I heartily agree with Zaxo's advice of a written contract.

You are welcome to take whatever approach you like. However, I'd like to make a point from the other side as it were. I work for a large company who for various reasons outsource much of their development and who tend not to get source code rights (stingyness being one of the reasons). Were I in the position to change this I would. As a businessperson I would never allow source code rights to a critical business system to belong to an outsider. Theres two reasons for this, the first is that it means I am funding the R&D for a product that I cannot prevent from being sold to my competitors. The second reason is that it could at some point prevent me from realizing my business goals. Since I wouldnt have the source code rights if I needed a change then I would be putting myself at the mercy of the third party vendor to provide that change but without any guarantees that the vendor will prioritize my requirements in the same way I would.

I've watched both of these issues play a critical role in my firms competitiveness. Changes that source code ownership would have made trivial have dragged on for months costing us market share and vast sums of management time to resolve. Likewise features developed just for us have appeared in the mainline rollout of the software which has been delivered directly to our competitors.

What does this have to do with you? Well nothing much, except that if I were the guy making the decisions and you said you would end up owning the code that I paid to have written you would be laughed out the door. I wouldn't want to do business with someone who so completely misunderstands the role that software plays in the modern businessplace and who obviously prioritizes their own benefit over the best interests of my business.

The bottom line is that its reputation you want to develop, not an inhouse store of code. Make a name for yourself as a good conscientious developer who does good work and holds the clients interests above all else and youll make a lot of money. Come across as a schemer who wants to get paid to make a cake and to keep it and you wont. At least in my opinion anyway.

I work for what some may call a large company who is not only a large outsourcee, but we also write "off-the-shelf" software - stuff that you may not get that much say in how it works.

It's the latter part, an off-the-shelf portion of the company, where I work, so I'll focus my rebuttal from that perspective.

We have many customers. Some large (multi-million USD transactions), some small (a few thousand USD transactions). And many of these - both small and large - ask for specific features. Generally speaking, as we have well over 600 people working on this product (probably about half of them developers, the other half trying and failing miserably to keep developers from tripping over each other), few requests come in where the customer is fully funding the development effort, nevermind giving us a rate of return on investment that would be acceptable to the corporation as a whole.

Most new features go in at a loss, in the hopes that it not only means a long-term relationship with that customer, but that the new feature will also help capture business elsewhere. I'm not generally privy to this type of information (I'm one of the devlopers tripping over other developers), but I have noticed a few times where different customers have come up with the same request, allowing us to sell to both of them, with a single unit of work. I would have to imagine it happens way more than I know about.

So, yes, that feature you so desperately want is going to be sold to your competitor. It's also going to be sold to many more companies that aren't your competitor, but who are helping fund this development through their purchase of that feature. This is not just stingyness. This is cost effectiveness. The value of that feature to your company may not be high enough to warrant paying for the whole feature outright and still maintain a reasonable return on investment. But it may be high enough when amortised over all the sales your vendor will generate from the feature, and, since you had a say in the creation of that feature, presumably it will fit your processes better than anyone else's, which still gives you an edge over your competitors.

That had better be a huge cost saver for you to want to purchase exclusive rights to it, because the vendor/contractor will not be able to make a larger ROI than whatever you're paying them, so they need to increase the price to pay for all the future ROIs they are going to miss out on.

Thanks, I appreciate your explanation of the other side again. Maybe I shouldn't have been so general in my original post. I think the issue is how critical is the system, and how commoditized it is. In some businesses the computer systems are in many ways the business. They can't be ripped out and replaced without huge investment. In such a situation the ability to change the software can be critical. Relying on a single vendor for all changes in such a situation means that you are essentially ransoming your company to that vendor. Which just doesnt seem to be good business sense.

---
$world=~s/war/peace/g

Ownership != Right to Use != Right to Resell. In other words, it's quite possible to retain ownership (preserving my right to reuse the generic portions of code I develop) while at the same time granting non-exclusive rights for in-house use to the company. They get to do whatever they want with the code for their own purposes and so do I.

Well presuming that i still had source code available to me then I suppose i wouldn't laugh you out of the room. But I suspect I would still insist that anything that encapsulated my business processes would remain my posession alone.

Update: Just to make a point I dont have a problem with the use of open source and the process of contributing back modifications made to it. Nor would i have a problem with opensourcing much of the generic part of a product developed for me. I do mind having that code be closed source and not available to me as the customer who funded its initial development.

---
$world=~s/war/peace/g

I've had Web & Software Development: A Legal Guide (ISBN 1413300871) from Nolo recommended (and I think I've mentioned it in similar threads). I don't have a copy yet (sitting in my wishlist on amazon still) but they're a pretty well respected outfit for legal advice books and I've got a couple of their other books.

Thanks for all of the responses! I have another question: Some people say whatever I do, it's important to get it in writing. It seems other people are saying that I should have an agreement where I can keep the more generic works, and the business specific work they can keep. Is there a good way to define this in writing? Or if it is termed like that, "generic works" and "business specific works" or something, is that good enough? It almost wouldn't seem like it, but then again, I don't have any experience with this, so I'm not sure.

    -Bryan

A few points spring to mind here. First off, you are becoming your own company. You may want to incorporate yourself for tax purposes. Secondly, I'm not a lawyer, nor is there likely to be a lawyer member of PM that is willing to state they're a lawyer and give you legal advice (there may be lawyers, but they're not likely to give free advice, and that's not a slight on the law profession). So you may want to hire one for legal advice on contract law. However, before you do that, it really sounds like you need some project management course. A good intro course into what you need to do was something I took back in University - my "software project course" which did a really good job of talking about getting requirements, documenting what you're going to do, etc., prior to actually doing it. We spent 10 weeks of the course gathering and documenting requirements, 2 weeks coding it, and the last week was finals/presentations. And, to be honest, those ratios are actually not that far off my current experience in the field, 7 years later.

You're describing that you're finding yourself propelled 7-10 years into a drone's future (I would classify myself as a drone for the purposes of this thread - someone working for someone else, not themselves). You have no boss - you are your own boss. You have a client. You want your client happy so you get repeat business. That's called management in most other corporations.

To become an effective manager of a project, you should learn a bit about project management. It's a tried-and-true formula for working through a project, whether that project is organising a Christmas party at work, or it's building a skyscraper. The more money and risk associated with the project, the more important it becomes. CountZero pointed out that you should get all the information first. He's right. You start out with a verbal agreement on concepts, but you end up with a written agreement on concrete statements.

I'm actually taking an e-learning course that my company has given me on CD on project management. There's a lot there. But I can definitely see where it's useful. That may be a bit expensive for you. So, one cheap way to learn this stuff? Get a job doing it. Let someone else pay to train you ;-) Like I said, if you get a regular "drone" job, perhaps in 7-10 years you'll be doing all this stuff, and be better able to handle the responsibilities you're facing.

My brother-in-law started his own company just recently (not in software). He knows the business inside out, the industry he's in - he used to be employed in the field before he struck out on his own. What he doesn't have a clue about, however, is the business of business. If he's not careful, he's going to have his company collapse - from being too successful. ;-) IMO, it's worth it to pay for professional services: lawyers, accountants, etc. And to learn project management.

What I don't want this little rant to do, however, is turn you off your opportunity. You're going to have an old acquaintance as your first client. Getting that initial verbal agreement that some of the code (business-specific) will be his, and some of the code (non-specific to his business) will remain yours, and then getting it written down later when you know more precisely where that split is (but before you start writing anything) will probably be less painful than it could with an adversary that doesn't know you personally. Your acquaintance is looking to you as someone to build a relationship with where there already is something to build upon. So you probably have a fair bit of leeway of good faith upon which to negotiate. But still get it in writing at some point before you turn over the code. Use the proceeds from this arrangement to help pay for some project management course(s), though. It'll be worth it if you wish to continue on your own. :-)

Thank you for your response! I've read through this a couple of times trying to digest everything you've said. I'm always willing to listen to advice, process and evaluate it. And I think what you've given me is good advice, too.

Just a few notes for clarification really. The first is that, even though I am "becoming [my] own company," I'm not really intent on doing this often anytime soon (especially since I have two years of college left), and I don't think it would be fiscally sound to hire a lawyer for such a small, possibly isolated project. Oh, and I don't plan on being like your brother-in-law. I don't have enough guts to think I'm good enough to pull down enough money with my meager skills to survive, much less have the business skills to make it possible. Nope, I actually have a good job this summer (by good I mean I should gain a lot of experience), and plan on "being a drone" when I get out of college, too.

The second is that I don't consider myself an expert on project management, but I have taken a course in my college (called "System Analysis and Design") that was offered by a professor who I respect immensely, and who has had very recent experience in the profession (by that I mean, she isn't just a professor who has been out of practice for the last 20 years, instead she has been doing it for a while, and just this year took a job to teach). Obviously there is ALWAYS room for improvement (in everything anybody does), but at least I'm not walking into the project thinking I'm gonna sit down, start coding, and get it done right.

Once again, I do appreciate your response, it has been helpful, I hope I don't sound as if it isn't helpful. I just thought I'd let you know where I'm actually coming from here, so you don't think I'm some fresh-out-of-college greenhorn striking out on my own into uncharted waters, just waiting to be beat down with experience! :D Thanks again!

    -Bryan

Is there a good way to define this in writing?

The easy solution is to make a list of the "generic" modules/scripts or a list of the "business specific" modules/scripts. Of course that means that you must be able to already know quite a lot of the project up front so you can make such a list.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Presumably you charge by the hour, why on earth would you want anything hanging around which might DECREASE the amount of time (I.E. $$$) the next project takes?

Because when you're bidding competitively for work being able to do more stuff in a smaller period of time is a good thing.