Hi, newsletter subscribers! Thanks for being interested in Changeset Consulting and my open source project management work, including the book I’m working on.
I’ll talk about upcoming talks and book progress, then share some of my recent writing, and tell you about useful new opportunities, tools and resources. (For hyperlinks, view as HTML or see the archived version on the web at https://buttondown.email/Changeset .) This is a longer one than usual, so the most urgent news first, including an event TODAY:
Upcoming talks, May & June
Today! I’ll chat on Tidelift’s Free as in Fridays livestream, May 7th at 4pm EDT/20:00 UTC, in a one-hour live conversation about open source maintainership and my work.
Next week: on Thursday, May 13th, at MenderCon, I’ll be speaking 1pm-1:50pm EDT (17:00 UTC) on “Starting an Open Source ‘Repair Shop’“. Register for free via this special Friends-Of-Sumana link.
Also next week, I’m speaking in a few virtual events within PyCon US. At the PyCon US Maintainers’ Summit, I’m presenting a prerecorded ten-minute talk “Researching the leadership gap for legacy projects” which will go live May 9th, and participating in “Funding open source work” (4-5pm EDT on Wednesday, May 12) and the presenter Q&A (4-5pm EDT on Thursday, May 13). And, as part of the Python Virtual Training Summit May 12-13 (not sure which date yet), I’m presenting a fifteen-minute live talk, “Tools we need to teach project management,” followed by questions and answers. That talk is based on the spec I blogged about: how nice it would be if I could snapshot or composite together a sample legacy FLOSS project, complete with messy old issues, docs, and chat and list archives, and replicate it in self-serve sandbox instances for exercises!
I just got word that, mid-June 2021, I’ll speak for 30 minutes at a conference I can’t announce yet. My talk will be: “Rescue and renew a project: How to get legacy open source projects unstuck”.
And, on June 7th, as part of Tidelift’s Upstream event, I’ll speak for half an hour on “Sidestepping the PR Bottleneck: Four Non-Dev Ways To Support Your Upstreams”.
Details as they emerge on my talks page.
In late March I spoke in the GitHub Office of the CTO Speaker Series on “What Would Open Source Look Like If It Were Healthy?” Transcript and video are now up – I suggest twice-a-year open source Responsibility Amnesty Day (on the solstices), tax reform for foundations and Donor Advised Funds, and maintainer peer-teaching tools, while telling three stories of the way things might be.
Also in March I led two sessions at MozFest 2021: “Apply for Grants To Fund Open
Source Work” and “How To Get A Project Unstuck”. Slides, video, and notes are now up.
The book: categories of stuckness, training, and positioning/scope
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).
As I’ve worked on it, I’ve started categorizing the five major places open source projects get stuck: strategy, team, interfacing (with users/contributors/upstreams etc.), workflow, and money. Does that sound right to you? Here are some examples. For instance, for “workflow”:
- Main question: Are our tools set up to support our work?
- Task to address it: Assess our developer, contributor, and maintainer experience, and upgrade our tools and platforms to reduce toil for everyone.
- How it can become stuck: Contributors started the project on an old platform that doesn’t integrate conversation, patches, and review, and no one’s put in the effort to integrate them or migrate to an integrated platform, so things fall through the cracks. Or: people have started multiple discussion venues, and it’s tiresome to duplicate and interlink engineering discussions among them.
- Related questions: do we run automated tests on every patch? do new issues, patches, and discussions get interlinked so developers and users can easily follow up? are there bottlenecks or duplications in the platforms we use to respond to issues, review code, and discuss the project in general?
Let me know if you’d like to hear more about these categories – or come to one of my talks!
I’m also trying to think about trainings for this material, and what I could feasibly teach in an interactive virtual course, what tooling I’d need (more on that in my “upcoming talks” section below), 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!
As I draft the book, I’m rewriting the chapter on Strengths, Weaknesses, Opportunities, and Threats analysis (which you have in the sampler). Here’s an excerpt:
Scope, Positioning, Product Differentiation, and Awareness
Project teams need a clear, shared, current understanding of what their tool uniquely does, whom it’s for, and why users should use it. The shorthand many engineers use for this is “scope.” A major reason that this problem arises is that the project team doesn’t agree on scope.
Here’s an example. Many of us take Wikipedia for granted now, and the existence of some kind of free online encyclopedia can feel almost inevitable. But, in the paper “Almost Wikipedia,” researcher Benjamin Mako Hill looks at seven competing websites that could have filled the same niche, and which in some cases started earlier and used superior technology. Hill finds that Wikipedia won partly because its scope was clearer. Wikipedia participants had a clear understanding of what the site was trying to be – an encyclopedia – while other projects were more uncertain or sprawling in what knowledge formats and mediums they tried to create.
Your project will be more like Wikipedia, in contrast to its defunct competitors, if your team clearly understands what the project is good at and what you want your tool to be – fundamentally, why it should exist and keep serving a particular niche, instead of letting competitors serve its users. And defining the scope of your project, which means explicitly excluding what your project is not aiming to do or be, helps you prioritize work.
The Wikipedia and Django examples help demonstrate that scope is only part of the puzzle. You also need to understand scope relative to competing tools, which you can think of as your tool’s positioning (what is it that your tool uniquely does?), so you can make product differentiation decisions (why should users use it instead of other tools?). Doing a SWOT analysis will help you not only understand your current scope, but inventory what your competitors do, so you can decide on your positioning and differentiate your product.
Positioning helps you set your goals, and focus on them in the face of “but why don’t you” suggestions and requests. But even a team with clear scope that knows its positioning can get unpleasantly surprised by problems that crop up too slowly to grab your attention, or that no one thinks to file as a bug. Regular awareness checks help. For example, what parts of your current codebase architecture are, in the long run,
slowing your development progress? Or, is there a long-standing user experience issue that’s getting in the way of your users being effective? And then there’s the world outside your project, which affects your project’s future. For instance, if you depend on a particular platform, you need to watch out for end-of-life and relicensing announcements for that platform. Or, if you’re lacking new contributors, you ought to watch out for deadlines for mentorship programs.
Doing a SWOT analysis will help you notice and catalogue these important-but-not-urgent issues. Once you know what they are, your team can get better at prioritizing, and can take charge of your own destiny instead of always being reactive.
Best wishes, as always.
– Sumana Harihareswara, Changeset Consulting