The Changelog: Software Development, Open Source - Pushing webpack forward (Interview)

Episode Date: March 13, 2020

We sit down with Tobias Koppers of webpack fame to talk about his life as a full-time maintainer of one of the most highly used (4 million+ dependent repos!) and influential tools in all of the web. Things we ask Tobias include: how he got here, how he pays himself, has he ever gotten a raise, what his typical day is like, how he decides _what_ to work on, if he pays attention to the competition, and if he's ever suffered from burnout.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash Changelog. Welcome back, everyone. This is the Changelog, a podcast featuring the hackers, the leaders, and the innovators of the software world.

I'm Jared Santo, managing editor of changelog.com. On this episode, we shine our maintainer spotlight on Tobias Koppers from Webpack. This episode continues the maintainer spotlight series where we dig deep into the life of an open source software maintainer. We're producing this series in partnership with Tidelift. Huge thanks to them for making it possible. If you haven't heard of Tidelift, they are the first managed open source subscription that pays the maintainers of the exact projects that you're using while giving you the commercial support you've been looking for. Okay, here's Tobias. All right, we are joined by Tobias Koppers. Thanks for coming on Maintainer Spotlight, Tobias.

Hi, thanks for inviting me. So y'all may not know Tobias' name, maybe you do, but you definitely know what he is, the creator of Webpack, which is the build solution for modern web applications. And Tobias, working on Webpack full-time. Isn't that right? Yes, that's right. How long has that been?

Three years or so, I think. Yeah. So that's what we would sometimes call living the dream, and then sometimes the guests laugh, and sometimes they agree. Is it a dream, Tobias? I think it's a dream. It's really cool,

because you can work at home, be your own boss, don't have pressure, don't have deadlines, Tobias? I think it's a dream. It's really cool because you can work at home, be your own boss, don't have pressure, don't have deadlines, can decide what you want to do. I think it's really great. It's like self-employed but without customers.

We have customers but it's more like indirect customers. Right. It's very vague who is being your boss today, right? We have customers, but it's more like it's more indirect customers also. It's very vague who is being your boss today, right? It might be someone in the issues, it might be somebody on Twitter, it might be you.

What's some of your background, I guess, to, if you're living the dream as an open source developer, leading Webpack, what was some of your career history? Like, what did you walk away from to do this? Yeah, so I studied computer science and then worked for

a C-sharp developer in hardware-related stuff. And, yeah, so I started Webpack as part of a side project to my master's thesis, so I kind of only worked for a short period on a real company, and then I opened up.

So it's funny that you say you don't have customers, because if you look on your GitHub repo, Webpack has 4.1 million dependent repositories. I mean, to say it's arrived or reached critical mass would be a massive understatement. 53,000 GitHub stars, over 4 million dependent repos on GitHub alone.

It's also got to the point where it's reached so much usage that people are very willing to criticize it, complain about it, make memes. I'm guilty of a few memes although they're always in good fun and i'm just curious if at this stage of webpack's career and your

career does the public opinion of webpack that some of the complaints some of the criticisms or the jokes do those get to you personally or do you not care about that i don't care that much about i i think it's because it's so large, then you always get negative feedback. Right. Yeah, it's like you get very few positive feedback because nobody posts stuff about something. You get more negative feedback than positive feedback, I think,

especially on Twitter or other platforms. But I tend to ignore the negative or not take it personally more take it as ideas what you can improve or what can be done better how do you accomplish that because this is something you work on all the time and so something that happens is when you dedicate a lot to something is you can begin to identify like i'm the webpack guy i think of i always think of daniel stenberg who like curl is his life and he said like this is his life's work is curl he identifies very closely and so i'm curious if you don't identify yourself as like the webpack guy or if you just have thick skin and the

criticisms brush off how do you not focus on the criticisms yeah i think i identify as a wet pack as it's it's like my my baby so it's kind of yes but i'm not the guy who takes it um seriously that the negative feedback is bad or yeah so often it's more like they're out of frustration they say something bad and have the ability to ignore this or i yeah i don't know difficult blessing right there to be able to do that some people can't let it go and so i think that's a it's a great characteristic trait but for the position that you're in to be able to let that slide off your back or not affect you is gotta be helpful i think so yeah what about the other side so when you receive that much criticism like you said it's because there's just so many people using

your software like i said four million dependent repos everybody uses webpack either in love or in anger wherever they are does the sheer magnitude of Webpack's influence on our industry and the amount of users you have, does that weigh heavy on your shoulders? That's a difficult question. That's what you're here for. We're curious. Yes, the curious is...

He's like, I never thought about it. Now I'm starting to feel like it. Yeah. A lot. I'm thinking I'm more proud of what Webpack has, about the influence that Webpack has on the industry.

We kind of made some decisions and they led to industry standards like the code splitting example or on-demand loading. In 2012, we started with on-demand loading of parts of the application and it took like five years until this

became mainstream. And I think I'm pretty proud that this is something I started to engage or to promote. And this this industry standard is similar to other things like CSS modules

as part of the module graph or something like that. I think we had a lot of influence and I think it's cool to influence what the people or the community like or what the ecosystem is about. So it's like cool to be this,

have this standing like influencing the whole JavaScript community. Absolutely. And well-deserved influence, I would say. I think about doing this kind of work and I just think like, what motivated you to, I guess, you know, the sheer size of Webpack, its influence is one thing, but what motivated you to want to do it full-time? Was it just simply Webpack? Was it this lore of this lifestyle?

What made you want to do this? Yeah. Before I started full-time, I worked like 10 hours per week on Webpack, so like part-time or something like that. And it was more work involved i work work involved than i could do in the free time i have or in the part-time with having a real job so at this time john started like um collecting money to open collective and trying to fund the Webpack project and my contract ended and I decided to

not continue to work on my existing job and it was a risky step but I tried to work at least a few months from the existing money of the Webpack collective

to try to work a few months full-time to make progress in a number of features. Webpack 2 was, at this time, active. So, yeah, I started with the idea of only working a few months, but it took on and we got more funding. So I liked working on Webpack full time and so I just continued working on that. It was a risky

step because at this time we had only money to fund me about a few, I think, five or six months. I was about quitting my job and whizzing and I have a family and I got a baby at this time. But I think it was a good idea and a good step to do this

and work full-time on this. And I think I made a lot of progress and brought Webpack forward with working more on this. And yeah. And hearing the behind the scenes on that is really interesting because, as you had said, you have a baby, so you've got a lot of responsibility. And it sounds like you were the first funded person to do Webpack full time, which I'm assuming that since that time you've been fully funded by Webpack.

And I guess part of me is kind of curious, how do you get paid? Is it once per month? Who cuts the check? How does that work for you? For you all? Once per month, who cuts the check? How does that work for you? For you all? Once per month, and the bill is paid by Open Connected. It's like me collecting money

through Open Connected, and once a month, I decide who gets how much amount of money. It's automatic depending on contribution on GitHub. So I pay myself and I pay the other contributors. I pay myself a fixed wage

and the other contributors get money depending on the contributions they make depending how much they do by month. Yeah, so that's how it's working. So you've been full-time for three years and Webpack's budget has continued to increase. I believe it's working so you've been full-time for three years and webpacks budget has continued to increase i believe it's around 500 000 annual estimated according to the current open collective have you gotten a raise on the what have you ever gotten a raise like you paid yourself more money

like year two i'm doing a good job myself a giving myself a raise it's not that much that we have it's more like we get about the money monthly which we need to pay

all the contributors so it's kind of in an equal situation currently like with

DeVagos bundling us a lot it's more like we have like 2000 a month extra we can save.

But I also think it's important to make some kind of savings for the future if some sponsors go away or whatever happens, then that you can pay the contribution that I paid myself for longer than the sponsors

are there. It's kind of more long-term investment into the future. Also, it also makes sense from a sponsor perspective because most sponsors want to have a long-term support kind of idea. So it's also for the project itself a good idea to make some long-term guarantee. Yeah. We definitely want to dive deeper into at some point i guess the value add for those brands who sponsor webpack for sure more deeply but i'm kind of curious if you would say that you feel like you've sacrificed quite a bit to be a part

of webpack would you consider what you're doing a sacrifice i don't think it's a sacrifice it's more like i want to work on this and i do it for fun and for my work for my job so it's i not sure i guess the reason let me let me frame the question a little differently because the reason why i'm asking you this is not to say – to give you a chance to say, oh, yes, I sacrificed greatly for the community. They should love me. It's more like there's so much that happens in open source because of people who truly care, and often they're doing these things in sacrifice and not knowing they're actually sacrificing. And I say that because there's so much in open source that happens because of goodwill, not a direct Tobias puts out work, Tobias gets dollars to survive himself, his family, to provide, to invest in his future, plan for retirement, etc. There's so many things that layer into people's careers and lives and how they accumulate wealth, etc., to just live and enjoy their life.

And I ask you that because I see a lot of sacrifice in open source. And I would, from my perspective, say that it seems you've sacrificed. I also see it often that most maintainers or most observers are basically living from the maintainers and it's more like they don't get the funding or the energy that works the work they do. But I hope that WebHack is at least a little bit better that we pay our contributors, we pay myself. So it's probably not what you...

Maybe not worth what... Maybe the contributors or also myself don't get what's worth the work, but I think at least we get enough to make it not a sacrifice. You probably get more if you're working for a company in the industry. I think if you want to get rich, then don't work for open source. But at least you get something back, and it's not totally worthless right well that's the thing though there are people in open source that are getting rich too that's certainly happening out there right they're not sacrificing and it's also this opportunity cost this opportunity cost comes

into thought is like well you you're doing this and you're costing yourself an opportunity option elsewhere yeah i think i would frame it as a trade-off versus a sacrifice because like toby said at the beginning he's working on something he loves he has a massive amount of influence in an industry that he cares about he gets to create his own work day so there's a lot of things that he gets as being where he is. Maybe he's sacrificing on salary, but he's receiving benefit on something that's potentially more important to him. Not putting words in your mouth, but I think that's how I look at it.

Yeah, I'm glad you said that because that's kind of what I'm trying to figure out because as we do this show, we're thinking, okay, there are other future maintainers or current maintainers out there that are like, yeah, I just need a tribe.

I need somebody to cling to and Tobias has got some wisdom. He's done this thing. He's stepped off in these ways. It's like, how do I do those things with some assurances as well? How do I have a frame of reference for my future in open source? Thinking about the listeners listening to the show. Right. So Webpack is unique insofar as it has gained a substantial amount of financial backing. Yeah.

Which many projects never reach that. So many open source maintainers, like you said, Adam, they struggle to reach at least financial sustainability for their projects. And Webpack has gotten there. Now, there comes with other problems. We'll get into those. But, Tobias, in your eyes, like I said, a $500,000 estimated annual budget according to the current sponsors and all that kind of stuff. we'll get into those but tobias in your eyes you know like i said a five hundred thousand dollar

estimated annual budget according to like the current sponsors and all that kind of stuff so not an insignificant amount of money like you said maybe not as much money as value that web packs bringing out it's really low but in your eyes how did you get here how did you the team of webpack get to this place where you have large corporations sponsoring you in substantial sums what got you here i would say john got us here he started all the ideas about going to companies that are saying on confluence that we need sponsors and i also think we have we had a good timing because the community or the ecosystem and the company is starting to invest more in open source and care about open source. And I think the mentality of companies changed in the last time and they are more willing to pay or invest into open source maintaining or open source funding so it's probably luck and

yeah yeah it's also john that he did a good job in going to companies and asking them for funding us and sponsoring us and it's also the visibility the companies get from, also they are sponsors and they are good citizens. And also it's like companies need more workers and it's difficult. And the last time it got more difficult to get good employees. And so it's also a good advertisement for getting employees for companies.

So for us, it was basically good timing and luck and probably also we did a good job in our product, but I think it was much luck. And Sean. When you say Sean, that's Sean Larkin. We've had him on the show. We'll put that old episode in the show notes.

It's probably a couple of years ago now. Even back then, he was relentlessly enthusiastic yeah about webpack and i even would joke that if you can't figure out your webpack config just complain about it on twitter and sean larkin will magically swoop in and fix it for you yeah and that was 2016 december 2016 somewhat he may have invented like the if you look at the core team on your guys's github yourself johann Ewald, who's on loaders and plugins. You have Kees Kluskins

on development. And then Sean Larkin on public relations. And I think back then it was pretty avant-garde for Sean to be a PR person for an open source project. And like you said, he convinced a lot of these companies to bring money

to the table. Where did Sean come from? How did you get him on the team? Did he drop out of the sky? Did you convince him that Webpack was the bomb? How did you get Sean involved? Yeah, I think he basically joined by itself, so it's not that you go to him.

So it's more we didn't, we wasn't organized at this time when John joined and he thought we did a good job on this product on Webpack and he used it at his company. And so he came to us and said that we want to get us funded and want to get us organized. And so at this time we also started, because of John, we organized. And so at this time, we also started because of John, we started to organize ourselves as a core team.

We had no core team of organization stuff like that before. But at this time, we moved to OpenCollectic, moved to HH Foundation and organized as his core team and

yeah, so basically made the all management stuff and he just joined by himself and

so not that we hired him for anything. You didn't like put a Craigslist post out there. We need a

we need an evangelist for Webpack. Yeah. Put it on Craigslist. It's wild how he joined himself, too. He saw the ingredients for a great recipe and made it a meal. I like that. You like that?

I do. Well played. Well played, sir. So we talk about the challenges of having arrived financially and yet still having more people who aren't paid full time and lots of contributors involved and we started getting a little bit into the money situation and it sounds like every month you just kind of decide how to parcel out the current budget has there been struggles on deciding how the team allocates the funds is Is it just yourself that does that? Is it the core team that all gets together and says, you know, Tobias gets 10 grand this month

and we're going to put five grand towards conferences? How does that work or not work? So technically the core team decided, but on practice I decided and basically didn't change anything last years about funding. It's more like I have a tool which extracts all the contributions from GitHub and kind of value the contributions by time and multiply my money factor. And it's mostly automated process that puts some value in contributions of GitHub and then you pay it with this kind of amount of money on OmConnected.

It's just a threshold, but if you are over the threshold, then I send you an email to get some information about to get 2,000 points and you can convert it to $2,000 on OmConnectives by sending an expense and that's what we do and I think it's kind of like 10 to 20 people per month that get money and

there's also some kind of factoring if it's your dollar money where you don't want money in the last year end of the last year, then there's a factor which all the money received by contributors is multiplied by a lower factor, then everybody gets less if they have less money

and everybody gets normal amount if they have enough money. So currently we have enough money so everybody gets this amount. Is it written down somewhere, like what your salary is? Is it that organized or is it sort of loose in that regard i'm not and it's pretty loose because and the tool is not open source because

i'm afraid that it would be usable if you know how the algorithms work and which kind of contributions you have to spend to get more amount of money yeah so it's kind of game it kind of yeah you could game it hidden away or secret um but i think it's the most fair way if it's automated and nobody decides how much to get and i think there was only a very few complaints in the last years about I get too few money or so. So I think it's kind of working and I hope people don't see it like I want to work for Webex

because I get money. I hope nobody wants to contribute because of the money because if you have no sponsors, you don't get money. So you can't rely on this money and I always recommend to not rely on the money of the app. It's more like, I want to declare it more like an extra benefit, extra incentive you get out,

and you should be happy that you get it and don't demand for the money or so. I never advise anybody to get into open source for the money. There's lots of good reasons to do open source. Money is not a good reason. As developers, we have very marketable skills. Open source is not a place to go if you're trying to get rich quick

or slow, but there's a lot of good reasons to be involved. You could, though. The opportunities there just don't go there for those reasons. You could, but they're just easier paths to that end. Like, if that's your end, there's better means. That's all. Right. Gotcha. Tobias, can you speak to, I guess, your longevity with Open Collective?

Because we referenced episode 233 with Sean Larkin way back in December 2016, and that was quite a while ago and that was a big part of that conversation or a large part around the sustainability side of it was the efforts made to build your community within open collective and even to this day you're using it it allows you to you know accept i forget what the term is but i guess it's contributions for expenses so it it kind of gives you this framework this paying framework this you know how you deal with finances and money and budget and contributors on a financial side what's your experience with open collective how has that worked out for you i suppose good but what are the mechanics of that and how does that work day to day yeah it's looking pretty good they uh take care about all this and getting companies making orders for companies getting bills or getting

expensive for getting contracts for larger companies so it's kind of it's difficult for a company to pay open source software because yes it's not the process like donating something it's not the process that companies know

about so it's more like from the official side, it's like the company has a contract with Open Collective and they start paying the bills of Open Collective from the view of the company. And from our view, it's doing all the work with the company-related communication for us. And we have the money and we can send in

expenses. So we are working as a contributor is working for Open Collective on technical base and they are sending expenses and Open Collective pays the expenses from the contributor. It's pretty easy from

contributor side and I think it's also pretty easy from contributor side. And I think it's also pretty easy from company side because they're doing a lot of stuff to enable companies to pay to open source. So on Open Collective, the expense distribution is necessarily open. It's transparent. Yeah.

Has that ever caused problems or do you have concern about the amount of money that you're being paid being public information for anybody to see? I don't have problems with that. Apparently not. I mean, you're doing it. I wonder if you ever, you know, you value that privacy or not. It would have been funny if he was like, what? Oh, that's public. Like, Oh shoot. He hangs up.

I don't think it's a problem for contributors for me and that it's public and i don't think so many people look it up what i earn or what the contributors earn and do statistics about this you can download all the contribution all the payouts to contributors and all the pays by sponsors as a CSV table and make some bad stuff with it, but I don't think it's abused or anybody cares about

how much the contributors earn. It's not that we are earning so much that you should have problems with that. Sure. No. It's just a matter of privacy. Are you guys solely on Open Collective? Or do you also do Patreon or any other ways that people can support you?

I also started to make some kind of sponsors profile for myself or like non-Webpack related stuff or if you want to just give me money personally or whatever to make something else but it's not that I get a lot of money there and Open Collective also recently joined with GitHub Sponsors so you can make a

GitHub Sponsors profile which redirects the money to Open Collective and we don't have Patreon. I tried it but it doesn't work really well. I also think it's more beneficial to have only a single platform. It's more simple.

One place to send people. It seems diversity on the front of ways you can sustain a project or ways you can give would be competing interests, meaning that it would be difficult to funnel everyone to a place to have a flow to either contribute and get paid, file an expense, etc. It seems like it would be a lot of work. And I was actually excited to see that news with Open Collective and GitHub because in the current state of GitHub sponsors, you would have to have a company

and by way of what Open Collective has always been about, has been about is because in the current state of GitHub sponsors, you would have to have a company. And by way of what Open Collective has always been about, has been about making it so that the world can sort of self-organize sans company so that they can be sort of the legal entity. Yeah, the legal entity, the home of record, I think is what they call it when it comes to a nonprofit case. Plus, if you're seeking dollars from people and you wanted to make those contributions tax deductible, at least to the United States, then a 501c3 organization, which they provide, makes that more possible.

So it's interesting to hear you say that you've also got to get up sponsors profile. Is that connected them back to OpenClick or is that just... Yeah, that's the idea. OpenClip is the fiscal or legal entity behind GitHub Sponsors, which can receive the money. This episode is brought to you by Tidelift, managed open source backed by maintainers. Save time and reduce risk with by Tidelift, managed open source backed by maintainers.

Save time and reduce risk with a Tidelift subscription. Manage your application's dependencies covering millions of open source projects across JavaScript, Python, Java, PHP, Ruby,.NET, and more. Subscriptions include security updates, licensing verification and indemnification, maintenance and code improvement, package selection and version guidance, roadmap input, and more. The bottom line is this. You get all the capabilities you expect from commercial software, but for all of the key open source software

that you're already using and depending on. Tidelift works with GitHub, GitLab, Bitbucket, and more. They support every cloud platform out there. And of course, you can try it absolutely free. Start your free trial today at tidelift.com so device you've been working on webpack full-time for a while now just curious what your average work day looks like is there an average work day i think so yeah i am usually check issues at the day and kind of try to answer

all the issues and then i usually check the prs on that pack i don't have enabled github notifications or emails so all the work I do I only try to make it when I request it, so it's like a pull system. I pull the work from the issues, I pull the work from the pull requests and basically reviewing pull

requests and also trying to finish pull requests if they are in good shape and sometimes I do work myself Also, trying to finish pull requests if they are in good shape. And sometimes I do work myself. So it's really most time I spend reviewing pull requests or finishing pull requests. Because in most cases, it's not that the pull request is in a good shape, but it's not like it's super finished that I could instantly merge it and I don't want

to request too many nitpicks from the people, so it's often that I finish the pull request myself like doing PNAP, doing like minor stuff that fits better into the whole system and so on.

There's a lot of work involved in really finishing pull requests and contributors. And also doing some of my own pull requests and sometimes I get distracted from my own work and to my own work and don't do issues in pull requests. It's more like randomly choosing like what i do you also have a project board and sometimes i select stuff from there so looking at the repo right now there's 369 open issues 81 open pull requests i'm just curious if this is like a good place for you or do you feel like you're behind? Are you ahead

of normal? What's your normal queue look like? We don't really close issues or pull requests. Most issues stay open until the bot is closing them. It's not really that

we really are behind closing issues. I only look at the first place at first page of the issues and do the stuff related to them and issues never get closed because people don't close issues if there's problems at all but sometimes they don't close sure i can just see jared twinging tweaking because he's a completionist and and you're like you're literally it's like uh pulling his fingernails off of his hand or something like that like you're really hurting him i could tell just leaving stuff open yeah i was like every open issue for me is like a little another layer of stress yeah not for me. That's good. It's more like it's an issue

GitHub makes a blue dot or blue line for issues if you don't have read them so like unread issues

I take on unread issues and then I do the stuff in and if no issue is unread then I'm fine. That's what I think.

You mentioned you have a bot too that's closing things is that right? Did you say a bot too that's closing things. Is that right? Did you say a bot closes the issues with any closed? Yeah. So we have a perfect bot

and it's closing after three months in activity. And if people put a lot of comments on the... So if the bot warns you two weeks in advance that it should soon close and if somebody comments at this time, the bot warns you two weeks in advance that the issue is soon closed and if somebody

comments at this time, then the issue will stay open. So it's also a good factor to, if the issue is open longer and don't get closed by the bot, then people are really behind the issue and it's really important. So also, it's good to see that only the important issues

stay open. And if nobody is interested in the issue and it's not yet, it wasn't fixed, then what is holding it? And yeah, I think WebEx has many issues. There are bugs, there are edge cases, and the huge configuration comes with a lot of edge cases, the combination of whatever doesn't work. So if some people write issues about really edge casey stuff and never get fixed,

and they are not behind pushing this issue, and then it probably don't get fixed. Okay. So what you're saying is you like the plus one or the, what's the repin? What's the repin? What's the thing people say in issue comments where they bubble it back up? What's that again?

Ping or something? Bump. Bump. Yeah, bump. I should have known that. So you're an advocate for that then. You're an advocate for plus one or bumping. Yeah.

Because that's what rebubbles it back up to you. Yeah, so it's basically what prevents the bot from closing the issue. Alright, so what we're doing is we're teaching users out there how to game the Webpack open issue system. Periodically bump your issues, folks. It's better if you close the issue and reopen new issues. Oh, even better.

These are pro tips right here. How to get help on Webpack. Close and reopen. So there's maintenance, which we're talking about, and then there's progress. And as the core developer, right, one of the four, and then one's a PR person, so you have a few people on the core team

pushing the progress forward, pushing Webpack forward. How do you decide when you're going to maintain and when you're gonna maintain and when you're gonna make progress so i try to maintain to have all no unread issues on unread pull requests so it's basically the basic maintenance and i also try to fix bugs reported as soon as possible so it's it's but it's not that often that there's a bug

which can be fixed and but it's a basic maintenance I always do and after that it's like more like what I have

fun to do sometimes I want to do progress do some innovation stuff yeah make some cool new future

or whatever and sometimes I have fun making the some innovation stuff, make some cool new future or whatever. And sometimes I have fun making the pull requests somebody do and maintaining, fixing stuff and stuff like that. Reorganizing. Most maintenance is refactoring and cleaning up.

Most bugs need some refactoring or cleaning up. Most bugs need some refactoring or reorganization and cleanup. That's the part that's fun and also you do that. But you also have contributors who

want to push the progress and so I think most progress or most new features or most progress for Webpack is done by contributors. So we have this project board and people can look up,

do some progress, pick some cards and do some progress and make a pull request. And then it's like, most often I finish the pull request, but it's also kind of making progress when I finish a pull request and then it's like most often I finish the pull request but it's also kind of making progress when I finish a pull request which is some feature

from the project board which is pushing the project forward. Right. Kind of mood-driven development. What am I on mood for? Yeah, that's awesome. Which is interesting too because some will thrive on a regimented day.

And it seems like the way you optimize your day, Tobias, is essentially at the whim of what issues or pull requests wait for you and whether or not you might be or might not be inspired to sort of resist that temptation to deal with issues or pull requests and kind of dream a little bit. Yeah. But also, most progress comes from issues. So there are some issues.

I have an idea about a feature. I have some problems that inspire me to make this feature or make this improvement. I also think that progress comes from issues. So writing issues and contributors that write issues, which are also contributors, kind of, that are the inspiration for new features and for the direction of that.

Yeah. So anyone out there that's on Twitter or doing these criticisms, as Jerry mentioned earlier, these memes, instead of complaining or memeing, if that's a thing, maybe they should just hang out in issues and try to drive progress. Because if I'm hearing you correctly, then that means that the feedback from the community is critical to the progress of Webpack because it's a significant

driving force of it. Well, as evidence of that, the 369 open issues, only 27 of those are bugs. So you have a bug label. And so we're kind of talking about bugs versus progress, you know, fixing things versus creating new things. And so many, many of those open issues, and I assume many of which are also pull requests,

are, like Tobias says, they're not maintaining the status quo. They're just issues that happen to be pushing progress forward. Yeah. So, basically because I prioritize bugs, so it's kind of,

bugs annoy me, so it's kind of, I want to make Webpack as good as possible and want to ensure high quality and stability for Webpack because I think stability and bug-sween quality and stability for Webpack because I think stability and bug-free-ness is one of Webpack's main features

compared to competitors. And so I really prioritize bugs and really want to get rid of them. And if bugs are reported, I usually fix them within days. So hack number two, how to get your issue addressed is put the bug label

on it. Even if it happens to be a feature, just throw bug on there. Tobias is going to give it at least two looks. Yeah, but if you write issues, you can't decide the label. Only maintainers can decide the label. Ah, you guys have your guards up. You can decide it's a bug. Take it back, Jared. Take it back. I take it back.

I take it back. But you can write it's a bug. So you mentioned competitors, and there's been lots of them that popped up over the years pika parcel es builds a new one that's like a go bundler built-in go it's not a dozen bundle go but supposed to be really fast i'm sure there's many others do you pay attention to other bundlers that show up on the scene yeah sure are sure. Are you cherry-picking features? Are you looking for inspiration? Are you ever felt threatened by a particular bundler that's launched? Yeah, I mean, we usually steal features from competitors.

That's nice. It's also a really good inspiration that a competitor decided to make some own product because most often they do it because they want to have some special feature like in example Rollup Rollup was created to make some ES module first

approach and make some super special optimizations which are related to ECMASIP modules and we also took this feature and integrated it into WebHack It's not that easy to integrate features from competitors because we also have to be compatible

to all existing features which makes it sometimes more involved, more difficult to now edge cases to integrate features from competitors. But we try our best to get the ideas from competitors and integrate them like roll-out inspirators to better

integration, powerful for easier configuration and for whatever, for speed and yeah, it's but most often it's a trade-off so you can make a really special bundler

which focuses on something you can't focus on because we have a broader user base, more features, and it's more configurable, more sensibility. And so it's not often that easy to just copy the features from competitors. But we try our best to get all the cool features from competitors. But we try our best to get all the cool features from competitors too. It's open source, so it's more the mentality

of open source to share ideas. And I also think if you're doing a new bundle, you're also copying most features from that page. And it's like exchanging features. And in the end, the user benefits if all tools have the same feature set

or similar feature set or at least share a common feature set which can work cross-border. If someone is listening to this that happens to be considering a competitor or a maintainer of a competitor, what where you're sharing knowledge and sort of leveling each other up and you can help them optimize their things. And maybe there's a place for their tool and a place for your tool as well that while you're competitors, you don't have to be bloodthirsty competitors.

You can be collaborative. Yes, I would say, yeah, if somebody has new ideas and want to do some cool stuff, then you can write an issue and we can discuss this. And we also have a Slack channel where we can chat with each other and share ideas. And I often see that people don't want to contribute to the webpack because it's too complicated and they start a new bundle because it's easier to create a new bundle with the feature,

the special idea, the new idea, the feature they want. And yes, it's true. But I hope that on long term that people write a prototype and on bundle kind of prototype and then on long term want to invest into integrating this into Webpack. But I can't force anybody to contribute to Webpack or to integrate to Webpack. And often it's not possible if you want to bundle and go with it.

It's very difficult to integrate it into Webpack. And yeah, so it's kind of difficult. I'm curious, taking a sidestep, I guess, to a overarching theme, which often happens to people who are obsessed with their work or really into what they do. It seems like you're really into what you do. Clearly, you've made a very purposeful career path towards open source, towards Webpackpack and you're committed to it

burnout often happens whenever you're in that kind of state sometimes it's you excel and there's no burnout but how do you sort of maintain i suppose your maybe your experience burnout so share with us maybe your aspects on burnout if you're have ever been near to it that People burn out on open source and so far I'm not unhappy and I don't think I'm burning out but I also have a bit afraid that it may happen and yeah, I'm not sure.

Yeah. I hope it doesn't happen to us. Yeah. One antidote we've seen to burnout is having some sort of analog some sort of afk kind of thing like when you're not at the keyboard when you're not working when you're not in issues or pull requests you're not coding you know what is it what's your pastime you have a family so maybe that's it but share with us maybe what you may purposefully do or by happenstance do as an antidote to burnout?

So basically in my free time, I spend most of the time webpacking and in my free time, I basically have a family. I have two small childs, one is one year, the other is two years, maybe three. So it's really a lot of work with family and children. And yeah, so it's kind of family is my alternative to working. Well, Tobias, thanks so much for coming on the show. We really appreciate you. We really appreciate all the work that you put in and really the trailblazing that you've done on Webpack along with Sean and the team congratulations on all your success and uh hope for future success

as well we just really appreciate what you've been up to and sitting down with us and tell us about it thank you for tuning in to our Maintainer Spotlight series. Hey, if you appreciate Webpack and the work Tobias has been putting in over the years, here's what to do. Pop open your show notes, follow the Discuss on Changelog news link, and leave a comment on the episode page. I'm sure he'd love to hear from you. I once again want to thank Tobias Koppers for joining us on the show. This episode was brought to you by our friends at Tidelift. They are all about paying the maintainers.

It was hosted by Adam Stachowiak and myself, Jared Santo. We get our beats farm fresh from the mysterious Breakmaster Cylinder, and we're brought to you by awesome sponsors. Thanks again to Fastly, Linode, and Real Bar for helping us do what we do. That's all for now. We'll talk to you again next time. Thank you. Outro Music