Sent by Jonathan Stark on July 7th, 2017
Several readers wrote in with their personal experience regarding code ownership when developing software for clients.
The two that I have shared below are representative of many I got that focused on how open source factors into the equation.
CF: I explicitly state in my agreement that my clients have a non-exclusive, perpetual license to code that I own
JS: Have you ever had a client push back on that?
CF: No push back, but... I maintain a few dozen open source projects (prominently featured on my site) and primarily work with WordPress, an open source platform, so attitudes around code reuse may be different for my clients than if you worked with a different set of technologies.
JS: Is this something you discuss this with clients in advance, or is it buried in your contract?
CF: While I do have a very explicit section in my contract called “Copyrights” that details this, I make sure to bring it up in advance. It’s important to set expectations and come to a conceptual agreement well before “the thing you sign” lands in front of the client. At that point, it should really be a formality. I usually frame it a bit like this:Over the years, I’ve created a large library of open source components that address many of the technical aspects we may want to implement on your site. This means I can work more quickly on your project, experiment with different approaches more easily, and deliver you a more well-tested codebase, since I’m using code that’s been used and tested on dozens of other sites. Practically speaking, this means that I own the code and license it you indefinitely. The specific combination of colors, layouts, icons, and so on is unique to you, but I can and do reuse code and best practice interaction patterns with other clients. Because of this approach, you benefit from well tested, proven solutions in less time.
JS: Have you ever reused code from one of these sorts of projects?
CF: All the time! I have a WordPress theme boilerplate I use as a starting point for every site I build. I have a CSS boilerplate I use to kick-start every project with a basic layout and typographic grid (and quickly start prototyping for my clients). I have dozens of open source projects I use to quickly and easily add everything from navigation patterns and interactive content (like accordions and modal windows) to deep integration with tools like MailChimp. This all allows me to be way, way more productive. My clients get better work more quickly. I spend less time writing code and debugging and more time focusing on solving their business problems.
The next message is from my good friend, podcast co-host, and multi-awarding winning Rails developer Kelli Shaver:
I think, as developers, it’s only natural that over time we build up our own libraries to perform various core tasks we find ourselves doing from project to project. There’s only so many ways you can re-invent the wheel and only so many times you should try. I have no qualms about re-using that type of code, but I’m also going to make it clear to the client that their project may contain such libraries, and that any code developed for their proprietary [whatever] isn’t going to be re-used elsewhere, their IP is protected, etc.
The way I see it, that’s no different than having two projects using ActiveRecord, for instance, except that I happen to be the author of the module in question, not the Rails team.
Sometimes the tasks are a little more specialized to our niches, but are still general enough to be too valuable for re-use to guarantee exclusivity. Using them also isn’t going to give away some trade secret. For instance, I wrote a ruby library that analyzes photos and pulls out the most dominant colors as hex values. On its own, it’s not that special, and it’s generic enough to be useful in all kinds of applications.
So I don’t think it has to be an all all or nothing approach (which I don’t think you were actually implying), as long as you communicate that to the client when necessary.
That said, if I’ve built up libraries like that, there’s also a good chance I’m going to open source them, unless there’s some good business reason (for me) or security reason not to.
Thanks to Chris, Kelli, and everyone else who sent in replies!