I'm going to guess that one of the best ways to attract high quality, experienced developers -- aside from running a smooth, mature, high-functioning shop to begin with -- is to quit treating your programmers with the same degree of legal inattention you give to your customers. Sure, customers will, for whatever reason, gladly give away all of their rights to sue you if something busts. All risk is theirs. Why they're willing, who knows.

Similarly, many to most if not just short of all programmers seem to be okay giving away all of their rights to their code, their ideas, and everything that goes with them. IP contracts often constrain programmers for life. What the coder makes in their shop stays in that shop forever, no matter what. Slashdot recently had an article on the topic: "Do you keep a code library? Do you take it from one employer to another?" I recommended using open source licenses to launder code, but why put yourself in a position you have to bother?

Anybody who really realizes the value of what they're doing wouldn't be so eager to give up their rights, I think. Nor would savvy companies trying to hire the best be so quick to make their new employees sign such a contract.

Imagine how much more buy-in you'd get if you gave employees the right to use code that they programmed three years after the code was written, as long as its use didn't conflict with the market of the current company/employer (defined on a case-by-case basis; that is, the coder would get specific exemptions from the legal dept. Yes, this does hope for relatively rational and reasonable employers, unf.).

You can quickly argue that giving away a codebase would give a coder reason to take off after, say, four years to build on top of what they coded up during their first year. I really don't think that'd be the case. What's most important is that you'd be paying your employees to not only work for you, but to work for themselves. You can't beat that combination.

My guess is that giving rights to your coders' code to the coders themselves would give you a number of benefits. First, you'd have much more modularly written code. People would want to have code that promotes reuse so that they can show it's theirs and use it for a project other than the one they're doing now. Your coders would take their coding much more seriously, knowing spaghetti code means the code is likely no longer theirs to claim outright (though you could certainly give them the rights to "surrounding code" too as part of a task description). You'd also see people take more care in their coding -- now they have a great reason for buy-in on their projects. Sure, you might miss out on some of their overtime hours as they furiously work on code they have at home, but you might be able to work out re-integrating improvements to that code back into your codebase if you're flexible enough and the new contract anticipated it. You could create a sort of "intracompany open source agreement" with your employees.

Furthermore, if your hackers do hit it big on the side, you've got two things to make yourself feel better about their loss. First, the code they wrote for you was pretty danged good. Second, you've got a contact in a business that's coding in styles that match your culture. Heck, buy them out if they do good enough. In any event, use their success as a potential means to create more business for your company! I was part of a company that apparently got bought out in large measure because we used the same accounting software as the parent. Imagine if the coding conventions, planning docs, heck the culture was the same at the spin-off. Get the best, have them give you their best work, and help associate with the best in new fields once/if they take off on their own.

Again, get your coders working not just for your but for themselves. I understand that you'd probably prefer to have coders with total and infinitely long company buy-in, but in a round about way that's exactly what this is. Your code is their code is your code, and your high-functioning company and its products will be better for it. Hey, three years is a very long time.

It's a rosy set of glasses, but I have to think there are some lessons in there from creative, employee-considerate IP contracts somewhere.