I spent last Wednesday hanging out in San Francisco for the first annual maintainerati event. The idea was that there are a lot of open source maintainers out there but events are usually separated by technology areas. Javascript framework maintainers may never meet programming language maintainers even if their problems are similar. The idea with this event was to give open source maintainers a chance to vent and problem solve with others.

The event was structured as an ‘unconference’. I describe it as a slightly more structured hallway track. We started the morning doing ‘dot voting’ on topics people wanted to talk about and then broke into groups to discuss the topics that got the highest vote. I chose to go for the discussion about recruiting newcomers and maintainers. We started with some discussion about what is a contribution and pros and cons of structuring the contribution process and eventually getting committer rights. There’s no hard and fast rule about when people can/should get commit rights and it mostly comes down to relationships; you need to build relationships with existing maintainers and existing maintainers need to build relationships and mentor new committers. This let to quite a bit of discussion about free vs. paid and company vs. non-company contributors. It’s a lot easier to build relationships if you can set up a meeting with a maintainer in your company but that doesn’t work for outside contributors. There’s also the question of trying to recruit volunteers for your sponsored project. Doing work ‘for exposure’ is problematic and exploitative yet open source has this idea of doing work for the inherent joy of open source and learning. Promoting unpaid contributions needs to be done very carefully if it is done at all. We ended up running out of time and I think the discussion could have certainly gone longer.

There was a second session in the afternoon about problematic communities. This one is unfortunately near and dear to my heart. We started out defining what makes a community toxic. A big point was that bad behavior prevents the community from making progress. Many of the discussion points were not just open source but other communities that tend to have overlap. Code of conducts are a necessity to make dealing with toxic behavior possible. There was some discussion about how specific these guidelines should be, and interestingly it was pointed out that having slightly less specific guidelines (but not too much) may help to avoid people trying to purposely hang out at the edge of acceptable. If your larger community is problematic, it can be helpful to work on making a smaller subset welcoming and let that influence the larger group. I appreciated everyone who took the time to contribute in the discussion.

Outside structured conversations, I spent time talking about empathy. Several attendees either were or had been in first line customer support positions. To succeed in this type of work, you need to have (or quickly build) empathy skills to keep customers satisfied. Developers are not well known for having large amounts of empathy skills. I’m guilty of this myself; empathy without emotionally draining myself is something I’m constantly working on. Figuring out how to teach empathy skills to others is a challenge. One of the ideas that came up was the need to be outside your comfort bubble. Travel and moving were a common way people cited to force yourself to have new experiences. Traditional developer mind set also tends to be very black and white (hi guilty here too). Most important was the desire to keep improving this skill and not write it off as unnecessary.

There were plenty of other conversations I’m sure I’ve forgotten about. Notes are available on the github and will be added as people get around to it. I really hope to see this conference happen again. It’s filling a space to have important conversations about non-technical topics that tend to get sidelined elsewhere. I met so many cool people and left with a lot to think about. My biggest thanks to the organizers.