About Open Source Stewardship
It's the end of the year, and, as is my wont, I've been thinking a fair bit about the things I'm thankful for in work and in life. One of those things, that has positively affected my work dramatically over the last 10 years, is the role of community in programming. In particular, the tireless work of talented, unpaid OSS project maintainers. The folks who generalize solutions to benefit all of us, who listen to our complaints, who fix bugs, apply our patches, manage releases, and all the other good stuff that comes with responsible code parenting.
So there I am, feeling all warm and fuzzy and thankful, tweeting my thanks to the good people who make my life easier. And then Jeff Atwood, one of my favorite bloggers, goes and harshes my vibe. On Wednesday Atwood wrote a piece for Coding Horror about the responsibilities of Open Source project parents. Using John Gruber, creator of Markdown, as an example, he basically says that Gruber, after giving birth to a coddled and universally loved baby, has pretty much stunted baby Markdown's growth through poor documentation and not listening to its community, resulting in a a number of messy forks and general confusion about where things might or might not be going.
Oh, the drama! Now, I'm not really up on my Markdown project history (frankly I prefer Textile for humane markup, but I'm weird like that), so I can neither refute nor confirm his claims. But it's a well-written article and certainly what his article did do for me was get me thinking further about what makes a great bit of OSS code into a sustainable, thriving OSS community project.
There are two things that make an Open Source project successful, from my point of view.
First, of course, the general utility of the codebase: is it innovative? Does it solve a problem or save you time? Is it better thought-out than what you could implement on your own in some reasonable amount of time?
Second, assuming the first criteria is satisfied, the project maintainer or steward. Is s/he responsive when someone submits a bug report? (there is a way to submit a bug report, right?) Do they actively engage with the community through a mailing list or other public forum? Do they encourage contributions and run the project in a democratic manner as to not encourage long-lived forks? Do they encourage unit and acceptance testing where applicable? Are new releases pushed out semi-regularly? Are they a strong leader with a good sense of what the project should be? Sometimes less is more, after all.
It occurs to me that the success of a long-lived OSS project is ultimately more about its maintainer being alert, responsible, and conversational than about the quality of the code that they're curating. Not that code quality isn't important of course, but we just take it as a given that anyone who cares about Open Source and contributing to a larger community is a competent software author.
I've often heard people say that they wouldn't hire someone as a developer who had never contributed to Open Source. I agree with this stance; in today's free software world, it's not only a best practice but a requirement. By giving something back you've shown that you're not only a responsible citizen but that you also know how to read and debug other peoples' code, and contribute to an ongoing project with many authors (sounds a lot like most production software projects, right?)
But while contributing to OSS is an exercise that every developer should be taking part in, not just anyone should be an OSS project maintainer. Maintaining an active project takes a fair amount of time, and requires ongoing dedication and love for the project itself. Most of us use OSS when we need it. That is, when you're working on a project that requires a Ruby-based CMS maybe you choose Radiant, and you find a bug or an optimization you can make. So you fork the project (on GitHub of course), update your branch, and send a pull request to the core team. Then you move on, and might not use that code again for quite some time. If someone else has issues with it, that's not your problem.
If you're on the core team for that OSS package, or you're a lone project steward on your own project, that responsibility never goes away. You've committed yourself to be partly responsible for the long-term success of the software you're maintaining and all that comes with that. It's much like being the boss, of a small company without a revenue model and full of volunteers. In other words, it can be hard work.
Project stewardship has its rewards too, of which I could write another long, rambly blog post if given ample time and opportunity. But the point is that these folks -- the ones that are running long-lived OSS projects, especially those that are doing it as individuals without a company affiliation or a 'core team' of co-conspirators -- they're doing us a big favor. And if they're doing a good job at it, well that's something that we should commend them for.
It's relatively easy to release OSS these days, and if you're a great coder with fantastic ideas and your code is truly useful or interesting, it'll find its audience based on its own visible merits. But to then grow that project from a neat hack or toy framework to a professional-quality product with a release cycle and feedback loop that engages the community, well that takes a certain sort of talent that not everyone has and isn't always tightly-coupled with great software craftsmanship. In fact, many very successful projects are handed off by their birth parents to foster care, much like a startup would hire a new CEO after the founder moves on to other early-stage ideas. There's nothing wrong with this. It's responsible.
As we wrap up this holiday season and prepare to go back to work in earnest, think for just a few minutes about what some of your favorite mature OSS projects are, and how much work the diligent stewards responsible for that project have saved you, how responsive they've been to your patches and mailing list messages. Maybe write a brief thank-you note on the authors' blog or send them a small donation to continue their work, if you can spare the time or expense.
Atwood's certainly right that there are some bad software parents out there (I have no idea if John Gruber is one of them, but I do like his writing in any case). He's also right that bad OSS stewards can derail otherwise awesome software libraries. But I just want to point out that I think the very nature of caring for long-running OSS projects can be difficult, and although that's no excuse for a bad steward (pass that duty off to someone else then!) it certainly does say an awful lot about the good ones. Good project stewards are like sysadmins; if they're doing a great job you often don't know that they're there at all.