Cogito, Ergo Sumana
Sumana oscillates between focus and opportunity

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


2021 July
MonTueWedThuFriSatSun
   1222334
567891011
121314152161718
19202122232425
262728293031 

5 entries this month.

Categories Random XML
Password:

[Show all]

You can hire me through Changeset Consulting.

Creative Commons License
This work by Sumana Harihareswara is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Permissions beyond the scope of this license may be available by emailing the author at sh@changeset.nyc.