Let’s drop the unrealistic expectation of total transparency in open source
Running a large, long-running open source project like Ruby on Rails is very rewarding but can also be exhausting. The glimmers of glamour usually only sparkle around release time, but the grunt of the grind is daily.
The grind is an endless stream of bug reports, requests, demands, questions, and occasional inquisitions. To avoid getting stuck in the mud, you need to travel as a team, not solo on a lonely road. Without the backing of stable, friendly faces, you simply aren’t likely to go the distance. It’ll be thanks for the fish and adios muchachos!
A big part of this feeling is that co-chairing a popular open source project means you’re always ON in the public space. Every reply to every ticket, every comment to every discussion is fair game for dissection, scrutiny, applause, or ridicule.
Doing the work of justifying choices, presenting arguments, and collaborating on code in public is great for transparency, but also at the heart of why the work is so draining. Everyone needs a place and a time to retreat. To step out of the spotlight and loosen the guard.
We’ve embraced that need on the Ruby on Rails team through a series of contracting circles of intimacy and privacy. There’s the community at large, where all the interactions happen in public on GitHub or the mailing lists or wherever. But then there’s also a Rails Community Basecamp, a Rails Contributors Basecamp, and finally a Rails Core Basecamp.
I appreciate that the standard response from the open source gospel is that this is somehow sacrilegious. That total and complete transparency into all matters of an open source project is more important than the mental well-being of its long-term, key contributors.
I’m sympathetic to that ideal. Surely Rails would be worse off if everything happened behind closed doors, the community at-large wasn’t involved in anything, and releases just dropped from the sky. But there’s a nuanced world of grey beyond those extremes where healthy, happy people live and work.
We’ve long since accepted how pivotal our individual idiosyncrasies are to the art of programming. That much of the work in programming tools and languages reside in tickling the interface between code and our all-too human emotions. It’s well past due that we recognize the same fallibilities are present at the group-level of development, and that we find ways of working to accommodate these.
I’ve worked on Ruby on Rails for more than thirteen years now. The only way that’s been sustainable and enjoyable has been to protect my sanity and motivation in dealing with the encouragement and discouragement, judgment and praise from thousands of strangers over the years.
Letting smaller groups do some of the work and shoulder some of the exhaustion in private has been a key strategy. It’s a small trade-off to complete transparency for the well-being of the most active participants. I’m not going to feel bad about that.