Visualizing Open Source Data in React with Brian Douglas
===

[00:00:00] Hello and welcome to pod rocket, a web development podcast brought to you by log rocket helps software teams improve user experience with session replay, error tracking, and product analytics. You can try it free at log rocket. com. 

I'm Noel and today we're welcoming back Brian Douglas. Brian's an educator consultant and he focuses on modern UI development. He's here to talk about visualizing open source data in react. Welcome to the show, Brian. How's it going?

I'm doing well. ~Yeah.~

~Good. Good. Can you tell us a little bit about just to get rolling, your journey? You used to be a GitHub kind of, how has this contributed? ~Can you tell us a little bit about your journey just to kick us off you used to be at GitHub. Can you tell us how that contributed to this topic? And what we're talking about exactly when we're talking about open source data.

Yeah. I started even before that. I used to be at Netlify. So I was employee number three back in 2015, ~20 ~to 2018. And Was working on in react. It was like my first full time react job and built the netlify dashboards. If anybody's deployed a site on netlify that dashboard, I helped build the original version of that and only reactive got very excited about that.

I also got really excited about [00:01:00] open source at that time and started contributing a ton to open source. So I built this little side project called open sauce where I could like Managed by open source contributions in one place. You think you can do that GitHub, but when you have multiple PRs and multiple repos and multiple organizations, it's hard to.

centralize that. So that actually led to me getting a job at GitHub. I built something using a GitHub GraphQL API and built that in react early days as well. And at GitHub, my role was dev rel, and I got to engage with open source maintainers and to be able to see data across organizations and repos.

That was like the thing I wanted to solve for. So because I knew react and had did front end UIs for a while, I didn't really do a lot like D3 or charts or anything like that. previously. I think actually my time at Netlify, we didn't have a lot of metrics or analytics,

Oh, yeah. Yeah.

the platform. So I didn't even build that when I was there.

So everyone who's joined Netlify since built all that stuff. But I had a pain point where I had to like, visualize pull [00:02:00] requests across multiple people in one place and reach for a tool called Nevo. And part of the reason why pod rocket reached out to me was I did a talk at react Miami on this.

So that's like the long meandering way of like how all that includes in why I'm here.

No. That's good. I'm curious on, on several points there. Kind of everything from like data visualization to how your time at GitHub influenced that. ~Is there any ~was there a specific challenge that you set out to face that kicked off this whole journey when you started on open source?

Like what was the real pain point you felt with what was available just like on, GitHub, for example?

Yeah. I come from a time where everyone used D3, like directly, a lot of data visualization on the web was like Python driven. A lot of it's ~like a lot of folks ~like Python is really good for data. So crunching a bunch of data. So then a lot of stuff got built in Python. But then obviously JavaScript got really big in the last ~1015 ~years, and then react in the last 10 years.

So yeah, There wasn't a lot of like cool visualization libraries. A [00:03:00] lot of it was hand built. You have to, and ~I'm, ~I like doing open source. I'm not a great open source maintainer. So I wasn't really interested in building my own thing. When searching, like there's ~a, there's like ~a tool called recharts, which is like a react.

Apache E charts, so Apache being like a older technology building. ~Apache basically, ~Apache Foundation has a thing called E charts and a lot of the visualizations built in this one tool. But I think it's actually powered by Java, to be honest. And it was, it felt clunky and slow. And like you got to, Manipulate the data in a way that matches that.

So did that for a little bit and like the earliest version of open source that we built a couple of years ago. And then we stumbled into Nevo, Nevo being a chart library that gives you a lot more ~custom, like customers, ~customizability, it gives you a lot of more bells and whistles to customize charts.

And the thing is we already had the data. And we had already built an API for this. So didn't want to spend more time trying to rebuild the API to match the chart library. So instead. Using a tool like Nevo, Nevo is like really the one tool that I [00:04:00] can speak to because I had the most experience with in the last couple years.

But I don't have to worry about how my data is set up. I could send it an array of data or a JSON of data and I'm good to go. And I could start manipulating the library really to react props, which is. My bread and butter.

~Nice. Nice. So it's, so is that kind of ~the main focus of the talk then is like how we're getting data into the react app and then handing that off to Nevo or, some viz library.

Yeah. Honestly, I had one slide for Nemo in the talk and I've given this talk again at Figma's conference. So config happening. I don't know when this goes out, but like at the end of June the summer is when config is happening. And I will probably dig in way more about the actual design and visualization at the Figma conference.

But I actually talked more about the pain point in like the hard part of like sourcing this data and getting insights from it. Cause at the end of the day, it's like you go, so the open source product it's basically the GitHub insights tab, but better. So every repository has this tab called insights and you can see like PRS and you see [00:05:00] some bar charts and it's ~pretty much that's ~pretty much it.

Like you get some traffic data as well of like folks looking at your repo, what pages and stuff like that. But my challenge when I was doing all these contributions, I needed to know, who do I talk to? When I didn't make a contribution are who's doing most of the contributions. So like the thing that we just, we're shipping this week actually there's a PR open for this feature and it'll be live later today.

It's called lottery factor. I was talking to Ryan Florence at~ at ~currently Shopify runs, remix and react router. And he's like, yeah, it's one of the like, tell a story next week. I~ I ~react, ~coughed ~about who's contributing the react router. Cause they're going to have a huge push for the next version of React Router 6.

So like, how do we tell a story? Like Mark has been working on React Router because he's been working on some remix stuff in the community, all open source. Like, how can I tell that story and that journey? And so we have this feature, this metric called watery factor, and we built this React component that shows top five contributors.

Distribution of who's done there's like a bar graph or [00:06:00] a line graph. It's hard on a podcast to not

Yeah. , we're not a visual medium. Yeah.

yeah, but basically you could see the distribution of the top five contributors and you have everyone else but then the lottery factor is if more than two people do 50 percent of more of the code, then the lottery factor is high.

And the lottery factor is, if I explain it if one of the maintainers, When's the lottery? Chances are they're not going to be maintaining that project ~like ~any longer or like their time is going to be winding down because they won the lottery. And there's another term called bus factor. So we use that.

It's the hit by a bus factor and a friendlier.

yeah, we use a lottery factor because we actually have an employee who did work with somebody who did pass away

Yeah.

took over. So it's a little morbid to talk about

Totally. ~Yep. ~I like lottery factor more as well. ~Yep.~

yeah, and but that's like a visualization of really quickly, I can know, okay, wow, okay, most of the work is being done by these two people or yeah.

Actually distribution, it's like Flutter being one project. Everyone was concerned because some of the Flutter team got laid off at Google. [00:07:00] But when you look at the actual lottery factor visualizing it inside of one chart, it's oh, actually, everyone kind of has pretty even distribution. If so and so gets laid off, like there's still other people who can pick up the knowledge, the torch and carry it over the finish line to get releases out for Flutter.

And that was just a simple experiment experience that ~we, ~we learned from. I also do a podcast. I talked to a lot of open source maintainers about what are cool things that you would look like you want to see? And I was talking to, brendan Burns from Kubernetes fame. He was co creator over there at Google.

And his statement was like, I just want to walk into a repo and it's no, if it's a good or a bad neighborhood. So like, how do I know if it's actively maintained? How do I know if there's like a figurehead or this is distributed work across multiple teams 

those are things that we want to also visualize, like representation of like company impact and sponsorship within projects.

So then you can make like a good decision to like, Oh, I want to do this open source thing. I want to contribute to open source based on like my needs and [00:08:00] what I'm working on. Cause a lot of times stuff downstream or upstream rather, and you don't know if like you're depending on something that it's like house of cards.

And that's, ~there's a ~type of visualizations we were trying to show, which I can go to other charts that I built as well. I centralized around this lottery factory cause I'm super excited about it. Cause it's like coming out today.

~Yeah. ~Yeah. No that's a cool. That's a good example. Yeah. So my question was going to be like, what are the unique challenges with open source data in particular? But I think that you've given us a few there, like it is an interesting space. I don't there's people thinking about this, but this kind of like tools for people that are working in open source as these like meta level tools is maybe not a thing we're thinking about a lot.

~Is there ~is there anything in particular that kind of drew you to this problem? Or was it just organically happened as you were like, this is a pain. Yeah.

so I mentioned in passing 10 years of react like that's a huge milestone Like we I came from a space where there were way too many front end libraries and we've centralized as industry around react today Obviously angular and view and ~I was just ~I was [00:09:00] it's like weird flex. I'm based out here in San Francisco I was hanging out with Evan you last night from

Nice.

and He was talking about like the Vite library.

So Vite is like the build tool that all these meta frameworks are built on top of. So Remix and Redwood and pretty much everything except Next. js is built on top of Vite. So when you start looking at that, like that impact, like how do you visualize, if Vite was removed from the situation, or if there's another thing that would replace Vite, like how do you see that visually in contributions?

And so we had this other chart I called contribution distribution, ~and that's actually the, ~so in the talk that I gave, and I'll be again at Figma's conference. The first chart I built was contribution distribution, which is basically a 30 day scatterplot. And I always joke because I got a C in statistics in college.

So I'm not a statistician at all. And like charts and math and stuff like that, like I can do it, but I'm more interested now because I have a pain point I'm trying to solve. So like how do you visualize if there's active movement in a project? And so we have a [00:10:00] scatterplot that. To the right is the most recent PRs in a project.

And then to the left is like oldest PRs. So when you start seeing like way more PRs on the right, you see it's a healthy, active, contributing society project. When you see a bunch of distribution, they're like projects on the left that are just sitting there and maybe getting stale, then you can make a decision like, okay, there's a bottleneck here.

Like whether it's like the maintainers, they have a long review cycle, or maybe it's just everything's this long cycle. Long review cycle or this thing like shipping crazy. So there's a couple of projects like next JS where they'll have a bunch of PR. So like ship daily. So you might have 20 PRS, like getting merged within the week.

And you'll see that distribution. I got a chance chart, but then you see something that was a lot slower. I could go library like they get one or two, maybe if you're lucky one PR a week. But there's a lot of stability in this like cloud infrastructure. We don't need to constantly squash a bug.

And there's like with rust, there's type [00:11:00] safety or type checking. So like you get some validation that the, everything's safe. They got to always constantly try to reiterate and fix them. Like a hot fix. So like the I think the answer to your question that you were going to ask before, like the challenge is really, there's no standards when it comes to looking at data.

And I think we've community called the chaos foundation, which is a community health and open source. They have a bunch of metrics. And I think that what's good about that is there's a bunch of metrics, but the bad part is no one knows what metric to look at. So if you have 200 metrics to look at and no one's a statistician, everyone gets seasons in their college courses,

correct.

~like~ Somebody needs to say, okay, this is actually important for this project and this is important for that project.

And that's what we're trying to solve with this visualizing data and Dirt React, but in open source is to say, Hey, growth stage projects, early stuff. That's come out in the last 60 days or last year. Like these are probably the metrics that you ~brought out, ~pay attention to like new contributors.

But when you like a Kubernetes, which is getting like 200 new contributors a month. [00:12:00] Okay. There's a lot of stability in there. There's like really strong governance.

Yeah. ~Yeah.~

And that is ~represented, like ~represented in the data.

Yeah, cuz I mean if For fear of getting into stats land a little bit and you know the ethical concerns there is a lot of like decision power in that, like, how do we represent this? And what do we showcase? What numbers do we show? Because as you said it might not necessarily always be a bad thing for every repo.

If there's like a ton of front heavy activity and then one PR a year, it's ~like this is ~like some low level rust library that ~like ~is in super heavy use, but it's super stable. No one's really even touching it. So it's like, how do you ~yeah. Like ~balance that. Cause again, ~there's ~there's a bit of ~a ~a responsibility there.

We don't want to misrepresent any projects that are probably okay, but they're just not, they're not performing well by a lot of the benchmarks that we would typically look at.

Yeah this is something that we do want to solve for. We don't want to do without the community support on it, but there's like a categorization of projects. So like when he put like a project into a bucket of okay, this is a stable or feature [00:13:00] complete. Like I think sometimes as developers, we feel like we can't say this is done, but there are ~like ~so one of my engineers, he maintains a project called Cobra, which is a, how do you build seal eyes and go.

And it's such a feature complete stable project that it doesn't take much maintenance. To maintain it anymore. Cause it's being leveraged by like almost every CLI that's powered through go is built on top of the Cobra. So there's no breaking changes. And for the most part, if you want something new, you go build something new or you build an extension or a plugin.

So being able to categorize into Hey, this is now like, when the trajectory of startups, you have like early stage or pre seed funded startups, and then you have growth stage startups or IPOed. enterprise companies. And I think that's ~a, it's ~a very similar trajectory. When you look at open source and open source is still new.

Like it's hard to put a pin on our, a category on all these projects because like we're like really less than 40 years of open source, like 30, if you really shake the tree a bit. But there's no [00:14:00] standard like in our life, in our both of our lifetimes, like most projects have only been as old as we are.

And that's wild to say out loud, but like what we need is not a foundation, but like a centralized like place to say, okay, this is what we're looking at. And then we have that at GitHub. So GitHub does give us like issue counts and PRs. They don't make any dictation, like any statements about whether a thousand PRS are good or a thousand issues are good.

But we do have stars as a metric. And the thing that I was actually~ I did do, ~I did a talk in London, very similar talk about unconventional metrics and open source. So visualizing these things and everyone centralizes around the star and stars only really matter in the first like couple of years of the project.

At the day, you're not looking at adoption and traction through stars. You're looking at adoption and traction through downloads and contributions. But when the project first starts, you can't look at downloads and contributions because it's too early to make a judgment. So a lot of projects will get 10, 000 stars in a month, but to get zero stars in [00:15:00] the next week.

And it's, I say that a lot because I think it should be okay. That cool. Who cares about stars at this point? Like projects live. Let's just see if people actually use it. So things that we've been looking at are things like rate of self selection, which is take the core team, take the organization who contributes outside of that circle.

So it's actually something we're working on next, which is how we distribute, like we already actually have in our API, but we now have a number associated within a percentage of who contributes outside the organization. So in Q4 of 2023, ~0 percent of all ~0 percent outside contributions to TypeScript.

So no one outside of Microsoft made a contribution to TypeScript. Between September and December of 2023,

Which is not a bad thing. It's just 

Yeah.

It's an interesting statement, especially depending on like anybody does JavaScript, TypeScript is like leading the wave of future development. So if you're dependent on TypeScript, there's not a lot of influence you have in the TypeScript ecosystem. There's no TypeScript foundation. There's just Microsoft [00:16:00] employees. And then frankly, ex Microsoft employees are the ones that make outside contributions. So at that point, it's do we question that or do we just continue to chug along?

Yeah. ~Yeah.~

~that's the, ~those are types of things that we can now show that story within this data.

~Yeah. So yeah, I think that, that is, yeah. ~And I think this goes back to our previous statement. I feel like for something like TypeScript, that is like super, you Very interesting, but then ~like ~back to the CLI tool, it's like yeah, but this is like one or two people's ~like ~pet project.

That's very heavily used. And that's got, it's going to have a low

Yeah.

count there as well. So is there a way to easily ensure that the necessary context is being portrayed. Or ~is it just ~is that onus always going to be on the developer who's looking at this thing to figure out which of these stats is most applicable for a given situation?

Yeah. ~I've got a, ~I've got a whole directive internally. So we're a team of eight at open sauce. What I've been pitching the team is we have opinions of 2024. So like it's a voting year in the U S so we're voting for president and the folks with the strongest opinions team seem to be getting voted as president.

But what I'm getting at is I also worked at [00:17:00] GitHub, where pre Microsoft we had a bunch of stuff we shipped, but never shipped to production. And it's mainly because we didn't know is, someone has to have a strong opinion for this to make it to production. So if we shipped a thing we don't know what the ROI is, we don't know what the value is once we ship it, or we don't know who we're gonna upset when we ship it.

You gotta go find out that answer. And then deliver that to get stakeholders to buy in. So like an open source, like we specifically want to make statements and decisions on, okay, is this good or bad? Or is this okay, for this category of project. And that's what we're currently tracking towards.

So like I mentioned, like rate of self selection, I don't think any one metric you could look at by itself. And make a decision about open source. And that's why I push that stars don't matter because everyone's centralized around stars, but stars are great for the first six months, first 12 months.

But then you've got to look at, okay, is there some adoption and like going back to Brendan Byrne story, the whole interview with them there, what they looked at early days in 2011, 2012 for Kubernetes [00:18:00] was outside contribution. But really outside contribution to issues. So issues is a good correlation to interest.

So if you have interested folks opening up issues, which you can now take unique issue authors and count that. And then if you have unique issue authors who are not in Google, ~Now ~opening up issues and commenting, then you now have a good circle of folks that influence that you could go reach out to you and say, why are you commenting here?

Are you building something? Do you have value that we can help elevate? And what they found was Red Hat was in Kubernetes, making contributions through comments and issues and eventually PRs. And then PRs are ~like ~the things that we were actually staking as adoption. So if Red Hat is now doing a PR to Kubernetes, there's some adoption happening, like there's some interest that turned into adoption.

So let's have a conversation. Historically, like what happened was Red Hat basically greenlit Kubernetes as the standard for orchestration and DevOps. And now we have everyone using Kubernetes.

Interesting. ~Do you think that there's ~I think we're framing a lot of this around these [00:19:00] large corporate or corporate like entities that are ~like ~deciding how to make moves or like we're monitoring, exterior interest, not that it's issues or contributions would be limited to ~the, to like ~large players, but I think it's.

It's easy to fall into a pattern of that's just how we talk about this. Cause that's how we frame it. But is there I guess you think that there should be some other formal abstraction that would help us capture this idea of ~the, like ~companies or larger entities who are interacting with these things versus just like people, because it feels like we're having to extrapolate from ~like ~the people who happen to be here into the entity, which they represent or are working for.

Yeah.

That's an interesting question. Like it's a thing that we're we want to actually start working on as well and open sauce because I can ~I ~see 10 Microsoft employees jumping into my comments like I'm gonna get excited. I'm like, Hey, Microsoft, please. I'd love to have a call with you.

Find out what can we get some sponsorship? Also, let's all solve your problems. And I think I've another engineer, one of my first engineers I hired at open sauce maintains a lot of angular stuff and [00:20:00] he never knew Google was using his stuff. Like ~he, ~he did a state management library in GRX and never knew Google was using ~his~ his project until he went to a conference and they're like, Oh yeah, we use your project.

So it's really cool. But like he, for years he maintained this thing with no sponsorship and everyone knows he's doing this thing, but he's man, it'd be cool if ~like ~I'm doing this outside my day job. It'd be cool ~if ~if I get some validation. So then my day job could be like, Oh yeah, Google, like they're sponsoring, like they're going to green light your involvement and invite you to conferences and et cetera.

But, and that would like, ~I, ~so I just retweeted something from one of my other, sorry, I'm not going to shout out all my employees. So one of my employee Becca she wrote a blog post about recognition and open source. And there's a correlation to ~Yeah. ~Representation and recognition and like people feeling good.

Everyone really centralizes around. If you donate to ~like ~small projects or projects we depend on in our dependency tree, ~then every, ~that solves all the problems. But sometimes like 10 year old Brian, like years ago, like if my dad gave me 20 bucks cool. Thanks [00:21:00] dad. You love me. But if my dad spent 10 minutes with me, like that's way more valuable than 20 bucks.

So when it comes to open source, ~like ~if Microsoft would just invite me to their conference or jump on a team's call or whatever, like show that I'm validated in the space, that's way more valuable. And ~that's ~that's what the blog post is about. But sometimes we can just forget, there's actually humans on the other side and we're not all trying to chase, big valuations and IPOs and enterprise jobs.

Sometimes we just want to know that we matter and that we're accepted in the community. And I think there's a way. For years the Rust community was just building this thing and got 1. 0 back in 2015. And now, ~yeah~ literally yesterday, a million dollars ~of ~Microsoft donated to the Rust Foundation.

That's the validation that Rust needs to show, okay, We care and we see you. But years of that was like, Hey ~Russ, ~come talk to us about our Azure compute and getting like Russ working in like weird VM environments. And so going back, ~like we, ~we definitely want to start showing that signal, but also.

There's been a trend of [00:22:00] now there's open, like commercial open source. A lot of projects are starting with the idea of I do want to build a company and I have a, I want to start a structure of like we build in the open. We have open source contributions, but also we have a paid self hosted solution that enterprises can use.

And with that trend happening, like now companies that leverage open source as they go to market can then start tracking to say, okay, we're actually doing a great job. We've got some good traction from these companies, these interested contributors. Now we have signaled that maybe we raise another round or maybe we ship a new feature based on these hearts that keep getting added to these issues.

mean, is that kind of the narrative feels like an overly charged word, but is that journey the thing that ~you are, you ~is in your mind's eye a lot of the time when you're making decisions about open source is this kind of that, not that it's like the only, a meaningful market or anything like that, but are these people that are like trying to do open source in a professional or a pseudo professional manner?

Is [00:23:00] that the thing you're thinking about a lot of the time when you're ~building these tooling or ~building this tooling?

So I've actually spent the last year we spent way more time thinking about the large enterprise and How distant they are from open source because so first goal I had for open source is can we get people to open? Do contributions in open source, so we built features where you can see PRs.

You can find out who the stakeholders are You can walk in a project that's know what you're doing and Make sure you're having a good time, but also know that when you're not going to have a good time, no, okay, this is not a project I can contribute to. So we solved that problem immediately.

Once we once I left GitHub and started a full time working on this problem, but immediately what I found is it's great that we can get a bunch of energy to do open source, like a hacktoberfest, but the missing piece is like there are established projects that could use attention, that could use help, could use contribution.

And a lot of these are dependent on. Company backing or financing or stakeholders. So we spent the last year really connecting with companies and enterprises to say, Hey. If we could like source all the data that you care about in open source in [00:24:00] the one dashboard, one workspace and then you can make decisions based on that.

Would that be helpful? So we've been solving that problem. ~Excuse me. So we've been, yeah,~

over here. Yeah.

been solving that problem where we provide now an open source workspace where you can see multiple repos across organizations in the one dashboard. And then we recently shipped ~like ~our team's product, which open source maintainers.

Up and coming companies can now also get insights and data with the same product we ship for enterprises. So starting with the contributor experience to then moving to enterprise to now maintainer happiness. That's ~those are like ~the trifecta ~of ~that we're operating in. And now the goal is can we now have a happy medium in a place that you can explore open source?

You can maintain your open source and you can also be super knowledgeable about your open source.

~Yeah. ~Yeah. I think that it is super, super interesting. Like you said, open source is fairly new, whatever you say, like 48, 40 odd years or something like that. And yeah, it does feel like we're hitting. Kind of maturity isn't the right term, but there's like more dimensions to this now than there were [00:25:00] really historic, like Microsoft's a big role.

~And ~and like the Linux community has been there for a long time, I think, but it always felt a little bit more I don't know, disparate from the traditional corporate world. And there was like the open source world and that, but there's all these, this weird strata in between now it's like all these funky I don't know, interactions and relationships, because you still have a lot of just the like, individual contributors who have their few little handful of projects and this is the thing I maintain.

But yeah, a lot more of just like the discussion around open source, I think is on these like big things that are shepherded by one entity. And this has been a pattern that's been emerging for a while. It's just so many of us as developers are relying on these tools that are like one, kind of firm is really the guide here.

And yeah, it just, it's interesting. It's interesting to think about that. Relationship and how these different players are like navigating the space and making decisions about what code to pull in or work on day to day. Yeah. I'm curious if there's for someone coming in new, like how do you what would you recommend?

Like how do they even make [00:26:00] sense of any of this? Cause ~it's ~it is such an interesting landscape at this point.

Yeah, yeah, and like the word new and open source, like a lot of that gets attributed to like brand new college students bootcamp grads. If you're in that space, like we have an intro to open source course called intro dot open sauce dot pizza. We put everybody there so that way you know how to interact and now how to look at PRs and issues and like really avoid because there's a huge movement around like this fixing typos at open source.

And I think there's a space for that, but I think we've over indexed on that. And I, we prefer to have folks like level up and know ~how to like ~how to operate. Like I was just at an event last night and it was like the networking is the thing that's ~like not, it's ~challenging to people.

It's everyone asks the question Oh what do you do? And ~what do I, ~what does that mean?

Yeah.

I'd rather ask the question what'd you have for lunch? Like any cool restaurants local? Yeah. That's a better opener. So like we, we try to teach people like how to ask about their lunch, as opposed to Hey, John, please, or give me issue.

But there are a lot of folks who have been engineering for years, folks who are stakeholders that depend on open source [00:27:00] and don't even know how to interact as well, like how do you even know. Where to start. And so our opportunity there is like we have this explore page where you could just, if you know JavaScript, or if you're interested in JavaScript, we've got a bunch of JavaScript projects.

You can see, basically we have a list of last committed repos. So we have a list that we cashed over the last hour and we'll just show you what got the last push to and then like most active. So projects that are like up and coming in the go ecosystem. That actually take contributions and still have merges that happen.

Like we show you those projects. And it's really just like this kind of whet your appetite to know there's open source that's happening. But the real goal is like, if you depend on open source, so if you participate in the ecosystem by consuming open source, like the best thing you could do is just know who's building.

And what we're really trying to build right now is we have these profiles, we have this thing that we're going to be shipping in two weeks called Star Search. And the idea there is in the nineties, I used to go to my grandma's house and we'd watch a show called Star Search and like Britney Spears, Beyonce, Justin Timberlake, Ryan Gosling, they were all on Star [00:28:00] Search as kids.

And the product that we're building is like, what if you could find developers ~and ~Who are up and coming before they're famous, like before they're standing on stage and doing keynotes. ~And ~and this is, it comes out of a need that, or really a concern that we had when we ship get up sponsors, which was if we ship get up sponsors, the folks who get sponsored are the folks who are the most famous.

So like, how do we combat against ~like ~up and coming folks who don't get the attention they need? And ~it quite hasn't been, ~it hasn't been a problem that's been solved yet. And there's not a lot of attention being driven to that. So there are maintainers who are doing thankless work behind the scenes who have never been seen.

My goal is like new people find new people and become friends.

Yeah.

The hope is that we can now showcase ~like ~folks who are really doing the thankless work and can now be showcased. We sponsored a tool called OSS dot love which it's really this thank you cards to open source maintainers. And the hope is that we can start integrating some of that stuff into our platform as ~we, ~we build this discovery engine for open source.

~Nice. ~Nice. That's super cool. This is a [00:29:00] question that's just occurred to me and it's very off script, but it's a problem that I feel like you're going to have an opinion on here. I've found that As of late a lot of open source There's a lot of discussion happening around open source projects in pseudo closed forums I'm thinking like discord servers and like slack channels and stuff like that like things that I feel typically issues would have been being opened for In the past in repos, like a lot of that's moving into these things that ~like ~aren't indexed on the internet anywhere.

So they're like not searchable and it's harder to get involved in those communities, your networking point flip the switch for me. Do you think that is like a problem? Is there been a failure of tooling a little bit? Because there seems to be a demand for something that is more like real time and community feeling like something like discord, but again, like we're, or Slack, ~we're ~like, we're in these closed.

ecosystems where it's hard to get in the door without knowing that you need to find the door to open. Is there, has there been some failure there? And is that something you guys are thinking about at all?

No, I don't know. I've ~got stronger, I ~got stronger opinions loosely held about this, but like [00:30:00] at GitHub where everyone's remote we had a very strong AC culture. So like the decision that was made pretty early when I, before I've enjoyed was like conversation happens in Slack decisions happen in Slack.

So like you could have back and forth and chat and be like showing screenshots and dropping ngrok links that are, I don't know if people still use ngrok at this point, but

I don't know. 

That can be happening in a real time. But as we're further and further, distributed. I think now we're in a post COVID world. I servers are great. I've got gigabit internet right now. Like we do need to be cautious around, like not everyone could be in that synchronous conversation. So if something is made, let's do a, like in my discord, The rule is if you have a bug, feel free to chat through it and ask questions, but drop an issue.

Cause what's going to happen is whatever it's decided needs to go somewhere historical record. Cause I'm not searching through discord

Yeah. ~Yeah,~

random errors and stuff like that or finding out decisions, but I can do that on GitHub pretty easily. And I can link that issue [00:31:00] into a PR when the decisions were made.

Yeah.

At github we ship github discussions for that reason like these are index conversations in the open attached to the project and it's itself and the hope is that more communities will do that Still, cause like we did have IRC prior. Still people use IRC, but like when I started to open source, you had to go find that door, hopefully in the read me or somewhere on the website of this is where we chat regularly come to the IRC and that's the place where you go and network.

And you ask people, what do you do? And what'd you have for lunch? Also, I have this bug. So I don't, I wouldn't fault like slacks and discords, like being a place that like, we should not be. Have those conversations, but I think it's going to be a lot easier for longevity of community.

And I think that's just the thing that I've been really calling out. Like this visualizing the state is there are like stakeholders within projects where they drop an issue and everyone stops and listens. And those folks tend to, so I mentioned Avenue is a great example of this. Like people will go read an Avenue issue.

And Evan will have a conversation in their Slack and go [00:32:00] back and forth on this stuff. But that stuff migrates into an RFC or in their RFC repo. So I think great leadership really comes into okay. And not every project could have a great leader and all the stuff you get to grow up and figure all this stuff out eventually.

And I think that's why we have a react is like the standard for front end apps in components because they had a strong governance and backing through the React core team instead of Facebook. But you look like a backbone or a knockout, like none of that had the same longevity. And I think that good or for ill, like corporate sponsorship at open source is helping giving us stability and like making decisions for what we're choosing.

So I don't have to go rewrite my entire react app to react 19. I didn't see like a quick migration because they're not going to break the entire industry. Like the entire front end web is not going to break because react decided, Hey, Facebook or meta cares about this stuff now. Yeah, I don't know if that was the answer.

It was like a long winded loosely held opinion.

No, I think that's good. Yeah. [00:33:00] I'm like, I think like people are very cognizant of this. I think a lot of, especially maintainers of open or of larger projects, they're ~like ~thinking about this problem and like the communication channels and people are cognizant of it.

I don't, I just think it's a curious development that ~we've ~we've seen recently, I guess on that note, you noted where, like the trajectory of some of these bigger projects here and how they seem to be a little stickier than things we've seen in the past. Where do you see the future of like open source going?

Do you foresee this kind of trend continuing of these like large kind of closely tied to a huge, firm. Corporation, company, whatever of some kind. Do you think that'll continue to be the norm? Will we see more and more of that? Or will there be more fragmenting again, going back to, 

yeah I think that we're getting a lot of maturity in open source. So like we were going through an evolution right now in open source, like 30 years ago it was like free as a Libre open source software, like free beer. Basically like there's a whole bunch of Richard Stallman quotes and statements that people make about [00:34:00] open source.

I wasn't around at that time. So ~like that,~ none of that stuff is relevant to me. What I know about open source in the last 10 to 15 years. Now that we have like a new generation that are now doing involved in open source, way more in the JavaScript space and the Rust space, even in Go at this point.

It's like indie hacking. You build a thing, it takes off, it doesn't take off. Who cares? It's one or done. It's a throwaway experience. If it does take off, we're seeing faster commercial open source out of stuff like that. Now whether it's all being successful, it's a thing that's happening right now.

It's a trend that we should all be aware of. Folks are building companies around the idea of open source and a lot of folks are being successful around that. So like we're going to see a lot more companies that were previously open source projects are now fully VC backed projects. And it's interesting and it's going to be an interesting evolution, but like open source.

Is like in that position to be like, Oh yeah, we can visualize this data because this is the trend that we see, but we're also see the absorption of open source into enterprise. So as [00:35:00] we saw this with Webpack, the core maintainer got hired, so not even acquired, but hired by Vercel to build ~the, like ~the successor to Webpack, which is TurboPack.

So there's no, like just a job, but Now the future of Webpack is now TurboPack and now it's owned by Vercel. So like now you see this sort of ownership of influence through hiring staff that were previously just taking donations now have full time jobs. So as we see more investment in open source, we're going to see this trend of a corporate backed contributions powered by enterprises.

So as Vercel and other companies get bigger, it's in their best interest to make sure the stuff in the roadmap and the stuff that's in there. Upstream from their product is going to stay alive because the last thing you want to worry about when you're trying to IPO it's like whether the web pack build is going to fix itself or not.

So that's the trend in that you see also Microsoft and AWS, like when Redis relicensed, like only a couple of months ago, the one thing that was interesting when you look at [00:36:00] visualization of data. So we have this on our repo pages, you can see all the forks that happen on Redis. The data license or terraform months ago, all the forks, all the new offshoots that are happening off of those like huge events.

But then you also have Valkyrie from sort of AWS, but now it's in the CNCF and you also have Garnet, which is the other Redis Clone that's built in C sharp at a Microsoft. So now you're seeing all these trends and all these sort of like disparate projects that don't start from, Ricky Dean, like bedroom office BW starting a new thing.

It's like literally it's built by Microsoft and it's 25, 000 stars within the first two months. So like that trend's happening at what's here. It's not going away. So you're going to see way more investment in open source as you think about, okay. If we're if Azure is powering a lot of the compute for the industry and Azure is dependent on the, all these Linux distros and all these compute platforms, if you better believe Microsoft's going to want to be involved in open source and same thing, [00:37:00] AWS, same thing with Google cloud with digital ocean for cell, they need to make sure open source sticks around because they're all benefiting rising tide raises all boats.

So if open source sticks around, whoever pays the bill, it doesn't matter. Everyone's going to benefit from it.

Yeah. Nice. Cool. I feel like that's almost as good a wrapping point as any. Is there anything else you would implore listeners to keep in mind? Maybe they're just, typical open source consumers or developers that are doing a little bit, but they're just in the space.

Anything you'd recommend people think about or check out? 

I, the only thing I'd say, keep in mind is say thank you. Like a lot of times, like there are folks who are doing open source that don't get a thank you. They just get a lot of complaints. And I tried to do this thing on Twitter where one day, every day I try to do one tweet and I do one reply.

Cause like I could go produce content and like people will give me a bunch of likes and favorites and retweets, but not everyone gets a reaction or a response. On their tweet. And a lot of people will write a whole blog post about how they're burnt out at open source and get no response. ~That's not true.~

A lot of people will respond to [00:38:00] that, but what I'm getting at is sometimes just saying, thank you saying, Hey, I see you saying, Hey, I love this project. Could go like way further than almost any 20 donation will go. Also donate to open source as well. That'd be great. But yeah, I'll leave it at that.

~Yeah, nice. Yeah. We donate. Donate your gratitude. Cool. ~Thank you so much for coming on and chatting with me, Brian. I know we're all over the place there, but that was an awesome conversation. So yeah. Thank you.

Pleasure.

Yeah, for sure. Take it easy.