That time I was a jerk
Yesterday I released the first draft of polite technology, a book I’ve been writing about communciation in the open source world. And today, like many other days, I have already spent some time dealing with a ‘troll’ on GitHub. You know the kind: the person who laces their criticism with personal insults and, instead of being specific and technical, talks in broad strokes about what’s bad and wrong about what we do and how we do it.
That person actually exists, somewhere in the world, typing those screeds. And, no matter what we think in the moment, they’re probably nice otherwise - they probably have friends and relationships, productive and supportive conversations. After all, most of us have been that person at some point.
For me, the moment I realized the dynamic was years ago, on a blog that I had before this one. I had rewritten the Drupal OpenLayers module and was building lots of maps with OpenLayers, and used it as part of my work at Development Seed. Day to day, I would help people on the issue tracker for the Drupal module and sometimes on the issue tracker for OpenLayers itself.
My frustration with certain design decisions about OpenLayers grew to the point that I posted one summary of all the things I thought were wrong about it: the theme system, its handling of projections, the philosophy about versioning - issues both small and large.
I’ve reflected on that interaction a lot, and feel like there are some lessons that I’ve learned over time - reasons why, for me, I felt justified, but eventually it was the wrong way to approach the issue. Here are some of the things.
The gap between maintainer and consumer needs
As a user of software, there are things that we don’t care about. If it works really well out of the box, we don’t have to care about tests. If the latest version is great, we don’t care about version stability. We don’t care if the source is well-thought-out or is full of mysterious hacks. We ideally care about these things, but their lack doesn’t make our jobs any more difficult in the moment, and most development has such a fast cycle that by the time they start to pose a threat, we’ve switched to something else.
I really wanted OpenLayers to change quickly: I wanted them to remove code that was relevant in 2008 from the release in 2010, to change systems in non-backwards-compatible ways, to switch to the new way. For me, as a consumer and as someone who could flexibly rewrite any integration code, that made sense.
But from the maintainer perspective, you care about the long term. You have to care about supporting all the other people who will have trouble with the new version. You have to worry about when that mysterious hack stops working, since it was always kind of fuzzy how it worked in the first place.
In other words, this is a place where consumer and producer incentives don’t align: there are things you want out of maintainers that they don’t want to do, because they have to think long-term and live with the consequences, and you don’t.
Understand where the effort comes from
When I rallied for changes to OpenLayers, I did so as ‘a member of the open source community’ - or simply, just me. Sure, I had lots of users to support, and lots of people used the Drupal module and thus were ‘turned on’ to OpenLayers through my work, but at the end of the day, there are really three roles:
- People with commitment who work on projects daily
- Organizations that pay for full-time work
- Everyone else
I was #3. And you’ll see this dynamic often: supply and demand can kind of work on an economy of hearty thank-yous, but there’s only so much you can insist on something happening before you need to either help or pay.
OpenLayers at that time, had sponsors, and those sponsors had their use-cases. And their use-cases often were the opposite of what I wanted: government organizations desperately want map projection support, whereas average web developers think it’s a distraction. And at the end of the day, the average web developers weren’t gearing up and becoming core contributors, and they weren’t footing the bill.
Remember what you’re concretely contributing to a project.
Fork or switch when it’s time
Part of the reason for my bile was a feeling of helplessness. This is the feeling that causes folks to use the word ‘forced’ in their writing. You’re ‘forced’ to do things one way, or ‘forced’ to use some system. If you feel like you’re locked in and the people in charge will never agree with you, it’s time to PR, fork, or leave, not argue.
Forking or switching is usually as a last resort: it isn’t easy to do and you’re making the open source ecosystem even more diffuse. But when your basic needs and assumptions have diverged significantly, it can be really healthy to leave. You see this in the open source ecosystem - what if, in his dissatisfaction with browserify, Rich Harris had written a rant on Medium, rather than Rollup? Or instead of writing lodash, John-David Dalton had just written a complaint about underscore?
If you have irreconcilable differences, don’t stay and complain: leave and build.
- I also wrote a nicer version of the OpenLayers critique on this blog, but even that isn’t very good and I would write it much differently now.
- OpenLayers 3 was released recently, and it fixes everything I ever disliked about OpenLayers 2. It’s really great.