#397: Evaluating New Open Source Tech Panel Transcript

00:00 The beauty of open source software and libraries is that you're not stuck with a single option

00:04 some vendors offering. This is especially true.

00:07 When that support is poor and antiquated.

00:10 Almost any capability you can think of.

00:12 Has multiple options, even for a single language such as Python. Just think about how many web frameworks you can pick from today.

00:20 But therein lies a new problem. If there are ten options, how do you choose? Do you go for the oldest and potentially most stable? How about the most up to date one? Maybe the hot new version that has the fastest adoption curve is the right one for you?

00:35 It's not easy, but luckily we have an excellent panel here to discuss exactly that.

00:39 You'll hear from Emily Morehouse, Cecil Phillip, kim van Wyk, Lukash Langa, Gareth Thomas and Dan Gerlanc.

00:46 This is talk Python to me.

00:47 Episode 397 recorded december 7, 2022.

01:04 Welcome.

01:05 To Talk Python to me. A weekly podcast on Python. This is your host, Michael Kennedy. Follow me on Mastodon, where I am@mkennedy, and follow the podcast using @talkpython, both on Mastodon.org. Be careful with impersonating accounts on other instances.

01:20 There are many. Keep up with the show and listen.

01:22 To over seven years of past episodes at Talkpython FM. We've started streaming most of our episodes live on YouTube.

01:30 Subscribe to our YouTube channel over at.

01:32 Talkpython.FM/YouTube to get notified about upcoming shows and be part of that episode. This episode is brought to you by Cox Automotive. Use your technical skills to transform the way the world buys, sells, and owns cars at Talkpython.FM/Cox and by Sentry.

01:49 Don't let those errors go unnoticed.

01:50 Use Sentry. Get started at Talkpython.Fm/sentry. Transcripts for this episode are sponsored by AssemblyAI, the API platform for state of the art AI models that automatically transcribe and understand audio data at a large scale. To learn more, visit talkpython. FM/AssemblyAI. Hey, all.

02:11 Welcome to talk python me, Gareth, Kim, Lucash, Cecil, Emily and Dan. We got a bunch of you here, and I'm so excited to have you all on the show.

02:19 Thanks for being here.

02:20 Interesting.

02:20 Yeah, I'm excited, man. We have a nice little party going on.

02:23 Yeah, we do. We definitely do.

02:26 Yeah.

02:26 So I'm really excited to talk about choosing technology, choosing libraries for programming, or maybe a database that we might use for a project.

02:35 We have this paradox of choice type of problem, especially in the Python space. I haven't even looked. Are we over 400,000 packages on PyPI? There's many, right?

02:46 We are over 14 terabytes of storage on PyPI that I know.

02:51 Oh, my goodness.

02:54 It's mostly machine learning, but again, there's a lot of packages.

02:58 Yeah, there's definitely a lot of packages. Okay, well, how do you pick? How do you go to that list and say, I'm going to search for a web framework, and look, there's 100 results. How do I pick or I'm going to find a way to talk to a database. What database should it be? So that's going to be our topic for the show today, and let's just start real quick with the elevator pitch of who you are and your background.

03:24 30 seconds or less. We'll go around the Brady Bunch squares here. Gareth.

03:29 Hi, I'm Gareth. I've been programming for probably 40 years, I guess, and now because I started when I was about three on a Dragon 64, but it was only recently I got into Python.

03:39 Really?

03:40 When I took up a job as a CTO of a company that did everything in Python and haven't looked back. And now I'm doing CTO stuff all the time.

03:47 Fantastic. I think CTO positions are very much in this role. You got to settle a little bit of guidance for the company and the teams, right?

03:57 Yes. I don't get to do code anymore. I just get to watch people write code.

04:01 You just get to make decisions for them and watch whether they enjoy or don't enjoy it. Kim, welcome back.

04:07 Thanks. I must be roughly the same age as Gareth, but I had been writing code for probably about 25 years because I couldn't start when I was three. Professionally. I've been doing some Python, some C, some otherwise, for 20 odd years, writing software for embedded systems, doing DevOps work, and at the moment, doing engineering work with site guests in the American sense you would call a mortgage provider in South Africa. My current employer.

04:30 Yeah. Fantastic. Lucas, welcome back.

04:32 Hi. I'm the core developer in residence for CPython. So actually getting money from the Python solution to help develop Python. Just yesterday, we released six simultaneous versions of Python at the same time, which I think is a record.

04:47 So I mostly do that item program for 40 years. I'm 37 at the moment, still maintaining 37 because my my birthday is March, so, like, approaching quickly, but, you know.

04:58 Don'T let 38 get you.

04:59 Yes, I'm not almost 40. I'm 37, you know.

05:03 Awesome. Well, congratulations on all the great work. I know you've done a ton of work to keep CPython moving forward.

05:10 Yeah, thank you. There seems to be, like, more and more to do, actually. So just looking at 311, one that we released yesterday, it had, like, almost 500 Comments since 3110, which is kind of unprecedented as a rate of change. So we have so much kind of velocity right now that I have never seen before. So a lot of team.

05:31 Amazing. I talked to Ned Batch Elder on another podcast that we were doing, come out for this one, and we looked the change log for CPython is 175,000 words. A typical novel is 80,000. So that's a lot. That's nuts. Cecil, always good to have you on the show. Welcome back.

05:50 Sure. Thanks for having me. Hey, everyone. I'm Cecil Phillips, developer advocate of Stripe. I will not tell you how old I am, but I will tell you that my programming grid beard is just starting to come in, so not fully there yet, but I'm still working on it. Primarily. been doing a lot of net stuff. Some python stuff. Recently started playing around with Go. Maybe we'll talk about that in the midst of this conversation as well. But other than that, as an advocate, I spent a lot of time doing video and going to conferences and doing demos and stuff. So I kind of feel like my job is to learn stuff to an extent. I mean, there's a lot of that that happens. And yeah, I kind of have a lot of fun doing it, both for work and outside of work.

06:27 Yeah, that sounds like a great job. Emily. Welcome back.

06:30 Hi There. I'm Emily Moorehouse. I'm the Director of Engineering at a company called Cuddlesoft. We are a kind of digital product consultancy, focusing on user experience for full stack applications. But we also get into some of the nitty gritty stuff. So we kind of do that. Full spectrum. DevOps firmware middleware development. Web applications all the way through design. So I get to touch a lot of different pieces of technology. A lot of my work is in Python, but not all of it. I write a lot of Ruby, a lot of JavaScript kind of across the spectrum. So I get to kind of see how different ecosystems handle open source, which is really interesting because I feel like the JavaScript world is very different Python world than the review world and kind of down that stack.

07:18 So this topic is right down, right near your wheelhouse. And I think also the consulting side, the agency side is interesting because you work with one group and say, here's what we recommend for you. Oh, another group has another company, has a different set of software skills, so you might recommend something different in that case. Right.

07:37 Yeah, Absolutely. And the technical expertise that our clients come with is very wide reaching. Right. So some people are completely non technical. Don't want to touch it, don't want to know anything about it. To very technical teams where we're kind of coming in as a specific partner on a specific piece of their tech that they are eventually going to take over. And there's a lot more kind of risk management for this, right? Like we can't build something for a client, but then we're going to say your library isn't supported in six months. So it also gives us a chance to start fresh a lot. Right? Most of our projects are greenfield. So we do get to say, hey, look like we've been doing our due diligence on this new framework or this new library or whatever it is. And we think that this is a really good place for you to be and get a chance to actually build something with a new library. More so than, like, convincing a company to rewrite their Django application. And something else.

08:32 Right. You also were the chair. PyCon. Is that the right title?

08:37 Yeah. I forgot to mention that I'm the recovering Chair chair Emeritus now.

08:43 Yeah.

08:44 Support group somewhere.

08:46 Sure there is not overseeing 2023, are you?

08:49 No, just get to it. Taking a break.

08:52 Fantastic. All right, well, thanks for that, Dan. Welcome to the show.

08:56 Thanks. I'm Dan Gerlank. I've been doing software development professionally for 20 years, to some degree more in one capacity or another. I'm currently the Director of Engineering for the Data Science and ML engineering team at Ampersand, which probably the simplest way to think of it is kind of like a brokerage for television advertising.

09:23 Prior to that, I actually ran my own consulting shop for a decent amount of time. So I've worked on that agency side a bit and also started my career in quant finance. So I went across a wide range of things, and I'm pretty involved with the Asara project these days on the open source side, and also do a bit of teaching on the side. I've taught on O'Reilly about Pandas and different things from time to time.

09:54 Teaching is always a great way to kind of learn these technologies a little bit deeper as well.

09:58 For sure. Then you definitely learn it for real when you go out to teach it.

10:04 The fear of having to stand in front of a bunch of people and not know the answer motivating you.

10:11 I guess conference speaking kind of works that way, but it's not as not as back and forth as well. All right, so let's kick off this conversation with maybe a story from some of you. So I wanted to start with just maybe a story how you've chosen some tech stack or some database or some new framework.

10:32 A lot of leeway and the scope there, but whoever wants to jump in, just give us a story, something you've sort of gone down that path recently.

10:40 Well, I'll jump in and talk a little bit about the strategy of how I choose to learn stuff. And I think it's important that you have a learning or a choice strategy, at least for me, because there's just so much stuff to play with and there's only so many hours in the day. And so you always have to be surgical with your time about what you choose to do. And so one of the things for me is, like, I don't build production applications, and I think that's an important thing to know. So everyone else's perspective might be a little bit different, but most of the apps that I'm building, I'm beta testing stuff, I'm creating things for other folks, doing proof of concepts with companies and stuff like that. So now when you think about the things that I have to learn, I usually have to learn things to get it to work for a little bit, and then I'll walk away and I'll go do something else. I don't learn it with the perspective of I have to maintain it over a long period of time. Now, that is not important that I do it the right way, but again, the perspective is just a little bit different. So for me, one of the things that I often try to do is try to find the thing that I'm really interested in doing, the thing that will be useful at work and try and plug those things together and try and see if we can find some symmetry there. And so an example would be like one of the things I'm playing with right now is open telemetry. Right now, I don't work for an open telemetry company, and that's not a thing that we have libraries or extensions for. But at the same time, too, we think about as we're building apps. Inspection is an important thing, right? And being able to give folks guidance is an important thing. And so when people come to me as an advocate and ask questions, I might not have to know everything in detail, but I try and know things enough so that I can at least have an opinion and have a conversation about it, be able to speak intelligently about it, even though I might not know all the knobs and whistles and vowels I have to turn to get the thing to work.

12:26 One of the things that I think would be really important for that role is really carefully tracking where's the momentum in frameworks. Maybe it's not the most important or wide, widely used thing at the moment, but in six months, you know, a little bit of the Gretzky quote, where is this thing going and what is the advice you're going to give to people?

12:45 Yeah, I agree with that. And that also, again, kind of goes into the strategy of what am I learning this thing for? You know what I mean?

12:54 Again, am I learning it specifically to achieve a particular personal goal? Is there something that I'm trying to fix? Am I joined? Am I trying to explore technology so I could pick and choose the thing that I want to do? What exactly am I learning this thing for? Am I learning it to teach it to someone else? Right. No, that's a completely different perspective as you're trying to figure out, well, how do I kind of zone into the thing that I'm trying to do?

13:15 Excellent.

13:16 Yeah, I think from that, that's something to what Cecil was saying there. One of the important things that you pointed out that you often end up doing is maybe helping people select a framework or a piece of tech stack or something to use. And the kind of thing that always that used to strike a lot of the teams I've worked on, and I certainly was guilty as anybody else is, spending a heck of a lot of time going back and forth. Thinking, well, we could use this one, or we could use this one and let's try this one, and we'll take three days to try this one, and then next week, we'll take three days to try that one. And ultimately, if somebody's paying you to write software, it's kind of an important listen to remember that ultimately you have to pick something and it'll be good enough. Your job isn't actually to pick the right thing and spend a month on it. There are other things they're paying you to do. So one of the important things to feed into tick stacks lectures is basically if it's good enough, that's fine. If it's not good enough, then obviously it must go. And it's useful to have somebody like Cecil to be able to tell you if it's good enough. But we can make the mistake seeking out kind of perfect is there anything wrong with us? And I will use it on let's find that one and stick to maybe it would be better. And three weeks later and they're saying to you, why haven't you made the deadline? But we have the perfect tool that's used the jet. It's taken us a month to find that we have the perfect tool. Now it's an easy trap to fall into.

14:22 It is, and I think a lot of people probably fall into it. And you got to decide, is this a one way door or a two way door? Is it the gate at the exit of the airport? If I make this choice, how committed am I to this thing? Because if you try it for a week and it's not what you thought it would, you could come back and try something else, then why spend three weeks before you even start, right? You've learned a lot in that quote, failure, right?

14:46 This portion of Talk Python toMe is brought to you by Cox Automotive. With brands like Kelly, Blue Book, Autotraderdealer.com and more. Cox Automotive flips the script on how we buy, sell, own and use our cars. And now the team at Cox Automotive is looking for software engineers, data scientists, scrum masters and other tech experts to help create meaningful change in the industry. Do you want to be part of.

15:13 A collaborative workplace that values your time.

15:16 And work life balance? Consider joining Cox Automotive. Visit talkpathon.FM/Cox today. Thank you to Cox Automotive for sponsoring the show.

15:28 I would even go further and say that technology choice doesn't really matter that much. Like the experience I had with large companies I worked for was that they often would choose technology that was utterly boring and kind of not interesting even at the time when they did choose it, but became kind of dated very quickly and it didn't matter one bit. Like Facebook was PHP, MySQL and Linux, right? Only when they already grew, it wasn't really Linux, it wasn't really MySQL and it wasn't really PHP. But at that point you already have enough infrastructure and enough employees and everything to actually keep it going anyway. Same with instagram. That was purchased by Facebook, but it was Django. Right, and still Django, but it's not really Django, but it doesn't matter. It brought them to where they are through it being an established technology. And I would in fact kind of err on the side of boring because it's going to be there for you going forward. And that's important, especially if you're choosing a data store. Like you want to choose something that, you know, like you're not going to have to migrate from in a year or two because that's not something that is a productive use of your time. So I'm going to kind of contradict what I'm saying now very often as part of my job and say you shouldn't be an early adopter, but well, in case of CPython, you absolutely should. And you should test our alphas and test our betas, but you have your CI for that. So it's a safe environment. Like, don't run 312 in production right now. Do test with it. Right. So this sort of thing in Python, yeah, it's already like you can use 311 one just fine. It should be okay since we are with our annual release cycle, kind of in sync with Linux distributions, which are doing testing of a new Python version as part of their release for October. So fedora and Ubuntu test our newest python. So it's kind of best tested as it ever was. But when it comes to your data store, when it comes to your web framework, choosing something that is extremely new and, well, we're not sure if it's going to stay forever. So maybe, maybe a kind of a bold choice. Unless it's like a 10 x multiplier of your productivity, I would just choose the boring thing.

17:48 Well, your advice about CPython 310 versus 311, it's not the same as Django versus FastAPI, right? It's like the evolution of the thing. But you could always roll back a little bit, right? It's a little bit different.

18:01 Oh, yes, absolutely. So it's like, I don't know, postgres 13 14 and so on and so on. At the same time, obviously technology changes, and even if we are not talking bugs, but just plant deprecations, there might be some disruption whether upgrading to any Python version nowadays much smoother than it was between Python Two and Python Three. So it shouldn't be a big deal. But it might be a deal depending on what third party libraries you're using. So, yeah, obviously there's considerations for you, which is why we would like you to test with 312, like in your CIS and so on and so on.

18:36 It's already there. Just put it as a run target.

18:40 Yes, but when it comes to third party projects, I am usually very boring. And if I was the last person from my friends to actually adopt Vs code and the last person to adopt fish, I was happily with Bash, and then I switched to Zsh just at the time when it started being boring. And I was like, Come on.

19:02 Really?

19:02 I kind of like my work to actually not depend on something that is extremely volatile.

19:08 Yeah, that makes sense.

19:09 Yeah. And I think it goes back to what Cecil was saying earlier about needing to have some sort of framework for how you make these decisions. And so I think that it's important to call out that a lot of times you need a base set of criteria when you're evaluating a tool, right? Like, please check the license, make sure that you're even allowed to use this thing for whenever you're doing. And then a lot of it kind of gets into that risk tolerance where it sounds like Lucash probably is on the very stable side of it versus the leading edge side. And so you've got to say, do I care about doing the new and exciting thing, or, like, should I make the obvious choice to make sure that I have that long term stability that you would get from choosing Django over FastAPI? Sort of sort of situation?

19:54 Yeah, absolutely. Gareth, how about you got some examples of decisions you had to make as your CTO role?

20:00 I'm just thinking I'm very much in the cache's world of boring is good. So you always want to go for the tried and tested if there's a marked difference between working in production and working in the wider in learning mode. So you've got Cecil's world of pulling the latest stuff, trying out new technology and playing. But if you're going to build a web frame, build a web app, then it's going to be hard not to choose Flask or that Django still, because it's there, it's around. And at the moment, all my current examples. So I'm currently at a company called My Energy, and we process huge amounts of user data, and we paid a company to write a platform for us. And it feels like they just went through NPM and installed anything they ever wanted all the time.

20:45 And now we're unpicking.

20:47 NPM install star let's go.

20:49 Yeah.

20:50 And it feels like they're playing a drinking game with TypeScript. And this bit is functional and this bit object orientated.

20:58 Picking technologies. Not just picking technologies, picking paradigms. So it's TypeScript. That's great. But is it functional? Is it object orientated? Is it procedural? And the answer is this bit is and this bit isn't. And this bit over here. And then we need an orm. So it feels like they pull in the only Orm that they've seen in the tutorial, but somebody's written, so we got type Orm, which doesn't do migrations, and you're stuck. And we've got a massive pile of technical debt on a brand new project you're having to unpick because no one consciously chose the project. Or is it? No.

21:35 In my last gig, we spent a lot of time because I've got horror stories about Zoe, but we spent a lot of time choosing the right framework and having the right reasons and put in a lot of effort. Into writing proof of concepts because we knew the traffic demands, we knew what we were doing, and we went flask. And we went certain technologies in AWS. We went docker.

21:58 And we just follow this route through choosing things to be stable and scalable, not necessarily the latest and greatest, not necessarily the most cutting edge. We just wanted to make sure we could develop on it. And even then, we chose badly chose a library because somebody followed tutorial. We didn't really think about end up using a rest framework that got deprecated.

22:18 So you have to put the effort into choosing the right things and be okay with going. I don't care if we're not cutting edge. We let Cecil be cutting edge and go and play in his advocate role, and then once it's in production in other places, then you use it.

22:33 Yeah. This distinction between what do you choose in production and what you choose other places also, it doesn't necessarily have to be just learning. Right. It could be, well, here's some tools that just kind of pull in data and process it. But if it's not perfect, the website is not going to go down, and we're not going to lose $1,000 a second until somebody fixes that type of situation. Right. Somebody's got to fix the ETL.

22:55 I think that's another big part of it is in most companies, your job or your function with the company is not supporting a web framework or building out features within a web framework. You're trying to implement whatever business logic you need beyond that. So going something tried and true or older is going to let you do that. And it may not exactly meet your use case, but like Lucas was saying, once you have enough if you have enough revenue, that's a problem. If you're Instagram or Facebook, well, that's a good problem to have. You can deal with it at that point.

23:33 Yeah, absolutely.

23:35 For you, Dan, the situation might be a little bit different as well, being more doing ML type of things. There's less tried and true. Right. The ML of two years ago is laughed at by the ML of today. Right.

23:48 Yeah.

23:48 It's changing so fast, it's hard to say we're going to pick stable, because you give up a lot by doing that.

23:52 Yeah, for sure. A lot of stuff we worked on, and I think some of it is that I've spoken with folks who are building ML companies, and they're like, yeah, the scale you're operating at is like ten times or to 100 times anything we've run for something that's an ML as a service platform.

24:11 So we've had to build out some things where kind of existing frameworks didn't cut it for us. But it was first, can we actually use those existing frameworks? Because ideally we're not an ML platform company. We want to use whatever the framework is. We can, because that will get us our job done. Only when we can't do that do we really need to go custom and build things out for scale.

24:40 It's easy to get into thinking like, my job is to put this to work and make this framework as awesome as possible or to get it going just right. And really it's to deliver functionality to a business. Right. That's just a means to an end. So, yeah, for sure.

24:54 I could maybe just a thought on that that came to me when we were talking about boring. The other thing that kind of can be very tempting is if me or I have a team. I come across a new fantastic tool. I think this looks great, let's use this. I've spent half an hour reading a tutorial. As Gareth pointed out, I know everything there is to know about it. It must be great. I work it into the project. We don't touch it. We make it work. We don't touch it for a week after that. Then I'm on leave three weeks from now on the beach somewhere and it goes wrong. Have I bothered to tell the rest of my team how this thing works? Because I've chosen something that isn't boring, that doesn't fit in with the stuff the rest of us all know, and now there's a huge problem there. So you want to give up the default to that as well. You want to be consistent with the stuff you use sometimes, as Gareth is saying, in terms of paradigm, that there might be shiny toys that don't fit in with the rest of it. And I'm afraid you've got to leave the shiny toy behind. Unless, again, we are talking in what you're paid to do, obviously, for your own bet. Shine it all your way.

25:47 Yeah, you got to think about the team buy in as well. If our group is going to be.

25:51 Using it, right, we fund development Sprints and we fund hack days to play with things. So if you got an idea for do you fancy using a FastAPI, then build a small thing and put a small project in. See how it works, see how it deploys, but don't bet the farm on it until you're certain about it.

26:13 That's a great way to do it, right? That's sort of a more structured way to experiment. So I'll share a quick story with you all here. Recently, I wanted to rekindle my blogging. I don't know, social media and places are a little scrambled these days, so I thought it might be a good idea to have something written as well that I can point to. So I went to make this website and I thought it's something simple, something marked down, something static. And I don't know, I've done. That my last blog was on WordPress. I don't want to use WordPress anymore. I don't want to have a database for my blog that seems like overkill. So I'm like, all right, well, what do I do to decide? So I went out to the community and I asked, hey, I'm thinking about this static website blog thing, python Tools Preferred, but I'm open for anything. And Kim, I think you even maybe weighed in on this.

27:05 Yeah, I think you did. And I got a bunch of different feedback. And so my solution to sort of exploring this place where I felt a little unqualified, I didn't have really much experience with, was to go out and ask. And the answer I got back really surprised me. I thought, well, maybe it's going to be pelican or Ghost. But a bunch of people started saying, Hugo. Hugo? This thing is Hugo. It's amazing.

27:29 Obviously there were people saying pelican and sphinx and whatnot. So I ended up going with Hugo, which was a bit of a struggle for me to decide because it's unbelievably good. Kim, are you using Hugo as well?

27:42 Yes, for a couple of things.

27:44 It's glorious. It's so nice for writing, but it's written and go. And so it's like, well, can I really fix it or tweak it as easily? But in the end, I decided, you know what? It's more important to have something that works really good, that has got a lot of popular support than having something that is in a language I'm an expert in. So I'd kind of like to hear your thought. If you're in that kind of situation, what's your process? How do you come to these decisions?

28:09 Well, I kind of redesigned my own blog when I kind of got the new job because it's like, oh, I need to communicate. So I went through a similar process.

28:20 What I ended up doing is obviously it's a super empty pattern, but it turned out to be super successful, which is just write your own and obviously everybody writes their own static site generator. But like, I'll be honest with you, like, with Python in 2020 and 2021 and 2022 now, like, it is so simple because all the building blocks are there. Like, you're not writing strings of HTML into a file. All of those kind of building blocks are done for you. And just let me bring up for you how big my huge site generator is because it's super tiny, but it actually handles everything I wanted to the extent where I'm using it for a couple of sites right now. And it's like what? And it's under 2000 lines of code at the moment, like, the entire thing. So it's like, it's not super big. And it was growing in time when I was adding new stuff to it. For example, at first I just did not have RSS at all because I was like, this thing is dead. Nobody needs RSS anymore and then a bunch of people just don't tell me like, hey, why don't you have RSS? So I just added it later on and then just what? Like, oh, we have XML in the standalone library and there's actually RSS libraries too. But this is so simple. You just have this one template that you need to output. So, you know, kind of I did my own thing and I can now write on the footer of the site that was generated with Python 310. I should just recreate the virtual and so I'll be able to say 311.

29:54 Then you'll be cutting edge.

29:55 Yes, but the reason why I actually did this was that all the notes that you're seeing there, if you click through of the thing, they are in fact in Markdown in my Notes. So I am kind of crazy about having notes. So I have a lot of them, right? So I have thousands of them and they are all in Markdown and in a Git repository synchronized over to my phone and whatever. So I can always just access them in a plane or whatever. So those are just tagged hashtag public in the Markdown text and they appear on the website and it's kind of automatic. So I don't actually have like a CMS for this. I just have my Notes app that I'm using. It's FS notes. It's open source, it works on the Mac, it's glorious and it works nice on iOS.

30:44 And you just kind of generate HTML out of that, which is pretty simple. And I can automate a bunch of stuff with this just kind of custom made, which with Hugo I probably could do, but I would have to learn how. And I already know Python, so it really took me no time to get this up there and it kind of works on the phone. It's okay, it's not going to kind of wow you, but it's a perfectly functional website.

31:11 Yeah. The audience says building your own static site generator is a great way to learn a lot about the language. I learned a lot for years, just maintaining my own.

31:19 Choosing static sites is an interesting choice on its own. Right? The DevOps story is incredibly nice that you don't have to worry about will the database go down? What kind of problem?

31:30 It's either going to be there or it's just not there either.

31:34 Will the database go down?

31:36 The unconsidered problem until you're in the DevOps space on a non static site is when your internal department would like a version of the site they can change the CMS on to make sure it all looks good before they rolled it to production. Now you've got to get database exports across into a different database or you've got to get migrations going.

31:53 Not that I would ever do a thing like this, but you might have to have two versions of Docker running in direct production so that you can do a live MySQL copy of MySQL path from one to the other, hypothetically speaking, would never do that.

32:08 This portion of Talk Python to Me is brought to you by Sentry. How would you like to remove a little stress from your life? Do you worry that users may be encountering errors, slowdowns or crashes with your app right now? Would you even know it until they sent you that support email?

32:23 How much better would it be to.

32:24 Have the error or performance details immediately sent to you, including the call stack and values of local variables and the active user recorded in the report? With Sentry, this is not only possible, it's simple. In fact, we use Sentry on all the Talk Python web properties. We've actually fixed a bug triggered by a user and had the upgrade ready to roll out as we got the support email. That was a great email to write back. Hey, we already saw your error and have already rolled out the fix. Imagine their surprise, surprise and delight your users. Create your Sentry account at Talkpython.FM/sentry and if you sign up with the code Talkpython all one word, it's good for two free months of Sentry's business plan, which will give you up to 20 times as many monthly events as well as other features. Create better software, delight your users, and support the podcast. Visit talk Python.fm/sentry and use the coupon code talkpython.

33:24 But it's also unhackable. That's an interesting theory is that, yeah.

33:27 The worst thing that could happen is it could deface. It could get defaced. I guess somebody could put some JavaScript malware on it if they took it over, but it's not open to little bobby tables or denial of service. To a large degree, you're right, it's a good point.

33:40 Hard to hack. Very hard to hack.

33:43 Well, for me, the most important thing that this literally just runs on the free tier, like on Netlify, it's good.

33:50 Mine is on Netlify as well. And I got to say, it's really leaving. Nice thing.

33:56 One comment that we were making about picking a library, something that you pointed out and that Lucas was saying as well. There is something to be said for making sure you can fix it if it breaks. But I think to the logic, it depends on how I suppose it depends on several things. How important the thing is to you, how quickly you can change it if it does break, and how kind of big the thing is. It never occurred to me, for example, using Hugo, it didn't worry me too much that I don't know when you go and I can't fix it because it's a big enough tool that I can probably make it do what I want. But I've got pretty simple needs. If I was picking a very fast something really low level in kind of my previous sea life, for example, to talk to the flash memory as fast as I can. I'd probably want to write that because or at least know that I can fix the thing I got because maybe I need to be able to tweak it or otherwise. So it also depends on what you need the thing for quickly. How much does it matter whether you tweak it or not? Depends largely on how important it becomes to your project. The downside, of course, when you do that decision six months later and it's super important, now you're stuck.

34:56 Now you're on the hook. I'm like you. I don't know when you go. Not really. I mean, I've read a paragraph of sample code to know what it looks like, but that's about it. But for me, it was okay to pick Hugo. That is a go tool because it's not actually running while you interact with my website.

35:12 Right.

35:12 If I was picking a go alternative to Flask, that would be a really big consideration because I'd have to kind of write code and live in it. Here's the thing. I run on the command line, and it either makes the static site or it doesn't. So it's not in the important path of interactions.

35:28 You could swap it out without your website breaking. The result will still be up live on the website while you're replacing Hugo with something else. If you want exactly the consideration there.

35:36 It could end the Lucas route. Try to recreate the same look and feel.

35:41 Yeah, so unlikely it would break and not be fixed by Hugo devs or the surface of the application is relatively well defined.

35:51 That brings me to the next thing here, is when you go to an open source project and you find it on GitHub, how much does stuff like this Hugo thing, it's been forked 7000 times and has 64,000 stars. Like, okay, if it breaks, someone else will fix it not my problem. If it had six stars and it breaks, it might be my problem if it breaks, even though it's not my project. How do you all think about that when you are choosing projects? Or Emily or Cecil in your case, is recommending technologies?

36:21 Yeah, I think for me, this is just my personal opinion. Things like forks and stars are like vanity metrics for me. I don't really care, to be honest with you. I do care if want to solve the problem I'm trying to deal with. Can I submit an issue and get relatively within six months? Like, someone answer me fairly quickly. Like, I don't want to wait for response. And are there commits being even that too, right? When I say, are there commits being made? You don't need to be making commits every day and every hour or every week or every month. If I see that the last commit was like, five years ago, I'm like, okay, well, if I have a problem, I don't know if this is the thing that I need to jump into because I don't know if I'm going to be able to get the support that I need.

37:04 But you still might taking it, but then you would have to take it on the assumption that you might have to write the fix or add the feature.

37:10 Sure. So I'm going to use you as an example, Michael. So if you decided to go with Hugo and there was an issue with Hugo and you don't know Go, and you're like, oh, shoot, what am I going to do now? You get to be in a position that you can either learn go or you could just swap it out and go with something else. Right, but what do you do?

37:27 I think I'd rather rewrite it from scratch than learn go.

37:31 Not that I hate go or anything.

37:33 I think thinking of just a time effort sort of trade off again, it's.

37:39 Mainly just about how do we like, is it solved? A thing that I want to solve, and then can I get like some level of support questions answered and documentation and stuff like that?

37:48 Yeah. So when I looked at this commit last, commit yesterday, there's a bunch of issues, but if you look at, say, the closed ones, there were issues closed a couple of hours ago, pull requests, I suspect probably those are linked together. Right. So there's clearly life in this project and to me that probably is enough. How about the rest of you, emily, what do you think?

38:08 Yeah, I totally agree. I think these are exactly the things that I look at is, you know, are things getting updated or commits getting in. If it hasn't had to commit in a year or two, sometimes that's still okay, right. Sometimes you're looking at Django reset password library, but yeah, it's continued to work over time and you don't necessarily need new features added to a reset password kind of thing. So knowing kind of what you're looking at and what you need out of it, I think is still important. But I totally agree. Forks and stars, even downloads are a kind of vanity metric. I also think that something else that I always look at is what is the audience of the tool? Right. So Hugo is very much geared towards a community of people building for mass numbers to use it versus a tool that maybe Lucas static site generator is probably very tuned to the things that he needs to do with it, that he could opt to open source it, but it's not going to be a tool for the message.

39:06 We have a visual decline. Just.

39:10 Knowing what you're getting out of it and knowing what that sort of feature roadmap is going to be, either it's like it is at a stable point and it's not going to change. This is something that is going to be very opinionated for someone specific. Use case versus Hugo is going to continue adding functionality that would serve a broader group of people and just using that as part of your metrics for deciding if that tool fits your needs.

39:34 One thing that I use, I used to do is I look if the last comment on the thing doesn't need to be super recent, but is the builder red or green? And if it's red, then I don't like seeing red in the last comment on the project I want to use and often if that will be a critical dependency, I would in fact just clone it locally and just try to just build build it and see if tests pass on my end and if they do good and if I cannot download some dependencies or like Py test has like 15 failures or whatever else, then I would be like getting more skeptical now? Because obviously, if you are installing a package with Pip, install. Unlike with CPAN in the Perl Universe, you run no tests. So you kind of only the only thing you know is that the files were put in the right place. But whether they're going to work well, just going to find out like at runtime, I guess so, yeah. So like every now and again I would just try to build something when I actually depend on it. But it's really critical because a lot of the dependencies, like yes, even downloads or a vanity metric because if push comes to shove I can just vendor in the dependency and fix it myself.

40:48 Well, there's also a project that you have a little involvement with that it's got a few downloads, right?

40:52 Yeah. So when Emily said that it's a vanity metric, my heart was hit like right in the middle because I live by those downloads. Man, it's awesome. I have never expected this to go so big. So it's still sometimes like I would just like sit and drink coffee and just suddenly think, how did that ever happen? It's mind blowing.

41:15 I didn't mention it, but I think that this is a really good example of a library that is very clear about what you're getting from it. Right? Like uncompromising code formatter, it's very clear that it's very opinionated and that a lot of it came from you. And the joke that I was going to make is like, you know, with black, like even if you need setups.cfg support, you are not going to be able to just add it and open a PR and get it merged in. So again, knowing what you're getting into and I think that a lot of this opens up a conversation on the other side of this for open source maintainers of being aware and being cautious and being clear to your users of what you're putting out there to say, look, hey, I'm not going to maintain this. This is just something that's here, if you like it, use it great. But taking that extra step to make sure that you're telling people what you are willing to take on as a maintainer as well.

42:11 For black maintenance in particular, the fun thing was that I gathered like a team of people who are maintaining it now and I do relatively little these days, honestly. There's a bunch of people who are super active and they actually kind of shook me out of this kind of psychological block to a stable version. Has to be perfect, we will never get there. And over 2021 we turned out a lot of releases and now like, yeah, black is stable. It's amazing. So another kind of consideration that you might have when you're looking at a library or a tool that you might use is like is the bus factor one? Is there just like one stressed guy who just tries to kind of make it work after hours? Or like are there a few people responding on the issues? You know, like is there more than one person with the keys to the kingdom? Because sometimes if you lose the keys for whatever reason, it's very disruptive. We had a bunch of libraries like that in the Python world where forks were necessary because the original maintainers lost interest or life or whatever else. So things happen. I cannot really say that I did anything like that.

43:26 I planned for it. It mostly happened by accident because it just had nice contributors that I liked. So I just shared the right access with them and they ended up being very trustworthy. But a maintainer should do that at some point because you cannot just do everything by yourself. It's just impossible.

43:44 The bus factor is interesting. There was this guy who had an NPM Project JavaScript project who had done some kind of protesting thing, like swapped out his project to just print stuff infinitely and some kind of just really frustrated that it was color JS and faker JS. And it was really frustrated that companies were using the project and not paying for it. It was open source under MIT or something, but that was his take. But then had a full on breakdown and got like arrested for creating bombs in Queens, New York. That's an extreme example. But it can happen. Something could happen, right? Or somebody could just get actually in an accident or they could have a health crisis, right? Like could be a place where it stops. So considering that is on the topic.

44:32 Of best vector, for that matter, which I mean, I think obviously what it means, just in case anybody needs a definition, if you're the guy, if you're the only person who knows how it works. And you get to hit by a bus tomorrow and you spend four weeks in hospital in the summer. Sanitized version of the the theory. Can somebody pick it up after you? And I think one of the things that does feed into picking tick steps and tick stacks and so forth is the best factor on the libraries and so forth is quite important. But what's also important is if it's a really complicated, super hard to use library or something that you need to be an expert in, and you have one of those experts, you've suddenly made a bus factor issue there.

45:07 Too.

45:08 Because now you need that expert to know what he's doing and be around and not choose to go to another company or be hit by a bus or any of those things. There's a consideration there for the complexity of a tool as well. Sometimes it's unavoidable, sometimes some things that you have to do or context. But if the tools are if you're constantly picking the hardest thing there is to hold a store, if you're picking the most challenging thing to use because it's the most fun, you might want to be considering that as well. How simple is it for somebody else to sit down, pick up your work and keep going with the libraries you've chosen to use is a consideration you should probably be keeping in mind as well.

45:41 Yeah, sounds like Gareth's projects of these hackathons or these group experimental projects might help a little bit to give a little exposure to some of the new tech rather than somebody figured it out in their corner and then just added it and everyone was like, Great, it works. I love it.

45:56 Yeah. One of the things I think is interesting there like just talking about the bus factor. It makes me think a lot of times when we're learning stuff we don't often think about or when we're choosing things we don't think about the human aspect that's attached to it, which, as technologists, are just not a thing that we do. So again, like the bus factor, right. Something bad happens to the person and now what do we do now? Right. What is the next step? Right?

46:19 Yeah.

46:20 Another thing that I've noticed a lot, again, kind of thinking about the humanity of learning is a lot of the times people choose things because the person to their right and their left, the people that are in their circle of influence are using that thing. So I'll give you an example. I go to a lot of senior design showcases at colleges, universities, and so on and so forth, and when I kind of look and I say, oh, well, why did you pick this language or why did you pick this cloud or why did you pick this framework? It's usually because the people around them are doing it too. Right. And the reason that is now, hey, if I pick the thing that Michael is using or Emily is using, or Kim is using, you know what, I have people that I could go ask the question. You know what I mean? So now I'm going to choose that thing not because of any technical reason. I mean, obviously it has to do with the thing I wanted to do. But the main reason I chose it is because, socially speaking, I have people that I could go ask the question. And so now my confidence level in that project is a little bit higher because of that reason.

47:18 Yeah, that's a really good factor.

47:20 Yeah. I think this hits the nail on the head because even in Python, like a popular programming language, right, by all standards, we have parts of the standard library that was written by a person and that person is no longer around. And now we obviously can still have access to the code. Like we have tested our passing. We can still maintain the code, right? We can still mutate it, we can still make it to different things if we need to. But the one missing piece which is sometimes needed and we don't have it anymore, is why certain choices were made originally, because that kind of informs where we should go next. Right. If something is kind of uncharacteristically convoluted and you see this and you're like, oh, I would simplify this, after a while of core development, you're like, every time you want this, there is a reason behind every kind of weird, weird part that you're going to find. But if there's nobody to ask the question to, that complicates things a lot. And we have a bunch of situations like that where there's like a stalemate between a few possible approaches because we don't really have an opinion of the original author to go by to kind of make a choice.

48:36 It was definitely a challenge. Gareth we're trying to jump in there often as well.

48:39 We make decisions because then it sounds cool. But actually the best decision you can make around framework or language is the one your team already knows. So your default thing should be don't change unless there is a really good reason to change. Because I've seen companies have gone, we need to write a thing in Java, because the industry does it in Java, but all they were was Perl and PHP devs. And so suddenly you have an entire stack that your developers can't maintain. So it might be the most perfect Java application in history, but no one you employ can actually do anything to it.

49:13 Going a bit back to the Cecil. Keep the humans who got to deal with it in mind, not just the technology. Yeah. All right, I want to move on to another topic. I'm getting short on time here, so maybe I'll throw this first. Dan so when we were talking about the bus factor, obviously that's a person who is a maintainer of an open source project in the context that we were saying before, or Kim brought into somebody at the company with that expertise. But a really common and big bus factor is a company has a closed source project and they either go out of business or they get disinterested in continuing that project. And you're in a bad place. So what I wanted to ask you all is how important do you see the open source side of things versus a closed source? Like, let's say there's some project for a database, it's twice as good, but it's closed source. Choose it not choose it. Putting money aside, suppose it's free.

50:07 I mean, I guess I generally say is how hard is it to change out for something else?

50:13 Like, is it postgres, but two X is fast postgres postgres, or is it.

50:19 Microsoft SQL Server, but it's still relationally. Probably just migrate that data to postgres or something.

50:24 Yeah, I think the risk is really if you're using this and it goes away and then you're stuck, that is definitely a real risk. And I have seen that happen with companies that actually had to rewrite their entire code base because they used something proprietary that then was decided because one.

50:44 Specifically is not profitable enough. So your project stops. Exactly.

50:49 This one. It was called QA Studio. It was a finance quant finance language, actually, by Palantir. There was a hedge fund I knew that had fully adopted it, and then they actually made the reverse migration to Python after the fact about the SEO.

51:06 What do you think?

51:07 Wow.

51:08 Where is that reminded of that you cross over?

51:10 Yeah.

51:10 I was reminded about kind of somewhat horrifying experience from my own career that Dan just reminded me of. I've seen it happen with the third party software that the company's bought, and then it's no longer available. But the other time I've seen it and it ties into what we were saying about kind of picking things that the team knows is I've come across bits of software where somebody says, well, that's the app that Bob wrote 15 years ago using Visual Basic Four or whatever it is. Nobody knows how to it doesn't do what we need to do anymore, but we don't have the source. Even if we did have the source, we don't have a Visual Basic Four compiler. Nobody understands it. We don't know how he built it. Bob is long gone.

51:45 You need Windows 95 to build it. How do we get that?

51:47 Well, exactly. All those things add up. And at the time, it's not to make you sound like Bob was an idiot. Bob did what bob knew. Bob knew a Visual Basic Four, and somebody said, let's turn out a tool as fast as possible, and Bob can do it for us today. And Bob did, and the tool works, and it's fine. And you don't think anything about until way down the line, and nobody knows how to maintain the things. So there's an argument to be had for where do the libraries and stuff you pick if you're not picking things that everybody knows, or at least a huge chunk of, you know, sooner or later you ran out of people who know how to maintain these things.

52:20 As I say. Not through maliciousness, just through I need to dumb Foster. If you ask Bob to do it fast, bob going to do it in Visual Basic 4 because that's what Bob knew.

52:28 That might have been a terrible a decent choice in 1992.

52:31 Exactly. Yeah.

52:32 But it's not in 2022 or now.

52:35 And code rots. It does over time. So it was the current compiler. But if you don't keep moving it forward, you get to a point you can't move it forward.

52:44 Even if the code would work fine in that old platform, the OS has changed and it somehow kind of gets a little out of line with that. Right.

52:51 CPU architectures change. Right. So you have to rebuild at some point and so on and so on.

52:56 That only helps if you kept up with the ability to do that. You decided to stop the line. Now we need to make it run on.

53:04 That's what Visual Basic Runtime and WebAssembly is all about. Let's get going.

53:10 Emily, what's your thought on this open source? My tendency, obviously, is to choose it's the first choice, but where's the threshold there?

53:19 Yeah, I think a lot of what we do very much lives in that realm of open source, but for me, I think it really comes down to portability. If it's something that can be easily swapped out, I'm all for it. But I see this a lot more with system architectures. So if you're going to decide to go with AWS RDS, it's postgres, right? You can use the fancy versions and whatnot, but under the hood it's still postpress and you can move that wherever you want to. Whereas if you're going to make the decision to go all in on serverless and you're going to write land as, that's definitely something that you can theoretically move someplace else, but that barrier to portability is a lot higher.

53:59 That's kind of where I look at it. If this thing goes away, or for us, a lot of it's like looking at client budgets. Right. So if this thing costs $10 a month now, but they decide to up their costs and now it's going to cost $1,000 a month, is that something that our client is going to be willing to take on from a financial perspective? So, yeah, there's a lot to it.

54:22 Yeah. You're sort of touching on another angle that's interesting as well. We don't really have time to go into it, unfortunately, but even if you have an open source thing, maybe your code is in Python and it's talking to postgres. You can get locked into commercial clouds like RDS or Lambda. Right. While it might still be running your Python, like you said, you can't just take it and run it somewhere else without rethinking all the little roots of things it's going into to hook into the other parts of the cloud there. And that's clearly not something you can take as an open source thing and run with. So I'll give you the final word on this and we'll wrap it up. Yeah.

55:00 One way I kind of think about it is there's some things that I care that they're open source and other things I just don't. As an example, I use MongoDB randomly. I have never looked at the source code. I'm probably never going to, whether it's open source or not, when I could see the source code or not. Is it important? I don't know. Is it the fact that I appreciate that there's community contributions and the discussion happening? Maybe that's the important part of the open sourceness that I do care about. When I think about smaller projects now, when I mean smaller projects, I mean like utility libraries and things of that nature, a lot of the times I'll find myself like, debugging and actually looking in the code because I might have seen like a weird error message and I'm like, I don't understand what this means. Let me try and navigate through let me get clone it and navigate through it and see what's happening. Right. In that case, sure, I totally care to this open source because I have a problem and I want to try and figure it out. Right. So I think it really just depends. Again, for me, more so I really appreciate when those utility libraries that I'm using are open source so I can figure out what's happening. But major things like I think about Mongo or Rabbit MQ or Redis or anything like that, I'm never going to look at that source code. You know what I mean?

56:09 I'm with you on that. Yeah, I appreciate that they're open source, but I'm not going to try to change it. I'll just probably break it.

56:16 All right, well, this has been a great conversation. I'm looking at the notes that we all put together to talk and we're halfway through it and we could just keep going and going, but we only have so much time. So what I want to do is I want to close out normally, ask about editors and cool packages and stuff. I want to close this out with a lightning round on one other thing, and this final thought is, how much does it matter that we have really beautiful say landing pages? Some of these open source projects like Vuejs or Tailwind, they could be a high end marketing budget spent on them and even poetry in the Python space. It's kind of got like a cool little landing page. So top to bottom here. Final thought, give me a couple of thoughts real quick on this and then we'll call it a show.

57:00 Dan I think it definitely helps in terms of getting people involved, not necessarily a requirement, and in some cases may mask issues with the underlying library.

57:12 Okay.

57:14 The only thing I can think of is like profit, kind of, which had a lot of Facebook very fancy Facebook marketing, but there's been some things like the Zillow stories and things like that of cases where it wasn't necessarily appropriately used, but it's very fancy marketed. So I think it just can be an entree even without full evaluation.

57:33 Right.

57:34 Maybe the efforts should just be put to the code or somewhere else. Gareth, what do you think? You've seen the tailwind CSS site? Are you ready to swap all your stuff over?

57:44 All I care about is how quickly I get to a demo of it and the documentation. So I'm old school, so if it's got a man page, I'm probably happier.

57:54 I often find myself looking at them going, that's great. I have no idea what it does. And I think the fancier the landing page, usually it actually puts me off a bit because I'm worried that they're putting a lot into it. Although I pay a lot more in JavaScript at the moment, they seem to have a lot more fancy landing pages.

58:11 You've got to stand out when there's a new library every week. Kim. Sure.

58:15 I'm pretty much with Gareth there. It would be hypocritical of me to expect an open source project to have a pretty page before I can use it, because, frankly, I can't do that, and that's not reasonable to expect the other projects I might consider using to do that. The one thing I would agree with Gareth, and one thing what I want to see, basically, is as fast as possible, what is it and how do I use it?

58:36 The marketing dump and stuff is all very nice and well written, but it's less relevant to me. The only thing I would argue that turns me off immediately on a big project are ones that go very video heavy without much text. If you have anchored your project towards, here's a video to show you everything you need to know, that's ten minutes I'm never going to get back. If I decide I don't want to use your library, you can equivalent text. Exactly. I could have read the equivalent text six times at the time it took me to watch your video. So maybe that's a personal quick. But that's the thing I don't like for video heavy. It doesn't work for me.

59:09 I must say, Emily, you probably have clients that come with fancy landing pages that I'm going to recommend that you start with.

59:14 Yeah, for sure. For me, I think documentation is paramount. And I think that a lot of, especially in the Python world, there are a lot of pieces of documentation that feel a little bit antiquated at this point where it is very much generated off of, you know, maybe some doc strings or, you know, argument types and all that stuff, that sometimes it's not the most user friendly. So for me, it's like, yeah, I can look at this stuff in the code if I need to. So having something that is either a playground quick start guide how to use it. That sort of thing is really important for the landing pages. I feel like it's not necessary, but I think that when a tool does a little bit of the work to show how it's differentiated, that helps me. Right. So if I can look at something and go, all right, I'm going to look at poetry, and they provide some great examples for why it's faster than the thing, why it locks better than the thing, whatever it is, it at least gives me sort of a starting point for why would I use this tool. Obviously, it's all sort of taken with a grade of salt because each tool is going to say that here are the things that they're best at and kind of hide the things that they're maybe not best at. I also think as you're sitting here on this page and you've you kind of scroll down and you can see all these sponsors.

01:00:28 That does matter.

01:00:28 Yeah, it matters, but it's also something that can make you raise an eyebrow. Right. So Vue is great because it's very diverse. It's not a single large company that is sort of powering everything. But I do think that is something to sort of watch for is who is driving this and what is the reason why it's here.

01:00:49 Cool. Cecil? Yeah.

01:00:51 I think, like a lot of other folks on this panel, I am not a designer, so I do appreciate the aesthetics of being able to see things clearly and read them clearly. I'm not here for the marketing stuff and I'm better because stuff, you know what I mean? I'm usually going to come in and I'm going to look for that getting started button. I'm going to look for that docs button. I'm going to look for the little code sample that I could copy, paste into Vs code and run kind of thing for the most part. But then I also recognize the fact that really nice documentation takes time and a lot of open source folks don't always have the time to create that.

01:01:26 Right?

01:01:28 Yeah.

01:01:28 But is that like a metric that we judge them by? You know what I mean? Yes or no? I mean, is that fair? You know what I mean? You could have a really good project, but if you don't have the good documentation, obviously I can't use it the way it's intended to use. But does that mean that it's not a good project? I don't know. So I feel like that's obviously a good opportunity for folks to contribute and send PRS and things of that nature. But for me, I'm just going in really quickly to see, hey, how can I start the thing? How could I run it, install it, execute it, docker, compose it, whatever, and then kind of just get going.

01:02:01 All right, lucas, you got the final word here?

01:02:03 Sure.

01:02:03 Well, I don't think you can really go wrong with an ugly website for a project that is open source, it very rarely hinders the project. Just look@python.org, I'm being unfair, but in perfect fairness, the last redesign was like some ten years ago or something. So kind of it doesn't look exactly as flashy as like tailwind or view or whatever, but it doesn't really matter because it does kind of let us all pipi is nice. Like Python.org.

01:02:31 Yeah, I was going to say PyPI actually did get that treatment though.

01:02:34 Yeah, exactly. So yeah, Python.org might get update at some point as well, but it doesn't hinder us in one bit because it's a functional jungle. In fact website and we use it every day. It's nice. I personally like if there was a designer that actually sat on the project and made the website work, there's a bunch of things that until recently nobody thought about. So all those outdated websites don't have this where like dark mode, white mode, looking good on a phone screen or whatever. Like those things end up being quite useful to me now. Like in the job I do, I work with people in different time zones. So every now and again they would catch me when I'm away from a keyboard and if I can actually go and check something on the phone, it's very helpful. It's not always possible or it's at least complicated sometimes when you scroll backwards yes. Or like a white background is going to glare at you at 03:00 A.m. Or whatever.

01:03:36 So I appreciate good design. It's obviously not something I do personally as well. Just like everybody else, I think here, however, there are people that are great at it and I appreciate it when kind of people like this get contacted and then those sorts of websites look good and are functionally better that way.

01:03:57 Thank you all for being here. It's been a great conversation. Thanks for taking the time and being part of the group.

01:04:02 Thanks everyone.

01:04:03 Thanks.

01:04:05 This has been another episode of Talk Python to me. Thank you to our sponsors. Be sure to check out what they're offering.

01:04:11 It really helps support the show.

01:04:13 Join Cox Automotive and use your technical skills to transform the way the world buys, sells and owns cars. Find an exciting position that's right for you at Talkpython.Fm/cox. Take some stress out of your life. Get notified immediately about errors and performance issues in your web or mobile applications with Sentry. Just visit Talk Python.Fm/sentry and get started for free. And be sure to use the promo code talk Python all one word when.

01:04:42 You level up your Python.

01:04:43 We have one of the largest catalogs of Python video courses over at Talk Python. Our content ranges from true beginners to deeply advanced topics like memory and Async. And best of all, there's not a subscription in sight. Check it out for yourself at training. Talk python.FM. Be sure to subscribe to the show, open your favorite podcast app and search for Python, we should be right at the top. You can also find the itunes feed at /itunes, the Google Play feed at /Play, and the direct RSS feed at /rss on Talkpython FM, we're live streaming most of our recordings these days. If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython FM/YouTube. This is your host, Michael Kennedy. Thanks so much for listening.

01:05:28 I really appreciate it.

01:05:29 Now get out there and write some Python code.