December 1, 2021

Maintainer skills workshops & an early book excerpt

Hi, newsletter subscribers! Thanks for being interested in Changeset Consulting and my open source project management work, including the book I'm writing: advice for maintaining legacy projects.

The most urgent part of this email: If your open source project is part of Open Source Collective, you're eligible to attend my upcoming workshops for free -- sign up now!

Also today, I'll share some of my recent writing and talks -- and share more of my unreleased book-in-progress, on reasons why open source participants end up overcommitting and flaking out. And finally I'll leave you with some jokes. (For hyperlinks, view as HTML or see the archived version on the web at https://buttondown.email/Changeset .)

Free maintainer skills workshops through Open Source Collective

Maintainers of open source projects often need help learning how to address issues such as "how do we recruit and promote project members?", "how do we raise money?"/"what do we spend our money on?", "how do we improve our code review bottleneck?" and "how do I finally have the difficult conversation I've been putting off with that one contributor?"

So, starting in early 2022, I'm running eight videoconference sessions -- a combination of workshops, training, co-working, and discussion -- that you can sign up for right now! OSC will "offer a limited number of places to leaders of projects hosted by Open Source Collective on a series of coaching, training, and workshops designed to work through these issues and to begin building a library of documentation." OSC is sponsoring this so it'll be free of cost to participants.

You're eligible if you are part of an open source project fiscally hosted by Open Source Collective. And in the sign-up form you can mention what challenges you're currently facing, and what problems you're looking to solve, so we can customize the topics we cover and the session structures we use.

If you're eligible and interested, please sign up by December 9th, so we can start scheduling.

I anticipate that these won't be recorded, but I will be writing documents/resources based on the sessions, and OSC will publish those under an open license. And, in case you're interested, but not affiliated with OSC: these workshops are a pilot. Depending on how they work out, I'd be happy to discuss similar courses/sessions with other orgs who want to sponsor them! I'll know more around February (after we've done 2-5 of the sessions), and would be glad to discuss then; reply to let me know if you might want that.

Recent writing

December 21st is the next Volunteer Responsibility Amnesty Day: Every solstice, take inventory of your volunteer responsibilities. Check with yourself, and end the commitments you need to end – maybe by taking a break, or by rotating it on to someone else, or by sunsetting a project.

Some Novel Python Packaging/Distribution/Inspection/Installation Projects

I led an effort to comment, on behalf of Python's packaging folks, on a US government request for comment on Software Bill of Materials standards. The NTIA's "Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM) – Second Edition" is now out.

Some fiscally-hosted open source projects now have the infrastructure support they need to hire US-based employees -- with benefits packages including health insurance and retirement accounts. I wrote about why this is a huge step forward for open source sustanability.

If You Give A Speech You Care About, Post A Transcript.

And I criticized security expert Troy Hunt after he wrote a piece on police and biometric security.

Recent talks

I gave several talks since my last newsletter in May. See details on my talks page, for all of them, including video, slides, notes/transcripts, etc. The two most interesting ones are probably:

1. My Upstream talk, "Sidestepping the PR Bottleneck: Four Non-Dev Ways To Support Your Upstreams" (video, written version). I discussed how a company can aid a project it depends on through testing infrastructure, money, secondary mentorship, and coaching and cheerleading -- putting together some advice that I hadn't seen elsewhere.

2. My PyCon US Maintainers' Summit talk, "Researching the leadership gap for legacy projects" (transcript). This one's still provoking comment. We don't have a pipeline to recruit or grow open source contributors with leadership and management skills. I shared a few hypotheses: one about the tooling we build and use, one about the effects of corporate involvement, one about changes in the problems we're trying to address, and one about values and culture. I'd love to know your thoughts. Which, if any, of these hypotheses ring true to you, and how could someone check whether you're right?

The book: work in progress

I'm working on a book to teach you what I know about getting open source projects unstuck. At the end of 2020 I released an ebook sampler with three chapters from the full, forthcoming book. It's free for anyone who subscribes to this announcements mailing list (as a subscriber, you should have gotten an email with a download link).

I'm also planning trainings for this material, and looking at what I could feasibly teach in an interactive virtual course, and what clients would be willing to pay for. If this is a topic that sparks your interest, please let me know so we can talk!

If you'd like to get more frequent samples of my work in progress, reply to this email and say so. I'm thinking of starting a private list where I send some snippets about once a week.

Here's one work-in-progress excerpt, from the chapter on helping unreliable colleagues. The goal of this chapter: Notice participants who consistently default on obligations, and help them improve -- or learn to work around them. Reminder: the focus of my book is grassroots/volunteer or multi-institution open source projects, where we can't assume that most contributors are being paid by the same org, or at all.

Helping unreliable colleagues -- early draft

There are contributors to your project whom you cannot depend on. When they say they'll do something, they default on that commitment often enough that you -- and other team members -- need to treat any commitment from them as tentative. This blocks forward progress on the project, especially since you and others might shy from the discourtesy of bluntly refusing to rely on their promises, and so the project is left scrambling for backup when a task goes undone -- especially if it's urgent.

Why do people default ("flake") on obligations that we've voluntarily agreed to? This is a problem beyond open source software -- one that I've run into in my personal, volunteer, and professional life within and outside of open source -- but open source dynamics make it especially likely. The structures and incentives of open source projects are a conveyor belt that turn reliable colleagues into overwhelmed overcommitters. So I'll start with the reasons this happens in general, and then move on to what makes it especially likely and prevalent in open source contexts.

Different people have different capacities for executive function. "Executive function" is a term from clinical psychology referring to abilities around planning, decision-making and dealing with unexpected situations, resisting temptations, and similar needs. For instance, someone with less executive function has more problems continuing to work on a difficult code review task when a social media notification pops up, and it's harder for them to return to the code review task if they interrupt it to look at the notification. Even though they've set a goal and want to work toward that goal, it's harder for them to regulate their attention and emotion to avoid looking at the notification, and their smaller working memory makes task-switching slower and more frustrating.

There are many reasons for the variation in people's executive function. One is sheer maturity: generally, children and teenagers get better at this as they become adults, partly because their brains are finishing maturing. Another is disability: people with Attention-Deficit Hyperactivity Disorder, depression, and several other conditions have executive function deficits, and the physical and mental stresses of other disabilities also suppress executive function. Some people have learned skills to improve their executive function, consciously or not, and some have not done so. And you'll see general variation as you would within any human population.

Participants anxious about our failures go silent instead of telling others that we need to default. Some people, in some situations, don't feel safe admitting to failure. Procrastination can be a temporary defense against shame. And a person may feel more safe at work -- more secure and more powerful -- than in a fluid volunteer context, where they aren't sure that they're entitled to the benefit of the doubt. (Or vice versa; a volunteer may feel freer to admit to delays than a paid worker.)

We often make mistakes or aren't clear -- with ourselves or others -- about who's obligated to do what, especially if someone has consistently taken care of a chore. Let's say that your roommate has cleaned the bathroom about once a week for the past year -- but you've never actually talked about that. Is she obligated to do it next week? Will she feel obligated to do it next week? It might even feel rude for you to bring it up, as though you are insulting her by asking whether she intends to keep doing something that she's demonstrated a commitment to. And she might feel it's rude to suggest to you that she is not obligated to do it next week, as though she has, through her actions, made an implicit promise to continue to do this chore.

And this kind of ambiguity is more likely in volunteer settings, especially in fluid working groups that emerge organically. In grassroots open source contexts, people usually don't have explicit job descriptions. People will assign themselves and each other specific tasks, but there's often no explicit assignment of ongoing reactive responsibilities and chores (such as code review, responding to questions on the mailing list or in chat, and doing a first pass on incoming bug reports).

Some additional reasons [that I will probably expand on instead of just leaving them as fragments]:

• Different people have different assumptions about what other people need from us, and how quickly they need it

• Some people treat open source as a hobby with no particular urgency and with low stakes for failure/dropped balls -- which is only a problem if other people with different expectations depend on them

• When there's no organizational structure causing co-regulation (as you would see in a company, with a boss, team, daily stand-ups, etc.) to remind people of backlog and deadlines, folks are more likely to forget or procrastinate

• Enthusiastic creators, especially software developers, can mean to say "that should exist"/"I could do that" and accidentally say "I want to do that" in a moment of excitement, or say yes to new commitments without thinking about our other existing commitments

• The participatory transparency of open source means anyone can pop up to say a discouraging thing, which demoralizes and slows down a worker - especially if it's unfair, harshly worded, or part of a group pile-on

• The participatory transparency of open source opens any participant to work requests from users or other contributors, which can lead to pressure to overcommit -- especially since the more competent a participant gets, the better their reputation, and the more stuff (and the harder the stuff) they get asked to do

• Notification overload and missed messages, magnified in open source contexts by the unlimited number of messaging platforms others can use to contact a participant

[The rest of the chapter discusses examples, cookie-licking and other common dynamics, and tools, skills, and approaches for dealing with the issue. If you want more frequent work-in-progress samples, please reply to let me know!]

Funny

I did 20 minutes of open source-focused stand-up comedy at SeaGL last year! Here's the recording. Enjoy!

Best wishes, as always.

– Sumana Harihareswara, Changeset Consulting