The Self-Destructive Side of Open Source Software

There was an interesting conversation today on Twitter between Hamlet D’Arcy (@HamletDRC), Marc Palmer (@WangJammer5), and me (@RobertFischer). Marc and I were riffing on our regular theme (our lack of direct financial return from our OSS contributions), and the following conversation ensued. It’s been edited for length: the whole conversation would be here on search.twitter.com if search.twitter.com worked.

That conversation, along with the comments on Marc’s “Do we need a commercial market for Grails Plugins?” post, suggest that there’s a bit of a misunderstanding about the economics open source software. Most importantly, people seem to be missing that commercializing open source software seems to be fundamentally self-destructive.

Take the standard recommendation to support yourself on OSS: offer consulting/training/speaking. The problem with this approach is that you’re directly competing with the time you have to do your development, so the more successful you are, the less time you have for open source. Building a consulting business and prepping presentations and training is hard and time-consuming work and it eats up a lot of your life. There was a blog post a while back (I’ve lost it) which event went so far as to argue that there simply isn’t enough time to be an accomplished open source project lead and be an accomplished writer/speaker. You can’t serve God and Mammon. This has been my experience: I have to make decisions about where to spend my time, and my open source projects are consistently on the losing end of that stick in favor of paid gigs (doubly so since the economic downturn hit my and my wife’s consulting pipelines about a year ago). This dedication of my time to paid gigs over OSS is fine by me—I’m making the decision about how to spend my time with intent and forethought—but it does show that as a way to “support yourself on OSS”, consulting/training/speaking fails because it wipes the OSS off the map.

There is a point where the speaking/training/consulting balance flips is when you can subcontract out the training and consulting, leaving the core developers to primarily develop. This requires a level of adoption and need that is a lot larger than a Grails plugin or minor Java library is going to have.

In addition, I always consider the training/speaking/consulting approach to be a bit of a conflict of interest. If you write a solid, accessible peace of software, what’s the value in your consulting? And if you’re consulting, aren’t you even more interested in just your own needs to the exclusion of what the community may want? The prime example for the latter is the conspicuous change from Jetty to Tomcat for the Grails default server right after SpringSource purchased them. Seems like the existence of Spring tcserver might have something to do with that…

So, if we toss consulting/training/speaking out, I’m aware of basically have two approaches to making money doing open source software.

First is dual-licensing. Zed Shaw makes a good case for it, and I’ve been thinking about giving it a shot with some of my projects. A post by Greg Stein that made its rounds on Twitter today argues the GPL can screw consumers because you’re basically banking on the benevolent dictator remaining benevolent. I’m unimpressed by the argument, which is basically whining that the GPL is too strict a definition of open source for these proprietary-software companies. Greg Stein thinks companies, who are taking open source and making money off it without returning to the community, are somehow “misled” when they rejected the GPL and opted instead to pay for a more permissive license. I have little sympathy for them. If they don’t like the GPL, use the BSD-licensed postgreSQL. In any case, the dual licensing approach seems like a reasonable way to go.

My reluctance to dual-licensing approach is threefold: 1) releasing code under the GPL means having to enforce GPL violations when/if I find them; 2) adoption is stunted, because many companies run screaming from software which even uses the characters ‘G’, ‘P’, ‘L’ in sequence, even if there is an alternative license they could buy into (another self-destructive side of open source software); 3) in the web development space, the GPL basically has no teeth thanks to the so-called SaaS Loophole: you don’t distribute the software but you charge people to use it, and you eventually sell the company (not the software), so the GPL never comes into effect. But it’s better than nothing.

Another alternative is Rich Hickey’s “Funding Clojure 2010″ approach, which is basically begging for donations—becoming an Open Source Friar of sorts. Rich Hickey may be able to get that to work, but I don’t think there’s a big enough audience for my work to get that to happen.

An alternatives along the same line is crowd-funding improvements, but that two critical failure points. First, developer time isn’t cheap—I have to feed myself and my family. Despite the fact that my open source effort might save companies dozens of hours of your developers’ time (assuming they trust their developers to do it, which many don’t!), companies seem to balk at reasonable rates. This is doubly-true in the web sector, where “companies” often means “single-person self-funded start-ups”. Second is that there’s a lot of work involved in avoiding bit-rot on a project which doesn’t qualify as an improvement. When a new version of Grails comes out, I have to go through all my plugins and make sure they still work right, often discovering bugs in Grails in the process. Who is going to want to fund that?

So, if we’re coming up with a way to support ourselves while doing open source software development, we have two critical requirements.

1. Our income needs to come from developing on the open source project itself. Auxiliary income sources ultimately detract from the open source development itself.
2. Our income needs to be ongoing, not single-shot. The shrink-wrapped software model doesn’t work, because the open source software I’m producing isn’t a self-contained product but an adjunct to another piece of software.

So, I’m really not sure what to do with this. A subscription model seems to be in alignment with our requirements, but how would that work? Some kind of patronage would work well, too [EDIT: (see comments)], but is that going to fly in this economic market? I just don’t know.

Related posts:

1. Dear User of My Open Source Project
2. Cry for Help on Open Source Projects
3. Open Letter to Burt Beckwith
4. Source Code Issues
5. Open Source Journaling: Autobase v0.8.1