37signals recently announced that they intend to drop support for OpenID authentication in their products. Good move. Even as a geek – someone who understands the reasoning behind OpenID – I’ve always found the actual implementations of OpenID to be needlessly cumbersome. But that’s not what this post is about. This post is about how a parenthetical in a comment by DHH on a HN post about the news helped me realize something huge about my experiences in the open source community.

The Comment

So, in case you didn’t click the comment link, this was the relevant part of the comment by DHH:

OpenID was promising because it was an open standard, not controlled by any one party. But unfortunately it had the usability of your average open source project (acceptable for hackers, terrible for anyone else).

That last bit is the real kicker.

Audience Disparity

MetaSearch and MetaWhere aren’t my only forays into managing my own open source project. I’ve used Linux professionally in some capacity or another since around 1997, and between that and a healthy dose of Slashdot browsing, I was drinking the RMS kool-aid. I rapidly adopted the typical GNU position – information wants to be free, yada yada.

I started hacking around with Perl, and as an exercise to force me to learn the language, I began work on a webmail client I called NeoMail. It achieved some modest success, though as you might imagine, it’s an embarrassment to me now and I truly wish those who are still using it over 10 years later (my referrer logs indicate you’re out there!) would install something new.

In any case, NeoMail took on an intentionally minimalist feature set. It read mail spools directly, bypassing any IMAP or POP requirements, sent mail using the command line, and didn’t support HTML mail. The thing is, this was the feature set I intended, and I worked hard to make any additional features prove themselves worthy. It quickly found an audience of users who appreciated an easy-to-install webmail application that didn’t try to also be a scheduler or advanced contact manager or cheese grater. All was right with the world.

However, an open source app maintainer faces two disparate audiences. End-users, most of whom can’t understand why you won’t just add one more “optional” feature to the application, and a large group of well-meaning hackers who are happy to contribute patches to add said feature, and fork their own (more open to new features) version if you don’t accept them. Thus, the trend toward insanity. I’d typed up a much longer explanation of all of this, but I think a couple of screenshots really say it better than I can.

The Library Difference

These screenshots just about sum up my early experiences with maintaining an open source app, and my experiences using most other open source apps. It was really frustrating for me. Even then, I guess I wasn’t the typical geek – I valued simplicity over features, and it was clear I was in the minority. I was so soured by the experience that I had even gone so far as to swear off trying to maintain an open source project, and contented myself with making small contributions to the projects of others.

Imagine my surprise, then, when I found myself giving it another shot. After reading a few articles on ARel and the upcoming ActiveRecord 3 query interface, I was dying to bring some more of the ARel functionality to the surface in the Rails 3 apps we would soon be writing at Mission Data. The advent of GitHub, the general friendliness of the Ruby and Rails communities, and the ease with which RubyGems can be packaged all lent me courage to try again, and I’m glad I did. The experience has been a complete 180 from the one I had previously. MetaWhere and MetaSearch have gained widespread usage, and I’ve gotten tons of useful bug reports, patches, and feedback from the community.

Audience Parity

So, for a long time, I imagined the sole reasons for my newfound success were the attitudes of those in the Ruby and Rails communities, and the various community tools (like Lighthouse and GitHub) that simply didn’t exist in 2000. And those are a huge part of it, to be sure.

But after reading DHH’s comment, I’ve come to believe that there’s something else at play, as well. When you’re writing a library, you have one audience: Hackers. Hackers are your users. And hackers, for the most part, admire simplicity in their libraries, because they immediately recognize the benefit that this simplicity brings when they are integrating your library with their code – you know, the code that actually addresses their problem domain. Even when there’s an underlying complexity to the activities being performed, hackers appreciate a simple API to work with because it frees up mental capacity to focus on the actual problems. And, if there is advanced functionality to be had from additional features, the default state of library code is to hide them from the developer until he needs them – they don’t get in the way or add confusion until the developer reads the documentation on those advanced features. Not often so for open source apps, where the gap between hacker and user leads to questionable decisions regarding feature exposure.

So anyway, I guess all this is to say that if you’re like I was – if you tried maintaining your own open source project, and it left a bad taste in your mouth – try again. But this time, write a library. I think your experience may be very different, too.