Panel Discussion: Open Source & “Perceived Competition” Between Projects

Thank you, everyone, for joining this panel. I'm sure everyone is very excited to hear your insights on all things open source.

So the first question is, as open source contributors, involved in multiple projects, can you share your insights on how you decide which projects to contribute to or create? We can start off with Dan. Sorry. The question is, which projects have you worked on? Just insights on how you decide to pick which projects to work on or create. Oh. I mean, I think usually it's, like, whatever you need for work. That tends to be the case. I think, at least in my case, I haven't created many projects. I contributed to a bunch. But in cases where I created something, it was usually because I was building a product and I needed a piece that did not exist. And I tried to make it. And then sometimes you try to make it usable by other people. I think it's mainly about the project that kind of inspires you or intrigues you. Just pick one. It doesn't really matter which one. Just don't try to do all of them. That's the most important thing, I think. And then you become an expert in one specific one. And that's, like, really helpful. Because you see all the different environments that people use something in. Which is often really surprising. But that just requires time to build up that knowledge. So just pick one that intrigues you.

Yeah, I think for me it was really sort of finding communities that I felt drawn toward. At the very beginning of my career, I was really interested in open data and civic tech. And just found really welcoming people in that space. I didn't have the skills yet at that time to really meaningfully make an impact. But I still felt like it was just a really interesting time to be exploring, at that time, these Ruby libraries for data processing. And if it wasn't for the community around that, I wouldn't have maybe even started this career.

I think for me it's always been work driven. Or that's where I've found the projects I want to work on. I had a problem at work. Like, where I saw a missing piece that I wanted to contribute. And then I did. Back when I had free time. I started learning React in mid-2015. Sort of related to a work project. And it was coincidentally the same time that Redux came out. I volunteered to write an FAQ page for the Redux docs. Dan accepted it and merged it. Gave me commit rights. Got busy with React. And then handed over the maintainer keys of Redux to me and another guy named Tim Dorr.

I owe Dan for my start in open source. I wouldn't be here without him volunteering to say, hey, you can get involved. And I owe you. Since I first got involved in Redux, too. Whenever we talk about this, I think about this scene from Tom Sawyer. Painting the fence. Or he paints the fence and makes it look like the most interesting thing someone can do. And then somebody takes over. Great. That's so cool. And I love the fact that you were speaking about the opportunities that you gained.

As someone who wants to be an open source contributor, what cool opportunities have you seen other people get? Have you got yourself? And what would you say to someone who feels like they don't have enough time for it? How would you convince them to actually make time to contribute to open source projects? We can go the other way around this time to switch it up. So I'll give a relatively recent example. We've had two primary maintainers on Redux Toolkit for the last couple of years. Myself and Lenz. And we had a person hanging out in our chat channel answering a lot of questions named Ben.

And about a year ago, he started contributing some actual pull requests with features. And he was enthusiastic and the pull requests were well tested and he was answering questions and we could see he was actively contributing. And so he was like, you're a maintainer, too. Welcome, join us. And it's kind of like that showing the initiative and trying to get involved, that shows the maintainers that you're interested, you get their trust, and they'll be happy to hand over more responsibility.

So I have a different answer. And that is, like, that's a good answer. But I also have a different one. That is kind of see it as part of your work, too. Maybe not contributing huge amounts of code or anything like that, but you are software developers and you're using third-party libraries. So if you come across a bug and you want to get involved in open source, the best thing you can do is write a good reproduction of that bug, file a very good issue, and that's a perfect way to get involved in open source. And as you do that in different projects, you start to kind of learn about the project.

You see the fixes. You see the pull requests that maybe someone else wrote. And given enough time, you might be comfortable to actually fixing the issue maybe in your work time where you get paid for it, if it's a small fix and it's something that you benefit in your company. And things like filing issues and stuff like that, don't ask for permission to do that. That's part of your work. Like, if you're spending days on it, of course, it's different. But yeah. Yeah, and another thing that I found, especially in the course of doing your day job, like, my day job currently involves working on an open source project, but before that, I was a product engineer at a bunch of different companies.

And the last job I had working on a product was at Venmo. So we were using a lot of the tools that we all use in this room, but for testing, obviously, testing library. So setting a whole team up to contribute to a large test suite, we were using some linting rules from the testing library ESLint plugin. And browsing through the GitHub issues, I saw there was some ideas for new rules to add to that library and thought, okay, well, I haven't written an ESLint rule before. This seems like a good opportunity to contribute to something that will also benefit my team but contribute to the larger community. And what was so cool about that experience and, you know, amazing maintainers on that project is just, you know, being out of your comfort zone, working on, like in my case, you know, understanding abstract syntax trees, learning about just the whole DX of developing and testing linter rules, and then getting this amazing code review from folks who are extremely well versed in, you know, in this particular area.

And that being like such an amazing learning opportunity, no matter what stage of your career you are, you know, the cliche about software is that it's just an unbelievably vast and expansive field. And so it's open source for me has always presented a really fun chance to get outside my comfort zone and, you know, be able to have give and receive mentorship in a really generative, really productive way. So I don't think I've ever given maintainers right to anyone that was like asking for it. That's not kind of how it works. First, kind of the opposite, whenever it gets annoying to not make someone a maintainer, then I make that person a maintainer. That's basically the essence. That sounds very negative. But what I mean with it is like, if people respond regularly on issues, they're like, oh, I can't reproduce this, or this is the fix. And then they answer, but they can't close the issue.

I'm like, Oh, it would be very convenient if that person is on spot every time, we'd also close the issue. So it gives the rights for that. Same with pull requests. If someone submits free pull requests, which are pretty good, then it's annoying that that pull request lives in their own form, because you cannot commit back and that kind of stuff. So you invite them to become a maintainer. And that's how it generally works, I think. Okay, can I ask you to repeat the question? It's been a while. I actually didn't write this down. But it was just about how would you convince someone to contribute to open source and what opportunities have you got? Someone else? Yeah, I guess like, I don't see myself in the business of convincing people to contribute to open source. Like, it's not necessarily a good idea always. Like, both for your and the other person's sanity. Like, okay, more seriously, I think, like, there are different kinds of contributions. And also, like, I think some end up, you know, like, realistically, if you send the PR, sometimes, you know, it's going to get merged, it's going to get reviewed. Sometimes it's, it's not going to get reviewed, they're not going to get merged.

Sometimes it's, it's not going to get reviewed, they're not going to get merged. And sometimes you get some good experience out of it, or like you get some knowledge out of it. And sometimes you just waste the time. So I think like, it's just, like, in my experience, I feel like I've gotten lazier about sending pull requests, because I'm just well, like, it looks like the person maintaining is it is pretty busy, like, their views are not coming in fast. Or like, it looks like the change I'm about to make, like, I don't even know if that's a good change. So I'm probably just not send it. So I don't know if like, it's always a good idea. But I think so like, like, I think it's just important to be prepared for disappointment that like you worked on this pull request for like a week and then nobody reviews it like that happens. But in terms of like what as a maintainer, like what I would usually find most valuable is, yeah, so like issue, when there is an issue, and I don't know what the problem is, like, there is a bug filed. And somebody says, like, oh, this thing is crashing, but like, I don't know how to reproduce it. And then somebody else comes over and digs into the code and like gives a precise way to reproduce the bug. That's very valuable. And so like, as a maintainer, I say, okay, like this person is actually like looking at what's happening in the code, and it's trying to help. And I just trust this person more. And then if this person sends a, you know, a code change, like, again, I kind of trust them more, it's easier to review.

And I think like, if you do want to kind of contribute to open source, I think there's just kind of like two genres. Like one genre is you send like a small change, and like you barely, you kind of just like throw it away. Like, here's the thing that worked for me, like, good luck with it. And then it's, it's still nice, because it gives maintainer a chance, like maybe that's a good idea, maybe that's a good change, or it gives them, you know, an idea to do something different. But it is kind of a contribution, right? You just send something out there, and hope it will help somebody maybe even like a random person scanning the pull request to find the fix for the same issue.

And another genre is actually like diving into, like how, like how the rest of the project's code is written, and kind of like really testing your change, really thinking through, like, you know, is this the right change to make? Or does it break something else? And then as a maintainer, if I see that, you know, it looks like you've done your homework, so to speak, it's so much easier to trust that sometimes I'm like, yeah, like, you know, looks good. Hopefully, this doesn't break stuff. But if it breaks stuff, I know there's a person who cares, who will come back and fix it.

Yeah, I don't know. That's helpful. No, thank you for that. Those are really good answers, because you spoke a lot about collaboration, upskilling, and how it can actually help you in your day job to improve like your coding practices and things like that. But we're here about the competition. And so what differentiates between, because all competition isn't bad, right? There's healthy competition. But what differentiates between from healthy competition to unhealthy competition? And how do you foster and make sure that we engage in a healthy kind? And do you feel like as maintainers, you have a role to play within this? So let's start off with Dan.

Oh, that's a tough one. Yeah, I'm not, I don't know. I don't want to set the rules. I think, I think there is like a kind of code of honor, an implicit code of honor, but I think it's different for different people. Like, not, you know, not saying like, I'll try bad things about other projects seems like maybe a good idea. But then there are some differences. And sometimes these differences are pretty significant. And so there's like this hard, like hard balance of like, how do you, and especially like, there's, you know, there's this equilibrium of like, if everybody is nice to each other, it's nice.

But then like, if you're if there's like a new, you know, there's like an established kind of set of players, and then there's a new player who, like does something differently. And because they're small, they kind of need to punch up, because they need to kind of prove, you know, here's why you should choose the small thing over something established. And so they kind of have to, like, expose the flaws in the establishment. And then the thing is, like, the established players can't really punch down because it looks bad. And so it's it's like a tough balance of like, how do you play this game? I actually don't know. Let's hear from other people.

Yeah, I think like, competition is a bit overperceived. In some ways. I have like a bunch of really interesting anecdotes around that. For example, I worked for quite a long time on my bags. I don't really like my bags that much. So here's the fun thing. Dennis is currently working with MobX, I'm currently working with Redux. I don't like... So that's how far competition goes.

No, but I literally had people walk up to me and said, like, why did you publish Immer? That only helps Redux and MobX? And it's like, yeah, who cares? Like, it's people sometimes think about open source as companies, where they're like, companies are competing with each other in a certain way. Right. And so they also talk like that's an issue. And they go like, hey, if you don't introduce this feature, I'm going to move to Redux. And it's like, okay, fine. Then apparently Redux is better for use case. So I rather have you move to Redux so that I don't have to deal with your issues. So people kind of over appreciate how that's in general works, I think. But the kind of rule I try to keep in my mind, as like, you're basically a jitters out there. Like, I have an opinion about other frameworks. Everyone here has an opinion about other frameworks. I asked JetGPT this morning what Mark thinks about MobX and it don't make me sleep really well. But just hallucinated, sadly. But anyway, like, we are all biased in a certain way. So it's up to you to decide what kind of works.

I think that's like the fair way to divide it. I think that's well said. Yeah, I think the whole question of competition, I don't know, I think of my kind of frame of reference for competition is playing sports in high school. And, you know, specifically basketball, soccer, football. And, you know, my, like, my coaches just really instilled this idea that like, you really want the competition at its best is when your opponent really pushes you to evolve and sort of bring the best that you can bring to the table as well. So I really think that, you know, it's sort of like, I'm a basketball fan, as I said, there in the, in the US, which is where I live, originally Canadian. Any Canadians in the room? Can I get a couple of who's? None. A one. A one. Amazing. Okay. Phew, there's always a couple secret Canadians lurking around so I just had to make sure. But yeah, there was the WNBA championships this week, and my team's New York Liberty, they lost a nail biter to Las Vegas Aces, who are the better team. But like Las Vegas, they had two injuries after the second game of two of their starters. And like, you know, as the team on the other side, like, that's always, you know, kind of disappointing, like, you know, if you want your competitors to be their best, and you know, you don't want to beat someone because they're, you know, having an off day, essentially.

So I think that that's, you know, the, the spirit of competition that like, I want to be a part of in the JavaScript and react ecosystems are like panels like this, you know, and not punching up or down or in any, any direction where you're like, trying to take away from what someone else has built. So I think, I think that things like this and meeting in person are just super productive. And like a great reminder that there are many, many, many other people that I think share in that idea of really productive competition in that sense of like, I want to bring out the best in you and I and by putting our ideas, you know, throwing them in the middle and kind of seeing what shakes out that that's how we're gonna get the best ideas in the end, you know? Yeah, that's how I think about it.

Oh, such great answers. I see it as academia, really, like, where maybe different universities compete about the same research, but it's mainly about sharing ideas. And it's mainly about the ideas competing and the best ideas winning if it is a competition. So it's not a competition between individuals. If it's the healthy kind of competition that is, it's a competition of ideas. And I think, like, that's what makes it so great to meet all of you and talk about all of these things. Because that's when the ideas can really clash and form something better. And you can inspire each other. And we share a lot of the same common problems as well.

So like, there's this form of competition where you're competing and withholding information from someone else because you want to win. Healthy competition, which is the kind I think we have is where we'd rather share these ideas and discuss them and make kind of all of our frameworks better in the in the process. So that's the healthy kind, I think. And I spent a lot of time reading discussion threads on Reddit and Twitter. And I see a lot of people fanboying the bad way. And saying, like, I love this tool. And anybody who likes this other tool is an awful person. And yes, there's kind of the competition in that if you choose to use React query to fetch data, you're probably not using Redux to do it. But that's okay.

We are all taking inspiration and learning ideas from each other's tools and progress and pull requests. You know, the RTK query data fetching library that's part of Redux toolkit directly stole idea and drew inspiration from React query and Apollo. I've spent work this year trying to figure out how to properly set up packages for ES module compatibility. I published a blog post and you know Apollo and React query have learned from it. I contributed the changes over to Emmer. I even have a quote on the top of Emmer's documentation saying how wonderful it is. Like, there's a lot of knowledge sharing back and forth.

Yes, there's kind of the competition in that if you choose to use React query to fetch data, you're probably not using Redux to do it. But that's okay. We're all trying to build tools that solve problems in slightly different ways. And we are trying to make the best tools so that you can decide which one is the best fit for your situation. Love those. Oh, yeah. Round of applause for that. I love that. Well, I really want to speak about AI just a little bit. I just love it. I used to use copilot a lot. And now that I'm not using it, I'm like, oh, my goodness. This is going to be super tedious. But to those people who may be intimidated to break in, or not break in, but essentially contribute in an open source way, do you feel like AI and these tools have helped to encourage these people to contribute? Or what do you think the role of AI has been in terms of open source and maybe collaboration and things like that?

I haven't really considered AI and open source specifically. I did finally turn on copilot in VS code a few months ago. And I mean, my own personal perspective, I think that AI is and machine learning are potentially viable tools. My biggest concern is in a lot of ways it seems like you already have to know enough about the topic to use them safely. I've seen numerous cases where people pop in and ask questions and say, like, I'm trying to use a certain Redux API that was suggested by chat GPT, except it suggested something that literally does not exist. Or in one case, a person asked me about a blog post I'd written about fetching data in selectors, except that I never wrote the blog post. It's seen enough examples of my blog URLs to mimic it and suggest it, and it does not exist. And so I think especially a lot of beginners, they're learning great things from, you know, chat GPT and suggestions, but you sort of have to know enough to filter the suggestions yourself.

So my own experience, it's like, you know, copilot is great at filling in lists of code that I'm writing, or, like, some bits and pieces, but you do have to exercise some caution as you're using these things. I think my perspective is AI can be used for a lot of different things, right? There's the generative part where it writes your code for you, but I think where AI could shine when it comes to open source, if you want to contribute, is to explain this unfamiliar code base, because open source projects are often quite complex. The code looks a bit different from what you might be used to from applications. So using AI to explain and get into how an open source project functions could be a very, very good use case, I think.

Yeah, I also have not really deeply considered AI in the context of open source, although working on Apollo Client, which is a GraphQL client, you know, I do have some some colleagues who've been thinking about AI in the context of GraphQL, which I think is, you know, a whole separate panel and very interesting conversation. But yeah, a colleague of mine, Patrick, he has a talk, I believe it's up online now, from GraphQL Summit just about, you know, generating, like, schemas with AI and really just showing some sort of glimpses of the future and like proofs of concept. But certainly, I think certain technologies, in particular, like a query language, like GraphQL, there are, I think there will be some really interesting ways in which, you know, we will really be able to, you know, automatically turn sort of natural language commands into queries and really realize this idea of, like, the computer as a true, like, user agent. And so yeah, I think it's a, you know, fascinating topic overall, but I would encourage you to check out Patrick's talk. And, you know, if you're interested about that specific niche there.

Yeah, I didn't have a lot of thoughts about it either. I didn't think too much about it. The only thing I discovered is that like, there's one benefit to Brexit, and that's you have more AI services around here than in the EU. I don't really have much to add, I think. I really agree with the, it might be a helpful way to explore the code base. But yeah, other than that, well, GPT-4 is a lot better than GPT-3 here, for example, at, like, given, like, fake answers. I mean, not better. Yeah. Yeah. It gives fewer fake answers. But yeah, I don't know. We'll see. We'll see how it goes. I guess, like, one distinction is, like, I think it's interesting to think about, like, open source is usually, like, shared foundations. But then I feel like the place where, like, AI kind of shines more right now is, like, built on top of those. So like, you know, it's easy to, like, generate React components, but maybe not, like, write React itself. So I don't know if it will make its way to, like, being useful in the kind of lower levels where you have to have this precision. Whereas, like, at higher levels, when you just, like, compose things together, that seems like the, you know, the most comfortable, like, place to apply AI right now. Thank you. It's so interesting the way that AI is just, like, revolutionizing the way that we work. I wouldn't go as far as to say we're all gonna lose our jobs tomorrow.

But I will say that it's definitely helping, but it's not totally accurate, as we're speaking about. And one thing I want to end on is the fact that open source extends beyond code. And there's other ways that we can contribute in terms of non-code. Can you all just give examples for the last, like, what, two minutes of ways that people can contribute when it doesn't come to coding and good examples that you may have? Like I said, I got my start with Redux by offering to contribute a docs page. And every project needs more documentation. And sometimes you contribute, you can contribute to the docs without needing to have a deep understanding of the code. Docs contributions are always, always welcome.

Yeah, I agree. And I got started with Redux by writing the server-side rendering tests that were missing. So writing tests is also a good, good contribution. Even if you don't want to contribute code that runs in someone else's browser, you know. Also, as we talked about previously, issues and good reproductions are invaluable. I want to really push that point. They help so, so much. Yeah. Yeah, plus one on reproductions. In addition to, yeah, I'm just going to pile on sort of the answers that came before. They're all so important. But definitely, you know, if you're researching something based on an issue you're facing, and you're in the GitHub issues, and you have a few minutes to spare and see, you know, a question hanging out that, you know, is where you have the answer at your fingertips, or you have the ability to help create that reproduction or, you know, just move the conversation along in a really positive way. That is super, super appreciated as well.

Yeah. One thing I think about is competition between things can often be seen as like, or people perceive it as like maybe one solution is smarter or modern or faster or whatever than the other. But that's usually not where competing projects come from. Usually they come from trying to solve different problems. But those are often not very like explicit, or they're like hard to really well communicate what kind of set of problems one solution is trying to solve. And that's usually where the difference is. So if you have like, a good angle on that, or you feel like this solution worked really well in these circumstances, that's like super valuable for the community to be able to share that. Because like, often your view on that is even better than the maintainers view they have on such a thing. I think whatever gets you excited. Like, if you know, want to make like a library faster, that's like one thing you want to write a bit of docs, another thing, you can just like help people in issues or on Twitter or whatever. So whatever you feel like you want to do. Perfect timing. Well, thank you so much for those answers and your insights. And can we get a round of applause please?