Tag Archives: free software

2017

Previously: 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009.

As 2017 began, I felt fairly despondent about what the year would bring. Looking back at the way 2017 actually turned out, it looks like the despondence forced me to shift focus in a few ways that, on balance, have been major positive changes.

A case in point. For the first half of the year, I was having problems sleeping. I struggled with feverish nightmares related to the news and the state of the world. The information consumption habits I thought so enlightened last year (no news after 6pm!) were not, it turned out, enough to release me from the power of the information flow. This summer, I started reading the physical local newspaper, and in the fall, I stopped reading news and magazines online altogether. My one engagement point with news during the day is at breakfast, over coffee. When I walk away from the table, I walk away from the manufactured anxiety of constant contact. It's been marvelously therapeutic. And I actually feel *better* informed on most subjects, since I'm able to judge them at some distance rather than succumbing to the endorphin rush of "breaking news" and the "conversation" that accompanies it. I am increasingly disconnected from memes and collective-outrage-du-jour and other aspects of the zeitgeist, but I consider this too to be an improvement in my quality of life.

In place of the online world that I'm increasingly leaving behind, I've been searching out new channels for engagement that feel more authentic. An oddly underattended college reunion and some related contact with college buddies has caused me to reflect on the communities that we move in and out of through the course of our lives, and to think about how these dormant connections might serve as the organic seed for meaningful future relationships. I've been devoting more time to music and to a new-found interest in the visual arts. I've reached out to some old friends, and after stumbling across a cache of old letters from high school and college, have started building the idea of private correspondence – letter writing for its own sake! – back into my life.

Regarding work, I had a somewhat busier year than I'd hoped, and I devoted less time to free software than I have in the past few years. (See my Hard G post for more.) My relationship with WordPress and BuddyPress is something that I have struggled with in 2017, though it's become somewhat clearer in the last few months. When I first started contributing to free software, my spirit was nourished by the personal connections I made to people who were using the software. As I became busier and more "important", I justified to myself that I had bigger things to worry about than those connections, focusing instead on some vague ideas about "leadership" and "product". Beginning this fall, I started approaching my free software work with a different attitude, starting with a dose of humility about who I am and the value I bring to the projects. I started spending much more time in the support forums. I began approaching bug reports and PRs with an amount of empathy that felt forced but eventually gave way to true feelings of kindness. And I've started thinking more about the ways that I can use my years of experience in these projects to connect the humans working in disparate areas in a spirit of actual cameraderie. I'm unsure how my time committments to these projects will or won't change in 2018 (though I have a feeling I'll be spending proportionately more time on BuddyPress, where I feel like I've got the ability to make a more direct impact), but I feel strongly that any time spent on them should be purposeful and humane.

With my career more generally, I have found some solace by being explicit with myself that I will not be doing this work forever. Thinking about an off-ramp in the next few years gives a bit more urgency and purpose to the work that I do today, and I think this is a good thing no matter what happens.

One small resolution for 2018 that I've already put in place is: more enforced time off. I've already slated a couple of weeks for the first half of the year when I will be totally AFK, no screens, no internet, maybe no newspaper. Just having this on the schedule has made the everyday load feel lighter.

Happy new year to all!

Indirect funding and the limits of free software patronage

A few thoughts about direct and indirect funding for free software development.

Proprietary software is often sold at retail, which makes for a diverse economic model. Let’s say that a million people buy a $10 yearly license for your iWidgetFactoryPro™. This year you’ll have $10,000,000 dollars, much of which can be used to fund future iWidgetFactoryPro™ development. If you lose fifty thousand users next year, you’ll have $500,000 less to work with. That’s a lot of cabbage. But you’ll still have $9,500,000, enough to carry on your product development, perhaps with a slightly reduced scope. Retail pricing spreads the risk around.

Most free software is not sold in a retail fashion. A single company might pay for the development of a tool, and then decide to release it under a free license. Or a tool’s builders may fund development themselves, with their own money or their own free time. Or a project that starts off as a labor of love may become important enough that a number of companies volunteer resources to improve it. In any of these cases, the funding model is highly centralized. Instead of a million users who share the financial burden roughly equally, as with retail software, a free tool may have a million users but just a small handful of funders, each of which is footing a disproportionately large part of the bill. It’s a precarious setup not merely because the sheer number of funders is so small, but also because the costs are distributed in a way that’s so uneven – and unfair! – that individual funders have arguably more inclination to walk away than the retail licensee who’s paid a lousy ten bucks for a copy of iWidgetFactoryPro™.

The asymmetrical funding model for free software is the cause of much hand-wringing among the individuals who maintain free software projects. How does a volunteer, a solopreneur, a small businessperson, an underfunded or unfunded Desperado, take on the huge and often unrewarding task of maintaining a popular project, while still managing to make money? My friend Daniel Bachhuber has written a number of posts recently in which he struggles with this problem, and is experimenting with a couple different models:

The key idea behind Sparks is to create a space where WordPress-based businesses can contribute to an open source roadmap, collaboratively prioritize, and then share the cost of development and maintenance […] When I explain the concept of Sparks to a prospective customer, they get it. It makes a ton of sense to share the burden of building and maintaining boring, business-critical infrastructure.

The strategy is to hedge against some of the instability of the “patronage” model – free software tools being supported by a very small group of generous funders – toward a more diversified financial base.

The structure of “Sparks” – crowdfunding, but where the members of the “crowd” are businesses with budgets – moves toward retail software in two ways that are worth considering. First, by getting interested individuals to take an equal share in funding the software, it tries to make the funding model more fair. Second, by tying the decision of which tools to build to the number of voters (or backers, or whatever) in support of that specific tool, it tries to make the funding model more direct.

Can this work? Direct funding models are kind of like health insurance exchanges: the economics only work if there’s a mandate that everyone participate. Proprietary software licensing is one such mandate. With free software, it’s an uphill slog, and a hard sell.

I have mostly given up on direct client funding for my free software work. There are a couple of interconnected problems:

  • Clients can be convinced to pay for something new and shiny and released with public credit to their name. But fewer want to pay for maintaining something old and boring and anonymous.
  • Once a project is released and in broad use, the client’s ongoing needs for improvement often (usually) diverge with the needs of the broader community.
  • When you are a maintainer of a large software project, quid pro quo contributions – “we’ll pay you to add this feature to WordPress” – are fraught with ethical and practical difficulties.
  • The things that clients want to build are not usually the things that I want to build, or the things that I think need to be built.

As direct funding has become less attractive and more difficult to manage, I’ve turned more toward indirect models. I’ve spoken and written at length about what I call “the reputation cycle”. This is the idea that time spent contributing to free software can improve your reputation, which allows you to increase your rates, which allows you to bill fewer hours, which allows you to contribute more time to free software. Over the last few years, I’ve ratched myself up to the point where I spend roughly 50% of my working time doing work that is not paid for by a client.

Or, at least, not paid for directly. Client work subsidizes free software work, but the subsidy is indirect. This indirectness avoids most of the problems sketched above. My decisions about how and where to contribute to the projects I’m involved with are made based on my own interests and my own assessment of project priorities and needs. Since the work is not being done under the aegis of any specific client relationship, I’m not bound by any specific client expectations.

If not framed correctly, the indirect model can feel vaguely dishonest. It involves charging a higher rate to paying customers, without providing any direct benefit for the increased cost. In one sense, this feeling is clearly misguided; the software I choose to work on in my “free” time is the very same software that powers my clients’ sites. They’re reaping benefits that are indirect – but not that indirect.

More importantly, the sense of dishonesty is misplaced because there’s no deception involved. The model is indirect, but it’s not implicit. My message for potential clients is pretty explicit: When you hire me, you are not only buying top-quality technical work, but you are also funding the more general improvement of the free software projects in which I’m involved. It’s part of the brand. It’s less Robin Hood – illicit redistribution of funds – than, say, buying organic milk: you pay more for a slightly better product, knowing that part of the extra cost goes toward the normalization of a system of production that’s superior to the conventional system.

Can this funding model – indirect, but explicit about it – be scaled? Probably not. Like patronage, it depends on the good will of a fairly small number of benevolent folks – developers and clients – to shoulder the burden of the other 99% of users. But there’s something noble about it too. A totally “fair” system, in which each user pays an equal amount to use a piece of software, ignores the fact that not all users have equal resources. One of the beauties of free software is that the generosity of those who can afford to contribute can benefit those who cannot.

 

One of the suckers

At the beginning of the 4.2 dev cycle, I was made a permanent committer for WordPress. (Cool!) Here’s how Andrew Nacin summed up the promotion:

Suckers

Suckers

Any maintainer of a large free software project will recognize the aptness of the “suckers” comment. I’ve spent more than five years as a leader on the BuddyPress project, and during that time I’ve developed a devotion to that project that sometimes feels like more like servitude than volunteerism. I feel a personal responsibility to the users of BuddyPress, which manifests itself as a pang of guilt about every bug, every missing feature, every unsatisfied customer. This guilt is part (not all, but not an insignificant portion) of what keeps me committed to the project. The same guilt sometimes makes me feel like a sucker.

With BuddyPress, the “sucker” aspects have been consistently counterbalanced by (a) the belief that my work is having a broad positive impact, and (b) the positive effect that contribution has on my reputation and my marketability. Point (b) is one that I’ve blathered on about on multiple occasions. My ability to make money as a consultant is directly tied to the reputation that I’ve earned doing free software work.

Since I started investing lots of energy into WordPress itself about nine months ago, I’ve been forced to reassess the “reputation cycle” somewhat. WordPress powers tens of millions of sites, as compared to BuddyPress’s tens of thousands. By this metric, the free software work I’ve done since September has had a far wider impact than any work before then.

You’d think that this increased impact would translate directly into a corresponding increase in reputation. Yet it hasn’t, at least not if you measure reputation by job offers. This time last year, I was turning away probably three or four freelance gigs per week, and probably one or two full-time jobs per month. I don’t get a fifth of that amount today.

This is not to complain – I am doing just fine, thankyouverymuch. But it’s worth thinking about the possible reasons why increased impact and productivity don’t always translate to more work. I think there are two big ones.

First: The further down you get in the technology stack, the more it feels like plumbing. I’ve built a number of major user-facing features for BuddyPress over the years, the kind of things someone might point to and say, “Boone built that”. My work on WordPress has been a lot less visible, and thus a lot harder to brag about. This is the truth in Nacin’s “suckers” comment. No one praises the plumber when the toilet flushes properly, but boy do people complain when it does not.

Second: I joined the WP core team around the time I stopped using Twitter. The time I used to waste looking at Twitter is time I now sink into doing meaningful work on projects like WordPress, which is to say that I’m more productive now than I used to be. But I’m talking less, and talking less about myself. If the Boone brand is in decline, it’s a publicity problem, not a quality problem. This is another side of the “sucker” coin: the greater the percentage of your time you devote to being productive, the less time you have to talk about how productive you are.

Unpaid labor in academic and free software communities

There are many aspects of my current free software development work that are (thankfully!) very different from my previous life as an academic. But one way in which they’re similar is the way that one’s relationship to one’s own paid and unpaid labor is connected to one’s career progress, and the personality types that this structure attracts.

I’m a known advocate ([1], [2], [3]) for fostering a symbiotic relationship between my paid client work and my unpaid work on free software projects. And while I’m emphatic that there’s value in having these two parts of my career separate from (yet supportive of) each other, the separation embodies an unavoidable tension between what I’m paid to do and what earns the respect of my peers. If people know who I am, it’s probably because of volunteer work I’ve done for WordPress, not because of my client work. As such, there’s continual internal pressure for me to focus more of my mental and emotional energies on the unpaid work. Yet it’s important not to yield completely to this pressure, since my paid client work is critical, both in terms of the financial support and the technical inspiration it gives to my work on the free software projects. Balancing these two pressures is something I’m constantly struggling with.

The relationship between labor and rewards in academic work is similarly structured. Most academics are paid primarily for teaching duties, with service and research being important but often secondary, at least as far as the official job descriptions are concerned. Yet the system of advancement in academia is structured in such a way that one’s research and publication record is of paramount importance. And in many cases, volunteer labor – things like peer review and service to professional societies – is critical to one’s reputation as a scholar. Anyone in the academic world will recognize the tensions that this arrangement can produce.

The peculiar motivations baked into free software development and academia tend to attract similar sorts of overachievers. To rise to the top of your field, you’ve got to do large amounts of unpaid labor, while still doing enough of your paid labor to keep your job. This means that the most successful people tend to be those who are spending the greatest amount of their spare time working for free. A couple of consequences fall out of this arrangement. First, people who are already in a position of privilege (financial and otherwise) are able to climb the career ladder more easily. This setup also means thatt successful people are likely to have a sense of self-worth that is closely connected to their work. And these factors mean that successful academics as well as free software contributors are more likely to suffer from burnout.

Last year, DHH of Ruby on Rails wrote an interesting piece on “the perils of mixing open source and money”. I’m very sympathetic to many of his points about motivation: the tenor of a free software project, and the quality of the software that results, is largely a consequence of the fact that the creators of the software are not primarily motivated by financial concerns. This is something that academics figured out a long time ago. As such, I think that it’s important to continue to foster “reputation cycles” and other structures that help to enable talented developers to devote energies to free software without directly paying them for it. At the same time, it’s important to be aware of the kinds of tensions I describe above, because the separation of paid and unpaid work in this area can tend to be personally destructive at the same time that it’s valuable for the (software/academic) projects as a whole.

WordCamp NYC video now available

In August, I gave the keynote presentation at WordCamp NYC. A few days later, I wrote out a condensed version of those remarks and posted it on this blog. The video for that talk was posted today to wordpress.tv and is embedded below for your viewing pleasure. Some of the meat of the argument is the same as my recent talk at WCSF, but the NY talk is more focused on freelancers, and has funnier jokes.

Free Software, Free Labor, and the Freelancer – WordCamp NYC 2014 keynote

I was honored to present the keynote address at this year’s WordCamp New York. Below is a rough copy of the text with some of the slides interspersed. (“Rough” means cobbled together from my notes, and minus most of the ***hilarious*** jokes. I guess you had to be there.) The video will be up on wordpress.tv within a few weeks.

===

The title of my talk today is “Free Software, Free Labor, and the Freelancer”. I’ve been asked to give this particular talk because I’m a freelancer who devotes large amounts of free labor to free software projects. The gist of my argument is going to be that freelancers can and should contribute more than they do, and I’m going to make this argument in a way that is sensitive to the economic concerns that are particular to freelancers and small business owners. I’m a developer, so most of what I’ll say will be specific to people who write code; there’s a lot to be said about the imbalances between coders and non-coders in a project like WordPress, but that’s a subject for another talk.

I’d like to start off by asking what it means when we say that WordPress is “free”. Many of the people in this room could rattle off, in their sleep, the two senses of the English word “free” when it comes to free software. What’s less often noticed is how these two senses can be at odds with each other. Let’s spell that out a bit.

gorges - wcnyc2014.005

The first sense in which WordPress is free is “free as in free beer”. When I invite you to my dorm room for a free Blatz, what I mean is that I’m not going to ask you for the 50 cents to recoup my initial outlay. “Free beer” is beer that you don’t have to pay for. And WordPress itself is free in this sense, because, in contrast to software like, say, Microsoft Windows, you don’t have to pay anyone to download or use the software.

gorges - wcnyc2014.006

But this is, of course, a secondary sense of “free”. When we think of WordPress as free software, what we really mean is “free as in freedom”. In technical terms, this means that WordPress is released under a free software license – in our case, the GNU General Public License, or GPL. The terms of the GPL can be summarized by the four essential freedoms that they guarantee to users of the software: (0) the freedom to use the software for any purpose; (1) the freedom to study and modify the software as they’d wish (this is the “open source” part); (2) the freedom to redistribute the original software; and (3) the freedom to distribute any modifications to the software. The GPL guarantees that users have these freedoms with respect to WordPress, and this is the primary sense in which WordPress is “free”.

gorges - wcnyc2014.008

The point I want to make at the moment is that these two senses of the word “free” are, in some sense, in conflict with each other with respect to software like WordPress. The root of the conflict is that building software – especially good software – is hard: programming is hard, design is hard, documentation is hard, support is hard, community building is hard. The fact that these things are hard mean that it takes a lot of people and a lot of time to build software. And this means, in turn, that it costs a lot of money to build software.

The traditional strategy for addressing this problem is to make your software proprietary. If you charge a couple hundred million people $100 each to use your software, you’ll have a few billion dollars that you can use to pay an army of programmers, designers, etc to build and maintain that software. But, prima facie, it’s tricky to keep this system up and running – the money only keeps rolling in if people are forced to pay in order to use the software, but software is by its very nature the kind of thing that can be infinitely copied and sent around the internet. The creators of proprietary software combat this problem by locking down their tools in a couple of ways. They lock it down in a legal sense, by requiring you to agree to End User License Agreements and other mumbo jumbo before using. They lock it down in a technical sense, through the use of license keys, DRM, and the like. And they lock it down through propaganda, such as the convention of using the word “piracy” to describe something that, in fact, is quite different from stabbing someone with a cutlass to plunder their dubloons.

By definition – remember the four freedoms – free software cannot be locked down in these ways. People can use it in any way they want (no contracts limiting use). People can distribute it in any way they want (no technical barriers to distribution). And the license actually encourages this redistribution (a fortiori, no moralistic jingoes about “piracy”, etc). At a glance, this breaks the economic model for creating and maintaining free software.

gorges - wcnyc2014.014

One of my heroes, Dolly Parton, has famously said about herself that “it costs a lot of money to look this cheap”. We can borrow this phrase as a slogan for the problem I’ve just described: “It costs a lot of money to be this free.” So that’s a problem that stands in need of some explanation. Given that it costs a lot of money to create free software, where is the money coming from? Who is footing the bill for WordPress?

gorges - wcnyc2014.016

The first group that comes to mind is what I call “the hobbyists”. This is Matt Mullenweg in 2004. Matt is one of the co-founders of WordPress, and the story of WordPress’s founding is, I think, typical of the story of the hobbyist free software contributor. Matt was a user of the free blogging tool b2. He and Mike Little decided in 2003 that they wanted to fork the tool to add some more features and make it a better fit for their own use cases. And they decided that their changes would be actively made available to a larger community. They weren’t getting paid for this – it was something they did for fun, to scratch their own itch. This kind of hobbyist is effectively donating his own labor to the project. And this is part of the story of who funds projects like WordPress.

gorges - wcnyc2014.017

The second class of folks responsible for funding free software is the business owners who donate some of their employees’ time to the projects. This is Matt Mullenweg in 2013. By this point in the history of WordPress, Matt is a successful businessman. Through Automattic (the company that runs the commercial wordpress.com) and Audrey Capital (his venture capital firm), Matt donates large amounts of employee time to the WordPress project. And Matt is only the most notable of a growing group of businesses that are doing something similar: a number of WordPress-focused web development agencies, webhosts, and other companies are following suit. So that’s another part of the story of who’s paying for free software.

It’s worth noting that so far I’ve described two groups of people on opposite ends of a spectrum: the hobbyist who donates time to the project for pleasure, and the employee who contributes because it’s part of his job duties. What about the rest of the spectrum? Well, that’s made up largely of freelancers. Unlike the employee, it actually costs the freelancer money when she contributes to free software, in the form of time not spent on client work. And unlike the hobbyist, the freelancer spends most of her day working with WordPress, which makes her very good at WordPress, but also makes her pretty sick of WordPress. So, at the end of the day, it’s likely that the freelancer would rather do just about anything other than, say, write a patch to submit to WordPress Trac.

This is the freelancer’s dilemma: she has the skills, and probably the desire, to contribute. But there are direct disincentives – financial and otherwise – to doing so.

In a few minutes, I’ll spend some time talking about strategies for overcoming this dilemma. But first I’d like to dispose of a common excuse that the freelancer makes for not contributing: Someone Else Will Do It. And of course, this is true – WordPress is a large project, and it’s in no danger of not being maintained. But a closer look at who that “someone else” is makes it clear that the freelancer is, to some extent, shooting herself in the foot by leaving all the work up to others.

gorges - wcnyc2014.022

To test this, I analyzed all the changesets that made up WordPress 3.9. For each changeset, I identified the “responsible parties” – those who had received “props”, or barring that, those who had committed the patch. Once I had these counts, I researched the employment situation of each contributor, and sorted them into various employer types. [I’ll try to write up the method and results in more detail in a future post.] Now, there are many reasons why you should take this analysis with a big grain of salt. But it does gesture toward some important patterns. The freelancer represents 238 out of 1380 commits during the 3.9 cycle. And about a third of those freelancer commits belong to a single person (Sergey Biryukov).

This seems out of whack. I don’t criticize Matt Mullenweg and his generous counterparts for funding the lion’s share of this work – I commend them for it. But from the freelancer’s point of view, it’s worth taking a closer look at exactly where the largest chunks of contribution are coming from, and looking in particular at the relationship between those contributors and WordPress. Andrew Nacin is a big portion of the yellow wedge here. He spends his days working on WP core, as well as maintaining the wordpress.org infrastructure (and a handful of other very unusual WP-based sites). The folks from Automattic are focused on wordpress.com, a huge and hugely influential WordPress network, but an idiosyncratic one in a number of technical and conceptual ways. And people in larger WP agencies as well as the Corporate category are working disproportionately on fairly large, high-traffic sites, largely for big media companies. But my impression is that these sites do not really represent what makes up the bulk of the WordPress sites in the world, most of which are fairly small and low-traffic – the kinds that are typically built by freelancers. There are specific considerations that are important for building sites of any type, and the people who build sites of that type are best positioned to ensure that the WordPress software is a good tool for building those sites. If freelancers want to ensure that WP continues to be the right tool for them and for their specific use cases – and they should – then they ought to be getting involved.

So let’s talk about some concrete strategies that the freelancer can use to contribute without doing undue damage to her bottom line.
gorges - wcnyc2014.027

The first strategy I want to discuss is what I call “patronage”. This is Mozart. Like many musicians and other artists before him, his art was financially supported (at least in part) by rich aristocrats. This was a time when there were fewer ways to make a living from the masses (no CD stores, for example), so one of the only ways for artists to get by was to find a person with deep enough pockets to fund the art. This worked out pretty well, at least in some cases: Mozart got to write music and put a roof over his head, the patron got the prestige of the commissioned works, and posterity got the benefit of Mozart’s music.

Free software patronage works in a similar way. Here’s an example. I wrote a plugin called BuddyPress Docs for a project at the City University of New York called the CUNY Academic Commons. They wanted a way for users to edit documents collaboratively, a sort of hybrid of Google Docs and a wiki, from within BuddyPress. It was clear from the beginning that this was a tool that lots of other BuddyPress installations could use too. I was very fortunate to be working with Matt Gold at CUNY, who has a deep understanding of the broader benefits of free software. So we agreed early on that the plugin would be made available on the wordpress.org plugin repository, and that the CUNY Academic Commons would pay me for at least some of the necessary upkeep on the public plugin. In exchange, the CUNY Academic Commons gets some good publicity. They’re listed as a plugin author. The plugin has been downloaded some 78,000 times, which sounds good when they are writing reports to their funders. And since the plugin was originally written for CUNY in 2011, I’ve parlayed it into a number of other patronage arrangements, with the University of Missouri and the University of Florida each requesting custom functionality which we arranged to have rolled into the publicly available plugin.

When it works, the patronage model is perhaps the ideal way to do free software development. Remember: our original dilemma was that time spent writing free software was time not spent doing client work. But when you’re working on patronage, you’re doing both at the same time.

But it’s hard to get patronage right. First and foremost, you have to find the right client. They’ve gotta be open-minded – and, ideally, excited – about the prospect of giving away a product that they’re paying for. And in most cases, that product is going to cost them more than it would cost them if it were not intended for general use – as any plugin or theme developer knows, creating something meant to be distributed is a good deal more complex and abstract than something meant for a single client site. Certain types of clients will be more naturally amenable to this sort of thing than others. I work primarily with public universities, where it’s pretty easy to sell the idea of using public funds for work that will benefit a broader public. Your mileage may vary.

Just as important, patronage only works on the right kinds of projects. Freelance projects usually start with the client producing a monolithic list of requirements. Part of the freelancer’s art is to turn this list into a scope of work that both satisfies the client’s needs and contains discrete items that are appropriate for general release. One of your jobs as developer is to know what’s needed in the community at large, and to massage your contracts in order to extract standalone items that address these needs.

You also want to make sure that you only agree to patronage setups when you – and the client – are willing to be in it for the long haul. Releasing a plugin means that you have a certain responsibility for upkeep. Include at least some of this upkeep in your ongoing maintenance contract with the client. And make sure that you pick something that you personally will want to continue to work on down the road.

One last point to make about patronage is this: Dirty work is hard to sell to a potential patron. Everyone likes the idea of having their name attached to an exciting new plugin. Fixing arcane bugs in an upstream project isn’t nearly as sexy. Unless you’re a really smooth talker, patronage probably won’t fund more than a small portion of your free software work.

So that’s patronage. It’s great work if you can get it, but it’s hard to get it right.

A more broadly applicable strategy for freelancers is what I call “the reputation cycle”.

gorges - wcnyc2014.040

Let’s start with some arithmetic. Say you work 1000 billable hours per year, and charge an average of $100 per hour. This would give you a yearly income of $100,000. Now let’s say that one day your hourly rate went up to $125. What happens to this equation? Well, you have a few options. One is to make an extra 25 grand:

gorges - wcnyc2014.043

Another is to shoot for the same income, but to work less:

gorges - wcnyc2014.045

Or you can split the difference, working a bit less but making a bit more:

gorges - wcnyc2014.047

This is a fun math lesson, but now we have to go back and answer the question of how to make this happen. If you’re charging $100 per hour for client work, how do you get yourself to $125 so that you’ll be faced with the choices described above? The question of how to raise one’s rates is, of course, the Great Question of All Freelancers, and there’s much that could be said (and has been said) about it. But there are a few very simple tips that I can give for justifying higher rates: get better at what you do, and get your clients to believe that you are better at what you do.

gorges - wcnyc2014.050

So what does this have to do with my talk today? Well, it so happens that these two tried-and-true methods for justifying higher rates are also two of the primary benefits of contributing to free software projects:

gorges - wcnyc2014.051

Let’s talk about these two claims in turn. First: how does contributing to WordPress make you better at using WordPress? I’d hope that this is self-evident at least to an extent, but it’ll be helpful to say at least a few words about the specifics.

Consider code review. hen you submit a patch to WordPress, it’s usually reviewed and commented on by a number of committers, and probably multiple other seasoned contributors. How much would it cost if you had to pay for this kind of professional code review? This point is especially important for the freelancer, who, by definition, works alone. The opportunity to learn new techniques and t get high-level feedback on your work is invaluable. And this kind of feedback is a free benefit of contributing to the project.

Another way that contributing can make you better at WordPress is that it forces you to learn more about WordPress. There is simply no better way to learn about how WP works than by diving deep into its very bowels. For every ticket you decide to adopt, you’re bound to find one feature of the software you never knew about; or learn one more odd quirk; or ideally, fix one problem that was bugging you. Over time, these little things add up: you’ll find yourself choosing better client implementations, making fewer mistakes, and getting your paid work done more efficiently.

There’s a lot more that could be said about how building free software improves your skills. But let’s change course for a moment. Remember, we’re trying here to suss out how contributing to free software can justify charging higher client rates. For that to happen, the client has to believe that you’re worth those rates. So let’s talk a bit about reputation.

Maybe the most direct benefit from contribution is that it gives potential clients independent verification that you are, in fact, an expert in your field. Put yourself in the place of a client who wants a WordPress website but doesn’t have the technical skills to tell apart self-proclaimed “experts”. Are you willing to pay a 10% or 20% premium for someone who can prove that they’ve written a popular plugin or even written a small part of WordPress itself?

gorges - wcnyc2014.060

Check out this page from the website of WordPress freelancer Bill Erickson. He’s listed details about his publicly available plugins, download counts, a list of WordPress-related presentations, patches accepted to Genesis and WordPress, and so on. I’m sure Bill lists this information here because he’s proud, and rightfully so. But it plays an equally important role in verifying his claim to be a WordPress expert.

Simply blogging about WordPress is another way to demonstrate your expertise in a concrete way – an especially effective one if you write a blog post that ranks high on Google. I’ve written technical posts about BuddyPress that still get Google traffic five years later. My rate for BuddyPress consultation (which makes up almost all my client work) today is almost 10 times what it was in 2009, when I started doing this work. What justifies that in the eyes of clients? There’s a lot to be said about that, but in part, it’s things like:

Each of these is an independent verification to clients that I am, indeed, the expert I claim to be. This stuff is hard to fake.

A less obvious way in which contribution can have ramifications on reputation is that it helps you tap into a network of quality referrals. Active participation in the WordPress community will get you noticed by other members of that community. And prominent members of the community are likely being solicited with very attractive job offers. Becoming a trusted member of the community taps you into this referral network. I personally send a few dozen referrals every month, and the people I send referrals to are exclusively those I know from the WordPress and BuddyPress community.

Let’s go back to the main point here. I’ve been talking about a strategy I call the Reputation Cycle. Here’s the “cycle” part of it.

gorges - wcnyc2014.067

When you contribute to free software, over time you will improve your skills and reputation. As a result, you’ll be able to demand higher rates from your client work. When that happens, you can work a bit less over the course of the year, and still make the same amount of money (or even more!). Some of that freed-up time can then be put back into your free software work. And the cycle begins again.

I think this is pretty compelling. But if you’re not convinced that this is a good thing for you personally, consider this: This kind of cycle is imperative for the future of WordPress and free software in general. Take another look at this chart I showed earlier:

gorges - wcnyc2014.022

One of the patterns it suggests is that a disproportionate part of funding for WordPress’s development comes from a fairly small number of sources: Automattic, Audrey Capital, 10up. When a freelancer spends an hour working on WordPress, it’s being paid for by the freelancer’s client (whether directly or indirectly). In this way, the freelancer converts a marginal amount of the money spent by clients on WordPress-based sites into a direct benefit for the WordPress free software project.

This is a form of redistribution. One way to think of it is that the freelancer is a kind of Robin Hood – taking from the rich to give to the poor. But I think this is a bit coarse, and prefer to think of it as a more subtle effect. Freelancers have the chance restore some equilibrium to the system, by shifting some of the onus of footing the bill for WP off of Matt Mullenweg and a few of his generous counterparts and onto a much broader subset of the WordPress universe. This dynamic ensures that the project is funded in a less centralized way, and helps to make the future of the software more secure.

gorges - wcnyc2014.070

One more thought to wrap things up. I’ve been freelancing full time for about four years. Over that time, I’ve used the techniques described today to get myself to a point where I spend about 50% of my working time doing non-paid free software work. I’ve chosen to orient my career this way because, like Richard Stallman, the father of the free software movement, I consider free software to be a critical tool in accomplishing some important moral and political goals that have implications beyond the software itself. But I’ve intentionally avoided framing today’s talk in this way. Nothing about how contributing is the “right” thing to do, or that you “owe” it to WordPress. If you are a freelancer who couldn’t care less about the GPL or user freedoms or Richard Stallman, my argument is that you still ought to contribute out of mere self-interest. And if you’re a freelancer who does care about these things, my argument is that there are strategies that help you to contribute without undue financial sacrifice. In my view it’s a brilliant structural feature of communities structured by the GPL that you don’t have to care about the ethical implications of free software in order to benefit from those implications. In other words, it’s equally valid to contribute for the sake of others or to contribute merely for yourself.

The pleasure of being a lone wolf

The WordPress consulting world has, of late, been all about consolidation and upsizing. Firms get larger by hiring independents and acquiring smaller businesses. Every week I read countless tweets and blog posts about the joys of working for a larger team: the camaraderie, the efficiencies of scale, the pleasure of getting a regular paycheck. And as a longtime solo freelancer, I’m very sensitive to the shortcomings of being a lone wolf.

At the same time, I try not to forget the beauty of going it alone. First and foremost is the flexibility. Aside from my personal expenses, I have no payroll and practically no overhead. I’m able to turn down work that seems unpleasant or doesn’t jibe with my philosophical predilections, even when the work would pay very well. If I have a good few months and feel like not taking on any more projects for a while, I can do so. I can spend as much time as I’d like working pro bono on free software. On the flip side, when someone approaches with a project that sounds fun but might not pay well, I can take it, guilt-free.

Flying solo also means that I’m constantly being integrated in and out of new teams and projects. I’m constantly exposed to new workflows, new tools, new technologies, new ideas. Sometimes the rootlessness feels lonely, but it can also be exhilarating.

It’s not so bad being a loner.

Affirmations for the free software developer

A friend recently came to me to express some frustration. He’s the leader of a relatively new free software project, and was having his first run-in with a user who was making extensive, arguably unreasonable support demands, in a tone that was increasingly hostile. If you’ve ever contributed to a public project, you have probably had similar experiences.

I responded to him with the following words of “wisdom”. Nothing terribly original here, but I have to remind myself of these points on a regular basis.

  • For every one user who engages with you in an unpleasant way, there are 10 users who provide feedback and request support in a friendly and reasonable manner, and 100 people who are using the software happily and asking for nothing.
  • People only bother to complain about something if they care about it.
  • Obviously, you want to be fair and kind to people who come to you for help. But your capacity to give a shit is like currency: it exists in finite quantities. It’s better to spend it on something that’ll provide positive good in the world, than to dump it into a bottomless pit.

GPL and free software language for government contracts

This weekend at BuddyCamp Miami (which ruled btw) I chatted with a number of folks about putting GPL clauses into client contracts. It can be especially challenging when working with universities or other bureaucracies that have hardcore, work-for-hire-ish intellectual property clauses already built into their consultant contract boilerplate. On a number of occasions, my clients and I have worked with the legal departments at universities to develop new language that fits the spirit and law of GPL software. In my opinion, this kind of work is among the most important work I’ve done since I started in this business, even more important than most of the software I’ve written. By having the discussions with legal, and by getting free-software-friendly boilerplate on their books, we take steps toward legitimatizing free software in the university, and making it part of the culture.

Anyway, I was asked privately to share some of this contract language, and I figured it would be more useful to do it in a blog post than in an email. So here are a few examples that have been approved by the legal departments at large universities. (Side note: We should come up with a system for sharing these kinds of strategy docs in a more organized way.)

  1. This clause replaced one university’s extremely restrictive IP boilerplate:

    Foundation acknowledges and agrees that enhancements, bug fixes and other custom developments produced under the scope of this agreement will be subject to release under the GNU Public License v2, or another compatible and relevant open-source license.

  2. The following clause is added as a footnote to the existing language about IP:

    Section VIII (1-3) shall not apply when work is being performed in the public domain. Consultant agrees to comply with the GNU General Public License version 2, as set out in the Attachment #2, when work is being performed in the public domain.

    A few notes about the language in this second example (which their lawyers wrote, not me). First, “Attachment #2” is a copy of the GPLv2. Second, I think there is a little bit of confusion here about “public domain”, because strictly speaking, “public domain” means that no one owns the copyright, while the GPL is dependent on copyright. I think the spirit of the phrase “performed in the public domain” is supposed to be something like “written for public consumption”. But a literal reading of this clause probably means that I must relinquish copyright over the work done under this contract into the public domain. In this specific case, the end goal is for me to extend one of my existing GPL-licensed WordPress plugins; so I will then be integrating this newly-created public-domain code into the plugin, and then distributing the whole thing under the GPL, with a note that the newly added library is in the public domain. This is not ideal, but it’s OK for this case where I’m building a standalone add-on for my own work – good enough not to continue negotiations 🙂

If I can dig up others, I’ll post them here. If you have real-life examples, please share in the comments.