The Self-Destructive Side of Open Source Software December 14, 2009 | 11:07 pm

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.

  • Eric Pederson

    What about dual licensing with AGPL?

  • Marc Stock

    “Some kind of patronage would work well, too, but is that going to fly in this economic market?”

    No, it won’t. Of course, it won’t fly in a good market either. I’ve found developers to be unbelievably cheap bastards. You could produce a tool that would save them 2 hours of time a day and unless they can get it for free, they will tell you to f* off. You may think I’m overstating things, but I’m really not. I’ve tried to convince people to buy tools with clear value many many times in my career and it just doesn’t work. I’m one of the only developers I know of on the planet who actually budgets money every year to buy whatever tools, libraries, etc. I want. That budget is generally $1000 per year. I challenge you to find a developer who even sets aside $50 per year. If you ask them why, they will tell you that their company must by it for them. It’s funny that car mechanics (who make a third of our income) buy all their own tools (yes, repair shops almost always require mechanics to pay for their own tools) which adds up to thousands of dollars and don’t bat an eye because they know that’s what they need to get their job done efficiently.

    There’s a big problem in developer culture that needs to change but I don’t see any change on the horizon.

  • http://www.smokejumperit.com Robert Fischer

    @Eric Pederson

    The AGPL does solve the SaaS loophole: see In AGPLv3, what counts as “interacting with [the software] remotely through a computer network?”. So that’s one issue down. Like I said, I’m inclined to try the dual licensing route: I just don’t have a lot of hope for it.

  • http://www.smokejumperit.com Robert Fischer

    @Marc

    That’s been my experience, too: it’s hard to get money out of the developer community unless you’ve got a cult of personality which drive people to your products *cough*37Signals*cough*. IntelliJ seems to have bested your cynicism, but that’s about the only one I can point to.

    The “patronage” model I was referring to isn’t the kind of watered-down meaning of “WalMart thanks you for your patronage”. I’m talking about a full-fledged “I want to hire this developer to do cool stuff to solve our problems, so that the cool stuff flows into our business first”. Even ignoring explicit brain shops, there are a few de facto patronage relationships out there I’ve seen—usually someone with the title of “architect” who solves problems in the large by providing tools for work in the small. If that kind of position could be merged with OSS work, that’d be my ideal kind of situation.

  • Marc Stock

    I can’t even get most developers to *look* at IntelliJ, let alone buy it. Almost every one tells me that either Eclipse is perfectly fine so there’s no need to look elsewhere or eclipse is free so how can something that can only be “incrementally better” justify the price. I don’t even try to convince people any more. I can also name at least a half dozen developers who were given free licenses to IntelliJ who won’t even download it.

    Your patronage idea is cool although I’m not sure how you sell it in today’s world. It’s a pretty old school idea though. Patronage was how most artists were funded through middle ages and renaissance, as I understand it.

  • http://www.smokejumperit.com Robert Fischer

    Despite your experiences, JetBrains seems to be doing just fine with it. I see a lot of IntelliJ in the wild on the NFJS tour. And especially in the early days of Groovy/Grails, IntelliJ was pretty much ubiquitous on in my contracting world.

  • http://www.smokejumperit.com Robert Fischer

    BTW, the patronage model is the basic model underlying my Grails Retainer services. And that’s working out somewhat well, although work hasn’t been as long-term as I had envisioned.

  • http://hamletdarcy.blogspot.com Hamlet D’Arcy

    >> This has been my experience: I have to
    >> make decisions about where to spend my time

    Congratulations on being an adult: the long era in your life where you have to make tough decisions between what makes you happy and what your obligations are as a human. If you would like to see this effect magnified then you should have children. Then you’ll really be confronted with tough decisions about what you want versus what your family needs.

    I, for one, have enjoyed this period in my life. I feel that finding the balance between work, my daughter, graduate school at night, my wife, and open source software has made me a better person. I don’t really have friends, but that was just one of the tough decisions I’ve had to make. Honestly, you and the gang at Groovy.MN are my closest friends, and we see each other less than once a month! Ok, I’m officially sad now…

  • http://hamletdarcy.blogspot.com Hamlet D’Arcy

    And here is the quote that popped into my quote a day just now:

    I don’t know why we are here, but I’m pretty sure that it is not in order to enjoy ourselves.
    – Ludwig Wittgenstein

  • http://www.smokejumperit.com Robert Fischer

    My question isn’t about what makes me happy vs. what doesn’t: my question is how to we build a sustainable OSS ecosystem, especially in the context of Grails plugins but also with respect to things like Rich Hickey’s work on Clojure. In looking at the OSS ecosystem, we have two choices: 1) we accept that OSS/Grails plugin dev is a “free time only” enterprise; or 2) we need to have a way for people to support themselves.

    If we accept #1, we need to be honest about that and build a liveness check into the Grails plugin ecosystem, because the 300+ plugins are actively and quickly bit-rotting and that’s just how reality works. Also, if we are accepting #1, then people need to back the Hell off and not be so demanding of the plugin developers (see the Free Toilet post).

    If we accept #2, then we need to figure out how people are going to support themselves, which is what this post is exploring. And I’m noting that relying on consulting and speaking to support OSS is destructive to the projects: it’s not a workable model/expectation for OSS support, at least in the world of the Grails plugin ecosystem.

  • Pingback: DynamicDomainProperties and the AGPL

  • Pingback: The Origin of The Indie3 Project | The Indie3 Project