Monthly Archives: May 2012

The “patronage model” for free software freelancers

· 9 Replies

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.

TimThumb problems and solutions for WordPress theme developers

· 4 Replies

TimThumb is popular PHP script for dymanic image resizing, and is often included in WordPress themes and plugins. It caches its processed images for performance reasons; its default cache directory is called cache, one directory level up from the script itself. TimThumb itself helpfully allows users to define a custom cache directory with a constant (FILE_CACHE_DIRECTORY) as well as a mechanism for loading this custom configuration (an optional timthumb-config.php file).

This setup provides plenty of flexibility when you’re using TimThumb on a one-off site for a client. But when TimThumb is packaged with a theme or plugin, this method of configuring TT not very helpful. Take the case of WooThemes, which uses TimThumb in all of its themes. We use a number of these themes on the CUNY Academic Commons, where I keep tight reins on file permissions. Our Apache user can’t write to the subdirectories of wp-content/themes/, which means that the versions of TimThumb in this directory can’t use the default cache location.

The problem is that there’s no easy way to fix this in a global way. Creating a /cache/ subdirectory in each of these theme directories and chmodding them to something more lax is out of the question in my scenario. After all, I already have a directory where Apache can write files: the WP uploads directories (wp-content/uploads and wp-content/blogs.dir).

But configuring TimThumb to put its cache in one of these places is difficult to accomplish globally. The obvious solution is to create appropriate timthumb-config.php file in each of the theme directories in question. This stinks, though, because it means that my modifications will have to be reapplied each time I upgrade the themes. In fact, what I’ve actually done for the moment is a variation on this: I created a centralized timthumb-config.php file, in a centralized location (wp-content, in my case), containing a single line:

[code language=’php’]

[/code]

I wrote a short script that crawled over every one of my WP themes, and if it found an offender (in my case, any theme with ‘WooThemes’ in the Author tag), create a symlink to the global config. I’ll be including this script as part of my more general deployment scripts.

Of course, this is all extremely inelegant. There are a few things that the theme developers could have done to account for my sort of situation:

  • Stop putting a copy of your shared utilities (the “framework”) in every theme directory. I understand why the theme shop might make this architectural decision – I’m sure that the vast majority of their theme sales are to people running the theme on a non-networked, single site. But it causes a lot of problems for Multisite networks that offer many themes to their users: a single change in the framework means updating all themes, which becomes a real pain if the theme dev’s autoupdater also isn’t working properly. Allow your framework to be installed as a network-activated plugin, or at least dropped into the wp-content directory. Better still: You can continue to ship the framework files with the themes, but only load them if the pluginified version is not found. That gives you the best of both worlds.

    Now in the case of TimThumb, this schema wouldn’t have solved the problem. But it would have meant hacking a single file, rather than 50 different files spread out through my installation.

  • Put a wrapper around TimThumb, to allow more flexible placement of the config file. For instance, create a file called mytheme-thumb.php, which looks like this:

    [code language=’php’]

    [/code]

    Then point all of your TimThumb-generated src attributes to mytheme-thumb.php, instead of directly at TimThumb. This way, if a global config is found, it’s loaded first, otherwise it falls back on a local timthumb-config.php file, as specified by TT itself.

  • Pluginify TimThumb before using it In a perfect world, you would have the flexibility of WordPress behind TimThumb: the ability to store your cache location to the database, for example, or to filter the location using apply_filters(). I did a bit of testing to see just how much overhead this would add. In my tests, TimThumb used about 700KB to load a simple picture. To load WordPress using the SHORTINIT constant (which loads just enough of WP to get things like get_option() and apply_filters()) takes about 2800KB. So loading WP SHORTINIT + TimThumb would take about 3500KB, or about 5x what it takes to load the same image using TimThumb alone. This wouldn’t be so bad with aggressive caching, but it’s probably too much sacrifice for a script that may get called several times on every single page load.

    So here’s another idea: Just drop in wp-includes/plugins.php. I once heard someone say that a great way to improve any PHP package is to include this file, and I think they’re right. plugins.php is self-contained (it doesn’t require the rest of WP), and it only adds another 50-100KB of overhead. Let’s take our mytheme-thumb.php file again, but add some plugins.php goodness:

    [code language=’php’]

    [/code]

    Now in this example, thumb.php wouldn’t have to be an out-of-the-box TimThumb instance. It could be filled with wonderful do_action() and apply_filters() goodness. And your global-timthumb-config.php or timthumb-config.php file wouldn’t just define constants – you could have full-fledged PHP functions, using WP’s hook infrastructure.

    This means maintaining a fork of TimThumb, but it could be a great resource for WP theme developers.

One year as an ex-academic

· 8 Replies

I realized the other day that it’s been just over a year since I quit graduate school, and by extension gave up on a life in academics. It was around the middle of April 2011 when I submitted my resignation letter. (I was spending the month teaching a course at my alma mater, and I felt more than a twinge of poignancy at the fact that I wrote the letter just a few hundred feet away from where I’d written my acceptance letter about nine years earlier, during my last semester of college.) Anyway, I thought I’d take a moment to reflect on how the year – my first spent as a non-student since I was four years old! – has gone.

The most personal of my fears about leaving graduate school had to do with the way I define myself. I was proud to think of myself as the academic type, and doubly proud to think of myself as a philosopher. (Observation: when someone who wears many hats does some work in philosophy, it’s common to see “philosopher” move to the front of their list of self-descriptors. Quelle prestige!) I’d spent about a third of my life under a certain avatar (in name if not always in practice), and I was nervous about casting it aside. How would I think of myself? How would I describe myself to others?

It turned out that the transition of self-definition was much less difficult than I’d feared. There are a few reasons why. First, from a practical point of view, I wasn’t really that engaged in my academic work anyway. The second half of my graduate career was characterized by attempt after semi-subconscious attempt to distract myself from the philosophical tasks at hand. These attempts were overwhelmingly successful, with the result that even when I did devote large amounts of time to doing philosophical work – which happened in fairly infrequent but significant bursts – my heart wasn’t really in it. A second, related reason for the easy transition is that, as a result of years of productive distraction, I had a number of alternative, and more meaningful, identities on which to fall back: software/web developer, educational technologist, teacher, etc. I imagine that such a transition would be far more difficult for someone who didn’t have viable alternatives.

So, from the internal point of view, the transition from academic to ex-academic went more smoothly than I’d hoped. The external transition – how the change has affected my relationships with others, or at least how I perceive the relationships – has been a little bit harder.

The thing is that, while I’m not one of the academics anymore, I spend much of my time with them. Most of my professional work is for universities, and many of my friends and co-workers are tied to schools in one way or another. Thus, I haven’t been able to quit the academic world cold turkey: I still have to go to meetings, deal with institutional BS, navigate political obstacle courses, etc. These are the crappy parts about working in universities, and becoming an ex-academic hasn’t made them any better in my case. (Admittedly, this is because of choices I’ve made to continue working where I work. I have friends who have left to go into, eg, banking.)

In addition to the more obvious annoying bureaucratic details of working within the university, there are the negative social aftereffects of dropping out: I don’t have a PhD, and never will, which means that I’m viewed (or at least, I feel like I’m viewed) in a different way. My opinion on academic matters just doesn’t matter in the same way anymore. I suppose that’s as it should be: the more time I spend away from the day-to-day of the university, the less relevant my opinions about that day-to-day become. Thus, when doing development work with universities, I’m a developer with some helpful experience in academia, rather than a technically-inclined academic. I should note that there have never been any specific instances where I’ve been called out on this distinction, or where it’s had an obviously negative effect on a relationship, but it’s always there in the background. (On a related note, I’ll probably never have a job where I, say, lead an academic computing program – but that’s not something I really want anyway.)

Thus, while I hate to sound sourgrapesesque about it, I haven’t lost much of anything by dropping out. I’m still heavily engaged in enabling the functions of the university that I find most important: teaching and scholarship. It’s just that I do it one or two levels of abstraction higher than when I was in the classroom or the library, and maybe it’s just as well.

On a personal level, the gains of dropping out have been enormous. Not only do I no longer devote any time to working on a project that I’m not really invested in (the dissertation), but I also no longer feel the crushing weight of the unfinished dissertation in my spare time. In the past year, I’ve read more broadly than ever in my life, discovering and developing areas of interest that I would never have dared to devote time to. I’m a new dad and I work from home, which means that I’ve been able to be the kind of dad I’d always hoped I’d be, without feeling guilty about the work I “should” be doing. I’m making an amount of money that is directly connected to the quality of my work, a startling and frankly disarming contrast to the way things seem to operate in universities, especially in the work I did as an adjunct. It’s been about a year since I intentionally read anything explicitly philosophical, but recently I’ve started to feel that itch again – and when I pick up a book or article, it’ll be because of an independent interest, rather than because it’s in an Important Person’s Bibliography.

So for me, quitting graduate school has been a nearly unmitigated success. It took years to work up the courage, and to develop the alternative paths that would make quitting feasible, but once those factors were in place, it was really the best decision I could have made.