Cogito, Ergo Sumana

Categories: sumana | Conferences and Performances

Announcing or reporting on conferences I'm attending or performances I deliver


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

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

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:

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.

Filed under:


: 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!]

Filed under:


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

Details as they emerge on my talks page.

Filed under:


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

Filed under:


: MozFest 2021 Followup: Apply for Grants To Fund Open Source Work:

This session was in two parts:

  1. a fifteen-minute video (a remix of the session I delivered at PyOhio, with five additional minutes of material)
  2. a one-hour discussion

The additional material in the MozFest video (slides, rough script) included:

The discussion was lively and varied. We talked about several topics and shared resources, and wished there were a thorough aggregator of funding opportunities for open source work, bigger than the one that the PSF's Project Funding Working Group has put together.

Some funding opportunities people brought up:

And we discussed the question "how do you get a community going and solicit money when you don't have anything to show yet?" and the fear that people will steal one's ideas, and the problem of answering funders who ask you "how will you sustain this project after the funding ends?"

Some other resources people mentioned:

Thanks to everyone who watched or participated!

Filed under:


: MozFest 2021 Followup: How To Get A Project Unstuck:

This one-hour discussion session covered some of the same material as my Linux.Conf.Au 2021 lecture, on "How To Get A Project Unstuck -- And Fixing The Skill Gaps That Got Us Here" (outline and links; video).

Below are some session notes, including some of the live collaborative document we used to take notes during the discussion. I've removed individuals' and projects' names.

Case studies

Autoconf (Case study: rejuvenating Autoconf; also see how my upcoming book is helping Autoconf's developers decide what to do next)

Pipenv (Pipenv case study)

Asking participants about their projects

Principles of getting a project unstuck

Some premises I use in my work:

Five major areas where legacy projects get stuck. I need help with the names for these categories! (And of course sometimes combinations of problems crop up.)

  1. strategy, e.g., what work do we need to prioritize, and how urgent is it? what is our goal, and should this project exist (or should we decommission it)? has the team agreed on these things?
  2. team, e.g., do we have enough maintainers to do the essential work, and do we have up-and-coming contributors who can replace us as maintainers in the future? does everyone know who has what powers, or are some people confused about who has the power to do certain things? do we run into team workflow problems when different groups want to participate at different speeds? is there a malicious, offputting, or flaky person who needs handling? do we have the social processes we need to support the project and each other, like meetings, mentorship programs, and Requests for Comment?
  3. connection, e.g., who are our users and what do they need? are we listening to them? are we responding quickly enough to their concerns? do they have a way of listening to us? who are our partners and upstreams? do we talk to each other? do new contributors fall through the cracks?
  4. workflow and digital infrastructure, e.g., do we run automated tests on every patch? do new issues, patches, and discussions get interlinked so developers and users can easily follow up? are there bottlenecks or duplications in the platforms we use to respond to issues, review code, and discuss the project in general?
  5. money, e.g., do we have enough money to do what we want to do? have we developed plans or proposals to turn money into progress? can we persuade funders to give us money?

Thank you to a participant who suggested "interfacing" rather than "connection". I do like that better.

The sequence of steps for gaining credibility within a project and helping turn it around:

  1. Settling in (doing routine tasks that do not require much trust, assessing and earning credibility)
  2. Taking charge (doing things that require trust but that the group has already agreed needs to happen)
  3. Making change (modifying and adding social, digital, financial, and legal infrastructure)
  4. Passing leadership over to successors and leaving

This is the outline of my forthcoming book. My sampler ebook of Getting Unstuck: Advice For Open Source Projects, available for free download once you subscribe to my 1-10 times per year newsletter, includes that full outline.

Questions & discussion

What kinds of "stuckness" have you seen in FLOSS projects? I feel like I've seen 5 major areas where legacy projects get stuck (strategy, team, connection/interfacing, workflow, and money). Does that reflect your experience?

What circumstances make it easier or harder for projects to get unstuck?

(I was struck by how much easier it was for participants to come up with programmer-specific problems -- especially problems with onboarding new contributors -- than to remember and bring up people, money, and other problems. After all, most mature software projects have a backlog of patches awaiting review, and so making it easier for more new contributors to get onboarded is a less crucial bottleneck than widening the code review bottleneck, which is probably a team, workflow, and money problem.)

Do you know a stuck project? What support would you need to start getting it unstuck?

Plans for followup

I suggested that people form optional accountability pairs, to talk with each other regularly and help both stay motivated to get their project unstuck. Two people did pair up.

Filed under:


: Upcoming Talks in March and April: I'm planning to deliver four talks or sessions in the next several weeks.

MozFest 2021 (online, has already begun): one session tomorrow and one day after tomorrow! "How To Get A Project Unstuck" (discussion, 2021-03-09 21:15 CET/3:15pm EST), and "Apply for Grants To Fund Open Source Work" (skillshare, 2021-03-10 21:15 CET/3:15 PM EST).

GitHub OCTO Speaker Series (online): "What Would Open Source Look Like If It Were Healthy?", March 30, 2021, 1:30 PM EDT. This (ridiculously ambitious?) talk will be streamed live on Twitch.

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.

And: RailsConf 2021 (online, April 13-15): "How to Get a Project Unstuck," a talk.

I've updated my increasingly unwieldy talks page accordingly. (Redesign coming in a few months, to that plus the rest of this site.)

Filed under:


: Outline and Links for "How To Get A Project Unstuck" LCA Talk: Here's a brief outline, and relevant links, for the talk I'm about to give at Linux.Conf.Au: "How To Get A Project Unstuck -- And Fixing The Skill Gaps That Got Us Here". I am not presenting any slides.

Introduction

My consultancy is Changeset Consulting.

Stories

  1. Gathering info and helping decisions:

    WisCon

    Mailman (What was new in GNU Mailman 3.0, announcement of the Mailman 3.0 release)

  2. Gathering funding:

    Video, transcript, and slides for my PyOhio talk on applying for grants to fund open source

    "Problems and Strategies in Financing Voluntary Free Software Projects" by Benjamin Mako Hill

    Autoconf (Case study: rejuvenating Autoconf; also see how my upcoming book is helping Autoconf's developers decide what to do next)

  3. Nudging, prioritizing, and communicating:

    Pipenv (Pipenv case study)

A case study I didn't have time to discuss in this talk: Finishing the rearchitecture and deployment of PyPI.

The credibility and change sequence

This is the outline of my forthcoming book. My sampler ebook of Getting Unstuck: Advice For Open Source Projects, available for free download once you subscribe to my 1-10 times per year newsletter, includes that full outline. The basics:

  1. Settling in (doing routine tasks that do not require much trust)
  2. Taking charge (doing things that require trust but that the group has already agreed needs to happen)
  3. Making change (modifying and adding social, digital, financial, and legal infrastructure)
  4. Passing leadership over to successors and leaving

I may also refer here to "Software in Person", my article on how to make the most of synchronous developer events.

Why maintainers usually don't have these skills

Where maintainers come from, what we value and grow, and a lack of tools and practices to help learn and teach these skills.

Let's change that

Existing initiatives or resources to improve and teach these skills:

Ideas for further tools and practices to improve skills (this is where I mention possible improvements to GitHub's "saved replies" tool).

Conclusion

Thanks for watching and listening. I look forward to hearing your thoughts, so please contact me to let me know!

Edited Feb 5th to add: video is now up! And thanks to Nick Murphy, R. Fureigh, and Keffy R. M. Kehrli for being test audiences!

Filed under:


: Two Upcoming Sumana-Talks-At-You Events: Most urgently: You have just over 24 hours to back the Mermaids Monthly project on Kickstarter, supporting a fun, independent speculative fiction magazine for 2021. If you back at the $100 “Subscription, Pin, and Poetry” pledge level, you'll get invited to a special Zoom party where I'll perform stand-up comedy.

And: in late January, I'll speak for the first time at Linux.Conf.Au, on "How To Get A Project Unstuck -- And Fixing The Skill Gaps That Got Us Here". You'll come away from this talk with steps you can take, in the short term and in the long run, to address this for projects you care about. Ticket sales are now open for LCA (which will of course be a virtual convention). Buy a ticket if you'd like to see my talk live and participate in questions-and-answers!

This talk will draw from the same material as the book I'm writing on getting open source projects unstuck. I aim to teach the skills open source software maintainers need, aimed at working scientists and other contributors who have never managed public-facing projects before. And I hope to have more news about that project soon!

Filed under:


: Stand-Up Comedy Today: I'll perform 20 minutes of stand-up comedy about open source software today (Friday), 3:30-3:50pm PT, 6:30-6:50pm ET, at SeaGL [as I did at GUADEC].

Watch for free, no registration.

Filed under:


: Some Followups From LibrePlanet 2017: I see that back in March 2017, I made a draft of some followup notes for my LibrePlanet 2017 keynote "Lessons, Myths, and Lenses: What I Wish I'd Known in 1998" (schedule description, video, in-progress transcript). I'm going to barely annotate/format this and post it as more of a found artifact and less of a designed communications instrument.

Wampanoag people

The Infinite Wrench

Mel Chua, Alex Bayley, Ashe Dryden, Christie Koehler

Open Source Bridge 2012

Kevin Gorman & Chip Deubner

Geek Feminism

Hans Reiser

Jupyter, Library Simplified, Zulip & zulipbot & good code review, Software Carpentry (save a day of work a week for the rest of their working lives), Dreamwidth and dw-dev, Beautiful Soup, Archive of Our Own, GNU Mailman and what's new in Mailman 3

Seth Schoen

Yudhisthira

Joseph Reagle

Kannada

Vajra Chandrasekera

Filed under:


: Imaginary Book Club, and How To Run It: "Imaginary Book Club" is an improv-type session that's fun to run at a scifi/fantasy convention. It's a panel where each participant "reviews" a book that does not exist, and the other people riff on that. Julia Rios and I came up with the concept (origin) and it first ran at WisCon in 2011.

It's a lot of fun! In the past ten years it's become a bit of a WisCon tradition, and sometimes other cons run it too, as NASFiC just did. One attendee said that every con should hold a version of it because it's so fun. So I figured I'd write up how to run it.

Basic structure

I suggest 3-6 people, allotting at least ten minutes per person. The moderator can be a presenter or not, per time and inclination. Assuming a 50-minute panel with one moderator and four participants:

  1. Very short intro by moderator, explaining the premise to the audience, and explaining that from here on out, everything may be a lie --perhaps allowing one-sentence introductions from each panellist
  2. First book
    • Panellist 1 gives a description & review of a book: title & author(s), genre, premise/setting/idea, and their reaction -- 2-4 minutes
    • Other panellists react, pretending they have also read the book, and the group discusses the book, digressing into general history/litcrit/anecdotes etc. -- 5-6 minutes
    • Audience Q&A -- 1-3 minutes
  3. Repeat for Panellist 2
  4. Repeat for Panellist 3
  5. Repeat for Panellist 4
  6. Moderator ends the panel by lifting the veil of lies and thanking everyone

This worked pretty well over a videocall, in my opinion, as long as the moderator could see everyone's faces simultaneously (gallery/tile view).

Prep

Pick participants who enjoy bantering and thinking on their feet, and whose go-to quips don't tend to the demeaning.

If you've never seen the session before, watch bits of Julia Rios's video from WisCon 2011, with Sumana Harihareswara, Benjamin Rosenbaum, Ellen Klages, Liza Furr, and Richard Chwedyk:

  1. Part 1: Material Velour, Color Unknown (an anthology about fashion edited by John Joseph Adams), and the lost Oscar Wilde cyberpunk novel*
  2. Part 2: Trailer Gnome
  3. Part 3: Beneath Yellow Skies by Elizabeth Bear (a novel about sparkly dragons in Iowa)
  4. Part 4: The Arm With the Golden Man

A few days before the session, the moderator ought to send panellists a prep note, telling them the structure to expect, and suggesting they each start thinking of a fake book to review. My prep email for the panel this year included:

This is meant to be a fun session with a lot of improv and banter. I've run it before, and it works well if everyone prepares their fake book review ahead of time but DOESN'T tell the other panellists what they've come up with, so it's a surprise during the panel.

Sample ideas for fake books:

and noted: "If you'd like to see a sample video, https://www.youtube.com/watch?v=Mi0t0Z8Ubgc is this panel at a past WisCon."

If people need help thinking of fake books, I suggest "real author in a genre they never wrote in" or "fake collaboration between two real authors" to connect easily with the audience. And I'm not particularly rigid on "no one can know others' books ahead of time!" and sometimes people want to share and divvy up ideas, and that doesn't ruin things.

Gotchas Book cover: The Babysitters Club #12: Claudia and the New Robot, by Ann M. Martin. Claudia might give up the BSC -- and it's all the new robot's fault! [Cover has clearly been photo manipulated to show a robot outline over a girl's body.]

There's a fine line between lovingly mocking an author's quirks and being mean. Watch out and avoid the latter.

It's nice if the fake books are varied -- not all tie-ins, not all sex jokes, not all by similar authors. If you're presenting, you could prep two or three different books in advance to avoid this.

Panellists will end up pleasurably digressing into actual litcrit and anecdotes. As long as they're being entertaining, let them!

Some panellists will go all-out, making fake covers or writing fake chapters. Most won't. Both approaches work fine with the audience.

Audience participation will be a mix of attempted quips, successful quips, and pedantry. Use your moderator's discretion to gently redirect anyone who is trying to quip and not landing well.

Jokes from this year that I shall now inflict upon you

I briefly discussed an anthology of short stories sponsored by Big Pharma, which included:

And I discussed the recently unearthed Babysitters' Club book by Isaac Asimov, Claudia and the New Robot, 1988 (cover above). JOKE STARTS HERE: Claudia Kishi's older sister Janine develops a robot that can babysit, and wants it to join the club. I liked the babysitting diaries told from the robot's perspective, in fixed-width typeface, and enjoyed how the robot's Kid-Kit contained materials and plans for the babysitter to actually build a new kid.

The Babysitters' Club franchise in many ways plays to Asimov's strengths, as it's got a very strong repeating structure, what some might call a formula, but so do the Black Widowers mysteries, the Susan Calvin robot stories, and the Azazel stories. And this book had some of the most three-dimensional, well-rounded characters of Asimov's entire career, and I think it really stretched him to write almost entirely from the perspectives of girls. JOKE ENDS HERE

Go try it!

If you're running an sf/f con, try an Imaginary Book Club session! Tell me how it goes! And this structure probably also works for fake films, games, TV shows, foods, and more, as long as the audience is fans who will get your in-jokes.

And, speaking of fun improv sessions for conventions, here's how to run Slideshow Karaoke in case you want to try that too.

Filed under:


: Three Sessions at NASFiC This Weekend: I will speak on two panels at the virtual NASFiC (the North American Science Fiction and Fantasy Convention) 2020, this weekend:

  1. "Imaginary Book Club", Friday 21 Aug, 7pm-7:50pm ET: "Imaginary Book Club" is an improv-type session where each of us "reviews" a book that does not exist, and the other people riff on that. Ada Palmer, Mary Anne Mohanraj, and Julia Rios join me (I'm moderating) in this comedy panel.
  2. "Running SF/F Organizations", Sunday 23 Aug, noon-12:50pm ET: "Creators, directors, publishers, and nonprofit leaders discuss the trials and victories of running magazines, publishing companies, and other SF/F businesses and organizations. They discuss logistics, strategy, budgets, and the effects of gender and race on their experiences as leaders. And they share what they wish they'd known ten years ago." I'll be talking with Cheryl Morgan, Eileen Gunn, and Mary Anne Mohanraj, with Victor Raymond moderating.

I may also be in another session -- finding out now!

Also, at 2pm tomorrow (Friday), Leonard is delivering "How Game Titles Work" which emerges from work he did researching his novel Constellation Games:

In 2009, while writing a novel about alien video games, Leonard Richardson uncovered the rules of rhetoric and syntax underlying the titles developers give their games. By following these rules, he was able to create dozens of realistic-sounding fictional games from distinct alien cultures. Over the past ten years, video game developers in the real world have subverted and played with these rules, expanding what a game's title can say about the experience of play. In this presentation, Leonard goes over the rules and talks about how they've changed over time.

NASFiC is free to attend this year -- visit this "how to attend" page to get livestreaming and chat embedded in the webpage for any sessions you want to watch.

Filed under:


: Four Conferences In Three Days: I'm performing or speaking at, participating in or attending four different conferences/conventions online between July 24th and 26th. You can join me at no cost for all of them!

Going chronologically:

  1. GUADEC: Friday, July 24th, 21:00 UTC (5pm Eastern Time): I'll perform twenty minutes of stand-up comedy as part of the social events for GUADEC, the GNOME Users And Developers European Conference. This will be a bit like the stuff I've performed at AlterConf, Open Source Bridge, the Google Summer of Code Mentors' Summit, and so on. Yes, you can hire me to perform stand-up comedy at your tech conference, too.

    I'm also curious to watch talks on power management, principles of digital autonomy, freelancing tools, an open, programmable virtual assistant, rescuscitating a GNOME app, measuring and improving a project's environmental impact, and making videos.

    Register: for free! Watch live via BigBlueButton (in your web browser).

  2. EuroPython sprint: Saturday-Sunday, July 25-26, European time: Within EuroPython, I'll co-lead an online sprint where people can learn more about, and hack on, Python packaging tools.

    I unfortunately don't think I have time to attend the rest of the conference, but I'm looking forward to watching the videos of "Lessons from the Trenches: rewriting and re-releasing virtualenv" and "The Hidden Power of the Python Runtime".

    Register: for free, for a sprint-only ticket! Please register by July 23rd. Participate via Discord and via Zoom or Jitsi (I'm not clear on whether the sprints will use Zoom or Jitsi).

  3. CON.TXT: Saturday, July 25th, Eastern Time: I'll attend CON.TXT, a fan convention for people who enjoy talking about media, scifi/fantasy, fan fiction, fanvidding, etc. I'm looking forward to "Bring Your Fandom to Work", "Financial Crime for Fun and Profit", and the vidshows.

    Register: for free! Register by July 24th. Participate via Discord and Zoom.

  4. PyOhio: Saturday or Sunday, July 25th-26th, Eastern Time: I'll speak at PyOhio, delivering a pre-recorded ten-minute talk, "Apply for Grants To Fund Open Source Work".

    When I tell people about grants they could get to help fund work on open source software projects, sometimes they are surprised because they didn't know such grants existed. I share:

    This year, all PyOhio talks are 5 or 10 minutes. I'm also interested in talks on PySpark, livestreaming, Flask, "How the Python Software Foundation Fared Through the Impact of the Pandemic", managing your finances, mapReduce, and underappreciated gems of the Python standard library.

    Register: for free! Watch via YouTube. You don't have to register to watch the talks; PyOhio will stream them publicly over YouTube. You do have to register to participate in sprints and open spaces.

Please consider joining me! Probably not at all of them! That would be pretty difficult! I am curious how it will all work out myself!

Filed under:


: Trailer and Registration for Otherwise Auction:

You have till 8pm ET tonight -- so, about 6.3 hours from me publishing this -- to register for this year's WisCon if you want to attend the auction I'm hosting on Saturday night (watching via YouTube livestream). You can register for USD$0 if affordability matters to you.

The auction is a comedy show where you don't need to spend any money, but you can donate to support some worthy causes.

This Otherwise blog post about the auction includes a one-minute video trailer/preview, and a list of auction items.

I'll also speak on Sunday within a panel on the recent renaming of the Otherwise Award (blog post).

Filed under:


: WisCon and Otherwise Auction, May 22-25: I'm hosting the Otherwise Auction (formerly the Tiptree Auction) at WisCon the night of Saturday, May 23rd. It'll be a virtual auction within WisCon, and mostly, Earth currency will not be involved. You can register for this year's WisCon now to make sure you'll be able to watch via YouTube and participate/bid via the private Discord chat server. I'm not 100% sure yet what time the auction will be, but it will probably be 7:30-8:30 pm Central Time.

This morning I was talking to my mother about some prerecorded material I am working on for the show. I told her how nice it is to get to work with my friends on a small fun project, and to edit together these videos with their faces all next to each other. Mom understood and said: it's like tying flowers in a garland. And my face broke into a goofy grin. It so is.

Filed under:


(1) : MOSS Video, BSSw Honorable Mention, and The Maintainership Book I Am Writing:

Video

Mozilla interviewed me about the Python Package Index (PyPI), a USD$170,000 Mozilla Open Source Support award I helped the Python Software Foundation get in 2017, and how we used that money to revamp PyPI and drive it forward in 2017 and 2018.

From that interview, they condensed a video (2 minutes, 14 seconds) featuring, for instance, slo-mo footage of me making air quotes. Their tweet calls me "a driving force behind" PyPI, and given how many people were working on it way before I was, that's quite a compliment!

I will put a transcript in the comments of this blog post.

(Please note that they massively condensed this video from 30+ minutes of interview. In the video, I say, "the site got popular before the code got good". In the interview, I did not just say that without acknowledging the tremendous effort of past volunteers who worked on the previous iteration of PyPI and kept the site going through massive infrastructure challenges, but that's been edited (for brevity, I assume).)

This video is the first in a series meant to encourage people to apply for MOSS funding. I mentioned MOSS in my grants roundup last month. If you want to figure out whether to apply for MOSS funding for your open source software project, and you need help, ping me for a free 20-minute chat or phone call and I can give you some quick advice. (Offer limited in case literally a hundred people contact me, which is unlikely.)

BSSw

The Better Scientific Software (BSSw) Fellowship Program "gives recognition and funding to leaders and advocates of high-quality scientific software." I'm one of three Honorable Mentions for 2020.

The main goal of the BSSw Fellowship program is to foster and promote practices, processes, and tools to improve developer productivity and software sustainability of scientific code. We also anticipate accumulating a growing community of BSSw Fellowship alums who can serve as leaders, mentors, and consultants to increase the visibility of those involved in scientific software production and sustainability in the pursuit of scientific discovery.

Exascale Computing Project logoThat's why I'll be at the Exascale Computing Project Annual Meeting next week in Houston, so if you're there, I hope to meet you. In particular I'd like to meet the leaders of open source projects who want help streamlining contribution processes, growing more maintainers, managing communications with stakeholders, participating in internship projects like Google Summer of Code and Outreachy, expediting releases, and getting more out of hackathons. My consulting firm provides these services, and at ECPAM I can give you some free advice.

Book

And here's the project I'm working on -- why I received this honor.

In 2020, I am writing the first draft of a book teaching the skills open source software maintainers need, aimed at those working scientists and other contributors who have never managed public-facing projects before.

More than developer time, maintainership -- coordination, leadership, and management -- is a bottleneck in software sustainability. The lack of skilled managers is a huge blocker to the sustainability of Free/Libre Open Source Software (FLOSS) infrastructure.

Many FLOSS project maintainers lack management experience and skill. This textbook/self-help guide for new and current maintainers of existing projects ("brownfield projects") will focus on teaching specific project management skills in the context of FLOSS. This will provide scalable guidance, enabling existing FLOSS contributors to become more effective maintainers.

Existing "how to run a FLOSS project" documentation (such as Karl Fogel's Producing Open Source Software) addresses fresh-start "greenfield" projects rather than more common "brownfield", and doesn't teach specific project management skills (e.g., getting to know a team, creating roadmaps, running asynchronous meetings, managing budgets, and writing email memos). Existing educational pathways for scientists and developers (The Carpentries, internships and code schools) don't cover FLOSS-specific management skills.

So I'm writing a sequel to Karl's book -- with his blessing -- and I'm excited to see how I can more scalably share the lessons I've learned in more than a decade of leading open source projects.

I don't yet have a full outline, a publisher, or a length in mind. I'll be posting more here as I grow my plans. Thanks to BSSw and all my colleagues and friends who have encouraged me.

Filed under:


: Art of Python Seeking Organizers for 2020: In May, I chaired "The Art of Python", a festival of arts about programming that took place at PyCon North America. People presented short plays, monologues, songs, and a video remix that explored how it feels to program and play with Python.

I am very glad I did it! But I have to concentrate on other projects now.

I cannot be one of the co-organizers for "The Art of Python" at PyCon North America in 2020; I hope someone else steps forward to lead it so it can take place again. If you want to organize "Art of Python" at PyCon 2020, please submit a Hatchery proposal as soon as possible. The deadline for Hatchery proposals is January 3, 2020. If you are interested but need help to do it, post about that someplace public -- your blog, Twitter, etc. -- and tell me, and if I hear from multiple people, I'll put you in touch with each other.

To help: I have written up a retrospective and HOWTO document about "The Art of Python". It's in two parts: "Why I Did This" and "How I Did This".

As I say in there: I saw a lack. I was not and am not a professional playwright, performer, or festival planner. But I didn't have to be, and you don't either. You don't have to be a professional performer to show what you experience when you're programming -- you just need a stage, and I wanted to create the stage. And now we have. I hope the show goes on.

Thanks to Kim Wadsworth and Leonard Richardson for editing help.

Filed under:


: WisCon Activities: I'm on my way today to WisCon, the feminist science fiction convention. This'll be the tenth anniversary of my first!

I'm a panellist or performer for three sessions:

  1. "Ethics In The Good Place And Crazy Ex-Girlfriend", panellist, Friday 9:00-10:15pm, in Caucus.

    Fantastical US TV shows The Good Place and Crazy Ex-Girlfriend both explore what we owe to each other, and to ourselves. What ethical frameworks do they explore and seem to approve? How do the shows judge the appropriateness of self-sacrifice, the importance of pleasure, the choice to fix or leave a dysfunctional relationship, and other ethical issues? And how do they use fantasy to approach and consider these questions?

  2. Tiptree Auction: comedian and auctioneer, Saturday 7:30-9:30pm (probably more like 9pm), in Capitol/Wisconsin.

    It is totally fine to just turn up for 15 minutes of this and spend no money and laugh at my jokes and then go get dinner. But also all the money we raise goes to the Tiptree Award.

  3. "Imaginary Book Club", panellist, Sunday 10:00-11:15am, in Conference 4.

    Panelists each choose an exciting book from the last year to describe, and the group discusses them all. The catch: we made all of them up. This year, we might talk about Charlie Jane Anders's inspirational romance, a newly discovered YA dystopia by F. Scott Fitzgerald, G. Willow Wilson's entry in the Babysitter's Club series, and the 90s-nostalgia horror anthology I'll Be There for You(r Blood).

And I will be getting cool free clothes during the Gathering and going to the Dessert Salon and subsequent speeches so I may catch you there!

I am also attempting to meet MetaFilter acquaintances on Sunday night and to hang out with other farflung friends over the course of the next week. Here are some tips for contacting me and so on during the con.

Filed under:


: Rabbit Hole Interview(s): Recently, the Rabbit Hole developers' podcast interviewed me; we discussed open source sustainability, maintainership, sensationalism among bards who sang the Odyssey, how PyPI is like Wikipedia, and what we think is paranoid.

The interview continued into a second episode discussing PyCon and The Art of Python, my past talks and plays, Halt and Catch Fire, what conferences are for, and the feeling of giving a bad talk.

Thanks to Stride for providing rough transcripts along with the audio!

A listener punned on my username ("brainwane") to tell me, "loved your perspective and insight on the podcast ... for me, it was 'braingain'". Awww!

We recorded these episodes on 27 February. The 7:17-08:06 segment of the first one proved prescient:

David:... NPM does an audit of the packages and says, okay, like, "this version is flagged with a known vulnerability, you should upgrade this." And it will just hammer you with that [unintelligible], infinitely, until you handle it. But like, you know, that’s also a form of open source software, that we’re depending on to nudge us.

Sumana: Right, and then the question of, again, sustainability, of like, well, is NPM, as a venture-backed thing, right..... You stay in this industry long enough and VC sounds like a dangerous term for anything you’re actually going to depend on.

David: Yeah, like the idea of something like PyPI going away. Like, I don't know what I would do? I would just have to find all of the binaries on a website? And like host my own... thing? Or...?

Stride released this episode on 19 March. On 22 March, surprising staff and at least this observer, npm laid off a number of workers on its open source team.

Please note that you can make a one-time or recurring donation of any amount to the Python Software Foundation that specifically supports PyPI and related packaging and distribution work (disclaimer: the PSF currently pays Changeset Consulting to work on PyPI and packaging), and that your org can sponsor the PSF for as little as USD$500 per year. And I am, as always, speaking here entirely for myself and not for any of my clients or colleagues.

Filed under:


: PyCon NA, !!Con, and WisCon: I'm back in New York City, and preparing to travel a bit; May is my big conference month this year.

I'll start the month at PyCon North America in Cleveland, Ohio, practically the whole conference, 1-9 May. I'm co-organizing The Art of Python, an arts festival -- several short plays, plus a fanvid and live music -- the night of Friday, May 3rd. And during the sprints, 6-9 May, I'll be concentrating on the world of Python packaging and distribution, e.g., PyPI.

I'll go home to New York City, then go to !!Con 11-12 May, where I am not organizing or speaking or suchlike.

And then I'll be at WisCon in Madison, Wisconsin, for the whole convention, 24-27 May plus a little extra on either side. I will once again be the comedy auctioneer for the auction on Saturday night that benefits the Tiptree Award -- if you have something to donate to the auction, please let us know by 15 May. I may not make it to the Floomp or the vid party. I will probably be on a few panels; several panels are still seeking volunteer panellists (sign up by 19 April). I do plan to be at the Gathering and the Dessert Salon (heads-up, changes to Dessert Salon entry flow).

If you're going to be at any of these events, perhaps we can share a beverage! If you want to make sure that we do that, let's actually set up at least a tentative appointment soon, so I can put it in my calendar.

I will be more responsive to emails and text messages than to social media while at these conferences, and in particular, I may see mentions and direct messages on Mastodon but I probably won't see mentions or direct messages on Twitter. Also, I am pretty forgiving about being called mispronunciations of my name, but here's a recording in case you want help -- I also respond to "Vikki" which is the fake name I use with strangers at restaurants. And I will probably not hug you unless we know each other well.

Filed under:


: Prior Art: On Friday, May 3rd, in Cleveland, Ohio, USA, as part of PyCon North America, I'm leading an arts festival called "The Art of Python". The call for proposals is open now, deadline 28 February. And I'd love your help not just proposing work, and helping publicize this, but helping me understand what's new and not new about this.

"The Art of Python" will focus on narrative, performance, and visual art. We intend to encourage and showcase novel art that helps us share our emotionally charged experiences of programming, particularly but not necessarily in Python. We hope that, by attending, our audience will discover new aspects of empathy and rapport, and find a different kind of delight and perspective than might otherwise be expected at a large conference. We are interested in how fictional narrative, visual and performance art, and different presentation formats can make different kinds of teaching and representation possible.

There's more about this at my co-organizer Erty Seidohl's blog post, including an invitation to also propose your "not-talks" to !!Con starting in a few days. "The Art of Python" is seeking your proposals now and the deadline for submissions is 28 February. And if you've never written a play and want guidance so you can write your first, we have a guide and sample scripts!

So why did I call this entry "Prior Art"? Because I'd like to know more about past artworks about the experience of making technology at technology conferences that have resonated with you, especially fictional narratives and live performances.*

A few of our inspirations are recent works of mine, like "Pipeline", my critique video about the tech industry, and the plays I made with Jason Owen ("Python Grab Bag: A Set of Short Plays" and "Code Review, Forwards and Back").

I must be following in footsteps I don't know. So: Who else did full-on plays at tech conferences? I wouldn't be surprised if someone did it a decade before me and I never knew. Go ahead and comment on this GitLab issue to share your comments.

Thanks to Erty and to Brendan Adkins for co-organizing "The Art of Python" with me! Thanks to PyCon's Hatchery program for new PyCon events, which makes this festival possible! Thanks to Jackie Kazil for the festival name! (My codename was "Spectacle!" which is probably misleading and less accessible.)

* A footnote here about music and webcomics and Halt and Catch Fire and whatnot grew enough that it'll be its own entry.

Filed under:


(2) : I Welcome Your Point Of View On Whether I Am An Alto: I love listening to and singing a lot of labor and folk songs. Like, the highlight of my week a little while back was when a friend got out his guitar and learned to play "Union Maid" and three of us sang it and harmonized together in a living room. I have an untrained voice but I enjoy using it.

A little while later, I saw a friend mention on social media that she would be participating in The Mobile Hallelujah, organized by Make Music New York, and asking whether anyone wanted to join her.

In this participatory choral program open to all interested vocalists, producer Melissa Gerstein and conductor Douglas Anderson team up to bring George Fredric Handel's "Hallelujah Chorus" -- from his Messiah oratorio, the oldest continuously performed piece of Classical music -- out of the concert hall and onto the streets of NYC.

I said sure! And then, on a bus on the way to the Metropolitan Museum of Art last night, I looked at the sheet music and listened to the guide track, and, uh, NEWS FLASH, HALLELUJAH FROM HANDEL'S MESSIAH IS WAY HARDER TO LEARN THAN YOUR AVERAGE PETE SEEGER TUNE, this surprises no one. It's a gorgeous piece because it's got a bunch of interconnected cause-and-effect stuff! It's not an eternal golden braid, but it's a very complicated four-minute Rube Goldberg machine! And it's not like I am actually good at sticking to a vocal part during a round or even a simple harmony (I'm an alto I think? I've never actually checked) if there are other people near me singing another part. I sort of gravitate to whatever I'm hearing loudest and end up chameleon-ing into that, like a panicky manager throwing their hands up and saying nobody ever got fired for buying IBM soprano.

But hey, New York City has a ton of great singers, so I figured they'd carry the thing and I would just, you know, add oomph for the bits I could figure out.

So I practiced a bit and got to the point where I could, most of the time, keep track of where I was in the sheet music. I think a bindi-wearing woman whisper-singing "Hallelujah" is in, at most, like the thirtieth percentile of weirdness achieved during that hour on New York City Transit. I arrived on the museum steps, tried and failed to find my friend, and saw people assembling -- like 8 sopranos, 20 altos, 1 bass, and an alto or two who said "I guess I'll try to sing tenor" -- and we sorted ourselves out and then the maestro gestured for us to start.

And I found out that a lot of us were muddling along! It was not like "dozens of people who know their parts very well, plus Sumana". It was .... you know how you can call food "authentic" or "rustic" to say "it was lumpy and the presentation was unpolished but I loved it because of who made it and how they made it and how I relate to them"? It was like that. We blurred a bunch of the cool counterpoints and whatnot instead of hitting them precisely, we didn't enunciate great -- whatever. We hit that last Hallelujah and I looked up from the sheet music and people on the sidewalk had gathered to listen, and they clapped! We'd done it! It was a fun thing to try, a fun challenge, and maybe I'll try to get better at singing in chorus, because that is fun!

My friend had been running late and turned up right at that last "Hallelujah". Ah well! We hung out afterwards anyway. Maybe I will see if she wants to sing some Woody Guthrie with me sometime.

I have been enjoying various bits of music recently aside from Handel's elaborate celebration of a divinity that I don't particularly believe in:

Filed under:


: Collection: A few deliverables!

At RubyConf Los Angeles 2018 last month, I co-presented "Code Review, Forwards and Back" with Jason Owen, and now video is up.

"Intersectional sustainable crop science, and GIFs" is my newest MetaFilter post -- it's an inventory of informative & funny Twitter threads by Dr. Sarah Taber, loosely grouped by topic (soil and ecologies, specific plants and animals, common misunderstandings about food/ag/econ, "family farms", organizing/politics and sexism, being an ex-Mormon, food safety, regulations, testing, and management systems, management skills and the economics of agriculture in the US, and oppressions therein, skill, culture, capitalism, land prices, slavery, white supremacy, and ag history in the US).

Taber explains: "My goal with this account is to beef up the "sustainable ag" info available for consumers w some science & general business mgmt info. The general public is incredibly frustrated with ag's slow rate of change. Someone should talk about the very real reasons change isn't instant....Some of the reasons won't reflect nicely on our ag institutions. Oh well. I'm not gonna tell folks it's all good, because it's not. We need to back up this "no BS" reputation by actually cutting the BS. If you feel weird about someone airing your dirty laundry, wash it." Also: "put info out there, see what kind of feedback it got, & thereby find out where the general knowledge level is at with ag these days". (Thread Reader)

When I want to read someone's old threads, I find it so difficult to dig through old tweets through the Twitter interface, so I thought this might be a useful resource to make and share.

Relatedly, I recently thought to look at some of my oldest microblog posts, and enjoyed a few from 2009:

Argued w/Leonard re Queen's "Don't Stop Me Now" yesterday: if you're "going at the speed of light," can you *have* a temp? (200°, F implied)...I fear quibbling with the metaphor of an atom bomb satellite rocket ship to Mars constitutes stopping the singer now, despite express wishes

"Life's not a math textbook. The answers aren't gonna be in the back of the book." "But at least, unlike me, you're doing the problem sets."

"Indie 101, do stuff that defeats your own purpose. Reflexively, routinely." -John Darnielle -- quoting from about 3:00 to 3:15 in the "Leaving Home" track in this 2007 concert recording.

Filed under:


: Credits and References for "Python Grab Bag: A Set of Short Plays": Today, at PyGotham 2018, Jason Owen and I presented "Python Grab Bag: A Set of Short Plays".* We predict a videorecording will be on PyVideo in the next few weeks. [Edited 26 November to add: Video is up.]

[Edited 7 February to add: The script is now available, licensed CC-BY.]

Credits

This session is the latest in my line of non-traditional tech talks. I conceived of the idea. Thanks to Jason Owen for working on it with me - thinking of play topics, editing, rehearsing! I wrote almost all of these plays and he made them better. And, as we mentioned in "The Unvarnished Truth", we spent upwards of USD$1650 out of our own pockets on this session -- paying our director and audiovisual assistant, buying props, and renting rehearsal space. Probably closer to $1850 when it all comes in.

Thanks to:

References

In from import import import,** we mention Allison Kaptur's blog post on import and PyCon 2014 talk "Import-ant Decisions", and George London's PyGotham 2017 talk, "import madness # how to implement mergesort from scratch using only import statements".

In "A Proposal for Explaining PEPs", we briefly mention PEPs 347, 385, and 481, which moved Python development from CVS to Subversion to Mercurial to Git, and PEP 8000, which is working on governance questions.

In "GNU Mailman: A Pythonic Playlist", I discuss the history of Mailman release names.

"Generators: Taste the Freshness" draws on this explanation of generators in Python.

"This Is How We Do It" draws on this history of The Zen of Python, and on Larry Wall's "Perl, the first postmodern computer language".

"If Shakespeare Wrote Incident Reports" starts with a quote from Act I, Scene 5 of Hamlet.

"Code Review: Fast Forward and Back" is a summary of "Code Review, Forwards and Back" which originally appeared at PyGotham 2017 (video).

"Be A Better Bureaucrat (The Intellectual argparse Play)" mentions James C. Scott's Seeing Like A State and David Graeber's The Utopia of Rules: On Technology, Stupidity, and the Secret Joys of Bureaucracy.

"The End (Of 2.7) Is Near (feat. Jason as Guido van Rossum)" starts by quoting Guido van Rossum's March 10, 2018 email to python-dev. It ends with a short clip from "Get Over It" by OK Go.

Slides & similar

"The Relief of Reuse (The Colorful argparse Play)" has a slide partway through, reading: "Jason switches to the robust, standardized, easy-to-use argparse library".

In general it's hard to see the slides on the videorecording, so here are the slide decks for "from import import import", "A Proposal for Explaining PEPs", "If Shakespeare Wrote Incident Reports", and "When The Old Was New".

In "Things We Don’t Say At The Daily Standup Meeting", the voiceover recording (kind of hard to hear on the recording) is us saying:

I don't understand what you just said.
I've done the same thing every day this week but I'm trying to find different words for it.
I can't concentrate on my work and I don't anticipate that changing till, best case, January 2021.
I feel like I got nothing done yesterday.
I am beyond stuck. I am drowning and I need help.

* Announcement, context, late-September reflections.

** For reference, in case the PyGotham 2018 site ever disappears, the play titles were:

  1. The Unvarnished Truth
  2. from import import import
  3. WHAT’S the DEAL with CLIENTS?
  4. A Play Entirely Full of Monty Python References
  5. A Proposal for Explaining PEPs
  6. GNU Mailman: A Pythonic Playlist
  7. Soup, Scrape, Sweep
  8. Generators: Taste the Freshness
  9. This Is How We Do It
  10. Cookie For Your Thoughts
  11. If Shakespeare Wrote Incident Reports
  12. Code Review: Fast Forward and Back
  13. When The Old Was New
  14. Things We Don’t Say At The Daily Standup Meeting
  15. The Relief of Reuse (The Colorful argparse Play)
  16. Be A Better Bureaucrat (The Intellectual argparse Play)
  17. Speaking Python
  18. The End (Of 2.7) Is Near (feat. Jason as Guido van Rossum)
[Edited to add on 26 November] and the play ordering was:
  1. GNU Mailman: A Pythonic Playlist (#6)
  2. Things We Don’t Say At The Daily Standup Meeting (#14)
  3. A Proposal for Explaining PEPs (#5)
  4. The End (Of 2.7) Is Near (feat. Jason as Guido van Rossum) (#18)
  5. WHAT’S the DEAL with CLIENTS? (#3)
  6. from import import import (#2)
  7. A Play Entirely Full of Monty Python References (#4)
  8. The Relief of Reuse (The Colorful argparse Play) (#15)
  9. Speaking Python (#17)
  10. Generators: Taste the Freshness (#8)
  11. When The Old Was New (#13)
  12. The Unvarnished Truth (#1)
  13. This Is How We Do It (#9)
  14. If Shakespeare Wrote Incident Reports (#11)
  15. Cookie For Your Thoughts (#10)
  16. Be A Better Bureaucrat (The Intellectual argparse Play) (#16)
  17. Soup, Scrape, Sweep (#7)
  18. Code Review: Fast Forward and Back (#12)
  19. thank-yous
Filed under:


(1) : Code Review Play at RubyConf, and Think Tank Fiction:

Jason Owen and I will co-present "Code Review, Forwards and Back" at RubyConf in Los Angeles, November 13-15 2018. We'll update and slightly lengthen the version we performed at PyGotham last year. If you'll be at RubyConf, consider watching our one-act play:

Your team's code review practices cause ripple effects far into the future. In this play, see several ways a single code review can go, then fast-forward and rewind to see the effects -- on codebase and culture -- of different code review approaches.

The setting: an office conference room. The characters: a developer, who's written a chunk of new Ruby code, and a team lead, who's about to review it. The code is not great.

See a fast-paced montage of ways things can go. Recognize patterns from your past and present. Learn scripts for phrasing criticism constructively. And laugh.

I've been doing a lot of theater-inflected conference presentations recently. I came up with the ideas for "Code Review, Forwards and Back" and "Lessons, Myths, and Lenses: What I Wish I'd Known in 1998" and "Python Grab Bag: A Set of Short Plays" (more details on all of these on my Talks page).

In some sense this is unsurprising, as I'm a programmer and public speaker who has dabbled in the more creative performing arts my whole life. As a child I had small parts in school* and community** theater, and my sister and I wrote and performed in some number of long skits for Indian-American association get-togethers (there was a lot of No Big Deal family-based practice here, as with writing and public speaking in general). I have also been willing to sing in public really quite out of proportion to my actual singing ability for a very long time. And I got all right at stand-up comedy and at comedy auctioneering.*** So I have started to bring those skills into my conference presentations, and am interested in how spectacle, fictional narrative, and different presentation formats can make different kinds of teaching and representation possible.

Someone else thinking about the value of storytelling in conference talks is Maria Farrell, who posted at Crooked Timber about that and about "think-tank fiction" (fictional stories/scenarios, sometimes composites of real situations and sometimes future projections, reflecting on and demonstrating the effects of particular policies and trends).

I find several of Farrell's reflections resonate with me, about the "quality of atmosphere" that obtains when you start telling a story at an event where it's unusual to do so, and:

...people at all-day tech events are really, really glad to just relax and have stories told to them. News flash. And actual stories, with, hopefully, meanings heading off on different trajectories, not TED anecdotes driving to One Big Lesson...

I hope Farrell can come to !!Con or a similar event sometime, to see how it nurtures some similar experiences.

There must be a bunch of talks like this and now my cataloguing fingers are itching. As Bruce Sterling wrote in "User-Centric":

To: the Team Coordinator
From: the social anthropologist
Subject: Re: *****Private message*****

Fred, people have been telling each other stories since we were hominids around campfires in Africa. It’s a very basic human cognition thing, really.

My colleague Erik Möller did a talk like the ones Farrell mentions at Wikimania 2013, "Ghosts of Wikis Yet to Come: Three Stories of Wikimedia's Future" (video). And I think Tom Scott's scifi shorts and story-style talks, and the "Slaughterbots" video from Ban Lethal Autonomous Weapons, are worth checking out as exemplars.

I also love related "our technology will make this future possible/likely!" narratives like AT&T's 1993 "Connections" video. (The AT&T Archives page pointed me to this collection of similar concept videos I totally want to see, made by Ameritech, Motorola, Sun, NEC, etc. Natalie Jeremijenko and Chris Woebken collaborated on a 2009 montage I haven't watched yet, and there's a 2014 followup -- looking forward to diving in.)


* Not always onstage -- the first bit of project management I ever did was stage management. I fuzzily remember running a puppet show in elementary school, and officiously checking off attendance using a clipboard (oh how important I felt!) for some middle school thing.

** Perhaps most memorably: Rudy, Rudolph the Red-Nosed Reindeer's nerdy little sister, in "The Night Before The Night Before Christmas" at a local YW/MCA. I actually had lines in this role! To demonstrate Rudy's bookishness, the script had her say aloud, apropos of nothing, "O is for oxygen," "N is for nitrogen," "C is for carbon", and so on. In retrospect this dialogue has more verismilitude than I would like to admit.

*** And of course this feels completely normal to me, because, you know, you only have your own one life, and your own life has a way of becoming the yardstick rather than the judged.

But a great swathe of programmers and other technologists don't think of writing or putting on or starring in a small play as No Big Deal. Many haven't ever memorized lines. And sometimes I forget that, if you've taken a storytelling workshop and served as a dramaturg for someone's one-woman show, and you're a programmer who gets to speak at conferences like PyCon and FOSDEM, you're unusual. Your intersection of skillsets is rare.

And one of the intuitions that's helped me develop my career is that I can provide unique value where the intersection of my skillsets is rare.

Filed under:


: "Python Grab Bag: A Set of Short Plays" Accepted for PyGotham 2018: Fresh from the waitlist onto the schedule: Jason Owen and I will be performing "Python Grab Bag: A Set of Short Plays" at PyGotham in early October. If you want to come see us perform, you should probably register soon. I don't yet know whether we'll perform on Friday, Oct. 5 or Saturday, Oct. 6.

(The format will be similar to the format I used in "Lessons, Myths, and Lenses: What I Wish I'd Known in 1998" (video, partial notes), but some plays will be more elaborate and theatrical -- much more like our inspiration "The Infinite Wrench".)

To quote the session description:

A frenetic combination of educational and entertaining segments, as chosen by the audience! In between segments, audience members will shout out numbers from a menu, and we'll perform the selected segment. It may be a short monologue, it may be a play, it may be a physical demo, or it may be a tiny traditional conference talk.

Audience members should walk away with some additional understanding of the history of Python, knowledge of some tools and libraries available in the Python ecosystem, and some Python-related amusement.

So now Jason and I just have to find a director, write and memorize and rehearse and block probably 15-20 Python-related plays/songs?/dances?/presentations, acquire and set up some number of props, figure out lights and sound and visuals, possibly recruit volunteers to join us for a few bits, run some preview performances to see whether the lessons and jokes land, and perform our opening (also closing) performance. In 68 days.

(Simultaneously: I have three clients, and want to do my bit before the midterm elections, and work on a fairly major apartment-related project with Leonard, and and and and.)

Jason, thank you for the way your eyes lit up on the way back from PyCon when I mentioned this PyGotham session idea -- I think your enthusiasm will energize me when I'm feeling overwhelmed by the ambition of this project, and I predict I'll reciprocate the favor! PyGotham program committee & voters, thank you for your vote of confidence. Leonard, thanks in advance for your patience with me bouncing out of bed to write down a new idea, and probably running many painfully bad concepts past you. Future Sumana, it's gonna be ok. It will, possibly, be great. You're going to give that audience an experience they've never had before.

Filed under:


: Open Source Bridge: I'll be at the last Open Source Bridge today (in fact, Changeset Consulting is a sponsor), in case you want to wave hi.

Filed under:


: Request: Donate To the Tiptree Award Auction: The James Tiptree, Jr. Literary Award encourages the exploration & expansion of gender, and holds a fundraising auction at WisCon each year. I'm the auctioneer, which is a pretty fun form of community service, and serve on the Tiptree Motherboard. We're seeking donations of objects to be auctioned -- handcrafts, books, memorabilia, games, and art, especially with scifi/fantasy or feminist elements, are welcome.

I would personally love to get some donations this year of types I haven't yet seen:

  1. Games of all sorts -- board games, card games, indie games, video games (we could auction off a Steam code or a USB stick)
  2. Handmade blank books
  3. Art commissions, e.g., "I will draw a portrait of you"
  4. DVDs or CDs of feminist media, e.g., a The Middleman box set
  5. Your secret recipe for a dish you consider wowzers

Some items I'll auction live from the stage. Some, people will buy directly from a cashier, at the Gathering on Friday afternoon or from the Direct Sale table at the auction. Some, folks will bid on via a silent auction throughout the con. And a few, we'll auction online. I wrote last year about what an award does, and the reflections I've seen from winners of the Tiptree Awards and Fellowships tell me those honors are doing the job -- encouraging creators and fans to expand how we imagine gender -- and by donating to the auction, you're supporting that.

The auction will be Saturday night, May 26th, and will be about 90 minutes long. If you want to come and you're local to Madison, you can buy a day pass at the door (just to attend WisCon on Saturday) for about $25. And it's totally fine to come to the auction just to enjoy the show, and not to buy anything.

Please feel free to signal-boost this, and if you're donating please fill out the form by May 15th. Thank you.

Filed under:


: 2017 Sumana In Review: Four years ago, during my first batch at the Recurse Center, every day I'd write in a little notebook on the subway on my way home, jotting down a few bullet points about what I had learned that day. I found it helped in a variety of ways, and the keenest was that on bad days, reviewing my notes reminded me that I was in fact progressing and learning things.

On any given day in 2017 I often did not feel very happy with my progress and achievements and how I was using my time. I fell ill a lot and I was heartsick at the national political scene and current events. It is genuinely surprising to me to look back and take stock of how it all added up.

Adventures:

I went hiking in Staten Island and in the Hudson Valley. I got back on my bike and had some long rides, including on a canal towpath in New Jersey and over the Queensboro bridge. (And had my first accident -- a car in my neighborhood rear-ending me at a traffic light -- and thankfully escaped without damage or injury.) I learned how to bake bread. I got to meet Ellen Ullman OMG. And I tried to travel less than I had in previous years, but I still had some fine times in other places -- notably, I had a great time in Cleveland, I witnessed the total solar eclipse in Nashville, and I visited Charlotte, North Carolina (where, among other things, I visited the NASCAR Hall of Fame).

Community service:

I did some of the same kinds of volunteering and activism that I'd done in previous years. For instance, I continued to co-organize MergeSort, participated in a fundraising telethon for The Recompiler telethon, signal-boosted a friend's research project to get more participants, and helped revitalize a book review community focusing on writers of color. Also, I served again as the auctioneer for the James Tiptree, Jr. Literary Award fundraising auction at WisCon, which is a particularly fun form of community service. The Tiptree Award encourages the exploration & expansion of gender. I wrote this year about what an award does, and the reflections I've seen from winners of the Tiptree Awards and Fellowships tell me those honors are doing the job -- encouraging creators and fans to expand how we imagine gender. This year I also deepened my commitment to the Tiptree Award by accepting the organization's invitation to join the Tiptree Motherboard; I am pleased to have helped the award through a donation matching campaign.

But the big change in my community service this year was that I tried to prioritize in-person political work. I called, emailed, and wrote postcards to various government officials. I participated in my local Democratic Club, including going door-to-door petitioning to get my local city councilmember onto the ballot for reelection.

And I found that I could usefully bring my technologist perspective to bear on the city and state levels, especially regarding transparency in government software. I spoke to my local councilmember about my concern regarding public access defibrillator data (the topic that led me to file my first-ever Freedom of Information Law requests, for government health department records) and this inspired him to sponsor a bill on that topic. (Which is now filed as end-of-session partly because of the limbo in potentially getting PAD data from NYC's open data portal -- I need to send an email or two.) I was invited to speak to a joint committee of the New York State Assembly on the software side of our forensics labs, and got particularly interested in this aspect of due process in our criminal justice system, publicizing the issue in my MetaFilter posts "'maybe we should throw an exception here??'" and "California v. Johnson". I testified before the Committee on Technology of the New York City Council on amendments to our open data law (I didn't prep my public comment, so this text is reconstructed from memory; video), and then spoke before the same committee on an algorithmic accountability measure (and publicized the bill, especially keeping the Recurse Center community apprised as best I could). And I did research and outreach to help ensure that a state legislature hearing on protecting the integrity of our elections included a few researchers and activists it wouldn't have otherwise.

In 2018 I want to continue on this path. I think I'm, if not making a difference, making headway towards a future where I can make a difference.

Work:

This was by far Changeset Consulting's busiest year.

I had a mix of big projects and smaller engagements. First, some of the latter: I advised PokitDok on developer engagement, with help from Heidi Waterhouse. For Open Tech Strategies, I wrote an installation audit for StreetCRM. And, working with CourageIT, I came in as a part-time project manager on a government health IT open source project so the lead developer could focus more on architecture, code, and product management.

Some larger and longer projects:

Following a sprint with OpenNews in December 2016 to help write a guide to newsrooms who want to open source their code, I worked with Frances Hocutt to create a language-agnostic, general-purpose linter tool to accompany that guide. "The Open Project Linter is an automated checklist that new (or experienced but forgetful) open source maintainers can use to make sure that they're using good practices in their documentation, code, and project resources."

I spent much of the first half of 2017 contracting with Kandra Labs to grow the Zulip community, helping plan and run the PyCon sprint and co-staffing our PyCon and OSCON booths, running English tutoring sessions alongside Google Summer of Code application prep, and mentoring an Outreachy intern, along with the usual bug triage, documentation updates, and so on. We wrapped up my work as Zulip's now such a thriving community that my help isn't as needed!

From late 2016 into 2017, I've continued to improve infrastructure and documentation for a Provider Screening Module that US states will be able to use to administer Medicaid better (the project which spurred this post about learning to get around in Java).

And just in the last few months I started working on two exciting projects with organizations close to my heart. I'm thrilled to be improving HTTPS Everywhere's project workflow for developers & maintainers over the next few months, working with Kate Chapman via Cascadia Technical Mentorship (mailing list announcement). And, thanks to funding by Mozilla's open source grants program and via the Python Software Foundation, the Python Package Index -- basic Python community infrastructure -- is getting a long-awaited overhaul. I'm the lead project manager on that effort, and Laura Hampton is assisting me. (Python milestone: my first time commenting on a PEP!)

Along the way, I've gotten a little or a lot better at a lot of things: git, bash, LaTeX, Python (including packaging), Sphinx, Read the Docs, Pandoc, regular expressions, CSS, the Java ecosystem (especially Gradle, Javadocs, Drools), the Go ecosystem, Travis CI, GitHub Pages, Postgres, sed, npm Linux system administration accessibility standards, IRC bots, and invoicing.

Talks And Other Conferences:

This year, in retrospect, instead of doing technical talks and expository lectures of the type I'm already good at, I played with form.

At LibrePlanet 2017 I gave the closing keynote address, "Lessons, Myths, and Lenses: What I Wish I'd Known in 1998" (schedule, video, in-progress transcript). I tried something aleatoric and it worked pretty well.

At Penguicon 2017 I was one of several Guests of Honor, and spoke in several sessions including "Things I Wish I'd Known About Open Source in 1998" (which was different from the LibrePlanet version, as intended) and "What If Free and Open Source Software Were More Like Fandom?" (further links).

Then, at PyGotham, Jason Owen and I co-wrote and co-starred in a play about management and code review: "Code Review, Forwards and Back" (video on YouTube, video on PyVideo, commentary).

I also attended Maintainerati and led a session, attended !!Con, worked a booth for Zulip at OSCON, attended PyCon and helped run Zulip's sprint there, and co-sponsored a post-PyGotham dinner.

Other Interesting Things I Wrote:

I did not write this year for magazines; my writing went into this blog, MetaFilter, Dreamwidth, microblogging, and client projects, mostly. I also wrote an entry for a local business competition (I didn't make it very far but I'm glad I did it, especially the finance bits) and started two book proposals I would like to return to in 2018.

I've mentioned already some of the posts I'm happy about. Some others:

"On Noticing That Your Project Is Draining Your Soul" (every once in a while someone emails me and mentions that this has helped them, which means a lot)

"How to Teach & Include Volunteers who Write Poor Patches" (12 things you can do)

"Inclusive-Or: Hospitality in Bug Tracking", a response to Jillian C. York and Lindsey Kuper.

I turned part of "Some posts from the last year on inclusion" into "Distinguishing character assassination from accountability", a post about pile-on culture and callout culture where I pulled out quotes from 11 writers on how we take/charge each other with responsibility/power within communities.

I loved Jon Bois's 17776 and discussed it with other fans on MetaFilter, and then, to try to understand its amazingness better, wrote "Boisebration", collecting links to fiction and nonfiction by Bois about class, feminism, aging, sports, politics, wonder, education, & art (and 17776 precursors/callbacks).

I found out about Robert E. Kelly, like so many did, when his kids crashed his BBC interview, then collected some links in a MetaFilter post about his writing on Korea, US foreign policy, international relations, and academia.

I wrote up a bit about "1967's most annoying question for women in Catholic ministry" on MetaFilter to signal-boost another Recurser's cool project.

I enjoyed the learning and the plot twist in "The programmer experience: redundancy edition", in which I discovered a useful resource for Form 990 filings and learned to use the Arrow library for Python date-time manipulation. And was grateful to Pro Publica.

And I made a few jokes on social media I particularly liked:

yesterday, was trying to explain virtual environments/containers/VMs to a friend and said "they range from Inception-style fake computers to putting a blanket on the floor and pretending it's lava"

and

today a friend and I explained leftpad & Left Shark to someone and I began sketching out a hypothetical HuffPo piece connecting them
We habitually crowdsource infrastructure from, expect unsupportedly high levels of performance from unsuspecting participants -> popcorn.gif

Public notice I received:

I got some public attention in 2017 -- even beyond the Guest of Honor and keynote speaker honors and my amazing clients -- that I would like to list, as long as I'm taking an inventory of 2017.

I rode the first revenue ride of the new Q train extension in Manhattan and really loved the art at the new 72nd Street MTA stop. A journalist interviewed me about that on video and my experience got into the New York Times story about the opening.

Presenters at the code4lib conference said their project was specifically motivated by my code4lib 2014 keynote "User Experience is a Social Justice Issue" (written version, video). I was honored and humbled.

And -- this is out of place but I need to record it -- as someone who knew Aaron Swartz, I consented to be interviewed by artists working on a play about him, and so someone briefly portrayed me (as in, pretended to be me and repeated my words aloud) in that play, Building a Real Boy.

Finally, Hari Kondabolu looked at the English Wikipedia page about him, much of which I contributed, and was amazed at how thorough it was. So that was awesome and I was proud.

Habits:

I got on Mastodon as part of my effort to improve how I use social media. I started using a new task tracker. I got back on my bike, and got somewhat into a habit of using it for some exercise and intra-city travel. A new friend got me into taking more frequent photos and noticing the world I'm in. Two new friends caused me to look for more opportunities to see musicians I love perform live.

Watched/listened:

I consumed a fair bit of media this year; didn't get into new music but enjoyed music podcasts "I Only Listen To The Mountain Goats" and "Our Debut Album". I did some book and reading reviews and will catch up to other 2017 reading sometime vaguely soon.

Leonard's film roundups & TV spotlights are a good way to see or remember most of what I saw in the last few years. TV highlights for me for 2017 are The Good Place, Jane the Virgin, The Great British Baking Show (which led me to write a tiny Asimov fanfic), Steven Universe, and Better Call Saul; I also saw Comrade Detective and Yuri!!! On Ice. Films I'm really glad I saw: The Big Sick, Schindler's List, Get Out (I fanned in MetaFilter Fanfare), In Transit, A Man For All Seasons, Hidden Figures, and Lemonade -- and a rewatch of Antitrust.

Social:

I made a few new friends this year, most notably Jason Owen and Mike Pirnat. My friends Emily and Kris got married and I got to hold up part of the chuppah for them. I took care of some friends at hard times, like accompanying them to doctor's visits. I got to see some friends I rarely see, like Mel Chua and Zed Lopez and Zack Weinberg, and kept up some old friendships by phone. My marriage is better than ever.

This year I shall iterate forward, as we all do.

Filed under:


: Video of Our PyGotham Play: You can now watch the 22-minute video of the play I discussed last month. "Code Review, Forwards and Back", co-written by and co-starring Jason Owen and me, directed by Jonathan Galvez.

Thanks to:

We were happy to hear people say things like I'm new to the industry, and this helped me learn things to watch out for or I used to be that reviewer and I'm trying not to be anymore or My name is Randall and I never hear my name in fiction and it was nice to hear you say my name or I don't code at all but this is a marvelous management parable. Indeed, code review is just a particularly visible moment where you can see the effects of an organization's culture and processes. Too execution-focused (the right hand doesn't know what the left hand is doing)? Too alignment-focused (we're taking so much time deliberating and gaining consensus that we can't make forward progress on the mission)? Too lax, or too superficial, in enforcing rules? Our play can't dive into every scenario but it's a start. And -- the most frequent comment we got from happy attendees -- it was a change of pace (no slides!).

We're revising the play and submitting this a few other places; once it's run its course, we'll be posting the text of the script online.

Filed under:


: Code Review, Forwards And Back: This Friday, at PyGotham, Jason Owen and I are co-presenting "Code Review, Forwards and Back". This is not a standard technical conference talk. It's a 25-minute play, basically a one-act.

The setting: an office conference room. The characters: a developer, who's written a chunk of new Python code, and a team lead, who's about to review it. You'll see the code. It's not great.

What happens if the reviewer waves it through, or lets conflict aversion get the best of them? What if the reviewer says it should be "better" but doesn't articulate how? What if the review is abrasive, or nitpicky, or laid-back? What if the reviewer rewrites the code right there and then? And if we fast-forward to the same team years later, how has this code reviewing style affected the quality and evolution of the codebase, and the team's culture, skill and sustainability?

See a fast-paced montage of ways things can go. Recognize patterns from your past and present. Learn scripts for phrasing criticism constructively. And laugh.

Or, to put it another way, it's Run Lola Run but about code review.

I was getting advice about this from a friend who's both an actor-playwright and a senior developer, and I may as well tell you what I told him, about why I want to do this. I have artistic and educational reasons.

Artistically: it's frustrating to me that there's such a limited range in how we persuade and teach each other in sessions at technical conferences. Most commonly I see conferences with lots of lectures, panel discussions, and live tool demonstrations. Those aren't very interactive, and so I welcome conferences who bring some variety into the mix on the axis of interactivity, such as hands-on workshops and trainings, and birds-of-a-feather discussion sessions. But also, we could be learning a lot more about spectacle from the giant field of endeavor that is all about entertaining people who are watching you perform on a stage.* We encapsulate wisdom as, e.g., songs and cartoons whose entertainment value helps us value and retain their lessons; Jason and I are interested in seeing how theater can do things a lecture can't do, can be like a demo of behavior, while talking about tech.

And educationally: especially when it comes to the emotionally fraught art of code review, the medium of theater seems like a promising way to encourage empathy in the viewer. Code review is a moment of great vulnerability, an opportunity for courage and healthy conflict. We only know ways to be if we can imagine them. Jason and I hope this play illustrates a few ways we can be.

So we're preparing that. I hope it goes all right.


* No actual stage in the conference room where we'll be performing. But, you know. Figurative stage.

Filed under:


(2) : Transparency And Accountability In Government Forensic Science: Sumana Harihareswara next to public hearing noticeIn February, I learned that the New York State Assembly was planning a public hearing on government oversight of forensic science laboratories, and then was invited to offer ten minutes of testimony and then answer legislators' questions. This was a hearing held jointly by the Assembly Standing Committees on Codes, on Judiciary, and on Oversight, Analysis and Investigation and it was my first time speaking in this sort of capacity. I spoke on the importance of auditability and transparency in software used in devices the government uses in laboratories and field tests, and open source as an approach to improve these. And I testified to the efficiency, cost savings, security, and quality gains available by using open source software and by reusing and sharing open source software with other state governments. Here's a PDF of my testimony as written, and video and audio recordings are available as is a transcript that includes answers to the legislators' questions. It is a thrilling feeling to see my own words in a government hearing transcript, in that typeface and with those line numbers!

As I was researching my testimony, I got a lot of help from friends who introduced me to people who work in forensics or in this corner of the law. And I found an article by lawyer Rebecca Wexler on the danger of closed-source, unauditable code used in forensic science in the criminal justice system, and got the committee to also invite her to testify. Her testimony's also available in the recordings and transcript I link to above. And today she has a New York Times piece, "How Computers Are Harming Criminal Justice", which includes specific prescriptions:

Defense advocacy is a keystone of due process, not a business competition. And defense attorneys are officers of the court, not would-be thieves. In civil cases, trade secrets are often disclosed to opposing parties subject to a protective order. The same solution should work for those defending life or liberty.

The Supreme Court is currently considering hearing a case, Wisconsin v. Loomis, that raises similar issues. If it hears the case, the court will have the opportunity to rule on whether it violates due process to sentence someone based on a risk-assessment instrument whose workings are protected as a trade secret. If the court declines the case or rules that this is constitutional, legislatures should step in and pass laws limiting trade-secret safeguards in criminal proceedings to a protective order and nothing more.

I'll add here something I said during the questions-and-answers with the legislators:

And talking about the need for source code review here, I'm going to speak here as a programmer and a manager. Every piece of software that's ever been written that's longer than just a couple of lines long, that actually does anything substantive, has bugs. It has defects. And if you want to write code that doesn't have defects or if you want to at least have an understanding of what the defects are so that you can manage them, so that you can oversight them (the same way that we have a system of democracy, right, of course there's going to be problems, but we have mechanisms of oversight) -- If in a system that's going to have defects, if we don't have any oversight, if we have no transparency into what those instructions are doing and to what the recipe is, not only are we guaranteed to have bugs; we're guaranteed to have bugs that are harder to track down. And given what we've heard earlier about the fact that it's very likely that in some of these cases there will be discriminatory impacts, I think it's even more important; this isn't just going to be random.

I'll give you an example. HP, the computer manufacturer, they made a web camera, a camera built into a computer or a laptop that was supposed to automatically detect when there was a face. It didn't see black people's faces because they hadn't been tested on people with darker skin tones. Now at least that was somewhat easy to detect once it actually got out into the marketplace and HP had to absorb some laughter. But nobody's life was at stake, right?

When you're doing forensic work, of course in a state the size of New York State, edge cases, things that'll only happen under this combination of combination of conditions are going to happen every Tuesday, aren't they? And the way that the new generation of probabilistic DNA genotyping and other more complex bits of software work, it's not just: Okay, now much of fluid X is in sample Y? It's running a zillion different simulations based on different ideas of how the world could be. Maybe you've heard like the butterfly effect? If one little thing is off, you know, we might get a hurricane.

Filed under:


: PyCon & WisCon: I just updated my "Talks" page -- I'll be at PyCon May 19-25, to represent Zulip at a booth and then to help run the Zulip development sprint. I will likely also have a new zine to share!

And then I'll fly straight from there to Madison for WisCon. I am not on any panels at WisCon this year but I'm the auctioneer for the auction benefiting the Tiptree Award. This year's auction includes a signed first edition hardcover of Octavia Butler's novel Wild Seed, an "Elect Alison Hendrix" pin from Orphan Black, an art print of "Aswang, at Night" by M Sereno, and a bunch more.

(As much as I love Open Source Bridge, I won't be there this year, and I won't be at Worldcon 75 (Helsinki) either, in case you're wondering.)

Filed under:


: OSCON, For a Single Day: I'm going to be at OSCON in Austin, Texas to represent Zulip in the Open Source Alley tomorrow (Thursday) 10am-4:30pm. Please consider coming by and getting a demo, or just talking with us about Python 3, mypy, and how we help new contributors (especially those who have a hard time setting up development environments on their own machines).

Filed under:


: Upcoming Talks: I happened upon the New York state Assembly's website last week,* and noticed an upcoming hearing about "Government oversight of forensic science laboratories" (PDF), hearing oral testimony by invitation only. I wondered: Who's on the list of witnesses? And will any of them talk about the danger of closed-source, unauditable code used in forensic science in the criminal justice system?

I followed up, and we got me, plus Rebecca Wexler, the author of that piece, invited to speak. We're testifying tomorrow, Wednesday, February 8th, in New York City. In preparation, I'm conferring with Karen Sandler of Software Freedom Conservancy (who was slotted to speak but now can't) and with acquaintances who work in government forensic labs.

I did speech and debate in high school so in some sense I have been preparing for this for twenty years.

A little further off:

Next week, I will participate in the WONTFIX Cabal (Maintainerati) unconference for open source maintainers on February 15, 2017, in San Francisco, California, USA.

I will give the closing keynote address at LibrePlanet, a free software conference, March 25-26, 2017, in Cambridge, Massachusetts, USA. Tentative title: "Lessons, Myths, and Lenses: What I Wish I'd Known in 1998."

I will be one of the Guests of Honor at Penguicon, an open source and science fiction convention, April 28-30 2017, in Southfield, Michigan, USA.


* via Lauren Sperber's blog post about "the New York State Reproductive Health Act to get abortion removed from New York State's Penal Code"

Filed under:


: Two OSCON Conversations, And A Trip Report Between Them: Conversation the last night of OSCON, reconstructed from memory:

"So, Neil Young --"
"The singer-songwriter?"
"Yeah."
"Man, what a white guy name."
"Are you impugning Neil Young? That man sells organic eggs at the farmer's market in my hometown!"
"Are you sure they're organic? You sure he doesn't just get them from Sysco?"
"Sysco doesn't even sell organic eggs."
"Uh, actually Sysco does sell organic eggs."
"Yeah right. I bet it's, like, orgänic, with an umlaut, so it can get around the FDA rules on calling things 'organic'."
"Yeah, and that's also how they get around the rules on Appellation Contrôlée."
"Anyway, Neil Young has a son who really likes model trains, and so he does model train stuff, and he actually has multiple patents related to model trains."
"Patents? Is he part of the Open Invention Network? Is this a defensive patent portfolio against Big Train?"
"You mean Supertrain?"

picture of Sumana in front of a steam train in Melbourne, AustraliaIn honor of late-night wackiness, I have not actually fact-checked whether Neil Young has any model train patents, or whether he or Sysco sell organic eggs. Caveat lector et caveat emptor.

My last visit to OSCON was in 2011, when I had worked for the Wikimedia Foundation for under a year, and wanted to build and strengthen relationships with the MediaWiki and PHP communities. I remember not feeling very successful, and thinking that this was a conference where executives and engineers (who in many cases are not terribly emotionally passionate about open source) meet to hire, get hired, and sell each other things.

These days, it turns out, OSCON is basically aimed at me! Because I am an executive trying to sell my services (e.g. get hired on an as-needed basis) to engineers and executives who make or depend on open source -- including the passionate ideologues, the burned-out used-to-be-passionate folks, the pragmatists, and all manner of other types. Changeset Consulting was novel, relevant, and interesting to approximately everyone I spoke with. Also, in the intervening five years, I've grown in skill, stature, reputation, and network. So I had something interesting to say, and O'Reilly accepted a talk proposal of mine for the first time. I saw scores of acquaintances, friends, peers, and colleagues in the halls and session rooms this year; I know and am known, which helps me feel at home.

I'm grateful to Audra Montenegro at O'Reilly Media for her speaker support. She worked with O'Reilly to cover my flight plus two hotel nights in Austin, making it possible for me to attend OSCON. She and other O'Reilly folks paid and worked with White Coat Captioning to provide CART (live captions) for my talk, at my request. And I was concerned that talking about inessential weirdnesses and inclusivity in open source upped my risk of harassment, so she arranged for some extra security for me. I'm also grateful to Andy Oram, my session chair, for his careful pre-conference prep (including checking on my pronouns -- she/her, thanks!), and for running a written Q&A session at my request.

I shall carry with me several memories of this OSCON, such as:

But here's a conversation that I particularly find stays with me. I was on the expo floor, talking with an acquaintance, and a stranger joined our conversation. I'll anonymize this recollection and call him Cyclopes.

He heard about the consulting services I offer, which focus on short-term project management and release management for open source projects and for companies that depend on them -- maintainership-as-a-service, in short.

Cyclopes: "Can you come to my company and tell us that the way we're doing deployments is all wrong, and tell them we should do it my way?"
Sumana: "Well, if your company hires me, and I assess how you're doing deployments and I think it's wrong, and I agree with the approach you want, then yes."
Cyclopes: "Great!" [explains his preferred deployment workflow, with justification, and says that it's like bashing his head against a brick wall for him to try to convince the rest of his company to do it]
Sumana: [lightheartedly] "So it sounds like what you really want is more a sockpuppet or an actor! Which might be cheaper!"
Cyclopes: "Hmmmm! You know, that is kind of what I want!"
[we three jest about this]
Sumana: "But, in all seriousness, like, you could go aboveboard with this. You know, you have options -- fraud and deception, or actually trying to persuade the other people in your org .... or, this is a wild guess, have you kind of burned bridges by being really abrasive, and now they won't listen to you?"
Cyclopes: "Yeaaaaaaaaah that might be what's happened."
Sumana: "OK! That totally happens and you weren't the first and you won't be the last."
Cyclopes: "Like, I've sent some pretty flame-y emails."
[acquaintance nods in sad agreement; we are all sinners here]
Sumana: "Oh man, the emails I've sent. I am so embarrassed when I look back. But you can come back from this. You really can. If you demonstrate to those people in your org that you really want to repair those relationships with them, they will respond. Like, if you say to them, 'I know I burned bridges before, I'm sorry about it, can we talk about this problem,' and you actually try to listen to them about what they need and what their context is, what they're worried about and what problems they're trying to solve, they will work with you, so you can figure out something that works for everybody. There's a book about this, about negotiation, that's a really short, quick read, it helped me a lot: Getting to Yes by Fisher and Ury."
Cyclopes: "Let me write this down." [notes book title and author on the back of my business card]
Sumana: "There you go, some free consulting for you. It's totally possible."
Cyclopes: "I think I could use that, I'm ripe for that kind of personal transformation in my life."
Sumana: "Great! Please, seriously, let me know how it works out."

Memory is unreliable, but I cannot forget the speed of my diagnosis, nor that this guy literally said that he was ripe for the kind of personal transformation I was prescribing. It's no model train patent but I think I'm happy anyway.

Filed under:


: Two Conferences, Three Talks: Last week I took the train to Atlanta to speak at the Great Wide Open conference, which I'd never visited before. I particularly appreciated the chance to share my lessons learned with an audience that was diverse on gender, ethnic, speciality, and other dimensions, the cozy and delightful speakers' dinner, and the organizing team's consistent approachability and helpfulness. If Atlanta is an easy trip for you, and if you're interested in growing your skills in free and open source software, I suggest you consider attending next year.

I spoke on underappreciated features in HTTP, and my slides are available as a PDF. If you're going to be at PyCon North America in Portland, Oregon this year, I'll be presenting a more Python-specific version of this talk there on May 31st. If neither of those works for you, check out the video of the very similar "HTTP Can Do That?!" presentation I delivered at Open Source Bridge last year.

Then I rode the train north to Boston; along the way I got to converse with a neat seatmate, a military veteran who loves taking family walks after dinner to play Ingress with his kids. Awww. His son loves Minecraft so I got to recommend the NYPL historical-map Minecraft worlds to him.

Then, this past weekend, I attended my first LibrePlanet. What a lovely time I had! I saw rockin' talks by people whose thoughts I was already eager to hear, and I met dozens of people who are working on promising projects like a nonprofit, transparent search for the web and a browser extension that lets users share their internet connections with people whose connections are censored. I especially commend the organizers for running the conference, including the video streaming, using entirely free and open source software! Since we knew that all of us are dedicated to software freedom as a goal in itself and towards a more just and a freer world, we could have complex conversations that advanced beyond first-contact advocacy and into details and long-term planning.

I spoke on "Inessential Weirdnesses in Free Software"; the written remarks I spoke from are now available as a text file. It is not the most legible page in the world, because I will be further revising this talk before presenting it at OSCON in Austin, Texas, on May 18th.

I also delivered a somewhat impromptu five-minute lightning talk, "What is maintainership? Or, approaches to filling management skill gaps in free software". I've now posted the textual version of that talk.

LibrePlanet participants told me they really liked both my talks; the latter especially spurred some to talk with me about potential contracts with my firm, Changeset Consulting, which was a big morale injection since I'm definitely seeking leads and referrals right now.

Thanks to both LibrePlanet and Great Wide Open for having me speak! I've also updated my Talks webpage with links to my upcoming appearances. My calendar's open after August, in case you know anyone looking for a speaker who makes a lot of jokes and gestures.

Filed under:


: What Is Maintainership?: Yesterday, at my first LibrePlanet conference, I delivered a somewhat impromptu five-minute lightning talk, "What is maintainership? Or, approaches to filling management skill gaps in free software". I spoke without a script, and what follows is what I meant to say; I hope it bears a strong resemblance to what I actually said. I do not know whether any video of this session will appear online; if it does, I'll update this entry.

What is Maintainership?

Or, approaches to filling management skill gaps in free software

Sumana Harihareswara, Changeset Consulting
LibrePlanet, Cambridge, MA, 20 March 2016

Why do we have maintainers in free software projects? There are various different explanations you can use, and they affect how you do the job of maintainer, how you treat maintainers, how and whether you recruit and mentor them, and so on.

So here are three -- they aren't the only ways people think about maintainership, but these are three I have noticed, and I have given them alliterative names to make it easier to think about and remember them.

Sad: This is a narrative where even having maintainers is, fundamentally, an admission of failure. Jefferson said a lot of BS, but one thing he said that wasn't was: "If men were angels, we would have no need of government." And if every contributor contributed equally to bug triage, release management, communication, and so on, then we wouldn't need to delegate that responsibility to someone, to a maintainer. But it's not like that, so we do. It's an approach to preventing the Tragedy of the Commons.

I am not saying that this approach is wrong. It's totally legitimate if this is how you are thinking about maintainership. But it's going to affect how your community does it, so, just be aware.

Skill: This approach says, well, people want to grow their skills. This is really natural. People want to get better, they want to achieve mastery, and they want validation of their mastery, they want other people to respect their mastery. And the skill of being a maintainer, it's a skill, or a set of skills, around release management, communication, writing, leadership, and so on. And if it's a skill, then you can learn it. We can mentor new maintainers, teach them the skills they need.

So in this approach, people might have ambition to be maintainers. And ambition is not a dirty word. As Dr. Anna Fels puts it in her book Necessary Dreams, ambition is the combination of the urge to achieve mastery of some domain and the desire to have your peers, or people you admire, acknowledge, recognize, validate your mastery.

With this skills approach, we say, yeah, it's natural that some people have ambition to get better as developers and also to get better at the skills involved in being a maintainer, and we create pathways for that.

Sustain: OK, now we're talking about the economics of free software, how it gets sustained. If we're talking about economics, then we're talking about suppply and demand. And I believe that, in free software right now, there is an oversupply of developers who want to write feature code, relative to an undersupply of people with the temperament and skills and desire to do everything else that needs doing, to get free software polished and usable and delivered and making a difference. This is because of a lot of factors, who we've kept out and who got drawn into the community over the years, but anyway, it means we don't have enough people who currently have the skill and interest and time to do tasks that maintainers do.

But we have all these companies, right? Companies that depend on, that are built on free software infrastructure. How can those with more money than time help solve this problem?

[insert Changeset Consulting plug here]. You can hire my firm, Changeset Consulting, to do these tasks for a free software project you care about. Changeset Consulting can do bug triage, doc rewriting, user experience research, contributor outreach, release management, customer service, and basically all the tasks involved in maintainership except for the writing and reviewing of feature code, which is what those core developers want to be doing anyway. It's maintainer-as-a-service.

Of course you don't have to hire me. But it is worth thinking about what needs to be done, and disaggregating it and seeing what bits companies can pay for, to help sustain the free software ecology they depend on.

So: sad, skill, sustain. I hope thinking about what approach you are taking helps your project think about maintainership, and what it needs to do to make the biggest long-term impact on software freedom. Thank you.

Filed under:


: What Should We Stop Doing? (FLOSS Community Metrics Meeting keynote): "What should we stop doing?": written version of a keynote address by Sumana Harihareswara, delivered at the FLOSS Community Metrics Meeting just before FOSDEM, 29 January 2016 in Brussels, Belgium. Slide deck is a 14-page PDF. Video is available. The notes I used when I delivered the talk were quite skeletal, so the talk I delivered varied substantially on the sentence level, but covered all the same points.

Photo of me at FLOSS Metrics meeting, public domain by ben van't ende, https://photos.google.com/share/AF1QipMGh90Jfl8uVKH3U-e4CGF93i-vbHvhjbWVOvkn3ZlOeBAoc5PX_n_augA9v-cvPQ/photo/AF1QipNmQJdbqw2TrhcX6HuooqUuQmLfFbRkn73QW_Aq?key=NXFqUUVqdlN6MWdQSFdSNEFBSVFKajRpQVVQNnpnI'd like to start with a story, about my excellent boss I worked for when I was at the Wikimedia Foundation, Rob Lanphier, and what he told me when I'd been on the job about eight months. In one of our one-on-one meetings, I mentioned to him that I felt overwhelmed. And first, he told me that I'd been on the job less than a year, and it takes a year to ramp up fully in that job, so I shouldn't be too worried. And then he reminded me that we were in an amazing position, that we would hear and get all kinds of great ideas, but that in order to get anything done, we would have to focus. We'd have to learn to say, "That's a great idea, and we're not doing it." And say it often. And, he reminded me, I felt overwhelmed because I actually had the power to make choices, about what I did with my time, that would affect a lot of people. I was not just cog # 15,000 doing a super specialized task at Apple.

So today I want to talk with you about how to use the power you have, in your open source projects and organizations, and about saying no to a lot of things, so you can focus on doing fewer things well -- the Unix philosophy, right? I'll talk about a few tools and leave you with some questions.

Tool 1: Remember to say no to the lamppost fallacy

The lamppost fallacy is an old one, and the story goes that a drunk guy says, "I dropped my keys, will you help me look for them?" "OK, sure. Where'd you drop them?" "Under that tree." "So why are you looking for them under this lamppost?" "Well, the light is better here."

A. Quantitative vs qualitative in the dev data

The first place we ought to check for the lamppost fallacy is in overvaluing quantitative metrics over qualitative analysis when looking at developer workflow and experience. Dave Neary said, in the FLOSSMetrics meeting in 2014, in "What you measure is what you get. Stories of metrics gone wrong": Use qualitative and quantitative analysis to interpret metrics.

When it comes to developer experience, you can be analytical while both quantitative and qualitative. And you rather have to be, because as soon as you start uncovering numbers, you start asking why they are what they are and what could be done to change that, and that's where the qualitative analytical approach comes in.

Qualitative is still analytical! Camille Fournier's post, "Qualitative or quantitative but always analytical", goes into this:

qualitative is still analytical. You may not be able to use data-driven reasoning because you're starting something new, and there are no numbers. It is hard to do quantitative analysis without data, and new things only have secondary data about potential and markets, they do not have primary data about the actual user engagement with the unbuilt product that you can measure. Furthermore, even when the thing is released, you probably have nothing but "small" data for a while. If you only have a thousand people engaging with something, it is hard to do interesting and statistically significant A/B tests unless you change things drastically and cause massive behavioral changes.

This is applicable to developer experience as well!

For help, I recommend the Wikimedia movement's Grants Evaluation & Learning team's table discussing quantitative and qualitative approaches you can take: ethnography, case studies, participant observation, and so on. To deepen understanding. It's complementary with the quantitative side, which is about generalizing findings.

B. Quantifiable dev artifacts-and-process data versus data about everything else

Another place to check for the lamppost fallacy is in overvaluing quantifiable data about programming artifacts and process over all sorts of data about everything else that matters about your project. Earlier today, Jesus González-Barahona mentioned the many communities -- dev, contributor, user, larger ecosystem -- that you might want to research. There's lots of easily quantifiable data about development, yes, but what is actually important to your project? Dev, user, sysadmin, larger ecology -- all of these might be, honestly, more important to the success of your mission. And we also know some things about how to get better at getting user data.

For help, I recommend the Simply Secure guides on doing qualitative UX research, such as seeing how users are using your product/application. And I recommend you read existing research on software engineering, like the findings in Making Software: What Really Works and Why We Believe It, the O'Reilly book edited by Andy Oram and Greg Wilson.

Tool 2: know what kind of assessment you're trying to do and how it plays into your theory of change

Another really important tool that will help you say no to some things and yes to others is knowing what kind of assessment you're trying to make, and how that plays into your hypothesis, your theory of change.

I'm going to mess this up compared to a serious education researcher, but it's worth knowing the basics of the difference between formative and summative assessments.

Formative assessment or evaluation is diagnostic, and you should use it iteratively to make better decisions to help students learn with better instruction & processes.

Summative assessment is checking outcomes at the conclusion of an exercise or a course, often for accountability, and judging the worth/value of that educational intervention. In our context as open source community managers, this often means that this data is used to persuade bosses & community that we're doing a good job or that someone else is doing a bad job.

As Dawn Foster last year said in her "Your Metrics Strategy" speech at the FLOSSMetrics meeting:

METRICS ARE USEFUL Measure progress, spot trends and recognize contributors.
Start with goals: WHY FOCUS ON GOALS? Avoid a mess: measure the right things, encourage good behavior.

Here's Ioana Chiorean, FLOSS Community Metrics meeting, January 30th 2015, "How metrics motivate":

Measure the right things... specific goals that will contribute to your organization's success

Dave Neary in 2014 in "What you measure is what you get. Stories of metrics gone wrong" at the Metrics meeting said:

be careful what you measure: metrics create incentives
Focus on business and community's success measurements

And this is tough. Because it can be hard to really make a space for truly formative assessment, especially if you are doing everything transparently, because as soon as you gather and publish any data, people will use it to argue that we ought to make drastic changes, not just iterative changes. But it might help to remember what you are truly aiming at, what kind of evaluation you really mean to be doing.

And it helps a lot to know your Theory of Change. You have an assessment of the way the world is, a vision of how you want the world to look, and a hypothesis about some change you could make, an activity or intervention you could perform to move us closer from A to B.

There's a chicken and egg problem here. How do you form the hypothesis without doing some initial measurement? And my perhaps subversive answer is, use ideas from other communities and research to create a hypothesis, and then set up some experiments to check it. Or go with your gut, your instinct about what the hypothesis is, and be ready to discard it if the data does not bear it out.

For help: Check out educational psychology, such as cognitive apprenticeship theory - Mel Chua's presentation here gives you the basics. You might also check out the Program/Grant Learning & Evaluation findings from Wikimedia, and try out how the "pirate metrics" funnel -- Acquisition, Activation, Retention, Referral, Revenue, or AARRR -- fits with your community's needs and bottlenecks.

Tool 3: if something doesn't work, acknowledge it

And the third tool is that when we see data saying that something does not work, we need to have the courage to acknowledge what the data is saying. You can move the goalposts, or you can say no and cause some temporary pain. We have to be willing to take bug reports.

Here's an example. The Wikimedia movement likes to host editathons, where a bunch of people get together and learn to edit Wikipedia together. We hoped that would be a way to train and retain new editors. But Wikipedia editathons don't produce new long-term editors. We learned:

About 52% of participants identified as new users made at least one edit one month after their event, but the percentage editing dropped to 15% in the sixth months after their event

And, in "What we learned from the English Wikipedia new editor pilot in the Philippines":

Inviting contribution by surfacing geo-targeted article stubs was not enough to motivate or help users to make their first edits to an article. Together, all new editors who joined made only six edits in total to the article space during this experiment, and they made no edits to the articles we suggested.

Providing suggestions via links to places users might go for help did not appear to sufficiently support or motivate these new editors to get involved. 50 percent of those surveyed later said they didn’t look for help pages. Those who did view help pages nevertheless did not edit the suggested articles.

But over and over in the Wikimedia movement I see that we keep hosting those one-off editathons. And they do work to, for instance, add new high-quality content about the topics they focus on, and some people really like them as parties and morale boosters, and I've heard the argument that they at least get a lot of people through that first step, of creating an account and making their first edit. But that does not mean that they're things we should be spending time on, to reverse the editor decline trend. We need to be honest about that.

It can be hard to give up things we like doing, things we think are good ideas and that ought to work. As an example: I am very much in favor of mentorship and apprenticeship programs in open source, like Google Summer of Code and Outreachy. Recently some researchers, Adriaan Labuschagne and Reid Holmes, raised questions about mentorship programs in "Do Onboarding Programs Work?", published in 2015, about whether these kinds of mentorship programs move the needle enough in the long run, to bring new contributors in. It's not conclusive, but there are questions. And I need to pay attention to that kind of research and be willing to change my recommendations based on what actually works.

We can run into cognitive dissonance if we realize that we did something that wasn't actually effective. Why did I do this thing? why did we do this thing? There's an urge to rationalize it. The Wikimedia FailFest & Learning Pattern hackathon 2015 recommends that we try framing our stories about our past mistakes to avoid that temptation.

Big 'F' failure framing:
  1. We planned this thing: __________________________
  2. This is how we knew it wasn't working: __________________________
  3. There might have been some issues with our assumption that: __________________________
  4. If we tried it again, we might change: __________________________

Little 'f' failure framing:

  1. We planned this thing: __________________________
  2. This is how we knew it wasn't working: __________________________
  3. We think that this went wrong: __________________________
  4. Here is how to fix it: __________________________

For help with this tool, I suggest reading existing research evaluating what works in FLOSS and open culture, like "Measuring Engagement: Recommendations from Audit and Analytics" by David Eaves, Adam Lofting, Pierros Papadeas, Peter Loewen of Mozilla.

Priorities

I have a much larger question to leave you with.

One trend I see underlying a big chunk of FLOSS metrics work is the desire to automate the emotional labor involved in maintainership, like figuring out how our fellow contributors are doing, making choices about where to spend mentorship time, and tracking a community's emotional tenor. But is that appropriate? What if we switched our assumptions around and used our metrics to figure out what we're spending time on more generally, and tried to find low-value programming work we could stop doing? What tools would support this, and what scenarios could play out?

This is a huge question and I have barely scratched the surface, but I would love to hear your thoughts. Thank you.

Sumana Harihareswara, Changeset Consulting

Filed under:


: Comparing Codes of Conduct to Copyleft Licenses (My FOSDEM Speech): "Comparing codes of conduct to copyleft licenses": written notes for a talk by Sumana Harihareswara, delivered in the Legal and Policy Issues DevRoom at FOSDEM, 31 January 2016 in Brussels, Belgium. Video recording available. Condensed notes available at Anjana Sofia Vakil's blog.

FOSDEM logo Good afternoon. I'm Sumana Harihareswara, and I represent myself, and my firm Changeset Consulting. I'm here to discuss some things we can learn from comparing antiharassment policies, or community codes of conduct, to copyleft software licenses such as the GPL. I'll be laying out some major similarities and differences, especially delving into how these different approaches give us insight about common community attitudes and assumptions. And I'll lay out some lessons we can apply as we consider and advocate various sides of these issues, and potentially to apply to some other topics within free and open source software as well.

My notes will all be available online after this, so you don't have to scramble to write down my brilliant insights, or, more likely, links. And I don't have any slides. If you really need slides, I'm sorry, and if you're like, YES! then just bask in the next twenty-five minutes.

I. Credibility

I will briefly mention my credentials in speaking about this topic, especially since this is my first FOSDEM and many of you don't know me. I have been a participant in free and open source software communities since the late 1990s. I'm the past community manager for MediaWiki, and while at the Wikimedia Foundation, I proposed and implemented our code of conduct, which we call a Friendly Space Policy, for in-person Wikimedia technical spaces such as hackathons and conferences.

I wrote an essay about this topic last year, as a guest post on the social sciences group blog Crooked Timber, and received many thoughtful comments, some of which I'll be citing in this talk.

I am also a contributor to several GPL'd pieces of code, such as MediaWiki and GNU Mailman, on code and non-code levels. And I am the creator of Randomized Dystopia, a GPL'd web application that helps you in case you want to write scifi novels about new dystopian tyrannies that abrogate different rights.

And I have been flamed for suggesting codes of conduct; for instance, one Crooked Timber commenter called me "a wannabe politician, trying to find a way to become important by peddling solutions to non-problems." Which is not as bad as when one person replied to me on a public mailing list and said, "Deja Vue all over again. I finally understand why mankind has been plagued by war throughout its entire history...." So maybe I'm the cause of all wars in human history. But I probably won't be able to cover that today.

II. The basic comparison

So let's start with a basic "theory of change" lens. When you're an activist trying to make change in the world, whether it's via a boycott, a new app, a training session, founding an organization, or some other approach, you have a theory of change, whether it's explicit or implicit. You have an assessment of the way the world is, a vision of how you want the world to look, and a hypothesis about some change you could make, an activity or intervention you could perform to move us closer from A to B. There's a pretty common theory of change among copyleft advocates and a couple of theories of change that are common to code of conduct advocates.

A. GPL

The GPL restricts some software developers' freedom (around redistributing software and around adding code under an incompatible license) so as to protect all users' freedom to use, inspect, modify, and hack on software.

The copyleft theory of change supposes that more people will be more free if we can see, modify, and share the source code to software we depend on, and so it's worth it to prohibit enclosure-style private takeovers of formerly shared code. Because in the long run, this will enable free software developers to build on each others' work, and incentivize other developers to choose to make their software free.

B. Codes of Conduct

Now, codes of conduct, antiharassment policies, friendly space policies: They restrict some people's behavior and require certain kinds of contributions from beneficiaries, so as to increase everyone's capabilities and freedom in the long run.

One pretty popular theory of change goes like this: we will make better software and have a greater impact if more people, and more different kinds of people, find our communities more appealing to work in. One thing making an unpleasant environment and driving away contributors, especially contributors with perspectives that are underrepresented in our communities, is hurtful misbehavior in community spaces. So we'll make the trade and say that it's worth it to restrict some behavior, in order to make the environment better so more, and more varied, people can do work in our communities, and thus make more free software and make it better.

And here's another related one, very similar to the one above, but focusing on the day-to-day freedom of community participants who are marginalized. If the constraint stopping me from, for instance, speaking in an IRC channel is that I strongly suspect I'll be harassed if they know I'm a woman, and that I don't have any reason to believe I can avoid or usefully complain about that harassment, how free am I to participate in that community? Is there perhaps a way to understand a certain level of safety as a necessary prerequisite to liberty?

I realize that this is probably the one room in the world where I have the highest chance of getting into a multi-hour "what does freedom mean" bikeshedding session, so I'm going to avoid focusing on the second model there and focus more on the first one, which emphasizes the end result of more free software.

Photo of me at FOSDEM 2016, CC BY-SA Luis García Castro, https://twitter.com/luiyo/status/700938185115836416

C. Assumptions

So I am not assuming that everyone in this room is a copyleft advocate, but I am going to assume from this point forward that we in this room fundamentally understand the restrictive license argument, that we have a handle on the theory of change that it's operating on. And similarly, I'm sure there are people here who aren't so big on codes of conduct, but I'm going to assume that we fundamentally understand the theory of change behind that approach, regardless.

D. Similarities

Now let's talk about similarities. Chris Webber calls both of these approaches "added process which define (and provide enforcement mechanisms for) doing the right thing." I agree. Without this kind of gatekeeping we see free rider incentives, on other people's software work and on other people's attention and patience and emotional labor.

They are written-down formalizations of practices and values that some community members think should be so intuitive and obvious that asking people to formally offer or accept the contract is an insult, or at least an unnecessary inconvenience. And so some people counterpropose sort-of-humorous policies, such as the "Do What the Fuck You Want to" software license and "don't be a jerk" codes of conduct.

They are loci of debate and fragmentation.

Some people agree to them thoughtfully, some agree distractedly as they would to corporate clickthrough EULAs, some disagree but click through anyway (acting in bad faith), some disagree and silently leave, some disagree and negotiate publicly, some disagree and fork publicly. Some people won't show up if the agreement is mandatory; some people won't show up UNLESS it's mandatory; some people don't care either way. And, by the way, good community management requires properly predicting the proportions, and navigating accordingly.

Both copyleft licenses and codes of conduct are approaches to solving problems that became more apparent along with different people realizing they have different expectations and needs, and consider different outcomes or processes to be "fair."

These kinds of codes and licenses usually cover specific bounded events and spaces or sites, and their scope covers interpersonal or public interactions. Codes of conduct usually don't cover conversations outside community-run spaces or the beliefs you hold in your head; open source licenses' restrictions usually kick in on redistribution, not use, so they don't constrain anything you do only on your own computer.

Neither one of these approaches can rely on self-enforcement. There is some self-enforcement of both, of course. There's a perception that -- as Harald K. commented on my blog post -- "licenses more or less police themselves (or in extreme instances, are policed by outsiders) whereas codes of conduct need an internal governing structure, a new arena where political power can be exercised." My personal understanding, which I share with people like Matthew Garrett, is that there's a ton of license-breaking happening, and we need to support existing organizations like the Software Freedom Conservancy to police that misbehavior and litigate to defend the GPL. As Conservancy head Karen Sandler points out in her December essay "From a lawyer who hates litigation", "I've seen companies abuse rights granted to them under the GPL over and over again. As the years pass, it seems that more and more of them want to walk as close to the edge of infringement as they can, and some flagrantly adopt a catch-me-if-you-can attitude." And you see enough individuals in our communities acting similarly that I don't think I need to belabor this point; codes of conduct are much more productive when they're actually, you know, enforced.

And both copyleft licenses and codes of conduct restrict freedom regarding certain acts, over and above what is restricted by the law, in the interest of a long-term good, which can in both cases be construed as greater freedom. As Belle Waring says to one skeptic in the Crooked Timber comments, paraphrasing their argument: "part of your reasonable resentment is, 'I don't want to be forced to do freedom-restricting things in support of a very uncertain outcome, just because the final proposed outcome is a good one.'" I will go into that bit of argument later.

E. Differences

But these kinds of agreements are different on a few different axes, which I think are worth considering for what they tell us about open stuff community values and about our intuitions on what kinds of freedom restrictions we find easier to accept.

One is that many codes of conduct focus on in-person events such as conferences, rather than online interactions. Many of the unpleasant incidents that caused communities to adopt CoCs -- or that communities see as "let's not let that happen here" warning bells -- happen at face-to-face events. And face-to-face spaces have a much longer history and context of ways of dealing with bad behavior than do online spaces. After all, a pretty widespread reading of the core function of government and law enforcement is that they keep Us Good Guys safe by stopping The Bad Guys from committing face-to-face (or knife-to-face or chair-to-face) assault.

But there's another axis I want to explore here: whether the behavior constraint feels like a contract or whether it feels like governance. Of course, we toss around phrases like "the social contract" and use the metaphor of contract to talk about the legitimacy of government, but to an ordinary citizen, contracts and governance feel like significantly different things. To oversimplify: to a non-lawyer like me, something that feels like a contract formalizes a specific trade, something discrete and finite and a bit rare. A copyleft license feels that way to me; it specifies that if I distribute a certain artifact -- which is something I would only do after some amount of thought and work -- I then also undertake certain obligations, namely, I must also redistribute the software's source code, under the same license. And, notwithstanding edge cases, it is often easy to examine the artifact, follow a decision procedure, and determine that I have complied with the terms of the license. If I meant to comply in the first place.

On the other hand, when we make rules constraining acts, especially speech acts, it feels more like governance.

Codes of conduct serve as part of a community's infrastructure to fulfill the first duty of a government — to protect its citizens from harm — and in order to make them work, communities must develop governance processes. That is to say, "governance" is what we call it when we're explicit about who gets to make and implement rules that affect everyone in a community, and how we choose those people or get rid of them. And a governance body does not necessarily have to be a legal entity. For instance, in MediaWiki governance, there's an architecture committee that decides on large technical architectural changes, and it has no standing in the eyes of the United States government.

It takes work to evaluate whether actions have complied with rules, and that work might require asking questions of suspects, bystanders, and targets. Enforcing a code of conduct, even a narrowly scoped anti-harassment policy, often requires that someone act on behalf of a community to do this, and to implement the outcome -- be it informed by retributive, rehabilitative, transformative, or some other justice model. And it feels more like governance than contract to me if a rule applies to actions I take many times a day without deliberate planning -- such as saying something in my project's live internet chat room.

One way of thinking about this is: is there some kind of authority that the community acknowledges as having legitimate power over everyday behavior, over and above existing government with a capital G? Because, again, licenses affect certain coding and architectural decisions, but they don't preclude, for instance, everyday discussion. In fact, the social and digital infrastructure it takes to make robust and usable software, including our bug reports, our automated tests, our conversation on mailing lists, and so on, is often not covered by any particular open license -- if it were, maybe we'd be seeing a different level of pushback even from developers who are happy with copyleft as applied to their code.

F. Shortcomings of the contract model

But I think another interesting thing that happens when you compare a governance model to a contract model, regarding approaches we take to improving behavior in our communities, is seeing how governance wins. It takes a lot of work, but it has a lot of advantages.

1. Flexibility

Contracts are binary where ongoing dialogue and governance can be more flexible and responsive. If I were going to be really annoying I would compare them to compiled bytecode and to interpretable scripts. Contracts have to sort of self-contain the tests for what the contract permits, mandates, and prohibits, whereas governance mechanisms and bodies can use more general standards, which might change over time. To quote one of the commenters on my essay, Stephenson-quoter kun:

contracts explicitly restrict acts which are simply unpardonable -- not sharing the source code to your modified version of a GPL-licensed project, sexually assaulting someone at a conference -- because everyone agrees that those things are wrong and we feel confident that we can agree up-front that there can never be any extenuating circumstances in which those things are actually OK. Governance, however, can serve to 'nudge' people away from bad behaviours – poor coding standards, rudeness on mailing lists -- by giving us a standard to measure those things against without enumerating every possible violation of the standard. A governance procedure can take context into account, and is much more easily subject to improvement and revision than a contract is.

Sometimes it's the little stuff, more subtle than the booth babe/groping/assault/slur kind of stuff, that makes a community feel inhospitable to me. When I say "little stuff" I am trying to describe the small ways people marginalize each other: dominance displays, cruelty in the guise of honesty, the use of power in inhospitable ways, feeling unvalued, "jokes", clubbiness, watching my every public action for ungenerous interpretation, nitpicking, and bad faith.

Changing these habits requires a change of culture, and that kind of deliberate change in culture requires people who take up the responsibility in stewarding the culture.

And a governance approach has a lot more ability to affect culture than a contracts-only approach does.

2. Contracts give us an illusion of equality and self-containedness

As Tim McGovern said in the comments to my Crooked Timber post:

contracts have taken over as a primary way of negotiating relationships: a EULA is a replacement for a legal understanding of the relationship between two parties who are doing business. I don't, in other words, sign a EULA when I buy a pair of socks -- or even when I buy a car (Teslas excepted) because the purchase relationship is legally defined; even the followup on what can and can't be in your warranty is legally defined. But companies would rather be bound by an agreement they write than a body of law based on either commonlaw or constitutional concepts, or legislation.

Contracts presume an equality between the parties; in theory, both sides can take a breach of contract to court. In practice, of course, a EULA is a contract that masks radical inequality in power between the parties.... Governance requires wrestling with equality in a real way, on the other hand, and voluntarily submitting to an authority constituted in some fashion (over time, by people, etc.), as opposed to preserving a contractual illusion of equality.

3. Contract pretends you have choices

I recommend that, if you haven't, you check out the article "Mothering versus Contract" by Virginia Held, from Beyond Self-Interest in 1990. It suggests that perhaps we should fundamentally conceive of our interactions with others as following a paradigm of motherhood rather than of contract -- one truth this approach acknowledges is that by default most interactions in your life are opt-out rather than opt-in, if there's any opting or choice at all.

Yes, there's the freedom to fork. But realistically, if you want to get things done, you have to collaborate with others, and we need to accede to other people's demands, in terms of interface compatibility, learning and speaking fluent English, and all sorts of other needs. A FLOSS project with a thriving ecology of contributors is far more valuable than a nearly identical chunk of code with only a couple of voices available to help out, and thus the finite amount of human attention limits our ability to make effective forks. We're more inderdependent than independent, and acknowleding that as a fundamental truth complicates the contracts-y libertarian narrative potentially beyond usefulness.

III. Lessons

I hope that my analysis helps give some vocabulary and frameworks for understanding arguments around these issues, and that we can use them to develop more effective arguments.

A. Freedom tradeoff comparisons

The first step might be — if you're trying to get your community to adopt a code of conduct, you might benefit by looking at other freedom-restricting tradeoffs the community is okay with, so you can draw out that comparison.

Or with UX (user experience) -- design is the art of taking things away, and when you're advocating for better user experience, which often involves reducing the number of visible ways to do things, consider comparing your approach to one of the freedom tradeoffs that your interlocutor is already okay with, such as the fact that your community has standardized on a single version control system. A single way for that kind of user to interact.

B. Artifacts

And if you're trying to build a code of conduct consensus in your community, it might help to start by talking, not about day-to-day beavior, but about artifacts that people think of as artifacts. Talk about the things we make, like slide decks for presentations, articles on your wiki. That can get people on the same page as you, in case they're not yet ready to think of the community itself as an artifact we make together.

C. Theory of change

If you're an advocate for a new initiative, licensing, code of conduct, or something else, understand your own theory of change, and build mental models to help you understand the people who disagree with you. Understand what part of the theory of change they disagree with, and gather data to counter it.

And, incidentally, this lens will also help you appreciate other complementary approaches that will help you achieve your goals. As Mike Linksvayer says: "Of course I think that copyleft advocates who really want to ensure people have software freedom rather than just being enamored of a hack should be always on the lookout for cheaper and/or socialized enforcement (as implied above, control of distribution channels that matter, and state regulation)."

So why might people oppose codes of conduct? Here are a few ideas:

As Chris Webber notes, "there's an argument that achieving real world social justice involves a certain amount of process, laying the ground for what's permitted and isn't, and (if you have to, but hopefully you don't) a specified direction for requiring compliance with that correct behavior." The addendum is that, as Alberto Brandolini said "The amount of energy necessary to refute bullshit is an order of magnitude bigger than to produce it." So part of the mental model you're trying to understand is what the person you're arguing with is trying to maximize, and another part is whether you agree on how to maximize it.

Paul Davis, the Ardour BDFL, commented on my Crooked Timber post, "The dilemma for a mid-size project like mine is that the overhead of developing and maintaining a CoC seems like just another thing to do amidst a list of things that is already way too long, and one that addresses a problem that we just don't have (yet)." He said he's more worried about technical, architectural decisions causing developer loss.

So, for instance, you could argue with Paul: what genuinely causes developer loss? And what priorities should you have, given your goals?

D. A fresh set of governance needs and questions

CoC adoption drives the adoption of explicit governance mechanisms, as Christie Koehler has recently explored in depth in her post "The complex reality of adopting a meaningful code of conduct" .... but we have many open questions that the legal and policy community within free and open source could really help with.

For instance, it's great that we have people like Ashe Dryden and organizations like Safety First PDX helping develop standards and advising organizers on developing and enforcing codes of conduct, but should we actually be centralizing this kind of reporting, codification and enforcement across the FLOSS ecosystem? Different subcommunities have different needs and standards, but just as OSI has helped us stave off the worst possibilities of license proliferation, maybe we should be avoiding the utter haphazardness of Code of Conduct proliferation.

And -- given how interconnected our projects are -- what if single open source projects are the wrong size or shape or scope for this particular aspect of stewardship and governance?

I'd very much appreciate thoughts on this from other folks in future devroom talks or blog posts -- if you tell me this is the kind of thing we talk about on the FLOSS Foundations mailing list then maybe I'll have to bite the bullet and go ahead and subscribe.

IV. Other thoughts + Conclusion

A. Comments on my CT piece

The comments on my Crooked Timber piece had many fine insights, on enforcement, culture, exit, voice and loyalty, fairness, and the consent of the governed. They're worth reading.

B. Hospitality to liberty spectrum

In addition to the contract-governance contrast, I think it's also worth thinking about the spectrum of liberty versus hospitality. The free software movement really privileges liberty, way over hospitality. And for many people in our movement, free speech, as John Scalzi put it, is the ability to be a dick in every possible circumstance. Criticize others in any words we like, and do anything that is not legally prohibited.

Hospitality, on the other hand, is thinking more about right speech, just speech, useful speech, and compassion. We only say and do things that help each other. The first responsibility of every citizen is to help each other achieve our goals, and make each other happy.

I think these two views exist on a spectrum, and we are way over to one side, the liberty side, as a community, and moving closer to the middle would help everyone learn better and would help us keep and grow our contributor base, and help make it more diverse. And to the extent that comparing codes of conduct to copyleft licenses helps some people put new initiatives in perspective, balancing the relationship between rights and responsibilities, perhaps that can also help shift our culture into one that's more willing to be hospitable. I hope.

C. This feels like a potentially insoluble problem

William Timberman said in Crooked Timber comments, "how does a socialist persuade a libertarian that coherence and the common good is sometimes a legitimate constraint on individual freedom?" And the answer is that I don't know, but I hope it is a soluble problem, and I hope I've opened up some avenues for exploration on that topic. Thank you.

Filed under:


: Risk Mitigation: FOSDEM logo Next week I'm headed to Belgium for my first Free and Open Source Developers' European Meeting. I'll give two talks. I'm excited, because it'll be a chance to listen, learn, influence, introduce myself to potential clients, and see old pals.

But I asked one old pal whether he'd be there and got the reply:

Don't plan to be at FOSDEM; one of these years, maybe after their CoC isn't a joke.

For some time, FOSDEM participants and people who'd like to attend have asked FOSDEM organizers to improve their Code of Conduct. In October, one of the people organizing the Legal and Policy Issues DevRoom suggested,

FOSDEM is a fantastic conference and the only thing I can think of that would make it better is publishing a Code of Conduct...

Discussion ensued, and in November, the organizers announced their new Code of Conduct. I appreciate that different organizations need to customize their anti-harassment/friendly space/conduct policies, as the Wikimedia technical community did under my leadership, and I recognize that FOSDEM -- entirely volunteer-run, requiring no attendee registration, and charging no admission fee -- has its own particular challenges. But I see why my friend looks askance at FOSDEM's CoC. If you compare it to the example policy offered on the Geek Feminism wiki, you see how lots of little differences add up. For instance, FOSDEM's policy doesn't give a way to anonymously report a problem, and it doesn't suggest how you can find or identify team or staff members.

I figure I can go, this time, see how it goes, keep my guard up a bit, and then, as a member with more standing in and a more nuanced understanding of the FOSDEM community, ask for specific improvements, and explain why. My support network, my judgment, and my courage are in good enough shape that I can handle the most likely nonsense without taking too much damage.

But there's this one wrinkle.

The night before FOSDEM proper, the organizers run a beer night that -- according to my friends who have attended -- is a highlight of the convention. Since many FOSDEM attendees spend the session days in subject-specific devrooms, and since I want to meet people from many and varied projects, this beer night is probably the most high-value networking event all weekend. But. As the Geek Feminism wiki astutely notes,

Intoxication (usually drunkeness) both genuinely lowers inhibitions and provides people with an excuse for acting badly even if they genuinely knew better.

The data makes me cautious. FOSDEM improved its policy, but not enough to completely reassure me, and we still have yet to see how they implement it. Many individual devrooms and affiliated events, such as the FLOSS metrics meeting where I'm speaking, have added their own CoCs, but that doesn't cover the beer night.

So how will I mitigate risk? Maybe I won't go to the beer party at all. Maybe I'll go, but stay in loud crowded places, even if that makes it harder for me to have the kinds of in-depth conversations that lead to sales. Maybe I'll mention my husband a lot and dress androgynously. Maybe I'll mostly talk with women, with other nonwhite people, and with friends I already know, trading off serendipity against safety. And, despite the organizers' suggestion that I "don't miss this great opportunity to taste some of the finest beer in Belgium," and even though I enjoy trying new beers, I'll probably stick to water.

(And then next year I'll be part of the whisper network, helping other folks decide whether to go.)

I'm writing this to help people who don't have to make these risk calculations see a snapshot of that process, and, frankly, to justify my attendance to those who can't or won't attend FOSDEM till it's more clearly dedicated to a harassment-free experience for participants. And comments on this blog post are closed because, as Jessica Rose said:

Any extended conversation around a code of conduct will eventually demonstrate why a code of conduct is necessary.

P.S. I tried to think of an appropriate "free-as-in-beer" joke and could not. Regrets!

Filed under:


: Several Upcoming Talks: I'm preparing several talks to deliver at open source technology conferences this winter and spring. me smiling at camera

I'll be at FOSDEM in Brussels later this month giving two talks:

  1. On Friday, January 29th, at the FLOSS Community Metrics Meeting, I'm presenting "What should we stop doing?" The FLOSS community often clamors for stats that would let us automate emotional labor, so we could focus on more valuable work. Is that appropriate? What if we switched our assumptions around and used our metrics to figure out what we're spending time on more generally, and tried to find low-value programming work we could stop doing? What tools would support this, and what scenarios could play out?
  2. On Sunday, January 31st, I'm speaking in the Legal and Policy Issues "devroom" on comparing codes of conduct to copyleft licenses, expanding on the discussion I started in this Crooked Timber piece last year. What can we learn about our own attitudes towards governance when we look at how and whether we make these different freedom tradeoffs?

In mid-March, I will present "Hidden Features in HTTP" at Great Wide Open in Atlanta, Georgia. This will be pretty similar to "HTTP Can Do That?!", which I presented to a standing-room-only crowd at Open Source Bridge last year. If you're a web developer whose knowledge of HTTP verbs ends around GET and POST, expect news, laughs, and lab reports from wacky experiments.

me with a micRight after Great Wide Open, I'll speak on "Inessential Weirdnesses in Free Software" at LibrePlanet in Boston. And then in mid-May, I'll be presenting "Inessential Weirdnesses in Open Source" at OSCON in Austin, Texas. More than a year after I wrote "Inessential Weirdnesses in Open Source" as a tossed-off blog post, I'm pretty dissatisfied with it. I should have more clearly stated my assumptions and audience, and my intent to play around with some vocabulary and what-ifs; I'm unhappy that many people misread it as a "we should eradicate all these things" manifesto. In these talks I aim to clarify and deepen this material. Open source contributors and leaders who are already comfortable with our norms and jargon will learn how to see their own phrasings and tools as outsiders do, including barriers that often slow down new users and contributors, and to make more hospitable experiences during their outreach efforts.

Then in late May I'll make a public appearance or two at WisCon -- the exact nature of which is a surprise!

I'm proud that this year I'll be speaking for the first time at FOSDEM, Great Wide Open, LibrePlanet, and OSCON. I hope my talks and the hallway track help me get the word out about Changeset Consulting to potential clients.

And if you can't make it to any of those conferences, but you'd like to hear more about Changeset and my other activities, check out Andromeda Yelton's one-hour interview with me in her Open Paren video podcast. At 39:29 I emit a huge belly laugh that makes me happy to re-watch and you might like it too.

me holding a mic in front of an audience

Filed under:


(1) : Slides & Code from HTTP Can Do That?!:

a bespoke header in an HTTP response My slides are up, as is demonstration code, from "HTTP Can Do That?!", my talk at Open Source Bridge last month. I am pleased to report that something like a hundred people crowded into the room to view that talk and that I've received lots of positive feedback about it. Thanks for help in preparing that talk, or inspiring it, to Leonard Richardson, Greg Hendershott, Zack Weinberg, the Recurse Center, Clay Hallock, Paul Tagliamonte, Julia Evans, Allison Kaptur, Amy Hanlon, and Katie Silverio.

Video is not yet up. Once the video recording is available, I'll probably get it transcribed and posted on the OSBridge session notes wiki page.

I've also taken this opportunity to update my talks and presentations page -- for instance, I've belatedly posted some rough facilitator's notes that I made when leading an Ada Initiative-created impostor syndrome training at AdaCamp Bangalore last year.

Filed under:


: Apology: Earlier today, during my stand-up comedy act at AlterConf Portland, I failed at living up to the AlterConf code of conduct and to my act's title, "Stand-Up Comedy that Doesn't Hurt". I made a joke that hurt members of the audience. The joke was in a section about attempts to be perceived as a cis ally:

I try to be intersectional in the media I consume, and sometimes that leads to carbon credit-style bargaining, like, "How many memoirs by trans women of color do I have to read before I go see 'Avengers: Age of Ultron'"? [laughter] And then sometimes there's cheating on that diet, like, "Does 'Mrs. Doubtfire' count?"

In this joke, it is not clear enough that the cis ally narrator is completely wrong to categorize "Mrs. Doubtfire" as having anything to do with the goal of reading and supporting trans narratives. I won't make it again and I'm sorry that I made a joke that hurt.

For this act I practiced in front of audiences that included trans people, and I asked them for feedback, but I was not thorough enough about checking beyond that for offensive material. In the future I'll be more thorough.

Filed under:


: HTTP Can Do That?! and Comedy: I'm speaking at Open Source Bridge - June 23-26, 2015 - Portland, OR On Wednesday of next week (June 24th) I'm presenting "HTTP Can Do That?!" at Open Source Bridge in Portland, Oregon.

I have explored weird corners of HTTP -- malformed requests that try to trick a site admin into clicking spam links in 404 logs, an API that responds to POST but not GET, and more. In this talk I'll walk you through those (using Python, netcat, and other tools you might have lying around the house).

I practiced this talk Tuesday night at the Recurse Center and it went well; people learned a lot about headers, verbs, status codes, and odd HTTP loopholes, and gave me constructive criticism so next week's version will be clearer.

I have also suggested a Birds of a Feather evening session called "Nothing Is Totally Incomprehensible If We Try Together" but don't yet know whether or when it will happen.

Then, at AlterConf Portland on Saturday, June 27th, I'll be performing some stand-up comedy for hippie nerds. I thought about trying to cram 100 punchlines into my 45-minute HTTP talk, but I don't think I'll be able to achieve that -- people need to understand something before they can understand a joke about it -- so it'll be nice to get 4 or 5 laughs per minute during the stand-up on Saturday.

Filed under:


(1) : WisCon Schedule: I'll be at WisCon starting tomorrow and leaving on Tuesday. I am scheduled to participate in these sessions:

  1. Imaginary Book Club, Fri, 4:00-5:15 pm in Conference 2. Five panelists discuss books that don't exist, improvising critiques and responses. I proposed this panel a few years ago (you can see video of its debut) and it has continued, which is cool!
  2. Lighthearted Shorthand Sans Fail, Sat, 8:30-9:45 am in Capitol A. What are your go-to phrasings to avoid sexism, ableism, etc. while getting your point across in casual conversation? I hope to walk out of this with some new vocabulary to replace bad habits.
  3. Vid Party, Saturday night 9:00 pm-Sun, 3:00 am in room 629. I am premiering a fanvid. Once it's premiered, I'll hit Post on blog posts to announce it publicly as well.
  4. Call Out Culture II: Follow-up to the Discussion Held at WisCon 38, Sun, 10:00-11:15 am in Senate A. Meta-discussion around discourse in social justice movements. I predict this session will be pretty intense.
  5. Vid Party Discussion, Sun, 1:00-2:15 pm in Assembly. We will discuss some of the vids shown at the vid party, and fan vids in general. This will be the first time I've engaged in public realtime conversation about fanvids. Before this panel I hope to publish some notes about what I learned from watching several vids that drew from multiple sources (including stills), made a political point, or were otherwise particularly ambitious. I'll probably reference those lessons during the panel.

I also proposed "What Does Feminist Tech Education Look Like?", "Impostor Syndrome Training Exercise", and "Entry Level Discussion Group", but am not a panelist or presenter for those sessions; I bet they'll be interesting, though, and you could do worse than to check them out. You can read Entry Level ahead of time for free online.

I look like the photo to the left. I am often bad with names, and will remember 5 minutes into our conversation that we had an awesome deep conversation three years prior. I apologize in advance.

If you are good at clothes, consider joining me at the Clothing Swap portion of the Gathering on Friday afternoon to help me find pieces that suit me. I'm introducing two old pals to WisCon and spending a lot of time with them (we live in different cities), and they're both white, so I might not be able to come to the People of Color dinner on Friday night. And sadly, The Floomp dance party on Saturday happens during the Vid Party so I probably can't attend that. I did buy a ticket for the Dessert Salon and will attend the Guest of Honor and Tiptree Award speeches on Sunday, and maybe you will be at my table!

One of my pals who's coming to WisCon is Beth Lerman, an artist who will be displaying and selling her work in the art show. Check it out!

Also I am open to doing a small room performance of my half-hour geeky stand-up comedy routine if several people ask for it. I don't know when or where it would be; Monday night would be easiest. Speak up in comments or some other medium if you'd be interested.

Filed under:


: Foolscap Followup: I'm currently at Foolscap, a hospitable and thoroughly delightful scifi/fantasy convention in the Seattle area. Leonard is a Guest of Honor and I get to be his consort. This year Foolscap takes place in Redmond, which means I am exactly "as lonesome as a Linux user in Redmond," but it turns out that doesn't have to be too lonesome!

Some links and whatnot I've meant to give people:

(This is probably incomplete. It's been a fun con and it's not over yet!)

Filed under:


: Interesting-Looking Talks at PyCon 2014: PyCon 2014 This year I'm going to visit PyCon! In fact, I'm presenting a poster: "What Hacker School Taught Me About Community Mentoring". You should register soon if you're coming, especially to take advantage of heavily subsidized childcare or to register for one of the tutorials.

Someone on one of my mailing lists asked what sessions people are particularly looking forward to. I tend to follow Skud's conference tips, which mean skipping sessions when I need to do self-care. But with such great-sounding talks, I may not be able to pull myself away!

I'm thoroughly looking forward to my first PyCon. (I stopped by one for like an hour in 2003 and helped at the registration desk; I guess it took me eleven years to get to the other side of the desk!)

Filed under:



[Main]

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.