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 21^st and December 21^st. 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)