The problem of the free software freelancer

Many contributors to free software projects fall roughly into one of two categories:

1. Employees whose employers who have taken a stance to support free software development – like Facebook or Automattic
2. Hobbyists who contribute in their spare time

In some ways, these two categories represent the extremes of a spectrum: the first group contributes because it’s their job while the latter contributes because they love it. These motivations are by no means mutually exclusive; I’d hope that most people who are paid to work on free software also love to do it. But this short list does describe what I would call the two “pure” drivers of contribution.

Between the two extremes lies a considerable gray area, where the two varieties of motivation – love and money – may coexist in the same person, yet point in different directions. Take me. I am a freelancer, specializing in development and consulting on WordPress and related technologies. On the one hand, I’m an ideological advocate for free software, and I love contributing. On the other hand, the dynamics of the freelancer’s situation often discourage contribution. There are only so many hours in my day, and when the work hours are spent doing client work for WordPress, I hardly want to devote my limited free time to working on WordPress for free. And clients have a bunch of perfectly understandable reasons for not wanting to share the work that they’re paying for: they don’t want to spend more money than necessary to get their site working, they want the competitive edge that may come from secrecy, and so on. The two “pure” motivations for contributing are in conflict with each other.

The patronage model

To combat the conflict, so that I can contribute more, I’ve moved increasingly toward what I think of as a “patronage” model. Broadly, the idea is that clients fund the process of turning the custom-developed features (that they were already going to pay for) into something that can be contributed back to the free software community; in exchange, they get certain benefits, like prestige and publicity. For me, the strategy has come down to a couple of key rules.

• Learn to preach the free software gospel – People and organizations like to feel that they’re being good citizens. So I’m prepared to explain to potential clients how their particular contributions, and free software stewardship more generally, can provide broader benefit. The nature of the pitch differs depending on the specific client and feature, but there’s almost always a larger story to be told about how the software community would be improved by the contribution in question. It can be useful to explain how the dynamics of free software development differ from proprietary retail software: Propietary software is developed on speculation, where the hope is that the upfront cost will be recovered by huge volume at low prices. In contrast, the vast majority of free software users don’t pay anything, which leaves the Kind And Generous Samaritans to bear the brunt. Don’t be afraid to sound lofty – in cases where the software wouldn’t be built without the patronage, the patron really is doing something wonderful.
• Stop accepting work from the wrong kinds of clients – In contrast to the foregoing rule, some potential clients don’t care about “being good citizens”, and no amount of clever proselytizing will change their minds. There’s nothing inherently wrong with this attitude: one of the freedoms of free software is the freedom to use it without any moral obligation to “give back”. But, as a developer who does care about the community, I’m not interested in working for this kind of client. So I don’t.
• Only accept client work that can result in contributions – Most client jobs, at least in web development, are primarily about implementation – taking off-the-shelf software, maybe installing some plugins and customizing a theme. This kind of work generally does not require the kinds of novel development or deep bugfixing that results in meaningful community contributions. There is nothing wrong with this kind of work. But, personally, I don’t find it as inherently interesting as novel development, and it doesn’t make the best use of my limited development time. Thus, I usually only take on a job if it looks like I’ll be able to spin off something truly new.
• Break down the cost structure – It costs more to build something for broad use than it does to build something for a single client. Every time you have to add a UI for options, or abstract a piece of code for more customizability, it takes time and money. Be honest with the client about how much extra money it will take to turn bespoke code into something distributable. This also means being strategic about itemizing the project scope. When writing a spec for the project, try to separate out those parts that could be turned into something distributable, so that it’ll be easier to provide an honest breakdown. There may also be cases where a client wants to contribute, but doesn’t have a clear idea how to do so – in these cases, don’t be afraid to suggest ways of dividing up the project so as to provide the biggest benefit to the community.
• Provide the right kinds publicity for the patron – Make it clear to the client the ways in which they’ll receive credit. Some ideas: Include the patron’s name in the name of the plugin. Write a blog post or some tweets thanking them for their patronage. Include the patron as a co-author. Maintain a credits.txt file in your codebase.
• Include strict licensing and IP clauses in the contract – I include language in all of my contracts to the effect of: All custom development for this project is subject to release under the GPLv2 or another relevant free software license. I do not do work-for-hire type clauses, or other arrangements that involve giving exclusive intellectual property rights to the client, because I want to maintain the right to release the software under a free license. I’ll admit that this stipulation has caused me a good deal of trouble in the last year, but it’s extremely important to me for two reasons. First, I’m an active contributor to the very same free software projects that my clients want to use in their projects. If I develop something proprietary for them, and then (knowingly or unknowingly) I include this proprietary code in something with a free license, I could be held liable for violating the license terms both of the project and of the client. Second, and more germane to the discussion here, every hour I spend doing proprietary development is an hour not spent on free development, and I think that free software is important for a number of critical reasons. So I don’t work with a client who won’t agree that all custom work be releasable (at least in theory) under a free license.

I’ve been freelancing full time for about two years. During that time, I’ve managed to take on a growing number of increasingly large projects. Through the same period, due to the patronage model, I’ve largely maintained – or even increased – the amount of time spent contributing to free software projects (even as my free time has been dominated by marriage and fatherhood!). More money in my pocket, and more free software for community use. Truly a win-win.

Not everyone will have my good fortune to be able to stick to such a strategy. I’m lucky to be offered far more work than I could possibly accept, which means I can turn down the stuff I don’t want, in accordance with the rules listed above. And I’m fortunate to be well known and well respected in my field. But it should be noted that my good fortune is not a coincidence. The more of your time you can devote to public work in free software – whether that work is as a hobbyist or as a patron-sponsored freelancer – the more well known you’ll become in the community, which will result in more job offers and more leverage with potential clients. It’s a virtuous circle that takes some courage to break into, but ends up being beneficial to everyone if you’re successful at it.

Small-scale patronage and the future of free software

Just as important as the benefits that the patronage model has brought to my own career is what it says about the future of free software development. Software like WordPress will never be commercially supported like Windows, where development is funded by the license fees of millions of users. For major development on free software projects, it’ll always be incumbent on a few generous patrons to provide resources. But there are dangers in overcentralized patronage: if, say, Automattic decided to abandon its committment to the WordPress project, a huge percentage of dev resources would suddenly dry up. The contractor-patronage model I’ve described here is a way of increasing the number of patrons, while lowering the financial bar for patronage – organizations can contribute in a meaningful way with just a few thousand dollars. Adopted widely, this promises to be a more secure foundation for ongoing free software development.