Paul Jolly: Yes. And Jon, back to your point of it being open source - yeah, it is an open source projects. One of the questions we’ve had from folks who’ve actually tried it out so far is why do need me to log in when I’m accessing play-with-go.dev? It’s a great question, and it’s kind of related to the fact that this is an open source project. We’re not logging in in order to steal email addresses, but as I said in the introduction, there’s a real container that is running per guide that you launch within play-with-go.dev. So there are real compute resources, and hence money that we are spending whenever anybody ever opens a guide.

So yes, we are an open source project, and we’re funded by sponsors entirely. But the focus, as Marcos was saying, is that this really is a project that is by the community, for the community, to coin a bit of a phrase there. Whilst it does look like this is an official Go project, this is an open source project, and the intention is that anybody should feel free to contribute in various different ways, whether that be just feedback on the site itself, contributing to Play with Go, Play with Docker, or any of the open source projects that are a part of it… Or if anybody wants to contribute content, as well. There really is sort of an open door as far as how we can make this content platform better. As Marcos said, there’s ways in which we’ve tried to lower the barrier to contributing by making sure that if anybody does contribute any content or any fixes, we can know instantly whether there are any problems with any of the existing guides. It should be a fairly resilient system.

Rasmus Andersson: How I came to join Spotify is a little bit interesting… So in 2001 I started my own company together with two friends - my brother and a friend eventually another friend. We worked on this, and eventually I was able to make a living out of this. I moved to Stockholm in Sweden, and I met some interesting people… And one day I got this phone call from someone, just some number I didn’t have in my address book. I mean, this is pre-iPhone; it was a little flip phone.

Dylan Schiemann: Sure. I think it was around ‘96 when I first really got into JavaScript, so pretty early in the days… And I had read most of the books that were out at the time, and honestly there weren’t a lot of other resources available yet about JavaScript, so I started joining the various standards mailing lists, which at the time were the StyleList, the DOMList and the JavaScriptList, and really just started participating in… I felt like the best way to understand the web platform as a whole was to participate in the standards process. So the time, frankly, it was a bit – unless you were paying to join the standards body, you really didn’t have a say, but you could still participate and figure things out and ask questions.

Standards was mostly a part-time job for a few engineers of each of the browser vendors at the time… But it was really fascinating to me to say, “Okay, how does this really work?”, and one of the first things we did at SitePen is we tried to create something sort of like Google Page Creator… So basically a web-based HTML, CSS and JavaScript editor. But this was back in 2000, so it was a little different than trying to do it in 2010, or something… And one of the things I wanted to do was figure out how to make it easier for someone who had no programming experience try to style a page, which led me down the color name path. I actually had proposed an alternative way to name colors at the time… There were a lot of cool ideas that didn’t go anywhere, but were still interesting to think about.

Today, standards are amazing compared to back then. I mean, they’re not perfect, but the open process, the way we handle things on GitHub, and talk through them publicly, and the growth of TC39 and WHATWG… I mean, Ian Hickson probably deserves the biggest amount of credit for sort of changing the way we think about the standardization process as a whole.

In the early Dojo 1 days I kind of had the feeling of “Standards are broken. We’ll just do whatever we want.” But today’s standards feel pretty good, so we try to align to them much more closely.

Eric Holscher: It’s kind of the substrate of career growth, and networking… I’ve gained so much from going to conferences and meeting people, and that’s been a huge part of my professional life, and how I’ve been able to do what I’ve been able to do. And at Write the Docs we really explicitly tell people, like “You’re here to meet people.” Because I do think it’s a two-step dance. The Pac-Man is the implementation, but you also have to give people explicit permission.

This first really hit me at a conference called XOXO, which is also here in Portland. It’s kind of a media and arts, kind of independent – I don’t quite know how to describe it, but… They were like “We are all here in the same room to meet each other and talk to each other. And there might be people that are you impressed by or scared to meet, but literally, your job here is to meet everyone else in the room.”

[24:12] That gave me the courage to join a group of people when I might not have… And I try to give people that same permission in my events, where I’m like “You are in this room because you were meant to talk to anyone else in this room. While you’re here, break out of your introvert shell and just know that is your job. No one is gonna turn you away.”

Then you take the Pac-Man rule, and that’s how you actually implement that in space. It gives people a little bit more nerve to know they can join that group if they see people standing that way. It’s kind of a social cue that people are gonna welcome you.

Kevin Owocki: Yeah, sure. So Gitcoin is a portmanteau of GitHub and Bitcoin. What that means is we take any GitHub issue you already work on GitHub, and we allow you to incentivize that issue by attaching a cryptocurrency bounty to it. So if there’s some bug on a repo in open source that I’m relying on, and I can see that that issue board is overwhelming or it’s got a lot of issues on it, I can place a cryptocurrency bounty on that issue in order to incentivize the repo maintainer to turn around the scope that I would like turned around preferentially. So it adds incentivization mechanics to open source software.

The community is about 1,700 people at this point. I’d say that people join Gitcoin a) to make a little bit of money in open source, but also just to learn about blockchain with a set of peers that are also excited about Ethereum and Bitcoin and the evolving Web 3.0 ecosystem.

Colin Dean: …your avatars. And interacted a little bit, and… But yeah, it’s always cool to meet people who are doing awesome content generation. You guys are a little bit of an inspiration for me continuing to do the stuff that I do.

Adam Stacoviak: Precisely. To close the loop on the invitation, I would say if you’ve made it this far and you haven’t gone here to this particular webpage yet and joined the community, you should do so now… Because we are just as open and welcoming in Slack, in-person, as we can be. Go to changelog.com/community. Free to join. We’d love to talk to you in there. Lots of people in Slack… It’s not overly busy, but it’s definitely active, and there’s a place for you there. So if you don’t have a home, or a place to put your hat, or hang your coat, or your scarf, or whatever you might be wearing, or take your shoes off and hang out for a bit, that is a place for you to join; you’re invited. And everyone’s welcome, no matter where you’re at on your journey. So I hope to see you there. What else is left? What can we look forward to?

Ujjwal Sharma: Yeah, that’s a very interesting question, and it’s one of the most important questions that you ask yourself. People really underestimate how important community fit is. You could start working at any project. For example, we talked about Linux kernel, which you didn’t find a good fit for yourself. But there’s a whole lot of really talented, really amazing individuals who work on the Linux kernel project, and they find that a good fit for themselves.

So I think it’s really important to understand what your fit is. Look at these projects, like – Node.js has been around for over ten years now, Electron for a little bit less, and v8 for more than that… But if you look at the initial phases of these projects, a lot of the people who got involved early on were people who were really interested in the technology. A lot of people who got early on involved into Node.js were interested in streaming, and event-based APIs, and runtimes. And people who got involved in v8 were interested in parses and optimization.

I’d actually go on a leg and say that’s not really the case anymore. I look at myself, and I look at some of the other younger contributors who have only been involved for the last year or so, or maybe just a little bit more… And I see people who essentially join the community. Me, for example - I’ve learned everything about the Node.js project, I’ve learned C++ essentially via working on the project. I’ve found amazing people on Twitter doing amazing things, and I was like “Huh, I really like these people. Maybe I could somehow find a way to work on them… Start writing tests, and then start writing JS code, and then start writing C++ code.”

As a project goes on and grows and gets more mature, and you develop your community - so it’s more about community than the code, at some point… Because I think, along those lines - that’s how I try to explain to myself - the amazing press coverage and the amazing community… I ascribe to the amazing Rust community, the success they’re having these days, is that they spend a lot of time building an amazing community, and they’re starting to reap the benefits of that.

So unless you have a welcoming community, unless you have somewhere where people can find a good fit for themselves, where people can feel at home… You know, technical superiority, as some might say, is a far-fetched goal, because you will miss out on a bunch of amazing people.

If you look at the direction projects like the Linux kernel is moving to, you’d see they’re starting to realize that they need to work more in inclusivity, and they need to work more on how to get people to feel more comfortable working on their project.

Colin Billings: Absolutely. I can talk quite a bit about it, but I can also share with you a number of places that people could go read… But the semi-pro version of circadian lighting - I think it starts with first understanding the role of sleep in our bodies. Our lives are spent on cycling between an awake period and a sleep period; and the sleep period is immensely important.

I was recently reading a book by this gentleman whose last name is Walker, who just released a very popular book on sleep… And I thought the way that he referred to sleep is pretty interesting. He called sleep the only reason why we don’t die.

Mikeal Rogers: Tell us a little bit about why you did eventually decide to join the WordPress project, and maybe why it wasn’t always part of the WordPress project.

Jerod Santo: Why don’t we just give a little constructive feedback on this TODO group website? Because the way it looks is it doesn’t look very much like you are invited to come join this group. It looks very much like, “Hey, check out what GitHub and Facebook and Adobe and Microsoft and Netflix are doing”… But maybe you run a five-person development agency… It doesn’t say “Every corporation that wants to do open source should be a part of this.” You’re saying that’s what you want - you want more people to come and join… I think that message is lacking a bit.

Daniel Whitenack: Yeah. I’m excited to hear more about Chris’ vegetable monitoring, and I’m really excited that you were able to join us, Anais, and share with us a little bit about time series, and about some of the things you’ve been working on, and your perspective on statistical methods versus machine learning - all that was really useful. We’ll for sure put links in our show notes to InfluxDB and the other things mentioned. Thank you so much for joining us, it was a great conversation.

Jerod Santo: Thank you. You join me. Because I’ve been hyped out for a little bit here.

Verónica López: Yeah, yeah. Now, we have been in a little bit of pause of meetings, but yes, for sure. Come join us and you might find me there… But on the Kubernetes Slack, always, always. Abd we are active on – our Slack channel is #release-management. That’s where we have activity. And also in #sig-release. Yeah. But honestly, if you send me a DM, or even a tweet, and you have a specific concern, I will respond to you. Hopefully.

Adam Woodbeck: Go has good support for UDP. If you’ve used TCP in Go code, you’re probably familiar with the – in the net package there’s the Conn interface. And if you use the dial or dial timeout, or the dialer in the net package has a dial context method. When you call that, you receive a Conn interface back, that allows you to do a few things - you can write to the network socket, you can read from it, you can change the deadlines, which we haven’t talked about yet, and you can tweak a few things in the connection through that interface. You can also do a type assertion to the TCPConn struct, the object underneath that interface, and it gives you a lot more options that you can do. You can then start modifying (say) your receive window, your send window, and other things like that. Enable keepalives if you want to. I would think for most purposes though, the Conn interface is suitable for most people using TCP.

Now, the reason I bring that up is because when you use the dial function in the net package, you can specify a network type of UDP as well, and you still get a Conn object. However, there’s an underlying UDP connection to that Conn interface now, and it’s going to function a little bit different. That object, although UDP is stateless, the object knows who it’s sending to. In other words, when you create this connection object, even though it’s UDP, you give Go an address that you wanna communicate with, so when you write to this object, it will only write to your destination. And when you read from this object, it will only pay attention to UDP packets coming from that destination.

Now, there’s a PacketConn as well, and that’s probably better suited for UDP, at least the way most people will use it, because the difference with TCP and UDP in Go is TCP has a separate client that dials or reaches out, and then a listener that listens for incoming connections. UDP isn’t like that. When you establish a UDP object, it’s both a client, if you will, and a listener. It’s listening on a local port, on a port on your computer, and anything on the network can send messages to it. So when you read data from that UDP connection, you get the amount of data you read, you get an address, and an error interface. So you as the programmer need to check and see “Okay, I need to look at this address. Who did this come from?” Because it may not necessarily come from the destination that you’re communicating with; it could have come from a third party, potentially. So there’s more work at the application layer to manage the incoming data through a UDP connection if you’re using that PacketConn.

Feross Aboukhadijeh: So I was thinking of different things I could do, and one of the things I was really curious about was could I do computation using WebGL, or workers, to do useful work on people’s browsers? Sort of use it as a distributed computer. So I looked into that, and the browser wasn’t really quite fast enough, so I then discovered WebRTC, which lets you do peer-to-peer connections between browsers… And the idea that I had was “Why don’t we connect a bunch of sites together and build something kind of like a torrent network, where the resources for a site can come from the other people on the site? And we can reduce the cost of running a site.”

So I ran with that idea for a little bit, and tried to make a company out of it, but I learned a ton about how not to do a company, I guess… One of the big problems we had was just being too focused on building stuff, writing code, and not really talking to customers and seeing if there were people who would ever wanna buy this stuff… So a little bit of time went by there, and we didn’t really have any customers, but we spent about a year just building a bunch of really cool technology, learning all about WebRTC and making some cool demos… And in the end we got acquired by Yahoo!, which was a good outcome for us, because we didn’t have any customers, and we worked on this thing for about a year… So it was a really exciting outcome, where we got to go and just basically join the video team at Yahoo! And made a little bit of cash, obviously.

And that’s actually what enabled me to spend a lot of time on open source later, and not worry about having a job. I could just fully devote myself for years just working on stuff and giving it away, and not having to be worried about making ends meet.

Anyway, getting back on track - so right about when that happened, I gave this talk at RealtimeConf, and I was talking about WebRTC, and how cool it is, and what you could build with it… And at the very end of that talk I mentioned the idea for WebTorrent, because I knew that Yahoo! was gonna have the technology we had worked on, and my concern was that some of the ideas of connecting everybody’s browsers together and making a really amazing peer-to-peer network that can decentralize, control things - that was a cool idea, and I didn’t want it to die with this acquisition.

So I was like “What if we rebuilt PeerCDN, basically?” Rebuild it from scratch, but instead of saving money on bandwidth, we made a goal of decentralization, and we made it match the BitTorrent protocol as much as possible, because we know that already works, and that has a lot of users, and there’s all this content on there, and there’s a big community of people… So we could just make this – basically, bring the BitTorrent protocol and put it into the browser. It was just an idea that I thought would be cool to work on, and I wanted to start working on it… So I threw in a slide at the very end of the talk, the last one minute or 30 seconds, and I said “I have this idea to make BitTorrent on the web. Here’s what it would do. If you think this is a cool idea, come talk to me.” I threw it out there, this thing that would – I wanted people to come, I wanted to find collaborators.

[20:16] But one of the people in the audience misunderstood what I said, and I did have a GitHub repo up with a readme in it, that just said what the project would do one day… And he tweeted it, and he had quite a few followers who clicked through this link and said “Dude, there’s no code here. What is this project?” So then he messaged me and was like “Dude, I thought you had code. What did I tweet this out to all my followers? There’s nothing here.” And I was like “Dude, you could have looked at the readme, man. It was clear that it was just an idea.” [laughs] So this guy basically launched WebTorrent for me, before

there was actually any code.

I think it was a good thing that he did that, because I don’t know if I would have built it otherwise. It was just this idea – it wasn’t clear whether people would wanna use it, or anything like that. But because of the reaction - all the people who started opening issues and saying “This is a cool idea. I really think you should do this”, I got really motivated, and I really wanted to actually build it at that point.

Dan Moore: [01:02:14.16] I’m torn. I want that world. I want that world. I’m not sure we’re there, because LetsEncrypt, the big lever there was Chrome, and the scary warning messages in the URL bar, and things like that. And I don’t know if we have – I mean, maybe you have that with the operating system vendors… So maybe that’s the lever. But it feels like we’re not there yet. But yeah, I would love a place. I’d love a world – and honestly, it’s interesting to me, because the more we talk about this conversation… Password managers and passkeys are both kind of two sides of the same coin, or they’re two approaches to the same problem, that both believe that computers are better than people at keeping track of verifiers of identity. And passkeys do it in a way that’s a little bit more opaque, and not maybe as compatible, but is a little bit stronger, because it’s private/public key encryption. Whereas password managers are more designed to like fit in with the world we currently live in and have all these nice add-ons that you mentioned, Adam. But I just don’t [unintelligible 01:03:28.18]

Ryan Worl: That’s a really good question, and to take a step back from that question for a second, talking about the commercial open source stuff… This is obviously a little bit inside baseball, but as a part of going through that decision process, we talked to the founders of a lot of commercial open source companies, and we asked them “Let’s say you were starting our company today. What would you do?” And without hesitation, the answer we got was “I would not start it as a commercial open source company today.”

[01:07:53.19] And there are a lot of different reasons that they gave for that, and I can’t really give some of those reasons without potentially identifying who those people are, and I don’t want to do that… But the challenges of an commercial open source company today, with the – it’s not even just the hyperscaler cloud providers anymore taking your stuff and running it. That’s obviously a concern, but you can get around that with – like, the AGPL does a decent job of preventing some flavors of that.

The other issue is just like the competition within the category that they’re building their product in is extremely high, and having your source code out there in the wild, and letting everybody know your secrets, essentially, about how you made your product better - you lose a lot of the juice behind why you have these huge staffs of developers working on interesting things. It’s not to say you can’t protect that other ways either, with software patents and stuff like that, but people don’t – the appetite for software patents… It would do a lot of brand reputation, I think, if these commercial open source companies created a bunch of software patents and started enforcing them against each other, for example. It’s a very challenging situation today.

A lot of the companies that you might view as successful commercial open source projects, they might be successful in the iteration that they exist in today, or yesterday in the case of all these real licenses, where they have good adoption in the developer community, and they might have good success in the VC-funded startup segment of the world… But there is an inevitable push to go upmarket, and to go after larger and larger customers, because it’s effectively the only way to support growth. The growth of what you can achieve within the small – if your customers are all small startups, even medium-sized startups, and developers playing around in their personal capacity or stuff like that, the revenue opportunity is just really small, unfortunately, for a lot of these businesses. It’s much easier to sell a million dollar a year contract to an enterprise than it is to get a million dollars of revenue out of a bunch of small and medium-sized businesses.

So the temptation when the growth starts to slow down is “I need to go do that now.” Like, that’s the first thing your investors are going to tell you, is you need to go upmarket and get enterprise customers. If the product that you’re selling them is support or a couple of features on top of an open source project, your ability to exert pricing pressure on that enterprise buyer, to get them to pay a higher price, or to get them to pay at all in the case of a lot of these open source projects, where they spent so much time making it good that the enterprise can just hire one person to maintain it internally, and just move on with their life and run the open source forever, and maybe pay you a peanuts support contract, essentially; not actually enough to support the business. It’s just really hard.

I completely understand where you’re coming from, and it might’ve felt as if these companies were successful from the outside, and some of them definitely were… But just, there is that inevitable pressure to keep the growth rate up, and the only way to do that is to go upmarket. And when you’re going upmarket, you need to provide something that looks valuable. And if your project is open source and the alternative is hiring a developer to maintain it internally, you kind of have a cap on how much you can charge.

It’s the same thing if you’re offering a cloud version of an open source project, for example. The premium someone will pay for your cloud version - it may be lower than you expect if they can self-host, because they’re always looking at that… They’re looking at both sides of the coin. “How much will it cost me to self-host this, versus how much does it cost to use your cloud-hosted version?” And that calculus does not always come out in your favor as a vendor. You may have to charge significantly more to make the numbers work on your side than what they think they can run it for internally. It’s really challenging stuff.

[01:12:18.08] We wanted to provide the best product possible, with the best product experience possible, and we didn’t feel like the shape of an open source commercial company was the right way to do it without having a lot of these distractions about the things that I’m talking about right now come up along the way. And we didn’t feel like it would be right to do that, the bait and switch thing that people are doing these days. We wanted to be honest, basically, from day one.

Chris Benson: The flipside of the coin on the fear is that this was also the year that we saw significant policy and regulation initiatives being put in place. We had the executive order that came about in the US, within Europe they had the AI act late in the year, and that made a big difference… And we have talked about a lot of this, by the way, obviously in the show, and I would refer listeners back - many of these things we’ve discussed here you can find in a dedicated episode on some of these things on our show. So look back through that. But in general, as I moved to - and I mentioned this on a previous episode - move into family, or go and hang out with some folks that had nothing to do with AI, and they don’t know what to believe.

[00:22:16.18] Another thing that got pointed out to me several times is that you’ll have big names in our industry, that are big enough to make it into mainstream, people like Yann LeCun - he famously considers it ridiculous, that there’s fear of AI and stuff like that. And then you had Geoffrey Hinton on the other side, another one of the major names, who left Google so that he could talk honestly about the dangers of AI. And so you’re talking about two global luminaries in the space that were actually recognized together recently as pioneers, and yet they have polar opposite views about that. And so I think that’s hard if you’re in the industry. But if you’re not in the industry, you have a lot of trouble trying to figure out who should you believe when you get a New York Times article or something like that that addresses these issues, and you go “Well, how do I handle that?”

So I’m hoping that in 2024 maybe we can pick up a few new listeners, maybe some of those that are interested in the topic, but don’t work in the industry, but maybe they can get educated a little bit more on kind of what the space looks like.

Chris Benson: Yeah. As you were going through that, it struck me that in addition to accounting for the unintended consequences behaviorally as you perturb data and stuff, that the flip side of that coin becomes vulnerabilities from a security standpoint, in terms of affecting the outcomes of foundation models, or any model for that matter, by doing that. And so it all just has a greater multiplier associated with the foundation, since you’re building so much on top of that.

So as we look at this in the days ahead, it will be interesting to see as well what the security implications are of protecting the end-users that are impacted by this, meaning the model will change the behavior of lots of different executions on that, where people are using it for various use cases that affect people. I would conclude by noting that in all of this that we’re talking about, it’s starting with human beings and it’s ending with human beings. And we are a little bit at the mercy of the models as we’re trying to make improvements in other ways in our lives to do things productive in the world. It’s a curious set of problems that we face going forward.

Zach Leatherman: Yeah, that’s valid criticism. I don’t really feel like I have a great story for that. I feel like the other side of the coin is that some of these projects are better about maintainers removing the funds and not really telling a good story about what the funds are being used for. There’s a lot of trust that goes into donating to an open source project, and I would say that I haven’t seen too many folks cancel their Open Collective contributions… Because I do really want folks to understand that it is an investment in the longevity of the project. So I don’t consider this Netlify arrangement to be something that will probably exist for ten years. I mean, if it did, that would be awesome, but I think if we’re all honest, I don’t think that that will be a thing that will exist in ten years.

That is kind of a fallback strategy for me at this point, and I’m open to discussing it with folks if they have concerns about that. But I do feel that my mindset is changing a little bit with this new arrangement at Netlify, and I’ll probably start to use the money in a more community-organized way moving forward, as I feel more comfortable with the arrangement moving forward. It just feels so weird to me… Like, the entire thing just feels surreal and weird. And even just like the last 3-4 weeks that I’ve been doing – because I’m on my fourth week of this open source arrangement right now. Every day still just feels strange. It was a thing that I had to sneak in after hours… Like, I went from less than ten hours a week on this project to like now I’m doing 40, and I have to physically stop myself from doing more than that, so I don’t overwork… Because it’s just like – I love it so much. [laughs] I just don’t know how to… I don’t what to say too much about it, but yeah.

Ed Welch: Actually, it’s been about three years that I’ve been working on Loki now, so I’m kind of trying to think of how I’ve evolved describing it over time… This may dovetail a little bit into what Jon was saying, but… Loki I tend to describe now as the time series database for string. So I guess before I talk about Loki, the part about the metrics versus logs that I think is interesting is the information that they can contain and store - there’s an associated cost with that.

One of the things when I talk about Loki as the time series database for strings is… When we talked about that context you can put in a log line - you can put a lot of information in the log line, right? Within Loki we log for every query, the results of that query and things like throughput and the lines process per second. And the query, and the org ID, or the tenant ID, and all this information… And it tends to be extremely high cardinality. So where metrics systems - it gets a bit more costly when you’re trying to store huge amounts of cardinality. If I had a metric for every one of those things I’ve just said that had a tenant dimension on it, it would be a lot.

The other side of that coin though is that’s a long string, and to process that in a system requires parsing it, and doing math on it that’s more expensive, it’s more data stored on a disk. So to me, the two play very nicely together in the sense of metrics make a really nice roundoup or sort of overall approximation of high volumes of that kind of data. So you can look at metrics, because it’s a float, over much longer periods of time than it’s gonna take to parse a 80-byte or 200-byte string.

Where those become a bit interesting is – so with Loki we have a thing for recording rules where I can generate a metric from those log lines as they come in. So what we’ll tend to do is generate roll-ups. So we’ll generate a 99% quintile on the query times by tenant. So now maybe I have cardinality of thousands of tenants, but the 99th percentile is taking all of those individual values and rolling them up into one metric.

So the systems (I think) complement each other really well when you set them up. You can have very high resolution, very high cardinality data, it’s just gonna be a lot more expensive to try to query it over time and put those in your logs, and then you can roll that stuff up. Or create metrics, just use the metrics you have in your system for higher volume requests, being able to keep an eye on a system that’s doing thousands of requests per second a lot easier, showing that data over time a lot easier… So I think they play nicely with each other. I think maybe both extremes – I guess I could argue that you could monitor an app only with… Well, you can make that argument either direction.

[47:58] To be honest, once your apps start getting big enough, you probably want specialized tooling for those types of aspects, metrics, logs… And traces, for big distributed systems, being able to view how your information propagates through - a lot easier in a tracing system than it tends to be in searching for a trace ID amongst all your logs, and looking at how each of those logs were formatted differently, and the timestamps between them, and trying to kind of reconstruct that same view.

Tobie Langel: And as Chris was mentioning - I mean, you’ve audited the package once. Wonderful. I mean, I don’t know how your life is around maintaining open source software, but I just get pinged all the time because there’s like a dependency that I have to update, because there’s a security vulnerability somewhere… That probably doesn’t affect my project, because I’m just using a bit of it, but I don’t know… So that’s the other side of the coin, right? We have to audit every change, and we have to audit all of these changes just in time, because we actually wanna pull those patches in, because if not, we might be risking something else.

Russell Goldenberg: Yeah. I’ll start here, and then I know Caitlyn you haven’t made a story for a little bit but you definitely have in the past, so I wanna hear your thoughts, too… I think the most interesting thing to me is that every story has a different process, and that’s a great thing, in the sense that we kind of get to tell the story in the best possible way, that’s right for that story. The downside though is that you sometimes have to start from scratch every time. So we don’t have a ton in the ways of like a streamlined process; it kind of comes with both sides of the coin.

So I’d say in terms of like a story’s lifecycle, most of the time it starts with us – well, definitely starting with the question; we usually have a bunch of brainstorming phases where we just kick around ideas, and some things stick, and then someone starts looking into it… and so, we haven’t really come up with this very, I guess, rigid structure to keep things evolving. I’d say more often than not we end up having to do a lot of work in actually figuring out and compiling our own data sources. I think it’s exceedingly rare where the data is just sitting there, ready for us to pull down and start visualizing. I don’t even remember the last time that was the case for myself. Even in seemingly obvious ones, like sports stories; those ones are usually pretty straightforward, because there’s tons of data out there already… But even then – I mean, this kind of goes with anyone in the data science field… Most of the work is actually doing cleaning of the data, and like “Oh, this data isn’t as robust as I thought it was.”

[08:00] So that’s a big part of what we do. And then a lot of what we lean into is spending time creating data sets that don’t exist. I feel like our tried and true example is the story about women’s pockets. Jan and Amber created this story around pocket sizes, comparing them in men and women’s jeans… And that’s not like a readily available dataset, so they literally went into a bunch of department stores and grabbed jeans, and measured them in the back, creating their own data stores.

So we do a lot of that type of stuff, where, when I worked with Mat a few years ago creating this dataset around Ali Wong’s stand-up comedy routine. We literally watched it, had a big spreadsheet going, annotated all this stuff… Caitlyn, I think you helped out with that one, too. And yeah, we definitely do a lot more of those type of stories, where we try to come up with these interesting datasets that don’t exist. And I think people – you don’t see a lot of those out there, because it just takes so much time, and it’s like, big risk, big reward. You don’t know what you’re gonna get. And we luckily have the luxury of being able to test that out.

So that’s just the data portion. When we actually get into development, the same rule kind of applies. The only piece – actually, nothing on our site, aside from our homepage, is actually scaffolded out. Every story - there’s no CMS. Everything is made from scratch, on a per-project basis. We have some starter templates in place, which you can definitely get into… But we really heavily leaned into trying to make the development experience for whoever’s working on it something new. They have no constraints, and they can just do whatever they want.

Everything is statically hosted, so that’s really our only concern at the moment but we have had exceptions where if something needs to be bigger and have a dynamic backend, then we’ll figure out a way. So I think that’s our biggest philosophy, is “Let’s not give anyone constraints off the bat, and see where it goes.” I’ll pause there in case Caitlyn wants to jump in before we talk more tech stuff.

Amal Hussein: Yeah, totally. That was the perfect answer. I really think we should blog about that, and that should be something that we coin… Because really, using accessibility as your guide is the best way to create not just performant user experiences, but delightful ones too, for everybody. It’s a healthy North Star… So thank you so much for sharing that.

Again, this was such a – a lot to fit into an hour, maybe even a little bit more than that, but we’re excited to have had a chance to dive into this with you. Thank you so much, Brian. There’ll be lots of links in the show notes, and we’re excited that the web is continuing to evolve, and push, and question, and iterate… So we’re very privileged to be contributors to this wonderful platform. Thank you, everyone, and have a wonderful day.

Guillermo Rauch: Yeah… Obviously, I wanna preface by saying we have a pretty opinionated viewpoint, in that we create a React-based framework, Next.js. It’s obviously very popular. But at Vercel, our platform works on top of the web platform, on open standards. We let you import projects like Next.js, or any other modern frontend technology. So in that sense, we’re also not opinionated. But what we try to do with Next.js is we want to create the state of the art, from our point of view, or the art of the possible. What’s the best possible developer experience that we can give people, and what’s the best possible end user experience. From those ideas, we invest in the framework to embed them.

So from the perspective of developer experience, I think, the state of the art is clearly collaborating on top of React components; I mentioned collaborating because one of the modern trends is for companies, organizations, teams to agree on a shared toolkit, a designed system, a set of reusable components that they can build sites, applications, prototypes from, and they can do so very efficiently.

React has enabled the web platform developers to agree on a standard to encapsulate that look and feel in behavior. The best example here is we used to have templating languages, especially on monolithic server-side-first frameworks, like Ruby on Rails etc. And to a great extent, a template language can combine both HTML and CSS into reusable little functions that output strings, and then you have ways of sharing components with a certain look.

What React has done, in my mind, has been this introduction of a greater possibility of composability, especially with hooks. Now we can encapsulate look, and also behavior. We can even take hooks and share the behavior part and apply them to different components. So it’s like playing with Lego bricks that have effects; Lego bricks on steroids, so to speak.

[19:39] To me, the state of the art looks like teams that don’t just know JavaScript, HTML and CSS, they also know how to encapsulate that knowledge into reusable components. React is a platform, it’s a reality in my mind. And I mention React as a platform because React embeds things that are not very intuitive if you come from imperative JavaScript, or even other programming languages where you have to embed these concepts of purity, and there’s rules of hooks. So these shareable behavior bits that I’ve talked about - they have rules that are not necessarily rules of the language. How closures work or not work with hooks is always something that trips beginner developers in React.

So to me, the React platform is here, it’s real, it’s making people really productive, it’s making developers happy… Now, the other side of the coin is is it making users happy? Because we have all these sophisticated libraries, and you use a lot of JS, and you can render on the client side, and all these things - it doesn’t mean you have good performance. That’s where I think we’re kind of waking up a little bit from the hangover of single-page applications, huge monolithic bundles, only using client and not leveraging server-rendering and pre-rendering. That’s where a lot of the new trends over the last couple of years, one of the things that made Next.js very popular to begin with was we gave you server rendering and pre-rendering out of the box… Whereas when you used React as it came from Reactjs.org, you had to assemble it together with WebPack, and then you didn’t have any server rendering or pre-rendering capability.

The state of 2020 is we’ve gotten a lot of power, but we’re starting to use it in the ways that are really performant for end users… And the trends that are interesting to me there is somewhat of a return to the server-side rendering world, but slightly different, because with JAMstack we have server rendering at build time, which is certainly interesting if you have things that are fairly static. We have server rendering through serverless infrastructure, with Lambda functions, like how Vercel handles Next.js over site rendering… And you can combine and mix and match technologies like this to make really performant websites. That’s where there still is a battle, and Web Vitals are now coming into the equation to allow us to measure properly what performance means… Because really until 2020 we didn’t have a good idea of how do we quantify web performance. So I’m really happy that that’s also part of our future.

David Kaplan: Peer organization is one, and stakeholder communication - it’s probably two sides of the same coin. Peer organization is still a communication thing, it’s a planning thing, but - how do you get people rallied around an idea, make sure they understand it, they embody it, they own it? Stakeholder communication is the other side of that - how do you make sure that when you’re solving a problem, you’re not doing it in an ivory tower (which often happens in engineering works) and that you’re really eliciting feedback about the solution from folks around you.

In a lot of cases with engineering actually the stakeholders aren’t product; it’s actually a lot of times senior engineers on other teams, who might be affected by whatever you’re paying down, or whatever tool you’re building.

Scoping is a big one, and I actually added this later on. I think that’s the result of having done this very concertedly now for about a year.

[01:11:55.12] One thing I’ve seen trip a lot of teams up is they’ve got the great mission, they’ve got good communication, they’ve got good external communication, but they just bit off more than they could chew. Every problem you can work on for years, you can probably work on forever; it’s knowing how to really chunk it up, and if you’re doing something like 20% time, make sure you’re getting value out; something that makes you feel good and changes the organization in very small increments. So there’s a lot of framing… That’s a difficult one to work, and there’s a lot of technique that I think we can learn from product process there; things like story mapping.

And then the last one is probably the most obvious one, but it’s learning in application. This is more about self-awareness, taking feedback and being able to act on it. None of this is possible, none of these skills, without being open to feedback, without eliciting feedback, without going home and replaying events in your head a little bit, and then thinking about how you can get better.

I think once you get empowered - to your point about having that opportunity to be empowered - the next step is finding out how to progress in that competency. It’s a very complicated competency leadership, and you need to be able to get that feedback and elicit it, or else you’re never gonna progress.

Jerod Santo: Pretty much anybody who knows Nick has had “the talk”… I’m just kidding, Nick. Okay, similar topic, a little bit shifting gears - I wanna pitch this back to you; this came up in chat… When we talk about learning, investing in ourselves and our knowledge, and learning new technologies, the other side of that coin is the balance that you talked about, Divya, the life balance. That’s why so many of these new job requirements in the software ecosystem aren’t really the best, because they require a certain amount of privilege or availability that some people lack because of their life circumstances, such as “You must be doing open source in your free time”, “You have to have a good portfolio of side projects”, “If you don’t code after work, then you don’t care about software…” Well, how do you balance the two? On one side you wanna learn and invest and advance, both in your personal career as well as the community and really the ecosystem of software that we work in; on the other side, we have lives. How do you maintain that balance?

Daniel Stenberg: [03:57] So I brought it up from a completely different reason, actually. Previous to that tweet, I tweeted another image that was one of these funny things, about one of these fake O’Reilly covers from a book that says “Thanklessly maintaining open source” and a sad lama on it… You know, more of the constant mantra that is maintaining open source is a bit of a thankless job many times, and we do a lot of things… And then someone replied to me and said “Well, you got a gold medal.” [laughter] So I had to sort of show the other side of the coin really, because I think I have gotten a lot of good things from open source, and I enjoy it a lot. It’s not an ordeal or a struggle for me, it’s a pleasure and I do it for fun… So I definitely wanted to bring out some of the goodies and goodness that I experienced from working with open source.

Jerod Santo: For the sake of conversation, let me play the bear for a minute with you, Alan, because as you said, internally it was not unanimous, so no doubt you had interesting conversations with your colleagues and leadership at Wire around this. One of the major points brought up by people who were skeptical of open sourcing - I think it’s a legitimate skepticism with regard to rip-offs. Rip-offs happen, and the more successful you are, the more they can happen.

In fact, just recently I was reading about a cryptocoin wallet called Coinomi, which I think is an Android-only thing now, and I was just reading about their history a little bit (these things interest me) and they were open source, I think it was GPL-ed even, and their Android application was all open source, on GitHub, and they were doing it all in the open… Which makes a lot of sense for a crypto wallet as well, because talk about you wanted to know what the coin is doing… Similar to an encryption type of a secure chat, you wanna know what’s going on under the hood, so it made sense for them to be open source. Well, what happened was other people who were being very capitalistic, decided they were going to just take that code, rename it, rebrand it, and put it on the Android Store.

This is not an isolated incident, we see this happening over and over. The Coinomi folks stopped open sourcing, they decided it wasn’t worth it for them anymore; I believe that repo is still on GitHub, but it hasn’t been updated in a few years, and they’ve marked it as inactive, so they’ve continued to develop the codebase closed, because they had these problems.

Was this a potential reason not to open source discussed at Wire? Because surely, if everything you do is in the open, somebody could just take all of your code and all that you’re doing and rebrand it and compete with you.