Cogito, Ergo Sumana

picture of Sumana's head

Sumana Harihareswara's journal

(0) : Sidestepping the PR Bottleneck: Four Non-Dev Ways To Support Your Upstreams: Logo for Upstream: A Tidelift Expedition This is the textual version of my June 7 2021 online talk at Upstream Live: "Sidestepping the PR Bottleneck: Four Non-Dev Ways To Support Your Upstreams", 23 minutes. Video is now up.


Hi, I’m Sumana Harihareswara. I founded Changeset Consulting, which provides targeted, short-term project management services to open source projects and the organizations that depend on them.

Just so you know, I won’t be sharing any slides today, so feel free to look away from the screen. Do some situps, look out the window, fold some laundry, or something. And: If you prefer to read rather than listen, the written version of this is now up on my blog.

If you want open source projects you depend on to succeed/thrive, then you want to support them.

This is both philosophical (you want to be a good open source citizen) and pragmatic (and ensure the health of projects you depend on).

It’s useful and important to do that through patches. One of the first times I spoke at an open source conference was at Open Source Bridge 2010: “The Second Step: HOWTO encourage open source work at for-profits”. I spoke on freeing up people in a company to contribute changes back and gave steps to widen your internal bottlenecks.

But now, even if your developers have time to polish up changes and submit them upstream, when you submit a patch, the bottleneck is on the maintainer’s side, because they don’t have a lot of time to do code review. You’ve contributed pull requests but they’re languishing. If a project is stuck, the gift you have given them isn’t helping – it’s like you’ve given them a gift card to a store that’s really hard to get to, so you’re not really helping them substantively.

Lack of time to do code review is common, so it’s likely your PRs aren’t helping as much as you’d thought!

And that’s if your developers even have time to make and polish PRs; maybe your developer resources are slammed, but you have other folks on your staff whose time is more flexible.

So let’s go into how you can develop a deeper toolbox, and how you can help projects you depend on, including expanding their code review bottleneck. Which benefits you and them.

So today I’ll share case studies and discuss 4 ways to help:

  • testing infrastructure – one of the most valuable ways you can sponsor an open source project is through your ops department.
  • money – whether you go with Tidelift or another sponsorship option, direct donation can move the needle.
  • secondary mentorship – you can help new contributors get situated and stay unblocked.
  • coaching and cheerleading – I’ll talk about a time when being an encouraging sidekick made a huge difference.

Testing infrastructure

First off, let’s talk about how your operations department can help developer throughput for a project you depend on – by providing access to infrastructure for use in testing.

As an open source project matures, it comes to a crossroads where maintainers have to ask: what platfoms are we going to support, and how robust will our support be? And their access to testing infrastructure, especially for continuous integration, becomes a key turning point that determines how robust it will be.

Let’s say they want to support the three basic OSes: Windows, Mac, and Linux. But wait, which VERSIONS of those platforms will we support, and which Linux distributions? So now we already have probably at least six or seven things to test.

But what else are we going to support? AMD and Intel chips? People who do and don’t have a particular soft dependency installed? People who run Python 3.5, 3.6, and 3.7?

You can see how these options multiply out, until the project has a test/support matrix with 56 environments.

And, often, projects are limited enough that they can’t rigorously and consistently test their whole matrix – a lot of open source projects can’t afford paid continuous integration services, and they don’t have enough virtual or physical computers to test all the environments they want to support. So maybe 56 environments is too much to handle, and the project ends up with two tiers of support – rigorously tested environments, reflecting the developers’ personal machines, and then everything else. If none of the developers use Windows then Windows is in that “might work” category.

Or the CI services they use limit how many simultaneous jobs they can run, and that slows down the revision and review cycle. Instead of taking 30 seconds or a minute to run CI it might take 10 minutes, or even an hour during peak contribution times like hackathons. This also creates pressure to reduce the number of tests that run on every patch, which means that maintainers have to take more time to review every patch before merging it.

But you can help with this. As a company, you can help your upstream open source projects by providing infrastructure. Give them access so they can use your testing setup for their continuous integration. This is especially useful if your cloud includes the ability to spin up proprietary OSes.

Broader and faster CI helps developer throughput and, in particular, helps the code review cycle go faster.


Next: money.

You’re here at Upstream, so you know that subscribing to a project via Tidelift gives you better assurances of a project’s security, reliability & legal compliance.

But you might be saying: Sumana, how does money specifically help widen the code review bottleneck?

So let’s talk from the point of view of maintainers & what they can do, using lifter income.

First off, with enough income, if a maintainer is spending their time at a job working on something else, sometimes they can quit, and spend time on their open source project.

I’m gonna take a moment now to talk about why that is SOMETIMES. And it has to do with health care and health insurance.

But that’s SOMETIMES. People in a lot of countries, when they quit a job, or go to part-time, they don’t have to worry about how that’ll affect their health insurance. Or, if you’re a tech worker in the US who doesn’t depend on your employer for health insurance, then you have some flexibility, and the more lifter money you get, the more time you can spend on open source. Like if you’re a student getting health insurance through your school, or it’s coming through your spouse or your parents, or you’re a veteran or a senior citizen and you get health insurance through the government.

A lot of tech workers in the US, though, would need to make A LOT of money from lifter income to quit their jobs, buy health insurance on the open market, AND be confident that they could continue to afford that even if the prices go up. So they have less flexibility, and money might not translate so directly into more hours of work.

OK, so, back from that sidebar.

But even so, even if someone can’t quit their day job, so the maintainer still has the same number of hours to spend on their open source project, money can still translate into BETTER work.

A huge example of this is EQUIPMENT. A lot of people volunteering in open source have old or inadequate computers at home, or they don’t have a proper desk, chair, secondary monitor, and stuff like that. A more efficient home office setup – or even JUST a second monitor – can help the quality and speed of someone’s work. Some one-off donations can pay for that, and then over time, a steady lifter income (of a few hundred bucks a month) can help someone move to a bigger place, pay more in rent or mortgage, so they can have a proper home office, with a door that closes, and faster Internet.

Another example is EDUCATION. A lot of open source developers, when they want to learn a new skill, default to looking for what they can read for free online. But someone who’s getting some steady lifter income can pay for books or one-off tutorials to level up, or subscribe to a paid content platform. Like, O’Reilly’s learning platform is $50/month.

And part of how we educate ourselves and each other is with conferences. But most conferences cost money to attend. Sometimes prices for conferences assume all the attendees have their registration costs covered by an employer or a university, and registration costs hundreds of dollars, even over a thousand dollars. Not to mention, if it’s an in-person conference, travel and lodging costs. Lifter income can make the difference, and make going to a conference affordable.

And another example is PAYING INTERNS and FREELANCERS. For example, a maintainer can save up lifting income to pay a freelance writer or designer to improve their website or their documentation, which will save them user support time. Or, for example, a large one-time donation can help break a review and release bottleneck. Last year, donations made it possible for my company to hire a GNU Autoconf expert to get a release out the door, 8 years after the last release. Zack Weinberg took more than six months to review and merge 157 patches, most of which were bugfixes, and make several beta releases, and finally release Autoconf 2.70.

Or a maintainer can save up income to pay an intern, and to teach them to become a co-maintainer. For example, the Outreachy internship program costs a mentoring organization $6500 per intern.

And speaking of interns:

Secondary mentorship

Let’s talk about interns and secondary mentorship. Here’s another way a company can help- you can help a project develop new contributors, and help them get further along the road to becoming co-maintainers.

Think about the engagement funnel for an open source project that wants more contributors and more co-maintainers. An individual contributor starts off not knowing project exists, then becomes interested, and starts contributing. Then, if the project can retain and grow them, they may grow skilled and trustworthy enough to be promoted to become co-maintainer of the project. And the more maintainers you have, the more time is available to do code review.

You can help with a few parts of that funnel. For one thing, if the project isn’t getting new people at the start of the funnel, your marketing department could help with that, with attracting new contributors in the first place. But a lot of the projects you’re working with are actually bottlenecked further along than that – maintainers don’t have enough time to mentor the contributors they have, and grow them to the level where they can promote them.

So I recommend that you help provide SECONDARY mentorship.

When an opensource project is trying to grow new contributors, they often work with internship programs, such as Google Summer of Code or Outreachy. Someone from the project mentors an intern, who’s often new to open source, for three months. But that mentor is usually doing this on top of their other responsibilities. And they’re often pretty new to management, and they’re almost always managing remotely (which is harder than in-person when you’re training someone new), AND sometimes that intern has never had a professional job before and has to learn basic professional skills along the way.

So, that mentor, one of the project maintainers, has a lot of domain knowledge about the project’s codebase, but could probably use an extra pair of hands. This is where you can come in. You can be a secondary mentor.

A secondary mentor does not need to be an expert in or even a contributor to the project codebase. Here’s an example: when I was working on MediaWiki a few years ago, I worked with an Outreachy intern named Frances Hocutt – this was his first programming job, as he was switching careers out of chemistry. Frances’s project was to evaluate and improve the web API client libraries for MediaWiki, in Java, Perl, Python, and Ruby.

One of his mentors was me, but I gathered a co-mentor and two technical advisors: engineers who have different strengths, live in different time zones, and who all promised to respond to questions within two business days. Frances was reading and writing code in four different languages, and was able to get guidance in all of them. The other guys had very different perspectives. Tollef has worked in several open source contexts but had never worked on MediaWiki, so he could approach MediaWiki’s API with learner’s mind and help Frances by modeling how he reasoned about it. Brad had hacked on the API itself and maintained a popular Wikipedia bot that uses it. And Merlijn is a maintainer of an existing client library that lots of Wikimedians use. I brought deep knowledge of our technical community, our social norms, and project management. And I was in charge of the daily “are you blocked?” communication so we could avoid deadlocks.

This worked really well. It made it possible for people to take vacations without Frances getting stuck, and to have more guidance available – from day to day, to help him stay unblocked and always have a next action he could take, but also on bigger topics, like about programming careers and engineering standards, how to judge whether his work was good enough. And after his internship, Frances actually got hired by the Wikimedia Foundation.

Outreachy now highly recommends that every intern has at least two mentors -- and in fact, when I run these mentorship programs, I often MANDATE that every intern has 2 mentors.

See if you can complement a primary mentor by being in a different time zone, and bringing different SKILLS – like project management, technical communication, or testing. You do not have to be a developer to do this. As long as you are reasonably literate in open source process in general, and you actually like helping people learn, you can really improve the odds that an intern will succeed at their internship, want to stick around, and get closer to becoming a project co-maintainer.

Coaching and cheerleading

Finally, let’s talk about coaching and cheerleading – I’ll talk about a time when being an encouraging sidekick made a huge difference.

I did some volunteer work last year, helping rejuvenate pipenv (a command-line tool that some people use to help handle Python packages they make and use).

Pipenv’s maintainers had not released a new version since November 2018, and users were concerned (in many cases switching to competitors). In early March 2020, someone suggested that perhaps the official Python Packaging User Guide should stop recommending it. I saw that suggestion and went into the relevant Internet Relay Chat channel to nudge one of pipenv’s maintainers and to ask: what do you need? What’s blocking you?

Dan knew what was blocking him. He said: “if you’re purely evaluating ‘how do we release the code’, yeah I might just be the main roadblock?” and said he needed “someone to yell at me to stop doing things that are not related to the goal?”

I said: “if you JUST want someone to yell at you to stop doing those unrelated things …. would you actually listen to that person?”

he said: “historically speaking, I’d insist I was doing something important briefly but probably reassess, I do know what needs to happen”

So, over the next three months, I donated about 15 hours of my time. Given my current hourly rates, this constitutes a donation worth a few thousand dollars, which is infinitesimal compared to the value unlocked by expediting a pipenv release. And with those 15 hours of work, I enabled Dan to do fix bugs, do code review, merging several pull requests in, and to make the release – releases mean your patches get not only reviewed but also released so you don’t have to maintain a fork! All in all, with my help, Dan released two betas, then a stable version in May.

Dan needed someone to help him with prioritization, release management, and communications. So I:

  • rewrote the release checklist and kept it updated
  • updated GitHub issues and tweeted to keep users apprised, and to ask them for help testing the beta releases (including suggestions of specific cases to test, and requests for specific expertise when Dan ran into nasty continuous integration bugs)
  • created draft outlines for him to fill in so he could write a status update and the beta release announcement for mailing lists/forums
  • closed duplicate "is pipenv dead?" issues and updated a longer-term issue about maintainer needs, roadmap, etc.
  • made a few documentation pull requests: helped move Pipenv docs from a nonfunctioning domain to a better one, fixed a bunch of obsolete links, and edited Dan's "how to release" docs, and made a pull request to move them into the repo and out of an ephemeral hackpad
  • every few days, checked in with Dan via IRC or email (we also had a few videocalls) to help him stay on task

That was 15 hours in total.

Those 15 hours of coaching and communication and cheerleading enabled Dan to review pull requests, fix bugs, and get that release out. And since then pipenv has made releases on a pretty steady clip.

So: An external perspective can help a lot. You can be that person. Whether you call yourself a sidekick, a project manager, a cheerleader, a coach, or something else, you can be a supportive accountability partner who helps with the bits that maintainers are not great at, or don’t have time for. And you don’t have to know the project codebase to do this, or be a feature-level developer - the only pipenv code I touched was the docs.

If you/your company depends on an open source project and you’re getting annoyed or worried because the release cadence has slowed to a standstill, there’s a strong chance you can turn that around. If someone on your team can spend a few hours complementing the existing maintainers and helping unblock them, that could save you a bundle compared to forking or switching dependencies. Try talking with the maintainers about what they need. And I do mean talking, as in, synchronous conversation via voice or chat, so you can build some trust and get the kind of conversation I had with Dan.


So: testing infrastructure, money, secondary mentorship, and coaching and cheerleading can all move the needle, to increase the health of projects you care about – and decrease the code review backlog so your patches get into the mainline.

I’m Sumana Harihareswara, and I can help you make this happen through my consultancy, Changeset Consulting. And let’s talk more in the chat after this talk – I’d love to hear your stories about what works.

(0) : New History of AIDS Activism: I'm looking forward to reading Let the Record Show: A Political History of ACT UP New York, 1987-1993 by Sarah Schulman for the same reason I love Bury the Chains: Prophets and Rebels in the Fight to Free an Empire's Slaves by Adam Hochschild. This thing worked -- how?! And what can we learn and replicate?

In just six years, ACT UP, New York, a broad and unlikely coalition of activists from all races, genders, sexualities, and backgrounds, changed the world. Armed with rancor, desperation, intelligence, and creativity, it took on the AIDS crisis with an indefatigable, ingenious, and multifaceted attack on the corporations, institutions, governments, and individuals who stood in the way of AIDS treatment for all. They stormed the FDA and NIH in Washington, DC, and started needle exchange programs in New York; they took over Grand Central Terminal and fought to change the legal definition of AIDS to include women; they transformed the American insurance industry, weaponized art and advertising to push their agenda, and battled—and beat—The New York Times, the Catholic Church, and the pharmaceutical industry. Their activism, in its complex and intersectional power, transformed the lives of people with AIDS and the bigoted society that had abandoned them.

Based on more than two hundred interviews with ACT UP members and rich with lessons for today’s activists, Let the Record Show is a revelatory exploration—and long-overdue reassessment—of the coalition’s inner workings, conflicts, achievements, and ultimate fracture. Schulman, one of the most revered queer writers and thinkers of her generation, explores the how and the why, examining, with her characteristic rigor and bite, how a group of desperate outcasts changed America forever, and in the process created a livable future for generations of people across the world.

Here's an excerpt from the start of the book.

Let the Record Show is a 736-page tome, so if someone wants to get together in a book club to read it together over a few months, let me know.

Filed under:

: If You Give A Speech You Care About, Post A Transcript: When I give a keynote address at a conference, I sometimes commission* and post a transcript or a near-transcript afterwards (example). And sometimes I do this for non-keynote speeches (example); this year I decided to get and post a transcript for the recent GitHub OCTO talk I gave, on what it would look like if open source were healthy.

If you give speeches that you're proud of, that you want people to think about and pass along so they can keep influencing people, you should do the same thing. Get transcripts up as soon as possible.

I often don't use slides, which makes presentation easier. When I do, I often include the transcript alongside each slide, the way Dustin Ingram and my spouse Leonard Richardson do.

And here's the sort of thing that enables:

My GitHub OCTO talk: so many people have informally said, upon seeing a link to the transcript of the hourlong talk, "oh thank goodness, a transcript." And one of the followup messages I've received says, "I just read your talk on healthier open source, it was terrific." before sharing a super cool related thing.

And I realized Cory Doctorow might be interested, and I emailed him with a link and a summary. He blogged and tweeted about it soon thereafter, which drew a bunch of readers/viewers. He's a really fast reader so I'm reasonably sure he read the talk rather than listening to it.

My WikiConference USA keynote from 2014, on "Hospitality, Jerks, and What I Learned": a writer for the weekly Wikipedia Signpost news outlet was able to use extensive excerpts in his coverage of my talk, which he loved. This talk is one of the things that Wikimedian colleagues still refer to and remember about me, and the fact that they can easily pass around and quote a transcript is part of why.

My code4lib 2014 keynote, "UX Is A Social Justice Issue": Here I did not post a true transcript, but I had written out my talk as an essay ahead of time so I could immediately post it online. So, several months later, when the editors of code4lib Journal were interested in turning it into a journal article, that was easy to do.

And that journal article has been quoted and cited by scholars! Some researchers cite me while discussing libraries and archives, which makes sense, since code4lib is a conference about the intersection of libraries/archives and tech -- examples include "User Experience Strategies for Every Library. Yes, Even Yours" and "Beyond ADA Compliance: The Library as a Place for All". It looks like Keshab Raj Acharya has cited it in a couple of papers on usability for empowerment and social justice, like here:

The last question in the sampling asks participants to briefly narrate both awkward and good experiences with the biotechnological equipment and devices at their workstation. Because user experience is a social justice and human right issue (Harihareswara, 2015), participants were asked to express their negative and positive experiences with the northern products being used in southern sociocultural and contextual settings.

Further afield, Kyle D. Trott cited it in an article on how to design instructional packets (more info). How neat! I've been able to give people a little useful pebble that they can easily reuse in their scholarly cairns, in ways I seriously did not expect.**

In "Documentation to the People: Building Empathy into Technical Documentation for Digital Archiving", L. Work and H.E. Kelly quote me:

.... Second, in the context of digital work, Harihareswara [14] contends that the larger technology field "systematically undervalues the jobs and roles that require empathy and has deeply gendered associations with hospitality and empathy." In digital archiving, then, it can be argued that we are prone to downplaying both the human element of our own work and the humanity of our users....

I contend!! But actually I do. I put substantial work into these speeches, and in them I contend in the marketplace of ideas. Making my arguments and observations legible, searchable, quotable, skimmable, and accessible*** means my impact is bigger and more durable. How many people have read Allison Parrish's excellent 2016 speech "Programming is Forgetting: Toward a New Hacker Ethic", and how many would have been influenced by it if it had remained video-only?

So: make or commission transcripts, and post them.

And: if there's a talk you love that you want more people to appreciate, maybe transcribe and post an excerpt.

* I pay Keffy R. M. Kehrli to transcribe my talks. I've also worked with Keffy to prepare a talk -- I was having trouble writing a talk, but I could talk about it, so I recorded myself talking about it, Keffy transcribed it, and I used that as the raw material for the talk script.

** And then there's a citation in "Design and Security Analysis of Improved Identity Management Protocol for 5G/IoT Networks", which, ridiculously, cites me (as footnote #8 in the excerpt below) for (as far as I can gather) mentioning PGP.

Yet it focuses on minimizing degradation in MO and maintenance expanse. It is done by constructing trusted-base with cross-certificate between service provider and MO, and implying principles of PGP (Pretty Good Privacy) [8,9] based on PKI (Public Key Infrastructure) [10,11] enables mutual dependence-base communication, and also able [sic] ID management to service providers.

This is nonsensical, and it makes me think less of the journal that accepted it.

*** The accessibility case for transcripts is so obvious that I wanted to focus on this entry on a different, I think underappreciated, argument.

In my opinion, it would be ideal for conferences to live-caption and provide sign language interpretation for all talks, to help Deaf attendees, people who speak English as a second language, people with ADHD, and so on. And the live captions could then at least be a first draft for a human-edited transcript, which, again ideally, would be commissioned and hosted by the conference alongside the video, with the speaker given the opportunity to add hyperlinks to relevant resources.

: Upcoming Talks Plus Stand-up Comedy: In May and June I'll perform some comedy and I'll speak on open source management and investment!

WisCon logo WisCon is going to be online this year, and on Saturday, May 29th, 7pm CDT/8pm EDT, I'll serve again as the comedy host for the Otherwise Award Auction. You can expect jokes and silly live bits about scifi/fantasy, a custom crossword puzzle to solve, and interesting stuff you can bid on! Please register (pay what you wish). I doubt that this will be recorded for later viewing, so if you want to see it, you should register to experience it on the 29th.

Conference logo ÖzgürKon is an international and virtual conference organized by the Free Software Association in Turkey. At ÖzgürKon on Sunday, May 30th, I'll be performing ~25 minutes of stand-up comedy about open source software life. You don't need to register to watch the sessions, but if you want to support the conference, you can buy a ticket. There will be a video recording.

Logo for Upstream: A Tidelift Expedition 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". They've now posted the full schedule and you can register for free. I believe there will be a video recording.

Conference logo, featuring a camel and butterfly wearing protective face masks The Perl and Raku Conference, June 10th 2021, online: "Rescue and renew: how to get legacy open source projects unstuck", a 50-minute talk. This will be my first time speaking at a Perl conference (except that I have spoken at OSCON, which started as a Perl conference). Registration is $10. There will be a video recording.

And I can't tell you the specific virtual conference yet, but in mid-June 2021, online, I'll deliver a 30-minute version of "Rescue and renew a project: How to get legacy open source projects unstuck". I'll mention it on my talks page when I can announce it. [Edited May 20th to say: it can now be told!]

: Willis and Cho: I meant to mention here that some months ago? I reread Connie Willis's Doomsday Book. So, I have a strong memory of having read Doomsday Book previously, back when I lived in Berkeley. In particular -- and my memory gets hazy on this -- I remember reading it in an aisle -- possibly while standing up -- at the late Black Oak Books in north Berkeley, not far from Chez Panisse, not that I had the money to go to Chez Panisse back when I was a student. I also have a strong-yet-fuzzy memory of meeting a guy at Black Oak and having a really nice conversation with him, and then going to dinner with him, and then him dropping me off at or near my apartment, and never learning each other's name or running into each other again, and only much later thinking "hold on, was that a date?" So that goes to show the level of basic human interpersonal domain knowledge I had around this time, which means that any novel I read at or before that era will likely reveal new levels to a less-doltish modern Sumana.

Doomsday Book, right. If there was a past Sumana who thought "how could people act so foolishly during a pandemic?!" then present Sumana is disillusioned and no longer doubts the verisimilitude of such a portrayal. I have been for years and am still a non-fan of the way so many scenes in Willis's stories are driven by missed phone calls and people who just will not listen or learn. It's like an endless fugue on the futility of communication. But this book does the main thing it tries to do, helping you see that the Black Plague interrupted real lives and that even when one cannot stop the big wave of history from sweeping across and drowning people, kindness matters, gestures matter, witnessing matters. It's a grand tragedy and it pulls at the heartstrings.

Just today I finished Zen Cho's latest novel, Black Water Sister. If you love Zen Cho already then you should absolutely go ahead and get this one, and if you've never tried her work, go ahead and start with this one! (Excerpt to start.) A closeted gay woman moves, with her mom and dad, back from the US to Malaysia, and discovers even more secrets to untangle. Suspenseful, funny, observant. I loved how familiar so many touches felt to me -- the rhythms and constraints of long stays with family, trying to find private time for private calls across time zones, Englishes where people say "why did you off the light" instead of "why did you turn off the light", and so much more that evidently translates among different Asian families. And I appreciated how this book got at the experience of coming to one's heritage country as an adult, after (previously) only experiencing it as a child, and starting to grasp how politics, real estate development, old familial dynamics, and chance decisions have shaped the people and places that one took for granted. Cho also -- like Maureen F. McHugh and Philip K. Dick -- has the skill to show us a protagonist making unwise decisions that we know, and sometimes she knows, are suboptimal (Jessamyn! Stop putting it off and reply to those text messages already!!), yet keep us rooting for her anyway.

It's been quite a ride to watch Cho work over the years and develop certain themes in greater and greater depth. She's written short stories (in particular I'm thinking of "The Guest" and "The Perseverance of Angela's Past Life") about contemporary queer women coming to terms with their own sexuality and finding acceptance. And she's written so many contemporary (or set in the future) stories about women coping with death, the dead, the undead, etc. vis-a-vis family and sometimes diaspora -- "The First Witch of Damansara", "Balik Kampung", "Everything Under One Roof", "The House of Aunts", "The Terracotta Bride", "The Four Generations of Chang E", and "First National Forum on the Position of Minorities in Malaysia". In particular Black Water Sister is intriguing to view in comparison to "The First Witch of Damansara" which shows us two granddaughters, one angry and one (the point-of-view character) an emigrant or expat to the West who is attempting to be sensible. Jessamyn in Black Water Sister is in some ways a Westerner and starts off doubting the supernatural things that are happening to her; to blossom she needs to access her own rage.

This is Cho's first contemporary novel (all her past novels and most of her novellas/novelettes have been in historical or fantasy-historical settings), and I find myself thinking about Courtney Milan's Trade Me, her first contemporary novel after a string of historicals, in which she brought to the fore aspects of her own personal experience she hadn't previously infused so directly into her fiction. Further books since then -- including her historicals -- have grown more radical, more attentive to what ground-down people need in order to break free into their own lives. It's fallaciously appealing to make 1-to-1 analogical predictions about authors' trajectories, but I do see Black Water Sister as a kind of culmination of some themes in Cho's work, and I look forward to seeing her build from there into cool new places -- always keeping her protagonists' distinct wryness and sometimes unnerving practicality.

Filed under:

: A Few Other Recent Books Read: Several months ago I read Laurie J. Marks's Elemental Logic fantasy quartet and liked it a lot. Today, Fire Logic, the first book in the series, is on sale for $1.99 on Kobo as an ebook. These books are great! They are about grown adults dealing with the aftermath of war, trying to make peace, falling in love with each other, raising children, and doing the hard work of working together with people whose temperaments seriously rub them the wrong way. You get multiple queer love stories, magic that feels numinous (as opposed to paperwork-y or airplane dashboard-y), and characters you can root for. Marks is in a writing group with Steerswoman author Rosemary Kirstein (I love the Steerswoman books) and I can see how they would appreciate each other's work. People at WisCon recommended these books for ages and I'm glad I've finally read them!

I've finished Nicola Griffith's Hild and it was slow going for me. I loved the court intrigue when I could understand it; in a novel I can have a hard time with keeping track of 20 different people's names! Sometimes Hild thinks really subtly and never comes out and says/thinks "here is the insight I just had" and sometimes I catch on and sometimes I don't. A friend who, she says, loves Hild the way I love Steerswoman is eager to talk with me about Hild and maybe she will explain some stuff to me so I can appreciate it better!

I had never read Richard Adams's book Watership Down and then I read it several weeks ago. What a story! Suspenseful and funny and moving! I didn't think I was going to cry, and then I cried at the last page. And I love what Adams does with General Woundwort's moment when he's balanced on the precipice of being a truly great leader and then falls back into being "no more than a tyrant with the courage and cunning of a pirate."

Naomi Kritzer's Chaos on CatNet. I have enjoyed every story or book I have ever read of Kritzer's, and this is no exception -- suspenseful, funny, satisfying. You know how some clothing manufacturers suit you really well, because the body shapes, the mannequins they're fitting their clothes to are very similar to your body? Evidently the ideal reader in Naomi Kritzer's head is shaped a lot like me, and I'm glad. This book continues the story started in "Cat Pictures, Please" and "Catfishing on CatNet. Those of you who have seen the animated film The Mitchells vs. The Machines might understand why, even though there is a conscious AI in the CatNet stories, Chaos is a more realistic teen-centered cautionary tale about modern tech platforms. I hope some number of teens read Chaos and think twice about installing sketchy apps on their phones and saying "sure, why not" to their permission requests!

Martha Wells's Fugitive Telemetry, the most recent book in her Murderbot series, is another fun story in the series; if you like the Murderbot books then this is another one, and if you haven't tried them yet, don't start with this, start with All Systems Red. I was talking with a friend about how the Murderbot books and Ann Leckie's Imperial Radch books (in particular the trilogy starting with Ancillary Justice) speak to the same modern meritocratic middle-class worry that echan illustrated in the vid "The Organization and the Assets", about brainwashed assassins and the institutions that make and use them. We're telling a particular story to ourselves A LOT, these past few years. I've heard recently (via Annalee Flower Horne) the sentiment that dystopia is when the same things that were already happening to everyone else start happening to privileged people; in the stories echan juxtaposes, and in Wells's and Leckie's work, we see from the point of view of people finding that they have been involuntarily complicit in harming others, just like the rest of us. There was a 2001 Bad Subjects piece by Jonathan Sterne about The West Wing and Star Trek as meritocratic fantasies* that rings true to me, and the trope echan highlights in "The Organization and the Assets" shows us the flip-side idea: You are the best at what you do, no one could question your competence -- and the very system that trained you forces you to use your talent to do massive evil, and you can't help it. The Murderbot books and the Ancillary trilogy start after the weapon-in-human-form is able to say no, and stop serving empire/The Corporation, and start trying to redeem their past atrocities.

I reread Neal Stephenson's Anathem and I still love so many of the ideas, the system of the maths, the articulations of how it can feel to feel like the least bright person in a discussion yet not want to show one's own humiliation, etc. But ugh! The treatment of women! Like when Cord is excited about something and Erasmas describes her as being enthusiastic about it the way other women are interested in shoes?! Why does our protagonist, who grew up in a monastery where all the fraas and suurs wear the same sandals, even have that stereotype about women?! It makes no sense!

I love every nonfiction essay by Joanna Russ that I read, so I'm slowly working to read all of them. To Write Like a Woman ranges around and gave me new ways to think about scifi as a literature, the portrayal of women in lots of kinds of literature, and ends with a letter she wrote that ends, "We are surrounded by nonsense. Love, Joanna" and it's energizing and thought-provoking. Wish I had met her.

* (see also: Hamilton: An American Musical)

Filed under:

: Upcoming Talks - Including A Livechat Today: As I just mentioned in my email newsletter:

  • 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.

  • A celebration of software maintenance: Mendercon, May 13th, 2021. Love legacy code? Find your tribe here. (hand making heavy metal symbol)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.

  • PyCon US 2021 logoAlso 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".

  • Logo for Upstream: A Tidelift ExpeditionAnd, 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.

: What Would Open Source Look Like If It Were Healthy? Video & Transcript: In late March I spoke in the GitHub Office of the CTO Speaker Series (online): "What Would Open Source Look Like If It Were Healthy?"

When I think about open source sustainability, I think about money, sure. But I also think about what configurations of funding would be more likely to keep legacy infrastructure ticking along AND provide R&D opportunities for innovators; what tooling we need; how a stronger ecology of consultancies would change the interactions among volunteers, companies, and other institutions; etc. I'll discuss what I've learned about healthy maintainership, and what a healthier future would look like for the open source industry.

Video and transcript are now below -- including timestamps in case you want to check my tone of voice and body language for a particular passage. I also added hyperlinks for things I was referencing.

GitHub Office of the CTO Speaker Series, March 30, 2021 (session link)

Video recording: on YouTube, Twitch

Speaker: Sumana Harihareswara

Transcription: by Keffy, proofread by Sumana

  1. I can only talk about healthier, not healthy (from healthcare to tax policy)
  2. A story of local innovation
  3. What's different: institutional collaboration, tooling, etc.
  4. A story of a person becoming a co-maintainer of a project
  5. What's different: consortia, tooling, training, etc.
  6. A story of a legacy project "failing"
  7. What's different: how we treat burnout, stakeholder governance tools, etc.
  8. Conclusion: things I didn't cover, and how the future will see us
  9. Questions and answers

Transcript (starts after introduction by host Idan Gazit):

Sumana: [00:06:00] Thank you so much. Thank you. And I'd also like to thank and acknowledge, since I live in New York City, the Matinecock and Maspeth people on whose ancestral land I stand; the African people whose bones were buried unmarked in this city’s foundations; and the involuntary and exploited labor of people from every land which helped to make New York City great.

I can only talk about healthier, not healthy (from healthcare to tax policy)

[00:06:26] I'm here today to talk about open source as an industry and what it would look like if it were healthy. Except I can only talk about healthier, not healthy. And I am going to share some stories, some composite visions of what healthier open source would look like. I am going to do that.

[00:06:46] But first, I'm going to take five or six minutes to ask, well, “what would healthy include?” What would it look like if open source were healthy? Well, literally, the people would be healthier, right? We would have health care for everybody. I live in the United States where we do not have universal health care. Universal health care in the United States, and in a bunch of other countries, would make open source healthier, not just because it would mean that friends of mine would have an easier time getting to see the doctor. But also, at least in the United States, the need for reliable health care and health insurance causes a tremendous number of open source contributors to have to take full time jobs with employers where they're working either 0% or a very small percent of the time on open source, and they're working most of the time on proprietary software. And then they have to do their open source just sort of on nights and weekends and things like that.

And if you look at for instance, Freexian, which is an effort where Debian developers club together and get sponsorship money, so they can each spend a certain number of hours each month consulting on really important parts of Debian software and infrastructure. A lot of those people who can take advantage of that are in Europe, are in places where they can do consulting, they can switch back and forth between full time employment and consulting a lot more easily because healthcare isn't a question.

[00:08:16] If we had universal health care, we would more easily be able to recruit programmers to work on under-produced under-supported infrastructural work like Debian. We'd be able to crowdfund people and we'd be able to free people, as well, to crowdfund short periods of work doing innovative research that might not lead to near term products and startups and things like that.

[00:08:40] Another thing that would have healthier open source, as one of its outcomes, would be high quality, universal, early childhood childcare so that parents can more easily concentrate on their work, if they are consulting, and if they are working outside the home. And if there were centers that provided regular daycare for working parents and also had extra capacity for drop ins and overnights. Then, in case, oop, there are some deadlines, some fire breaks out, that parent could participate and could make sure that they had the time to make the right decisions instead of the quick decision, because somebody else was helping take care of the kids.

[00:09:20] Another thing that would make open source healthier would be a hell of a lot more direct funding for open source infrastructure and for research and development from the nonprofit sector and from rich universities. And I'm going to get into the weeds just a little bit right now on basically tax policy, but it's actually important. Right now, there are lots of rich universities and nonprofit foundations who have trillions of dollars of assets in the United States alone. And some of those do spend a little bit of money funding, sometimes through grants, open source software, open source projects, open source infrastructure. It would make a huge difference if nonprofit foundations and rich universities and donor-advised funds, which is a new kind of construct that exists, actually paid out more of their assets, those trillions of dollars that they have, to fund open source software work.

[00:10:12] And right now, if you look up the 5% payout rule. Basically, most of these foundations, at least the United States, only have to make charitable expenditures that equal or exceed 5% of their endowment each year. And as these endowments go up and up, often by more than 5% per year, that means they're accumulating money instead of spending it out.

[00:10:31] The Nonprofit AF blog suggested, and there's going to be some links in the notes that I hope Idan is putting into the Twitch chat right now. “Donor-advised funds have grown even more rapidly in number and assets and DAFs have NO LEGAL MANDATE to pay out anything each year. So donors take tax breaks immediately when they transfer their wealth to DAFs. But those DAFs are not actually legally required to actually distribute those funds to nonprofits.” So there's a lot of very wealthy people who use DAFs and private foundations for tax advantages. And there are, as I said, some grant programs that fund work in open source from some of these, but it's very competitive, and it doesn't have to be. The money ought to be there.

[00:11:14] So closing that loophole, also funding the IRS to actually enforce its rules, would also free up money for government investment in infrastructure, including health care, climate resilience, education, and open source, all of which would make open source healthier. The IRS enforcement thing – I can get into that at a later time.

[00:11:33] And also, you probably knew once you started hearing me talk that I was going to get to this, a universal basic income or a minimum income would free so many people to work on what they want to work on. And then if institutions, including companies, wanted to pay people extra to make an enterprise thing happen, then they could.

[00:11:55] And you know, as long as I'm being a real visionary and asking for things that feel impossible. Open source, being healthy, a healthy world would be one in which I could retcon, right? Backport some of the inclusion and support – that we ought to offer everyone – into the past. The not so recent and sometimes the recent past, so we aren't missing as many people in open source and in this industry, who ought to be working with us right now.

[00:12:23] So this would be a universe in which, 14 years ago, harassers didn't force user experience expert Kathy Sierra to end her entire career in technology. And she's only briefly returned. This would be a universe in which seven years ago, a now departed co-founder of GitHub didn't act so inappropriately to the first female developer and designer Julie Ann Horvath that he forced her out of the company. And this would also be a universe in which some of my friends are still alive, like Aaron Swartz, and Noirin Plunkett, and Igal Koshevoy. And I'm not going to share the stories of those five people in detail, because I didn't put a content note on this talk. And I don't want to sideswipe you emotionally more than I already have.

[00:13:02] But we have a bunch of work to do to build the infrastructure of inclusion, along with the digital and the financial and the legal and the other social infrastructure that we need to build, to grow the health of open source. That's the long term. And it is our job as residents of the universe to do our bit on those things.

[00:13:24] But in the meantime, let's talk about some things that are a little bit closer. So I'm going to tell you three stories of some different futures. These are maybe things that could happen in the next two to ten years, and they require smaller changes in the world. And after I tell you each of these stories, I'll tell you what we would need to get there. New tools, easier ways to hire certain kinds of services, easier ways to share resources with others, and so on.

A story of local innovation

[00:13:54] So, first, a story of local innovation. Let's say that this is a future in which the Australian Data Science Education Institute has made more of an impact in the world of people who teach science and technology and engineering, because they know that real projects give real motivation. Which means that if you want people to learn how to do things like data science, instead of giving them a toy project, give them real data to work with, something where if they work with it, it's going to make a real difference in their neighborhood or to their group.

[00:14:37] So let's say in your city, a local education agency or nonprofit thinks, well that's a great idea. And they start an initiative to help people do project-based learning to help improve their programming and data science skills. And so they work with local activists to come up with a bunch of data science questions and they, they pop those opportunities open, they publicize what these questions are, especially to local institutions where people are trying to do project-based learning.

[00:15:07] And so there's, you know, a bunch of those – maybe the first idea that comes to mind for you is, let's say, Montessori schools or homeschoolers, right? There are schools and unschools, where the curricula include independent study and project options. People want to learn that way.

[00:15:23] But another group that might be really interested in this might be UnderdogDevs or The Last Mile. And these are groups where formerly incarcerated software engineers, and software engineers who are still imprisoned, work on prisoner reentry, through retraining to work in the software industry. Or maybe the local data science institutes and the local activists could reach out to retraining programs for returning veterans who want to go from the military into industry.

[00:15:54] So this local nonprofit, the education nonprofit, they hire a consultant for some initial project management and open source training, so that the few people, the few Montessori kids, and ex-prisoners doing reentry, and veterans. The few people who said “that project!”, who are working together, can get some help from a part time contractor who helps run the project and who helps them learn how to do open source.

[00:16:25] And there are a bunch of different project ideas. But this project, the one that these particular five people got interested in, had to do with AEDs. These people all live in a particular city and every person has a heart. But sometimes hearts go a little wonky, right? Now, automated external defibrillators are an amazing technology. On average, when a person in the United States calls 911 because someone suffered cardiac arrest, emergency medical responders get to the scene in 8-12 minutes. But for people suffering cardiac arrest, for every minute that defibrillation is delayed, the chance of survival goes down about 7-10%.

[00:17:07] But automated external defibrillators, which are just paddles that anyone can use, and you put them on someone's chest, and if it's a normal heart rhythm, they don't shock. But if it's the kind of heart rhythm that could be shocked back into normal, then it says “okay, I'm gonna do a shock now.” And bystanders, even untrained ones, who use AEDs on victims can save lives.

[00:17:26] And so that's why there are a bunch of these public access defibrillation programs all around the world to make AEDs more accessible in more places. In train stations and police stations and gyms and swimming pools and sometimes even in franchise coffee shops and things like that. But a ton of people do not know where their nearest AED is. I bet you don't know. And there are some neighborhoods within any given city that are probably AED deserts.

[00:17:54] So where are public access AEDs? And what's the distribution of them? And is there a desert? Is there a place where we could put a few in and they would really maximize how many people would be able to get to them in just a few minutes? That's the question that they start asking. So they need to learn some things about geographic information systems and playing with CSVs. And all that stuff.

[00:18:16] This project manager helps them out and is able to spin up a new project quickly with a particular template of issues and labels, and so on, that's appropriate for a local project with a few new learners. They're able to use sort of a cookie cutter to recopy useful configuration settings, issue templates, labels, milestones, who has what privileges and so on. It's very turnkey, they don't have to spend a bunch of time making it themselves.

[00:18:45] And another tool that helps them as they grow this new project is an automated way to say, “hey, we want to capture this decision, this design rationale.” So the project manager used this turnkey tooling to create a minimal, Read the Docs website, some documentation for the project. And in an issue or a pull request if one of the project collaborators @-mentions a bot, then it makes a pull request that adds a markdown export of that discussion into a work in progress draft pull request that, if merged, would go into the Read the Docs section “architectural history.”

[00:19:28] So the manager can lightly edit that and put it in the history of this set of design choices that they made so that, when new folks come along, they can understand why the features and the structure are what they are. And this consultant manager is only part time. But – just in case there's suddenly a flood of new people who are interested, maybe because they get featured on the news or something like that – this part-time manager can keep up using a notification feed, a dashboard of: what are people saying? What tickets are experiencing a big spike of comments in the thread? Is there a fire to be aware of? These are overview tools, not just, “oh, here's a bunch of individual notifications.” These are monitoring tools for monitoring the flow and the workload. And it's unlikely for this project that anything like this will happen, but it gives everyone peace of mind.

[00:20:17] So they learn, right? These five volunteers, these five learners plus their part-time helper, paid for by the educational nonprofit, learn. They do something that's not innovative, right, there might be 50 other projects just like this around the world, but this is theirs. And they made it, and they understand it. And it's important to them, and it helps them get some information that they use to talk with local city council members and agencies, to get some more public access AEDs placed into neighborhoods that don't have as many, and then spread the word that they're available.

[00:20:50] And then once they're done with that, a bunch of them said, “you know what, we should work on next is cross referencing transit and library hours, to see who has a really hard time getting, via transit, to their local library while it's open.” And they realize that they probably don't need the consultant anymore, they know how to run the project. And if they find that they do want a little extra expertise to help them out, they can reach out to an institution that this consultant introduced them to. And it protects freedom in concrete ways. So if there's some company that sues them for breaking some patent that they didn't even know about, this institution will help support and protect and defend them. It also provides platform support to help developers do their work better, and offers financial infrastructure in case they want a place to put donations and a means to spend them. If they need some architectural guidance or code review once in a while, someone can drop by. Or some tips on project management. And in general, this institution works on recruiting new people into the free software movement and retaining them – which has now happened.

What's different: institutional collaboration, tooling, etc.

[00:21:56] So think about what's different in this story, compared to our world.

[00:22:06] One thing that jumps out to me (and might not to you) is, I think: this story has better collaboration on technology projects, creating funding, handing them off, providing infrastructure and so on, among different kinds of institutions, than we have in our world. Including nonprofits, a for-profit, like this consultant, different kinds of educational institutions, and so on. There's a lot more fluid collaboration, including among the different nonprofits, some of which happen on perhaps more of an educational rhythm, like the school calendar, and some of which don't.

[00:22:47] Another is, this is not, “oh, let's fund a hackathon.” “Oh, let's fund a weekend hack day with a contest of some kind.” This is not about that right? Funding instead has gone into infrastructure, so that over the course of possibly months, this project can succeed. So that's not just the paying for the manager, but also paying possibly for the forge, because this forge has features that are appropriate to this group, including possibly people who are under 13.

[00:23:22] This is also an example of how an ecology of consultancies can change the interactions among volunteers and companies and other institutions, because in this universe, it's really easy to hire an open source project manager, either a freelancer, or one from kind of a temp agency, who can help people start to run a project and help them learn what they need to learn about open source engineering and contribution.

[00:23:46] Hi, my name is Sumana, and I run Changeset Consulting and you can hire me for this sort of thing. But it would be great if there were a lot more institutions like mine. And that institution that I mentioned, at the end, there are a few that do a bunch of those different things. But I don't think there is one institution that does all of those things, especially just from little informal groups that might not have any particular legal entity.

[00:24:11] Finally, let's talk about the tooling that I mentioned, right, which goes to what Idan mentioned in the introduction. So there's the ability to use this cookie cutter approach to create, let's say, a repository or project, whatever you might call it, whose digital workflow and scaffolding is optimized to support one particular purpose. There's the help for a part-time maintainer, by giving them not just notifications of individual events, but monitoring – right? They’re like the system administrator, but not of a digital system but of a social system. Monitoring for the spikes and fires to give them an overview.

[00:24:50] And then this bit of tooling really is close to my heart: the ease of capturing the design rationale. If you ever read the excellent, excellent book Making Software: What Really Works and Why We Believe It, which is a collection of research about what works in software engineering, you'll see the number one thing that a new contributor to a project needs, and has a really hard time getting is the design rationale behind bits of decisions. Why did they do it this way? And why did they do it at all? Right? They're looking through code. Was it a deadline? Was it to fix a bug or work around a bug? Was somebody trying out a new framework for fun or what? Because that totally happens. Tools to capture this as you go, can surface it at a level that's higher and easier to read than commit logs and comments when you're trying to get the architectural history of the project. And this also then helps you explain to other people who might especially be contributing in ways that are not code, including stakeholders from governments.

A story of a person becoming a co-maintainer of a project

[00:26:02] So that's the first story. Next, I want to tell you a story about a person who becomes a user and then a contributor, and then a co-maintainer of a project. Which happens now, but probably less like this than in this story.

[00:26:21] Paula started at the DMV as a data entry clerk. And she thought maybe that was all that she was going to end up doing. And well, I guess that's okay. But in this universe, municipalities and states are forming consortia. Different states will sometimes join a consortium to club together and fund an open source replacement for not-that-great software that a vendor has sold to them in the past, proprietary software. And different Departments of Motor Vehicles in different United States mostly do the same thing. So they realized, well, why don't we get together and make some DMV software. So there's a consortium of eight states that are pooling their money to make this open source replacement for their current proprietary vendor systems. And the codename for this new software project is Motorhead, for now. They're thinking of changing it.

[00:27:23] And Paula, through her unionized benefits, gets, if she wants it, training in this new piece of software and a chance to give feedback, right? She's going to be one of the users of this piece of software. So she gets asked, “hey, do you want to be one of the people who tries it out and gives feedback.” And so she tries it out. There are things she likes, there are things that she thinks could be improved. And through the consortium, and the DMV, and also her union, she comes to understand that one of the things that could happen is that she could actually help fix some of the things that she doesn't like.

[00:28:01] So through, again, partly in-house, partly through the consortium, and partly through the professional development benefits of her job, she starts training up on how to contribute to open source software. There's a textbook, and there's training material that helps her learn some basic engineering skills. And she really loves being able to pop the hood and fix stuff that was annoying her. Also, she doesn't have to fight about inclusive assumptions being made from the start both about the software's administrators and users and about the kind of data that they're holding about individual people whose data passes through the system. From the very start, it is assumed that well, sometimes people change their names, including people who administer the system. Some people identify outside the gender binary. Sometimes individuals die. And it's important to make room for that in the various data structures and workflows, including, again, people who administer the system. Sometimes people get harassed and so it's important, when it comes to information that's mostly public, to be able to move things sometimes from private to public or vice versa, and be respectful of people's needs around that and to allow users to block harassers from contacting them.

[00:29:21] All of these are fights that Paula doesn't even have to have – that's already built into the engineering assumptions. So Paula is able to switch into a role where she's doing a lot less data entry and a lot more IT and contribution as one of the contributions that this particular DMV makes to the consortium work, and she learns more about what it's like to work together in a project like this. And she finds out that the DMV offers, as a professional development benefit, a course offered by training firm, where she could learn to be one of the leaders, one of the maintainers of an open source project.

[00:30:00] So she thinks that'd be pretty cool. So she goes in on this course. And there's a textbook. And there's also a playground basically, a sort of sandbox, where she can learn about issue management and release management, etc. And there's a trainer who takes her through exercises and assesses how she does on those things and gives her feedback about how she does. So she learns in a safe environment: how to take inventory of a project, clean out a bug tracker, clean out the old unreproducible bugs, look at a bunch of feature requests and prioritize them, talk with users and find out more about what they need, deprecate an API, run a release, including navigating feature freeze and code freeze, run a meeting, make a budget and so on.

[00:30:50] And then when the people who are working on this project say, “oh great, you're done with that course. Come on, why don't we make you an apprentice maintainer.” She's able to work and participate in a way that makes her feel safe. Because she's backstopped, right? There's a safety net. And that comes with the tooling.

[00:31:12] Certainly, it's the support. It’s the emotional support from other people and their willingness to help but also the tools on that forge, oh, they help her so much, right? If she wants to write a reply to something, but she isn't super sure about it, built into the platform, is a way for her to share that note with her colleague and say, “hey, could you check this and maybe edit it.” And then as soon as that person approves it, or edits and approves, it lands into the repository with her name on it, right, it's just a way of getting some editing and polishing help and approval from her colleague. So she can gate her reviews, replies and emails on someone else's approval. Or she can shadow them and watch them make a decision about how to reply to something. Or they can… somebody can help her by ghost writing with her.

[00:32:01] Similarly, one of the ways that you save time and sort of save your emotional energy, when you're replying to patches and pull requests or issues, or what have you, is with saved replies, saved responses. And in this particular forge, it's very easy to share those with your fellow maintainers so that everybody can benefit from the hard-won wisdom of how do you write this quite the right way. And it'll have all the important links in it.

[00:32:29] And as she grows, as she grows more confident, and doesn't need that scaffolding as much anymore, and she's monitoring the community (well, I don't like to use the word community most of the time for these projects, because it's not a group of people who know each other and actually take care of each other). But as she's monitoring her constituencies, right, the users and stakeholders and so on, there's a dashboard that helps her notice things that aren't happening that should. It's not just notifications of things that are happening. It's also, for instance, “hey, that seemed like it was an important conversation and it stopped and it's gone stale and quiet,” so that she can take a look and see: is it that it should be marked resolved? Or do we need to push and rephrase this so that we can get the conversation going again?

[00:33:15] Or. let's say there's a person who was contributing and participating regularly, and has now gone quiet. She can check in on what's happening with that person. Along the way, as she's learning to use and contribute to and then co-maintain Motorhead, she goes to a conference and then the next year she sprints at it and works with people during a hack week. And then the next year she speaks, she gives a talk at that conference. This is a conference that's hosted by a free and open source software organization. This is actually the organization that lobbied for the procurement rule change in state government that allowed this consortium to happen. And this org has a really wide purview. So there's a lot of cross pollination at this conference. People are working on the technology side, but they're also working on all the other things that takes to liberate people with technology.

[00:34:10] There's talks and workshops about fundraising and money management and effective public speaking and writing. People are planning together about how we liberate users by giving them high quality free software platforms and apps and services. Some people are sharing compelling new visions and articulations for the free software movement as circumstances change, right? New metaphors, new fronts to fight in. There are summits by people who are lobbying to change more procurement rules, and also educational curricula standards around the US and around the world.

[00:34:44] And there are efforts. There are many sort of hack weeks and sprints and workshops and hallway conversations about growing the number and types of volunteers who contribute to crucial free software projects and making strategic choices to improve free software infrastructure and recruiting and mentoring successful leaders like her.

[00:35:03] You get the idea. Oh, and no one harasses her at this conference – which she does not notice. Because it's easy not to notice the absence of a thing like that.

[00:35:14] So Paula helps get this new system production-ready, and it replaces the old proprietary system. And she makes and implements a really big decision after that, which is that a project can have – rather, an instance of Motorhead can handle beginning to trust another instance from another state and implement business logic. So we can handle both sides of a person moving from one state to another. So that Motorhead can coordinate automatic re-registration of a person. New license, new voter registration and so on. And Paula is now a trusted expert within the consortium. And people ask whether she'll come join a worker co-op that offers migration services for the various US states that are deciding to switch to Motorhead, and that would be an interesting change. But she really doesn't like to travel. So she's thinking about it.

What's different: consortia, tooling, training, etc.

[00:36:08] So what's different in this universe?

[00:36:15] Again because I think so much about institutions, the consortia, right? More than that, having all these procurement rule changes for public government funded agencies, so that people from different municipalities and states and so on can get together and create a consortium. That's not happening nearly enough right now. My spouse, Leonard Richardson, works on an effort, called Library Simplified, where public libraries in lots of places can join together to make lending ebooks easier and use open source and open standards to save money and control their own destiny.

[00:36:50] Also, the worker co-ops, again, some of these exist, but they're not nearly as common as they could be.

[00:36:59] Another thing that is not as much the case as I would like it to be is having those inclusive assumptions from the start. Now, in this case, because this is software that has to do with personal data at the Department of Motor Vehicles, okay, maybe it's more likely that a lot of those inclusive assumptions would be baked in, but also the next WordPress, the next git, the next Tor. Ideally, in healthy open source, they also don't have these perceptual gaps about who uses it, and what their needs are likely to be.

[00:37:32] Consultants and training companies exist in this universe that provide training on how to be a contributor, and how to be a maintainer. There is not that much of that right now. And it's a big gap that makes it harder for us to grow the leadership that we need for successors in free and open source software leadership. So I've actually written a bit of a spec, which I think there's a link to, I hope, on Twitch now, for the software we will need to have real interactive sandbox training to teach maintainership skills, without someone having to learn everything from a real life project. And I am working on basically the textbook on how to come into an existing free software project and become a co-maintainer and help get the project unstuck if it needs to. And you can actually download a sample of that right now for free.

[00:38:19] Some tooling. This, again, there's tooling to help maintain or share the burden; there is tooling to help people teach each other or cross check each other's work. And tooling to notice the dog that didn't bark. Again, this is almost the converse of what I said in the previous story about notifications. Right?

[00:38:36] What a great conference that sounds like. Now, I haven't been to an in-person conference for more than a year. So maybe I've just made up a Disneyland in my head. Of, oh, this is the conference that I want to go to. But this is inheriting from the legacy of OSBridge and OSFeels and OSCON. And also something that you can get sometimes with Allied Media Conference and SeaGL and LibrePlanet. I just want like a big combination of all these things.

[00:39:02] And the institution that hosts that, I think it doesn't exist. I think there's different institutions that do a lot of those, including the Wikimedia Foundation, for instance, but yeah, we need more of it. I don't know whether it should be in one house or a bunch of different ones. But at least right now, for instance, the Free Software Foundation is not that.

A story of a legacy project "failing"

[00:39:23] And the last story that I'll share with you is a story of a legacy project that “fails,” except, I don't know if it is actually a failure. Maybe it's just an ending.

[00:39:40] So Sean is the maintainer of a Drupal/Instagram integration. It helps you reuse photos from Instagram into Drupal. And Sean maintains a lot of stuff, right? And it's made somewhat easier by the fact that there are user groups, user councils who can help him a bit with some money. Also some help with things that don't require him, right? User-to-user help in the forums and cleaning up the bug tracker and things like that. But even so it takes work as these APIs change and things like that. So Sean has taken on more and more, and he realizes one day that he's feeling a little more burned out, feeling kind of exhausted. And a friend of his, instead of sending him some list of 10 productivity hacks, does, perhaps, a kinder thing and actually takes some time to sit down with him and do a responsibility audit. Just a big list of “what are all the open source things that you're responsible for right now.” And there's a lot on that list. And Sean realizes that this Instagram/Drupal integration is just not where he wants to be putting his time, he needs to concentrate on fewer things that have higher priority to him.

[00:40:58] And so at the next solstice, he uses the open source tradition that has arisen that twice a year at the solstices, there's a Responsibility Amnesty Day, which is the day when you can just say, “hey, I can't keep doing this anymore so I'm putting it down.” And everyone understands. So he does that at the next solstice. And his user council basically says, “well, crap, okay.” People recognize that every open source project has a lifecycle that includes an end. And that that is natural that at some point, every project is going to come to an end. There's a fairly easy governance and decision mechanism that this user stakeholder council can use to confer and say, “well, what are we going to do about this?” And if they come to no decision, then the null/default that’s gonna happen is that after they fail to come to a decision during the election, and discussion and deliberation period, then, well, the project is going to go read-only. And that's just how it is.

[00:42:03] So they assess their ability and collective desire to maintain it themselves, or hire or support a new maintainer. And in this case, they don't want to do that. Not enough people want to contribute enough, in order to make that happen, because enough of them think, “well, in the next five years or so, I'll be moving off either Drupal, or Instagram.” But they do want to use their collective power to make an easier migration path for themselves. And so they hire, at a one-time and smaller cost, an end-of-life consultant. This person looks at their project, looks for competitors, updated descendants and replacements and forks, figures out maybe what it would take for possibly merging with another project or how hard it's going to be to migrate people on to the various alternative services, and rustles up some consultancies to get prices so that now the users know what their options are for buying paid migration services. If that's what they want to do.

[00:43:08] And then, after all that is done. After a little bit of time for everybody to kind of say their goodbyes on this one project. It's moved to archive mode, the code is moved to the Software Heritage data set and moved off of the active area of the platform so people don't stumble on it and think, “oh, I should use this. It's still maintained.” No, it's clear that it's not. Everybody gets to concentrate on projects with a future. And Sean gets to lay down one of his burdens, so that he can work on the things that he wants to.

What's different: how we treat burnout, stakeholder governance tools, etc.

[00:43:40] So what's different about this? I think one of the differences between this healthier open source industry and the one we're in is a general understanding that burnout is really serious and needs to be addressed through reduction of burdens, and not just “be more productive” stuff.

[00:43:57] I’m really curious what people think of this Amnesty Day idea! In case it speaks to you, the solstices in 2021, at least in my area, are June 21st and December 21st. Take that as you will.

[00:44:13] Okay. So my spouse Leonard heard this idea and said, “you know, this is the kind of thing that might not work in real life, because then we're squeezing together a bunch of sudden end-of-life, ‘this is no longer maintained’ announcements onto just two days a year. And it might be hard for the users.” And I said, “but maybe this would be good, because then people would know to look out for those days, right, and say, ‘oh, I gotta check the day after’.” You tell me what you think.

[00:44:38] I think it would be great if there were better tooling for democratic governance, or at least, you know, better shared resource, stakeholder decision making built into the platforms that we use. And this is like the stuff that Shauna Gordon-McKeon is working on with Glizzan and Concord, which I hope there'll be some links shared in the Twitch. Also Elinor Ostrom’s work, Luis Villa’s work. This is all stuff that people have thought a lot about and written a lot about. But my point is that if this user council can exist and can make these kinds of deliberative decisions quickly and easily because it's built into the platform, that also makes reuse more possible, because then user stakeholders don't think “I'm going to go reinvent the wheel, because at least I know, I'll have control over that I'll have a voice in that.” No, if people know that they can have a voice in the software that they use, and that they can materially support it, then they know that they can actually reuse and stick with it, right?

[00:45:42] Now, one note about this tooling, this is possibly a kind of forge that's fundamentally different from the kind of forge, the kind of platform that another kind of project might need. An open source project that's made by a company that’s just throwing the code over the wall, they don't need this governance stuff, right? Because they're the governance. You look at the Open Tech Strategies’ archetypes that they did with Mozilla. You think about how a business-to-business project is different from a mass market project, different from a specialty library, which is different from a trusted vendor. Nadia Eghbal -- and I have some thoughts about her book in case you want to talk about it. But she suggests these categories of “toy, club, federation, stadium,” based on the ratios of users and contributors and user growth and contributor growth, so isn't it likely that they need really different things? And perhaps monopolies and monocultures in our platforms wouldn't help with this, right? Because they're kind of brittle, and they get to be one size fits none.

[00:46:44] Another thing that happens in this story is the existence of this end of life consultant. As hard as it is to find consultants who can help you start a project, it's even harder to find consultants who will help you end one in a graceful way. If you look at what the Digital Impact Alliance has funded in the past, in its strategic grants, they include product consolidation, and managing upstream dependencies and downstream forks. It’s a lot easier to find grants and funding and consultants to help you start a new project, as hard as that is, than to help find that kind of support, to end a project that needs to stop gracefully. And it would be healthier for everyone if there were funded pathways and more hirable experts to help you end stuff and migrate people on to the next path.

[00:47:29] And finally, I just want to bring your attention to the Software Heritage approach, not just the code, but also conversations getting archived.

Conclusion: things I didn't cover, and how the future will see us

[00:47:38] So, in conclusion, there's so much I haven't even touched on in this talk, right? I haven't even discussed in detail the problems of having a single proprietary point of failure for so much of the whole open source ecology, the importance of ease of import and export of all of the artifacts associated with the project, including conversations where we actually make our engineering decisions. The kind of resilience that comes from having cross-dependent projects, hosted on different forges. I haven't talked about copyleft and licenses. And these new, not really open source, licenses that some companies are adopting. Like, venture capital-funded platforms that get to outspend their rivals for years to gain market share and how that impacts these dynamics.

[00:48:21] I really have not talked enough about the international nature of open source software. And this goes all the way from the problem of conferences in the United States and Europe that are not accessible to people from many countries, such as Nigeria, because they can’t really get visas, all the way to our collective failure to use free software and free culture to help liberate people in Myanmar, China, and elsewhere.

[00:48:43] But I do note, there's a lot to do to reduce the exhaustion and burnout and exploitation, and the unreliability and underproduction of essential infrastructure and the waste of the open source software industry. And I hope I really sketched out some ways that these things could be improved and mitigated.

[00:49:05] And if we actually do make this field healthier, then people a generation from now will look back and say, “wow, you got so much wrong.”

[00:49:15] Right? They all look at us the way we look at people from, you know, ago. As a gag, people who have been doing open stuff for decades will send their less senior friends links to things that happened, right?, to leftpad and Heartbleed and the Timeline of Incidents and the firings of people unionizing at npm and so much more, and anticipate their, “They did WHAT?” replies. The next generation of open source participants will look back at people like me, and they will keenly observe what we missed what we got wrong. This talk will be a laughingstock, right? Look at how late we were to form consortia and co-ops to support projects we cared about. Look at how slow we were to take advantage of these market opportunities for different kinds of training and consulting businesses. Look at where we were too complicit in the intersecting oppressions endemic to our society and too accepting of the ridiculously skewed tax policy of the United States, ridiculously skewed economics of the industry, look at where we were just generally too much “of our time.” And that will mean that we've actually done reasonably well.

[00:50:27] So thank you for listening. Thank you to Mike Pirnat and Nick Murphy for listening to some rehearsals and to Leonard Richardson, Veit Heller, Soo Somerset, Lindsey Kuper, Julie Ann Horvath, and Marie Clemessy for some discussions over the course of the past year or so that helped me with these ideas.

[00:50:45] Thank you for listening. And now I would welcome your questions. So, Idan?

Questions and answers

Idan Gazit (Host): [00:50:51] Thank you, Sumana. That was fantastic and I would like to remind everybody that we have, I will put it on the screen. There we go. We have the OCTO Discussion. I've already got a couple of questions going on in there.

Sumana: [00:51:06] Okay.

Idan: [00:51:09] I wanted to ask a little bit about sort of, you talked about these overview or monitoring tools. I've struggled with my GitHub notifications for years. And everybody loves to hate on GitHub notifications, in particular, in a Goldilocks kind of way, you know, there are too many [crosstalk], not the right abstraction. You’re talking to hear about notifications that are in a different scale, cutting across tooling, and helping me get a sense for what the community wants. And I have sort of two related questions there. It sounds first, like this is something one step removed from GitHub, because it looks at other sources of information, not just the commit stream, but also other kinds of interactions. Not just conversations and pull requests. So the first question I have is, what are the those other sources of information? And I think, maybe related, on the way to that you highlighted, what's active right now. I'd love to talk a little bit more about that lens. Why is “what's active” so important? Because this implies this sort of one-way signal, like “I'm the leader, I must watch where my people are going so that I may lead them.” What about the opposite direction? How do we also give a return channel for maintainers to contributors as part of this? That it's not just about “okay, what's going on?” But also, “how do I help shape this?” And how do we give these maintainers those tools? I know, that's a whole big solution space, so we can break that down. But I'm curious what you think about those.

Sumana: [00:52:44] Sure. So I think that the first thing that you just said, about what are these other sources of data, that notifications, that we might want to look at for a dashboard like this? I think a really good source for thinking about this is probably the CHAOSS Project. That's C-H-A-O-S-S, for people who don't know. This is a working group that is trying to really think in a very systematic way about metrics in open source software. And they are assisted by a consultancy called Bitergia that have thought a lot about: what are all the different sources of information that you might want to grab, archive, analyze, reproduce, and so on from an open source software project. So, there's stuff that happens on a platform like GitHub, or on a, you know, GitLab, Launchpad, Sourcehut, and so on. And then there's conversation that happens because we exist on the internet. And so these are going to be, in some cases, social media notifications. Sometimes these will be individual personal email, or Discord, or Slack conversations. I think that places where you know people are talking about the project could widely vary to Reddit, email, individual, as I mentioned, Discords, and certainly Stack Overflow, for instance.

[00:54:16] So a thing that I think is probably a bit of a holy grail, but I don't know whether it actually exists, is something that helps me see all that. I looked recently at the HEY, H-E-Y email service, and the various choices it makes about what it's doing to try to surface to you the conversations that you need to know about and the messages you need to know about, so that your inbox isn't just the world-writable to do list, right.

[00:54:44] And I think I struggled a lot emotionally with thinking about it because I've been using email the way that most people have for a great majority of my life, but rethinking the user control over what they see. And hooking in maybe things like Zapier to look at these other data sources. It might be kind of interesting to try and create that “okay, where is it?”

[00:55:08] And then when you talk about this whole active thing, I think the, “tell me about something that's gotten really active” really does feel like a capacity to fight fires, to me. It feels like a way to know, in a way that isn't just “oh, I've gotten a bunch of individual notifications about this thing,” but has a higher abstraction level. The question of: is this something that I need to step in on because tempers have gotten heated? Or because people are making a decision faster than they should? That is, the intuition that I have about that on sort of first thought about why do I think that’s the case, I also think that it usually shouldn't just be something that one maintainer has to monitor. This might also make sense as a kind of a bat signal for people who care about a project who can include curators and power users and stuff like that.

Idan: [00:56:15] So, I mean, sort of built into that, though, is, I think, a problem that we're grappling with right now, which is that X doesn't scale, Sumana doesn't scale, there's only there's only one. And for many contributors, or many maintainers, if I were to walk up to them, I’m assuming—I'm presuming, but if I were to walk up to them and be like, “here's some more tooling for you to monitor,” they’d be like, “no, go away. Because I don't have the bandwidth to get into it.”

[00:56:50] I think this maybe ties into—

Sumana: [00:56:52] And you’ll mention, you'll notice, by the way, Idan, that both of the maintainers that I talked about when I talked about this kind of tooling were both paid.

Idan: [00:57:02] Well…

Sumana: [00:57:01] And that's a huge difference as well, is that some of the maintainers who don't have time and are being burned out here, they are not being compensated for their labor. And so that’s tough.

Idan: [00:57:13] Well, it's difficult to work multiple jobs. This is not something new or specific to software. So absolutely. And I think it maybe ties in a little bit to the story you described around this new contributor persona, Paula, and apprenticeship.

Sumana: [00:57:34] Yeah.

Idan: [00:57:37] Because I think one of the problems that people have when contributing to open source software, actually, the other side of it, the maintainers, is that contributors come through, especially on popular projects, and they're like, “oh, I want to contribute.” But to the maintainer, it's very difficult to sort out who's just passing through. They're interested and maybe they lose interest as soon as they encounter the actual difficulty and need to chew on hard things. And who's actually going to be there for the long run. And without passing judgment, about how people contribute, maintainers are people too, and the time that they spend cultivating new contributors, it's opportunity cost, they can't be in two conversations at once. They can't be reviewing PRs while they're holding somebody's hand.

[00:58:25] So if you're talking about wave a magic wand, you get to edit reality and open source grows up in a slightly different fashion. What’s different in that timeline? Is this like a world in which this apprenticeship starts as onboarding classes for open source? Even if we sort of magic away the issue of compensation, where people are compensated for their time, if you want to make a living doing open source, you can do so. And maybe you're not going to be you know, capital W Wealthy, but you know, you'll be able to earn a living wage doing so. Is that sort of the entry point? I mean, I don't know that much about how apprenticeship really worked back in the day. But what does this alternate reality look like where there's a scalable model for onboarding people into open source that doesn't end up in the trap of maintainers only have 24 hours in the day and they need to spend a bunch of them working and a bunch of them sleeping and a bunch of them on personal whatever? Where do they also have time to handhold a million people?

Sumana: [00:59:34] I think part of what you would see is, so when you think about carpentry or athletics or music, generally there is a wide bunch of… I think of open source, if two different people say, oh, I'm learning the guitar, or I play the guitar, you don't really know the context in which they play the guitar. Are they playing it for themselves to amuse themselves? Are they in a band that actually tours? Are they a teacher? Are they writing a song for a specific company project or something like that? So in open source as well, the projects that get a tremendous number of views and stuff like that. We have right now, an assumption that every single one has the same interface – but you don't have the same interface to beginning violin and watching Yo-Yo Ma, right. You don't have the same interface to beginning to do a little woodworking on your own in your garage, versus, watching a master wood sculptor or learning to take those classes or something like that, right? And I think that in this universe, where I get to wave my magic wand, the people who have different motivations for participating in different projects have appropriate substitutes available. This is kind of just in general, right? You see libraries in the United States, become – like, the branch libraries, the physical locations, they become these substitutes, where that's just where a tremendous number of social services happen. So this is where people end up having ad hoc daycare, or schools as well. That’s where food gets administered to hungry people. And that's where music classes happen. And that's where counseling happens, and so on, and so on. And so when we had to shut down the physical locations of various schools and libraries, during the pandemic, it was terrible, because we had monolithed these things!

[01:01:59] And so, somewhat similarly, if all these different needs that different people have for learning, for ambition, for entertainment, and so on, if there aren't alternate substitute approaches for them to take, then they're going to end up going to open source projects. I sometimes talk about the ambition taboo in the tech industry, how in general, since we don't have good ways of assessing people's talent in a way that is fungible and transferable from one place to another. We don't have something like medicine where you have the board exams, right? Instead, all we have is sort of “have you ever been the maintainer of an open source project? Have you gotten a contribution into an open source project? Have you given a talk at a major conference? Have you written a book? Have you gotten hired by a company that we think is prestigious?” and to a somewhat lesser extent, “have you gotten a CS degree from one of these, like, five universities?” but even that doesn't matter as much.

[01:02:59] And so if we had… if I could wave a magic wand, there'd be a lot more work being done on how we can do good assessment, and how we have other places for people who want to aim for ambition, for mastery and validation of that mastery, that doesn't then have to possibly interfere with people who are trying to do work for other motivations. So: an example.

[01:03:27] When I talk about music, or athletics, or woodworking, or something like that, you know, people who engage in lots of different ways, end up being on different platforms that act in different ways. And the interfaces for “hey, do you want to join in?”, are shaped in different ways? I do think that there's a place for, for instance, if you're a really popular open source project, and then people keep knocking on your door, you know, what you should have? You should have subsidized assistants who help, right? Like, why should… if you're in it as a maintainer because you primarily want to be writing features and fixing bugs and reviewing code and stuff like that, then wouldn't it be great if you could have assistants like me. I am someone who can be hired to do stuff like this, to help with the stuff that is not really in your purview.

[01:04:20] So that kind of work… and that is something that companies can do to hire and to help out the projects that they want to help, who are feeling overwhelmed in some way. So we don't have to close it off and make it all one-way mirror or something like that. We can, instead, adjust not just expectations through certain kinds of platform friction and certain kinds of expectation setting in text and things like that. We can also subsidize all of the helpers, all of the assistants who can help work with new contributors, and there's actually some stuff in my upcoming book about how you work with… like, somewhat lower-effort ways to work with contributors who are coming to you with, who need a lot of guidance, and maybe who’re providing pretty poor patches. This is not an insoluble problem.

Idan: [01:05:11] Yeah.

Sumana: [01:05:11] I'm sorry, that really went all over the place into a lot of stuff.

Idan: [01:05:16] It did. But I mean, there is a lot of stuff. And it’s not a strictly, easy to wrap your head around it. I've seen on the subject of certifications, there's certifications for certain parts of our industry. It’s like, if you want to be a Cisco-certified networking expert, then you pay Cisco, a whole bunch of money and then at some point, you get a little diploma that says, “I’m not terrible at this job.” And you can get this kind of certification for a lot of different things, but they tend to be very industry-focused, like if you—

Sumana: [01:05:50] It’s very specific to particular subset, a particular framework, usually a particular commercial product.

Idan: [01:05:57] Exactly. It’s like, “I know how to administer Salesforce, and I have the diploma to prove it.” And it costs me quite a bit of money to buy that diploma, which obviously excludes a lot of people but there has been sort of talk over the years of, if we think of the crafting of software as a trade like a lot of other building trades. If you want to be an electrician, you have to be a licensed electrician. If you want to be whatever—

Sumana: [01:06:26] A doctor.

Idan: [01:06:26] you to be a licensed whatever, exactly. In that there's, maybe there's room for something like boards, so that there's a way to independently evaluate people.

[01:06:40] We have time for one, one last question. You keep coming back to—

Sumana: [01:06:44] I should say that I wasn't thinking of certification, I was thinking that kind of course would basically be more about you've gotten the skills and that ideally, it would not be something where people would want that certification for their wall. But I recognize that when you set up a course, then there are things that might emerge around it.

Idan: [01:07:04] Right. One last question, you keep coming back to this tooling built into and you say, the forge, forge being sort of a generic name for a GitHub or a SourceForge, or a GitLab, or the sort of the platform of collaboration for software development. And this tooling to help identify what needs to be worked on to mediate communication between contributors to a project, maybe also to capture things that happen out of band. You say, like, “what if I have a Slack conversation with somebody, and then I need to bring it into the system, or I have some other kind of communication?”

[01:07:46] If these things are built into the platform, then is the fitness of that thing about satisfying most users? And if they aren't built into the platform, then who owns it? Is it just another open source project? How do we not end up with the the XKCD problem of now we have 15 different competing standards? It’s like, “ah, I’m gonna have one system to tie it all together. And now we have one more system.” How do we not end up with that kind of thing? What do we do that's going to drive towards maybe not consolidation into one single thing, that’s also bad, a monoculture, but how do we prevent it from just exploding into “here's yet another choice in a crowded field of choices?” What's going to help sort of guide us in that direction?

Sumana: [01:08:38] Definitely a complicated architectural question. So—

Idan: [01:08:44] Maybe I can constrain a little bit and—

Sumana: [01:08:48] So some of the things that I talk about are things that I think are probably pretty easy. They're prosthetics. They’re not so much about things like interchange between what's happening on this platform and what's happening outside. So for instance, when I, when I talk about things to help people ghostwrite each other's comment replies and share their saved replies and things like that. That's pretty on-platform, right? And then there's stuff that is much more about interaction and tooling, that somehow might have some kind of API integration with some other thing like Slack and Discord and Stack Overflow and stuff like that.

[01:09:40] I think that the issue of “well, we don't want a monoculture but how do we not like fragment too much?” I just, I don't see, when I look at just the marketplace dynamics of the industry, it doesn't feel like that's going to be too much of a problem. Because there just aren't that many different user types. There's maybe 10, let’s say, different user types of different specific shapes of open source software projects, and what kinds of governance structure and participation structure and prosthetics they need.

[01:10:31] I would go by, for instance, the Open Tech Strategies Archetypes report here and say, all right, there's just not that many very different. And probably, you could find something like five supersets of that and have, alright, this… And much like people use different kinds of collaboration software for different sizes of organization, and for optimizing for, let's say egalitarianism versus hierarchy. So, I think similarly, something like, you know, five different—

[01:11:07] And as long as there are migration paths from one to the other… People aren't generally going to find that migrating from forge to forge is something that they do on a month-to-month basis. But as long as there's migration paths, so that you can say, “oh, I've outgrown this, like a hermit crab outgrowing its shell, and now I need to move on to the next one.” Like going from like Flask to Django. “Oh, I now have more complex needs, now I need to move over here.” That doesn't feel like too much of a problem.

[01:11:33] Again, I assumed that this talk will be a laughingstock to people in the future who look back and say, freeze frame, “this is where she said it wouldn't be a problem.”

Idan: [01:11:43] And the narrator, “It turned out to be a problem.”

Sumana: [01:11:47] Seriously, yeah.

Idan: [01:11:48] Excellent. Sumana, thank you so much for coming on. And for being a part of the OCTO Speaker Series and sharing your wisdom with us. It was a pleasure to have you here today. And, folks, if you still have questions and want to engage, there's still the discussion thread, it'll be around. And please keep sharing thoughts there.

(closing pleasantries elided)

: Fatigue And Adaptability: In my dream last night, I was in an in-person work meeting. And then, halfway through, we started talking about how badly we were coping with the strains of the pandemic. After each person spoke, they got a blanket and lay down on the floor and started a much-needed nap.

I had this dream the night after I read that, in some chunks of the world (such as mine),

The clear skies we're seeing might merely be the calm in the eye of a storm.

Consequently, I would advise everyone who is fully vaccinated to make the most of their liberty while they have it, in case it goes away again.

In particular, if there are important things that you've been putting off due to to the risk of doing them, because they're necessarily in-person, you might want to get on that. That might be health things, that might be family things, that might be work things. Whatever it is, maybe do it sooner rather than later.

Leonard and I got our second vaccine shots in late March, so the past few weekends we've seen a few fully-vaccinated friends. I got to go hiking on Sunday! But now I am thinking I need to think about errands, and -- despite this weariness -- use this time towards them, while I can.

Whatever structures I set up to help me through this, whether routines or mindsets -- I ought not let them calcify past usefulness. I am trying to remember that I have the capacity to be flexible, and that fear is the mind-killer.

Filed under:

: Recent Books I've Read: The Devil Comes Courting by Courtney Milan -- about people in 1870 falling in love while figuring out how to encode Chinese characters for transmission on the first worldwide telegraphic network. It's like a "Landsailor" view of the kind of infrastructure historical fiction that Neal Stephenson's Baroque Cycle did: postcolonial, nearly all the major characters are Black or Chinese, focusing on how we can use these advances to connect to and empower ourselves and each other. With interiority and smooching and so on.

Ammonite by Nicola Griffith. As I read it, I grew increasingly sure that this feminist scifi classic is in conversation with a bunch of feminist sf classics I have not read, by Suzy McKee Charnas and so on, which I think the author's note at the end confirms. Still a great story and legible to me regardless. An anthropologist involuntarily joins a couple of civilizations and has to actually face the thing in her that was stopping her from connecting with people. Arduous travel, figuring out how stuff works, people falling in love, super-powerful meditation -- lots of interesting and moving passages.

Nadia Eghbal's Working in Public: The Making and Maintenance of Open Source Software: a book that is wrong in ways that accumulate page by page. This surprised me badly, especially since her Roads and Bridges report was so helpful. My copy of Working in Public has corrections and rejoinders from me in the margins of about every fourth page. I need to write a more thorough review but, in short, Eghbal's choices to ignore all projects that don't use GitHub, and all contribution types other than code commits, and all of the effects of venture capital on the economics of open source, and the roles governments can play in funding digital infrastructure, constrict the analysis and recommendations towards a disappointing conclusion that will not help most of the infrastructural open source projects (and their maintainers) I know and work with.

I'm partway through reading Nicola Griffith's Hild, a historical fiction novel about a real person, St. Hilda of Whitby. I am grateful that it starts off with Hild as an observant child trying to figure stuff out, because that's a key way Griffith gives me the necessary exposition to understand seventh-century Britain. And the book gets some form of indie-cred economy units because the only reason I've ever heard of St. Hilda is because of Hild, a bit like how the only reason I've ever heard of Dr. W. H. R. Rivers is because of Pat Barker's beloved World War I novel Regeneration. Neat to get to experience a world I've never known and learn about a person I didn't know. (This is perhaps where I should plug my MetaFilter post about Congressman Dalip Singh Saund, the first Asian American elected to the United States Congress, who in 1956 beat Jacqueline Cochran-Odlum -- a woman who'd flown fighter jets, known Amelia Earheart, and beat several men to get the Republican nomination -- to become Congressman from Burbank, California. I would please like a lush 10-episode prestige cable miniseries period drama about that election!)

: Thinking About Safety And Competing Access Needs: I don't have much to say about this but this piece ("safe spaces and competing access needs") and this discussion ("Safe" isn't a monolith.) have been rolling around in my head a lot, and I thought you might like to think about them too. Especially if you have responsibility for any shared physical or virtual group or venue that has a Code of Conduct, and especially if anyone in it has ever suggested that particular words or topics ought to be off-limits.

(1) : Anniversary: Today is my fifteenth wedding anniversary!

Leonard and I got engaged on 18 April 2006 and then married on 21 April 2006. For our tenth wedding anniversary we visited Paris. While there we visited the awesome Musée des Arts et Métiers, where I noticed:

Paris's museum on the history of technology displayed not only a Jacquard loom but its predecessors; others had done programmable looms but their versions didn't auto-advance the program along with the weave, or didn't allow composability (replacing individual lines of code), and so on. Jacquard was Steve Jobs, integrating innovations. I need to remember that there are always predecessors.

And -- as I recall with gratitude and relief -- I don't have to be Jacquard. I can be one of those other folks. "Somebody Will". "I am willing to sacrifice something I don't have / For something I won't have / but somebody will someday."

Today Leonard and I are celebrating our wedding anniversary by having a little virtual vacation to France. We drank some French-blended tea with breakfast, we'll get some French takeout later, and we'll watch some French TV ads on YouTube and play GeoGuessr to virtually walk around Paris.

I'm appreciating today the gentle quiet durable pleasures of a long partnership. I hope you get some gentle pleasure today, too.

Filed under:

: Python Packaging Tools: Security Work And An Open Position:

Two exciting bits of news regarding massively improving how we package, distribute, and install Python software!

First: a new grant. New York University (specifically Professor Justin Cappos) and I have successfully asked the US National Science Foundation for a grant to improve Python packaging security. The NSF is awarding NYU $800,000 over two years, from mid-2021 to mid-2023, to further improve the pip dependency resolver and to integrate The Update Framework further into the packaging toolchain. I shared more details in this announcement on an official Python packaging forum.

I'll be part of this work, paid to work on this part-time, doing some outreach, coordination, project management, and similar. Thanks to the NSF, Justin, the Secure Systems Lab at NYU, and all the people who work on Python packaging tools!

Second: the Python Software Foundation is hiring a full-time project manager and community manager for Python's packaging toolchain. Thanks to Bloomberg for the funding! Please check out the job description and spread the news. Please apply by May 18th, 2021.

The job is remote and you can apply from anywhere in the world. As the description says: "Total compensation will range from $100k-$125k USD based on qualifications and experience." And you'd report to Ee W. Durbin III, a colleague I strongly recommend and love working with.

I'm thoroughly grateful that we've now gotten to the point where the PSF can hire for a full-time person for this role. As a volunteer and as a contractor, I've performed -- in many cases initiated -- the activities that this person will do, and I've seen the critical need. We deeply need a full-time coordinator for holistically assessing and improving the user and developer experience of Python packaging, because -- as Russell Keith-Magee said in his PyCon US 2019 keynote -- the status quo poses "an existential threat" to the future of the language. And so one of the desired qualifications for the role is: "Belief that Python packaging problems are of critical importance for the Python language... but that those problems are solvable."

We've gotten better and better at attracting corporate and grant funding -- and yes, I'll take some credit for that, with my past work researching and writing grant proposals, leading funded projects, and volunteering with the Packaging Working Group and cofounding the Project Funding Working Group. So, now, what should we focus on? We need to prioritize improvements for strategic value (e.g., should we first concentrate on overhauling the Warehouse API, or making a generic wheel-builder service, or tightening metadata compliance, or ....?). What can we learn from other package management toolchains, especially those that emerged after PyPI and pip (e.g., yarn, npm, cargo), and what should we copy? In my opinion, you do not need to already have an opinion on these questions to apply for this role -- you just have to be interested in talking with a bunch of stakeholders, poking through past discussions, and collaboratively developing some answers.

I won't be applying for this PSF role -- I'm going to be, instead, excited to collaborate with that person and help them learn all the stuff I know, so that in the long run, we'll have more people, with that set of skills and domain knowledge, working on Python packaging. I'll concentrate on the Python supply chain security piece specifically (via the NSF-funded work at NYU), plus finishing my book and maybe creating and leading associated trainings, and taking what I've learned to other languages and ecosystems through client work.

So: please spread the word and apply!

(2) : Trying to Notice What's Missing: I'm ploughing through some open source project email threads and thinking:

In 2010, people got together in Berlin for a Wikimedia developers' meeting .... and then a bunch of them hung around a lot longer than they'd expected, because a volcano erupted and so their flights got cancelled. As I understand it, you can trace certain architectural decisions and improvements to the discussions and pair programming from that chunk of unexpected extra in-person time.

It's conference season, at least in the northern hemisphere, and we're going into our second year of virtualized or missing technology conferences. The maintainers, users, and stakeholders of the open source software you depend on have gone more than a year without getting to quietly gossip with each other over a snack or while walking to a sponsored party. It's been more than a year since one guy has been able to make that other guy laugh and remember "ah, he's not so bad really". It's been more than a year since people could easily scribble boxes and arrows together on the back of a conference schedule or poke at the demo on someone's laptop.

We come together every once in a while to refill on trust and camaraderie and a shared understanding of what we're trying to do and who we're trying to do it for; I assume that, for some folks, those wells have now run dry.

In a tree's rings you can see the years of drought. Where, in our code and our conversations, will we see the record of this separation? Do you already see it?

: Discovery Versus Context: This insightful, funny, downbeat Brandy Zadrozny interview obliquely reminds me of something I realized the other day: the modern Web is, relatively, amazing at offering discovery but awful at offering context. It's easier than it's ever been for a single blog post/microblog post (such as a tweet), song, video, photo, etc. to be discovered, publicized, and plucked out of the context of what the creator usually says, what they are aiming to do, who and how large their usual audience is, and what power they hold in the institutions of their lives. And so it's easier than it's ever been to be heard, and easier than it's ever been to be misunderstood.

: If You Call Me A Thought Leader For This Post I Will Give You A Stern Look:

In scifi/fantasy fandom there's this phrase, "Big Name Fan". This is someone who is well-known, influential, for the fannish things they say and do and make. The idea is that a BNF is a minor celebrity -- not at the television-interviews level, but still, within their Internet and convention circles, someone who gathers a crowd, and whose tossed-off words have disproportionate power to help or hurt others.

The chunk of fandom I'm thinking of is, mostly, women. We're socialized to not admit when we have power, and to shut up and use it to serve others. Joanna Russ wrote about this dynamic in "Power and Helplessness in the Women’s Movement"; fan Hope reiterated that expectation in "Nobody Ever Admits They're a BNF", advising Big Name Fans that they get to benefit from feelings of belonging but "You are not allowed to have hurt feelings, you are not allowed to argue with someone, and you absolutely are not allowed to have an opinion." I think the only/first time I've found out that I've been called a BNF, it was in the context of someone criticizing my too-abrupt comments in a Dreamwidth thread; they were disappointed, taken aback, at such a BNF acting in this way.

Given that it's considered arrogant to call oneself a BNF, at least in public, perhaps you can infer how difficult it then is for a person to honestly and transparently reckon with the concomitant opportunities and constraints.

And perhaps you can draw a line from this dynamic to ones in the developer relations industry, or in large collaborative volunteer groups such as major open source projects, etc. If you have an explicit role such as "conference chair" or "professor" or "maintainer" then you know whether you inhabit it or not, you can straightforwardly mention that you hold it, and you and your peers can come up with norms for the special powers and responsibilities that come with it. But absent that? As far as I am aware you do not get a how-to book and access to an all-celebrities group chat upon achieving some number of Twitter followers. A person who has gradually accreted influence must notice that they have more intangible influence than most of the people they talk and listen to, and -- through reflection, study, and private conversation -- develop their own guidelines for how to use that influence.

But: there's how you act, and then there's how everyone else acts toward you. No matter whether or not they get some explicit roles to help everyone understand these kinds of expectations, I think -- at least in the bit of US society that I'm used to, where we have strong egalitarian ideals -- we don't help newly powerful people get used to all those social epiphenomena that will now start brushing against them. Envy, intimidation, and so on. Maybe there are now influencer finishing schools that include "you are now the object of other people's projections and their parasocial interactions with you will get very weird" in their curriculum.

I have counterproductive feelings and habits in my head that relate to this whole issue, around envy, martyrdom, etc. As with the stuff I mentioned earlier this week in "Paralipsis", this blog isn't the right place to work through those things. This week I'm particularly grateful to friends of mine with whom I can talk candidly about this stuff. And if you and I are friends, perhaps we can talk about it too.

: A Few Books Influencing Mine: I'm working on a forthcoming book on rejuvenating legacy open source systems. In addition to my bibliography of open source management books/courses, I'm grateful to a few management, teaching, and writing books that have influenced me recently:

Florence Nightingale's Notes on Nursing: What it is, and what it is not, a cranky and thoroughgoing text on management that covers the healing environment as a whole: "let whoever is in charge keep this simple question in her head (not, how can I always do this right thing myself, but) how can I provide for this right thing to be always done?"

Greg Wilson's Teaching Tech Together: How to create and deliver lessons that work and build a teaching community around them, a guide to effective instruction: "We have been talking about mental models as if they were real things, but what actually goes on in a learner's brain when they're learning? The short answer is that we don't know; the longer answer is that we know a lot more than we used to....As scary as it is, we are the grownups."

Via a recommendation from Eszter Hargittai on Crooked Timber: Thinking Like Your Editor: How to Write Great Serious Nonfiction and Get It Published by Susan Rabiner and Alfred Fortunato (concentrating on the kind of nonfiction from big publishers that gets reviewed in major newspapers), and So You Want to Publish a Book? by Anne Trubek (who runs a small press). I just read these within the past week. In Trubek's book I particularly appreciated the list of presses and imprints belonging to the Big Five, her breakdown of budgets, her frank appraisal of what helps sell more copies of a book, her thoughts on horizontal solidarity among authors and reader, and her assessment of Amazon's effects on the market. And in Rabiner's and Fortunato's book, I was struck by their in-depth explanation of how to structure a book proposal (and the many examples of what works and what falls flat), their thoughts on what editors are seeking, and their advice on structuring a book and making one's argument fairly.

Filed under:

: Painstakingly Reminding Myself How To Play:

This is a little bit about how free-range learners in programming assess our own skill levels and choose what to learn next. But it's also a response to my own insecurity, and to the sometimes-stultifying weight of concentrating one's work on infrastructure.

Working on things that matter

In the Abstruse Goose comic "Computer Programming 101", a learner provokes an explainer with further and further questions about the CS and hardware and physics underlying a programming task. One reading of the comic: "Get comfortable with abstraction. If you try to understand how everything works, you'll get nothing done."

Yeah, of course, everyone's time is finite, and we all have to make our own decisions about how much time to spend on learning and how much time to spend doing other things, using our existing levels of knowledge. (Although I've recently tripped up on the assumption that the listener aims to get anything in particular "done".)

But there's also a kind of obliviousness that is so helpful, not just cognitively but emotionally, when I'm learning. Not knowing that something is risky, or not really being able to comprehend risk, helps you do it. This is one reason it can be useful to learn a bunch of programming skills when you're young, not just because very little responsibility rests on your code's shoulders, but also because at that stage you haven't yet seen all the vulnerabilities and Daily WTFs and unlocalized sadnesses... you don't even know what all edge cases exist in the world. You can take the leap of faith that all your infrastructure will work -- heck, you don't even know what infrastructure you're relying on! You don't even realize you are taking that leap of faith! -- and concentrate on getting your corner just right.

For context: for my job, I primarily work, and want to work, on mature open source software that many users already depend on. I find a lot of satisfaction in rejuvenating and stabilizing widely-used open source projects and thus healing important parts of the whole system. My professional experience is loaded up with working on stuff like GNOME utilities and MediaWiki and the Python packaging toolchain. (I left the Wikimedia Foundation partly to mess around with blank slates and without legacy infrastructure/stakeholders.... and then turned into the de facto community manager for Python packaging!) I played with BASIC as a child, and I learned a bit of Scheme and bash in college, but I came to programming in a serious, sustained way AFTER years in the industry, as a technologist and manager in software engineering teams.

Which means that when I do want to make a little toy, sometimes it's been hard for me to just come to it with learner's mind. I see that it has no unit tests, no localization, a bad UI, crappy OO, no extensibility and zero separation of concerns, ridiculous performance. There are at least five worlds of software development (that article is pretty obsolete but its point is reasonable) and I am a permanent resident of the People You Don't Know Will Need To Use This Software world. I spent some of my childhood in Playing Around world but it can be hard for me to remember how to get around there. (And oppressed people, out of necessity, often mitigate risk more, tempering audacity. So that's yet another privilege thing.)

As Amandine Lee writes: "People's intuitions and risk-friendliness also vary based on personality, and how they've seen things fail in the past." Yes! But then the very next sentence: "A lot of growing as an engineer is fine-tuning that initial response to design decisions." She meta-cautions us against knee-jerk caution, a reflex that leads to "wasteful carefulness". Was it nearly a year ago I talked about this, about the balance between preservation and growth? Maybe it's a springtime kind of rumination.

Precursors to relaxation

I am trying to think about what helps me let go of those worries and fiddle, sketch, prototype. Curiosity about a specific dataset helps, as does the impatient desire to munge some data into a form I can more easily reuse. Or an external force causing me to concentrate on achieving some specific outcome OTHER than "other people need this," like "I want to create enough of a game that I can put it in my application to the Recurse Center" (e.g., this commit in "Where on the Oregon Trail is Carmen Sandiego?" -- global variables and pretty naive string concatenation abound, as you can see, and I think those were the first two classes I ever wrote). I also think it helps when I feel like I am exploring abundant neat stuff left over by past architects, as with "HTTP Can Do That?!" (video).

Geoffrey Litt reports that part of it, for him, is concentrated time: "Also, I just gotta say: years of professional software engineering has trained me to work sustainably, but there's something to be said for a few long, unsustainable days of furious programming. Early-stage creative prototyping seems to benefit from a certain energy level that's not easily attainable in a sustainable environment." (Which makes me think about different ways participants can use Recurse Center, deliberately creating bursty rhythms of work and recovery, if they're concentrating on inventing, versus using a consistent routine to aid learning.)

Security and insecurity (how novel, I know)

A few years ago* I started thinking about how to harness this dynamic for play and confidence, specifically by improving my cybersecurity skills. My reasoning went:

  1. I often see good engineering that is better than I could do
  2. There is a counterproductive reaction-pattern in my head that sometimes finds it intimidating, not inspiring, to see amazing work
  3. Thus I get turned off in a fixed-mindset way, thinking "I am not a good engineer" because of my relative inferiority
  4. But the reverse is also kind of true; if I discover flaws in real running production code then I will notice my relative superiority and feel more confident about my own abilities, which raises my morale and makes it easier for me to try things that I might fail at
  5. There is a lot of poor engineering out there, especially when, for instance, viewed through a security lens, and it is probably possible for me to use existing resources to understand common flaws and learn how to find them
  6. Thus, it would be a good step for me to learn more about the bit of the software industry that has lots of terribly written code, in production, that I can inspect and feel superior to

(There's something here in common with what I've said about ways to deal with impostor syndrome, and self-assessment vertigo -- find reminders of my own competence as compared to the whole human population, not just the experts whose skill level I aspire to.)

Less coherently, I feel emotionally insecure and feel digitally insecure; I would like to be able to make better-reasoned tradeoffs about my digital behavior and protection. And I was noodling around, thinking about the community of practice of script kiddies, and the envy I feel when thinking about having the time and equipment to play like that, and the joy of feeling powerful but not responsible. I thought that would be something I would get out of offensive (rather than defensive) security skills: a feeling of power without necessarily then feeling a new weight of responsibility.

Fast forward to now. I went in approximately the opposite direction. Sure, I know more about cybersecurity now, and I'm even a visiting scholar in an academic lab working on cybersecurity. But it's to better secure the Python packaging pipeline! More infrastructure work! I have not learned any offensive skills and all of my power comes with responsibility! It's like the sitcom trope where a person says "I think I'm gonna skip that party" and then the show cuts to them seated in the middle of a big banquette table at the restaurant and everyone's wearing party hats.

And I now know myself well enough to know that, as soon as I notice a needless wasteful problem, I itch to fix it, and have to remind myself to pick my battles. So: even if I did grow in my offensive skills, every time I noticed a vulnerability, I would immediately feel a frustrated desire to patch it, more than I'd feel a confirmation of my own capabilities. I am too mature to have power without feeling commensurate responsibility. I missed my window.

Old advice for a new mind

A few nights ago I couldn't get to sleep because of a wave of insecurity and negative self-talk. I never went to MIT and I wasted my social opportunities in college and that's why I founded Changeset solo instead of with a cofounder and that's why I haven't yet achieved what I wanted to! I'm middle-aged and my neuroplasticity is declining and it's too late for me to gain momentum on improving my habits and getting more efficient and making an impact! That sort of thing.

And I remembered an old teacher of mine, Mr. Berkowitz. He taught government and economics at my high school, and he looked ancient and frail -- when he slowly walked the path between the administration building and his classroom, I thought I could see the wind threatening to knock him over. And that's why it made such an impression on me when, on the last day of class, he told us: "if you keep learning, you will never grow old."

And I got out of bed and went to my computer, and figured out how to install Rust (with help from 2 people in the Recurse Center's Zulip chat), and started Rustlings, an exercise-by-exercise approach to learning Rust by fixing code that doesn't work. I completed the first exercise and got the string of "tada" emojis and smiled, a strong real spontaneous smile, and felt and noticed it. And a few exercises later, I was calm enough to go to bed and fall asleep.

I have some unformed ideas about how knowing a bit of Rust might help me with my work, to lead projects like Federico Mena-Quintero's work on librsvg, replacing C library code with Rust. But maybe the big reasons it appeals to me are that everyone I've ever heard of working on Rust is friendly, and the language aims to be really helpful with its error messages, and no one needs me to learn it. It's ok if I don't do it. Which makes it more ok to do it.

In my job I want to work on things that matter. To do that job well I need to learn. The pressure of "this matters" can make it harder to learn. Therefore there is meta-work I must do to make tidepools and sandboxes for myself to learn in, shifting my mindset accordingly. And, for bigger jaunts into Playing Around World, maybe making time for another retreat at Recurse Center sometime.

* I have a note here that maybe this was related to my experience watching a preview of Jessica McKellar's talk "Building and breaking a Python sandbox". In it, McKellar mentioned to us that ping runs as root, which stuck with me.

: Paralipsis:

I'm in the process of working with a contractor to overhaul my personal and professional websites. Thus, I have been thinking about my brand (oh how I want to put distancing quotation marks around that word when it pertains to me), and breadth.

I value my ability to use this weblog to write about a broad variety of topics (and, in the writing, find out what I think) and in a variety of tones. This is at odds with the approach of many successful professional blogs, and perhaps there's an inertia here, a self-sabotaging recalcitrance to shape up and make my interface easier for my future customers to grasp. "Indie 101, do stuff that defeats your own purpose. Reflexively, routinely." as John Darnielle said.* I think I'm not. I think I'm doing this out of a kind of intuition, about habitually being and seeming like a person who will bring a multidisciplinary approach to your problem, about the relative advantage of being a bit weirder and having more odd edges to catch on in a Web of frictionless interchangeability, and about the mental benefits to me of minimizing the upfront cognitive cost of choosing which venue I use to think aloud about what.

But, in the overhaul, the contractor and I will be making it easier for people who only want to see the work-related stuff to browse and concentrate on that, particularly via resource collections on the Changeset Consulting website.

And I've been reflecting on the limits I do have in what I blog about. As early as 2002 I wrote here:

I'm not my whole self here. If you are your whole self in your weblog, if I could completely know you by just reading your weblog, then you've broken some barrier and become a Philip K. Dick character, or you have a very small life.

Talking about that necessarily seems a bit coy, but I've been meaning to write about it for years, so, here are some thoughts.

The nonrandom distribution of absence

... rhetorical devices ... in which a speaker claims something to be true while implying the opposite. Sarcasm works that way, of course, but there are subtler forms. For instance, praeteritio, also known as paralipsis: pretending one is omitting information while providing it. "I shall refrain from mentioning my opponent's lengthy criminal record...."

Several years ago, a friend of mine asked me for a bit of advice, because she was thinking of blogging something about sexism in technology, and wanted a risk assessment. How likely is it that jerks would contact her employer and suggest she be fired, or send her rape threats or death threats, or try to break into her online accounts, or find her phone number and harass her that way, or follow her around and try to argue with her at conferences, or give her a hard time via Twitter, or start overlooking her for various kinds of opportunities, or write thoughtless or hurtful comments on the inevitable Hacker News discussion, or otherwise demonstrate Lewis's Law?

I write about technology, and sometimes I write about anti-sexism initiatives. But I thought about the things I rarely or never publicly write about, because I'm afraid. Here's what I wrote, more than six years ago:

I don't write about the few really bad experiences I've had.

I don't write about the things friends and acquaintances are going through.

When I travel, I don't publicly mention what hotel I'm staying at.

I don't talk in detail about what it's like to be the only woman in the room.

I don't write about my own sex life, at all.

I don't write about figuring out what to wear, or about the trouble I fear if I explore traditional expressions of femininity.

I don't talk about my period.

I don't talk about men assuming that I went to Hacker School to learn how to program, from scratch.

I don't talk about deciding which photos of myself are too chesty to put on my site, or about not knowing whether photographers at an event really want to get a lot of shots of the only woman of color who's turned up.

(And here I stopped writing for a while, because it's wearying and sad and tedious to think about this, and because there were probably more topics that I didn't even want to mention in the list.)

@hashoctothorpe started a #whatitslike hashtag on Twitter.

It's like deciding how far to stick my neck out, all the time, every second, never not making that decision #whatsitlike

"Like being the emotional grownup in the room." #whatsitlike

Like watching my friends and role models be terrorized and being unable to help. #whatsitlike

"Like my friend and i were talking and you interrupted to ask that" #whatsitlike

My friend -- the one who'd asked for advice -- thought about it for a while, and changed all her passwords, and posted the piece she'd written.

But some don't. "Ghost works are all the works that never get made in the first place, or are made but not released".

A bit later, Leigh Alexander wrote:

One of my colleagues just wrote me she's frustrated about all the conversations we're not having. We all are, I think, migrated against our will to interminable residencies in a politicized minefield, where even talk amongst ourselves is scrutinized.... We are not free to debate and to disagree lest we be set against one another.

And that resonated with me, because we're missing people in our public discourse; our conversations are poorer because some of us are more afraid to speak our truths, and that difference is not randomly distributed.

Sometimes the most urgent thing to hear, the lifeline, is "you are not alone." But the consequences of sharing are hard to assess ahead of time. And I'm not just talking about harassment. Sometimes the legal ground shifts under your feet; in the US, if the Affordable Care Act disintegrates, then it will have been more unsafe to talk about health stuff online.

Or the technology changes, so the ground shifts from opaque to transparent under our feet, and archaeology turns trivial. What is public? Or: what is secret, or private, or public, and does that middle category exist anymore?

I think that’s what Twitter is all about, and permits: it’s sort of magically translated the informal register of text messages into the public space, and for public figures, allowed them to get away with throwaway comments far more than before.

I don't know how well Danny O'Brien's 2009 assessment there held up. Perhaps as more people learned to use Twitter search it got less true.

Then, mostly separately, there's the "brand" stuff.

Limited-purpose public figure

me, preparing to have my photo taken at an open technology event, on a rooftop in Queens in 2013

Am I a public figure?

Courtney Milan wrote, regarding a legal controversy in 2014:

...if you inject yourself into an issue of public concern, you may be a limited purpose public figure -- that is, someone for whom the standards differ....

...And the standard for defamation actions for limited purpose public figures is substantially different than for private citizens.

I don't know whether I am a limited purpose public figure, legally, for any controversies at the moment. But the phrase strikes me. It's an evocative phrase, sounding more sophisticated than "brand" or "platform". They get at different things.

A brand is a way to carve a shelf into your brain, at a particular junction of ideas and feelings, so that a picture of me can sit there. But a too-narrow shelf is a pigeonhole. What do we avoid sharing, not because it is uncharitable or misleading or overly revealing, but because the more different things I say the less you know where to shelve me? How many ghost works un-exist for these reasons? Ryn Daniels wrote: "More and more of the time, I end up not posting something I was considering. The bigger my 'brand' gets, the bigger the boundary I have to maintain between it and my self."

The contractor interviewed a few of my friends, colleagues, clients, and peers in the free and open source software world to help understand what they see in my business and in my personal blog. They determined that the indie informality and voice of my personal site helps establish my credibility especially among free and open source folks, and that we can have the personal site and the Changeset Consulting (business) site reinforce each other, so that the Changeset site does the job of establishing my serious professional face to potential clients (i.e., mostly companies) yet benefits from my personal writing too.

This feels like a reasonable path forward. A brand is a public tool for a limited purpose; the business site will be pointed, drawing the reader through a few specific paths. And the personal site will be more browseable, but still diffuse, more of a kaleidoscope where decades of my facets shimmer and reflect off each other. Still not everything, of course; I'm still not a Philip K. Dick character. But enough rich variety to retain the capacity to surprise you, and, just as importantly, myself.

* about 3:00 to 3:15 in the "Leaving Home" track in this 2007 concert recording.

Filed under:

: Autocorrect Hilarity: A friend found out recently that his spellchecker did not know the word "disempowering" and instead suggested "disemboweling". Spellchecker, I beseech you, in the bowels of Merriam-Webster, think it possible you may be mistaken.

Filed under:

: Not The First Time We Tried (FSF, GNU, RMS, etc.):

Here's the open letter in which thousands of people and several organizations ask for major changes at the Free Software Foundation and GNU in light of the FSF's recent and extremely frustrating choices. I haven't signed the letter; I am in a position much like Andy Wingo's (I have some obligations to GNU Autoconf that are not yet discharged). But I agree, for instance, that FSF needs a new board, and I want to put something down here to mark my solidarity with so many who have spoken up in the last week.

Some of my peers think this is the first major effort to file a bug about Richard M. Stallman and about FSF and GNU governance, that critics went directly to asking for his removal. It's not the first bug report or request for negotiation; far from it (as former FSF board members Bradley Kuhn and Matthew Garrett discussed in 2019). Today's FSF board announcement would be more promising if it didn't follow years of one-step-forward, two-steps-back conversations about FSF and GNU governance. I have participated in past attempts to talk about these problems with FSF and GNU, with lower stakes, and I figured I'd lay that out here.

In particular, you ought to know that the FSF and GNU have repeatedly failed at fair and consistent treatment. I care about everyone having to obey the same rules and having the same freedoms and the same opportunities; the FSF and GNU have demonstrated that they do not. Boring stuff ahead: Caution that this is a somewhat long and boring post about governance, policies, and similar dry stuff. Skip to the "Fairness" section for the wrapup.


My first time shaking my head and sighing at something Stallman had done at a FLOSS conference was in 2009, if not earlier. And over the years I heard more and more. In particular, I became aware of multiple instances of inappropriate behavior over the years at the FSF's conference, LibrePlanet, such as taking over sessions through loud disruptions. And, in 2017, RMS explicitly said that, as president of the FSF, he was not subject to the rules in the Q&A of Marianne Corvellec's 2017 talk (here is a recording).

During the session submission period (in late 2018) for LibrePlanet 2019, a significant number of former speakers, including myself, jointly contacted the Free Software Foundation Board of Directors. In our message, we expressed concern to the Board over inconsistencies in how the LibrePlanet Safe Space Policy is applied to members of the Board itself.

During discussion with the Board over a few weeks, the group expressed the critical need for LibrePlanet's Safe Space Policy to apply to all participants, including all the members of the Board, which included Stallman, FSF Board President. During the discussion, the Board did not address the following specific actions we requested:

  • That the Board explicitly clarify that if RMS violates the Safe Space Policy again organizers will step up and impartially apply the rules to him.
  • That the Board appoint a disinterested ombudsman or committee with the power to oversee and handle safe space policy complaints, and enforcement, including for Safe Space Policy complaints against members of the Board.

On November 8, 2018, the Board told us they were working on a response but that it would take time. In early February 2019, many of us got individual email replies from one of the FSF Board of Directors, representing the Board. The response from the Board said FSF was working with a third-party consultant to improve safety procedures. I hoped to see a public announcement of the name of the consultant, or a Code of Conduct transparency report after the con (example). We have seen neither.

The board also said that safe space policy complaints against FSF staff, board members, and officers would be handled by other members of the board, rather than appointing a disinterested ombudsman or committee. But in the last few years, outgoing and former FSF board members including Bradley Kuhn, Benjamin Mako Hill, and Kat Walsh (further re: Walsh) have all tried to use their Board and Voting Member seats to appropriately limit Stallman's behavior and authority, and were evidently unable to form a majority to do so.


In May 2018, during the discussion of a controversial joke in glibc's documentation, I emailed a few FSF staff and board members as well as the GNU Advisory Committee. I shared my assessment of the relevant policy documents:

The governance question currently affecting glibc (context: hinges on whether Richard has the authority he claims to have and whether he is a responsible user of that authority. I've reviewed the conversation and relevant policy documents.*

In my assessment, while Richard has a tenuous claim on his privilege as Chief GNUisance to prohibit the removal of a joke he wrote from the glibc documentation, his choice raises questions about his fitness for the role of Chief GNUisance, especially as the joke contravenes GNU documentation standards ("Make sure your manual is clear to a reader who knows nothing about the topic and reads it straight through.") and "Information for Maintainers of GNU Software" ("Don’t feel obligated to include every change that someone asks you to include. You must judge which changes are improvements—partly based on what you think the users will like, and partly based on your own judgment of what is better. If you think a change is not good, you should reject it."). In my experience as a free software community leader, Richard's choice is also apt to cause attrition among existing GNU maintainers and contributors, which will slow work towards GNU's goals.


* for reference: 0.

I asked:

What would the criteria be for re-evaluating Richard M. Stallman's position as Chief GNUisance?

If the answer is that there are and can be no such criteria, and there is no change in circumstance or aspect of Richard's behavior that would cause GNU to demote Richard and promote someone else to Chief GNUisance, then I would like that explicitly and publicly stated.

And if the answer is that there exist such criteria, or that you would like to develop them but have not yet done so, then I would like that explicitly and publicly stated.

The GNU Advisory Committee as a whole did not make a formal reply; a few individual members replied with criticism of my "bullshit". I did not pursue the question further.

A year and a half later, in late 2019, Stallman was not on the Board of Directors of the FSF, but still claimed leadership of the GNU Project. A collective of GNU maintainers signed a statement saying, "We think it is now time for GNU maintainers to collectively decide about the organization of the project." I know of no public response to this statement by Stallman or the GNU Advisory Committee. "The FSF never officially helped or even replied to our requests to formulate an open and welcoming working relationship with us as GNU volunteers."

In February 2020, the FSF published a post saying that "The Free Software Foundation and the GNU Project leadership are defining how these two separate groups cooperate." They asked for input from the public. I wrote to them on February 12th to ask:

  • There are many standards by which to judge whether an institution's work is moving the mission forward, and by which to judge whether a person in a position of leadership is acting as a good steward of that institution. For FSF and GNU, those standards might include fundraising and money management, effective public speaking and writing, keeping principles like the Franklin Street Statement in the public consciousness, providing compelling new visions and articulations for the movement when necessary, growing the number and types of volunteers who contribute to crucial free software projects, making strategic choices to improve free software infrastructure, recruiting and mentoring successor leaders, offering useful architectural guidance or code review, and project management. Which standards are appropriate to judge FSF, and which for GNU, and which for both? And how can we ensure that each organization regularly checks that the other is staying on course?

  • Similarly: let us look forward to what the FSF and GNU can do in the next several years. Can we make strides on things free software developers care about -- including platform support to help developers do their work better, financial infrastructure, protecting freedom in concrete ways, and recruiting new people into the free software movement and retaining them? Which organizations' leaders are genuinely interested in and excited about those goals?

  • How shall the board members, and the voting members, for the FSF be chosen? How can you ensure that those lists are transparent (I believe right now the list of voting members is not public) and that FSF members like me have a voice in those appointments and elections?

  • Similarly, for GNU: how is the leadership chosen, what voice do GNU volunteer contributors have in choosing leadership and policies, and is that process in accordance with free software values?

  • As of 2019, FSF was working with a third-party consultant to improve safety procedures at events such as LibrePlanet. What were the outcomes of that consulting, and did it result in FSF adopting or strengthening any principles or procedures that should be included in a partnership framework with GNU?

I received an acknowledgment that my message had been received, but nothing further, and neither GNU nor the FSF ever made an announcement regarding the cooperation framework. The only subsequent announcement was an email announcement by Stallman, later that month, documenting the existing GNU governance structure.


Fairness is at the heart of free software values. We set policies -- the GPL, for instance -- that apply to everyone equally.

To remix another phrasing, no one is indispensable and no one is disposable.

I contributed, in good faith, to efforts to address the unfair, inconsistent treatment of Richard Stallman regarding LibrePlanet safety standards and in the GNU maintainer procedures and documentation policies. Others did similarly in several other areas. I joined my fellow free software advocates in doing this not just because of the individual incidents that free software advocates have been reporting for many years. I did this because of the meta-behavior of Stallman's claim that he is not subject to the same rules as everyone else. To borrow a phrase, I was tired of treating Stallman like a missing stair. So we filed bugs about the situations caused by his behavior, and by FSF's and GNU's unwillingness to consistently apply their policies.

The grief of having all those efforts marked as WONTFIX causes some ache -- as does the dismissive attitude I see from some peers in the tech industry, as though our care and work were foolish and useless. As though this setback means we should scrap the whole endeavor.

To me the history of free software is partly the history of us making it better, on a social and infrastructural level, the same way that the history of the United States (I'm an American) is partly the history of us making it live up to our ideals. With words and actions (codes of conduct, The Carpentries, Software Freedom Conservancy, Python's Steering Council model, so much more) we've been steadily working to improve, and -- with or without the FSF and GNU -- we will keep working.

I've been using GNU/Linux for more than twenty years, free software is my profession, freeing people using free software is core to my values, and I ain't stopping.

: A Miscellaneous Reading List:

A few days ago I submitted my nomination ballot for the Hugo Awards. In many years it's a bit hard for me to think of five excellent things to nominate in each work category. But last year I spent a lot of time highlighting interesting short speculative fiction that you can read for free online, so it was super tough to choose in the Best Short Story category! I wish I could have nominated 15 things.

My nominations for Best Novelette:

and Best Short Story:

Also, in Best Dramatic Presentation: Short Form, I nominated "Explaining the Pandemic to my Past Self Part 2" by Julie Nolke.

I didn't have as many books to nominate -- I often read stuff years after it's published, and I've been far more lax about logging my reading than I was years ago.

A few days ago I finished The Traitor Baru Cormorant by Seth Dickinson; I liked it, and since it came out in 2015 Dickinson has published two more books in the series, so I'll probably pick those up. It's wrenching and full of political intrigue, and perhaps it's a measure of my mental wellness that I was up for that. I don't think I would have made it more than two chapters if I'd tried that in December.

Today I finished reading Conflict Is Not Abuse: Overstating Harm, Community Responsibility, and the Duty of Repair by Sarah Schulman. I'd meant to read it since I'd read this fascinating and wide-ranging Autostraddle interview. For a few years now I've been interested in feminists talking about how we distinguish character assassination from accountability. I appreciated adrienne maree brown's thoughts from last year that included:

i, we, have to be able to discern what is me/us, and what is fear.

which leads to my next unthinkable thought: do i really know the difference between my discernment and my fear?

Schulman goes broad and deep in discussing this topic. What do we lose when we use email and text messages to try to discuss conflict, instead of phone and in-person meetings? How do displaced anxieties and unprocessed trauma cause us to overreact to expectable, no-one-is-at-fault problems with our friends and peers? What ripple effects emerge when we are afraid to negotiate and when our groups don't support processes of reconciliation? A very worthwhile read and I recommend it for anyone who wants to think more deeply about a wide variety of phenomena that often get labelled "cancel culture."

Less recently, I read the thought-provoking collection "The Beatrix Gates (Plus....)" by Rachel Pollack, in PM Press's great "Outspoken Authors" series. I appreciated a perspective on the transgender experience that I'd never read before, and images from the stories will stay with me.

And, many many months ago, I finally finished Bleeding Edge by Thomas Pynchon. I was a little disappointed! Lots of fun observations, but I found the finale of the virtual reality plot kind of empty.

I have a bunch of notes about shorter reads to share with you:


Filed under:

(1) : A Spec For A Sandboxed Open Source Project Environment: I'm writing a book on maintaining legacy open source projects to help teach people vital skills. Right now, as far as I know, there's no textbook or course you can work through to learn skills like assessing an open source project systematically, triaging bugs, noticing quiet-but-promising contributors to promote, improving code review processes, writing a grant proposal, and finding your successors. Or, more accurately, there are courses and guides that cover different software leadership areas, but there's nothing that covers the whole toolbox.

When I'm teaching skills, I want to give learners exercises they can use to develop and practice those skills. And if I turn the book into a course, I'll want to be able to assign those exercises and review their homework. So I started thinking: 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've been thinking about this for a while. Today I wrote up a spec. I don't know what to call it - "Maintainer Sandbox", "Snowglobe Factory", and "Diorama" all sound good. The spec below assumes that I'd be leading a cohort of learners through a semisynchronous online course; it would work fine for an in-person class as well, but I'd have to adapt the access levels part for a completely self-paced and self-driven course.


As instructor, I would create a snapshot of a sample open source project (comprising materials listed below). The hosting platform would replicate it in self-serve instances, usable over the web, for user exercises. Upon signing up for a course, a user would get access to a freshly provisioned instance, complete with project history.

Materials: Each instance would include the following artifacts, all browseable and searchable via the web browser:

  • Bugtracker-type artifacts and history that would generally be available as part of a GitLab or GitHub project: a git repository for code history, past and present issues and patches/pull requests/merge requests (complete with tags/labels, milestones, assignees, and similar metadata), past release announcements, and a wiki
  • Project documentation and overview information for users and for developers, as would generally be available on a project's website (even if documentation source is available in the git repository, the snapshot we provide should include the docs as rendered into HTML)
  • Archives of the project's mailing lists, as would generally be available as a Mailman, Majordomo, or similar instance, browseable and searchable via a web interface like this web view of python-dev (a Mailman 3 list)
  • Archives of the project's chat conversations, using a public Zulip chat history like this public archive of Rust's Zulip chat or a browseable history of Internet Relay Chat conversations via a web interface like this web view of Freenode's #pypa logs

(Olivier Lafleur conversed with me on Twitter about how to do some portion of this using GitLab. Also, the Perceval project may be a good tool to consider for mailing list and chat archives.)

Access privileges: The learner would not only interact with the example project materials as a reader but also as a participant, moving through the three access levels described below. The instructor would be able to view a learner's instance, with administrator (Level 3) access, to assess the learner's actions.

  • Level 1: The learner starts with the same user privileges that a new user would ordinarily have -- they can read all the public mailing lists, chat histories, wiki, and bugtracker items, and file bugs.
  • Level 2: The instructor can promote the learner to the second access level, at which point they can (for instance) triage, label, and close bugs and pull requests/patches, edit the wiki, and post to public mailing lists.
  • Level 3: The instructor can promote the learner to the third (administrative) access level, at which point they can (for instance) browse and post to private mailing lists and chat channels, and use maintainer powers on the git repository (such as merging pull requests/patches).

Authentication: I imagine that dealing with authentication within the application could get sticky. My preferred approach:

  • As a signed-in platform user, the learner is automatically logged in to all the web applications within the instance, and cannot log out.
  • It is not possible to view an instance unless you are either the learner or instructor associated with that instance.

Multi-user access: Ideally, it would also be possible for an instructor to expand access so that a project can have multiple users (in other words, give Learner A access to Learner B's project instance), so that learners can engage in peer learning and group exercises. However, I expect that would lead to a much larger range of headaches, including Code of Conduct problems in interactions between learners, so -- in earlier versions of this tool -- I am fine with not having this functionality, and instead advising pairs and small groups to use screen sharing for group exercises.

End of life: At the end of the course, each instance would turn read-only for two weeks (to allow the learner to make notes, and to make local copies of any work they had done), and then the platform would delete the instance.

Thoughts? In particular, if you know of software that already does more than half of what I want, I'd like to know about it.

: Bad Startup Idea: You provide a set of songs that people want to sing together but don't have the skill and range to sing. We use machine learning to rearrange them into more singable versions.

Pricing: this is a monthly subscription, enterprise-licensed, with a minimum of 100 seats per customer.

Target market: companies that want to be just a bit like classic IBM, and religious congregations and schools without music directors.

Exit: sell to Spotify.

Filed under:

: Missing DIY-ish-ness:

Alexandra Rowland wrote that "The opposite of grimdark is hopepunk. Pass it on." (further thoughts). And when I think about punk, I think about DIY and imagining and making the structures that need to exist outside of government and outside of well-funded institutions, and I think about people directly helping each other overcome the problems of our lives.

I think of the New Orleans DSA's brake light clinic, and Kaitlin Marone's essay about how it works and why. I think of Freedom Schools and the Black Panther Party's free breakfast for kids and community medical clinics, and mutual aid.

Beautiful Trouble talks about the temporary version of this as "shame the authorities by doing their job" and notes:

Be clear about whether you want to make a temporary fix, or fix the problem for real. Sometimes what you actually want is to have the community solve its own problems in a way the state never could.

Right now I do not spend most of my work-and-volunteering time doing this kind of thing, either the more temporary or the more long-term version. I have a backlog of stuff I want to clear first, but if I can rearrange the pie chart of my attention so more of it is DIY/punk/grassroots stuff, I believe I will be happier. So this is a note to myself about that.

Filed under:

about Sumana Harihareswara

Archives by year, archives by category

RSS feed
Dreamwidth feed microblog
Mastodon feed
Twitter feed
Spam As Folk Art

Changeset Consulting
weblog powered by NewsBruiser
Bloggers' Rights at EFFSupport Bloggers' Rights

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.