-Hello everyone.
My name is Julia Ferraioli. My pronouns are she/her. Today is October 26th, 2023,
but really it's like still 2020, right? [chuckles] Today I'm speaking
with Shauna Gordon-McKeon. I'm recording this conversation
for Open Source Stories and it's a lovely crisp day
in Seattle today. I heard a rumor
that we might be getting snow soon, so I've got my fingers crossed. Shauna,
would you like to introduce yourself? -Yes.
Hi, I'm Shauna Gordon-McKeon. I am coming at you from Washington DC. Where it is 70 degrees and hard to imagine
it will snow anytime soon. Last year it did not snow
at all the entire winter, which was a bummer. So I am hoping for some snow this year. -I spent some time in DC myself
and snow was one of my favorite parts, -so I'm--
-Yes, there's been snow in the past. DC is more famous for its sweltering,
humid, and hot summers, but it does usually get snow. It's just last year there was no snow. Hopefully,
we will get some this time around. -I'll cross my fingers
for both of us then. -Excellent. -Before we dive in, what has gotten you excited lately? This can be something in industry, this can be the trees turning,
whatever you like. -I was recently on a different podcast
and I talked about women's soccer. Now, I feel like
it's going to become my shtick is that whenever people ask me for
my non-open-source, non-tech thing, it's always going to be women's soccer. I am really excited. I signed up for a soccer clinic
with Ashley Hatch, who is one of the star forwards
of my local team. She is a US women's national team
bubble player so not a star. Sorry if Ashley Hatch
is ever listening to this, I don't know why she would. You're a star in my heart. She was not on the World Cup team,
but she was almost on the World Cup team. Anyway, she's doing a charity clinic
for local players. I signed up
and so supports local youth soccer and then I get to learn a little bit
about soccer from elite soccer players. That's pretty cool.
Pretty psyched about that. -That's amazing. It sounds like
it's going to be an awesome time. -Yes. Generally speaking, the lack of support and investment
in women's sports is a total bummer. Every once in a while
you get a benefit like this where there's a level of access
and experience that you can get because you don't have just huge numbers-- these players deserve huge numbers of fans
clamoring for these opportunities, but unfortunately they don't get them
for the most part, which is better for me as a fan because I get to do these
clinics and stuff. So it'll be really fun. I will learn a ton, I'm sure, because I am not a particularly
good soccer player, so I imagine Ashley Hatch
will have a lot to teach me. -I wish you luck. The last time I played soccer, I got kicked in the stomach and so I never went back to the field. -That's unpleasant.
I could see why you wouldn't come back. -It's my brand
is getting hit by sports balls even when I'm not playing with them -or playing them.
-Yes, that's fair. -[chuckles]
On a completely different note, I know you from the overall
open-source governance world and I'm wondering, what are your thoughts
around governance these days? How are you thinking
about governance in open source? -I have been interested
in open-source governance for about five or six years now. How I started getting interested
in governance was, in 2017 there was an open-source project
that had a BDFL, which is Benevolent Dictator
for Life model of governance. This person had unfortunately passed away
and they were like, "What do we do now?" How decisions got made,
how conflict got resolved, it was all in this one person
and they're not in charge anymore. Should we just replace this person
with another BDFL? Should we do something more democratic? We want to do something more democratic,
but how or what? They wanted an outside facilitator
to come help with that. I hadn't really done
anything like that before but I think it's still generally true
that there's not a lot of people with a ton of expertise
in open-source governance. That was especially true in 2017. I got asked to help and I was like, "I am new to this. I am not an expert,
but I would certainly love to try." That was such a huge
learning experience for me. Also really clarified for me that the success and long-term
sustainability of projects really depends a lot
on the community around the project. That in turn is so influenced
by how decisions get made, how conflict gets resolved. All of these governance questions. To me, governance is not something
that's completely separate from the work of software development. Often the questions around who makes
decisions, those decisions are like, what should the API look like? What should the architecture look like? What things should we support? They're technical decisions that have real-world consequences and thus people get
into conflict over them. How do you decide who
is going to work on what, what is going to be prioritized? All of these questions to me
fall under the rubric of governance. I've actually been
trying to come up with a term that's a bit more expansive
because I think governance is-- On the one hand, I really want
to rehabilitate the term governance. I think people hear the word governance and they think about
partisan gridlock in Congress or they're like
a local school board thing, which is extremely tedious. They're just like people associated
with bureaucracy and badness and they're like, "Oh, I don't want
to have anything to do with it." I do want to rehabilitate
the term governance and make it something that people
are actively thinking about. I also tend to think more
expansively than just like, who is in charge? How do they make decisions and into more questions around
how does information flow? What are the power dynamics? How do people influence software
and software influence people? All of that messy stuff. I haven't got a good term for it. If you or anyone listening to this
has some ideas for terms, I feel like it would be nice to be able
to talk about it a bit more articulately. -We need a branding expert to really get ahold of that particular group of concepts. -Yes. -How decisions get made, it's a very small part of actually building software
and building communities. It's how people work together. Which has so much wrapped up in it from communication mechanisms
to norms to pretty much everything,
culture, et cetera. There's so much wrapped up there. -I also think,
when we say decision-making, I think people tend to think it's always easier to think
about the most formal version of something because when you formalize something, you're making it concrete
and legible and visible to people. I tend to use Python as an example because I'm deeply embedded
in the Python community and I just love it. For example,
when speaking about governance, people might think about, "Okay, there used to be a BDFL,
now there's a steering council. They make decisions. Those people get elected by a vote
and that's all very formalized. It's written out in PEPs and it's very clear and visible," but there's sorts of other decisions
that are happening all the time as well. Sometimes they become part
of formal processes if they get important or they get heated, they can come into this formal space. If someone is interested in maybe
contributing to Python, the language, and they look at it
and they see a bunch of men, for instance,
although there are definitely more women than there used to be, and Python is actually doing
a lot to try and diversify. Like many open-source projects,
like many tech projects, there is a gender imbalance. If you look at that and you feel just subtly
inside of yourself, a feeling of unwelcomeness and you decide not to spend your time
learning more about it, you just turned aside gently. That's really subtle. It's really informal. It's only visible to that person and it might not even be
visible to that person because we as individuals
make decisions all the time that aren't fully conscious. It might just be a vibe where we're like, "That's not the vibe I want based purely
on just knowledge of gender dynamics." That's still a decision
that's affecting the community and it could even affect
the technical elements because what if that one person
was going to end up being extremely influential
and a core contributor who does-- maybe they become a release manager. You never know
what that alternate universe is. I think I care about
those subtle, informal, quiet, easy-to-miss decisions too. I think maybe I pay even
a little bit more attention to them because they're so easy to miss because they're not made visible
in the same way that the super formal decisions are. -We do tend to think about things
from the technical perspective, like how do the technical decisions
get made, but there are so many other decisions that get made explicitly or implicitly
throughout the project's lifecycle. -Yes, and they influence each other. I do a lot of work as an open-source community
manager/project manager/developer advocate so I'm often in those spaces where community issues
overlap with technical issues. Something that I have done
on multiple occasions is identified a technical question
that needs to be asked and then attempted to gather
the right people in the room, which can be an extremely
challenging social task because it involves identifying
who is impacted by a given change, making a connection with them,
convincing them it's worth their time to come to this meeting, figure out whether a meeting
even makes sense versus a more asynchronous process. Those decisions that you make around who you're going to try to reach out to, how you're going to try
to reach out to them, how you're going
to facilitate this conversation, all of those influence
what the technical decision is. I think this is
a ongoing problem in open source specifically where open source is generally decently
welcoming of user feedback when the users are themselves developers
and fluent with developer tools. I would much rather try
to give feedback to an open-source project that's got a GitLab
or a GitHub issue tracker than to say Google, which I feel like has never taken
user feedback in its entire life. That's probably not true.
It's very big. I'm sure someone somewhere
has successfully given user feedback. That being said, a lot of people
who use open source are not themselves developers. They're not comfortable going
to an issue tracker and consequently, often there's just
a huge amount of stakeholders who are unable to contribute
to the roadmap of the project, even though their users, theoretically the project
is being built for them. This is for a combination of reasons. Often open source projects
are under-resourced. The maintainers of these projects
might very well want to do that but just don't have the capacity for it. There's also not a lot of best practices or methods for reaching out
to users and making those connections. I think that to the extent
that we can think about software projects
as a community of people, that information is flowing between, I think that's a much richer way
to think about it and it allows us to understand
why certain technical decisions get made. Because the answer might be
because the people in the room who would've influenced the project
to make a different decision, never were there
because of these structural forces. -To go back to your example
of submitting feedback, if you have to go and register
an account somewhere just to provide, oh, this alignment was off
piece of feedback or what have you, that's probably going to dissuade you
from actually submitting that feedback. The project maintainers are missing out,
the project's missing out and then the users are missing out. -Yes, totally. I think even for people
who are very comfortable, I have on numerous occasions
had the experience of finding a problem
with an open source project, and thinking to myself,
"I know how to give feedback. I should go to the issue tracker. I should search the issue tracker to see if this is an issue
someone else has already reported. That's already
at least a minute right there. It might be 10 or 15 or 20 minutes if it's something
that's got a lot of issues and so you have to review
a lot of different issues to see if yours is a duplicate. Then once I do it, I should include
all this information like, what is the expected behavior?
What was the actual behavior? Copy and paste any error message, making sure to remove
any confidential information, which is not usually an issue,
but I always check just in case, put the version number of the project
to make sure to say what operating system I'm on
and the versions of those things. If it's a web-related thing, probably also get the browser
and the browser version. I'm like, "I know what to do
to make the perfect bug report," and I'm often like, "This is going to take
15 to 20 minutes of my time. It is not worth it." There's like a number of issues. For instance, I use Mastodon and I use the ELK client interface
and there's a number of issues where I'm just like, "This annoys me, but it doesn't annoy me enough to spend
15 to 20 minutes reporting the bug." You can make an argument. I think there's an interesting argument
to be made about there is value in-- the fact that I would rather not spend
15 minutes doing on it, reporting this issue is a sign that
this issue is low priority for me because if it was high priority for me, I'd probably spend the 15 minutes
filling out the bug report. That's useful information,
but it would be better if I could still give the feedback
and just be like, "This is super low priority,
but if you think you're going to work on it, I can try to reproduce
the issue or something." Instead, I just don't report at all. Again, this is someone
who has a lot of experience and comfort with reporting bugs via issue trackers and I still don't do it a lot of the time
just because I'm like, "This is too much." Then for someone who's less comfortable, because different people
have different levels of comfort, the barriers that lead to feedback
being left or not are going to be at a different level. I'm more likely to get over
the hump sooner because I have that comfort level but for someone who's like,
"I'm actively afraid of this process because what if they yell at me,
I've never done it before, how does GitHub work?" That's going to be
a much, much higher barrier where probably
they'll only get to that point where they're like, "Okay,
it's either this or I stop using the product entirely,
or maybe even at that point, they'll be like,
"I'm just going to find a product that suits my needs because it's just too much
of a hurdle overall. -We do talk a lot about
reducing maintainer burden and that's where a lot of these
best practices for reporting issues come from but you have pinpointed that the trade-off is user burden to sometimes the detriment of the project. The part that always gets me there is that
the project is never going to know that you decided not to submit the issue. -It's a secret decision
that's not visible to anyone else. -Right.
When we're talking about these social systems,
the interactions, the part of open source and open source governance
that's not visible or well-defined, that absolutely factors into how we think about the overall operations of an open source project. -I think you're really right
to call out the tension between asking too much of the user versus asking too much of the maintainer because there is work
that needs to be done to communicate something
that's fairly complex. As someone who has tried and failed and sometimes succeeded
to fix a lot of bugs in my life, they are often these deep wells
of complexity and so the process of submitting
a bug report, it's-- the maintainer is already going to do
a lot of complex things in order to fix it so it makes sense to be like,
"Let's get all the information that only the user can give and do that," but it's labor
that needs to be done anyway. It's information that needs to be gotten
and so who's responsibility is it to do that? I have a theory,
I've no idea if it's correct, but I think it's possible that through experimenting with what user support looks like
in open-source projects, there is potentially a way
to bridge that gap in a way that doesn't increase the burden
on maintainers but also gives users the support that they need to file bug requests and to otherwise understand
about the project, potentially eventually get involved. You can imagine someone has
such a good experience reporting a bug and creates a relationship
with someone in the project that it actually brings them
into the community. I don't know what that looks like, I don't know
what the best practices are there because I think there are projects that are doing interesting things
with user support, but it's one of those areas that's been so under-resourced,
under-studied, under-appreciated in open-source projects. You can imagine in some ideal world, someone wants to report a bug, they have some easy pop-up form to do it. Someone who is not a maintainer,
someone who's a user support expert, who contributes to the project
by lending their expertise as a user support expert
reaches out to them, talks them gently through the process. If it seems useful that they get the version number
of the operating system, they can be like, "Hey."
It'd be really helpful to know what version of the operating system
you have. Most people do know
what operating system they have. They know whether they have Mac,
Windows, or Linux. They often will not know how to find out
what the version number is, but a user support expert
can walk them through that, and generally be appreciative. Instead of being like,
"Here do all of this." They can be like, "Great.
Thank you so much for that information. I appreciate you taking
the time to do this," and give them that positive feedback because if someone is making the effort, it's good to have that effort
acknowledged and appreciated. I would love to see more appreciation
for user support people. I suspect that if open-source projects
add more explicit user support, then we would find over time,
we would learn things about that process that would enable us to do it better, whether that's understanding what kind of information is more likely
to be needed from different bugs, or figuring out
what initial contact is best for users, whether that's a form, or maybe you start
on social media of some kind. I think there's a lot of potential
for growth there. I think that's part and parcel of the general issue in open-source
where there's a lot of different things that people need, and maintainers are asked to do all of it. Often, the user support person
is just a maintainer, and the maintainer is like, "I am so busy and overwhelmed
and burnt out." We ask maintainers
if there's only one maintainer, and there's no other leaders
in the community, that person is not just doing
the coding or the architecturing. They're the DevOps person,
they are the documentation writer, they are the project manager,
they are the publicity person, they are the user support person. If they're trying to get funding,
they're the grant writer or the marketing crowdfunding expert. We just ask maintainers to do everything
because often they're the only one and there's a lot
of different things to do, but because we think
of open-source software as just code, it's not visible that there's just a huge amount
of different skillsets crossing a wide variety of domains that no one person is going to be
familiar with or good at. We miss all of that and I think a lot of people don't contribute
to open-source because they only think
of contribution as coding but maintainers desperately need
user support help. They need grant writing help. They need publicity help. It's just we just collectively
don't pay attention to it and then maintainers struggle alone
under the burden of having to do it all. That was a little bit of a rant. -I appreciate the rant. It is so true that
the role of maintainer when we think of it initially
as the technical lead, it's the you-must-do-everything role and that is unrealistic. You cannot be the Swiss Army life of your project for all time. Having a user support role within a project
makes perfect sense to me and also brings more people
into contributing to open-source in a variety of different ways. I know that we are technically over time, so I want to give us a final prompt here, which is, what do you hope to see in open-source in this undefined term of all of the open-source dynamics that we have in the next 5/10 years? -This is a great question. I think at a fundamental level,
this is a collective action problem. I think it would be great to have
user support people, and marketing people,
and documentation people, and governance people, all of these skill sets
in open-source projects. Then there's the question of how do you sustain
these projects financially. How do people contribute? To me, I do think to some extent,
it does come back to governance because often, you have--
there are funders in this space, whether it's these big businesses,
or whether it's private foundations, grassroots people, there are resources
that can go to these projects. I think part of what holds back
that flow of resources at times is a lack of accountability because many of these projects
are run by a single person, and those people might be
of impeccable character. If you want to make
a significant investment which for a big foundation
might be a lot of money, but for an individual person, $50 might be a lot of money to them. I think in some cases,
people are willing to just be like, "I like this tool, here some money,"
but if you want to be like, "I'm going to donate $10 a month," or some ongoing thing, maybe you do want visibility
into what your money is being used for. Similarly,
if you wanted to volunteer your time, knowing that there is accountability,
and you have a stake, and you're able to actually participate
in the overall direction of the project, I think can lead to a virtuous cycle where you're willing
to invest time or money or whatever it is you're trying to invest
because you have the sense of, "There's the project,
I am a participant in the project, it is accountable to me." Not in like,
"They must answer all of my demands," but in a sense of like,
"If I have questions, I can get them answered. If I want things to happen
in a certain way, it might not happen in that way,
but I at least have a forum to express my desire," and that request
will actually be considered, it won't just be brushed aside. I think you can create
those virtuous cycles, but I think in order to create
the virtuous cycles, we need to be thinking about
what governance mechanisms can lead to that kind of accountability
in that stakeholder participation. I don't think it needs to be
super bureaucratic or super complicated. I think there is a lot
of relatively small changes in terms of not needing
to figure out all the details, but just be like, "Okay,
we're still going to have the meeting that makes all the decisions, but now we'll have
an advisory board of people." Then if after a year
of having this advisory board, everyone's like, "This is going great,"
we'll invest them with actual power. That's just one approach. I think thinking about these things and starting to create that accountability
would hopefully-- who knows? I can't predict the future
but would hopefully lead to more people being willing to invest
their resources, their time. Then I think they would have
so many greater knock-on effects on open source if you have the systems
for people committing resources, less burnout, and ability to tackle all of these-- there are so many elements of open source
that open source does badly. I love open-source, but we're not known
for our user experience design. We're not known
for addressing user support. There's all these areas
that get under-resourced. I think if we can level up our governance, hopefully, that would encourage
more people to contribute, which will then enable us
to level up all of these other areas. -No, I love it. I think that everything
you're saying really drives or goes back to the ethos
behind open source, one of which is transparency. In my head, accountability is
very much tied to transparency. Understanding, "Okay,
what goes into the project? What's coming out of it? Where do I see benefit?" Makes perfect sense. I hope that your vision comes true. -Me too. -Thank you so much, Shauna, for joining us today
on Open Source Stories, and I hope we get to do this again. -Yes, me too.