Really Own Your Code

Walking to the bus stop, with a coffee burning one hand and my breakfast the other, I noticed how poor my area looks; an urban area where many students and young professionals rent houses. The tenants aren't poor, the owners neither, but the area itself is impoverished, because the owners don't care and the tenants don't care. I got on the bus, and dropped half my coffee on the bus floor as it went over a speed bump, because I was holding the coffee so as not to burn my hand too much. Ah, well, glad it wasn't my bus. It struck me right there how little tenants look after the property they rent. Some local teenagers smashed a bottle of beer outside my house, and I didn't clear it up. I didn't ask the local authorities to do so either. I just looked at it with disdain whenever I passed it, and resented paying my local taxes even more. In my job as a coder, on a 1.5-man project, I am a tenant. I'm actually a good tenant, in that I look after the codebase pretty well, but I'm still a tenant in the most important, and crippling, way. I don't own my code. This isn't the same as responsibility for my code; I have that. It's my code, but it's not mine. I can't walk away from my employer and reuse the code elsewhere. That's not completely true; for a couple of libraries I wrote for the project my boss has given me licence to release them for free. For those libraries, I actually find myself reserving my best coding practices, because I know that other people will need to read the code. Not just in some abstract "sometime after I leave my job" way, but in a "they already do read it" way. I don't bother to create separate libraries for code that I can't release separately. In other words, I don't decouple as much as I could, because the practical benefits are too indirect. Realistically, I know that my project will die when I leave. That's not to say that I won't be very gracious in documenting it. My boss doesn't have the skills to maintain it well, and he's uncertain as to how to make more money from it, so he probably won't want to release the whole thing for free until it suffers from bitrot (which will probably be whenever IPv6 becomes dominant). The fact that I don't own the code means that my goals and the project's goals are slightly at odds with each other. There's an IP stack in the project, a serialisation library, clever handling of scroll bars when stuff is dragged around the display, but only our 200 students (per year) are benefitting from those. The funding comes from a nationwide education body, but they don't have rights over the code either. In that respect, it's a waste of money, because other establishments can't easily customise it for their requirements, and largely they don't know about it. In fact, even within our department, another member of staff wanted to use the software, and she couldn't, because it didn't have a particular feature. I offered to implement it, but my boss declined because it wasn't part of what the funding was paying for. If it was my code, I'd happily implement it in a separate branch, in my spare time, and I'd feel enthusiastic about it. Now let's look at the most recent entry in Bugzilla for this project: "A long term thing for a quiet Friday afternoon (if such a thing exists!) In the same way you have files in the jar for customisation of "installation number", "installed to" etc, I think there may be a long-term need to use a similar mechanism to allow some customisation of the conformance rules (this will be important if other people use IPSim, as there may be some things that I want to give feedback on that other people may not care about" We lost 150 users already by not doing this for the other member of staff. Plus, I could only code in advance customisations that I can anticipate. If I'm on holiday or busy coding a new feature that we already have funding for, we'll miss out on the opportunity. For a small project like this one, developer motivation and the quality of the project would increase if the developer could reuse the work elsewhere. That could mean open-sourcing it, as has been done for two small parts (a functional programming library and a Java layout manager), or it could mean an agreement not to use the code for commercial purposes for a fixed term after employment. How about for a larger team? I'd suggest to assign each source file to a single developer, who has responsibility over that file, and has actual ownership, so that he can reuse the file at some point, even now, in another company. Then any changes made by any other developer to that file are automatically licenced so that the owner can use them.