00:47 - Jen’s Superpower: Being Optimistic

• Recognizing Negative Loops
• Intentionality & Prioritization
• Preventing Security Vulnerabilities

10:13 - Working On Open-Source Projects vs Commercial Software/Products

• Gathering Feedback (RFCs)
• Baby Steps = Big Impact

12:57 - Major vs Minor Releases

• Semantic Versioning
• Deprecation Warnings
• Advanced Notice
• Incremental Rollouts

18:45 - RFC / Feedback Processes

• Dealing with Contradictory Feedback
• Reaching Consensus
• Visionary Leadership
  • Additions

23:25 - The Ember Core Team

• ~30 People
• Funding
  • LinkedIn (Corporate Sponsorship)
  • Consultants & Consultancies
  • Volunteers

26:31 - Doing Open Source Better

• Sponsor Company (Time)
• Knowledge Sharing
• Framing Work As How It Values Contributors
• Reframing How We Think About Open Source Sustainability (i.e. Company-Wide Open Source Work Days)
  • Frame Value to Company
  • Frame Value to Users
  • Frame Value to Engineering Teams
• Attitude Shifts

39:56 - Participation Encouragement & Engagement Tips

• Use The Buddy System
• Having Well-Scoped Issues
• Increasing Levels of Challenge (Subtle Cheerleading)
• Help People Spin Up Quickly

46:00 - Widening the Pool of Participants

• Being Easy to Reach
• Social Media Activity
• Working In The Open

47:36 - UX-Driven Design (User Experience-Driven Design)

Reflections:

Damien: Perspective of those impacted. Sponsors, users, etc.

Arty: What it’s like to work on a big open source project and the challenges we face.

Jen: Exploring small-project lifecycles.

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

ARTY: Hi, everyone and welcome to Episode 253 of Greater Than Code. I am Artemis Starr and I am here with my fabulous co-host, Damien Burke.

DAMIEN: And we are here with our fabulous guest, Jen Weber.

Jen Weber is a member of the Ember.js core team and is a senior software engineer at ActBlue Technical Services. Jen loves open source, rapid prototyping, and making tech a more welcoming industry.

Jen, thank you so much for being here. Welcome to the show.

JEN: Thank you so much for having me.

DAMIEN: So you should have gotten an email preparing you for the first and most difficult part of every appearance on Greater Than Code. Are you ready for this?

JEN: I am.

DAMIEN: What is your superpower and how did you acquire it?

JEN: All right. So I did get that email and I've been thinking about those for the last couple of days. I think my superpower is being able to imagine the ways that things can go well.

DAMIEN: Wow. That's very special.

JEN: Thank you.

DAMIEN: How did you acquire that?

JEN: So I used to be very good at imagining all of the ways that things can go badly. Those are still the patterns that my mind walks whenever I'm confronted with a challenge, but someone gave me some advice. I was recounting to them all of the ways that things could go badly, they were like, “What would it look like if things went well?” I've been trying to build that as a muscle and a skill anytime I'm working on a new project, or something hasn't gone well, something's already gone badly, and I'm trying to figure out what to do next. I found that helped me open up to more creative thinking.

ARTY: I really think that is a superpower and in order for things to go well, for us to manifest good things toward a good direction, we have to be able to see the steps to get there, imagine ourselves walking in that direction to be able to do it. And if we're caught in a loop of worrying about all the things that are going to go wrong, anticipating those things going wrong, then it's like we're going to be waiting for him and doing things that help bring those things that we don't want into being.

So if you find yourself in this mode, it sounds like this is something that you struggled with and learned this adaptive skill to break out of this pattern. So what kind of things do you do? Like, do you tell yourself things or ask yourself certain questions, or how do you snap out of that mode and get to a better place where you're thinking about things in a positive frame?

JEN: Sure. I think for me, the first step is just recognizing when I'm in that negative loop and accepting that it's my first reaction, but that doesn't need to be my conclusion to my thought process. If I'm working on let's say, there's a real-world challenge. Just to give an example as part of my work on the Ember core team, I might think about how do I engage the community and announce that there's going to be this new version of Ember?

If I imagine things going badly, I imagine like, “O, wow, nobody even retweets it a single time,” and if I imagine things going well, I think like, “Wow, it's this big moment in tech.” And if it was a big moment in tech, what would have the involved people done to get to that successful end point and trying to work backwards from that to connect the dots. It takes some intentionality, it takes having enough rest, it takes not being over-caffeinated to be able to unlock that kind of thinking.

DAMIEN: But it sounds so powerful, especially as an engineer, or as an advocate. It's like because we're in the role of making things into what we want them to be, which is things going well, right?

JEN: Yeah, and it's a little different than a wishful thinking, I would say, because you're still thinking in order for things to go, well, you have to overcome challenges, you have to solve problems, you have to prioritize, there's going to be difficult moments. So you're not just dreaming that this good feature is going to come into existence, but actually figuring out what are the nuts and bolts, and pieces, like, what are the ingredients to that recipe? When we think and reflect on that, how can we take those ingredients and apply them to right now to get where we want to go?

ARTY: So you take that vision and then work backwards and translate that to actual action. These are things that we can do right now to walk the path of getting where we want to go.

JEN: Mm hm, and it might take you somewhere totally different direction. It might be very different by the time you're done. But usually, you can figure out a few things here and there that are steps in the right direction, and the right direction could be one of many different directions.

ARTY: Do you find yourself ever getting disappointed that things don't go the way you envisioned?

JEN: Oh yeah, for sure.

[laughter]

Yeah, and I think that's a little bit part of the rollercoaster of being involved in software. Like every single day is a series of things going a little different than you thought they would. You read the code; you think it's going to go a certain way. You're wrong; you change your plan. You have this idea of a direction you're going to go, you've thought about what are the successful steps to get there, and then you end up in the wrong corner and you have to go back to the drawing board and surviving those cycles is just part of what we do.

ARTY: So does that superpower help you escape those feelings of disappointment then?

JEN: Oh yeah, I think so because not that I have some way to see the future, but more that I have tools for helping to figure out what my next step could be.

ARTY: So then you're always focused back on action.

JEN: Mm hm.

ARTY: And how can I take what I learned and this vision of what a good direction would be, taking these new data points and things into account, and then reimagine and translating that back into action.

JEN: Yeah.

ARTY: I think that qualifies as a superpower.

DAMIEN: Yeah, I think about it, I guess because I was writing code this morning, and so often, when you're writing – when I'm writing code at least, it's like oh, the phrase was “defensive programming” from a long time ago. How can this go wrong? What happens if this is nil? What happens if some evil guy in a black hat comes in and tries to do something here?

And what I've had to learn and still need to remind myself of is the good case. What is it that we're doing good for our users, or whoever else the code touches? What are they trying to accomplish and what experience are we trying to create for them? And so, both, as an engineer and a product manager, just being able to ask that question and see an answer on a small scale on a feature in stories, super important.

JEN: Yeah, and even if you're thinking of that adversarial aspect where it's like, you're trying to think through all of the security risks that are involved in developing some software, you can still use this thinking to your advantage. What would a successful future be where somebody tries to exploit that vulnerability and they fail? You've got them. What are the things you built? What are the strategies and habits that that team had? What is the monitoring and infrastructure that resulted in successfully preventing this, or that problem from occurring?

DAMIEN: It's not only a useful strategy and also, feels really good.

JEN: Mm hm.

DAMIEN: That’s great.

ARTY: I like that, though just thinking from a standpoint of just vulnerability, or even a case where things go “wrong,” in the case that you do have somebody hacking your system, or trying to exploit some vulnerability, what's the logging and information infrastructure? What does that story look like where even though these things are happening, we're prepared, we have the right things in place to give us visibility into what's going on, and be able to catch it and address it quickly. Like what do all those things look like such that we're ready to go and can still have a success story, even in the case of these challenges that come up?

DAMIEN: That sounds connected to something, I think we want to talk about today, which is what goes well when you get a major library upgrade, what does that look like?

JEN: Yeah. I've been thinking about this a lot lately; informed by two things. So one is that I'm involved in an Ember, which is a frontend JavaScript framework, and we're getting ready to do a 4.0 major release. So going through all of those exercises to have preparedness all comes back to how do we do this, or what do our users need, what are the resources that are missing?

That's one thing on my mind and the other is that I've recently updated some dependencies in the apps that I work in and had a hard time. What can I learn for myself about what to do differently? What can I learn that might be takeaways for library maintainers? What can I share with my coworkers and my collaborators to make this easier next time?

ARTY: What's it like working on an open source project and how does that feel different? What are the different aspects of that from working on a commercial product versus something in the open source community?

JEN: There's a couple of pieces. The biggest one is that when you're working in your own code base, you have at least a fuzzy picture of what the product is, what the constraints are, how many users there are, and the things that the developers on your team generally know and the things that they don't know. You have all this information that would help you inform how do I roll out some new, big feature, or something like that.

When you're working at open source, your universe of possible products, developers, and users is huge. Like, you could never write down a list of all the ways that somebody is going to be using that software and so, it becomes really different than having a set of well-defined products requirements; we want to get from point A to point B. It's like, we need to give everybody a path forward even though they're using this tool in all these different ways.

To do that, a lot of effort goes into gathering feedback from other people in the community. So we use a process called RFCs, or Requests for Comments where someone says, “Hey, I think this would be a good feature. Hey, I think this thing should be removed, or deprecated,” and you have to get feedback. Because we can't imagine all the ways ourselves that someone could use this feature, or tool and then once there's consensus amongst the core team, then something can move forward. But everything goes through a lot of iteration as part of that process.

So the overall progress can sometimes feel slow because you have to think through all of this extra weight—the weight of depending on thousands and thousands of developers and billions of users on you to make the right decision. It means you can't just “Oh, let's just merge this breaking change and I'll make this breaking change and I'll just post on Slack to everybody like, ‘Hey, watch out. I just changed this one thing. I documented it here. Good luck.’” You can't really quite pull that lever in the same way, but when you do have a step forward, it's a step forward for all of these apps, for all of these projects, for all of their users and so, little baby steps can still translate into really big impact.

ARTY: So when you have something that's a major release in that context, like a major release of Ember versus a minor release. How are those different? What kind of things do you do in major releases?

JEN: Yeah, that's a good question.

So I'll just provide a little bit of background information on this vocabulary that we're using for anyone who's listening in. A lot of projects follow semantic versioning, which is a set of rules that a lot of projects agree to follow that if you ever see a version number that's like 4.2.1.—oftentimes, that's semantic versioning and action in the first number—is for major releases and a major release is one that has a breaking change.

So that means that I make a change in that code base. I would expect that other people would have to change the code in their own apps and they would be forced to go through that—make that change—in order to upgrade to that version for the library I'm working on. Minor is usually used for features. Patch, the last one, is used for bug fixes and internal refactors, things like that.

Not all projects follow in the same way. Some projects have time-based cycles where they say, “Oh, we do a major release every six months,” or something like that. But for us major releases are breaking changes and the things that are different about them is that we have to give people a path forward to get to the next version. That could include putting some deprecation warnings, any code that's going to get removed or change any API that are going to shift in the next major version. We want to let people know, with a little warning, if they're using those older syntaxes, or APIs, whatever's going to be removed. We also want to try to give a lot of advanced notice about what's going to change, or be removed via blog posts, things like having a help channel set up maybe that's just for those upgrades. When it's time to actually do the major release, we try to make it boring.

This is something that I would like to see happen across the rest of the JavaScript ecosystem. It does seem to be catching on more, which is that when you do a major version release, all it does is it removes the things that need to be removed. You make your breaking changes and that's it, and then in follow-up releases is when you add in all the new features.

So let's say, some API is just the old way of doing things. It doesn't match up with a new rendering engine, or something like that. You're going to want to remove the old thing and then incrementally work to roll out these big splashy, new, exciting features. So maybe your exciting release is actually going to be 4.1, or 4.2, or 4.3.

This has a couple benefits. It lets your major releases be a little less risky because you're not just removing code and then adding new code at the same time. It lets people not be as overwhelmed like, “Oh, first I have to deal with all of these things that are removed, or changed and then now I also have to learn this whole new way of thinking about how to write my app using this tool.” It lets you take little baby steps towards doing things in a different way.

DAMIEN: Does this mean, in an ideal scenario, that if you don't have any deprecation warnings—if you're taking care of all the deprecation warnings—then your major release can go – you can upgrade some next major version without a code change.

JEN: Yeah, that's the dream.

DAMIEN: It does sound like a dream.

JEN: Yeah, and it's not always perfect, but it's an important pathway towards including more people and participating in upgrades, app maintenance, and creating sustainable code bases so you don't have to follow the Twitter, the blog post, and be checking the JavaScript subreddit just to keep up on with what's going on. You're not going to be surprised by big sweeping changes.

So coming back to this experience I had with upgrading a different library recently, I was upgrading major Jest versions and was very surprised to see that there were a ton of breaking changes in a changelog and I got a little bit frustrated with that. And then I went back and I read the blog posts and I saw a blog post from 2 years ago saying, “These are the things that we are doing, this is what is happening,” and that was great, but I wasn't doing Jest tests 2 years ago and so, I missed all of that. Can we use the code base itself to connect those dots, make those suggestions, and guide people towards the work that they do?

DAMIEN: If they put those deprecation warnings in 2 years ago, you would've had 2 years to make those changes.

JEN: Yeah.

DAMIEN: And then when you finally upgraded, it would have been a dream, or have been painless.

JEN: Yeah, and maybe they're there. Maybe there are some and I just need to pass the debug flag, or something. Hopefully, there's nobody who's shouting at their computer. But there's this one thing that we put it in the console log output, or something. It's possible I overlooked it but.

DAMIEN: I want to rewind a little bit back to the challenge of dealing with a product that is used in so many contexts by so many people, like Ember is, and the RFC process. The first thing I thought of when you mentioned that is what do you do with contradictory feedback? Surely, you must have hundreds of engineers who say, “You have to get rid of this,” and hundreds who say, “No, this has to stay.” How does the core team manage that?

JEN: Yeah. So I think the most important piece is the contradictory feedback needs to be considered. So it's not just like, “Oh, let's collect these comments as annual feedback forms,” or anything like that.

[chuckles]

This isn't like, “Oh, let's do some natural language processing on these comments to figure out if the sentiment is positive, or negative.”

[chuckles]

None of that stuff you have to actually read through them and think what could I do using this new feature to help meet this person's needs, or what's at the heart of the objection that they're making? If someone is saying, “This doesn't work for my team,” and entering that process with a willingness to iterate. In the end, we can't make everybody happy all the time, or no RFC would ever get moved forward. There's always going to be a point where you have to prioritize the pros and cons, and ultimately, the decision comes down to reaching consensus amongst the core team members.

So being able to say, as a group, “We believe that the feedback has been considered. We believe that the iterations have been incorporated, the people's concerns have been addressed,” or “We're going to work to create tools that think that problem be not a problem for them,” and find a way to move forward with whatever the proposal is. Or sometimes, the proposals don't move forward. Sometimes, they get closed.

ARTY: Is the work you end up choosing to do primarily driven by this feedback process, or do you have some visionary leadership within the core team that drives a lot of things forward that aren't necessarily coming via feedback?

JEN: That's a good question. I think it's a little bit of both. So certainly, a lot of RFCs have come from the community and from people asking like, “Hey, can we have this better way of doing things? I have an idea.” And then other times, you do have to have that visionary leadership.

So to give an example, we have just started doing – well, I shouldn't say just started doing that. I think it's been like 2 years now. We have started doing this process called additions where if there's a big splashy set of cool features that are meant to be used together, we give it a name. That's separate from the breaking changes process, ideally. We can create nice, new splashy sets of features without breaking people's apps and trying to design that experience isn’t something that you can just piecemeal through RFCs waiting for feedback to come through.

There were quite a few members of the core team that designed a new way of building Ember apps that was better aligned with focusing on HTML as the core of building for the web and focusing on JavaScript features as opposed to requiring developers to know and understand the special API syntaxes. You can just write JavaScript classes instead of needing to understand what an Ember object is.

So aligning ourselves more with the skills that everybody, who works in the web, has at least a little bit of. That took a lot of brainstorming, a lot of planning, and ultimately, introducing those things still follows an RFC process. Somebody still has to say, “Here's the thing we want to change, or do, or add. Here's the greater vision for it.” But to get that big picture look still requires the big thinking. So the core team, I don't even know how much time. They must've spent countless hours trying to hash out those details.

ARTY: How big is the core team?

JEN: So there's several core teams. Though when you say the core team as a whole encompasses people who work on the data layer, the command line tools, the learning tools, and then the framework itself. I want to say, could look this up, it's like upwards of 30 people, I think.

ARTY: Wow.

JEN: I can get you the exact number later, [chuckles] but everyone's pulling out their different area of domain and so, all of those teams also have to coordinate around these major releases because we want to make sure the work that we're doing is complimentary. If we do the framework improvements, but we don't fix up the docs, we’re not on the good path for a successful release.

ARTY: Are people working on this stuff full-time? Are people funded, or doing this in their free time, or how does that work? Because there's this big picture challenge of we have this ideal of community sourced, open source projects, and then the realities of trying to fund and support that effort bumps up to constraints of needing to make a living and things and these sorts of difficulties. How do y'all manage that?

JEN: It's a mixture.

So the Ember project is fortunate to have a major player—LinkedIn—that uses Ember and so, some of the core team members, their work on Ember is part of their LinkedIn work because of the frameworks doing well, then LinkedIn projects that are going to be doing well. There's also a number of people who are consultants, or who run consultancies that do Ember work, they're involved. Their voice is an important part of making sure that again, we're serving a variety of apps, not just ah, this is this tool that's just for the LinkedIn websites. But it's like, they've seen so many different kinds of apps; they're working on so many different kinds of apps right now. And then there's people who help out on more of a volunteer basis.

So I've been in my past work, it was at a different job. It was part of my job responsibilities to participate on the framework core team. These days, I'm more of a volunteer and I mostly help organize other volunteers—people who want to do some professional development to learn, people who want to network, people who found something that they're frustrated about enough that they want to fix it themselves. That’s how I got involved; I wanted to learn. So that's the sustainability of having people involved is always an ongoing challenge it is for every open source organization, I think.

ARTY: Yeah. Do you have any ideas on how we can do those sorts of things better? As you said, it's a concern, in general with how do we do open source better with these kinds of constraints? And then two, I feel like there's been some cultural shifts, I guess, you could say over time of you think about when the open source movement first started.

We had a lot more of this community ownership ideal where we really were going and building software together and now, there's a lot more of, well, there's all this free software out there that we use, that we build on top of to build our apps on, but that ownership piece isn't really there. It's an expectation that there should just be this free software out there that's maintained that we get and why is it falling apart?

So I feel like, culturally, just over time, some of those things have shifted as far as expectations around open source and then you talked about some of the corporate sponsorship aspects with usage as being one way these things get funded. But I'm wondering if you have ideas on how some of these things could work better.

JEN: People have done PhDs on this topic, I'm pretty sure. [chuckles] Like, theses. I read a white paper, a really involved white paper, a few weeks ago that was about, what was it? it was called something like the Burden of Maintaining Software, or something like that and it did this deep dive into how much goes in and just keeping the ship afloat. How much goes into just if there's a package that needs to be updated? That kind of ongoing, constant, mundane work that adds up really, really big.

So for very large projects, I think it's a good thing to have some sort of an evolvement of a sponsor company, if you will and so, that sponsor company may not actually ever donate any money, but the time of their engineers that they say like, “Hey, we're willing to help support this project” is really important.

I think another piece is that the leadership of projects should consider the people involved, that that group is going to be rotating. That people's involvement is ephemeral. Every time somebody changes jobs, maybe they're not going to be involved in that project anymore. If we can think about that ahead of time, plan for it, and make sure that we are sharing knowledge with each other such that the project can survive somebody moving onto something else, it can survive somebody going on vacation for a while.

So I think that's another key component of success is how do you make it so that you're not just relying on the same set of people still being there so many years later? We’ve been very fortunate within the Ember community that a lot of the same people have stuck around, but I try really hard not to bank on that. The group of contributors that I help organize, I think, “Hey.” We have a chat every time somebody joins the learning core team and say, “Hey, we get that you're not going to be here forever. Please let us know what we can do to support you. Please let us know when you're thinking of taking a break, or taking a step back. Please involve other people on any project that you're working on so that they will also continue your work and also support you so you don't get burnt out.

Another thing I try to do is always framing the work into how it values the contributor. Sometimes in open source you hear this discussion of like, “Oh, well, everyone should participate in open source because we all benefit from it.” There's a better attitude that we can have, I think, which is that for people who are interested in participating, what can they get out of it? What can I do as a leader to help them get something out of this?

If you just approach it with this altruism of “This is a community and I want to help,” that'll get you like a little bit. But if you can say, “I want to help because I want to learn from other developers,” that's something I can deliver on. That's something that they can take. That's valuable for their future earning potential, income, confidence, maybe they'll make the connection that helps them find their next job. Even if someone isn't being paid to help out, is there something that they can take away from this? And lastly, just acknowledging that doing work for free is a privilege as well.

We have to reframe how we think about open source sustainability, too. Not everybody can devote a few hours after work here and there and involving them and including them means that it's got to be part of their workday. So continuing to socialize from the company level that engineers should have a little bit of time here and there to try to help improve an open source project. Everybody doing that just a little bit helps with quite a few of the problems that these projects face.

ARTY: I've been thinking about this myself and you work directly, you're significantly involved in a major open source project, and so, you see things that a lot of people don't have perspective on. So I appreciate your insights on this.

I'm wondering what if major companies that were using open source software, if we made more efforts for companies to be a project sponsor and donate part of the company somebody who's on the company's time to help contribute to projects as like a thing. I feel like if that thing caught on, that the companies that were using this software for free [chuckles] had more of a sense of a social obligation to be one of the people that contribute some time to helping with that. Or get some companies that are big enough, too. It's probably easier and they have more interest in those sorts of things.

But I feel like if we did make that more of a thing, that that would be useful because as you're saying, somehow realistically speaking, this has to be something that can be worked into the workday.

JEN: Yes.

ARTY: For us to be able to support and sustain these things. And people that can do that outside of their workday as an extra free time thing. It really is a privilege.

JEN: Yeah. I think a couple of strategies that can help here are to frame it in the value to the company and frame it as a value to the users, frame it as a value to the engineering team. So rather than having it be like, “Oh, you use free software, you should do this thing.” Instead more like engineers, we always need to learn constantly in order to keep improving our own skills and to keep up with things that are changing.

So having an open source hour, or something like that—it takes a little more than an hour usually to accomplish much. But having a period of time that engineers were allowed to contribute to open sources. Professional development that you don't have to pay for a subscription. You don't have to pay for a licensing fee. You don't have to pay for somebody’s conference submission. If someone has the opportunity to reach outside of their sphere of knowledge, or comfort zone and it just so happens that if they succeed, it'll benefit your company maybe indirectly.

Another piece is what's the value to the users? So there were a bunch of people who all contributed effort towards bringing some improved linting tools for the template system within Ember. When we think of linting tools, we usually think that's like, “Oh, here's this thing to remind me to use nice tidy syntax and don't make my variable names too long and space everything out in a certain way,” but they can also help us find real actual problems in our apps.

So an example that this team worked on is they introduced some more linting rules for accessibility. If one person succeeds in introducing this new linting rule for accessibility, then it's there in their app for their team and they get to stop talking about, “Hey, make sure you do this one thing” over and over again because now it's enforced in the code base. Also, they've brought this benefit to all of the other apps that are out there.

Again, sometimes you can tie it back in to that value for the product and for the users, and really trying to think creatively about that connection. Because there's so many different things we can all spend our time on, you've really got to sell it in a way that aligns with the goals, or values of that organization.

ARTY: Yeah. I like that reframing. I can see just how important that is. Other things I'm thinking about if you had a dev team and one of your developers was really involved with the Ember core team, you'd have more knowledge about how things worked. So when something was broken, or something, you probably have more insight into what was going on and being able to help the team more effectively –

JEN: Yeah. [overtalk]

ARTY: To build stuff. And then if there's any suggestions, or things that could make things easier for your team, you'd have the ability to have influence with getting RFPs through to get changes made and things. I think you're right. It needs to be reframed as a value proposition.

JEN: Yeah, and it also requires an attitude shift on the side of the projects as well. There's tons of people who've tried to do open source and hit running straight into a wall of they open up pull requests that are never merged, or even reviewed and that can be a really frustrating experience. And some projects just don't have the feedback structure, or the governance structure that really allows open participation either.

So that's something that I think is an ongoing journey with lots of projects. It's like, how do we communicate? How do we involve other people? What types of decisions do we say like, “Hey, implementer, or community, you're in charge, you can make this” versus things that have to pass some sort of review. It’s not just a one side of companies need to step up, but also, maintainers seem to have a long-term vision of how they're interacting with everybody else.

DAMIEN: Yeah, I really love that frame of this is professional development and that you can get for free. That's like how would you like to educate your engineers and make them better engineers, especially on the tools you work on and not –? Yeah, that's really awesome. But then of course, on the other side, you need a welcoming environment. That's like, “Oh yeah, when you make a contribution, we're going to look at it. We're going to give you useful feedback on it.”

JEN: Yeah. I tried to get an open source project going a few years ago and I struggled for a while and eventually ended up giving up. But some of the things I ran into, I'd have somebody that would volunteer to help out with things and I'd work with them long enough to just start to get a feel for things and be able to contribute and then they would disappear. [laughs] And I go through that process a few times.

It's like, “Oh, yay. I'm excited, I get –” another person has volunteered and so, then I go and start working with them and trying to – and I put a lot of attention into trying to get things going and then they disappear. t was difficult to try and get traction in that way and eventually, I went, “Well, I'm back by myself again” [laughs] and that I just need to keep going.

ARTY: Right. So what kind of things have you found help with getting that participation aspect going and what kind of things are barriers that get in the way that maybe we can be better at?

JEN: Yeah. So my advice is always start with using the buddy system. Trying to pair program with people, who I'm hoping to stay involved, and the leveling up version of that is the people who are contributing pair with each other. It's so much more fun. There's so much more of a learning experience when it's two developers working on the project.

Left to my own devices, the projects that I work on, I have to really dig into my willpower to keep them moving if I'm the only person working on it versus if we're pairing, what's the value that I'm getting? It's like, I get to hear how the other person approaches the problem. I get to experience how they work. They teach me things. I teach them things. We have this good rapport.

So I pair once a week with my friend, Chris, and we work on everything from this kind of mundane stuff to the big vision, like what would we do if we could totally change how this thing works, or something like that, and that kind of energy and get ideas, they build up. So that's one piece.

The other, this one's difficult, but having well-scoped, well-written issues is a huge time sink, but also, it can be one of the best ways get people engaged and keep them engaged. If I stop writing really specific issues, people peter off. Someone will ask, maybe only once, they'll ask, “Hey, I want to help out, or something. What should I pick up next?” They don't usually ask a second time, but I don't have something right away to hand off to them.

So what is the momentum? Can I keep writing up issues and things that other people can follow through with? And then presenting them with increasing levels of challenge of like, “I have this unstructured problem. We've worked on this a lot together. You can do this. How would you approach this? What do you think we should do?” I don't necessarily say,” You can do this,” because it’s more of a subtle cheerleading that's happening than that.

But “I'd love to hear your proposal of what should happen next” just is a really powerful moment and sometimes, that can be the thing that catapults somebody into taking more ownership of a project and gathering together other people to help them out. And then people do come and go, but the commits are still there! So that's something, right?

[chuckles]

Like, things have taken some steps forward.

DAMIEN: Yeah. People come and go, that's something you know you have to accept on an open source project, but it happens in other places, too. [chuckles] No team stays together for all of eternity.

JEN: Right.

DAMIEN: Is the project going to live on and how can you make it so that it does? So these are very good lessons, even for that.

ARTY: It seems like just investing in thinking about, we were talking initially about planning for the success case, even when things happen. So if we think about the case of okay, people are going to leave the team. [chuckles] What's the success case look like? Imagining the way that things go really well when people are leaving the team, what does that look like? What are the things that we wish we had in place to be able to ramp people up quickly, to be able to find new people, to work on the project quickly? All of those things that we can think about and open source has this to a much larger degree and challenge so that you really have to think about it a lot.

Where on a commercial project, it's one of those things that often happens when you wish it wouldn't and one of the things I see in corporate companies is you'll have a management change, or something will happen with a product that upsets a bunch of people and you'll have exodus phase on the project and then ending up often rewriting things because you lose your core knowledge on the project and nobody knows what's going on anymore and it actually becomes easier to rewrite the things than to [chuckles] figure out how it works. If we had imagined the ways that things could go well and prepared for those certain circumstances, maybe we wouldn't be in that situation.

ARTY: Yeah. You mentioned something really important there, too, which is what can we do to help people spin up more quickly on something. That's another big piece of sustained engagement because you need a group of people spun up quickly. You need a group of people who can figure out the next steps on their own. And so, we've spent a lot of time, the projects that I work most actively on, making sure that everything is there in the Read Me, making sure that if you run npm start that things work if you're running it on a different environment. Those types of little things, reducing those barriers can also go a long way and just widening the pool of people who could potentially help is another big one.

DAMIEN: How do you do that? Because you're a core contributor on the project. You have the curse of knowledge.

JEN: Yes.

DAMIEN: You have a development scene that is tightly home to work on this project.

JEN: That's a great question. Ah, I do have the curse of knowledge. Being easy to reach so that if people do encounter problems that they can find you and tell you, which can be, it can be a small step. Just making sure that if you have a documentation page, it's got a link at the bottom that’s like, “Find a problem, open an issue!” That sort of thing.

Also, I'm pretty active on Twitter. Sometimes other contributors, experienced contributors, they'll spot something that somebody else has posted and they'll say, “Hey, Jen, take a look at this,” and they bring it to my attention. There's this team effort to uncover those gaps.

Another aspect is just working in the open. So having open meetings, having open chat channels, places where people can interact with the people leading the projects, they can come to the meetings, things like that means that we're more likely to hear their feedback. So if we get feedback, “Hey, this thing was difficult,” making sure that we address it.

DAMIEN: Wow. Well.

JEN: I'm really big into user experience driven design. We've been talking about maintainability a lot, we’ve been talking about the code, and versions, and things, but coming back to what is the impact for our users.

If you accept a user experience driven way of developing software, it means that you're always going to need to be upgrading, you're always going to have to be flexing, changing, and growing because the products of 2 years ago versus the product of today can be really different. Open source library that you needed to rely on 2 years ago versus today. Maybe the web app ecosystem has shifted. Maybe there's new ways of doing things. Maybe there's new syntaxes that are available.

Sometimes, it can be a little frustrating because you feel like, “Oh, there's this endless pile of work. We made all these wrong choices back in the day and now this thing's hard to upgrade,” and all that.

A different mindset is to think about what do we know today that is different than what we knew yesterday? What are the things we know today about our users that inform our next move? How do these upgrades, or improvements, or my choice of open source library help the end user have a better experience? And trying to come back to that big picture from time to time, because it can be pretty frustrating. When you get stuck, you think like, “Oh, I can't. I just tried to upgrade this major version and everything broke and everything's terrible. But what's the feature list look like, how am I going to use this to deliver something better to the users can really help?”

DAMIEN: Wow.

ARTY: So at this part of the show, we usually do reflections and finish off with any final thoughts we had, or takeaways from the episode.

Damien, you want to start?

DAMIEN: The big takeaway I got from this is kind of… it's perspective. Jen, you mentioned a user experience driven design. I was already really close to that language, but from a perspective of contributors to an open source project, sponsors—both in terms of engineering and then money—and then also, users. Like, these are also users. These are also people who are impacted by the work we do. So in order to do it successfully, it's very important to think of how can this go well for them and then move to that direction. So thank you, that was really great.

M: For me, the big takeaway, I feel like I learned a whole lot just perspective wise of what it's like to work on a big open source project. I haven't really had a conversation like this with someone that's been that involved with a major resource project before. So I found that really insightful.

One of the big questions I asked you about how do we make this sustainable? [laughs] Like all the challenges around things. I know they're big challenges that we face in figuring that out and you had some really key insights around how we can frame things differently as opposed to framing it as an obligation, like a social obligation, or you should do this altruistically because it's the right thing to do as the appeal that we make is when you're talking to a contributor, how do you frame things to be a value proposition for them as an individual. When we're talking to a company, how do we frame things in a way so there's a value proposition for the company to get involved with doing something? And change the way that we frame all these things to be able to get folks involved because they realize benefits as individuals, as company, as people being directly involved in things?

I feel like if we can do some work to maybe change some of the framing around things. That maybe there's a pathway there to increase engagement and support of open source projects, which I think is one of those things that we really need to figure out. There's not really easy answers to that, but I feel like some of the insights you came to there are really key in finding a pathway to get there. So thank you, Jen. I appreciate the conversation.

JEN: So for me, when I'm reflecting on the most is the story that you shared already of trying to get people involved and just having them leave. They show up for a little while and then they disappear and where does all that work go? I'm interested to explore a little bit more of that small project life cycle.

I was pretty fortunate to just come in at a time where there was already a well-established community when I started getting involved in Ember and I'd love to hear more from other people about what are the success stories of those first few steps where someone began this little project and it really started to grow and take off. This might be a case where like some of the strategies I described, they work when you already have an established community. So it's kind of like a catch-22. I don’t know, that could be a really cool future episode is the beginning.

DAMIEN: Yeah. That's something I'd definitely like to hear about.

ARTY: Well, thank you for joining us, Jen. It was really a pleasure talking with you.

JEN: Thanks so much for having me!

Special Guest: Jen Weber.

Support Greater Than Code