Changing communities have changing needs with Andy Piper

amanda casari: Hello, everyone. My name is amanda casari. My pronouns are she/her. It is 27 June, 2024. Today I’m here with Andy Piper. Andy, hello. Can you briefly introduce yourself, please?

Andy Piper: Hi, amanda. As you say, my name’s Andy Piper. I am based in the UK. I’m a freelance technologist. I have done a ton of work with open source projects throughout my career. I’m a techie and I love people and community, I guess is the easiest way to describe myself at this point.

amanda casari: I’m very excited about this. Andy and I were chatting a little bit before we started the recording. We were talking about things that start to bring us good feelings, warm fuzzy feelings. I think that’s what we’ll be focusing on today. Kicking that off, I’d like to ask what’s bringing you joy this week, Andy?

Andy Piper: What is bringing me joy?

amanda casari: Yes.

Andy Piper: Yesterday, I met face-to-face, for the first time, one of my colleagues on a project that I’m working on right now. We’d only seen each other through video calls before. They are in London right now. We were able to just say “hi” yesterday evening and that was lovely. It’s always great to make those in-person connections. This evening right after this conversation, I’m going to go to the Open Web Advocacy meetup in London as well and see some people who are passionate about open standards. I am as well. I’m looking forward to that. The sun is shining in the UK this week, which is always a great thing as well. Those are things that bring me joy.

amanda casari: Oh, fantastic. I have to ask, are you still surprised when you meet people in person for the first time that you’ve been working with online? I am still surprised sometimes at their height, regardless of how tall they are. However tall they are in life in my brain, has somehow maybe been set at eye level by my monitor height, I’m not sure what it is, but I’m still surprised every single time by any person’s height when I meet them for the first time now.

Andy Piper: I think that’s exactly right. Then yesterday my friend didn’t actually recognize me. They were stood within almost arm’s distance of me outside a building. They’d messaged me saying they were going to be running a little bit late. I saw them look around, take out their phone, and message me on Discord and I was just waving in their face. There’s still that disconnect sometimes between faces on a screen or avatars, little messaging icons in chat, and what people actually look like in real life when they’ve had an actual day in public.

amanda casari: That’s fantastic.

Andy Piper: It was fun.

amanda casari: We always force ourselves to share these things too, as part of the conversation that Julia and I still, I think are working on individually. [laughs] This is somewhat ridiculous, but this is, I think why this is bringing me joy. I know everybody has different ways that they like to make beverages for themselves. I have gone through many different kinds of coffee makers.

Many different people give me lots of different kinds of technology to create things. I still use a stovetop coffee maker. Then I like to microwave my milk [chuckles] but I have to keep an eye on it because otherwise, it bubbles to the point that it bubbles over. I want it just to the point that it’s about to bubble over, which makes everybody in my household laugh because I sit there watching it until it’s about to actually go over the top, and that’s when it’s actually at the correct temperature, depending on the volume and the foam. No one has been able to replicate that for me with other kinds of different technology.

It makes me laugh every single time of just like, “Yes, you’re going to spend at least 85 seconds plus or minus depending on the milk and the day every day watching your milk bubble over.”

Andy Piper: You mentioned that, it brings to mind a memory of mine from my childhood, probably in the ’80s of a relative, one of my great uncles visiting. I think I was watching some food in a microwave. He came up to me, and said, “Don’t look in the microwave.” He thought that the microwaves were going to come out and fry my eyes or something. Anyway.

amanda casari: I remember when microwaves first came out. Our favorite thing to do as small – children was put your nose right up on the screen, especially when popcorn was-

Andy Piper: Exactly.

amanda casari: -going off, and also got the same warnings of like, “No, you’re going to cook your brain if you’re too close.” [laughs] Which just teaches me that maybe our conversations around technology and humanity consistently could be improved.

Andy Piper: That’s right. There’s always a learning curve around something new to get around. Then once you are up to speed on how things actually work, for me, there’s both a joy and a responsibility in explaining those things to others in a non-threatening way so they don’t feel quite so alarmed by this magical new thing that may otherwise be scary to them.

Excitement highlights opportunities

amanda casari: Is there anything that you are most passionate about lately that you like explaining to other people, whether it’s about open source, technology, or work you’re currently doing?

Andy Piper: I know I’m passionate about the OpenSocial web. At the moment, I’m working with the Mastodon project. I lead developer relations for them at the moment. It’s obvious that that would be a good thing for me to be passionate about, and I am. But, I have to say that this particular conversation in terms of explaining the OpenSocial web to people, why it’s good, why it’s valuable, and why having decentralized technologies that cannot be owned by an individual and subverted is a bit of a tiring one, I’ll be honest with you. I am joyful about it.

I’m excited about it. I really strongly believe that independent social web technologies that give everybody the opportunity to own their own content, their own data, or their own network are the future. There is, I think a technical– I know there’s a user friction in explaining that to people and people getting on board with it, understanding how best to use it, not being frustrated because it’s a bit more difficult right now than what they’re used to. I am excited still to have the conversation. I have to say that I do sometimes get a bit tired of it, but I do keep coming back to it, and keep standing up and saying, “You know what? You all need to be thinking about this.”

amanda casari: Is there anything that specifically resonates with folks who have the most fear right now?

Andy Piper: I think it’s the opportunity to be interoperable. The opportunity that I can share something on a picture-sharing site like Pixelfed that can be seen and reshared from my Mastodon account, for example. I think certainly the identity piece is something that we can do better in that space because I’m racking up a whole series of social web ActivityPub service based accounts right now. I get it because I have one for video, one for photos, one for my tech stuff, one for my blog, but it would be better if all of that came together somehow.

We haven’t, I think as an open source community figured out how to do that yet. That’s an opportunity. That’s what smart people in open source communities get to collaborate on. It’s exciting.

Community building is changing

amanda casari: How have you been building community for, and with, Mastodon and with other of the social web organizations or people who are contributing, how has that been going for you and how do you find more people when you’re looking to see who’s to become more than a user?

Andy Piper: Thanks for asking. It’s really challenging because, and I think this is true of open source in general, there’s a ton of politics involved especially because there’s a ton of projects involved and there’s an overall vision, I think for ActivityPub and the social web that this stuff is decentralized, and we have the opportunity to own our own networks, and all those other bits of business.

But to some extent, there can be friction where a project is seen as bigger, smaller, or more dominant than another. That is challenging. My approach has been to come on board with the project, say, “Look, you’re all focusing on building the platform, running a platform, making a good user experience for people. Love it. Very happy with that. Let’s talk about how we can improve our documentation, our support, our partnerships, how we can improve the experience for people building on top of the platform.”

My previous lives, I’ve done a lot of developer relations roles. I have a view that if you’re building a technical platform like Mastodon– I used to work at Twitter, and I helped with the API there. I worked at IBM and worked with MQTT as a protocol there. It’s the people that are passionate about those protocols and that then go on to build libraries in their favorite languages on top of them that really expand the opportunity for people to get involved because IBM was never going to build MQTT implementations in every language that existed for every context that existed. They were going to focus on the things that mattered to their enterprise customers.

Twitter came out with an API very early on and then just said– it was originally a single page. It was I think the developer’s page on the original 2006 twitter.com and it just said, “If you call this, then you’ll get this bit of XML back,” because XML was a thing before JSON. People picked that up and people went away and built Java and C libraries and then carried on, Python and Rust, and other things came along further down the line, which hadn’t even been thought of back in 2006.

Those community of people had taken the time to get interested and involved and find all the speed bumps and gotchas in the API implementation, tell the company or the platform about it. Also by making that available, they suddenly enabled all these other people to go build that next layer of apps, those data visualizations, those third-party clients. One of the things that I get excited about Mastodon, and I also have done it previously, is platforms typically don’t really focus on accessibility, but there are a community of users that really care about accessibility.

Either because they have their own needs, maybe they’re partially sighted, maybe they really rely on assistive technologies of some kind, or something else. The platforms are going for the broadest possible audience. Those, what I will call niche because they are a smaller community of people with those assistive technology needs, those niche communities are not generally catered to, but you get passionate people that say, “Well, okay, give us the tools and we’ll go ahead and build you a screen reader or something that helps different communities.”

All of that is a long-winded answer to the question because the first thing I did at Mastodon was to say, “Okay, let’s get our list of third-party libraries up to date. Let’s figure out who’s been keeping up with the platform. Let’s figure out who’s done more than just build something for themselves, put it up on GitHub, and then not do anything with it. Let’s figure out the people that have built a library in a less used language, or that have built one or two libraries that are really heavily used and make sure they’re spotlighted. Make sure they’re easy to find. Make sure we’re talking to them and helping those developers because they are our greatest assets and our allies to help us grow.”

That’s how my focus has been to talk to the people building on top and say, “This is what we are working on, how can we help you? These are the reasons why we can’t do the things you want to do right now, but we are listening.” That’s part of the community building from my perspective, it’s on the technical side. I also care about having more humans beyond the technical community using the platform. Then it’s about talking about my own experience, what have I got from it? What have I gained from it? Who am I talking to? What experiences have I had?

It’s almost a micro Open Source Story on Mastodon. It’s like what’s my experience been in the last couple of years? I’ve also been using Mastodon since it came onto the scene since 2016, 2017. What have I learned? How do I use it? What are my tips and tricks that you might have heard of?

amanda casari: I love how you really emphasized also when you were talking about technology maintainers and types of projects. It was interesting there because you talked about technology and people and then went back to people. I loved how you talked about, when you talked about types of projects, the way that you categorized and thought about really checking in with people who create open source projects on what are your expectations and the boundaries that you want to set for how much your work is used, where it’s shown, where other folks want to come and get involved.

Where did you just want to make a thing and put it out there for someone else to use because I think that when technology is looking at picking up for different platforms, and I know I’ve seen other work from folks about this, sometimes it’s hard I think to understand that really truly some people they just want to make a thing and put it out. Some people it’s part of really their own identity of how they see themselves as a part of their work. When you just go look at a repository page, it’s not always clear maybe the differences between those and you have to be, I think very careful when you’re working in large-scale projects, how you connect with those.

On differing needs

amanda casari: Is there anything you could share of how to be thoughtful of connecting with communities and maintainers that you would recommend for other folks when you’re working across projects and ecosystems, either for maintainers to help have that conversation with people about, “Here’s my expectation of how you’re going to use things,” or for people approaching them? How can you respond with care and understanding of: this might be their whole life and it might not be their whole life?

Andy Piper: That’s really interesting and you asking me that question has made me stop and think a little bit. I can talk about something that we’ve just done on a project I’m working on and I’ve done in previous projects, which is we’ve just updated the contribution guide, the contributing.md. I also tried to tidy up the GitHub organization landing page for the project to make it a bit more visual, give people a little bit more steer to the key repositories, code of conduct, and so on.

One of the things for Mastodon has been around contributions that it’s a very small team, but it’s got a massive user base. Everybody has an opinion, wants a particular feature, but at scale as we build new versions and make those new versions available, that we want as many people as possible to upgrade to as quickly as possible, usually because there could be maintenance needs, security needs, and so on. We want everybody ideally to have a similar user experience, of features, but as we do that, we can’t easily just ship a load of new features each time and there’s two reasons for that.

One is new features means more potential bugs and instabilities and so we don’t want to give ourselves too many of those to deal with in each release. The other thing is dissonance for users. Suddenly you are faced with an entirely new release with loads of new features, you’re not going to learn about all of them. I sometimes think about this in a very close source sense, which is the iPhone. You think back to the first iPhones, they had very few features.

They’ve added features to the operating system over time and now because we’ve had the opportunity, if we’ve been using one for a long time as I have, a lot of stuff is second nature, but I’ve learned it over the years, not all at once. That’s a user dissonance thing.

So, that contributing guide, especially in our case where we’ve got a small team and we can’t do everything at once and we have to take things steadily in order to enable everybody to have a hopefully stable experience on the platform is really important. We hadn’t always done a great job explaining the process for the fact that more than one person does reviews and discusses a pull request and a feature. That was one thing that I think any project can do or should be doing if they want contributions: tell people what your expectations of those contributions are. Have a code of conduct, have a contributing guide. Lay out how you want people to talk to you.

The flip side of that is an experience for me as a participant because I recently got involved or wanted to get involved with a project. I went to an event called Electromagnetic Field which is a big open source and open technology celebratory festival here in the UK every two years. It’s a little bit similar to Chaos Computer Camp and some of the other big ones around Europe. I built a little device there and I got really excited about it and I thought I’d love to help build, learn more about it, do more stuff with this software, and in the case of that software, their community is heavily chat-based.

It’s quite difficult to find information or find up-to-date information because there’s an expectation that you are participating in a chat. It turned out that actually because the project had had a bad experience where somebody had wanted to fork and make changes or kind of siphon off a community, they’d chosen to make elements of their software not open source. There was a great sense of tension between how much information they gave you and how much opportunity you had to go in and openly send in pull requests, send in issues, make changes to wikis versus their, I think understandable, previous experiences.

As a user, in my case, I really wanted a lot more clarity around what the entry points to that project were and I didn’t really find them. I think just trying to enable that is my lesson here. I don’t think, though, that– especially if you’re an individual doing an open source project and suddenly you had loads of people coming to you to contribute, talking to those people is obviously a big distraction from what you might want to be doing, which is to go and build a project, or go write some code, or go test some things, or go have a cup of tea and read a nice book because you’ve put some code on the internet, as you said earlier on.

I think there’s an interesting tension between those two sides of the story there.

The needed work isn’t always full of glamour

amanda casari: Do you think it’s easy for folks who are working in open source to see and understand if they do need help? What kind of help– You mentioned the contributing guide, contributions sometimes are– and you’ve probably seen me or heard me talk about this for a very long time, contributions exist in so many forms. When someone is thinking of asking for help, do you think it’s easy for folks to know what kind of help they need or what kind of help they could even ask for that they may not see elsewhere? Is it easy for folks to parse that out, or do you think that that’s something that we still have some work to do on?

Andy Piper: I think it is something we have work to do on. I think that quite often I hear somebody say, “Oh, I’m no good at design, so I really need a user interface designer.” They set an expectation on themselves, “I’m no good at X, therefore I need Y or somebody with X skills to come in and help me.” I think there’s a ton of other skills there like project management, community management, documentation, writing.

Actually this is getting to an element of the roles that I bring to projects quite often, which is almost– I’ve heard them described as janitorial roles, which makes it sound to some extent like they’re perhaps low-paid or perhaps badly treated sanitation worker type tasks. By the way, I think that people that keep our offices clean and look after us in all kinds of other ways are super important in my life. I want to make it clear that I’m not belittling those kinds of roles.

I think they are really important, but those kind of roles in the sense of an open source project, the people that are willing to do those kind of roles, to figure out which bugs are duplicates of others, to do some triage, to try to bring a bit more quality and rigor into processes– A lot of developers, in my experience, just want to write something cool and do something fun, and, “Works on my machine, ship it.” Again, I’m not treating all developers like that, but it is a sense of excitement that you have when you build something new. I think that leads you not to think of every single angle and that’s fine. I unfortunately, partly, always say it’s because I’m British and cynical, and just downtrodden by default, and look on the downside of everything, and this is a joke, obviously, but I tend to come in with all of the hard questions and say, “Have you thought about these other things?”

Sometimes you do need to think about, “Should we ship this feature before we’ve thought about all of the safety issues, or the security issues, or the downstream impact on other projects that are consuming our library or whatever? How do we handle a release process? How do we do communications? Who are our key partners?” Depending on what scale of project you’re in and whether you’re in a corporate-sponsored project or something like that like I was when I was doing Cloud Foundry at VMware.

Who are the partners that are consuming the services that we’ve built that need to be well informed of a change to our database or something? All of that is to say there’s a ton of different roles and ways in which people may need help, may have not thought of, and may not be aware of. For me, as somebody who’s been doing job labeled “developer relations” for 15 years, developer relations has a range of different capabilities, depending on your angle.

It could be marketing, it could be business partner management, it could be documentation writing, it could be technical support, or it could be going and waving hands on stage, which I’m prone to do when I have the opportunity, to get people excited about your project. There’s a whole scale of range of things that somebody with those type of skills can come in to help on a project with. It’s your choice as a project maintainer, project leader, how to [crosstalk] deploy them.

amanda casari: I love how you identified all of the different– I agree with you. I think developer relations, “devrel” for short, becomes this bucket of the “Can you do, please?” I think it gives you an opportunity, either at companies or with projects to look at and identify things that no one thought to ask for and no one realized was a problem. And then you get the opportunity to say, “Can I help solve this, either based on my skills or what I can learn, or who I can find to come help with things?”

Flexibility helps drive success

amanda casari: I’m curious, Andy, what are you most proud of in your work in open source that nobody thought to ask you to do, but you saw as a need, and either brought someone in and connected into a project, or were able to help fill that gap when you saw it was there?

Andy Piper: I’m going to rewind back to my MQTT days, and I’m still a big advocate and fan of the protocol. IBM had this standard or this notional standard. They’d written a specification for a protocol and they’d said, “Here you go, we’re going to publish this and it’s going to be royalty-free.” They didn’t do any more than that. They didn’t actually take it to a standards body initially and they didn’t– I think they released sample code in C and Java because they were their corporate languages back in the early 2000s. That was it essentially.

There was an expectation that “Hey, people will pick up this specification,” because the people they wanted to use this low-level protocol would be capable of doing that. To some extent that happened, but there wasn’t any particular effort to advocate it, or even initially to move it into a standards body, to move it into an open source home. I think it may be argued how much I had to do with it as an individual. I certainly pushed hard for IBM to formalize that, moving it out beyond the walls of the company and into, as it was, the Eclipse projects that became the initial open source implementations. Then go to OASIS to get the protocol standardized as an open process. Actually, that was as I left the company in 2012. I was able to continue working on the protocol after I’d moved to another employer, VMware, Foundry at the time, because it was open source.

I was running the mqtt.org website. I was involved in talking about it in public, which a lot of IBM’s engineers weren’t easily able to do because of their day job or because of fears of contamination from coming in from external sources, maybe seeing a competitor’s code that may have become blended, and all those kind of things that IBM was very fearful of at that point in its history. I think that stuff that I’m very, very proud of, and I don’t think anybody at IBM was thinking about particularly until it started to become self-sustaining externally and started, “Oh, actually people are using this.” That’s something I’m particularly proud of.

There’s a ton of little things about just times when I’ve come along to a project and said, “What’s the license here,” or, “Where is your community?” “How can you do this better?” These are the problems I’ve had with trying to consume your project. How can we bring this stuff together in a more consumable way?” [crosstalk]

amanda casari: That’s fantastic. I love how the story told by MQTT really has the cascading effects that are happening of the– you saw the need for one part and then pushed for the next, and then pushed for the next, which then enabled you, when you were external to IBM – that starts to affect change back in the direction that you came from. I think those interactions that build on each other, it’s a part too where looking back later, you can see– I think it gets described externally by people as maybe where you got lucky.

I feel like that minimizes your experience, expertise, and the ability to notice in a situation that something might need to be discussed. I appreciate that luck absolutely does exist. [chuckles] It also exists on top of a mountain of experience and coincidence and community and expertise and technical knowledge and in knowing people. I think sometimes we get in conversations where someone, just because you’re in the conversation, you get an opportunity to ask the question.

Andy Piper: I think knowing people and also connecting people, rewinding again a little bit to something you said earlier about how, for example, developer relations can help, if they can’t write a particular sample project or something, then there’s a good chance because of their network in the community, that they can find or promote that to people that can come in and help. The other thing or a role I found myself playing is that invisible glue in organizations, who knows all the people in all the different departments that can join people up, who may not have known that the other was working on this particular thing.

I find that challenging in my current context ActivityPub because again, there’s a such a variety of work going on in so many different projects, and I’m not part of all of them. I try to lightly take part in the standards conversations and talk to the Mastodon team day-to-day, but I don’t talk to every other project that’s building on ActivityPub. To use a somewhat dated term, there’s a lot of known unknowns. I sometimes struggle with that because I’m the information person, and I like to be able to [crosstalk]

amanda casari: I realize, I’m so sorry, but we’re at the end of our time. I have so many more questions for you we didn’t get around to. Thanks. Before we go-

Andy Piper: Actually, a great conversation.

amanda casari: -any departing thoughts for folks who would be listening or should be listening?

Listening to others is squidgy but vital

Andy Piper: I think the thing that I have taken away from my experience in open source, overall, and developer relations has just been growing my personal sense of empathy and trying to reduce my sense of entitlement because I see so many different experiences. I think that just be prepared to have a lot of patience, listen, and recognize that your experience is not the only one that matters in a room. I think that those are my thoughts that I’d like to share with folks.

They maybe don’t seem massively actionable and a bit fluffy, but people and software, and community are all squidgy and fluffy and sometimes there isn’t a solid “do this and everything will be fine” answer to anything. Have patience and listen.

amanda casari: I very much appreciate that and I think we can all use that reminder consistently, and even myself can use that. I could probably put that on my hand and carry it around with me and it would do me quite good. Thank you again, Andy, for joining us on Open Source Stories today. It was so nice to have you.

Andy Piper: Thank you.

The story was facilated by amanda casari and edited by David Jones.