Cogito, Ergo Sumana

Categories: sumana | Deliverables

Announcements of things I have made, like zines, software, and articles on other websites.


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

Contents:

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

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

Introducing the question/problem

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

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

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

A little more about the problem I see

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

So what hypotheses do we have?

Tooling hypothesis

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

Corporate involvement hypothesis (hypotheses)

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

New problems hypothesis

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

Values and culture hypothesis

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

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

How would we check?

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

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

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

Thanks.

Filed under:


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

Sean maintains a lot of stuff, right?...So Sean has taken on more and more, and he realizes one day that he's feeling a little more burned out, feeling kind of exhausted. And a friend of his, instead of sending him some list of 10 productivity hacks, does, perhaps, a kinder thing and actually takes some time to sit down with him and do a responsibility audit. Just a big list of “what are all the open source things that you're responsible for right now.” And there's a lot on that list. And Sean realizes that this [particular project] is just not where he wants to be putting his time, he needs to concentrate on fewer things that have higher priority to him.

And so at the next solstice, he uses the open source tradition that has arisen that twice a year at the solstices, there's a Responsibility Amnesty Day, which is the day when you can just say, “hey, I can't keep doing this anymore so I'm putting it down.” And everyone understands. So he does that at the next solstice.

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

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

Filed under:


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


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


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


: New Free Ebook Sampler from "Getting Unstuck: Advice for Open Source Projects": I've written and released a sampler from my upcoming book on rejuvenating open source projects: Getting Unstuck: Advice for Open Source Projects. It's like a lengthy trailer in text form.

You can get this 38-page ebook for free when you subscribe to Changeset Consulting's email newsletter (1-10 updates per year).

Getting Unstuck sampler cover

Who this book is for and what you should get out of it:

You are about to get an open source project unstuck.

Maybe a bunch of work is piling up in the repository and users are getting worried, waiting for a release. Maybe developers have gotten bogged down, trying to finish a big rewrite while maintaining the stable release. Maybe the project's suffering for lack of infrastructure — testing, money, an institutional home.

You noticed the problem. So that means it's up to you to fix it. Or you're getting paid to fix it, even though you didn't start this thing.

A while ago I blurted out the phrase "dammit-driven leadership." Because sometimes you look around, and you realize something needs doing, and you're the only one who really gets why, so you say, "Dammit, okay, I'll do it, then."

After reading this book, you should be prepared to:

  1. Assess a legacy project to decide whether you should get involved.
  2. Settle into a legacy project and become a competent and credible contributor.
  3. Take charge of a legacy project on a project, people, and financial level.
  4. Execute transformative change in a legacy project.
  5. Make a legacy project more sustainable, and pass leadership on to someone else.

This sampler is a free 38-page ebook (PDF, ePub, and MOBI available) that includes:

Thanks to Julia Rios for paid services editing and producing this book, including the cover! Julia is a Hugo Award-winning editor as well as a writer, narrator, and podcaster, and is available for freelance work!

A special note for my blog readers: I'm keenly interested in your feedback once you read the sampler. Have you solved any of these problems in a different way? Would a different structure, for each chapter or for the book, help you better? Did any of my examples or phrasings particularly ring true? Are there things I've written that you have found useful and that you hope I will incorporate into this book? Email me with "Unstuck" in the subject line.

Next: In 2021 I'm looking forward to finishing this book and either self-publishing or working with a publisher. And I will likely bring this sampler from behind the subscribewall once I produce a new edition of it that can have a "the full book is coming on [date] from [publisher]!" line. In order to do that, I need to finish the book proposal, submit it to publishers, and get cracking on the rest of the book.

Get the sampler for free when you subscribe to Changeset's email newsletter (1-10 updates per year).

Filed under:


: Getting Autoconf Unstuck: For most of this year, Zack Weinberg and I have been working on a pretty ambitious project:

  1. to make a fresh release of GNU Autoconf, a crucial free and open source build tool that hadn't had a new release since 2012
  2. to get paid for that
  3. to help put Autoconf on a more sustainable footing so it doesn't have to get rescued again a little while down the road

Autoconf 2.70 is due out this month; if you use Autoconf, check out the 2.69e beta and test it soon since Zack aims to make the release on December 8th.

If you hear "Autoconf" and think "I don't even know what that is or why it is important", you can read my LWN story about the rejuvenation & what's next.

(I am proud that a person said "That's one of the best pieces of technical writing that I've read in a long time." about my article.)

Several companies use/depend on Autoconf internally and would like for Autoconf and the entire Autotools toolchain to get back on track. There's lots of code out there already depending on autoconf. Converting it would be risky and expensive. Plus, competing build systems don't cover all the edge cases Autoconf does. If this makes you nod, check out the 2.69e beta and test it.

But also, the funding we got has run out, so we're trying to get some corporate sponsorship to make 2.71 even better (including building out a robust continuous integration system), and get the project on a sustainable footing. We'd like to:

Even a donation as small as USD $5,000 could help make substantial progress. If you want to directly pay Changeset to work on this, email me and let's talk. Or: the Free Software Foundation, a 501(c)3 nonprofit, collects donations on behalf of the GNU Toolchain (see their list of Working Together for Free Software Fund project areas), and your organization can make a tax-deductible donation to the FSF targeted at GNU Toolchain maintenance.

Filed under:


: Short Story Recommendations, And Hobby Project Lessons: Recommending short fiction is important for discovery, and to help us talk about things we like (and not just criticize things we don't).

Recently I've been posting to MetaFilter each day to recommend short stories, mostly scifi/fantasy but not always. For example, I pointed to Brishti Guha's translation of a (wacky, in my opinion) 11th-century Sanskrit piece by Kshemendra about language misunderstandings and an angry scholar. "...the reason the meat was so poor was because hunters couldn’t get hold of any well-fed animals. All the animals wanted to listen to Gunadhya’s story even more than they wanted to eat!" I enjoyed this fragment so much that I called my mom and read it aloud to her, and she told me cool stuff about the Sanskrit in-jokes in the story.

Other MetaFilter participants said nice things about how much they like the series which is nice to hear. Lots of people have said, in comments in that thread or on individual posts or in private mail to me, that they value getting these recommendations, that they are eager for links to good short fiction to help them read great stuff instead of getting sucked into the whirlpool of reading distressing news. Similarly, I have found it nice to have a wee research project, and to have a little template for bite-size things to write and publish that people enjoy. And I've discovered some cool magazines I hadn't known about before, such as Compelling Science Fiction and Cossmass Infinities.

I started posting these in late August. I decided that I'll stop at the end of this month, and suggested sources for folks who want to keep going.

And I've learned some things about what I found motivating about this project, and am working on adapting those lessons to my book project so I can get more traction.

Overall, I seem to benefit from having consistent frequent but delayed publication/gratification (which suggests a drip marketing approach as Julia Evans has just blogged about), having a clear vision for what each little chunk of work is supposed to be like (which suggests I need to bear down on outlining work), and external validation from eager readers (which suggests I should set up a few oral conversations sometime soon with people who need a book about brownfield maintainership).

Filed under:


: Changes Coming To Pip In October 2020: People who deal with Python: Changes are coming to pip, Python's package installation tool, in October 2020. Please share this migration guide and our video with your circles.

SHORT VERSION:

I'm working on improving the Python packaging toolchain, foundational work that will (in the long run) make the whole Python experience way less confusing. In the short term this may mess with some people's workflows, so we want lots of people to hear about it now.

The pip team made a 2-minute video to explain what's up:

We are also doing user experience studies, and want you to sign up if you ever do anything with Python (whatever your level of skill/experience).

Please boost this toot or retweet this tweet if you want to help us get the word out.

MORE DETAILS:

Computers need to know the right order to install pieces of software ("to install x, you need to install y first"). So, when Python programmers share software, like when they publish packages on the Python Package Index or internally in large companies, they have to precisely describe those installation prerequisites. And then pip needs to navigate tricky situations when it gets conflicting instructions.

Up until now, pip's been very inconsistent in handling this stuff, which makes it easy for your Python environment to get messed up. That's why we successfully applied for $407K in funding from Mozilla and the Chan Zuckerberg Initiative to finish and roll out a proper dependency resolver for pip. The goal is that pip will get better at handling that tricky logic, and easier for you to use and troubleshoot.

You can test the new behavior (in beta) right now by using an optional flag in pip 20.2. And in pip 20.3, coming in October, the new behavior will be the default.

Once you're using the new resolver, pip is going to be stricter and more consistent. So things won't mysteriously break as much, and we can add more features that lots of people want.

But! Right now, a ton of people unknowingly have Jenga towers of wobbly dependencies in their environments and will run into pain when we make the resolver stricter and more consistent. And this may lead to you getting stuck in troubleshooting, assuming that pip caused the problem, when actually the deeper cause is conflicts among how your upstreams specify requirements (TensorFlow just fixed a related thing, for example).

So: We're trying to get Python users to try out the beta of the new resolver that's available in the current stable release of pip (20.2), fix your own environments, report bugs in your upstreams in advance, and report bugs to us so we can fix them in the next couple weeks. We started spreading the word about this a few months ago. And now: video! People watch videos, I hear? I hope this helps.

Filed under:


: Breaking Release Bottlenecks -- What Changeset Can Do: I did some volunteer work earlier this year, helping rejuvenate pipenv (a command-line tool that some people use to help handle Python packages they make and use). Here's what I did, how long it took, and how you can do the same.

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 of this year, 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 (IRC) channel to nudge one of pipenv's maintainers and to ask: what do you need? What's blocking you?

Dan Ryan ("techalchemy") knew what was blocking him:

techalchemy: if you're purely evaluating 'how do we release the code', yeah I might just be the main roadblock?
techalchemy: someone to yell at me to stop doing things that are not related to the goal?
techalchemy: lol
sumanah: let us assume that a successful release -- even as a pre-alpha -- is something that does not instantly break every user's life
techalchemy: yeah longer term planning though would require tech writing for sure and onboarding help, god do I struggle with that
techalchemy: have you heard me explain something...
sumanah: if you JUST want someone to yell at you to stop doing those unrelated things, just for about a month, then that can be cheaper .... would you actually _listen_ to that person?
techalchemy: historically speaking, I'd insist I was doing something important briefly but probably reassess, I do know what needs to happen
sumanah: :-) ok. So, how frequently do you need those checkins? like, 4 times a day, 5 days a week?
techalchemy: hopefully not that much, but I could see a few checkins being helpful especially if we were also onboarding some new people
sumanah: techalchemy: ~10 minutes of conversation, via IRC, 4 times a day, 5 days a week, for 3 weeks....

That would have worked out to about ten hours. We underestimated how long it would take Dan to address some nasty continuous integration bugs, so instead of three weeks it took three months. Over those months, I donated about 15 hours of my time, helping him release two betas, then a stable version in May. 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.

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

Phil Gyford noticed that initial IRC conversation and said:

It's kind of fascinating as an example of bottlenecks in open source development and the importance of project managers.

And Yoz Grahame replied:

I regularly have conversations like this, and it's a toss-up as to which of the two roles I play.

Yeah. An external perspective can help a lot. And, ideally, a project manager is a supportive accountability partner who helps with the bits you're not great at.

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 you see in the IRC log above.

Or: contact Changeset Consulting for a free initial 30-minute chat. Maybe it'll only cost you a few thousand dollars to get that bottleneck unblocked. Let's find out!

Filed under:


: Apply For Grants To Fund Open Source Work, and Career Thoughts:

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. Therefore, a month ago, I delivered a ten-minute PyOhio talk in which I shared:

I've now posted a transcript (with slides), and the ten-minute video is up.

The Python context, and followup Q&A

Have some additional thoughts and info I could not fit into the talk!

Background and ideas: People who work on Python's packaging tools usually aren't paid to do so. It's usually but not always a side project. We have gotten grants (or similar funds) of $80,000 USD or $150K or $207K and they are a huge reason why we

On March 22, 2019, I started a wiki page to list some fundable projects in Python packaging. I figured that if we had a structured, public list of well-scoped, shovel-ready tasks that would move faster with funding, it would make it easier to find grants, sponsors, and other directed funds. And, heads-up, corporate readers: if you can help the PSF get some money to do these things, they are much more likely to happen, and Python will get much easier to deal with.

We've now moved that list to GitHub. If you know that filling a particular gap would improve Python packaging and distribution, go ahead and make a pull request!

And that doesn't just go for packaging. The Project Funding Working Group is seeking project ideas on a wider scale. If you make a well-structured list of fundable TODOs for your Python project, it can go in that list -- this will, in the future, make it easier for you to get funding.

Eligibility and how the money flows: often, only public charities or similar institutions are eligible to apply for certain kinds of funds, which is why getting the Python Software Foundation involved is helpful -- they are often eligible to apply in cases where you as an individual are not eligible. The way we've been doing it for the past few years is: some volunteers research a grant opportunity and write a proposal (often with the assistance of a PSF staffer) and the Python Software Foundation submits it. If it gets funded, the PSF hires contractors to do the proposed work, and then those contractors perform the proposed work and (via the PSF) report back to the funder. I cofounded the new Project Funding Working Group to centralize those efforts, bring enthusiastic volunteers together, teach more people to do this stuff, and capitalize on the momentum of the last few years.

We know some things about what some funders are seeking, and want to help match you up with funders who might be a good match. Depending on where you live, there may be country-specific grants that the existing members of the Project Funding Working Group know less about! Like, there is the Prototype Fund for people in Germany, and Innovation Fund Denmark, and there are a bunch of European Union grant opportunities that I know very little about like Horizon 2020.

Erika Owens asked some followup questions:

...how to assess if a grant is worth applying for - how do you know the foundation is legit? how do you balance the amount of time proposing/reporting with the likely grant amount?....

also, from a documentation mindset—where can you go for help with this type of work? what public writing is useful to others? (and possible given so much secrecy with funding)

Good questions.

When is it worth applying? & more: Different projects need different amounts of money. A one-time gift of $10K (about 60-100 hours of work at USD$100-150/hour) is not enough to make a significant dent in some of the listed fundable packaging tasks, but $10K could support a "get the next release out and clean up docs/bugtracker/patch queue" effort for your favorite library. This is why the Project Funding Working Group is trying to amass informational resources (a list of funders, "how to write a proposal", etc.) and point a lot of people at those resources so many people can self-serve -- the volunteers in the Working Group do not have time to write a dozen grant proposals from scratch in a year, each of which is for $10-30K. It might take 10-20 hours to research and draft a multi-page grant proposal from scratch (it gets easier when you can copy and paste from previous proposals or planning documents for the same software project). Sometimes it takes longer if a bunch of stakeholders (such as project maintainers) have to agree on priorities and scope. I hope that the working group writes a few proposals each year and that they're for at least $80,000 each, and that we advise or otherwise help a bunch of other volunteers to write grants for varied amounts. Let's see how the first year goes. Maybe I'll be wildly off.

I feel pretty lucky in that most of the grant-and-similar-funded projects I have worked on had fairly light reporting requirements, things that ended up taking maybe an hour per month plus maybe three hours at the end of the project. (Then again, I prep along the way by collecting meeting notes and updates on a public wiki page.) At the end of this year I need to make a fairly substantive report to the Chan Zuckerberg Initiative, so I may eat my words then!

A timeline from March 1st-Aug 29th of Open Tech Fund proposal acceptance What public writing is useful to others? I see people sharing actual grant proposals and budgets, and the Project Funding WG will too (soon), and I think that helps a lot. I bet a before-and-after of a proposal before and after editing would also be helpful. Timelines like this slide here (from my PyOhio talk) help others set expectations for the process. Project retrospectives like this Read the Docs post -- ditto. Lists of funders including real talk about what they're looking for. Reminders of deadlines (like: apply for the Better Scientific Software Fellowship by September 30th). If you have more suggestions, please open an issue!

How do you know whether the foundation is legit? Hmmm. I have confidence that I could tell whether a funder was fishy before getting into anything I'd regret, but I am having a hard time articulating the evaluation criteria I would use. Something to work on.

And where can you go for help with this kind of work? I know I ought to learn more from the world of professional grantwriters and other nonprofit experts, like Candid, and perhaps I will have a spurt of energy sometime soon to go dive in.

My career

This week, on the way to posting this, I rearranged my conference talks page to be more navigable. I have given 35-50 talks on tech-related topics in the past 10 years, depending how you count. I used to talk a lot about Wikimedia, then about HTTP, then Python packaging and the plays.

The response to my one talk about grants has already been strong and, if I just reacted to that, I'd give more talks about grants. Already my blog posts and talk about grants have led to Changeset Consulting client leads and some client work. And there's a logic here -- I have succeeded in doing something lucrative that other people would like to replicate.

And it can be easy to get sucked into grantwriting (the work of researching and creating grant proposals), because I am clearly expert enough to be helpful, there are deadlines to motivate me and colleagues, and every available grant is an explicit invitation with a concrete amount of money attached. It's a trail others have already blazed.

But grantwriting is a treadmill that ties projects to rich funders with short timescales, a topic ably covered by Nonprofit AF, The Revolution Will Not Be Funded: Beyond the Non-Profit Industrial Complex, and many others. As with recruiting, or diversity/equity/inclusion work, there's a lot of toil here.

So, I am excited about the potential of the Project Funding WG, which will help many open source groups pursue not just grants but "external grants and similar funding." Including talking with companies who want to sponsor particular improvements, or generally sustain their dependencies (via Tidelift or a direct gift) and avoid the headache of forking or switching.

And I'm open to Changeset Consulting doing some paid consulting work on grantwriting, and I'm doing some unpaid grantwriting to garner funding for projects where Changeset would do paid work. And I'm particularly interested in joining together with folks who are making big proposals to big foundation-style or government funders, upwards of USD$500K or in the millions.

But, in the near future, I mostly want Changeset to work on paid projects, funded by for-profit companies, to rejuvenate and level up open source projects that they depend on but do not control. And that's looking promising. I'm using many of the same skills you use in grantwriting, because they're sales skills. And I am looking forward to blogging about one of these projects soon.

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:


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


: My Recent-ish Government Transparency Efforts: I've put together a page of my past few years of Freedom of Information Law requests and the responses they've garnered. In particular, folks might be interested in the NYC Department of Health and Mental Hygiene's followup reports to 2005's Local Law 20, regarding the quantities and locations of automated external defibrillators at certain public places -- they wrote these reports and submitted them to the City Council, but I couldn't find them anywhere online till I asked DOHMH for them.

Now I have a Muckrock account, which I used to successfully get the list of ~600 DMV-licensed driving schools in New York State. Funniest names: "Accurate Drving School", the coexistence of "Evolution" and "Revolution" driving schools, "Good Luck Driving School", the coexistence of "Mistah Driver Auto School" and "Mister Driver Driving School", "Super Mario's Driving Connection", and "Totally Cool Driving".

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:


: My LWN Story Summarizing PyPI's Overhaul: Python Package Index logoThis coming Monday, April 16th, we plan to flip the switch on the new PyPI and redirect https://pypi.python.org web browser requests and pip install requests so the codebase serving them is Warehouse (which is in beta right now at https://pypi.org). I'm proud of our team's work and hope you find it useful.

I haven't blogged here in a while, but I've been writing a lot, mostly announcements and explanations listed on, or a few hyperlinks away from, the onwiki index to my PyPI work. When I can't give people choices (and, unless your organization sets up a private package index/repository, PyPI can feel like the only game in town), I want to give them a lot of lead time to test, file bug reports, and migrate, and I want to provide backstory.

So: today LWN publishes a new article by me, "A new package index for Python". In it, I discuss security, policy, UX and developer experience changes in the 15+ years since PyPI's founding, new features (and deprecated old features) in Warehouse, and future plans. Plus: screenshots!

This summary should help occasional Python programmers understand why a new PyPI codebase is necessary, what's new, what features are going away, and what to expect in the near future.

If you aren't already a subscriber, you can use this subscriber link for the next week to read the article despite the LWN paywall. Thanks to LWN for the venue and the subscriber links, and thanks to Jake Edge in particular for thorough editing. Thanks to my Warehouse team for fact-checking me.

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:


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


: Timesaving Negativism or Masculine Calumnies?:

"Do your lairstone relations HAVE to come over?" she snooted.

"Look, my uncles are almost done repairing their peatship, so happiest case, this is the last time for a long while."

"After all day patching up that thing, I suppose they'll need a nightcap."

"'Just a teardrop,'" he parroted.

"And then they'll intoxicate themselves into such a state of excitation --"

"I promise you, I understand your exasperation, but if my zombie uncles forget their precautions and catch another xenoparasite, this time it's on them to dig it up."

"Fine -- but you serve this time, I'm not a starwise waitress."


(This tiny short story inspired by Mark Dominus's list of awesome English anagrams and his !!Con talk on this topic.)

Filed under:


: On LiveJournal: I've posted to MetaFilter about some recent goings-on at LiveJournal; if you have an LJ account you should probably take a look.

Filed under:


: New Zine "Playing With Python: Two of My Favorite Lenses":

half-scratched-out bpython logo, Python code, and technical prose written and drawn on paper, with notebook and pen, on a wooden table that also has a mug and a laptop on it

MergeSort, the feminist maker meetup I co-organize, had a table at Maker Faire earlier this month. Last year we'd given away (and taught people how to cut and fold) a few of my zines, and people enjoyed that. A week before Maker Faire this year, I was attempting to nap when I was struck with the conviction that I ought to make a Python zine to give out this year.

So I did! Below is Playing with Python: 2 of my favorite lenses. (As you can see from the photos of the drafting process, I thought about mentioning pdb, various cool libraries, and other great parts of the Python ecology, but narrowed my focus to bpython and python -i.)

Zine cover; transcription below

Playing with Python
2 of my favorite lenses
[magnifying glass and eyeglass icons]

by Sumana Harihareswara

Second and third pages of zine; transcription below

When I'm getting a Python program running for the 1st time, playing around & lightly sketching or prototyping to figure out what I want to do, I [heart]:
bpython & python -i

[illustrations: sketch of a house, outline of a house in dots]

Fourth and fifth pages of zine; transcription below

bpython is an exploratory Python interpreter. It shows what you can do with an object:

>>> dogs = ["Fido", "Toto"]
>>> dogs.
append count extend index insert pop remove reverse sort

And, you can use Control-R to undo!
bpython-interpreter.org

[illustrations: bpython logo, pointer to cursor after dogs.]

Sixth and seventh pages of zine; transcription below

Use the -i flag when running a script, and when it finishes or crashes, you'll get an interactive Python session so you can inspect the state of your program at that moment!

$ python -i example.py
Traceback (most recent call last):
    File "example.py", line 5, in 
        toprint = varname + "entries"
TypeError: unsupported operand type(s) for + : 'int' and 'str'
>>> varname
3
>>> type(varname)

[illustration: pointer to type(varname) asking, "wanna make a guess?"]

Back cover of zine; transcription below

More: "A Few Python Tips"
harihareswara.net/talks.html
This zine made in honor of
MergeSort
NYC's feminist makerspace!
http://mergesort.nyc

CC BY-SA 2016 Sumana Harihareswara
harihareswara.net @brainwane

Everyone has something to teach;
everyone has something to learn.

Laptop displaying bpython logo next to half-scratched-out bpython logo, Python code, and technical prose written and drawn on paper, with notebook and pen and mug, on a wooden table

Here's the directory that contains those thumbnails, plus a PDF to print out and turn into an eight-page booklet with one center cut and a bit of folding. That directory also contains a screenshot of the bpython logo with a grid overlaid, in case you ever want to hand-draw it. Hand-drawing the bpython logo was the hardest thing about making this zine (beating "fitting a sample error message into the width allotted" by a narrow margin).

Libby Horacek and Anne DeCusatis not only volunteered at the MergeSort table -- they also created zines right there and then! (Libby, Anne.) The software zine heritage of The Whole Earth Software Review, 2600, BubbleSort, Julia Evans, The Recompiler, et alia continues!

(I know about bpython and python -i because I learned about them at the Recurse Center. Want to become a better programmer? Join the Recurse Center!)

Filed under:


: iCalendar Munging with Python 3, Requests, ics.py, and Beautiful Soup: Leonard and I love seeing movies at the Museum of the Moving Image. Every few months we look at the calendar of upcoming films and decide what we'd possibly like to see together, and put it on our shared calendar so we remember. And for every showing (example) the MoMI provides an iCalendar (.ics) file, to help you add it to your electronic calendar. But it's a pain to individually download or refer to each event's .ics file and import it into my electronic calendar -- and the museum's .ics files' DTEND times are often misleading and imply that the event has a duration of 0 seconds. (I've asked them to fix it, and some of their calendar files have correct durations, but some still have DTEND at the same time as DTSTART.)

Saturday morning I had started individually messing with 30+ events, because the MoMI is doing a complete retrospective of Krzysztof Kieslowski's films and I am inwardly bouncing up and down with joyous anticipation about seeing Dekalog again. And then I thought: I bet I can automate some of this tedious labor!

bash terminal showing the successful output of a Python script (a list of movie titles and "Calendar ready for importing: MoMI-movies-chosen-2016-09-26.ics") So I did. The create-fixed-ics.py script (Python 3) takes a plain text file of URLs separated by newlines (see movie-urls-sample-file.txt for an example), downloads iCalendar files from the MoMI site, fixes their event end times, and creates a new unified .ics file ready for import into a calendar. Perhaps the messiest bit is how I use a set of regular expressions, and my observations of the customs of MoMI curators, to figure out the probable duration of the event.

Disclaimers:

Much thanks to the programming ecology that helped me build this, especially the people who made RegExr, Beautiful Soup (hi Leonard), Requests, ics.py, and the bpython interpreter, and the many who have written excellent documentation on Python's standard library. Thanks also to Christine Spang, whose "Email as Distributed Protocol Transport: How Meeting Invites Work and Ideas for the Future" talk at Open Source Bridge 2015 (video) introduced me to hacking with the iCalendar format.
Filed under:


: New Essay: "Toward a !!Con Aesthetic": Over at The Recompiler, I have a new essay out: "Toward A !!Con Aesthetic". I talk about (what I consider to be) the countercultural tech conference !!Con, which focuses on "the joy, excitement, and surprise of programming". If you're interested in hospitality and inclusion in tech conferences -- not just in event management but in talks, structure, and themes -- check it out.

Christie Koehler also interviews me about this and about activist role models, my new consulting business, different learning approaches, and more in the latest Recompiler podcast.

[announcement cross-posted from Geek Feminism]

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:


(3) : Star Wars: The Force Awakens: I saw the original trilogy many years ago and just don't remember a lot of stuff. I was maybe sixteen; I missed my window for really loving it, in keeping with that old saying, "The golden age of science fiction is twelve." And then I saw Phantom Menace -- standing in line for it and all -- with my then boyfriend, when it came out, and then we had our first real argument, because I didn't like it and he did. Past Sumana, bewildered and frustrated in that dorm hallway, you are not wrong, basically the entire critical consensus agrees with you, and someday you will learn to trust your own aesthetic judgment.

In any case: even though I'd never seen Episodes 2 or 3, and I barely remembered the others, The Force Awakens was totally accessible and fun for me. I walked in as someone who thought Boba Fett was one of Jabba the Hutt's names, and I was fine.

I've heard that -- to trufans -- there's sort of a red herring happening in The Force Awakens about someone being set up to be the next Jedi. I did not see it, and I think one reason is that I don't know anything about what the harbingers of Jedi are, but also I think it's because I am such a nonfan that when I am watching a Star Wars movie I do not automatically think "ah there will have to be a new generation of Jedi, so who will it be?" It has not soaked in for me that Star Wars is fantasy and that the way we solve problems is by finding and training people sensitive to the Force. I have Star Trek in my DNA instead (like Leonard) so I assume that the way we solve geopolitical problems is by, like, being transgressively inclusive and making good arguments.

P.S. Does "TFA" mean Star Wars: The Force Awakens or two-factor authentication? In my upcoming fanfic on security in lightsaber summoning, both! Although I may need to figure out whether the Force is something you have, something you are, or something you know.

P.P.S. I will not be writing that fanfic, but you go ahead and feel free. Happy new year!

Edited to add at 11:45pm PT: OK, I wrote the fanfic. "Security Question" is about why a young Jedi apprentice can't shortcut the anti-theft system on the lightsabers by Force-summoning the two-factor auth token itself.

Filed under:


: Yuletide Treasure Reveal: "Pops Real Nice": Fanfic authors started a Secret Santa-style gift exchange, "Yuletide", in 2003, concentrating on fandoms that don't have that much fic written about them. This year, for the first time, I participated. Now that the authors' names have been revealed, I can announce: I wrote fic about two songs by the Mountain Goats!

Pops Real Nice (2194 words) by brainwane
Chapters: 1/1
Fandom: The Best Ever Death Metal Band in Denton - The Mountain Goats (song), Beat the Champ - The Mountain Goats (Album)
Rating: General Audiences
Warnings: No Archive Warnings Apply
Characters: Animal Mask, Original Male Character(s), Original Female Character(s), Cyrus (The Best Ever Death Metal Band in Denton), Jeff (The Best Ever Death Metal Band in Denton)
Additional Tags: Wrestling, Zines, Psychologists & Psychiatrists, Divorce, Texas, Utah - Freeform, Transcribed, Inspired by Music, Friendship, The Mountain Goats, John Darnielle - Freeform, All Hail West Texas
Summary: After the events of "Animal Mask." Before, during, and after the events of "The Best Ever Death Metal Band in Denton".

Enjoy "Pops Real Nice" and the making-of endnotes (including thank-yous to my beta readers) at Archive Of Our Own (brought to you by the Organization for Transformative Works).

I received a sweet Babysitters' Club fic, "(Not) Like Uber but for Babysitting", by cbomb, which took my prompt and ran with it. It made me cheer (as in, cheer out loud) when I found out that BSC is deliberately setting itself against the "sharing economy" trends of Uber, Airbnb, et alia by making its babysitters' treatment a first-class priority. Awesome, and in keeping with the values we've always seen in BSC!

Thanks to everyone who makes Yuletide happen.

Filed under:


: More Zen Cho, and History in Hamilton: People who read this blog will probably like the stuff I've been posting on the Geek Feminism group blog. I wrote a bit more about Zen Cho's Sorcerer to the Crown in October, covering "Cruciat-ish, or, Magic and Microaggressions", "The Diasporan Ugly Duckling", and "All The Fun Bits". And then, in November, I wrote a list of reasons why Hamilton appeals to geeky feminists -- including its user experience affordances.

I took some of those concepts and developed them further into my first-ever piece for Tor.com, "The Uses Of History in Hamilton: An American Musical". It compares Hamilton to Drunk History, Hark! A Vagrant, 1776, the HBO John Adams miniseries, Ginsberg's "America", Hughes's "Let America Be America Again", Sassafrass's "Somebody Will", and science fiction in general, and considers its narrative approach and metatextuality. I also link to a few great pieces of Hamilton fanfic.

Filed under:


: What Software Freedom Conservancy Does, Why It's Important, And Why You Should Give: I appreciate the work of the Software Freedom Conservancy, a nonprofit that helps free and open source software projects. Right now they need 2,500 people to become Supporters to keep their work going. So I made a video about why I support them, using language and examples that you can understand if you're new to this topic. It's embedded below, along with the text script I spoke from.

This month, I'm volunteering to help raise money for the Software Freedom Conservancy. My local bookshop does something cool for the holidays: volunteers wrap gifts for free, and any tips from the customers go to a charity that the volunteer gets to choose. So I've been explaining to the customers (most of whom aren't technologists) that I am donating their tips to the Software Freedom Conservancy.

My one-sentence explanation: The Software Freedom Conservancy is a nonprofit that helps programmers give away their software for free.

If they are curious, I explain further:

One way they do this is by being a nonprofit umbrella. Developers who want to make software and give it away often need a way to take donations and spend them on stuff like travel (to see each other and work face-to-face). Setting up their own nonprofits would take a ton of time and paperwork and filing fees. So the Conservancy takes care of all that, handling the accounting and stuff like that.

Another thing they do is license compliance work. You see, if you just write something, then automatically, the license that applies is standard copyright. But programmers who want to give away their software do it by saying it's under a different license, one that says, it's fine for you to copy this and look at the code and change it and even give it or sell it to other people, as long as you let other people do the same thing, too. But there are some companies that don't follow these rules. They maybe reuse these things that other people gave away, and package them into a phone or a tablet or something, and then they close it up. They don't let other people see that code -- they don't give other people the same chance that they benefited from. So the Conservancy follows up on that, sends them legal letters that say, "hey, that's illegal, that's not fair, don't do that."

And another thing they do is, there's this internship program, a paid internship program called Outreachy, to help get women and other underrepresented groups into this part of the tech industry. You see, most internships in the software industry are paid -- it's not like a lot of other industries. We gotta pay these interns to help them get into this part of the industry. So the Conservancy is the nonprofit umbrella for this program, and handles the finances so that companies can donate money and the interns can get paid.

That's my explanation. I'm glad I can help tell people about this great nonprofit and the unique work they do. And it really is unique. So if you or people you care about have benefited from the Conservancy's work, or if you just think it's a good idea, please give them $120, or whatever you can, during this fundraiser, and spread the word. Thank you.

Technologists might also like Matthew Garrett's "GPL enforcement is a social good" and Mike Linksvayer's thoughts on his favorite Conservancy accomplishment of 2015.

Please give -- right now, there's a match available that will make your gift count twice!

Edited 6 February to add: The donation match runs till 1 March 2016. Please give.

Filed under:


(3) : Announcing Changeset Consulting: I'm delighted to announce the launch of my new business. I am the founder of Changeset Consulting, LLC.

Changeset provides short-term project management services to free and open source software projects. Need to expedite the releases of new versions of software, write developer onboarding and user documentation, triage and respond to bugs, clean out the code review queue, or prioritize tasks for upcoming work? Changeset Consulting lightens the load on your maintainers.

Details about the services I offer, my past work, and useful resources I've made are at http://changeset.nyc. I'm seeking new clients and would love referrals.

For now the shop is just me, but I'm aiming to have enough income and work by summer 2016 to hire an intern or apprentice, and to eventually hire full-time staff. We'll see how it goes.

I highly recommend Galaxy Rise Consulting, the firm I hired to design my website. Much thanks to Shauna Gordon-McKeon, and to all the friends and family who encouraged me on my way here!

Filed under:


: A Month, Ish: I have been fairly low-volume on this blog lately. Some stuff I've been up to:

I wrote a Geek Feminism piece about feminist tech demos I saw at a showcase in New York City. I also asked the Geek Feminism book club what we want to read next, and then posted some thoughts on Zen Cho's Sorcerer to the Crown. I'll be posting more about Sorcerer to GF this week.

I wrote fanfic about Star Trek: The Next Generation and current events.

I helped spread the word about a bunch of openings for UX experts, developers, and sysadmins at the New York Public Library.

For the first time, I've signed up to participate in the Yuletide Treasure fanfiction exchange (my "Dear Author" letter). I'll get my assignment by November 1st and I'm pretty curious -- this experience will inform my answers to my question: What would a "Secret Santa"-style gift exchange along the lines of Yuletide Treasure look like in other parts of open source or open culture?

Leonard and I finished watching The Legend of Korra and I read Ancillary Mercy (my review), and I got most of the way through Stone Butch Blues by Leslie Feinberg. I listened to the entirety of Gimlet Media's show StartUp and cried at the end of the second season. And I got super into the musical Hamilton, getting to see it for $10 via the lottery for front-row seats, buying the cast album, and listening to it many, many times. I've started posting thoughts about it in the Hamiltunes community on Dreamwidth. For those of us who miss The West Wing and good Star Trek it fills quite a void.

Leonard and I hosted various visitors. I cooked a few dishes I'd never cooked before. I cycled places (my longest ride on this bike so far: from Astoria to Park Slope and back, about twenty miles) and learned how to clean and lube the chain. I worked on business planning and started talking to leads. I got used to a Jolla phone running SailfishOS (it's a little underfeatured but improving steadily).

In perhaps the most boring news at all, I'm trying out the world of the standing desk, using a stack of books to raise the laptop to typing height; I'll have to take out Gooseberry Bluff Community College of Magic by David J. Schwartz from this pile in order to finish it.

Filed under:


: Software In Person: In February, while coworking at the Open Internet Tools Project, I got to talking with Gus Andrews about face-to-face tech events. Specifically, when distributed people who make software together have a chance to get together in person, how can we best use that time? Gus took a bunch of notes on my thoughts, and gave me a copy.

Starting with those, I've written a piece that Model View Culture has published today: "Software In Person".

Distributed software-making organizations (companies, open source projects, etc.) generally make time to get people together, face-to-face. I know; I've organized or run hackathons, sprints, summits, and all-hands meetings for open source projects and businesses (and if I never have to worry about someone else's hotel or visa again, it'll be too soon).

Engineers often assume we don't need to explicitly structure that time together, or default to holding an unconference. This refusal to reflect on users' needs (in this case, the participants in the event) is lazy management. Or event organizers fall back to creating conferences like the ones we usually see in tech, where elite men give hour-long lectures, and most participants don't have any opportunities to collaborate or assess their skills. Still a bad user experience, and a waste of your precious in-person time.

Why do you think you're spending hundreds of thousands of dollars holding hackathons, sprint weeks, and conferences? And how could you be using that time and money better?

Subsections include "Our defaults", "Investing for the long term", "Beyond 'hack a lot'", "Grow your people", and "Setting yourself up for success". Thanks to Gus and to Model View Culture for helping me make this happen!

Filed under:


: My Eulogy for Nóirín Plunkett: A few hours ago, I spoke at Nóirín's memorial service. This is what I said (I am sure I varied the words a bit when I read it).


My name is Sumana Harihareswara, and I will always remember Nóirín's compassion, insight, and bravery.

They were brave to publicly name and fight back against wrongs done against them -- by members of the open source community -- wrongs done against them and others; I think it is not exaggerating to say that their bravery galvanized a movement. Our open technology community owes them a debt that can never be repaid.

We also benefited tremendously from their insight. Nóirín had just started a new role at Simply Secure, one that combined their expertise in open stuff with their writing and coordinating skills, and their judgment and perspective. And before that, when they worked as a project manager for the Ada Initiative, I had the privilege of working closely with Nóirín; I am grateful for that, but of course now I know what I'm missing, what we're all missing, because I had the chance to see, every day, their diligence and insight and discretion and judgment and empathy, and compassion. Some of us lead like engineers, by making systems that scale; some of us lead like nurturers, cultivating relationships and trust with emotional labor. Nóirín was brilliant at both of those, and I wish I could have decades more to learn from them, and toss around more ideas and frameworks.

The last time I saw Nóirín was at WisCon, a feminist science fiction convention in May. One morning I came down the hotel stairs and saw them seated against a wall, crying, sobbing, because Ireland had just passed a referendum legalizing same-sex marriage. They were so happy that their friends and loved ones and everyone back home were now freer to marry and have their families recognized that they'd gotten a glass of champagne from the hotel restaurant, at maybe eight in the morning, to celebrate. They felt deeply the joy and suffering of others.

Nóirín, I miss you, and I will try to live up to the example you set. Thank you.

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:


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


: New Vid: Pipeline: I've made a new fanvid: "Pipeline". It's a little over 3 minutes long and cuts together about 50 different sources (documentaries, movies, TV, comics, coding bootcamp ads, and more) over Taylor Swift's song "Blank Space". My launch blog post on Dreamwidth goes into more detail and includes links to download it. You can stream it at Critical Commons (choose View High Quality for best experience) and I embed the video below:

It's CC BY-SA; please feel free to redistribute, link, remix, and so on, as long as you attribute me as the vidder and distribute your changes under the same license. Comments are welcome, though moderated.

Filed under:


: Missing Women in FLOSS Philosophy, and Borrowing Models from Fandom: I've arrived in Madison for WisCon! And just in time for WisCon:

I have a blog post up (in two parts) focusing on the frameworks that we free software/open source folks often take for granted, what might have been erased from our FLOSS intellectual heritage due to sexism, what FLOSS might look like under a different approach, and what practices and perspectives we might borrow from the fan fiction/fanvidding realm of speculative fiction and media fandom.

Part 1 is up at Crooked Timber as the guest post "Where are the women in the history of open source?" Part 2 is up at Geek Feminism as "What if free and open source software were more like fandom?"

Please feel free to comment at CT or GF.

Filed under:


: Recompiler, Passionate Voices, Book Club, A Soviet Spy, and More: A few announcements:

We have three days left to fund The Recompiler, a new technology magazine that will combine tutorials and technical articles with personal narratives and art. My household has now funded this campaign and I hope to attend the launch party in Portland next month. I particularly loved seeing (via the video on Indiegogo) that 2600 is one of the inspirations for The Recompiler. 2600 has many virtues, but it pays people in a free t-shirt or a year's worth of issues of the magazine. I am looking forward to seeing The Recompiler pay people to write "you can totally do this, here's how" high-quality technical articles.

My old boss Erik is running a new video interview series called "Passionate Voices" and kicked it off by interviewing me (72 minutes); if you are interested in my work on inclusive communities, my thoughts on codes of conduct, and my reflections on the Recurse Center, you might want to watch this.

In about ten days, I'll be leading a Geek Feminism book club on Courtney Milan's Trade Me -- read the first chapter free online, get hooked, and snarfle down the rest by May 28th so you can participate in the comment thread.

Also on Geek Feminism, I posted a quick note about the word "girl" in the name of superhero Supergirl.

Finally: I met some pretty interesting people via the Columbia master's program I did. And for several years, I've known Jack Barsky as a mentor, a tech executive, and a friend. He's now the subject of a profile by 60 Minutes because, no joke, he used to be a Soviet spy. This guy who gave me important advice, who always got to the heart of the matter and had super emotionally honest conversations with me, has a past that sounds beyond melodramatic. I was not aware until this month of all the twists and turns within his story, and I am honestly still processing it. Give it a look.

Filed under:


: My Thoughts on Two Ken MacLeod Works: Crooked Timber invited me and other writers to discuss the work of science fiction author Ken MacLeod. Thus, I have a new post up at CT: "Games, simulation, difference and insignificance in The Restoration Game & The Human Front". Henry Farrell, Farah Mendlesohn, Cosma Shalizi and Jo Walton have joined me in writing about various aspects of MacLeod's work, and after their posts go live, CT will also be publishing a response by MacLeod.

My post includes a joke about Trotsky's death and a note about what the year 1947 means to me (not Roswell), and starts:

I had, frankly, been afraid of trying to read Ken MacLeod, because I wasn't sure I had the prerequisite domain knowledge. I studied Russian and majored in Political Science at UC Berkeley, and wasn't sure that this had given me enough expertise on the history of Communism to jump into his work. Now that I've overcome this fear, I should check whether there's a market for a MOOC, "Remedial Ken MacLeod Prerequisites," in which I discuss leftism in the twentieth century, MacLeod's crony and former Big Pharma dispenser Charles Stross, and the landscape of rural Scotland, or, "Reds, meds, and sheds."

Check it out! Comments are live over on Crooked Timber.

Filed under:


: New Takes On My Published Writing: My Crooked Timber guest post on codes of conduct, freedom, governance, contracts, and copyleft software licenses has attracted over 200 comments. Many of them are thoughtful and interesting, and worth at least a skim if you found anything useful in the original post. For instance, can we compare mindshare to other forms of property? And what do we do to legitimately obtain the enthusiastic consent of the governed? Some of them have old or new perspectives on Adria Richards or Linus Torvalds. And about five percent of the comments are gross, hurtful, or laugh-out-loud wrong on multiple axes, e.g., "The FOSS world is not asking for codes of conduct, she is seeking to thrust them upon it." I shall be mining those for use in my stand-up comedy routine at AlterConf in Portland, Oregon in June.

Also, the code4lib Journal asked for me to turn my code4lib keynote from 2014 into an essay, "User Experience is a Social Justice Issue", for their special issue on diversity in library technology. The new article includes some contextual introduction and a retrospective with links to related work by others in the past year. You can comment there.

Filed under:


: Crooked Timber Guest Post on FLOSS Licenses and Codes of Conduct: The social sciences group blog Crooked Timber has published my guest post, "Codes of conduct and the trade-offs of copyleft".

A lot of open stuff -- such as the Wikimedia/Wikipedia and Linux projects -- are discussing or adopting codes of conduct, or expanding their existing policies. I'll reveal my biases at the start and say I think this is a good thing; for more, read my speech "Hospitality, Jerks, and What I Learned". But in this piece, I want to talk about the similarities and differences between codes of conduct and a set of agreements that some of these communities are more used to: "copyleft" or other restrictive software licenses. And I'd like to draw out some ways that the kinds of acts and artifacts that these policies cover reveal different attitudes towards contracts and governance.

Also I make silly references to Antitrust and Ducktales while oversimplifying free software licenses and political theory. So check it out.

Much thanks to Skud for an initial conversation about face-to-face versus online codes of conduct; my article, in the end, barely addresses that, but it was a seed for this piece. Thanks to Henry Farrell of CT for editing and publishing my guest post. And thanks to Naomi Ceder, Paul Tagliamonte, Leonard Richardson, and several other people who talked about this topic with me or beta read bits or drafts of the piece -- of course, all errors are mine.

Feel free to comment over at Crooked Timber!

Filed under:


: My Family And The Ada Initiative: Please join Leonard and me in donating to the Ada Initiative. Why? Let me tell you a story, and then a surprise.

My parents came to the US from Karnataka, in south India, in the 1970s, and they were lonely. They spoke Kannada and English and Farsi and Hindi and Sanskrit, but Kannada was their mother tongue, and they arrived in Oklahoma and found no Kannadiga community to speak of. (Go ahead and groan. My dad passed on his love of terrible puns to me.)

An Amerikannada envelope and my parents' wedding photoI'm not saying they were the first Kannada speakers in the US. There were definitely already Kannadigas in the US in the 1970s. Indians had been immigrating here for decades.* There were letters and long-distance phone calls and occasional visits, a few families getting together, the adults laughing and swapping tips in Kannada while kids ran around. But the Kannada-speaking diaspora was scattered and had no central place to talk with each other. A bunch of people who shared a characteristic, but not really a community.

So my parents did some community organizing, in their spare time, in between working and raising my sister and me. How did they get Kannada speakers together? They started "Kannada Koota" local organizations (like user groups). "Koota" means "meeting" in Kannada. They basically started a grassroots network of Kannadiga meetups. How did they get these folks talking to each other, all across the country? They started a bimonthly magazine, Amerikannada, and ran it for 7 and a half years, until their money and energy ran out. It had great fiction, and articles from the literary magazines back home. And it included ads for those Kannada Koota meetups, "how I started a Kannada Koota" articles, and tutorial exercises for "how to learn Kannada", for parents to teach their kids. My parents were sharing best practices, talking meta, inspiring people all over.

I didn't really know that, as a kid. As my parents processed subscriptions, recruited articles and ads, wrote, and edited, my sister and I stapled, stamped, glued, and sealed bits of paper in languages we couldn't quite yet read. We had a rubber stamp with the logo: a griffin-like creature, half-lion, half-bald eagle. I gleefully deployed those magical bulk-mail stickers, red and orange and green with single-letter codes, and piled envelopes into burlap sacks and plastic bins for the frequent trips to the post office.

An Amerikannada envelope, my dad's employee badge at a nuclear power station, and the Rajyotsava award he received for service to the Kannada languageIt was always my Dad who took the Amerikannada mail to the post office. He was strong in those days, heaving the great bags of mail like an Indian Santa Claus (mustache yes, beard no) alongside the blue-uniformed workers on the loading dock, the part of the post office most people never use or even see. My sister and I came along, not to help -- how could we? -- but to keep my Dad company.

At home, while toying with BASIC on a PC Jr, I overheard the shouted long-distance phone calls in mixed Kannada and English. Stuff like "Go ahead and give me the directions to the venue, and I'll tell it to Veena." or "Well you know who you should talk to? Raj is going to be over there around then...." Weekend after weekend I spent reading science fiction in some corner at a Kannada Koota.**

My father receiving the Rajyotsava award from the government of Karnataka. From Kannada WikipediaThe funny thing is that I thought I was rebelling against my parents by taking the path I did. I majored in political science at Berkeley instead of engineering, and fell in with open source hippies. I used AbiWord on Caldera Linux to write papers about nineteenth-century American political theory and naturalization rates among Indians in Silicon Valley. I fell away from coding and saw that other things needed doing more urgently: tech writing, testing, teaching, marketing, management.

And here I am now, a community organizer like them, finally appreciating what they did, what they made, what they gave up. My dad had to work to support us; he couldn't edit Amerikannada full-time, even if that would have been a better use of his talents, and a greater service to the world. My parents couldn't find enough ads and subscribers to pay for the cost of keeping the magazine going. I appreciate WordPress and PayPal all the more because I see that Amerikannada folded (partly) for the lack of them.

My momWhat if one of my parents had been able to bring in income from the community we were building? What if it had been sustainable?

Today, the community that I most identify with is that of women in open source and open culture. We've talked to each other in pockets and locally for decades - hats off to LinuxChix and VividCon, for instance - but in the last few years, The Ada Initiative has brought us more resources, a stronger community, and faster progress than ever. And this is possible because the Ada Initiative's staff is full-time.

So, here's the surprise: Leonard and I will match every donation to the Ada Initiative up to a total of USD$10,000 until midnight August 27th PDT, one week from today. Yes, again. And this time, if the community matches the full amount, we'll chip in an extra thousand dollars.

The Ada Initiative's work is useful in our own lives. When I needed an anti-harassment policy for my workplace's technical events, and when Leonard wanted resources to advise his technical communities on diversity, we consulted the Ada Initiative's resources. AdaCamp brings together, teaches, and inspires women from all over, including me. And the network I found via the Ada Initiative helped me write a keynote speech and respond to unwanted touch at a hackathon.

But more than that, we know that we're improving our world and helping science fiction, open source, and Wikipedia live up to our values. We believe in inclusiveness, compassion, empowerment, and equal and fair treatment for all, and the Ada Initiative opens the doors for more women to get to enjoy those values in the places we love.

And my parents taught me that I should give back. It feels so much better to give back than to give up.


* One couple who moved from Gujarat to California in 1958 had a son who's now a Congressman.

** Nowadays I get to be the only Kannadiga at science fiction conventions.

Filed under:


(2) : Thoughtcrime Experiments, One Year Later: Today is the one-year anniversary of Thoughtcrime Experiments, the free scifi/fantasy anthology Leonard and I edited last year.

Thoughtcrime Experiments cover

Thoughtcrime Experiments got a bit of recognition in the form of award nominations. We made the British Fantasy longlist (voting closes 31 May). The Variety SF blog loved Ken Liu's "Single-Bit Error" and considered it one of the best short stories of the year. And Patrick Farley's "Gaia's Strange Seedlike Brood (Homage to Lynn Margulis)" has made the Ursa Major shortlist. We'll find out if he won next month.

Another form of recognition was the sharings, remixings and adaptations we hoped would happen when we released Thoughtcrime Experiments under a Creative Commons license.

LibrisLite, an ebook-reading application, includes our anthology as a free sample book. Marshall T. Vandergrift made a hand-crafted ePub edition, Arachne Jericho made ePub, Kindle/Mobipocket, Microsoft Reader, and Sony Reader editions, and manybooks.net provides the book in many formats. Andrew Willett's short story "Daisy" received a lot of love this way, including an audio recording read by Ian McMillan and an upcoming project I can't mention yet. A fan also read it aloud at a storyreading party.

Mary Anne Mohanraj and Sumana Harihareswara at WisCon in 2009(To the right: E. J. Fischer's photo of me with Mary Anne Mohanraj, author of "Jump Space.")

We were also gratified to see people thinking about, reviewing, enjoying, and linking to individual stories and illustrations.

"Jump Space" by Mary Anne Mohanraj got substantial thoughtful attention, such as Rachel Chalmers's review:

"Even cooler, the story they sort of chose for me is "Jump Space", which I purely love. It's a head-on collision between the Heinlein juvenile adventure stories I adored as a kid - the Have Spacesuit Will Travel or Space Family Stones - and a thoroughly 21st century set of attitudes towards love, sex, dating one's professor, marriage, faithfulness, jealousy, prostitution, slavery and even raising children (my main preoccupation these days and one that Heinlein tended to rather idealize...)

Erica Naone's review of "Jump Space", in part:

I think the anthology is trying to explore a wider variety of human elements and viewpoints than are seen in the typical science fiction anthology...

Mary Anne Mohanraj's "Jump Space" has some of the most fully realized relationships that I've seen in science fiction.... the theme of love's simultaneous strength and fragility was emphasized against the backdrop of space. Love and family seem even more accidental and precarious when the universe is so large.

Mohanraj wrote a post about what she did wrong & right in "Jump Space". Hugo Schwyzer posted about "Jump Space" and academic ethics (specifically, on initiating professor-student romance), to which Mohanraj replied.

Rachel Chalmers's review continued:

I liked "Jump Space" so much that I was startled to find a story in Thoughtcrime that I liked even better. It is "Single Bit Error" by Ken Liu. Can't tell you much about it without spoiling a rather excellent surprise, but wow, it's just a stunner. Weaves together theoretical computer science and existential philosophy in a way I've always thought could be done, but never quite managed to do or see anyone else doing...

You should allow for my extreme bias in favor of my friends; despite this utter lack of objectivity I recommend this anthology to anyone who's interested in the best and bravest modern science fiction.

Bio Break by Brittany Hague(To the left: "Bio Break" by Brittany Hague.)

Kit Brown wrote: "I really liked Daisy by Andrew Willett and Single Bit Error by Ken Liu. I also loved Robot vs Ninjas by Marc Scheff and snagged it to add to my desktop wallpaper rotation."

Erin Ptah's illustration "Pirate vs. Alien" also got some attention: "More silliness may be found in this picture by Erin Ptah, wherein a buxom pirate battles a well-endowed alien who appears to be preparing to give himself a shave."

Lynda Williams says of "The Ambassador's Staff," a short story by Sherry D. Ramsey: "Well put together, goes down smooth, and captures my feelings about too little sleep and too much coffee, to boot. Allegorically speaking."

Sam Tomaino calls Thoughtcrime Experiments "an anthology filled with stories that I enjoyed thoroughly". And Jane Irwin of Vogelein liked it, especially "Daisy".

Erica Naone's thoughtful reviews of several Thoughtcrime Experiments stories are another useful resource; I can't quote them all here or they'd take up half the post!

One manybooks.net reviewer says:

When I saw the "mind-breakingly" description, I thought to myself, "No way, that is just too ambitious." Well after reading the first five or six stories, I must say I agree. This seems to be another example of really good authors publishing under the Creative Commons. Welcome to the future.

Other readers posted about the Creative Commons and DIY facets of our project interesting:

rollicking....The anthology wears its DIY cred on its sleeve and even has a how-to appendix and all the source code for the website is gank-able. It’s available as a free download or POD book. Keep Circulating the Tapes!...

They're publishing because they want to give back to the community. They have no illusions about reaping financial gains from these transactions, and that's okay. We all do things for love that we would never do for money....

The point of Thoughtcrime Experiments is its punk/hacker ethic. You don't have to wait for Gardner Dozois or any of the other 'masters of the genre' to make an anthology for you, you can go out there and do it yourself. If you can't find a magazine publishing SF you'd like to read, and feel they're all publishing the same tired stuff, Much like their punk predecessors at 'Sideburns' they have an appendix on "How we did this". It's the three-chord diagram for a revolution in SF.

Now, it probably won't catch on. Just because punk happened, doesn't mean one can start a revolution every time one is needed. But imagine if it did. Imagine if the kids started getting together, and producing their own SF magazines. Imagine if SF became, for some small portion of the population, the new rock-and-roll, or at least the new indie-rock....

But it's not just the anthology that's interesting. Leonard used this entire project to better understand the editing process. His conclusions are quite interesting for writers. Basically, that we don't suck as bad as we think we do just because we get so many damn rejections...

Times Square by David Kelmer(To the right: "Times Square" by David Kelmer.)

Another author talked about our anthology while considering commodification, scarcity, and publishing. And Freedom to Tinker noted,

Still, part of the new theory of open-source peer-production asks questions like, "What motivates people to produce technical or artistic works? What mechanisms do they use to organize this work? What is the quality of the work produced, and how does it contribute to society? What are the legal frameworks that will encourage such work?" This anthology and its appendix provide an interesting datapoint for the theorists. (See Leonard's response.)

Jed's repost of our call for submissions, and his announcement once we were out, also commented on the ripples our project might send out: "So I'm hoping, as Leonard and Sumana are hoping, that in addition to providing a good read, this anthology will inspire others to embark on new publishing ventures."

If you want our thinky thoughts about the whole venture, you might be interested in Sharon Panelo's interview with me, my length anthology retrospective and thoughts on scifi publishing, more such, and Leonard's many interesting posts on the stories, the process, and what we learned about the field. And I hope we get that Hour of the Wolf radio show interview up for download/reading sometime soon.

To finish up the link roundup: Grasping in the Wind, BoingBoing, Tor.com, John Scalzi, Baby Got Books, and Locus also notified their readers of our existence, for which we are grateful.

The book's still up. Read or download it for free, or buy a paperback for USD5.09 plus shipping. I'm arranging to have about seventy copies for sale at cost at WisCon.

If I missed your review, please post a link in the comments!

Filed under:


: Let's Hear It For (Labors Of) Love: Here is another narrative of my WisCon: something I learned from editing and publicizing Thoughtcrime Experiments, and what that makes me want to do next. It's long (the longer the post, the more I feel I'm leaving out), but there's some filk silliness at the end. (Title hat-tip to the Smokin' Popes; cue up Destination Failure while reading this, it'll take about that long.)


I arrived with ten copies of Thoughtcrime Experiments and nearly immediately gave away or sold them. I probably could have sold fifty, if I'd had them. I made about 200 copies of my flyer (seven-megabyte PDF, used a canned iWork Pages template) and people eagerly took them. I got to show contributor Alex Wilson Erica Naone's reviews of the stories, including her review of his "The Last Christmas of Mrs. Claus." In the "Was It Good For You?" panel, I mentioned three stories that made me feel unusually at-home: Connie Willis's "Even the Queen," my fellow panelist K. Tempest Bradford's "Élan Vital," and Mary Anne Mohanraj's "Jump Space" from the anthology I just published, squee!

Throughout the convention, people sounded receptive when I chattered about the anthology. Several people told me how exciting they found our project, and a few made noises about following Leonard's instructions and conducting the experiment themselves. And a few people said: "what are you doing next?" or "when you do it again next year..." A flattering boost and a natural assumption, but not a completely justified one.

Do I want to do it again? Good question!

In the "Was It Good For You?" panel, I observed that some editors and authors start with a vision they need to express (my nickel version of auteur theory), and some start wanting to respond to a community's need for certain viewpoints or stories. The way Leonard and I divided up anthology work reflects that division. He did line edits, pushed for more variety in the art, exhausted himself tweaking the layout to perfection, indeed conceived the project in the first place. I publicized the call for submissions, recruited artists, read slush and wrote rejections, and promoted the finished book electronically and in person.* My revealed preferences: sociable work. I want my work to make others happy. (When we got the first galley proofs from CreateSpace, I said it's real. But the reality of the literary marketplace is socially constructed, and foisting Thoughtcrime publicity onto hundreds of minds at WisCon transmuted the book into something more real.)

But how many people experienced any happiness from Thoughtcrime Experiments? A few thousand downloads and page hits, maybe ten thousand fleeting "oh it's neat that they did that" impressions. Is that enough? Would I spend my energy on a sequel anthology for a readership of less than, say, fifty thousand?

I mean, when I promoted the call for submissions, and when I went to WisCon, I couldn't help but see how many quality small presses and mags our genre enjoys. Shimmer, Goblin Fruit, GUD, Ideomancer, Small Beer, Electric Velocipede, Clarkesworld, Andromeda Spaceways Inflight Magazine**, Strange Horizons***, Verb Noire, Aqueduct... I'm just going off the top of my head. Some are electronic, some are print, some are more regular than others, but it's not like any one part of Thoughtcrime is new. Rejected Quarterly plus Creative Commons licensing (already done by Stross/Doctorow, not to mention Strange Horizons & others) plus easy online reading (several abovenamed pubs) plus good payrates (several again) plus gumption (passim). Thoughtcrime is a tiny fish in the pond.

When I see us in context, of course we've gotten maybe 4 emails of praise and 10 blog mentions from people who don't know us. What kills me is how little attention all these presses get. If Leonard weren't an author seeking markets, he wouldn't have started Thoughtcrime, and I wouldn't have heard of most of these presses and magazines. I'd see Tor's and Orbit's stuff in the bookstores, and maybe if BoingBoing or Tor.com or Making Light**** said something really positive about a particular story online I'd go click.

The ease of publishing doesn't mean readers automatically get hooked up with content they'd enjoy. Publishing is a binary switch, off to on, and new technology makes it cheaper to pull that switch. But publicizing -- marketing -- is analog, and really lossy. I'll only persuade a percentage of my desired audience to go read x, and I'll only ever hear about the fraction of that percentage that somehow signals back. Logs and analytics just tell me about impressions, not lasting impressions.

I am like the googolith person to observe, "it's a shame awesome indie stuff doesn't get as much mindshare as the mainstream does! It is almost as if having a large, established, for-profit publishing apparatus is good at turning capital into reputation, accessibility, and distribution!"

But just as I should be less in love with originality when appraising my past work (so what if Thoughtcrime did no one new thing? It combined a bunch of those things for the first time and it's a damn fun read), I don't have to put auteur-y novelty first on my priority list when allocating my future efforts. Why should I just turn five or nine stories from 0 to 1 on the publishing meter when I could get thousands of great stories from 1 to 2 or 5 or beyond?

Well, that "beyond" would be pretty tough. One assessment that sounds oppressively real: "The problem for SF writers and publishers today isn't that there's not a mass audience for high-end SF storytelling; it's that there are immense numbers of other diversions on offer for those hundreds of millions of people." Why should a person read at all, and if she reads why should she read the particular work I adore and want her to read? What particular need would I be uniquely fulfilling in her? Because that's where marketing starts: identifying or arousing a need.

I can reckon how a person might go about increasing the mindshare of any given indie scifi publisher among people who already consider themselves scifi fans. It's never been a better time to be a publisher or a cheapass reader; Amazon, Bookmooch, ManyBooks, Goodreads, DailyLit, the Kindle, blogs like Tor.com and BoingBoing, and other resources help hook up readers with the abundance of awesome fiction that already exists, for free, online. (If you are a cheapass scifi reader and you are saying, "Where do I start? SHOW ME THE FREE STORIES," Futurismic's Friday Free Fiction weekly roundup will get you started.)

Indie publishers still need a little marketing to get into many of those channels. Search engine optimization, some tech hairdressing, and time writing the equivalent of press releases come to mind. I can see a path to getting a rabid scifi fan to taste something new. I'd grow the market a little (rewarding!), but also displace the readership of my rivals, Big Publishers and other small presses (kind of disheartening!). I actually don't know how zero-sum the economics of this project would be, and am curious; I'd want to collect a lot of metrics, and set a quantitative goal in hopes of avoiding existential despair.

But the project of turning nonreaders into occasional sci-fi readers, and occasional readers into rabid readers? Unsolved and incredibly exciting. I'm wondering who else is doing this, and how; comments welcome.

I would like to make the pie higher, as the saying goes. Thoughtcrime Experiments will never be a huge slice of it in any case, and I'm not so delusional as to think it's objectively the tastiest portion.

So Leonard and I have different ideas for what's next (not that either of us is about to start anything; our jobs, writing, travel, friends, worries, etc. are consuming us for now). He's tentatively interested in doing what Brendan dares us to call Again, Thoughtcrime Experiments. I'd help again if he wanted. We found stories we loved and made them more real, and I love doing that. But my ambitions point me in another direction: scaling up.


* It wasn't till like three months into Thoughtcrime that I realized I was following in my parents' footsteps. My parents did a zine! Amerikannada, the literary magazine my parents ran for several years, printed fiction and nonfiction by the Kannada-speaking diaspora in the United States. The Amerikannada logo was a hybrid eagle-lion. They've been editing and writing and celebrating Kannada literature for decades, but I remember Amerikannada specifically because I got to help with kid-friendly mailing chores. After Leonard and I had an argument about art direction, I felt like I'd unlocked a memory of another editorial argument, conducted over my head as I pasted stickers to envelopes in the rec room of the first California house. I have no idea whether that's memory or invention, and indeed know nothing of how Mom and Dad divvied up the work, ran submissions, decided on timetables, or made any of those editing/publishing decisions I now find fascinating. I should ask them.

** You can sing "Andromeda Spaceways" to the same meter as "American Woman." As long as you're here: "Goblin Fruit" works as "Stacey's Mom" ("Goblin Fruit / is made of hemp and jute") and I always want to sing "Clarkesworld" to the tune of "McWorld!" from those old McDonald's ads.

*** Strange Horizons is a special case all on its own. When I started realizing that they've been publishing quality fiction and nonfiction weekly for more than seven years, paying pro rates, and generally been ahead of every curve I thought I was exploring, I couldn't believe that I hadn't been a fangirl earlier. I'm feasting on archives now, especially their reviews. You can start with Anathem and Little Brother, and then see if you find this analysis of Ted Chiang's work and this West Wing analysis as thought-provoking as I do.

**** I have been reading the Nielsen Haydens for like six years or more. Patrick and Teresa taught Leonard at Viable Paradise, and Patrick gave Leonard advice before we launched the anthology. We thanked them in the acknowledgments to Thoughtcrime. Teresa reminds me of my late mother-in-law, Frances, in a lot of ways. And yet, and yet.***** Nora speaks better than I could.

***** I meant to write about WisCon racism discussions weeks ago. Explanation seems impossible, so I'll sum up. Thank you, Rachel Chalmers, for putting my head straight when I saw you in January. Thanks to all the antiracists who have put spoons into this discussion, in education and anger both. And thanks to WisCon 33 and its participants, for being the place where I had drinks and panels and meals with uncountable fans of color. (Pleasantly disorienting: the meal where I was the only heterosexual and the only monogamist but not the only woman or person of color.)

My perspective on race in fiction has shifted. The short edition: if you write or edit or critique fiction, looking out for lazy racism is no longer optional. Analogies: 1. The feminist infrastructure is strong enough that sexist writing gets a bunch of flack, and the antiracist infrastructure is getting there. 2. An antiracist lens is going to be a usual mode of critique from now on. This is part of the new normal. The discourse has shifted. Someone trying to pretend this is a fad or a personal attack is like the RIAA lashing out to protect business models that no longer work. Some thoughts on problems and solutions in an upcoming post, I hope.

Filed under:


(1) : Thoughtcrime Experiments Anthology Is Up: Nine new original stories, five new original artworks, and an essay on how and why we did it. Read it online, download the PDF, or (soon) buy the print-on-demand book. Link, download, read, and remix away -- it's all Creative Commons-licensed.

There isn't a theme, really, just "what we like." It turns out that we like political satire and family drama and detective thrillers and fables and fable deconstructions and the mysteries of debugging. It's all good stuff and we hope you like it.

Filed under:


: A Tiny Anthology: If you liked my most recent poem (the Linton Johnson one about BART), you might like these:

Most of these are sonnets on various schemes.


Edited 25 Nov 2010 to add my Garrison Keillor event introduction.

Filed under:


(4) : Poem: "BART Spokesman Linton Johnson": I wrote this in September 2008.

BART spokesman Linton Johnson
You speak for the trains
You must say so many things
Joyous and doleful
When the trains are stopped
Or when ridership is up
Or when the stations cry out for murals or bleach
You hear what the tunnels say
They whisper in your ears as you ride
Like a regular passenger
Out of uniform, out of sight
The seats and the cars plead with you
The turnstiles and ticket machines click and tick
As you watch the security cameras
They thank you for saying what they cannot
Each conductor drives one train
And announces its stops and destination
Only you sing of BART the whole
From Dublin to Pittsburg to Fremont to Richmond to SFO
Your heart MacArthur, centered above the freeway
Sing of the vessels that carry us from desk to bed
Speak for the trains
BART spokesman Linton Johnson
Filed under:


(3) : Two 101-Word Stories Inspired By Fred von Lohmann's Talk Last Night:

O'Porter

Most clients sounded more stressed and less grammatical than this guy. "Why did YouTube take down a video without soundtrack music? I didn't break any copyrights, did I?"

"You came to the right effing lawyer," O'Porter smirked, though technically EFF had fired him when he kept calling Seth a "Latin hunk." "Let's see it."

The stranger clicked Play and swiveled his laptop. O'Porter watched hamsters and tried to hear the words under the strange hiss --

Seth David Schoen closed the lid, peeled off his mask, and walked away from O'Porter's body. Really, breaking the Content-ID tool was just a bonus.


Venky

"I'm saying, 'Leibnitzian Python wonder-language that contains no ambiguity' was a JOKE, not a spec."

"So he was a jester-philosopher, the Birbal of his day."

"I think Colbert, Haskins or Stewart --"

"If code is law, shouldn't law be code? And who'll port it but us?"

"But it's the Cyc problem. We write legislation using subjective moral distinctions that change over time. Barring Seldon-level sociological prediction, your version 1 architecture is going to include something as abhorrent to future Americans as slavery is to us. Worst. Legacy. Code. Ever."

"Not if CSAIL works with us," said the dean of MIT Law.

Also inspired of course by Leonard and by Brendan. Very much not inspired by anything Seth or anyone at the Electronic Frontier Foundation has ever done.

Filed under:


(5) : Skills And Lenses: A few models I've happened upon recently:

I started thinking about these models while chatting with friends and acquaintances near and far. Man, sociability is awesome.

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.