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.

Comments

• October 5, 2009, Marc Stock wrote: To a consumer-developer (i.e., 95% of all developers), the contributer-developer only exists in your mind. I don't think I've ever worked with another Java developer who felt that they should be (by default) be a contributer to any project they consume. Most devs just want something that makes them more productive and that's it. So the other 5% who make this stuff have an entirely different mindset from the get go. Consequently, they think contribution is a natural part of the ecosystem. Which is cool but it's unrealistic to think more than a handful of people will feel the same way. Just an FYI...I have never contributed a single line of code to an open source project. Not because I don't care about them but I simply have other things I'd rather do with my free time (like play guitar and read up on cool new technologies...oh and other libraries I can consume). Now, I have no spouse, no children...just a dog. So someone who has those things will have even less free time than I and are consequently even less inclined to contribute. That said, people who do contribute to open source have my utmost respect. I do realize the time and commitment involved (and sometimes even personal expense). So my hat's off to you all. Even if your library sucks, I will still give you props for having the gnads to put yourself out there like that. Finally, what you say about Java devs is true. Very few go into the libraries they consume. (I will look at library source but it's for debugging purposes, understanding the thinking behind it, and making up for crappy documentation -- not for writing code that exploits implementation details). They also rarely look at new libraries or keep up on the latest and greatest toys. Hell, I can't get 90% of all Java devs I've ever met to even try another IDE than Eclipse even though they complain how flaky it is and have to restart the damn thing three times a day. This is why I like going to GUM meetings where I get to chat with people who aren't afraid of trying and embracing new things. Anything that makes me better, faster, stronger has my rapt attention. Oh, and I'm not shy about paying for it either.
• October 5, 2009, Robert Fischer wrote: I'm not sure the numbers are high as 95% (you're probably biased from being in a Java environment), but I'm very aware that my take is a minority take. After all, there certainly is a higher adoption of consumer-developer projects, which means we're fighting upstream. And the predominance of the consumer-developer paradigm means that contributor-developer projects are going to get flak forever. So, the question contributor-developer projects are faced with, then: should you take your ball and go home? Should you just not share your code? Or maybe just post it via blog posts or let it rot as GitHub projects nobody ever sees? It's just not worth it to me to expand JQuery PeriodicalUpdater or Sublog into something I'd be willing to construe as product offering: I don't see what I'd get out of that, and I quite literally don't have the free time to burn on things which aren't getting me paid or grades. (Even this blog post and comment are done on borrowed time, when I should be working on my book.) And the "work on open source, it'll get you paid!" line is false to fact in my experience.
• October 6, 2009, Hamlet D'Arcy wrote: First off, GOOD JOB. This post is a much more thought out, better written, and better presented than the free-toilet post. It is much easier to see that you have a good idea when you strip away all the flippant (albeit humorous) surroundings. I think you've discovered a very useful generalization that applies to people and communities. But communities are the important part! One thing that I really like about the Ruby Community is their embracing of alternatives and crazy ideas. Some real innovation was born there. The Ruby MN group feels like a bunch of free thinkers... comparable to something like the Vienna Circle. ("Oh, you want to rewrite bytecode, let me help you." JUGS often feel like products of derivative work ("Oh, you want to release a library, let me show you how to make the API adhere to the guidelines in Practical API and Effective Java"). Both have value in context, but an individual should probably choose which path to take when releasing software. Mixing the two approaches seems to be creating the conflict.
• October 6, 2009, Robert Fischer wrote: Yeah, the "Free Toilet" thing was my initial knee-jerk reaction. I got some crap for my free work not being documented and functionally complete enough, and when I suggested that the complainer contribute the documentation/functionality they'd like (Y'know, "Be the change you want to see."), the response was, "But it's your project. You're supposed to do this stuff." i.e.: You're supposed to put more free work in to make sure your project meets my standards, and I'm not willing to put any skin in the game. Suffice it to say, I did not take that well. That post's finally published form is actually the third or fourth iteration, with each one becoming less vitriolic. The original title was "FYI: My Open Source Users", and basically told everyone to shove it. That wasn't really what I wanted to say. When the "Free Toilet" version came around, I still wasn't sure what I wanted to say, but I thought that was closer. It actually took Burt's post and the Grails Podcast discussion to make me realize what was going on. That plus a few weeks of trying to really crystallize it in my head resulted in this post.
• October 6, 2009, Robert Fischer wrote: The sad thing about more refined, well-thought out posts is that they don't make their way through the internet. :P
• October 6, 2009, Marc Stock wrote: "The sad thing about more refined, well-thought out posts is that they don’t make their way through the internet. " Indeed, reason doesn't sell. It's just not controversial enough. It's why there's no real news on TV anymore.
• October 7, 2009, Doyle wrote: I'm largely a consumer but have contributed when I see a common problem. I do agree that most developers are consumers. I do encourage devs to download the dist with source and docs. I do think one thing you are missing is the psychology of open-source development. Writing code is personal you own it, you made it, it is your sweat. When you release it you are really putting your self out there. When I watched this video it explained it well http://code.google.com/events/io/sessions/MythGeniusProgrammer.html I think more people would contribute if you could change the culture. I think the ruby camp might have a less built up well tested libraries and the may have a better attitude of putting your self out there. My last bit is that some of use the libraries to make kick-ass products and that is the ultimate compliment when you use someones code. I used 'I' a lot here.
• October 7, 2009, Robert Fischer wrote: @Doyle How do you see the "Myth of the Genius Developer" factoring in here? After all, I'm basically complaining because I don't get enough contributions. If someone wanted to step in and take over some of the open source projects I've thrown off, I'd be more than happy to let them. So far, no takers. For my part, I never really had a problem with throwing open source stuff out there. I figure if it's good, it's good, and if it's bad, someone will replace it, and then I'll have a better solution. Contributing to existing open source projects is a bit trickier unless you know the person/people running it: I've encountered a few situations before where the perfect is the enemy of the good, and my patch gets rejected because it's not 100% perfect. The sad part is the core developers usually build something in even more limited than the patch I submitted later on.
• October 7, 2009, doyle wrote: Basically I think most people who would release something don't because they see the end product and it's usually 90 to 95 percent good. They don't see the process/progress of the build up to the initial release. And the other reason you hit it with contributing to existing projects.
• October 8, 2009, Dan wrote: I have noticed that a 2 line patch is the Open Source developer's equivalent of a $15 bottle of wine. It might not be appropriate to the current meal, but it is almost always appreciated.

(Digital Fingerprint: bcecb67d74ab248f06f068724220e340 (203.215.201.194) )