Amal Hussein: [singing] “Don’t you… Forget about me.” Do we have to do copyrights for this too, if I sing it? “Don’t… Don’t… Don’t…” Just kidding. I won’t. I’ll stop now. It’s less than 25 seconds.

Jerod Santo: [01:03:58.28] Is this the right clip? Should we be doing it less, or more? Or just right? Something worth thinking about. Maybe ask you, the listener - these Kaizen episodes, do you like them less or more than all the other Ship-Its? Because if it’s a lot more - I don’t know, maybe we have to make adjustments. If it’s the same, then we just keep it as is. If it’s less, maybe we should stop doing these. I guess maybe we should Kaizen our Kaizen, and hear from the listener, and ask you if this is something we should do at the exact same rate, or more, or less. What do you all think? How can we make it better? And then we’ll know for next time.

Alexey Palazhchenko: [12:09] So essentially, it can write the whole project for you. There is a very fun video on YouTube where the guys writes a game in six minutes using Copilot. It’s basically a game where you pick a random number, and whoever chooses a number closer to the random number wins. And it just works. He types much less than he presses stop to complete the sentence. It’s just crazy. And yeah, I envision that in the future it can also write readme for your code, write Docker Compose, Kubernetes manifests, all that. Actually, I should try that with Kubernetes manifests. That would be fun to try.

Brett Cannon: Basically, up until 2016 I had never really taken any form of a break from volunteering on Python. I had been doing open source from April 2003 till 2016, more or less with no real stop. I never took more than maybe a week, and even then, with the advent of smartphones and all that, you’d stay very connected, and so much open source is done through email… It’s very easy to not ignore it and stay connected even when you’re on vacation.

In 2016 I had a couple rough interactions with some people. Basically, people just flat out had been rude to me, and in ways that I thought were incorrect for the rudeness… I mean, honestly, I’d say rudeness is just never reasonable, period, but the motivations behind the rudeness I thought were incorrect. It happened about every other week for three months straight, and… I don’t think there’s any scientific backing of this, but I’ve heard the phrase it takes ten acts of kindness to undo one negative kindness, and unfortunately, in open source there are plenty of people who are willing to say how you did something wrong, but people don’t necessarily say when you do something right. It’s very much a push versus pull; people are very much willing to push negativity towards you by saying you did something wrong, but it’s almost a pull action having to ask people to compliment you, because otherwise it’s proactive versus reactive. People are very proactive about seeing what’s not working, versus people having to very consciously be reactive to the fact that “Oh, hey, I’ve been using this thing all day and not had a single problem. I should thank someone for that.”

[24:19] So having multiple negative incidents happen consecutively, as close as they did over the three months in 2016 (that summer), my wife was noticing… She was like, “What’s wrong?”, because I’d be walking down the street, or just waiting for the bus, and get a nasty email or something - my face would just shift; she’d notice the change in my attitude and she’d be like “What’s going on?” It’s like, “I got a really bad email.” She’d be like “You just need to stop checking… Why do you still do this?”

She has luckily come to PyCon with me enough times that friends of mine have become friends of hers… If I go to PyCon without my wife, usually the second question I get after “Hello, Brett” is “Where is Andrea?” So she has subsequently come to understand it, but she very much always has pushed me to moderate my engagement level to make sure that this didn’t happen. And basically, at that point, I had never really worried about my moderation.

After three months, I just went like “You know what, I’m just starting to not wanna check my personal email. I don’t wanna check my open source email. I honestly am dreading it”, because I was waiting for something to happen. And when I realized that, it was like “Alright, this is what burnout is. This is what causes people to just rage-quit a project and stop participation.” And I didn’t want that to happen. As I said, I have friends, I enjoy my engagement, and I didn’t want to just write it off. So I thought “Okay, what do I need to do here?”

I basically decided to take the month of October in 2016 off from volunteering. Now, I was still willing to do paid time, and very much moderate where I did things, such that I could control potential areas where I knew there was potential contention. Certain mailing lists typically can get a little heated in discussion, so I ignored that almost entirely, for instance. I would still check issues, but if anyone was in any way cranky, I just ignored it and just walked away. I was like, “No, I don’t need to engage. I’m just gonna keep myself safe from being too upset.”

What I ended up doing was I spent the entire month more or less just reflecting on “How did I end up in this position? How did I end up in a place where this project and this community that I basically love was pushing me towards wanting to walk away from it?” I came to the realization that people who were being rude were typically coming from a place where they (I think) had a misunderstanding of what open source is and how it’s maintained and how it functions, and what’s required to make it function…

Because most people, when you point out that they’ve been rude, they go “Oh, I’m sorry. I really didn’t mean it” or “I’m just having a bad day” or whatever. Very rarely is it systemic and actually a core part of their personality… And I just started to think about “What needs to be said to the people and to the general open source community - and obviously Python in particular, for my case - to help people understand how open source truly functions and how people need to adjust their expectations, attitudes and views such that they don’t really ever feel like being rude by accident, more or less, and how do they make sure that they just come from a perspective of “Oh, it’s all okay” and not trigger themselves to that potential rudeness level, and just have everyone work together better?” And that’s basically what happened.

[27:43] Now I do what I call “volunteer detox” once a year, for a month, to reflect, see where things are, to make sure I recharge, give myself a chance to more or less recuperate if any negativity has built up over the year… I also try not to read emails one day every weekend, to make sure I don’t have a trigger. So I enjoy at least one day a week without any potential outside negativity that I might have to deal with.

And then my wife tries to also make sure I stick to those said plans, so that I don’t cheat and try to sneak an email checking on a Sunday, or something.

Theo Browne: [00:59:52.01] I’ve been thinking about this a lot today. The reality is I don’t spend a lot of time interacting with junior engineers right now, because my content is very much [unintelligible 01:00:00.23] PSA - if you’ve been coding for less than five years, don’t watch my videos too much. They’re just going to distract you. If you’ve been coding for less than two years, actually stop watching my videos. They’re going to hurt. I know my content, I know what it’s there for, and it isn’t there to tell people what they should be learning right now. It’s there because I’m excited about things and I want to talk about them. It doesn’t mean I’m shipping them. I try to be clear when I am and I’m not shipping things, but for me the point of this is to explore and talk about these things that are fun and exciting. It’s easy to fall in the trap of thinking you have to keep up with and learn all of these things. And my concern with AI is that you can go way further without actually learning the thing.

If you use AI to make the process of learning easier - like, when I try to deploy on CloudFlare, because CloudFlare’s docs are a master class in gaslighting your users… [laughter] It’s genuinely incredible how many lies and misconceptions they can fit into a page, that I end up in a group chat with three CloudFlare engineers, all telling me different things. All of them are wrong. It’s unbelievable. But for whatever reason, Claude has a 60% success rate with this, where CloudFlare engineers have a 20%. So it’s hard for me to use something like CloudFlare without something like AI smoothing out those rough edges. But I think the where it is in your process, and the – the biggest signal for me is if you run some code and you get an error, are you fixing the code or are you telling the AI to fix the code? If you’re a beginner and you’re telling the AI to fix the error, you’re screwed. If you’re a beginner and you copy the error you got, and you paste it into a new prompt and you’re like “Hey, I just got this error. Can you explain it to me and what it might mean?” And then you learn what that error means and you go back and you change the code yourself, now you’re using the AI to accelerate your learning, not to replace the act of learning. And that’s a subtle difference of seeing different people go one or the other way in. Are you copying the error message or are you copying the source code and throwing that into Claude? Which one you pick tends to have a very apparent effect on the way that you’re learning.

Cameron Seay: For young calves like you, out there still in the wars, that’s gotta make you real uneasy. I could care less. I’m at my last stop. This is where I’m gonna be. Well, I leave here, you’re gonna find me right here. So I’m gonna be right here. But, I mean, it’s got to be a concern. Because you don’t know – coupled with AI, and the economic stuff, it’s just a very unpredictable landscape. One doesn’t even know what skills to acquire; you don’t even know what skill set. “Can I sell this…?”

Josh Comeau: Yeah. Ultimately it was not the physiotherapist’s fault. What I’ve come to learn is that it was kind of a ticking time bomb, because I had nerve mobility issues. When you move your arms, your nerves slide around, and mine weren’t able to do that super-well.

So what happened is I essentially pulled a nerve, it got inflamed and irritated, and really annoyingly, the thing that irritated it the most was trying to type. So the posture of sitting with your arms bent in typing really irritated the nerve, to the point that within 3-4 minutes I would get this burning in my elbows, sometimes it was in my wrists…

I went to the doctor – or rather I zoomed with my doctor, because of the times we’re living in… And he said, essentially, it’s probably something called Cubital Tunnel Syndrome, which is a type of ulnar neuropathy. The idea is you have a nerve that runs from your neck to your pinkie, and that nerve is getting compressed because it’s been irritated.

[04:50] It’s essentially just a mild burning pain that progressively gets less and less mild if you don’t stop what you’re doing… So I was essentially only able to type in really short bursts. And if I tried to do that for more than like a dozen times a day, my arm would just be very unhappy with me, and the next day it would be worse.

Essentially, for a couple of months I wasn’t using computers at all. I essentially took the opportunity to just go on lots of walks, and play video games… Because for whatever reason, video games – holding a joystick wasn’t as bad. I also of course experimented with lots and lots of other remedies. I got myself a standing desk, I saw a new physiotherapist, I saw an occupational therapist, I tried a whole bunch of different antiinflamatories, I got custom splints made, a lot of different exercises… Lots of stuff. Essentially, I ran the gamut. I have three or four different ergonomic keyboards… I tried a lot of things, and none of them really helped.

Then a co-worker suggested to me “Why don’t you try coding by voice?” Of course, the initial response that I had to that was “Oh my God, that sounds awful.” Because you know, dictation in general is pretty good… Taking what you say and outputting it in English sentences, and I imagine other languages, too. But coding is a lot of syntax, and grammar, and not a lot of dictionary words. So my thinking was “Am I gonna have to literally dictate character by character?” and just how difficult is that going to be.

Jerod Santo: Yeah… There’s still some code that I read, because there’s so many optional aspects of that syntax - you know, like implicit return - and you can drop the parentheses if you want to, and this kind of stuff, which to the uninitiated, to somebody who writes JavaScript more casually – like, I’m a JavaScript sprinkles frontender, so I write JavaScript all the time, but I’m not primarily writing JavaScript, if that makes any sense. When I revisit this thing, or when I’m reading somebody else’s code who has different levels – like, they’ll use different levels of syntax. It’s still foreign to me. I’ll have to stop, and it makes it less readable. I think if you’re super-initiated, it becomes more readable. But for the casual author, it’s like “What’s going on here?” because there’s so much optionality in that syntax.

Feross Aboukhadijeh: Yeah, so there’s a C library that can play back midis, it’s called libTiMidity. I think you can even install it on Homebrew if you’re on a Mac. So you get this command line program called TiMidity, and you can pass it an argument that’s the midi file you wanna play, and then it’ll play it. It sounds pretty good. You’ve gotta give it an instrument pack, so that it can play it back.

Then I found the library version of that, which takes in the midi file and the instruments and produces a WAVE sound as output. And I was like, okay, I need to compile this to WebAssembly… Which I had never done before, because I’d never had really a need to use WebAssembly or Emscripten, if anything… For whatever reason, it’s just not something I ever needed to do, until now.

One of the main things – a lot of people talk about how it’s for performance, and that’s certainly a thing that it’s good at… A lot of people talk about how it let them finally stop writing JavaScript, which is less true than they think, because I think we’re still gonna need JavaScript for a long time… But the main thing that I think makes it cool is that you can take code written in other languages, like C, that you don’t wanna have to port to JavaScript, and just be like “Okay, now it runs in the browser.” That’s the aspect of it that I liked a lot.

Jerod Santo: [00:07:43.09] Writing and [unintelligible 00:07:44.05] And he just thought that we would lose our brains. Like, we would stop being able to remember things. And I recall when programmable phones were picking up, and you no longer had to memorize people’s phone numbers. And there were some folks who were kind of offended by that… Because there was a social dynamic to like whose numbers do you have memorized? It kind of shows who’s important to you in your life. And there’s certain people like, “I’m just going to remember your phone number.” And 10 years later, they’re all off that. They’re all done. It’s over with.

Monty Widenius: What we have now, we have MaxScale, which is a really good proxy, that can also be able to do failover and other things, but also gives you more control over using MariaDB especially in larger environments, and we have licensed under something we called Business Source License. This was a license that me and David Axmark, the other founder of MySQL, came up with some ten years ago. And then we started to make it more popular, because I see a lot of companies struggling with that. They would love to do open source, they see the benefit of it, but they are afraid that if they will become open source, they will lose all the revenue, the customers would stop paying them, and that causes a problem, a conflict - you want to do the right thing, but you can’t, and the Business Source License was invented to solve exactly this thing, to allow more people to do eventually open source, and also give the users of the software many of the freedoms that you expect with open source software. So it’s not an open source license, but it’s an “eventually open source” license, and within four years it’s guaranteed that the code that you have is open source, but you had all the code from the start, so you get the benefits that if there are bugs, you can fix it, if you want to add something, you can do that… You still have to pay for it, like with any closed source software - or commercial software, actually - but you still have the freedom that you are not held by the one company who can do any changes, or just go out of business or stop producing the software.

Michael Knyszek: Okay, fair enough. But goroutines basically before Go 1.14 could only stop executing, or like be asked to stop executing by the garbage collector at the start of a function. Like, when a goroutine entered a function, and when it blocked on a channel, or… There was like a whole bunch of situations where it would yield its time. And this would cause latency issues in a lot of applications. If say one goroutine didn’t call a function for a runtime - let’s say it was just like encoding or decoding some really big thing, and it would just be in this tight loop, doing like arithmetic, and nothing could stop it. So the work to make it possible to stop a goroutine, basically at any time, was largely – the problems that it was solving was very much visible in an execution trace. And I think at the time, Austin was the TL of the Go compiler runtime team. They used the execution trace view to sort of visualize that “Hey, this isn’t actually just a latency problem, this is a throughput problem.” And you could see that this one goroutine was executing, the garbage collector was trying to stop all Goroutines, and it stopped all of them except one. And so what that basically meant was that if you had – like, if your application was normally going along happily at, say, 16 cores, there was a period of time, maybe even milliseconds, where only one core was actually doing any useful work. And that’s not just a latency problem, adding milliseconds of latency to basically everything that’s happening at that point, but it’s also a throughput problem, because nothing else is executing. And that was super – I think the visualization in the execution trace was incredibly powerful to display that particular problem and to motivate fixing it.

Anthony Eden: Oh, yeah. And imagine, none of what we do is possible. Everything would stop.

Matteo Collina: Pretty much. The other point is implementing a graceful shutdown pattern. It’s very important for your application, most of the time, unless you specifically don’t want to do that. But I will not get into that case. So when an error happens, and is not caught, it will crash your system. It will crash your Node server. Now, what you want to do - you want to try to land as gracefully as possible, which means typically stop accepting new connections, stop accepting new requests, process what you have in flight, and then –

Daniel Thompson: Oh, gosh. Well, we’ve been working on it for just over three years now, since May… And it goes back to a different open source project that I was involved in. My friends and I, we were working on a project called Quasar, which is a Vue.js system for building websites and SPAs and SSR apps and Electron apps and Cordova apps. And I was always kind of interested in outreach and getting into other ecosystems, and I reached out to the wonderful people over at Purism.

[08:23] They make this PureOS open source-conform system. I mean, the company is following these ideas of open source, and the products are following these ideas… And I thought, “Well, hey, maybe I can stop over there and ask if it’s possible for us to figure out a way to work together and we start putting some of these Quasar apps on their app store. And they’re like “Oh, cool, that’s awesome. So how are they made?” And I was like “Well, you know, we use Vue.js and Electron” and they’re like “Whoa… We can’t. Here’s a long thread over at the FSF, and read through about un-Googled Chromium, and why some header files aren’t appropriate…” And I was like “Okay…” So three days later, and miles of threads later, it was kind of clear that what I thought open source was wasn’t always what open source really was. And just saying that something is open source and putting it on GitHub, doesn’t mean it really fulfills the needs of the FLOSS community, right? I guess the difference between free/libre open source software and open source software, and open core software - everyone’s kind of has these different feelings about how you enable other people to use your code. And at any rate, and as fate would have it kind of dejected, a couple of days later a really good friend said, “Hey, did you check out the WebView library?” And I was like, “Okay, well, fine. I’ll go look at it.” And this was like a combination of projects. There was a developer named ZSerge, who wrote a bunch of C and Objective-C bindings for the platform-specific web views on Windows, Mac, and Linux. And then we found a Rust port.

So we did a first practice, Lucas and, with Go. I think I did the first C example, and then Lucas did Go, and we’re both like “This isn’t really nice.” And then we found the Rust library. The Rust library kind of helped us, and allowed us to get to a kind of proof of concept really quickly. And what we were seeing was kind of this, like “Daniel?” Lucas said, “Is this right? The app is only two megabytes.” And we’ve been using Electron apps, and are used to things weighing 600-700 megabytes and then download. And okay, it was it was just a dot app. It wasn’t like all of the crazy MSI installers and DMGs. And don’t get me started on the Linuxes, but… It was kind of tangible and real. And we were both really new to Rust. Totally unaware of the complexities of the stuff we were getting ourselves into… And we had these proof of concepts, we got it working on Mac, and we got it working on Linux, and we got it working on Windows, and that’s kind of the time when I think we got slashdotted. No, we got hacker-newsed first. And it was kind of this almost raging, how dare you not ship Chromium?! And it was interesting, because it kind of gave us an uptick, and it gave us some visibility to the larger community… And then just one after the other, these amazing people joined us, who really believed in “Yeah, we can make it more energy-efficient, we can make it more secure, and we can really follow in these open source ideals and do our best and stay transparent and accountable.”

[12:27] And you know, things went pretty well. We got further and further, and then boom, COVID happened. And I think, for those of us who were around and active in software, and especially open source, it kind of got to be – I don’t know, I mean… I know personally I had just this crazy experience of not knowing when to stop, and that kind of led to this weird COVID burnout, and we’re all just like “Oh my gosh, alright, so the world’s ending, let’s go have a barbecue.” And you know, things kind of got back on track, and then the investors started ringing the doorbell, and the venture capitalists, who will remain unnamed… I don’t think there’s anything wrong with open source software becoming commercialized, but it scared me, because I’ve been working in open source projects for almost two decades, and I didn’t want this project to become corrupted by some kind of capital that starts dictating the direction it has to take. We kind of ghosted the first VCs to call us, and went into overdrive and registered Tauri as a program within the Commons Conservancy, which is a Dutch organization around NLnet, that really exists to support open source projects and protect them, and especially to protect the code and to protect the community. I mean, we’ve all heard of bus factor, but I think that the ability for money to corrupt ideas such that the original vision gets lost… I mean, I’m not saying that’s the kind of militarization of open source that I’m most worried about… But for our project, we really wanted to keep it in the hands of the community. And I think that that was really the right decision at the time, because as time went on, we got really close. We built our betas, and then we decided to get audited, which is a little silly… I mean, who are we are…? It’s just some friends and an open source project, and then we got some grant funding, and we took our donations together… And we had an external horizontal audit of all of the libraries, and a vertical audit of an example app… And I have to tell you, if you’ve never had your code audited, it can be scary, but I think what we all learn from the experience is that it’s really exciting when your presumptions are challenged, and you get to a point where you realize through the help of the external pen testers or auditors or code reviewers, or whatever it is you want to call them, that you can actually continue to make your thing better.

And we obviously published the finding after we did six months of work, rebuilding the parts that were problematic… And yeah, now here we are, a couple of weeks post 1.0 launch, and it’s so exciting to see the gravitas of the future in the team. Because you know, up till now, we – we do have a change log that we implemented in probably the first six months, so that we can maintain the history of what we’ve built… But now you have other concerns, like what parts do we have to audit next? And what is our release strategy going to be? How are we going to branch this? And it’s really exciting to see the working group come together.

Derek Parker: So in the case of a probe attached to a function or something like that, it’s blocking. For that moment of time, the execution of the program that invoked or triggered the probe will be stopped, so that the eBPF program can do any kind of inspection that it needs… Which is also why, for the context of tracing - this is what got me interested in eBPF, was the combination of the two last subjects we were talking about, which is the overhead of system calls, and just the overhead of tracing in general.

A similar thing would happen – so the reason why I got interested in it was because I wanted to make Delve’s tracing backend more performant, have less overhead, so that maybe you could use it in a production context if you wanted to.

I did a tweet a while back, when I first started working on it, of like the overhead added. I had a program that ran in some odd number of microseconds… And then with eBPF-based tracing on top of it, it went from maybe like 20 microseconds to 300-400 microseconds, or something like that… Which sounds like a significant amount of overhead, but we’re talking microseconds.

And then I timed it using the ptrace-based tracing that Delve had been using prior, and it bumped up to like 2.3 seconds. So you go from microseconds to actual seconds, which is like – you can’t have that kind of overhead if you’re tracing something in production. So that was kind of what got me interested in it, having these really small, targeted programs that can be called as a result of something, that don’t do context-switching between kernel and user space, and stop the program for as little time as possible, and really get kind of performant, detailed, but also ad-hoc tracing.

[16:01] The other difficult thing was making it ad-hoc. So a lot of times when people write eBPF programs, they’re very, very targeted. You already know when you’re writing the function what corresponding function it’s gonna be attached to; what kernel function, or whatever… You generally already know; so you kind of know the arguments to expect, and things like that. But in the case of Delve, and what I was doing with eBPF, I was kind of abusing it a little bit to try to do just – I wanna attach this probe to a completely arbitrary function, where I don’t know how many arguments or return arguments it has. I know nothing about it, but I wanna get all the information out of it. How do I do that?

So that opened up a lot of questions of how to write a generic eBPF program, and how to communicate between that program and Delve, communicate between the kernel space and the user space, in a way that also won’t introduce back the slowness that I was trying to get rid of.

Fred K. Schott: Yeah, this all started about two years ago, just taking a look at the ecosystem as a whole; it’s one of those things where everyone is acting in their best interest, so consumer of packages on npm - they just want it to work in their system; publishers of packages - they want it to work on as many user systems as they can. And what this means is that everyone just ends up pushing the status quo forward.

It’s very hard to actually see when you kind of pull the covers up and look under the ecosystem, what’s going on. Actually, things don’t really change that often, which - for good reason; but that also means that a lot of people - for example when they’re publishing a package - will compile it down and downgrade it to work on the latest possible version of Node. And maybe they will stop maintaining that package, so then it’s forever pinned at, you know, all these different Babel transpiler bloat, to get async/await working on Node… It ends up actually looking a lot hairier than it does above the surface, where these things all just kind of work, and they all just kind of work because we have these very powerful tools, like Webpack and Rollup, that allow for them to work on the web, and then everyone’s looking out for Node in their own way.

[04:29] So this project was started to see what you could do about that. Obviously, that’s a big - as you said - ambitious goal; I’m not trying to change the world in one day, but if there were little things we could do…

As of today, there are three different projects. The first is just the website. Pikapkg.com, the very first thing I did was create a place to search for ES modules… ES modules being these modern packages that actually do run on the web, in certain scenarios, or at least are much more modern; they’re focused on the web. Generally, there’s not as much risk of transpiler bloat when the target itself is more modern.

And then other projects as well that I can get into, to then work with those and publish them… But it all kind of came out of this, “What are the little things we could do to start building what would be a more modern ecosystem?” The mission statement of the project is to make modern JavaScript more accessible, making it easier to find these packages, to publish them, to install them, and then really to use them.

Mat Ryer: You can’t stop Johnny doing links. Johnny’s gonna link. If there’s a possible way, yeah. Johnny gonna link.

Kevin Ball: Okay, so I guess that makes it my turn. I love that y’all are talking about confusion. This reminds me a lot of refactoring code that already works, because it’s confusing… And sometimes that’s the right thing to do, and sometimes it just creates a lot more confusion. So JavaScript - yes, the name is non-ideal. Yes, it confuses recruiters. So does every other distinction in the programming world. How many of you have gotten the “Hey, long-time freelance we developer, would you be interested in this salaried embedded programming position using C++ in India?”

I mean, recruiters are always gonna be confused. But if you wanna confuse people, try renaming the most widely-used language in the world. Have you ever tried changing the name of a widely-used piece of code? Now try it again without Find and Replace. Try it again in over one million public packages, downloaded over a billion times a day into who knows how many private applications and packages. This is not gonna reduce confusion, folks. This is gonna ramp confusion up to 11.

[15:58] Not even thinking about the code, what about documentation and past articles? How many millions of articles are already talking about JavaScript? Now every new developer of WebScript, or EichScript, or whatever the heck you wanna call is gonna have to not only look for things in that, but also understand that these other things talking about JavaScript have relevance to them. They’re not gonna replace the knowledge, we’re just adding onto the stack with something more and more confusing for new people coming into the industry.

Every one of those recruiters is gonna talk to you “Oh, you have JavaScript experience. Well, we’re looking for WebScript, so you’re clearly not applicable.” This is not gonna make anything better. So I would close with a Haiku… [laughter] Because you all make it possible. “Should we rebrand it? D’oh, JavaScript is just fine. Stop navel-gazing.”

Chris Benson: Yeah, “That’s a bad thing, and I’m sorry to hear that happen”, but they kind of move on. And then there are other stories where they kind of get very emotional about it. My suspicion is that should such a story in the future evolve where it was AI-driven, that would get to a whole new level of that. And I think the interesting thing for me, psychologically, is the fact that in all cases, it was the same loss of life. But the way we choose to react to it can vary. So it’s just an interesting psychological point from my standpoint… I don’t think it would stop AI, but I do think such an event would create a lot of pause.

Gerhard Lazu: This first hop I think is really important, and the first hop will be from your router to the gateway, wherever that may be. On Vodafone, this used to be 8-9 milliseconds. So you mentioned sub-millisecond - I would love to have that. And while I don’t have that with Vodafone, what happened recently is it went down to about five milliseconds, three milliseconds… Actually, it was 3-4 milliseconds, it fluctuates, but it’s twice as good as it used to be. So that is a good improvement.

Now, Trunk Networks is my secondary ISP, and I can switch between the two. Currently, my setup is configured so that I disable one, and then the other one, even though it’s live, the routing only uses one of the gateways. So when I disable the primary, the Vodafone, I fall back to the secondary. And even then, my first hop is five milliseconds. So the quickest that my gateway is – so that’s like my starting point, whether it’s DNS after that when I go to Google’s DNS, or Cloudflare’s DNS, or OpenDNS, it will be on top of those 4-5 milliseconds in this case. And that’s still good. If it’s over 10 milliseconds, I think that’s when you start feeling it. And it’s not only that, like when it starts fluctuating. So from that perspective, 5 milliseconds as a starting point - great. It’s when it gets higher than that when it’s bad. And when you have packet loss, it’s even worse.

[40:11] So one problem which I have - and I hope that you’ll be able to explain to me why that is - is when I switch from one ISP to another one. So when I disable one of the connections, there’s like a maybe 20-30 seconds period, as if the existing connection stopped working. And TCP connections - new ones are okay, but existing ones stop working. Why is that?

Jesse Dodge: Yeah, I’ll talk a little bit about this. One thing that I’ve mentioned already was performance efficiency trade-offs, and I think that the key idea here, and one thing that we’ve found when we did this survey that Roy mentioned, of papers in our field, is that most papers just don’t report anything. They don’t report any efficiency-related metrics at all. Most papers in our field invent some new model, or some new loss function, some new training scheme, something like that, and then claim in a table “Here is our better performance. We beat our baselines.” But they don’t report, for example, training curves, or some other measure where you can trade off efficiency and performance. Maybe accuracy could be one measure of performance.

[35:56] So an example of this – and I guess the first thing that I would say here is what we hope everyone in the research community starts to do (and we are seeing this happen now) is just report something; report some measure of how… Maybe it’s going to be the floating-point operations to run your mode. Maybe it’s gonna be a training curve. Maybe it’s gonna be the results from your hyperparameter optimization search.

One example of this I can point to is a paper - and I use this as a positive example of how somebody can report this kind of information. So Roy and I wrote a paper that used early stopping… So we partway-processed an example, and then potentially had our model stop early. So instead of feeding the example all the way through our model, and then coming up with a prediction at the end, we had ways for our model to stop this computation early and make a decision quickly. And this method allowed us to show performance efficiency trade-offs, these smooth curves, which anyone can then compare against at any point.

And what I would hope to see is other work come along and show a better curve, rather than just a single point on this performance efficiency trade-off; they can report just “Here’s how efficient my model was, and here’s the performance”, potentially beating our entire curve, or just a single point better along one of those dimensions. In this way, just reporting more information allows others to compete along either of those dimensions, or potentially draw a better curve.

Adam Stacoviak: You know, I think it remains to be seen, but it seems clear that change is coming. What that change is, we may not know. If they can promise to the other bigger players who may have concerns and stop using GitHub, which may change the ecosystem and social network that it has become for programmers and software developers and anybody making software, change is gonna happen, we’re just not sure how that change is gonna take place.

The other thing to consider is the viability of GitHub. You alluded to their revenue and run rate, and loss, and things like that… Obviously, they’re a business; it’s not just this happy place, free code gets hosted, and somehow magically it does. Bills get paid, money has to get made, it’s a business.

The next step for GitHub to become the GitHub that needs to be there for the next 10 years to keep that going needs to be a GitHub that can go through either, dare I say, an ICO or an IPO, right? ICOs are interesting new ways to fund things through cryptocurrencies; there’s been a lot of speculation around that… Or an ICO, which is not easy. Either of those are not easy. So you either get a new valuation, more funding just to keep trying to make more, or you eventually become a GitHub that competes with Microsoft, Google, Amazon, Facebook… Maybe not Facebook, because they don’t have cloud, but the other three do. So you start to compete with them. Do you wanna do that, or you do you wanna get bought by one of them? It’s a tough road.

Drew Wilson: Yeah. For me, it was like a – the decisioning was “Well, if I stop Letter now, it’s going to take me four years to get to the point with any other company where I’m at right now with Letter, so I may as well just keep funneling my cash into this thing, and try to make it work, since we’ve already gotten so far.” And that was kind of the reasoning behind it. Had Letter worked out, everyone would have said “That would have been the greatest decision you ever made. That was the best investment you ever made, Drew.” But if it doesn’t work out, they’re like “You probably should have cut your losses earlier.” [laughs] How do you know in the moment? You don’t. And so sometimes you win, sometimes you lose. Actually, let me rephrase that… You always lose, and then sometimes you win. [laughs] You’re usually losing, and then sometimes you win. So yeah, it makes the wins all the more sweeter when they happen.

Adam Stacoviak: [39:54] Well, there is Netflix, there is Apple TV, and there’s other things you can stream from. I choose Plex because I just prefer it – well, I mean, if for some reason culture doesn’t care for this movie anymore, Netflix didn’t stop serving it, and now I no longer have access to it. Or just not having to leverage the cloud so much. Just not having to put that kind of pressure on the backbone of humanity, really. At some point, it’s gonna be a bigger deal. If I own these discs, or if I don’t mind owning these disks… It also blocks out commercials for my kids. There’s all sorts of reasons why people choose to use Plex. I also happen to be a home theater geek, so in my home I have a 120-inch screen, a laser projector, THX speakers in the wall because I’m just crazy like that… Because I really appreciate movies. And so for me, it’s like, I don’t want to change discs anymore. I don’t want to have to keep a rack of blurays, 4k blurays, whatever, pick your flavor, and have to go swap them out. I’d rather just - give me a lossless version of it, that’s on my network, that gets served wherever I want, whether it’s a restaurant for my children, because they want to do something while we’re sitting there waiting for food or whatever, or we’re are on a trip or something like that… We also have a travel trailer RV… So we will stream Plex from our home in our RV. We don’t have to take all those discs with us. There’s so many reasons why people choose it, and that’s what’s important to me and my family. Not everybody really cares about movies and access to their media library. I do. And I built this beefier service so I can make sure I can do it anywhere.

Adam Stacoviak: That’s okay, too. I mean, we all have different ways we look at things. Clearly, you’ve been successful, so it’s working, Evan. Don’t stop. But as a position of encouragement, I would just say - you obviously see this, but for some reason, I’ve gotten some really good benefit in slowing down enough to celebrate the wins… Because you can just get so bogged down in the go-go-go, or the seemingly losses, even though they were wins, because you can’t really see the details of them… There’s just a lot of value I’ve personally seen in that, so anytime I get a chance to advocate it, I like to do so.

Duane O’Brien: [52:04] Yeah… That’s not a metaphor of the entire FOSS Responders group, it’s just the way that I’ve explained it to people… Like, why is it important to support these events? Because this is where our community gathers. And we want them to be able to gather at these places the next year. And some of the events won’t survive, and that’s kind of the nature of things, but we want as many of them to be around here for us and for the community next year as we can.

This was also an intentional choice to not try to address with everything that could possibly be addressed within the open source community in response to Covid-19. There’s so much work that’s being done there, between open source ventilator designs that are going around, and open data projects that are going around, and the MOSS Fund folks announcing their initiative to provide seed grants for open source projects that are doing work in this area… There’s a lot of different kinds of work that are being done. We wanted to focus our effort on this particular area, and really prioritize support for people who might otherwise fall through the cracks of the support system. So I’m much more interested in seeing us supporting that meetup organizers who’s out a couple thousand dollars, or that small regional conference organizers who is out a few thousand dollars, because they’re the folks that are gonna take it on the chin. But there’s a range of impacts.

The Python Software Foundation, when they canceled PyCon, announced in a blog post “This is what we’re gonna have to pull out of our reserves in order to make up the losses”, and it was hundreds of thousands of dollars. And if they have to shift focus away from infrastructure, maintenance and improvements and stop working on improvements to PyPI and focus on fundraising instead, that means we’re not getting the work done on PyPI that we all need as a community.

So it’s a big problem. We’re still getting our collective hands around how big the impact was on these conference and event organizers, and as well the individuals who were out of pocket going to these events who weren’t able to get refunds either from the hotel or from the conference.

Most of us who travel for work, our work folks cover that for us, but… If you were a designer who was going there to meet clients, or a bootcamp graduate who was going to one of these events out-of-pocket to try and secure your next job, the impact is felt much more significantly.