Cogito, Ergo Sumana

picture of Sumana's head

Sumana Harihareswara's journal


: It Can Be Hard To Talk About Learning And Teaching: Copied from a comment I made on MetaFilter in a somewhat contentious thread about explicitly learning and teaching tacit knowledge:

Some fundamental assumptions I have about this topic, and about some opportunities and difficulties more generally when talking about learning and teaching:

It can be hard to accurately remember the experience of not having a skill once you have advanced sufficiently in it (this is per the Dreyfus model of skill acquisition) - not just that you once were a novice, but what your mental models were, what perceptual gaps you have since fixed, and other details.

Different people, learning different topics in different environments with different motivations, resources, different configurations of interpersonal support, different levels of time commitment available, at different underlying levels of maturity and self-efficacy/locus of control and and metacognition and skill in related domains and so on, will have different experiences of the process of learning (some will not even notice that we are learning at all!) and different memories/assessments of what worked. In some cases this will reflect genuinely different learning/teaching approaches; in some cases people will use different words to describe the same experience, or will have divergent conscious memories of the same basic experience.

Different people also TEACH in very different contexts; me coaching a friend through how to break down an overwhelming task list via videocall is different from a chess teacher demonstrating things on YouTube, or a Public Service Announcement on the radio about how to notice if someone's having a stroke, or a mentor letting their mentee shadow them at work for a day, or me blogging about how to use a particular PyPI feature, or a volunteer language tutor meeting a 5th grader once a week in a noisy afterschool room. And, again, different teachers will have different memories of what worked, as in the previous point.

Curiosity and the desire for competence and mastery exist in lots of domains - in institutional settings like school and work, but also in hobbies, sex, relationship skills, domestic skills such as cooking and repair, self-improvement, art, etc.

Researchers have learned some things about how learning works, and it is possible to read that research, or practitioner-aimed summaries of it, to learn ideas that can help us learn - and teach each other - better.

Some human cultures valorize learning/practice/study; some cultures (including some of the ones that valorize learning) are scornful of theory and research in pedagogy/androgogy, educational psychology, and related fields.

We have all learned things and we have probably - at least informally - taught other people things, and we can all usefully share experiences as long as we allow for potential confusion along the way.

Filed under:


: COVID-19: The Delta Variant, Better Masks, and Free Testing: I am concerned about COVID-19 trends; particularly if you are in the United States, you should be aware and make/modify plans accordingly. Some of this post is New York City-specific.

Background: The COVID case numbers in the US -- including in New York City -- are going up pretty steeply because of the Delta variant.

It looks like the Delta mutation has really changed the game -- not only with breakthrough cases of COVID affecting people who have been vaccinated, but causing severe illness among some vaccinated people, and causing significant illness in children. And it's now clear that not only are vaccinated people catching Delta, we can easily pass it on to other people.

This third big wave of COVID transmission is hitting the rest of the US worse than it's hitting the Northeast, but NYC's getting hit, too.

We can see Delta's effect in the coronavirus stats in New York City. The daily case rate per 100,000 people has gone up from under 5 in June to 23 now, and test positivity rate has gone up from under 0.5% in June to 2.7% in early August (more details here). Relatedly, about 94% of tested cases in NYC are Delta infections; if you catch COVID in New York City right now, overwhelmingly, you're likely to catch Delta. This isn't just NYC, of course; similarly, in Washington, DC, the daily case rate (per 100,000 people) has gone up from like 1 in June to 23 now, and test positivity rate has gone up from 1% in June to nearly 6%.

As schools and many workplaces move back to in-person interaction, and as the weather gets colder and people socialize indoors instead of outdoors, we should expect further transmission.

A commentator I follow recently advised everyone that "now is probably better than later in the year, for anything entailing risk of exposure, so react accordingly."

Two more things you should know about: better masks and free COVID testing.

Masks: In mid-2020 it was hard to buy N95-quality masks. Now it's easier. here's a blog post about where you can buy reliable-quality masks online, including proper N95s and P100s. At least as of a few weeks ago, they are available for sale online at not-onerous prices. I bought a P100 for use in particularly crowded and unventilated settings.

Free testing for COVID-19: You can get free high-quality molecular (PCR) testing in New York City through the city government-run hospitals and related testing sites. PCR tests are accepted by airlines, employers, etc. that want to see your negative results. Again, it's 100% free: "Walk-in testing is available at no cost to you at these NYC Health + Hospitals locations." And you can just walk in during their open hours. You do not have to make an appointment or "pre-register" - but you can do that online to save time filling out a bit of paperwork.

It is 100% free to everyone including the uninsured. They ask that, if you have an insurance card, please provide the card when you go to get the test. But you don't have to pay a co-pay or anything like that, and if you don't have an insurance card, then the city covers the cost. You do not pay anything.

About 90% of the time, you'll get the rest within 2 days. In case that's not fast enough, check out these Express sites where you are guaranteed a result within 24 hours of your visit. These are, again, molecular (PCR) tests, and are appointment-only. Scroll down to "Schedule Your Appointment" within https://www1.nyc.gov/site/doh/covid/covid-19-rapid-testing.page to make an appointment.

Wishing all of you as much health as possible.


: Low Availability: FYI: I have some obligations, starting this week and going through mid-September, that will take me offline a lot and otherwise occupy me; I will have low and intermittent availability. Please email if you want to reach me - https://www.harihareswara.net/ & https://changeset.nyc/#contact have my address - but I will probably be slow & terse in response.

I will probably be on social media very seldom. If you are currently waiting for me to answer you on something time-sensitive, please remind me if there is so I can try to get to it in the next week!

Also, in case you talk with me on Signal, my Signal safety number may change either in the next couple days or in late September.


: Some Novel Python Packaging/Distribution/Inspection/Installation Projects:

People who program in Python have an easier time hearing about package-related tools that have been around for a while and that are under the banner of the Python Packaging Authority, or that are commercially supported (this simplified diagram showcases a lot of them). And if you're looking for canonical guidance on what tools to use, check out packaging.python.org and tell your colleagues. A simplified diagram illustrating some of the important tools in Python packaging and how they relate to each other. On the left, end user tools (pip, conda, and pipenv) are on a computer. They draw information from cloud-based tools to the right: Warehouse (PyPI), bandersnatch, conda-forge, and Anaconda Cloud. Those in turn draw information from developer tools to the right: conda-skeleton, twine, setuptools, auditwheel, wheel, and packaging utils.

But -- since open source and open standards make things interoperable -- people also develop new tools for their specific needs in packaging, distribution, inspection, and installation, and sometimes I come across them when people announce them. I haven't tried any of these yet but here's a list of some stuff I noticed from the last few years.

Pypitoken, "A library for generating and manipulating PyPI tokens"

Thoth, "an enhanced server-side resolution offered to the Python community" (related: thoth-solver: "A tool for aggregating Python package metadata" and Dependency Monkey which "can compute all the possible combinations of packages that can occur in a resolved software stack and verify the given stack works well")

installer, "a low-level library for installing wheel distributions"

Dotlock "is a package management tool similar to pipenv, but with a different philosophy: instead of acting as a wrapper around pip, dotlock handles package resolution natively."

simpleindex provides "a lightweight PEP-503 private index/proxy" that declares routing rules to serve files from local directories. Also see pywharf.

Mach-nix "allows one to package Python projects and environments with Nix, requiring minimal knowledge of Nix.... Why would you want to use this tool? Reproducible builds with all build and run-time dependencies provided by the same package manager, regardless of whether they're Python dependencies or not."

The Python Packaging platypus mascot, a purple platypus happily springing out of a crowded cardboard box

ipwhl: a downstream repository in which "Each repo release will ensure a single version for a project for each platform, and one can use it to replace PyPI for both build and runtime dependencies for reproducibility." Per the repo for "interplanetary wheels (or floating cheeses)": "platform-unique, singly-versioned Python binary distributions backed by IPFS for security and reproducibility."

Python devirtualizer: "a preliminary implementation which manages shared packages so that only one copy of each package version is required."

pip-deepfreeze: "a small tool that aims at managing the dependencies of a Python application in a virtual environment."

And one more thing that is a PyPA project: the Python Advisory DB. After public discussion, there's a new community-owned repository of security advisories for packages published on https://pypi.org.

Filed under:


: Researching The Leadership Gap for Legacy Projects: I've given a lot of conference talks recently. As part of the PyCon US Maintainers' Summit in May, I delivered an eight-minute talk, "Researching the leadership gap for legacy projects". The video is now available, and here's the written version (I did not use slides).

Contents:

  1. Introducing the question/problem
  2. A little more about the problem I see
  3. Tooling hypothesis
  4. Corporate involvement hypothesis (hypotheses)
  5. New problems hypothesis
  6. Values and culture hypothesis
  7. How would we check?

Hi! I'm Sumana Harihareswara of Changeset Consulting and I'm not using any slides today, so you're free to take a few minutes to stretch, fold some laundry, what have you.

Introducing the question/problem

We have a pipeline for getting folks with coding skills to start or contribute to open source projects. That's great and I'm glad.

But I'm pretty sure we don't have a pipeline to recruit or grow contributors with leadership and management skills. A maintainer of a widely-used project *is* a manager, but since skilled managers are scarce in open source, we're seeing important projects stumble, or even wither, for lack of managerial work. (At least, this is what I've seen, and if you are seeing something to the contrary, I want to hear about it.) And I think this is a factor in the open source sustainability problem.

Knowing why this is happening can help us fix it. So in this talk I'll share a few hypotheses: one about the tooling we build and use, one about the effects of corporate involvement, one about changes in the problems we're trying to address, and one about values and culture. And I'll talk about how we would check whether any of these are true. I hope that considering this question will aid your efforts in focusing time and energy on things that will make a difference to project sustainability.

A little more about the problem I see

Founders start projects but are unprepared for the managerial demands of maintaining things that other people depend on. And, when legacy projects stagnate, contributors don't know how to take them over and stabilize them by solving common strategic, team, communication, workflow, and financial problems. Since they don't know how to rehab existing projects, individuals and orgs fork or start new ones, exacerbating fragmentation headaches.

So what hypotheses do we have?

Tooling hypothesis

Here's one. It used to be that, if you were going to run an open source project, you had to make the tooling platform yourself. You had to set up and administer, and maybe even build, your own bug tracker, source code repository, wiki, documentation site, and tarball release repository. Now these are hosted services -- GitHub, Read the Docs, PyPI. That means that it's easier to start a project, but that also means it's easier to start a project without learning a lot about the value and capabilities of these platforms along the way. And then project founders are less equipped to use those things well.

Corporate involvement hypothesis (hypotheses)

Here's another: it changes things when companies get more and more involved in open source, or hire people from open source. Maybe big companies hire the people who have managerial skills, and sometimes take them out of open source work entirely, and leave behind the ones who don't. Or maybe open source would be failing worse without corporate involvement, and corporate engagement is sort of subsidizing the poor management that we would otherwise see.

New problems hypothesis

Here's another: what got us here won't get us there. We're trying to address new or unsolved or undersolved problems and areas in open source -- distributed and cloud computing, getting telemetry while protecting user privacy, user experience design that can stand up to the best that industry can offer, diversity, equity, and inclusion, and so on. So, in general, open source contributors have grown a certain median level of leadership skill, but we're seeing cracks in the infrastructure because of the new loads they are trying to handle.

Values and culture hypothesis

Here's another: Let's talk about our culture and values, and how that affects contributor retention and promotion. We in open source recognize and promote people for the code they write, but we're bad at recognizing and valuing people for the managerial contributions they make -- we treat glue work https://noidea.dog/glue as invisible. So we don't attract or retain people with managerial skills or with the interest in growing in that direction.

And I'd like to thank Amye Scavarda for some thoughts about some of these hypotheses.

How would we check?

So. How would we check whether any of these are right? A few thoughts. We could talk with the scholars who were funded by the Ford and Sloan Foundation grants on critical digital infrastructure to get their thoughts. We could work with the CHAOSS people, the open source metrics working group, to construct a means to quantitatively measure maintainership actions happening within a project, and find out what other attributes it correlates with -- like whether or not those particular projects, or the domain areas they're in, were particularly influenced by companies. We could look for conversations from 15 years ago to check what our forebearers were saying, whether they thought this was likely to be a problem. We could try to offer explicit skills learning opportunities to contributors, to see whether people are interested, and whether we can find ways to retain the people who take those offers as open source maintainers.

My gut says that the source of the problem is a mix of the corporate involvement and values and culture hypotheses. So that's the basis I'm working from. I am working on a book outlining and teaching the skills open source software maintainers need, and teaching these skills to contributors who have never managed public-facing projects before. It'll be a textbook or a self-help guide for new and current maintainers of existing projects (what I call "brownfield projects", as opposed to "greenfield") and will focus on teaching specific project management skills (such as initial project audit, grantwriting, bug triage, and meeting facilitation) in the context of open source. If you go to changeset.nyc, under "resources" you'll find a free sample.

But let's talk during the Q&A session on Thursday. Which, if any, of these hypotheses ring true to you, and how could someone check whether you're right?

Thanks.


(1) : A Comedy Memory: I'm having trouble getting started on things I ought to do today, so here's a story I think I've never told here before.

In early 2011, I travelled to San Francisco for work, and one evening I went to an open-mic comedy night at BrainWash. I signed up for a slot -- maybe I got slot #4 or 5. And the first or second person to go up was just bad. He was not just misogynist or unfunny, but both -- it was as though he had forgotten that you will actually need punchlines to make people laugh and that demeaning women and fantasizing about drinking alcohol is insufficient. For instance: "I went to Wondercon and I saw a woman who said that on Saturday she dressed up as Batwoman and on Sunday she dressed up as Dark Phoenix, and I said, 'all anyone wants is [raunchy desire elided]'."

He finished his gross set and slouched out the door, and then several minutes later I went up, and said:

I'm in San Francisco because I just got a job with the nonprofit behind Wikipedia. So I've decided that this is the open mic that anyone can edit, and I'm going to edit a routine you heard earlier tonight.

And I then repeated the earlier guy's setups, but then added actual punchlines. For example, my punchline about the cosplayer was feigned shock at mixing DC and Marvel, and I turned a setup about soy milk that had ended with "you could make a White Russian out of that" into a joke about white vegans.

My audience loved it. I loved it. I told folks about it the next day and one of my colleagues said that I should just make that my M.O., going to open mics and improving upon an act that had come before. I said that I did not want to get beat up. But also I think it's a bit rare that someone else's comedic incompetence and my talent line up such that I can so immediately dunk on someone by spontaneously riffing on their work, like Mozart does to Salieri in Amadeus.

Filed under:


: Software Bill of Materials & the US Federal Government: In February, the United States's President Biden signed an executive order on the US's supply chains; he followed this up with an EO in May specifically concentrating on improving cybersecurity. To quote Tidelift's summary, "in essence, this order is a striking attempt to create a new global standard for cybersecurity that all organizations around the world will need to ensure their software supply chain meets or exceeds in the near future."

Because of the EO, the US's National Telecommunications and Information Administration requested comment "on the minimum elements for a Software Bill of Materials (SBOM), and what other factors should be considered in the request, production, distribution, and consumption of SBOMs". I heard about this thanks to Jacob Kaplan-Moss, who suggested the Python Software Foundation could share its open source perspective. So I led an effort to submit a comment on behalf of the Packaging Working Group of the PSF - thanks to Morgan Mayo (PSF Director of Resource Development) for some of the prose!

The Packaging WG comment, along with comments from 80+ other individuals and groups, are now up at the NTIA website. Check out Section II ("Background context about the Python packaging toolchain and ecosystem") for a simplified yet still confusing diagram. Section IV of our comment ("Infrastructure funding") is pretty short; for a longer treatment on a related topic, see Tidelift's comment "Software bills of materials are important—but they won't work at scale if we don't pay the maintainers".


: Monday Will Be Volunteer Responsibility Amnesty Day: Volunteer Responsibility Amnesty Day logo: a sun at a horizon A few months ago, in my talk "What Would Open Source Look Like If It Were Healthy?", I told a story of an overwhelmed open source software maintainer. Every solstice is a Responsibility Amnesty Day, and he uses one to say "Sorry, I need to stop doing this."

Sean maintains a lot of stuff, right?...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 [particular project] is just not where he wants to be putting his time, he needs to concentrate on fewer things that have higher priority to him.

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.

Several people really perked up at that idea. So now there's a website: https://www.volunteeramnestyday.net/.

my temporary logo: smiling stick figure next to a sunsetThe next solstice is Monday, June 21st, 2021. Maybe you should take a moment between now and then to list out what you're responsible for, so on Monday, you can announce that you're setting something down.


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

Intro

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.

Money

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.

Conclusion

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.


: 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

Contents:
  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:


about Sumana Harihareswara

Archives by year, archives by category


RSS feed
Dreamwidth feed
Identi.ca 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.