It's been a while since I've posted anything about open source communities, but that doesn't mean I haven't continued to think about them. It's an issue that's near and dear to me and I spend a lot of time considering different aspects of open source. I'd like to take a moment to talk about one of those in particular: feelings. More specifically, why they matter in open source and some ideas on how best to incorporate them into our open source interactions.
I want to be clear: while the Twitter exchange was essentially subtweeting a particular blog post, the rest of what I write below is more general. I don't want there to be confusion about what the blog post in question does or doesn't say, or how it does or doesn't present it's arguments in contrast with what I write below. I think this issue is more general than that and so I'm not going to link to the other blog post to avoid distraction.
In the Twitter thread I used an analogy of building a bird house. If I want to assemble a simple bird house by joining sides together with nails, I have a whole toolbox at my disposal. I could use a screwdriver and drive the nails with the handle. I could pull out a rubber mallet and use that. Or I could select a hammer and get the job done efficiently and quickly. It seems obvious that everyone should choose the hammer. But what if I really like screwdrivers? What if I've never even seen a hammer but I'm really good at driving nails with a handle. Maybe I simply don't feel like learning about hammers right now?
This brings us to the first point I was trying to make: that people choose tools for all sorts of reasons and there's never really a "best for everyone" option. A vibrant open source community should have lots of tools that could drive those nails, and we should celebrate and encourage that diversity because you never know when a nail is just the right shape that it can only be driven by a screwdriver handle. In my opinion it's far more valuable to talk about why hammers make a good choice for driving nails than why screwdrivers do not. That gives the consumer room to weigh their own use case against the stated benefits of all their options and pick the best one for them. It might seem like saying "screwdrivers are terrible for this because..." is valuable, and maybe it is (more on that below), but without actionable information about what else I could use it's kind of moot point. And if I'm going to be talking about why a hammer is such a great tool for this job in the first place, is it really all that important to mention the screwdriver?
This is where the birdhouse analogy starts to fall apart in the context of open source. Open source tools and libraries are not physical items in a toolbox. They're not manufactured by faceless tool companies for the purposes of monetary profit. And this brings us to my second, and more important point: open source is (mostly) created and consumed by individuals and we need to be mindful of the inherent humanity in such a system.
I can relate to the idea that as software craftspeople we need to put feelings aside and be analytical about our choices, both for ourselves and for our communities. After all, that's how we've been trained to write software in the first place. If a particular convention, methodology, tool, etc. isn't the best, shouldn't we do everything we can to make sure that knowledge reaches far and wide so everyone builds better software? Like other engineering disciplines, feelings have no place in this world. Does a structural engineer reserve judgement on a bridge design just because it might upset one of their peers? People might die if they do.
But here's the thing: open source is different. It's different because the people behind it, the people making it tick, are largely doing that for free, in their own time, without a defined and accepted convention for compensation (monetary or otherwise). As a global software community, we are in the midst of trying to figure out how to make open source more sustainable. There's been a lot of discussion around this lately and there will continue to be a lot more. It's a real problem without a good solution right now. And one of the biggest sustainability challenges is how to prevent burn-out. How do we, as software practitioners who rely more and more on the generosity and selflessness of open source maintainers, ensure that those maintainers stay healthy?
I think one of the ways we do it is by recognizing that this open source system we rely so heavily on has an intrinsic component of humanity that can't be abstracted away like we do with other economic systems. More directly, maintainers are people and people have feelings. But why is this different? Why shouldn't I feel comfortable saying something like "Kia cars are crap that don't get good gas mileage so you shouldn't buy one"? There's a few reasons why open source is different. For one, it's more direct. The maintainers working on the open source that you consume are typically peers that you interact with directly or through a minimum of hops. They hear what you say and read what you write.
Another difference is that those maintainers are often making personal sacrifices for your benefit, usually with very little in return. Sometimes open source is a job, but most of the time it's personal. That library you just took a dependency on can often be measured in weekends on a laptop instead of playing outdoors, evenings writing code instead of watching a movie with family, sleepless nights wondering about the best way to architecture a new feature. Those are choice the maintainers made so we shouldn't regret or feel bad about them, but we should at least recognize that there's likely a measure of personal sacrifice involved.
To get analytical, open source is an economy. And like any economy there are "currencies". In this case, the currency is often intangible. Open source maintainers do what they do for a variety of reasons. I suspect that while working on open source is a selfless act for many maintainers, it's not entirely so. There are other currencies involved. Some maintainers would like name recognition. Some seek approval or acceptance. Some believe it will have indirect monetary benefits like helping to land a better job. In all of these cases, there's an expectation that the consumers of open source will end up paying that currency in one way or another in exchange for the work provided. The fact that this exchange is both assumed and poorly defined is a problem for a different blog post, but it's there regardless.
The point I'm trying to make is that different "currencies" like approval, name recognition, acceptance, and networking all have a basis in personal interactions...or to put it another way: feelings. We can't separate feelings from open source because feelings are intrinsic in the assumed exchange between maintainers and consumers. To ignore them is to ignore a large part of the implicit contract that's present in open source, whether we like it or not. One thing we can all do, maintainers and consumers alike, to strengthen our open source communities is to recognize the presence and value of feelings...of humanity...in this system, accept it, and integrate that understanding into our interactions.
So to come back to the original discussion about presenting alternatives, does this mean we should never talk about how one tool is better than another? That we should never present comparisons or pros and cons? Absolutely not, that's absurd. The case I'm making is to be softer in our approach. To realize that the words you use and the phrasing of your advice has a real impact and actual consequences on the very software community you're trying to improve. That in the equation of how to discuss open source we have to account for the feelings of maintainers as one of many variables instead of dismissing them as irrelevant. Sometimes...many times...that's just a matter of phrasing or presentation. For example, instead of talking about why a tool is bad, try talking about why it's good first. Instead of explaining why you wouldn't use something, try explaining why you would first. Write comparison tables with both cons and pros. Treat discussions about open source as if you were personally discussing the maintainers themselves, because for them it often is personal. In other words: a little kindness and empathy goes a long way.