0:00

If I'm trying to engage with you

0:02

on an issue. And every

0:04

response to me is rude,

0:07

sarcastic, disrespectful.

0:10

I have no problem. Just closing the issue

0:12

and saying, I'm sorry, I'm not gonna be

0:15

able to continue on with this issue

0:17

in this way. I have already tried

0:20

my best to be respectful

0:22

and replying. You are not responding

0:25

the same way. So I'm going to move

0:27

on to other things now and just

0:29

leave it at that. Maintainers are not

0:31

under any obligation to

0:34

continue a conversation that

0:36

is negatively affecting

0:38

their mental health that is draining

0:40

the , um, uh , you're not being paid

0:43

to deal with that. There's no

0:45

reason to put up with it.

0:49

Hi everyone. And welcome to developer

0:52

experience a podcast by

0:54

Algolia. We chat with guests who build

0:57

products for developers about their developer

0:59

experience strategy, what it

1:01

means for them, why it's. And

1:04

so on, on today's episode, we

1:06

are going to talk about sustaining

1:09

open source projects. So

1:11

there's a recurring meme that you

1:14

will see if you spend some time on tech, Twitter,

1:16

and it's that all modern digital infrastructure

1:19

somehow depends on a project that some random

1:21

person has been thankly maintaining

1:23

for day in Nebraska. And

1:26

this has been a particularly

1:28

hot topic in tech for the last couple

1:30

of years. How do you actively

1:33

maintain a project that others rely

1:36

on, but don't bring revenue. How

1:38

do you deal with stress? How do you deal with

1:41

fatigue and is the

1:43

promise of up , and so are still

1:45

holding that you will learn that you

1:47

will grow and meet other people.

1:49

Is that still holding? So to

1:51

talk about this today, we have Nicholas

1:54

Zais . Nicholas is the creator and

1:57

maintainer of lint , a

1:59

widely popular JavaScript linter

2:02

with a giant ecosystem of

2:04

third parts he plugins. So

2:06

if you have a JavaScript project with a continuous

2:08

integration, you are certainly

2:11

using it and you do not want it

2:13

to fail. Nicholas is also a

2:15

seasoned author who wrote several books

2:18

about JavaScript since the early two thousands

2:20

and more block post than you can probably

2:23

afford to read. Nicholas. I'm

2:25

delighted to have you welcome on this show.

2:27

Thanks for having me.

2:29

So let's get started right away. Slint

2:32

has become a staple of the JavaScript

2:35

ecosystem. There is no question about

2:37

that. Most JavaScript projects

2:39

use it. We all run lint in our

2:42

CI . We all rerun our CI

2:44

because we forgot to lend something and

2:46

we forgot to make it automatic on our machines.

2:49

And because it's highly extensible,

2:52

you even have other projects that are

2:54

in the same domain, like pretier for

2:56

example, that can be run in

3:00

Esly . So they kind of enter the

3:02

ecosystem while being different

3:04

projects. How do you

3:07

handle becoming a pillar

3:09

of an ecosystem? And what does this

3:11

concretely means in terms of load time,

3:14

investment and responsibilities?

3:17

Well, I think the , at the most

3:20

important thing for not just me

3:22

or any of our maintainers

3:24

on the ES Lin team is to

3:27

have a lot of respect for

3:29

the developers and their time.

3:32

And that really causes

3:34

us to think long and hard about

3:38

what changes we we make. And when,

3:40

because we know that esent is

3:43

embedded in a lot of companies

3:45

, CI systems, that

3:47

means if we introduce a change that

3:51

breaks some existing behavior, we

3:54

could be wasting dozens

3:56

or hundreds of developers time

3:58

for several while we seek

4:00

to fix that. So we spend a

4:03

lot of time thinking about how

4:05

are we going to impact somebody's

4:07

life if they upgrade to this tomorrow?

4:10

And as a result, I think that

4:12

we're a little less risk

4:15

averse than some other projects

4:18

in the similar domain, because

4:20

for other projects, if something

4:23

breaks, it's almost always because

4:25

of something that they did. But if we update

4:27

a rule that all of a

4:29

sudden is flagging something as a warning that

4:32

wasn't previously flagged like that that's

4:35

something that can block a lot of developers from

4:37

doing their job . So it's a responsibility

4:40

we take really seriously.

4:42

And we do put an

4:45

extra amount of thought into all of the changes

4:47

that go in so that we're not disrupting

4:49

the ecosystem at any random

4:51

point in time.

4:53

So what's really interesting in

4:55

what you just shared is that there is a strong

4:58

mindset. Like it does look

5:00

like it's starts from values and a

5:02

mindset, and I'm really interested

5:05

in how you build something like

5:07

that, how you build such a mindset and like,

5:10

you know, the size of lint could be

5:12

thought of as, oh yeah. When you

5:14

contribute to something as big as lint

5:16

, obviously you're gonna be careful, but

5:19

at the same time, I'm not so sure, like

5:21

there are many reasons why people contribute

5:24

to open source. Not everybody is

5:26

necessarily as passionate about it

5:28

or wants to apply

5:31

the same level of professionalism

5:34

that they would in a job where

5:36

they get paid for it. So I'm

5:38

wondering how do you create that culture?

5:41

Where does stem from?

5:43

I think if I were to trace it back, I would

5:45

go back to the first

5:48

year of ES L's existence,

5:51

where there were just a small number of people

5:53

who were using it, but they were really passionate about

5:55

it. And I was still managing

5:58

it as just a hobby project.

6:01

And at one point

6:03

I made a commit directly to

6:06

the main branch and it

6:08

was something that broke a previous behavior.

6:11

E even though it was fixing a bug and

6:14

I thought, you know , I was doing the

6:16

right. And so I released it. And

6:20

one of the contributors sent

6:23

me a message and just said, Hey, you know, you changed

6:25

this. I didn't know it was coming. It

6:28

broke my workflow . You

6:30

really shouldn't be committing to the main branch

6:33

directly. You should be sending a poll

6:35

request so that people book

6:37

can be made aware of what changes are coming in. And

6:40

that was the first time anybody

6:42

had really mentioned

6:44

anything like that to me, that they

6:47

were relying on the project. And

6:50

I couldn't just sneak in stealthy

6:52

changes whenever I wanted, because it

6:55

was something that I thought was right for the project,

6:57

because that's a really fast way to

6:59

alienate users. And

7:03

that was really the beginning

7:05

of the thought process on

7:07

the project of, okay, this is a

7:10

tool that people are starting to rely on. We

7:12

can't just make changes whenever

7:15

we want, even though I'm

7:17

the author and the sole maintainer

7:19

at that point in time, I can't just

7:21

be committing directly to the

7:24

main branch without letting people

7:26

know what's landing and

7:28

allowing them to voice their concerns before

7:30

it gets released. And we've

7:33

just continued to build on that

7:35

theory over time, where

7:38

if you go on our readme , we have our

7:40

published semantic versioning

7:43

policy. And that was developed

7:46

over years as a team,

7:48

as we figured out the mistakes that we

7:51

made, like, okay, we made this change,

7:53

even though it seemed right. It caused

7:56

everybody CI system to break. So

7:59

what's more important here. Well,

8:01

it's much more important to us that

8:04

people CI systems continue

8:06

to work. And that if for some reason

8:08

they're not going to work, then that

8:11

is most likely going to be a

8:13

major version release for esent so

8:15

that they know ahead of time that it's coming. And

8:18

it's a way that we think

8:20

about maintaining the project that

8:24

some folks can find strict.

8:27

Like we get all kinds of issues

8:29

and poll requests of people asking us to

8:31

make changes. And a

8:34

lot of times we just say

8:36

no, because the change would be

8:38

too disruptive to the eco a system, even

8:41

though for some set of

8:43

developers, it might be beneficial.

8:46

So it's, it's definitely a

8:48

different balancing point . And to

8:51

your point, there are a lot of people

8:53

that come to the project and just think, Hey,

8:55

cool. I wanna add something to ES

8:57

Lin . I think it'll be great. And they

8:59

don't fully think through how

9:02

it will affect all of the existing

9:04

users. And, you know , that's

9:06

where having a strong team

9:09

of maintainers really

9:11

is important to just hold that line

9:14

and protect the end users.

9:16

So how do you create such a

9:18

team? Like I work on open source

9:21

, but , uh , it's part of my job. And so

9:23

I'm in a team and we are, it's all our

9:25

jobs, right? We are all working for

9:27

a company and we get to do open source , but

9:30

then you see some projects that have

9:32

like a single maintainer and

9:35

many people rely on it, but you also

9:37

see projects like esent

9:39

, or VJs comes to mind with

9:42

really strong, close knit communities

9:45

and teams of maintainers that

9:47

seem to really be, to really agree

9:50

on the mission to really agree on

9:52

where they're going. Lal communities

9:54

also comes to mind . How do

9:56

you create that? How do you make that happen?

9:59

Well, I think that it starts with

10:01

having a maintainer who

10:03

has an idea about what they

10:05

want the values to be. And then

10:07

I think it really is just a matter

10:10

of repeating those, you know

10:12

, in the issues in the poll request. So people

10:14

become aware and then it

10:16

, the contributors that you have

10:18

that accept that that's how

10:20

the project works. Those are the people

10:23

that you want to really

10:25

draw in and get them to

10:27

be more active in the community because

10:30

you, as a single maintainer or even

10:32

just two maintainers, it can

10:34

be really hard to just police

10:37

every issue, every poll request that

10:40

comes in, especially if it's a large

10:42

and popular project. So

10:45

you need to start building the community

10:47

around the project by

10:50

rewarding the people who are upholding

10:52

the values that you've set up. And

10:56

that's something that , uh , once

10:58

I decided I didn't want to be a sole maintainer

11:01

anymore. That was something

11:03

that I put a lot of thought

11:06

into was just how

11:08

do I start rewarding the people who

11:10

are behaving the way that I

11:13

want them to behave, and that is

11:15

beneficial to the community. And

11:18

that's when I started experimenting with

11:21

creating a core team, eventually the

11:23

technical steering committee. And

11:26

then as I saw people

11:28

that were contributing meaningfully

11:31

to the project, inviting them

11:33

to join and become

11:36

part of the leadership of the, and

11:39

I think through that, we've been able to

11:42

sustain the values that the

11:44

project believes in by making

11:46

sure that we're looking out for new contributors,

11:49

who are participating in

11:51

a beneficial way and who seem to really

11:53

buy into the structure that

11:56

we've set up to hopefully get them more

11:58

and more engaged and eventually bring

12:00

them onto the team as a regular

12:03

maintainer. I don't see a

12:05

way of really sustaining

12:08

a project as a

12:11

single maintainer for very long , especially

12:14

if a project ends up becoming popular.

12:17

Do you believe that at some

12:19

point you also need to, like, as

12:21

you create a team, do you

12:23

need to give other maintainers a

12:25

little bit of leeway? Like you've been

12:27

working on that thing for so

12:29

long and you have a strong vision and

12:32

maybe you consider it as your baby, but

12:34

does, at some point, do you also need

12:36

to accept that people will invest

12:39

better and more if they

12:41

can bring a little bit of themselves and their ideas?

12:44

Yeah, absolutely. One

12:46

of the things that was really

12:49

hard for me initially, was

12:52

giving up S some of that power

12:54

and not being the sole decision

12:57

maker anymore. But on the other side

12:59

of that, we were able to build

13:02

a really awesome team by

13:05

doing that. And by letting

13:07

people voice their opinions

13:09

on where the project should go and

13:13

what should happen in when

13:15

certain types of submissions

13:18

come in, you know, our semantic

13:20

versioning policy started from

13:24

somebody other than me who was on the team, who

13:26

said, you know, we keep running into these issues.

13:28

Maybe it's time for us to document it well,

13:31

great. That's a great idea. And then we all

13:33

continue to build on afterwards. And

13:37

there were certain decisions that were taken

13:39

on the team that I personally

13:42

didn't agree with, but

13:45

the larger team decided

13:47

that it was the right way to go. And

13:50

so I decided to accept

13:53

that and continue on, on , because

13:56

at , at this point in ES

13:58

Lin's history, there are

14:01

large parts of the code base that I'm not

14:03

familiar with because the project

14:06

has grown so big. And

14:08

at a certain point, I realized that, and

14:10

I had to realize that there

14:12

were team members who are more familiar with certain

14:14

parts of the code than I was, and

14:17

that it would be a good idea to really rely

14:19

on their expertise, to

14:22

decide how that part of the code should

14:24

grow and develop. And

14:27

I think that the project

14:30

and the team as a whole has been better,

14:33

the more that we've been able to incorporate

14:36

other people who have other ideas

14:39

and other strengths than

14:42

I do, because there are some things that

14:45

I don't know that well and somebody else does.

14:48

So right now, we're going through and

14:51

trying to start adding , uh

14:53

, type definitions to the various

14:55

repositories. And I have very

14:58

little experience with that, but

15:00

we have a couple of team members who

15:02

are very experienced with type script . And

15:05

so being able to lean on them and

15:07

let them lead those endeavors

15:10

have , has really made us go a lot farther,

15:12

faster than if I tried

15:14

to stay deeply involved with

15:17

those projects.

15:18

I think you're making an excellent point on

15:21

the fact that, yeah, it's , it's the whole thing

15:23

of you'll go faster if you are alone,

15:25

but you'll go farther. If you're a team. And

15:28

personally, like after looking at

15:30

many open source projects, many projects,

15:32

but also many open source projects, there

15:35

is no recipe for success and

15:37

whatever that means for you, but where

15:40

I've seen the most traction and

15:42

the most happiness is in

15:44

the projects where of course

15:47

you have to have a , like a good idea

15:49

that solves something from the ground up , but

15:52

is the projects where the maintainer

15:54

opened the project to other

15:57

contributors early, because ultimately

15:59

it's the same thing in a company. People don't

16:01

want to just, you know, dust

16:04

up the parts of the projects that

16:06

you don't want to touch. They want

16:08

to have an impact. They want to make something that

16:10

they believe in. They want to get something

16:13

out of it, whatever it is, whether it

16:15

is just, you know, learning something

16:17

new or having something

16:20

to put on the resume, whatever it is, they

16:22

want to have an impact. And I've seen

16:24

project Lin is one , but also

16:27

I'm thinking of , uh , former Algolia

16:30

employee. Uh , no Noma is working

16:32

at laal and he

16:35

is, is a big open

16:38

source contributor in the PHP community. Most

16:41

of his projects, if not all

16:43

, are really successful, partly

16:46

because he opens them to

16:49

external contributors really early. Usually

16:51

when the prototype is out, he

16:53

opens it. And then in

16:56

many cases, even just

16:59

gives them out to other people to, to

17:01

be the core container. And I

17:03

think that's , uh , it can be

17:05

difficult, especially when you care

17:07

about something, when you spend a lot of time

17:09

of thinking, you want to

17:12

keep that prop pretty , but

17:16

you will likely, never

17:18

go as far as

17:21

fast, if you're trying to

17:23

do it all yourself. And

17:25

if you are basically just asking people

17:28

to do what you ask them

17:30

to do, people are not contractors. People

17:32

want to be part of

17:34

something. They wanna be part of a team.

17:37

Yeah. I think that that's one

17:39

of the interesting struggles of

17:42

open source projects is know

17:45

, I, in my mind have some

17:48

places where I'd like ES LT to

17:50

go, but if

17:53

I don't have the time to do it, is that

17:55

something someone else wants to

17:57

do or not? And

18:00

one of the things that we've generally

18:04

stuck with over the years with ES LT

18:06

is it's going

18:09

to be a lot easier to attract

18:12

contributors if we allow

18:14

them to work on, what's interesting

18:17

to them, even if that isn't

18:19

something that's on the official roadmap

18:21

. And it's interesting

18:25

to see where people go when you give

18:27

them that type of free freedom , because

18:30

we can say, you know, these are the

18:33

high level priorities that the

18:36

TSC has set for the next year.

18:38

And these are the things that we would like

18:40

to accomplish if

18:43

anybody would like to help with those great.

18:46

But if other people have other

18:49

ideas and more

18:51

importantly, if they're willing to work on them,

18:53

then a lot of times, especially

18:56

if it's not gonna be a breaking change, we're

18:58

more than willing to let people propose

19:01

that change through the RFC process and

19:04

then go forth and implement them

19:06

on their own and we'll

19:08

help out as they need it. And we've

19:10

had some really interesting

19:13

features come out of that process

19:16

that we wouldn't have otherwise thought

19:18

of or prioritized for

19:20

the TSC to work on, but because

19:23

somebody came along and they had an idea

19:25

and they were willing to work on it, then

19:27

we were willing to consider it.

19:29

And then where it ended up. And

19:33

I think for an open source

19:35

project to be

19:37

sustainable over the course of years

19:40

and not just months, you really

19:42

do need to be open to

19:44

those contributors coming in with their ideas

19:47

that maybe are not something

19:49

that you would think of or

19:52

would prioritize on your own. But

19:54

if you have somebody who is willing to put in the

19:56

work to build it and

19:58

document it, you can get some

20:01

really amazing contributions that

20:03

way.

20:04

Yes. And the show is about developer

20:06

experience. And, and in that case in

20:08

open source , there are many developers that you're

20:10

catering to the developers on

20:12

your team, the maintainers, what is

20:15

the experience that you are giving them? And ultimately,

20:18

it's also about being honest

20:21

with where you want to take

20:23

a project. It's okay for a project to

20:25

stay a pet project, to be something

20:27

that you want to maintain. That's fine. And

20:30

people will want to rely on

20:32

it, but you can be upfront about the

20:34

fact that something is not meant to be

20:37

used in production. That it's

20:39

just a toy project for you to learn. But

20:41

yes, if you want to really take

20:44

something somewhere, you will likely

20:46

not do it on your own. There are very,

20:48

very few projects that really

20:50

took off being maintained by a single

20:53

person. If they are the exception,

20:55

they should probably not be a model. Anyway.

20:57

So speaking of developer experience,

21:00

there's one thing that when

21:02

you shop for a , a

21:04

new dependency, a depend you, something

21:07

that you need, one of the things that you

21:09

are look into is, is this repository

21:12

maintain. That can mean a lot of things that can

21:15

mean. When was the last comment? What

21:17

is the number of open issues? Open

21:20

PRS basically? Is there any activity,

21:23

is there any traction ? And when

21:25

I'm looking at the main ESL in

21:27

repository, I'm not talking about the plugins, of

21:29

course, because they're , most of them are third

21:32

party , but looking at the main repository, it

21:34

has an incredibly low number

21:37

of open issue and poor requests

21:39

relative to the size and the impact of the project.

21:41

This is really impressive. What

21:44

are the bottlenecks that you identified

21:46

over time and what systems

21:49

did you put in place to manage

21:51

the day to day upkeep,

21:53

Keeping the issue and pull requests

21:55

count low is a priority

21:57

for the team, because

22:00

we found early on that

22:04

the more issues in pull requests

22:07

that were the

22:09

harder it was to maintain

22:11

the project needing

22:13

to go back and forth

22:15

between hundreds or I think

22:18

at one point we actually had over

22:20

a thousand open issues was

22:23

really stressful for the team. Uh

22:25

, cuz you know, every issue, every poll request

22:27

you have to, to kind of load back into

22:31

your memory, the entire context

22:34

of what was going on in that issue and

22:38

swapping between all those issues

22:41

was really difficult. And

22:44

it seemed like we were just facing

22:47

and never ending on lot

22:49

of things that needed addressing

22:52

and people, you know,

22:54

leaving comments, Hey, there's been no update

22:56

on this in two weeks, so

22:59

would need to be circling back. Uh

23:01

, and eventually we just decided that, that

23:04

we couldn't possibly

23:06

keep up that way. Uh,

23:08

so we've experimented with

23:11

a bunch of different systems for

23:13

managing that. Uh, at

23:15

one point we added in a stale

23:18

bot , uh , that would just automatically

23:21

close issues that were older than

23:23

I think it was 90 days. Um,

23:26

because we had found looking

23:29

at our issue history

23:32

that once an issue was accepted,

23:35

which means that the team agreed

23:37

that we were going to address it, that

23:40

90% of those

23:42

issues were closed with

23:45

a poll request within 90 days.

23:48

And if an issue was open

23:51

for longer than 90 days, the

23:54

chances that it was ever

23:56

going to be resolved were

23:59

just incredibly small. And,

24:02

and this was all driven from actual data.

24:05

We pulled all of our GitHub issues from the

24:07

beginning of the project and

24:10

crunched all the numbers on it. So with

24:13

the stale bot , we just said, okay, any

24:15

issue that is not resolved within 90

24:18

days is likely to never

24:20

be resolved. So we'll

24:22

just close those. Uh

24:24

, and that was our

24:27

first attempt and that really helped

24:29

a lot. And yes, some people got upset

24:32

that their issues were being closed

24:34

automatically, but fundamentally

24:38

the data on how we were running the project backed

24:41

up that decision and we left as

24:43

nice a message as possible , uh

24:46

, about why we were closing it and invited

24:48

people to open new issues. If

24:50

they really felt strongly that , um,

24:54

the issues should be addressed

24:57

since then we moved

25:00

on and just

25:03

identified some issues

25:06

and poll requests that we

25:09

didn't really need the team to

25:11

triage. And we knew they could just be closed automatically.

25:15

Uh , so we got very strict

25:17

about what type of changes

25:20

we would be making to core rules because

25:23

at this point we have almost 300

25:25

core rules and so

25:28

we can't just continue adding

25:30

more rules. It gets really

25:33

difficult to maintain when

25:35

I first started the project, I

25:37

never envisioned ES L

25:39

having more than about 50 core

25:41

rules. And so at

25:44

some point we realized that we

25:46

just couldn't be , uh

25:48

, as loose with accepting

25:51

new rules into the core. So that

25:53

helped us just start to close

25:56

proposals for new rules, a lot faster. Uh

25:59

, we have a bunch of rules that just enforce

26:03

style preferences and we decided

26:05

we were not gonna add any more options

26:08

to those rules because you

26:10

can keep adding options for style preferences

26:13

until the end of time, there are just too

26:15

many ways that people like to tweak their

26:17

style preferences and we

26:20

can't keep adding new options. So

26:23

that everybody's one-off exception

26:26

is supported with those

26:29

two restrictions. We're able to just very

26:31

quickly start closing

26:33

some of the issues that we're

26:35

proposing, either new

26:37

rules or changes

26:40

to those stylistic rules

26:42

that we are not gonna be implementing.

26:45

So that has helped a lot. And

26:48

then for poll requests, we

26:50

do prioritize reviewing poll requests

26:53

over , uh, reviewing

26:56

issues because if somebody's

26:58

taken the time to submit some code

27:01

or some documentation , um,

27:03

we want to try to get them an answer as quickly as

27:05

possible. And sometimes that answer

27:08

is this. Isn't something

27:10

that we're gonna merge , uh , either because

27:13

of the

27:15

rule restrictions or because

27:18

it's something that needs to first go through the RFC

27:20

process. So we're able to get people

27:23

or response fairly quickly. Uh

27:26

, and then we do still have

27:28

a stale issue and stale pull

27:31

request bot that runs after

27:33

90 days. But in reality,

27:36

we don't end up with a lot

27:38

of automatically closed issues

27:41

and pull requests at this point because

27:43

of, of all of the strict triaging

27:45

that we do upfront

27:47

Does the triage involve

27:49

bugs as well, because you mentioned people

27:52

who want new rules and that your

27:54

vision and that you have a strong vision is

27:56

helping a lot deciding whether this

27:59

is a good idea or not, but

28:02

issues are another topic when you have

28:04

bugs in Lenton . I imagine that

28:07

even after many, many years of solidifying

28:10

the core and adding many, many tests, you

28:12

still have issues and bugs every now.

28:15

And then do you have any

28:17

kind of prioritization when

28:19

it comes to the types of bugs? I

28:21

would say the type of gab issues that

28:24

you tackle first, do you have

28:26

systems to make sure that a

28:28

bug ticket is legit? Do

28:31

you require that issues

28:34

are filed in a certain way? Otherwise you

28:36

close it. Do you have any systems when it comes to

28:38

reproduction of alleged bugs?

28:42

Yes. So we do try to prioritize

28:46

bugs and bug fixes, cuz

28:49

those generally tend to be smaller

28:52

and easier to merge into

28:54

a release without affecting people. We

28:57

do have a GitHub issue

28:59

template for our bugs. So

29:02

we do force people to provide a

29:04

certain amount of, of information.

29:07

We generally try not

29:10

to close issues, even

29:12

if they don't have enough information

29:15

off the bat. Well instead just say,

29:17

Hey, you haven't really given us enough information.

29:20

Can you please go back and fill in all the information

29:23

on the template? And then we can take another look

29:25

and sometimes people

29:28

will go back and fill in the information,

29:31

a surprising percentage of the time. People

29:33

just never follow up after that. And

29:35

then if we haven't heard back in about

29:37

a week, we'll just close that issue and

29:40

consider that it was not reproducible.

29:42

Otherwise we do go through

29:45

the process of making sure that somebody

29:48

can reproduce the issue. We

29:50

do ask for a minimal reproduction

29:53

case , uh , in the issue template. Sometimes

29:55

we get that sometimes we don't, if it's

29:58

easy enough to reproduce, like we

30:00

do have the online demo for

30:03

Slint . That is a really quick and easy way

30:05

to try to reproduce basic

30:08

issues. Any of the issues having to

30:10

do with rules or parsing, you

30:12

can usually reproduce using the

30:14

online demo and that

30:17

way we can quickly reproduce issues. Even

30:19

sometimes if I'm on my phone, I can just

30:22

copy paste that into the demo and

30:25

verify if it's a legitimate bug or

30:27

not. Otherwise we'll

30:29

ask people to set up a

30:32

minimal repo, especially if it

30:34

is a potential issue that

30:36

has to do with plugins because the

30:38

ecosystem is so vast. We do

30:40

get a lot of bug of reports that

30:42

are actually not related to

30:45

esent itself, but are related to

30:48

a plugin or a parser or

30:50

a custom rule. And those can be

30:52

a little bit trickier to

30:55

figure out, especially if they're just using

30:57

a custom parser, because we want

30:59

the core rules to work with as an

31:01

, any custom parsers as possible.

31:04

And we do go out of our way to make

31:06

sure that the core rules will

31:09

work with type script . For

31:11

example , uh , even though Esly

31:14

core doesn't support type script , we've

31:16

found that in a lot of cases, just

31:19

some simple changes to the rules will

31:21

allow type script code to

31:23

work, even though it

31:26

won't be considering

31:28

the type definitions as part of

31:30

the rule itself. So in those cases,

31:33

we might need a minimal

31:36

like repo to be set up so

31:38

we can debug it. Or sometimes we'll

31:40

ping a plugin owner or

31:43

parser maintainer to just comment

31:45

on the issue to let us know if it's something

31:47

that they think might be a core

31:49

issue, or if it has more to

31:51

do with the plugin or the parser

31:54

Earlier, you mentioned that

31:56

at some point, you'll also have to learn

31:58

how to say, just know to contributions

32:01

or issues that don't don't

32:03

match the vision don't match, what

32:06

you're trying to achieve and something

32:08

I've I've noticed when, you know,

32:10

reading conversations around fatigue

32:12

in open sources , that one of

32:15

the things that maintainers get tired

32:17

with is support questions

32:20

in issues. You know, you will have people who encounter

32:23

an issue and that's actually

32:25

documented. That's a behavior that is documented.

32:28

There is also sometimes

32:30

rudeness in issues when people are

32:32

really passionate and you can see that

32:34

on very heart repositories.

32:37

If you look at the react repository,

32:40

you have some flame wars over there and

32:43

I'm curious, what's your take

32:45

on that? Is that something that we

32:48

have to not accept the rudeness,

32:50

but accept that it'll

32:52

happen? And when it systems, is

32:55

it something that you're still trying to figure

32:57

out? How do you handle all that kind of stress?

33:01

I think to a certain extent, you need

33:03

to expect some

33:06

level of rudeness.

33:09

You need to expect some

33:11

level of laziness

33:14

as well. When it comes to people,

33:16

opening issues where they could

33:19

have just searched the dock implementation and found the answer

33:21

there as well. Um,

33:24

it it's something I think that

33:26

is always going to be

33:30

a part of open source

33:32

, especially on GitHub, where

33:34

they make it basically zero cost

33:37

to open an issue , uh

33:39

, which is something that I

33:41

have struggled with over the years

33:43

on GitHub. I think that the

33:46

zero cost issue opening is

33:50

a problem to where the

33:52

person opening the issue. It costs them

33:55

very little to do so, but

33:57

the person triaging the issue that

34:00

costs , there's usually a

34:03

fixed cost for every issue

34:05

that is higher than the cost of opening the

34:07

issue. And that imbalance

34:10

is part of maintainer

34:13

burnout , at least in my opinion, and

34:16

until GitHub helps us by

34:19

raising the cost of opening in

34:21

a issue a little bit, which issue

34:23

templates help, but are

34:25

still not quite

34:27

there. It's going to be up

34:29

to maintainers to help maintain

34:32

their own sanity. And I

34:34

have a zero tolerance policy

34:37

for bad behavior on issues.

34:39

If I'm trying to engage with you on

34:42

an issue. And every response

34:44

to me is rude,

34:47

sarcastic, disrespectful.

34:50

I have no problem. Just closing the issue

34:52

and saying, I'm sorry, I'm not gonna

34:54

be able to continue on with this

34:56

issue in this way. I have already

34:59

tried my best to be

35:01

respectful and lying. You

35:03

are not responding the same way.

35:06

So I'm going to move on to other

35:08

things now and just leave it at that. Maintainers

35:11

are not under any obligation to

35:14

continue a conversation that

35:16

is negatively affecting

35:18

their mental health that is draining

35:20

them. Uh , you're not being paid to

35:22

deal with that. There's no

35:25

reason to put up with it and

35:27

I'm very quick to close

35:30

issues. If I see the discussion isn't

35:32

going anywhere and I do

35:34

that without any regret. Uh , and

35:36

generally what I'll do is say

35:38

something along the lines of thanks

35:40

for the discussion at this point. I don't

35:42

think we're going to be moving forward with this. So

35:45

I'm closing the issue and then I close

35:47

it. And I unsubscribe from all

35:49

notifications that are on that issue. And

35:52

I'm done if people want to go back and complain

35:54

that the issue is closed, that, but

35:57

that's not something I'm going to engage

35:59

with going forward. I

36:01

would much rather spend my time on the issues

36:03

and pull requests where people are being

36:05

respectful and considerate and

36:08

are making meaningful contributions

36:11

to the project as a whole. And

36:13

that way I'm able to keep myself

36:16

refreshed, interested, and

36:18

just cut off any of the more

36:21

toxic interactions that I'm

36:23

having.

36:24

Yeah. I think this is really full

36:26

of extremely good advice, especially

36:29

for maybe younger folks who

36:31

are starting out their open

36:34

source journey and trying to gain

36:36

knowledge and experience through open

36:39

source . There are so many great things

36:41

that you can learn from open source

36:43

because the barrier to entry is

36:45

very low. You can get started right

36:47

away. You can open up a request right

36:50

away. There are many, many things to learn,

36:52

but maybe one of the biggest is

36:54

that you are entitled

36:57

to own sanity. You are entitled

37:00

to being respected. And even

37:02

when you get paid for it, like you're

37:04

a support engineer support agent, you

37:06

are not supposed to get abuse from

37:09

clients . There is no reason

37:12

on earth, why you would have to

37:14

accept it. And then of course it depends

37:16

on the communities and it depends on the

37:18

kind of atmosphere that is

37:21

created, but in

37:23

no way, this is justifiable

37:26

that people will talk to you badly. Even

37:29

if you broke their build , like you

37:31

can understand sometimes that people get

37:33

frustrated, but there is

37:35

a limit to the kind of

37:38

behavior that you can intake . And yeah,

37:40

no matter whether you broke something at

37:43

the end of the day, it is only software.

37:46

We are not putting anybody's

37:48

lives in danger. Yeah. I feel that it's

37:50

extremely important for folks to understand

37:52

is that this kind of behavior can

37:55

only continue if we let it

37:57

happen. And it's not enough that

38:00

we say no to it, but

38:02

it'll only fester if we let it

38:04

happen.

38:05

Yeah. There's still a lot of bad

38:07

behavior out there. But I

38:09

think that part of keeping your

38:12

sanity is just limiting

38:14

how frequently you engage

38:16

with it. I have a bunch

38:18

of canned reply I saved

38:21

in GitHub. So for any

38:23

type of issue that is

38:25

stressing me out, I have

38:28

a way out that I thought about

38:31

when I was calmer and not

38:33

stressed out that I can just put

38:35

in, like, you know , if somebody has

38:38

opened an issue for something that is documented,

38:42

then I have an auto reply to

38:44

say, Hey, thanks, sorry , you're

38:47

having a problem. Here's where you can find the answer

38:49

and just paste in the link and then close the

38:51

issue. Like I , I think the

38:53

other thing leads to burnout for

38:56

open source maintainers is

38:59

not every issue or

39:01

pull request, deserves

39:05

weeks of conversation. And

39:08

that's something that burned

39:10

me out very early on where I thought

39:12

like, wow, you know, anytime and

39:15

brings me an idea. I

39:17

need to fully vet it. I need to ask questions

39:20

to make sure that I understand where

39:22

they're coming from. I , I need

39:24

to respond to all

39:26

of the criticisms that they have

39:29

about my response to it. And

39:33

now my approach is every

39:36

issue deserves that level

39:38

of scrutiny. Not every poll request

39:40

deserves that level of scrutiny. It's

39:43

completely fine that if an issue

39:45

comes in and you know that

39:48

you are not gonna take any action related

39:50

to it that day, that you just

39:53

close the issue and say , uh , I'm sorry, we're

39:55

not gonna be moving for , with this. Thanks

39:57

for the idea. And then just be done with

39:59

it. And yes, people will come back and

40:02

complain and feel like that their issue

40:05

hadn't gotten their day in court,

40:08

but their issue didn't deserve

40:10

a day in court. So you don't have to give it. And,

40:13

and that , that's why I'm very

40:15

strict with myself. If

40:17

I close an issue that I

40:19

have no intention of following

40:22

up on again, then I also unsubscribe

40:24

from the notifications because the

40:27

extra amount of time it's going to take

40:29

me to read through somebody's

40:32

complaint about my having

40:35

closed . The issue is not

40:37

worth the time or the stress that it's

40:39

gonna cause me. I have other

40:41

things that are more important to the project to

40:44

work on, and I need

40:46

to give myself permission and all

40:48

maintainers need to give themselves permission

40:50

to just move on from an issue. And

40:53

don't engage with any

40:55

of the complaints that come in after it

40:57

closed.

40:59

It makes a lot of sense, especially after

41:01

you mentioned like the amount

41:04

of quality that you expect and

41:06

, uh , like the fact that one

41:09

of your biggest values is that

41:11

you do not want to add something

41:14

lightly. If it may

41:16

cause breakage that you have a steer in

41:18

committee, like all those things contribute

41:21

to quality. They are not easy

41:24

things to put in place. They take time, they

41:26

take resource. And it

41:29

is, I believe that , uh

41:31

, people in open source , especially

41:34

when they put such care in

41:36

their work are also entitled

41:39

to expect a certain level

41:41

of care coming from the people who

41:44

are users, because ultimately we

41:46

have that messaging that comes from the corporate

41:48

world where you need to be customer obsessed

41:51

and customer centric on all that

41:53

open source . And of course it may

41:55

be a bit different if you use open source in

41:57

the frame of a company, but open source , you

42:00

have users, they're not customers, and

42:02

you can apply really high quality

42:05

standards. You can see that with , uh

42:07

, Linux, for example, huge,

42:10

extremely strict quality standards and

42:13

Lin external. But at the

42:15

same time, the people using your

42:17

software are not paying you for it. You

42:19

are doing that on your own time, and that's not

42:21

here to justify that. Oh yeah, we

42:24

don't care about people. Complaints. It's

42:26

just that the relationship is not

42:28

the same. There is no contract

42:31

kind of a moral contract, but there is no contract

42:33

that you do this because

42:35

I pay you. Uh , and so it's

42:38

also a learning experience for the user

42:40

when you are using open source . And

42:43

maybe that's also where a lot of

42:45

the misconceptions come from you

42:47

are participating in open source . It's

42:49

not just a shop of free software. You're

42:52

using community may maintain

42:54

software. It's very different from free.

42:57

Just grab it, like you become

42:59

a part of it. And so there also

43:02

are expectations on people who

43:04

consume, especially when

43:07

a project has really high quality standards.

43:10

Yeah, absolutely. I mean, it , it

43:12

really is a two

43:14

two-way relationship, more

43:16

than anything else. It's , uh , as

43:19

a user, when you go to

43:21

the GitHub repo, you

43:23

are entering into a

43:26

relationship with the project

43:28

that is two-way, you use

43:30

the project, but also you

43:33

can contribute and, you

43:35

know , contributions, aren't just code. Every

43:38

time you open an issue, you

43:40

are contributing every time you open a discussion

43:42

or a poll request, you are contributing.

43:45

And anytime you participate in

43:47

the project's chat room or

43:49

discord server, you are contributing.

43:52

And that's why it's

43:55

important to establish

43:57

a code of conduct upfront early

44:00

on in the project's lifecycle

44:03

so that you can set the expectations for

44:06

what the behavior of the community is.

44:09

I mean , for every issue that is

44:12

opened on ES LT

44:14

, we say right at the top, in the

44:16

template that by opening this issue, you

44:19

agree to adhere to the code of conduct.

44:22

Like that is part of the agreement

44:24

that you make when you make

44:26

a contribution to the project. And

44:29

the earlier that you get that laid

44:32

out, I think the better off your

44:34

project is going to be. And

44:38

part of that is not just what

44:41

we consider enforcing a code of

44:43

conduct, which is if somebody does

44:45

something bad, you let

44:47

them know that they're in violation

44:50

and either warn

44:52

them or punish them in some way. Now

44:55

that's one side of it. But the other side is

44:58

you really need to reward the people who are

45:00

behaving in the way that you

45:02

want the community to behave. And

45:05

whether that is by inviting

45:07

them to join the team, you know, on

45:09

Slint we actually have three different levels of

45:12

team members. So committers reviewers

45:15

and the technical steering committee, and

45:18

as people contribute more, they can

45:20

progress up that ladder until

45:23

they become a part of the steering committee. But

45:25

also what we've started doing

45:28

is paying contributors

45:30

when they make of contributions.

45:33

And we particularly

45:36

are looking at not

45:38

just code contributions,

45:41

but how people behave on the issues,

45:44

how people behave in discord. If

45:46

people are submitting documentation,

45:49

if people are just generally helping

45:52

out in the ecosystem, once

45:54

a month, we as a team get together and

45:57

we award people some amount

45:59

of money for any contribution

46:02

that was beneficial to the project. And

46:06

in that way, we

46:08

have been able to really

46:10

encourage the type of

46:12

contributions that we want, because

46:14

even though the dollar amount

46:17

isn't a lot, so it starts at

46:20

a hundred dollars. I think we've done

46:22

as much as 500 for some really outstanding

46:25

contributions. People realize

46:28

that their contribution is

46:30

being valued by the project, and

46:34

they're then willing to contribute

46:36

more in the same way.

46:39

So speaking of money, that's an excellent

46:41

segue to my next question lately, there

46:44

has been several attempts at monetizing

46:47

open source . We've seen many different

46:49

ways like donations, some of the

46:51

ways I've been criticized by the way, but the

46:53

nations sponsorships, things like that

46:56

more recently, VC funding has

46:58

started for opensource projects. There

47:01

are several projects now that are backed

47:03

up by VC funds. I wonder, do

47:05

you think opensource needs

47:07

to solve this problem of monetization?

47:10

Should opensource have a

47:13

business model to, to begin with?

47:14

I do think that opensource needs

47:17

to solve this problem because the

47:19

more projects that we have that businesses

47:22

are dependent on the

47:24

more risks that we

47:27

have, as well as we

47:29

saw with heart bleed

47:31

and log four J uh

47:34

, all of these projects

47:37

that people are using and might not even know

47:39

that they're using, these

47:42

are actually significant

47:45

security risks for companies. And

47:48

in the past, we used to talk

47:50

about like, well, the risk is

47:53

if the maintainers stops maintaining

47:55

the project and your company

47:57

is reliant on it, then you can't get bug

48:00

fixes, which is an annoyance,

48:02

but not the end of the world. Now

48:04

we're at the point where the problem, if

48:07

a project goes unmaintained security

48:10

risks to your company, to

48:12

your company's customers. And

48:15

that is where I think the only real

48:17

solution is to figure out how

48:20

to fund these projects at such

48:22

a level that you can minimize

48:25

that risk going forward, because

48:28

open source soft , where is

48:31

the way that so many startups

48:34

get started, there's no way that they

48:36

could get started if they

48:38

needed to pay for the

48:40

equivalent of the commercial versions

48:43

of all of the projects that they're being built

48:46

upon, it would just cost too much money. And

48:48

I think that there is a

48:51

responsibility then when

48:54

those startups get

48:56

their funding to start contributing

48:59

some of that money back to

49:01

the projects that they are reliant

49:03

upon in order to grow

49:05

their business. Because if

49:08

you're able to get that companies

49:11

started specifically built on the

49:13

back of free and open source software,

49:16

if you are then able to turn a profit, then

49:18

I think that it's time to start funneling

49:20

some of that money back to opensource

49:23

projects. And there

49:25

are a lot of companies in the past few

49:27

years that are starting to

49:29

do that, which is, but

49:32

I think we need to move past the point

49:34

where it's companies practicing

49:37

altruism to fund open source

49:39

projects, to having it be

49:42

a fundamental part of

49:44

their business model, that a

49:47

certain amount of the money that we take in needs

49:49

to go back to open

49:52

source projects so that our

49:54

business can give back

49:57

to the projects that were built upon and

50:00

ensure that we can continue using

50:03

them going forward by

50:05

paying the maintainers to

50:08

continue maintaining those projects. And

50:11

I do think it's so some point we

50:14

are going to need some

50:16

kind of government intervention to

50:18

do that probably in

50:20

the realm of tax credits of

50:23

some sort, to really encourage

50:25

companies to do that. Because if

50:28

we have to continue relying on the

50:30

kindness of companies, I

50:33

don't think we're gonna make any progress going

50:35

forward.

50:36

That's , uh , that's an excellent point.

50:39

I definitely am grateful

50:41

for the fact that more and more companies

50:44

are trying to give back whether

50:47

it's altruism or , uh , you

50:49

know, PR to me is besides

50:51

the point, as long as it gets done, but

50:53

it's not a system. If it's not something that

50:56

people can rely on, it is not

50:58

a system. And the fact that you

51:00

mentioned some kind of government intervention

51:02

in the form of tax credit, for example, is

51:04

really interesting because is

51:07

no denial that

51:10

technology is now everywhere.

51:13

It might not have been the case 20 years

51:15

ago and could have been easily, you

51:17

know, overlooked. But today, even

51:20

like, when I look at my city's

51:23

website, because I need to register to

51:25

both , or what of something like that, they

51:27

have a website that is built on open

51:30

source . Of course they are, and everybody

51:32

is. And so we can no

51:34

longer ignore the fact

51:37

that our entire lives and

51:39

human experience is being digitized.

51:41

And that it happens on

51:44

the labor of people who just take

51:47

the time to do that on their free time. They're

51:49

not being compensated and this is not

51:51

sustainable. Um, so I

51:53

think this is, this is really interesting. I

51:56

, I want I'm wondering, because

51:58

this is not something that exists

52:00

yet. Are there things that you've tried

52:03

to sustain ENT that

52:05

either have failed and you can

52:07

re as not really

52:10

good ways and are they things that

52:12

succeeded?

52:13

Yeah. So we've definitely done

52:15

a lot of experimenting in

52:18

this realm. Uh , the

52:20

first thing was approaching

52:23

companies to sponsor

52:25

the project directly, which

52:29

was difficult. There

52:32

were three companies

52:34

that reached out initially

52:39

saying that if we

52:41

were to start collecting sponsorships,

52:43

that they would donate , uh

52:45

, which was part of the reason we started accepting

52:48

sponsorships was because we

52:50

knew that we had at least three companies willing

52:52

to sponsor the project. Then

52:56

we went through contacting

52:59

companies individually, which

53:03

is time consuming. It's difficult. A

53:06

lot of companies are

53:08

not set up to sponsor

53:11

O open source projects, which

53:13

means that you need to

53:16

deal with their budgeting

53:18

process, which sometimes

53:21

can take an entire year to get

53:23

through just to get money allocated

53:25

for this purpose. You know, I , I spent a

53:27

lot of time early on going

53:29

through my network, asking

53:32

them to find

53:34

who the right person at their companies would be

53:36

to talk to about sponsoring

53:39

esent and then sometimes working

53:42

with them on how to make

53:44

budget for proposals to do that. And

53:47

I wrote a whole post about

53:49

that on my blog about

53:51

everything that I had learned about how

53:53

to talk to your employer,

53:57

to help them figure out how

54:00

to start donating to open source projects.

54:02

Uh , and so the amount

54:05

of time that took , uh

54:08

, was definitely

54:11

out of proportion with

54:13

the number of sponsorships we got at

54:15

the end. I'm still glad that I did it.

54:18

Uh , there was a lot of learnings there , um

54:21

, that hopefully will make that process easier

54:23

for other people in the future. So

54:26

I , I would say that that was a mild

54:28

success. Another thing

54:31

that we did was we put ads

54:34

on our website and that

54:37

I would say has been a success. We

54:40

use carbon ads . So they're one of the ethical ad

54:42

companies that are out there. Uh

54:45

, and that has been

54:47

a moderate success. We're bringing

54:49

in about a thousand dollars a

54:51

month through that ad

54:54

placement, which is fantastic.

54:57

A lot of people go to our website to

55:01

read documentation. So

55:04

that's just an easy way to monetize

55:07

that traffic. Uh , we purposely

55:09

kept it to just one ad because we

55:11

didn't want to go

55:13

the route of filling up every page with

55:15

ads. That wasn't the type of experience

55:18

we wanted for our users.

55:21

We tried doing t-shirts

55:23

and stickers, and that was a

55:26

failure. We , none of us are

55:28

marketers. So even

55:31

though it seemed like a cool idea that

55:34

never really brought in too many

55:36

sales, even though we would periodically

55:39

tweet about it or have somebody share it

55:41

that really, I think in

55:43

total, over the several years

55:45

that we've had that shop up, I

55:48

think has brought in less than a hundred dollars. So

55:51

kind of cool to have, especially

55:54

if people are going to conferences

55:57

, um , but definitely not

56:00

a big source of revenue for

56:02

the project. And really the,

56:05

the times where we have received

56:09

the most in donations

56:12

have been after we

56:15

have talked about a

56:18

problem that we were having

56:20

with funding. So after

56:23

we wrote about our experiment

56:25

with having a part-time

56:28

20 hours a week maintainer and

56:30

how that didn't work, because

56:32

we didn't have enough money

56:35

to really fund

56:37

somebody at that level, nor did we have enough

56:39

money to hire somebody full-time

56:42

we , we ended up getting a bunch of donations after

56:44

that, and that seems

56:47

to coincide with other open source projects.

56:50

I know when babble blog that

56:53

they were running out of money, they got

56:55

a big influx of donations as well.

56:58

Uh, obviously it's not

57:01

really a sustainable model. You

57:03

need to complain about not having

57:05

enough money in order to get

57:08

donations, but that's been our

57:10

experience so far.

57:12

So esent is the

57:15

defacto JavaScript center right now. It has

57:17

been that for a while. Uh

57:20

, but it's not the first and it's not the

57:22

only one. And I would love

57:24

to understand what you learned from

57:27

previous art, such as like JS hint

57:29

, for example, which I used a few

57:31

years back and what you are learning from

57:33

newer kids on the block, like Rome, for

57:36

example, which is trying to, to disrupt many

57:38

different things in the JavaScript ecosystem,

57:41

is it influencing the future of EES

57:43

L are we going to see

57:45

things that come from learning

57:48

from the past and being pushed by what's

57:51

coming?

57:55

Absolutely. Uh , there's definitely

57:59

a long history that ES

58:01

lent is built upon. So I

58:05

way, way about in the day when

58:07

I was at Yahoo, I had created

58:10

a custom version of JS lint

58:13

for use on the homepage team

58:16

in order for us to enforce our

58:18

own standards. And

58:20

JS lint of course, was not pluggable

58:23

or extendable in any way . So you actually

58:26

had to go, go right into the core and add it

58:28

right there. Uh , and then

58:30

I did contribute to JS hint as

58:32

well. Uh , and

58:36

a lot of the

58:38

pain points I had from

58:40

JS lint and JS hint, I

58:43

addressed in lint

58:46

the most obvious S one being the

58:48

ability to have plugins custom

58:51

rules, custom parsers, and

58:53

stuff like that. Because for

58:56

a little while, JS hint

58:58

got stuck implementing

59:01

S six. And

59:04

when ES lint got

59:08

waiting for APRI a to

59:11

implement E six, we

59:14

were actually able to switch to a different parser

59:16

and just continue going. And so

59:19

making esent pluggable, I

59:22

think was one of the first decisions

59:25

I made based off of my

59:27

experience with JS LT and JS

59:29

hint to allow ES

59:32

LT to move faster. And

59:35

the more pluggable it was, the more we

59:38

were able to adapt as

59:40

different things popped up. So when

59:44

react came out with JSX , uh

59:47

, we were able to use

59:50

Facebook's custom par to allow ES

59:52

lint Tolin react

59:55

code, which gained

59:58

ES lint . A lot of followers in the react

1:00:01

act community because they couldn't

1:00:03

use J ENT . And now going

1:00:05

forward a Rome and

1:00:09

Dino lint just came out. There's

1:00:11

also RS lint , which is

1:00:14

a Java script litter written in

1:00:16

rust. Uh , these

1:00:18

are all things that we

1:00:20

are looking at to

1:00:22

see what ideas might make sense for

1:00:26

esent . Uh , right now we're actually

1:00:28

in the process of looking to see

1:00:30

if it will be possible to

1:00:33

use the parser

1:00:36

used in Dino ENT in

1:00:39

esent just by plugging it in , uh,

1:00:42

that that's actually just popped up within the last week,

1:00:44

because those rust

1:00:47

based parsers are obviously a lot faster than

1:00:49

the JavaScript based parsers. And

1:00:52

if you're going to, belying a large code

1:00:54

base that could potentially

1:00:57

give you some dramatic speed improvements

1:01:01

overall, though, I I've

1:01:03

always been of the mind that ES

1:01:06

lint will not be the dominant JavaScript

1:01:09

linter forever. And

1:01:12

none of us on the team have

1:01:15

any false delusions

1:01:18

about that. Like at some point something

1:01:20

is gonna come along. That's better, faster, and

1:01:23

everybody will move on to that. Uh

1:01:26

, and our goal is really just to

1:01:28

continue improving ES LT

1:01:30

in ways that make sense for the community. We

1:01:34

are not in a competition

1:01:37

with Rome or Dina , lint , or

1:01:39

RS LT or anything

1:01:42

like that. I , I do don't believe that

1:01:45

that's the right mindset to have in

1:01:47

the open source community. I

1:01:49

think it's much healthier to think about

1:01:52

making the best product you

1:01:54

can build for the

1:01:57

community that you have. And

1:01:59

yes, if there are things that you can learn from

1:02:01

other projects that make sense for

1:02:03

your project, then yeah, let's

1:02:06

pursue that. And let's see if we can make that work.

1:02:09

But if we reach a point where other

1:02:12

projects are just objectively

1:02:15

better at solving the problems

1:02:17

that ES lint is

1:02:21

trying to solve, we

1:02:23

may reach a point where we say, you know, it's

1:02:25

not worth continuing the project.

1:02:28

We should be encouraging people to use

1:02:30

this other project. I don't know how far

1:02:33

in the future that will end up being, but

1:02:36

I know at some point it will happen and

1:02:40

I started ENT to solve a

1:02:42

particular set of problems. And

1:02:44

if at some point in the future, some other tool

1:02:47

is better at solving those problems. Then

1:02:51

the whole team will be more than happy

1:02:53

to let people know that and

1:02:57

help with people's transit in onto

1:03:00

whatever that better tool might end up being.

1:03:02

That's a great mindset and an excellent

1:03:04

way to wrap this up. Nicholas,

1:03:07

where can people go to find you online?

1:03:10

So you can find me at my website,

1:03:12

which is human, who codes.com.

1:03:15

You can also find me on

1:03:17

Twitter. I am at slick

1:03:20

net , which is S L I C

1:03:22

K N E T . I also do

1:03:24

have a human who codes

1:03:27

Twitter handle, but that's mostly just

1:03:30

an automated feed, but you

1:03:32

can get to me through there as well.

1:03:34

All right . And you can find me on

1:03:36

Twitter, on front stuff, underscore

1:03:39

IO, and , and you can find my

1:03:42

[email protected] . If you are interested in, Esly

1:03:45

check it out online, the search

1:03:47

is actually powered by Algolia. And

1:03:49

if you're interested in Algolia , you can

1:03:51

find [email protected]. We

1:03:54

are also at Algoa on Twitter, Nicholas,

1:03:57

thank you so much for chatting with me

1:03:59

today. Thank you for your time. I

1:04:01

learned a lot of things. It was really

1:04:04

interesting listeners. I hope

1:04:06

you enjoyed this. I hope you learn

1:04:08

new things as well. Thanks a lot for following

1:04:11

developer experience and stay

1:04:13

tuned for the next episode. This

1:04:17

was developer experience, a podcast

1:04:19

brought to you by Algolia. You

1:04:22

can find this podcast on your favorite podcast

1:04:25

platform. We are on Spotify, apple

1:04:27

podcasts, Google podcast, Pandora,

1:04:30

overcast, everywhere. If

1:04:33

you want to know more about Algolia check

1:04:35

us out on algolia.com and

1:04:37

we are at Algolia on Twitter.