Consumer-Developers and Contributor-Developers

Although my reputation is primarily tied to Grails, I straddle both the Ruby and JVM communities. Going to Ruby.MN kept me on the cutting edge: many ideas that surfaced in that context would hit the mainstream developer awareness about a year or two later, including CouchDB, polyglot programming, and behavior-driven development. For someone whose livelihood is based on knowing the cutting edge of technology, following the Ruby community is the way to go.

One of the unique things about the Ruby community is that they have positively no fear about diving into the bowels of the libraries they use. Partially, I think this is because of the borderline insanely dynamic nature of the Ruby language, which is why I satired that functionality in Ruby is the Future⁰. Whatever the reason, though, Ruby developers seem motivated to really explore and grok and push the boundaries of libraries, and that is awesome: that kind of adventuresome development drives new innovation and pushes people to become better developers.

⁰ If you read that April Fool’s Day post, be sure to read the follow-up at April Fails or April Fools Epic Win? On “Ruby is the Future”.

Leaving that context and going into the JVM environment, though, is some serious culture shock. Java developers have a conception that libraries are black boxes, and if you have to go reading into the library’s source, that means the library is in a certain sense broken. The idea is that the API of the library is the thing you should be coding to, not the implementation. Given that, reading the implementation is bad form, because all it can tell you is non-guarantied functionality which may well break in the next release of the library. Coding in a way that breaks your upgrade path is incurring technical debt, and therefore to be avoided if you want to stay agile/lean/whatever and be able to leverage the up-to-date library functionality.

Both of these approaches have dark sides, however. The Ruby approach encourages under-considered APIs and “works-in-my-case” libraries, which probably accounts somewhat for the Ruby community’s tendency to throw off a multitude of gems to solve the same general problem. The Java approach encourages a sense of helplessness if the library doesn’t work precisely as expected: since there is such an emotional barrier (not to mention technical difficulty) in cracking open the library, contributions to that library tend to come in the form of helpless, pleading bug reports.

Now, this portrayal of the distinct communities is obviously a gross generalization, but it is interesting to consider these alternative approaches to open source. Once upon a time, open source required a level engagement with the source which made all the users of a project de facto developers on that project. Now, though, many developers can consume an open source library without ever having to know anything about its inner workings. Not finding existing nomenclature, I’ve referred to these two different approaches as Contributor-Developers and Consumer-Developers¹, respectively.

¹ I dislike the terms users vs. devs for an open source project, although that’s one distinction that’s somewhat related. The issue is that “users” is an ambiguous term in open source projects: it’s easy to see the confusion with projects like WordPress, which have non-technical end users, middle-tier consumer-developers, and contributor-developers. The “devs” side is blurred on projects like Grails and Rails, where the innards of the system are wide open and there is an expectation that anyone but the most novice users will be comfortable taking a look.

There’s a tendency among some open source enthusiasts to try to blur this distinction—to say that even consumer-developers are contributing in a sense, because their helpless and pleading feedback is at least some feedback, and therefore positive for the project as a whole. While it’s true consumer-developers are contributing to the product when they provide useful feedback, there’s a more fundamental difference in approach which needs to be respected. Consumer-developers and contributor-developers have different understandings of what open source is, and therefore they expect different things out of their open source library.

To the consumer-developer, open source is a solution to a problem. It’s a product. This kind of mindset is demonstrated by Burt Beckwith’s “Free Toilet” response². You can really hear the voice of the consumer-developer mindset in these snippets:

We use or buy it because we don’t want to, don’t have the time to, or can’t implement it ourselves. It’s disingenuous and selfish to claim that since you gave it away for free, you have no further obligations unless that’s made explicit from the beginning.

I’ve talked to other Grails users about writing and supporting Grails plugins and I half-jokingly caution them to not release them. It’s work. It’s a product.

Another Grails plugin developer who has been rather prolific (although not so much lately) stated with the release of a couple of his plugins that he wouldn’t be doing any further work on them. I’m fine with that – it’s honest. It’s somewhat annoying – support yer damn product

² Here’s the original “Free Toilet” post, and my response to Burt’s post.

If you are developing open source software for consumer-developers, you are committing to providing a high degree of polish, documentation, and support, and you can’t expect to get help. Note that right of the bat, Burt equates software usage with “use it” and “buy it”, and that’s the key idea: you are a vendor, and the users are your customers, so the flow of work is basically unidirectional. That’s taking a lot on yourself, but these projects are the ones that get the widest adoption because they have the lowest barrier to entry, and so if you are developing open source because you want to improve your reputation or get the warm-fuzzy of being an altruistic³ contributor to other people’s success, then this is your target audience. And if this is your target audience, you shouldn’t release a project unless it is already fully polished and if you’re willing to make maintaining it your hobby.

³ Read: “uncompensated”

Developing for contributor-developers, however, is different. When you develop for contributor-developers, you’re just sharing code. You’re saying, “Hey, here’s a hunk of my code which is tangential to the business logic of the project. If you find it useful, feel free to use it.” This was the conception behind JConch and GORM Labs and all my CPAN stuff. None of these solve a particular problem, but they contain tricky code in a related topic area.

The important thing to realize is that sharing code is a substantially more limited relationship than providing a solution: if you are sharing code, you’re simply saving development time and providing a way for people to model future code. Since cracking open the codebase is expected, extending it and contributing to it is also something’s that is expected. Conversations among contributor-developers about how and why things work should be standard, whereas the consumer-developer is only going to be interested in what APIs are provided and when extension/fixes will be ready.

When I wrote the “Free Toilet” post, I was partially responding to the culture shock of contributing to perl’s CPAN and being engaged in Ruby’s gems: when I got involved in Grails and started contributing, I expected it to be more akin to Rails, but I was instead getting flak for providing an under-polished product. I thought I was contributing code to a communal pool, and then being faulted for not contributing enough into that pool. It struck me like I was putting stuff out there for fun, but getting nothing back except feedback saying I wasn’t doing enough or not doing it right or whatever. What I was really being told was that I was trying to establish a contributor-developer relationship with a consumer-developer community, and that dissonance left both sides feeling slighted.

Now, I’m not here to say matter-of-factly that the contributor-developer approach is the only one that’s valuable: I am a consumer-developer of postgres, Open Office, Linux, GMP, Felix, Apache Commons, and a variety of other open source projects, and so it would be wildly hypocritical of me to knock that approach. But it is important to have space for the contributor-developer open source projects, because that approach saves developers a lot of time and the low barrier to entry brings out a lot of open source contributions which might later evolve into more product-style offerings. Consumer-developer projects may be where the adoption is, but the innovation is in contributor-developer projects.

Related posts:

1. Dear User of My Open Source Project