This post will talk about financial, real-life problems. If you don’t feel like knowing about my personal financial and work situation, feel free to skip this. I say this, because some people complained before that I make it know too often that I don’t get paid for most of my Gentoo-related work. Not sure, maybe they feel at unease because of that. At any rate, this is not conditioning my contributions, most of the time.
While I like working on Free Software and think it’s great if I were to do that just as a pass-time like I used to do five or six years ago, I wouldn’t go much far. Time passed, I grew older, and life got complicated. I don’t have a rent to pay (for now — fortunately), but I’m living alone with my (unemployed) mother since last autumn. Electricity, connectivity, water, LPG, taxes… at the end of the day, I don’t have any more the liberty of turning down many offers. (On the other hand, I had to turn down a few because I was already quite fully booked).
But at least I try my best to develop Free Software when I’m working: thanks to the fact that there is space to choose licenses, sometimes I even can write new Free Software while doing my job. Although this often requires some trickery that is not too obvious when you start the kind of freelancing/consulting work I’ve been doing the past two/three years.
The first obvious way to make money during development is improving the Free Software that is used as part of the infrastructure by the software you’re writing. This might end up getting apparent in spite of various NDAs you might have signed, so it has to be vouched carefully, but in general it’s the kind of information that you know you’ll just show the world. If somebody is following my commits to the tree lately can probably tell something’s up, with me picking up two tied packages on areas that I don’t usually follow that much. And from that you can see that there’s a better pam_pgsql out there which was needed for my task to go on.
Similarly, whenever I used Gentoo for something work-related, I ended up trying to get in the tree all the modification and improvements needed; gdbserver was one of the packages I needed to complete a past project, and it’s now in the tree for everyone to use. it’s not a bad thing. At the same time, you can count in the presence of Rudy in the tree, and thus the fixes for its dependencies that I keep sending upstream.
But there are more “subtle” ways to work on Free Software while doing paid work, and that is to divide the problem you’re working on in separate functions; all that concerns business logic will most likely have to be kept proprietary, at least with most customers, but at the same time, the smaller, general problems that don’t include any business logic in them may be left out of the secrecy. I actually find this a generally good approach for many reasons: you may get code improvements if someone else needs to solve similar problems and decide to use your codebase; or you might get better security reviews (let’s be honest, security issues will appear in your software, whether it’s open- or closed-source; but if it’s open, they are more likely to come in sooner; and sooner might mean your deployment is still limited enough you can cover your bases with upgrades without spending a fortune, or bothering your users).
Of course to be able to split your problem into open-source subprojects, you also have to make it very clear that the business logic of your customer is not at risk. This means that you have to carefully choose the license to use (and in these cases, GPL is rarely an option, unless you work at an arm’s length), and at the same time you have to make sure that the terms are clear to the customer. Telling them “I used this, so you should follow these general terms” is rarely going to help you convince them to use more Free Software when possible, and contribute back to it; it’s actually going to make them wish not to respect the license and just not do anything. Having clear statements about what they have to publish, for GPL and similar licenses is the best way to accomplish that.
And there is another thing you have to learn, and especially teach your customers: the advantage of upstreaming changes. This is something that is generally well-understood by distribution developers, packagers, and all those developers using others’ code but not developing it directly, but most of the time, corporate, proprietary-oriented customers won’t understand the importance of it. If you have to customize some software to suit your need better, whether or not you’re obligated to publish your changes should really have little bearing in whether you should send them upstream or not. Even if the license is very permissive and won’t require you to publish change, you really should send them upstream. Why? Because sooner or later you’re going to have to update your software.
Even when software update is not that welcome a task, because obviously the fewer changes, the less risk of bugs, there are situations where upgrades are inevitable. New architectures, new hardware revisions, new required functionalities, security issues. All these problems might require you to update your software. And when you update software that you customised, then the trouble starts. If your customisations are simply hacks, piled up over and over again, you’re going to have to make some sense out of the hacks, and apply them again over the new codebase, praying that they’ll apply cleanly, or work at all. If you sent your changes upstream, or at least sent a request for he feature you pushed in, there are chances that either the code is already there (and might require just little tweaking) or at least that someone else kept the patches up-to-date.
Obviously, this is very low-scale; there are entire projects with consultancy companies behind them to offer support, customisation and all the frills needed; on the other hand this is what I do for a living myself, most of the time. So please, don’t mess up expecting that all Free Software work is done by volunteers, or that it’s never paid for. Nor try to defend messy code with “nobody was paid to do that”… when you pay people to write code, most of the time, they will not make it nice; they’ll most likely try to cut as many corners as possible. Unless, of course, readability and properness is a requirement (which rarely is).