Transcript

Shane Hastie: Good day, folks. This is Shane Hastie from the InfoQ Engineering Culture Podcast. Today I’m sitting down with Eric Arellano, Nick Grisafi and Josh Cannon, all three from the Pants Build or Pants Open Source community. Folks, welcome. Thanks for taking the time to talk to us today.

Introductions [00:24]

Eric Arellano: Absolutely. Thanks for having us, Shane. My name’s Eric Arellano. I use they/ them pronouns. I started working on the Pants build project about five years ago and have been active with a project ever since. I work on it for my day job as a software engineer, a startup called Toolchain. And I actually first got involved, I was in doing my summer internship project and ended up leading Pants Build’s Python 3 migration and fell in love with open source and the community. That was my first major time really working with open source and contributing back.

In between that, I was a middle school computer science teacher and teaching intro Python to 12 and 13 year olds and also I’ve been a volunteer crisis counselor for LGBTQ youth for two years now. So I think a lot about the human side of open source and communities and really like the focus of your podcast. I’m excited to be here today.

Shane Hastie: Nick, tell us about yourself.

Nick Grisafi: I’m Nick Grisafi. I’m a platform infrastructure engineer at Rippling. I use the Pants build system professionally and for fun. I was first introduced to Pants on a project when I first started at Rippling where we were trying to improve our testing strategies and also the tools that we wanted to introduce to the code base. We really needed a system that was flexible and allowed us to do something called incremental adoption. So we didn’t hit it all at once and Pants was the gateway into that.

One of my favorite experiences was within the first hour of using Pants. I was able to get it up from nothing to something, to show managers and people that this works. And to this day we continue to use Pants to empower developers to introduce tools and just to keep productivity as fast as possible. And yeah, I heard this podcast too is very tech oriented. So really happy to be here.

Shane Hastie:  And Josh.

Joshua Cannon: I’m Josh. Howdy. I’m a build engineer at IBM’s Watson Orders. So we’re an organization designed around fully automated drive through order taking, which is really fun. And so I’m really passionate about developer experience, which is why they hired me on as a build engineer. And specifically, I got tasked with taking a look at our Bazel, which is a mono build system, a cousin to Pants, if you will. But then it was holding us back and slowing us down. And so I was tasked with either finding a way to make that better or finding a different tool that would actually lift us up and propel us forward. And so that’s how I got introduced to Pants.

Lift by one thousand breezes [02:38]

Joshua Cannon: I’m a huge advocate of developer experience and lift by a thousand breezes and so that’s something I think Pants provides the engineers, which is why I fell in love with it. But also the community on GitHub and Slack really lifts you up as well. And so that kind of propelled me through opening my first issue to fixing my first issue, to making my first feature implementation all the way through to maintainer. So kind of gone through that life cycle through Pants and it’s been really rewarding.

Shane Hastie: Josh, can we delve into that lift by a thousand breezes a little bit more?

Joshua Cannon: So it’s kind of the opposite phrase of death by a thousand paper cuts. So the way I think about it is you can try to work hard and design and do things that would give a large strong gust and that’s hard to do. Instead, what you can focus on is giving a lift by a thousand breezes, which is basically small, incremental changes that are going to add up to that strong gust. Just as how a thousand paper cuts can cause a death just as quickly as a stab wound or as something is a stab wound, a lift by a thousand breezes can lift you up as strong as the strong gust. And so I’m a really big proponent of that.

Shane Hastie: Talking about the Pants build community, what makes it special?

A welcoming open source community [03:48]

Nick Grisafi: The people, I mean, if you’re coming into open source for the first time, it’s pretty daunting to come into a channel full of what you consider experts and then ask something that you think is really stupid. But then in Pants everybody makes you feel comfortable. They look for those questions and then next thing you know, they’re improving documentation or they even push you even further like, “Hey, can you contribute to our docs? Can you find where there’s shortcomings and we’ll fix it?” And it just kind of gets you going and you could give that feedback and then quickly see them fix something. It’s pretty rewarding. So I would say, yeah, the people really drive what Pants is.

Eric Arellano: You know, Nick, you mentioned stupid questions. So we have a lot of newcomers who will come and say, “Hey, sorry, this is probably a really stupid question. Here it is.” We always respond with that, it sounds like a teacher, that we really don’t believe in stupid questions, there’s only inadequate documentation and it means that Pants isn’t intuitive enough.

We think a lot about the idea of like when your teacher would say that if you have a question, probably 10 other people have that same confusion. We view our project that same way, that if you are getting stuck on something or something’s not intuitive, we’re extremely grateful that you went out of your way to tell us that and ask for clarity because we now can then figure out, is this a documentation bug or is this a UX bug that we need to redesign something so that the next person doesn’t get us confused by this.

Shane Hastie: This is not something that open source is known for. In fact, the reputation of a lot of open source communities is directly the opposite. How do you keep out the toxicity?

Joshua Cannon: I think we’re all popping because it’s a good question.

Pay it forward to keep toxicity out [05:26]

Nick Grisafi: Pants itself is just fun. I mean, you think about Pants, you see the logo, it starts fun and then you work your way through and you meet some great people. I have never seen anything bad happen in the Pants community, just interesting things that make me want dive deeper into the system.

Eric Arellano: I think something that helps a lot also is the idea of pay it forward, that people have helped you out along your Pants journey and therefore we find that a lot of times people who in the first week they come in, they’re only asking questions and within a week they’re often jumping in and answering questions for other people, which has been amazing for the growth of the community. We’ve grown really dramatically.

So we’re a 10 year old project but we relaunched with version two in 2020. Since then, I’ve seen really dramatic growth in the community size and it would not be sustainable if it was only the core set of maintainers who are trying to do all these things like helping out new users and writing documentation. I think that that pay it forward approach has really paid dividends for us. Lots of users are helping out every day, sharing their experience with things that we as maintainers might not actually have very much direct experience, and bringing in new ideas. That’s how I got hooked was that I was an intern, felt like I had no idea what I was doing with open source, with Python and opened an issue asking what it would look like to do a Python 3 migration. People were incredibly helpful to me throughout. And here I am now that I want to pay it forward to the next generation of Pants community members.

Joshua Cannon: I think it’s part of the culture of the Pants community too. Like me personally, I think I fall into that role that Eric was describing of people helped me and so I want to help others. It’s part of the culture that got fostered. And honestly, I can’t speak for others but I try to race the other maintainers to find an answer for people just to see if I can. And again, it’s that it is rewarding, right? It’s not just altruistic. It’s quite rewarding to see and foster others.

There are some users I’ve seen now in the Slack community that have grown throughout my time, short time as a maintainer, seeing them going from, like Eric said, asking questions to answering others.

Concrete actions to welcome particiPants [07:28]

Eric Arellano: I would add for listeners a couple concrete steps that we’ve taken to create this inclusive and welcoming community. One of the big changes we did was last year, introducing a welcome channel in our Slack where we invite people, never an obligation, an invitation to share what they’re working on and how they learned about Pants and always give them a warm welcome and let them know that we love questions here and we love feedback. That has been really exciting every day to look at. Often it’s three to five new organizations joining and really creates I think a sense of community.

Other concrete things we’ve done have been getting specific about how we recognize people’s contributions. At the beginning of the project until I think a year or two ago, we like many open source projects, primarily recognized maintainers and contributors through code contributions. And we actually used to call our maintainers committers, a term from programming. And we realized that for a healthy open source project you need so much more than code, even though that is an important foundation. So we changed the name to maintainer and started recognizing all types of contributions, including a lot of new future ideas that we’ve had from users that a future request is a way of contributing to community, pointing out again where you’re confused with docs is contributing.

So we renamed committer to maintainer and then we also added a level of recognition below maintainer of contributor that you have gone out of your way to do several meaningful things to the community and we want to recognize you formally in the community.

Nick Grisafi: One experience I want to share that I totally forgot about. I don’t know how I forgot this. I joined Pants community, like what is it, over a year ago, just about over a year ago now. And the first moment I joined the channel, I got reached out to by Benji and he sent me a private message welcomed me to the channel, offering to support me if I have any questions. Was curious about our use cases and things like that and I never had that happen to me before in any open source community. So it almost had that cool factor like, “Hey, this guy runs it and he cares about me. I’m a newbie. I just joined.”

Shane Hastie: A couple of very clear pieces of concrete advice there. What else can people involved in open source communities do to be more welcoming?

Advice for other open source communities [09:46]

Eric Arellano: Another thing that’s helped us lot is we consistently invite people to our Slack community, whether it’s in a blog post or podcast like this. We are constantly inviting people because we use GitHub for all of our project tracking and for our code and everything. There is a lot of activity on GitHub but it often tends to be more focused on a specific change that someone’s trying to do, whereas Slack is a lot more that people might be running into a problem with how they deploy things with Docker and they want advice from other community members.

So we’ve had a lot of success with Slack in particular and there’s a lot of other alternatives like Discord that other communities prefer. But concretely in every blog post we do, every time we do some type of outreach, we encourage people come join our community. This is where it’s happening.

Joshua Cannon: One thing you’d see from Pants that you normally don’t see from open source projects is that really the community owns it. So there is no company that owns the project itself. There’s a nonprofit organization that I will say runs it. And so because there’s no one person owning it, it really is that community. Everyone’s ideas can be heard. Everyone’s ideas get weighed equally and I think that’s very important to fostering that sense of contribution.

Nick Grisafi: And you see that all the way through the code level too. If you’re onboarding Pants and you’re writing your first Pants plugin and you need to have some good references, the code itself really serves that purpose. You could go in. I just wrote a plug in the other day to improve our dependency and inference. Eric pointed me right to the source code with an example and that’s something I could put into our production pipeline within a day, which is pretty awesome. And the concepts are a little bit over my head. So to learn something just based on code self-explanatory is pretty amazing.

Shane Hastie: Power of the outsider. That was something that we mentioned in the conversation before we started recording. So what do we mean by that?

The power of the outsider to overcome the curse of knowledge [11:45]

Eric Arellano: The term power of the outsider I think a lot about a related idea, which is the curse of knowledge. The curse of knowledge is a cognitive bias. It’s really hard to remember what it was like before you didn’t know something. So if you think about using your phone and like how to send a text message, it’s super obvious to you and it’s really hard to think about what it would be like for someone to get a phone who’s never used if we go back 200 years, for example. You can try, but realistically you have this curse of knowledge that makes it hard for you to empathize with people and it ends up resulting in open source projects, and general in projects looking like things like writing documentation that makes a ton of sense to you as a maintainer because you wrote the thing but is super obtuse and confusing to anyone who hasn’t used the system before.

So with the power of the outsider, we as maintainers and as contributors to the project, we think about this curse of knowledge. A lot, our goal is for Pants to be extremely ergonomic and intuitive for anyone to use intuitive, meaning you can figure it out on your own. You don’t need to read our docs. We try to assume that 80% of our users will never end up reading our docs and can they figure out how to use Pants even without that? So we need help because we have this curse of knowledge. We need help that we can try our best to empathize. But realistically we need that feedback from people who have never used a build system before or have never used Pants about what they found confusing and what improvements we can make to it.

Nick Grisafi: It brings me back to our last podcast where we discussed the topic about what was it called, the bus factor, and these people who retained the curse of knowledge. And let’s say one day they randomly get hit by a bus. Where does that put you, your organization and your company? If the knowledge cannot be shared and spread and distributed, then most likely it’s only tailored to one person and that could cause failure. So it’s important to share knowledge. Share knowledge and make sure that you’re putting yourself into the shoes of other people. When you’re not around, will they understand this and be able to maintain it? It’s really important.

Shane Hastie: What’s the role of corporations? You mentioned a non-profit organization owning and guiding it, but a lot of corporations get involved with open source initiatives. What’s the role for the commercial organization for the corporation today?

The role of corporations in open source [14:13]

Eric Arellano: I think there’s a lot of opportunities for corporations to help out open source projects. It needs to be done carefully. I mean, there’s a lot of risk with it that the corporation ends up dominating. But we’d like to think that Pants has been a healthy relationship that, for example, I mentioned working for a startup where 90% of my day job is working on the Pants build project. Josh is able to do some work on Pants as well with his job and a couple of the maintainers are, whereas others are more contributing on their own free time.

So about two years ago we identified as the Pants build nonprofit organization that the majority of maintainers were coming from one company, the startup that I worked for, Toolchain, and that that was a systemic risk for the health of the open source community. The Pants build project is again going to be successful, we need outside perspectives and it can’t be dominated by anyone voice because that one voice isn’t going to represent all the different teams that we’re trying to reach.

So we made it an intentional goal among the maintainer team that we are going to invest a lot in bringing up to speed new contributors and new maintainers and growing the diversity of our maintainer base and our contributor base. And through a lot of those steps that we talked about earlier like redefining what a maintainer means, creating that welcome channel. We’ve had a lot of success that now I think the majority of the maintainers are not represented by one single organization, I think.

Joshua Cannon: Talking from two different levels as well. I can say that the corporation or a corporation’s, I’ll say, allowance of users to contribute to open source, it kind of goes back to that lift by a thousand breezes. I couldn’t do my job effectively without all of the tools I use, many of which are open source and those tools wouldn’t exist if people weren’t able to contribute to them because we all have very limited free time. And so that they did so in a corporate manner. Some corporations even own and maintain those tools. So there’s kind of that aspect of the golden rule. Do unto others as they’ve done unto you. So that’s kind of the higher level.

The lower level too is the features that you can bring from your corporate perspective to put this more concretely. I’m about to give a proposal to Pants that I think will benefit a lot of people, but for us specifically rolling it out on our own repo, we saved ourselves, I mean myself, a month’s worth of dev time and my organization a year’s worth of dev time. And so having that perspective from my real world use case that I can then reapply back to the tool is really important as well.

Nick Grisafi: One of my favorite things is that you use as Pants page, if you go there, you’ll see a bunch of different companies, some really cool companies and it just makes you think like, wow, that’s scale, they use Pants? That’s pretty amazing. So if it works for their use case, a hundred percent, can it work for our use case too. And then you find out in your use case you have something that they didn’t even think of before. You just have some pattern that wasn’t thought of and then you go into the Slack community and you bring it up and you start a discussion there. I think that’s pretty awesome.

Shane Hastie: Joshua, if I can hone in. You’ve mentioned a couple of times the importance of developer experience. What are things that our organizations are doing to improve that developer experience today?

Improving the developer experience [17:28]

Joshua Cannon: Ooh, that’s an excellent question. So I think what corporations are doing is being more intentional about it. DevOps is quite an umbrella term. It’s thrown out a lot, but you’ll see job listings now for developer experience engineers, making it a dedicated role, having somebody who can own that experience. I’ve seen kind of an upbringing at the companies I’ve been at around building a culture of that experience, helping each other out, finding the tools that work and then sharing that.

It’s not enough for me to find what works for me and now I’m successful at my job, but spreading that around. And from the corporation’s perspective, making sure that’s part of the culture. So everyone knows that they can and should do that. Because really, oh man, I’m sounding like a broken record, but that in itself is a lift by a thousand breezes.

Shane Hastie: And for those organizations that aren’t doing that deliberately yet, when they start…

Eric Arellano: So yeah, that’s actually one of the core missions and reasons why Pants exist, is that we have this hypothesis that 90% of teams don’t have the resources or perhaps the experience yet to focus on their developer experience. And they might be using a lot of custom bash scripts that they wrote and they kind of work but it doesn’t work great. It’s kind of death by thousand cuts or the analogy of the boiling frog, that a frog, which apparently this isn’t actually true, but the analogy is that a frog will be in boiling water and you increase the temperature over time and the frog won’t realize until it’s too late that the water’s already boiling. And that’s our hypothesis that that’s how developer experience is for most teams that start small. You don’t have much code and then you incrementally add more and more scripts until you get to this point where no one really understands, it’s really confusing.

Eric Arellano: The same time we know most organizations don’t really have the resources for a dedicated team of developer experience. For example, when I was working at Twitter before my current job, I was on the developer experience team and we had a team of I think it was like eight or nine people who our sole job was to help developer experience for the other engineers. Most companies don’t have that resource and that’s not realistic to expect. So part of our mission with Pants is to empower those everyday organizations that you can get rid of the custom bash scripts and have this amazing build experience without having to have a whole dedicated team trying to reproduce the wheel because you can leverage what the open source community has already done and solved.

Nick Grisafi: Touch on that point. My favorite part about Pants was deleting all those bash scripts. That just simplified things like that. It’s all controlled through a single point now, Pants. And now they’re introducing Go. So we could actually do the same thing for our Go projects, Python projects. That’s all the same interface.

Joshua Cannon: To answer Shane your question too and know your audience. On reflection, I’d say that really being intentional about developer experience is a great place to start. All of your developers are having an experience. That’s a fact. Whether they’re having a good one or not is subject to debate. And so being intentional about it.

I think in any organization of a decent size, you’ll find those people much like myself who naturally tend to gravitate towards wanting to improve the developer experience and it’s not always altruistic. I know a lot of times I started doing it because I got so frustrated. I needed to improve it for myself for my own sanity. And so finding those people and really fostering that kind of culture and that passion from those engineers will go a long way.

Getting started improving developer experience [21:00]

Nick Grisafi: To touch on that. Where do you start? Most of the time you have to acknowledge the problem and that’s getting the people at the top of the company to acknowledge that problem, to give you those resources so you can go ahead and do it. And exactly what Josh said, like finding the individuals to evangelize this and understand the frustration but have an idea for a solution and to make that a reality.

And then just wanting to help people. You have people on your team that genuinely care about this. Put them in charge and let them help people. Make sure that there’s a feedback channel that anybody in the company feels comfortable coming in and could give feedback and get feedback as quickly as possible. That feedback loop is super important so you could collect the information. It’s not a distraction. It might throw you off guard sometimes like, “Oh, this guy literally can’t do something very fundamental.” But you have to not see it as a distraction but as a point for improvement. You have to go in there, understand how they even end up in this situation, put yourself in their shoes and improve it for good. Document it and try to never let it happen again. That’s the point.

Nick Grisafi: But if you don’t have the resources at your company and the people at the top are not focused on this, then it’s almost near impossible to get it started and done. Then it just has to be community driven and organically driven, and a lot of the time people don’t have generally just time for that.

Shane Hastie: Give people the time.

Nick Grisafi: Give people the time to make things better.

Shane Hastie: Some interesting thoughts and good ideas in their folks. If people want to continue the conversation, where do they find you?

Nick Grisafi: You can find me in the Pants’ Slack community. I mean, my name is NJ Grisafi in there. I have a profile picture of hiking in San Diego. Most likely you can see me in the general channel asking something really stupid or maybe something you didn’t know about. But yeah, that’s a good place to find me.

Joshua Cannon: I think if I may, you can find us all on Slack. And I’m going to go ahead and speak for Eric and Nick here. If you don’t feel comfortable enough asking your question in general or in welcome or any of the other channels, you’re welcome to ping us directly and we’re happy to guide you along.

Shane Hastie: And we’ll include the links to the Pants’ Slack channels in the show notes. So thank you so much.

Joshua Cannon: Thank you.

Nick Grisafi: Thank you.

Eric Arellano: Thank you.

Mentioned: