#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 some vendor is offering.

00:06 This is especially true when that support is poor or antiquated.

00:09 Almost any capability you can think of has multiple options, even for a single language such as Python.

00:16 Just think about how many web frameworks you can pick from today.

00:19 But therein lies a new problem.

00:22 If there are 10 options, how do you choose?

00:24 Do you go for the oldest and potentially most stable?

00:27 How about the most up-to-date one?

00:30 Maybe the hot new version that has the fastest adoption curve is the right one for you.

00:34 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 VanWijk, Lucas Schlinge, Gareth Thomas, and Dan Garland.

00:45 This is Talk Python to Me, episode 397, recorded December 7th, 2022.

00:51 Welcome to Talk Python to Me, a weekly podcast on Python.

01:08 This is your host, Michael Kennedy.

01:09 Follow me on Mastodon, where I'm @mkennedy, and follow the podcast using @talkpython, both on fosstodon.org.

01:17 Be careful with impersonating accounts on other instances.

01:20 There are many.

01:21 Keep up with the show and listen to over seven years of past episodes at talkpython.fm.

01:26 We've started streaming most of our episodes live on YouTube.

01:30 Subscribe to our YouTube channel over at talkpython.fm/youtube to get notified about upcoming shows and be part of that episode.

01:37 This episode is brought to you by Cox Automotive.

01:40 Use your technical skills to transform the way the world buys, sells, and owns cars at talkpython.fm/cox.

01:48 And by Sentry.

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

01:50 Use Sentry.

01:51 Get started at talkpython.fm/sentry.

01:55 Transcripts for this episode are sponsored by Assembly AI, the API platform for state-of-the-art AI models that automatically transcribe and understand audio data at a large scale.

02:06 To learn more, visit talkpython.fm/assemblyai.

02:11 Hey, y'all.

02:11 Welcome to Talk Python to Me.

02:12 Gareth, Kim, Lukasz, Cecil, Emily, and Dan.

02:16 I've 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 Sure thing.

02:20 Yeah, I'm excited, man.

02:22 We have a nice little party going on.

02:23 Yeah, we do.

02:24 We definitely do.

02:25 Yeah, 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:34 You know, we have this paradox of choice type of problem, and especially in the Python space.

02:40 You know, I haven't even looked.

02:42 Are we over 400,000 packages on PyPI?

02:45 There's many, right?

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

02:50 Oh, my goodness.

02:52 Yeah.

02:52 Jack, look.

02:53 It's mostly machine learning, but, you know, Kenneth, there's a lot of packages.

02:58 Yeah, there's definitely a lot of packages.

03:00 Okay, well, how do you pick?

03:02 How do you go to that list and say, I'm going to search for a web framework, and look, there's 100 results.

03:08 How do I pick?

03:09 Or I'm going to find a way to talk to a database.

03:11 What database should it be?

03:13 So that's going to be our topic for the show today.

03:16 And let's just start real quick with the elevator pitch of who you are and your background.

03:24 You know, 30 seconds or less.

03:25 We'll go around the Brady Bunch squares here.

03:28 Gareth.

03:28 Hi, I'm Gareth.

03:30 I've been programming for probably 40 years, I guess, and now, because I started when I was about three.

03:35 I'm on a Dragon 64.

03:37 But it was only recently I got into Python, really, when I took up a job as a CTO of a company that did everything in Python and haven't looked back.

03:44 And now I'm doing CTO stuff the whole time.

03:47 Fantastic.

03:48 And I think CTO positions are very much in this role.

03:53 You've got to set a little bit of guidance for the company and the teams, right?

03:57 Yes.

03:57 And I don't get to do code anymore.

03:59 I just get to watch people write code.

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

04:06 Kim, welcome back.

04:07 Thanks.

04:08 I must be roughly the same age as Gareth, but I have been writing code for probably about 25 years because I didn't start when I was three.

04:14 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 dot engineering work with, I guess, in the American sense, you'd fall a mortgage provider in South Africa, my current employer.

04:30 Yeah, fantastic.

04:31 Lukash, welcome back.

04:32 Hi, I'm the core developer in residence for CPython.

04:35 So actually getting money from the Python Software Foundation to help develop Python.

04:40 Just yesterday, we released six simultaneous versions of Python at the same time, which I think is a record.

04:47 Yeah.

04:47 So I mostly do that.

04:48 I don't program for 40 years.

04:50 I'm 37 at the moment.

04:52 Still maintaining 37 because my birthday is March.

04:56 So like approaching quickly, but you know.

04:58 Don't let 38 get you.

04:59 Yes.

04:59 I'm not almost 40.

05:01 I'm 37, you know.

05:02 Awesome.

05:03 Well, congratulations on all the great work.

05:05 I know you've done a ton of work to keep CPython moving forward.

05:10 Yeah.

05:10 Thank you.

05:10 There seems to be like more and more to do, actually.

05:13 So just looking at 3.1.1 that we released yesterday, it had like almost 500 comets since 3.11.0, which is kind of unprecedented as a rate of change.

05:24 So, you know, kind of, we have so much kind of velocity right now that I have never seen before.

05:30 So a lot of change.

05:31 Amazing.

05:32 I talked to Ned Batchelder on another podcast that we were doing.

05:35 We'll come out before this one.

05:37 And we looked.

05:38 The change log for CPython is 175,000 words.

05:42 A typical novel is 80,000.

05:45 So that's a lot.

05:46 That's nuts.

05:47 Cecil, always good to have you on the show.

05:49 Welcome back.

05:50 Sure.

05:50 Thanks for having me.

05:51 Hi, everyone.

05:52 I'm Cecil Phillip, developer advocate at Stripe.

05:54 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.

05:59 So not fully there yet, but I'm still working on it.

06:02 Primarily been doing a lot of .NET stuff, some Python stuff.

06:05 Recently started playing around with Go.

06:07 Maybe we'll talk about that, you know, in the midst of this conversation as well.

06:10 But other than that, you know, I, you know, as an advocate, I spent a lot of time doing video and going to conferences and doing demos and stuff.

06:17 So I kind of feel like my job is to learn stuff to an extent.

06:20 You know what I mean?

06:21 There's a lot of that that happens.

06:22 And, yeah, I kind of have a lot of fun doing it both, you know, for work and, you know, outside of work.

06:27 Yeah.

06:27 That sounds like a great job.

06:29 Emily, welcome back.

06:30 Hi there.

06:30 I'm Emily Morehouse.

06:31 I'm the director of engineering at a company called Cuddlesoft.

06:34 We are a kind of digital product consultancy focusing on, you know, user experience for full stack applications.

06:44 But we also get into some of the nitty gritty stuff.

06:47 So we kind of do that full spectrum DevOps, firmware, middleware development, web applications, all the way through design.

06:56 So I get to touch a lot of different pieces of technology.

06:59 A lot of my work is in Python, but not all of it.

07:02 I write a lot of Ruby, a lot of JavaScript kind of across the spectrum.

07:06 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.

07:14 I found world and the Ruby world and kind of down that stack.

07:17 So, yeah.

07:18 So this topic is right down right in your wheelhouse.

07:21 And I think also the consulting side, the agency side is interesting because you work with one group.

07:28 You say, here's what we recommend for you.

07:29 Oh, another group has another company has a different set of software skills.

07:35 So you might recommend something different in that case, right?

07:37 Yeah, absolutely.

07:38 And the technical expertise that our clients come with is very wide reaching, right?

07:43 So some people are completely non-seqtical, don't want to touch it, don't want to know anything about it.

07:48 We're going to be able to connect 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.

07:55 And there's a lot more kind of risk management for this, right?

07:59 Like we can't build something for our client that then we're going to say, you know, your library isn't supported in six months.

08:05 So it also gives us a chance to start fresh a lot, right?

08:09 Like most of our projects are greenfield.

08:10 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.

08:19 And we think that this is a really good place for you to be and get a chance to like actually build something with a new library more so than like convincing, you know, a company to rewrite their Django application and something else.

08:32 Right.

08:33 You also were the chair of PyCon.

08:35 Is that the right title?

08:36 Yeah, I forgot to mention that.

08:39 I'm the recovering chair.

08:41 I'm chair emeritus now.

08:42 Yeah.

08:43 Yeah.

08:43 So I was going to ask.

08:45 I heard that there's a support group somewhere.

08:45 I'm sure there is.

08:47 Not overseeing 2023, are you?

08:49 No.

08:50 I'm taking a break.

08:52 Yep.

08:53 Fantastic.

08:53 All right.

08:54 Well, thanks for that.

08:55 Dan, welcome to the show.

08:56 Thanks.

08:57 I'm Dan Gerlank.

08:58 I've been doing software development professionally for 20 years to some degree, more in one capacity or another.

09:08 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's kind of like a brokerage for television advertising.

09:22 Prior to that, I actually ran my own consulting job for a decent amount of time.

09:28 So I've worked on that agency side a bit and also started my career in quant finance.

09:34 I've worked across a wide range of things.

09:38 And I'm pretty involved with the Asara project these days on the open source side.

09:44 I can also do a bit of teaching on the side.

09:47 I've taught on O'Reilly about pandas and different things from time to time.

09:52 So.

09:52 Fun.

09:53 Yeah.

09:53 Teaching.

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

09:58 For sure.

09:59 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.

10:07 Motivate you.

10:08 That's right.

10:11 I guess conference speaking kind of works that way, but it's not as back and forth as well.

10:15 All right.

10:16 So let's kick off this conversation with maybe a story from some of you.

10:21 So I wanted to start with just maybe a story how you've chosen some tech stack or some database

10:29 or some new framework.

10:31 You know, a lot of leeway in the scope there.

10:35 But, you know, whoever wants to jump in, just, you know, what?

10:37 Give us a story of something you've sort of gone down that path recently.

10:40 Well, I'll jump in and talk a little bit about like the strategy of how I choose to learn

10:45 stuff.

10:45 And I think it's important that you have a learning or a choice strategy, at least for me, because

10:51 like there's just so much stuff to play with.

10:53 And like there's only so many hours in the day.

10:54 And so you always have to be like surgical with your time about like what you choose to

10:58 do.

10:59 And so one of the things for me is like, I don't build production applications.

11:03 And I think that's an important thing to note.

11:05 So, you know, everyone else's perspective might be a little bit different.

11:08 But like most of the apps that I'm building, I am beta testing stuff.

11:12 I'm creating things for other folks, you know, doing proof of concepts with companies and

11:16 stuff like that.

11:17 So now when you think about the things that I have to learn, I usually have to learn things

11:20 to like get it to work for a little bit.

11:22 And then I'll walk away and I'll go do something else.

11:24 Right.

11:24 Like I don't learn it with the perspective of I have to maintain it over a long period of

11:29 time.

11:29 Now, that is not important that I do it the right way.

11:31 But again, you know, the perspective is just a little bit different.

11:34 So for me, one of the things that I often try to do is, you know, try to find the thing

11:39 that like, I'm really interested in doing.

11:41 I like the thing that'll be useful at work and try and like plug those things together.

11:45 Right.

11:45 And like try and see how we can find some symmetry there.

11:47 And so an example would be like one of the things I'm playing with right now is open telemetry.

11:52 Right.

11:53 Now, I don't work for an open telemetry company.

11:55 And, you know, that's not a thing that we have libraries or extensions for.

11:58 But at the same time, too, like, you know, we think about as we're building apps, right?

12:02 Like, you know, inspection is an important thing.

12:04 Right.

12:04 And being able to give folks guidance is an important thing.

12:06 And so when people come to me as an advocate and ask questions, I might not have to know

12:12 everything in detail, but I try and know things enough so that I can at least have an opinion

12:16 and have a conversation about it.

12:17 You know, be able to speak intelligently about it, even though I might not know like all

12:21 the knobs and whistles and like dials I have to turn to like get the thing to work.

12:25 You know, one of the things that I think would be really important for that role is really

12:30 carefully tracking where's the momentum in frameworks.

12:34 Maybe it's not the most important or widely used thing at the moment, but in six months, you

12:40 know, a little bit of the Gretzky quote, you know, where is this thing going and what

12:43 is the advice you're going to give to people?

12:45 Yeah, I agree with that.

12:46 And that also, again, kind of goes into the strategy, right?

12:48 Of like, what am I learning this thing for?

12:51 You know what I mean?

12:52 Like, am I learning it to, again, like, am I learning it specifically to achieve like a

12:58 particular personal goal?

12:59 Is there something that I'm trying to fix?

13:00 Am I trying to, am I trying to like explore technology so I could pick and choose the thing

13:05 that I want to do, right?

13:05 Like, like what exactly am I learning this thing?

13:07 Am I learning it to teach it to someone else, right?

13:09 Like, no, that's, that's a completely different perspective as you're trying to figure out,

13:13 well, how do I kind of zone into the thing that I'm trying to do?

13:15 Yeah, I was going to add something to what Cecil was saying there.

13:18 One of the important things that you point out that you often end up doing is maybe helping

13:22 people select a framework or a piece of tech stack or something to use.

13:26 And the kind of thing that always, that used to strike a lot of the teams I've worked on,

13:30 and I certainly was guilty as anybody else, is spending a heck of a lot of time going back

13:34 and forth thinking, well, we could use this one or we could use this one and let's try

13:37 this one.

13:37 Well, if I take three days to try this one, and then next week we'll take three days to

13:40 try that one.

13:41 And ultimately, if somebody's paying you to write software, it's kind of an important

13:45 lesson to remember that ultimately you have to pick something and it'll be good enough.

13:48 Your job isn't actually to pick the right thing and spend a month on it.

13:51 There are other things they're paying you to do.

13:53 So one of the important things to think to take stack selection is basically, if it's good

13:57 enough, that's fine.

13:58 If it's not good enough, then obviously it must go.

14:00 And it's useful to have somebody like Cecil to be able to tell you if it's good enough.

14:03 But we can make them step seeking out kind of perfect.

14:06 Is there absolutely anything wrong with this?

14:09 Now we'll use this one.

14:10 Let's try that one and stick it.

14:11 Maybe it'll be better.

14:12 And three weeks later, they're saying to you, why haven't you met the deadline?

14:14 Ah, but we have the perfect tool.

14:16 Haven't used it yet.

14:17 It's taken us a month to find that.

14:18 We have the perfect tool now.

14:19 Yeah.

14:19 It's an easy trap to fall into.

14:22 It is.

14:22 And I think a lot of people probably fall into it.

14:24 And you got to decide, is this a one-way door or a two-way door?

14:27 Is it the gate at the exit of the airport?

14:30 Like if I make this choice, how committed am I to this thing?

14:33 Because if you try it for a week and it's not what you thought it would, you could come

14:38 back and try something else.

14:39 Then why spend three weeks before you even start, right?

14:42 You've learned a lot in that quote failure, right?

14:45 This portion of Talk Python Nemy is brought to you by Cox Automotive.

14:50 With brands like Kelly Blue Book, Autotrader, Dealer.com, and more, Cox Automotive flips the

14:57 script on how we buy, sell, own, and use our cars.

15:01 And now the team at Cox Automotive is looking for software engineers, data scientists, scrum

15:07 masters, and other tech experts to help create meaningful change in the industry.

15:12 Do you want to be part of a collaborative workplace that values your time and work-life balance?

15:17 Consider joining Cox Automotive.

15:20 Visit talkpython.fm/cox today.

15:23 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.

15:33 The experience I had with large companies I worked for was that they often would choose

15:39 technology that was utterly boring and not interesting even at the time when they did choose it, but

15:47 became dated very quickly.

15:50 And it didn't matter one bit.

15:51 Like Facebook was PHP, MySQL, and Linux, right?

15:55 Only when they already grew, it wasn't really Linux, it wasn't really MySQL, and it wasn't really PHP.

16:00 But at that point, you already have enough infrastructure and enough employees and everything to actually,

16:08 you know, keep it going anyway.

16:09 Same with like Instagram that was purchased by Facebook, but it was Django, right?

16:13 And still Django.

16:14 But it's not really Django.

16:15 It doesn't matter.

16:16 Like it brought them to where they are through it being an established technology.

16:21 And I would in fact kind of err on the side of boring because it's going to be there for you,

16:27 you know, going forward.

16:29 And that's important, especially like, you know, if you're choosing a data store, like you want to

16:33 choose something that, you know, like you're not going to have to migrate from in a year or two,

16:37 because that's not something that is a productive use of your time.

16:41 So I'm going to kind of contradict what I'm saying now very often as part of my job and say,

16:47 you shouldn't be an early adopter.

16:49 But well, in case of CPython, you absolutely should.

16:52 And you should test our alphas and test our betas.

16:55 But you know, you have your CI for that.

16:58 So it's a safe environment.

16:59 Like don't run 3.12 in production right now.

17:01 Do test with it, right?

17:03 So this sort of thing.

17:04 And Python, yeah, it's already like you can use 3.11.1 just fine.

17:08 It should be okay.

17:09 Since we are with our annual release cycle, a kind of in sync with Linux distributions,

17:16 which are doing testing of a new Python version as part of their release for October.

17:23 So Fedora and Ubuntu test our newest Python.

17:26 So it's kind of best tested as it ever was.

17:30 But when it comes to your data store, when it comes to your web framework, you know,

17:33 choosing something that is extremely new.

17:35 And well, we're not sure if it's going to stay forever.

17:39 It's maybe, maybe a kind of a bold choice.

17:42 Unless it's like a 10, 10 X multiplier of your productivity.

17:46 I would just choose the boring thing.

17:48 Well, your advice about CPython, you know, 3.10 versus 3.11.

17:52 It's not the same as Django versus FastAPI, right?

17:55 It's like the evolution of the thing, but you could always roll back a little bit, right?

18:00 It's, it's a little bit different.

18:01 Oh yes, absolutely.

18:02 So it's like, I don't know, Postgres 13, 14 and so on and so on.

18:06 At the same time, like, you know, kind of obviously technology changes.

18:09 And even if we're not talking bugs, but just plant deprecations, that there might be some disruption

18:14 when, whether, you know, upgrading to a newer Python version.

18:17 Nowadays, much smoother than it was between Python 2 and Python 3.

18:22 So it shouldn't be a big deal.

18:24 But it might be a deal depending on what third party libraries you're using.

18:29 So yeah, obviously there's considerations for you, which is why we would like you to test with 3.12, like in your CIs and so on and so on.

18:37 It's already there.

18:37 Just put it as a run target.

18:40 Yes.

18:41 But you know, kind of when it, when it comes to third party projects, I am usually very boring.

18:46 And, you know, kind of, I was the last person from my friends to actually adopt VS Code and

18:52 the last person to adopt Phish.

18:54 You know, like I was happily with Bash and then I switched to ZSH just at the time when it started

19:00 being boring, you know, and I was like, come on, really?

19:03 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.

19:10 And I think it goes back to what Cecil was saying earlier about needing to have some sort of like

19:14 framework for how you make these decisions.

19:16 And so I think that it's important to call out that a lot of times you need, you need a base set

19:22 of criteria when you're evaluating a tool, right?

19:24 Like, please like check the license, make sure that you're even allowed to use this thing for

19:29 whatever you're doing.

19:30 And then a lot of it kind of gets into that risk tolerance where it sounds like Lukash probably

19:35 is on like the very stable side of it versus the leading edge side, you know?

19:39 And so you've got to say, do I care about doing the new and exciting thing?

19:43 Or like, should I make the obvious choice to make sure that I have that long-term stability

19:47 that you would get from, you know, choosing Django over FAPS API sort of situation?

19:54 Yeah, absolutely.

19:55 Gareth, how about you?

19:56 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 Lukash's world of boring is good.

20:05 So, you know, it's, you always want to go for the tried and tested.

20:08 If it's product, there's a marked difference between working in production and working in

20:14 the, in the wider, in, in learning mode.

20:16 So you've got Cecil's world of pulling the latest stuff, trying out new technology and playing.

20:21 But if you're going to build a web frame, build a web app, then it's going to be hard

20:25 not to choose Flask or Django still, because it's there, it's around.

20:29 And at the moment, all my, all my current examples.

20:32 So I, I'm currently at a company called My Energy and we process huge amounts of user data

20:37 and we paid a company to write a platform for us.

20:40 And it feels like they just went through NPM and installed anything they ever wanted all

20:44 the time.

20:45 And now we're unpicking a load of...

20:47 NPM install star, let's go.

20:49 Yeah.

20:49 And it, you know, and it feels like they're playing a drinking game with type, with TypeScript

20:54 and this bit's functional and this bit's object orientated.

20:57 And so, you know, picking technologies, not just picking technologies, picking paradigms.

21:02 So it's TypeScript.

21:03 That's great.

21:04 But is it functional?

21:05 Is it object orientated?

21:06 Is it procedural?

21:07 And the answer is this bit is, and this bit isn't, and this bit's over here.

21:10 And then we need a type boat.

21:12 We need an ORM.

21:13 So it feels like they pull in the only ORM that they've seen in a tutorial that somebody,

21:18 somebody's written.

21:19 So we've got TypeORM, which doesn't do migrations and you're stuck.

21:22 And we've got a massive pile of technical debt on a brand new project, which you're having

21:27 to unpick because no one consciously chose the projects.

21:31 Or is it known?

21:32 In my last gig, we spent a lot of time because I've got horror stories about Zoop.

21:40 But there's, you know, we spent a lot of time choosing the right framework and having the

21:45 right reasons and put in a lot of effort into writing proof of concepts because we knew the

21:50 traffic demands.

21:51 We knew what we were doing.

21:52 And we went Flask and we went certain technologies in AWS.

21:56 We went Docker.

21:57 We went and just follow this route through choosing things to be stable and scalable, not necessarily

22:03 the latest and greatest, not necessarily the most cutting edge.

22:05 We just wanted to make sure it was, we could develop on it.

22:09 And even then we chose, badly chose a library because somebody followed tutorial.

22:13 We didn't really think about end up using a REST framework that got deprecated.

22:18 And so, you know, there's, you have to put the effort into choosing the right things and

22:23 be okay with going, I don't care if we're not cutting edge.

22:25 We let Cecil be cutting edge and go and play in his dev advocate role.

22:29 And then once it's in production in other places, then you use it.

22:33 Yeah.

22:33 This distinction between like, what do you choose in production and what you choose other

22:37 places.

22:37 Also, you know, it doesn't necessarily have to be just learning, right?

22:40 It could be, well, here's some tools that just like kind of pull in data and process it.

22:44 But if it's not perfect, it, the website is not going to go down and we're not going to

22:48 lose, you know, a thousand dollars a second until somebody fixes that type of situation,

22:53 right?

22:53 It's, oh, somebody's got to fix the ETL.

22:55 Well, and I think that's another big part of it is in most companies, your job or your

23:01 function with the company is not supporting a web framework or building out features within

23:05 a web framework.

23:06 You're trying to implement whatever business logic you need beyond that.

23:12 So going to something tried and true or older is going to let you do that.

23:17 And it may not exactly meet your use case.

23:20 But like Lukash was saying, once you have enough, once that's, if you have enough revenue,

23:26 that that's a problem.

23:27 If you're Instagram or Facebook, well, that's a good problem to have.

23:31 You can deal with it at that point.

23:33 Yeah.

23:34 Yeah, absolutely.

23:35 Well, and for you, Dan, the situation might be a little bit different as well.

23:38 Being more doing like ML type of things.

23:41 There's less tried and true, right?

23:43 Yeah.

23:43 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.

23:49 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.

23:53 A lot of stuff we worked on.

23:55 And I think some of it is that I've spoken with folks who are building ML companies and

24:01 they're like, yeah, the scale you're operating at is like 10 times or 100 times anything

24:07 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

24:17 us, but it was first, can we actually use those existing frameworks?

24:21 Because we ideally, we're not an ML platform company.

24:26 We want to use whatever the framework is we can because that will get us our job done.

24:32 Only when we can't do that, did we really need to go custom and kind of build things

24:40 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

24:46 as awesome as possible or to get it going just right.

24:49 And really it's to deliver functionality to a business, right?

24:52 That's just a means to an end.

24:53 So yeah, for sure.

24:54 I could maybe, maybe just a thought on that that began to be when we were talking about

24:58 boring.

24:58 The other thing that kind of can be very tempting is if me or I, the team, I come across

25:03 a new fantastic tool.

25:05 I think this looks great.

25:06 Let's use this.

25:06 I've been half an hour reading a tutorial that's going to point it out.

25:10 I know everything there is to know about it.

25:11 It must be great.

25:12 I work it into the project.

25:13 We don't touch it.

25:14 You know, we make it work.

25:16 We don't touch it for a week after that.

25:17 Then I'm on leave three weeks from now on the beach somewhere and it goes wrong.

25:21 Have I bothered to tell the rest of my team how this thing works?

25:24 Because I've chosen something that isn't boring, you know, that doesn't fit in with

25:27 the stuff the rest of us all know.

25:28 And now there's a huge problem there.

25:30 So there's, you want to give a bit of thought to that as well.

25:32 You want to be consistent with the stuff you use.

25:33 Sometimes, as Gareth was saying, in terms of paradigm, there might be shiny toys that

25:38 don't fit in with the rest of it.

25:39 And I'm afraid you've got to leave the shiny toy behind.

25:41 Unless, I mean, for, again, we are talking in the, what you're paid to do.

25:44 So it's obviously the toy you own and your own bat, shiny toy away.

25:47 Yeah.

25:47 You got to think about the team buy-in as well.

25:50 If our group's going to be using it, right?

25:52 We fund development sprints and we fund hack days to play with things.

25:57 So let's get, if you've got an idea for, you know, do you fancy using FastAPI?

26:02 Then let's build a small thing in it and we'll put a small project in, see how it works, see

26:07 how it deploys.

26:08 But don't bet the farm on it until you're certain about it.

26:13 That's a great, great way to do it, right?

26:15 It's sort of a more structured way to experiment.

26:17 So I'll share a quick story with you all here.

26:20 Recently, I wanted to re-kindle my blogging.

26:24 I don't know.

26:25 Social media and places are a little scrambled these days.

26:28 So I thought it might be a good idea to have something written as well that I can point to.

26:32 So I went to make this website and I thought it's something simple, something marked down,

26:36 something static.

26:37 And I don't know, I've done that.

26:39 My last blog was on WordPress.

26:41 I don't want to use WordPress anymore.

26:43 I don't want to have a database for my blog.

26:47 That seems like overkill.

26:48 So I'm like, all right, well, what do I do to decide?

26:51 So I went out to the community and I asked, hey, I'm thinking about this static website blog thing.

26:59 Python tools preferred, but I'm open for anything.

27:02 And Kim, I think you even maybe weighed in on this thread over here.

27:05 I think I did, you know.

27:05 Yeah, I think you did.

27:06 And I got a bunch of different feedback.

27:09 And so my solution to sort of exploring this place where I felt a little unqualified,

27:15 I didn't have really much experience with, was to go out and ask.

27:18 And the answer I got back really surprised me.

27:22 I thought, well, maybe it's going to be Pelican or Ghost.

27:24 But a bunch of people started saying, Hugo, Hugo, this thing is Hugo.

27:28 It's amazing.

27:29 Obviously, there were people saying Pelican and Sphinx and whatnot.

27:32 So I ended up going with Hugo, which was a bit of a struggle for me to decide because it's unbelievably good.

27:41 Kim, are you using Hugo as well?

27:42 Yes, yeah, for a couple of things.

27:44 It's glorious.

27:45 It's so nice for writing, but it's written in Go.

27:48 And so it's like, well, can I?

27:50 I can't really fix it or tweak it as easily.

27:53 But in the end, I decided, you know what?

27:55 It's more important to have something that works really, really good that has got a lot of popular support

28:00 than having something that is in a language I'm an expert in.

28:03 So I'd kind of like to hear your all thought.

28:05 If you're in that kind of situation, what's your process?

28:08 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.

28:17 So I went through a similar process.

28:19 What I ended up doing is, and you know, obviously it's a super anti-pattern, but it turned out to be super successful, which is just write your own.

28:28 And obviously everybody writes their own static site generator.

28:31 But like, I'll be honest with you, like with Python in 2020 and 2021 and 2022 now, like it is so simple because they're like all the building blocks are there.

28:43 Like you're not, you're not writing strings of HTML into a file.

28:47 Like, you know, like all of those kind of building blocks are done for you.

28:51 And just let me bring up like for you how big my huge site generator is because it's like, it's super tiny, but it actually handles like everything I wanted to the extent where I'm using it for a couple of sites right now.

29:04 And it's like what, and it's under 2000 lines of code at the moment, like the entire thing.

29:11 So it's like, it's not super big.

29:13 And it was growing like, you know, in time when I was adding new stuff to it.

29:17 For example, at first I just did not have RSS at all because I was like, this thing is dead.

29:22 Like nobody needs RSS anymore.

29:24 And then a bunch of people just told, tell me like, Hey, like, why don't you have RSS?

29:28 So I just added it like later on, you know, and it's just what, like, oh, we have XML in the standard library.

29:34 And there's actually like, yeah, RSS libraries too.

29:37 But like, this is so simple.

29:38 You just have like, you know, this one template that you need to output.

29:42 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 3.10.

29:48 I should just recreate the virtual.

29:51 And so I'll, I'll be able to say 3.11, but you know, kind of.

29:54 Then you'll be cutting edge.

29:55 So yes.

29:56 But like the reason why I actually did this was that all the notes that you're seeing there, you know, kind of, if you feel like click through the thing, like they are in fact, like in Markdown in my notes.

30:08 So I'm kind of crazy about having notes.

30:10 So like, I have a lot of them, right?

30:13 So I have like thousands of them and they're like all in Markdown and like in a Git repository, synchronized over to my phone and whatever.

30:20 So I can always just access them in a plane or whatever.

30:23 So those are just tagged hashtag public in the Markdown text and they appear on the website and it's kind of automatic.

30:31 So I don't actually have like a CMS for this.

30:34 I just have my notes app that I'm using is FS notes is open source.

30:38 It works on the Mac.

30:39 It's glorious.

30:41 And it's also, you know, on iOS and, you know, and you just kind of generate HTML out of that, which is pretty simple.

30:49 And I can automate a bunch of stuff with this just kind of custom made, which with Hugo, I probably could do, but, you know, I would have to learn how, and I already know Python.

30:59 So it was really, it really took me no time to get this up there.

31:03 And it kind of works on the phone and it's okay.

31:06 It's not, it's not going to kind of wow you, but it's a perfectly functional website, you know.

31:11 Yeah.

31:11 Jay out of the audience says, building your own static site generator is a great way to learn a lot about language.

31:16 I learned a lot for you just maintaining my own static.

31:19 I mean, choosing static sites is an interesting choice on its own, right?

31:23 It's the DevOps story is incredibly nice that you don't have to worry about, you know, will the database go down?

31:29 What, what kind of problem is, you know, it's, it's either going to be there or it's just not there.

31:33 Will the database go down?

31:35 The unspoken, the unconsidered problem until you're in the DevOps space on a non-static site is when your internal department would like us version of the site, they can change the CMS on to make sure it all looks good before they roll it to production.

31:48 Now you've got to get database exports across into a different database, or you've got to get migrations going.

31:52 But I had, 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 files from one to the other.

32:03 There you go.

32:03 I would never do that.

32:04 Of course, of course.

32:08 This portion of Talk Python To Me is brought to you by Sentry.

32:11 How would you like to remove a little stress from your life?

32:14 Do you worry that users may be encountering errors, slowdowns, or crashes with your app right now?

32:20 Would you even know it until they sent you that support email?

32:23 How much better would it be to 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?

32:34 With Sentry, this is not only possible, it's simple.

32:37 In fact, we use Sentry on all the Talk Python web properties.

32:40 We've actually fixed a bug triggered by a user and had the upgrade ready to roll out as we got the support email.

32:47 That was a great email to write back.

32:49 Hey, we already saw your error and have already rolled out the fix.

32:52 Imagine their surprise.

32:54 Surprise and delight your users.

32:56 Create your Sentry account at talkpython.fm/sentry.

33:00 And if you sign up with the code Talk Python, 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.

33:11 Create better software, delight your users, and support the podcast.

33:16 Visit talkpython.fm/sentry and use the coupon code Talk Python.

33:24 But it's also unhackable.

33:25 That's an interesting...

33:26 There is that.

33:27 Yeah, the worst thing that could happen is it could deface.

33:30 It could get defaced.

33:30 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.

33:39 You're right.

33:39 That's a good point.

33:40 Hard to hack.

33:41 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, and, you know, it just...

33:49 Yeah.

33:49 It's good.

33:50 Mine is on Netlify as well, and I gotta say, it's really, really a relieving nice thing.

33:56 One comment that we were making about picking a library, something that you pointed out and that Luke was just saying as well.

34:01 There is something to be said for making sure you can fix it if it breaks.

34:04 But I think to the large degree, it depends on how...

34:08 I suppose it depends on several things.

34:09 How important the thing is to you, how quickly you can change it if it does break.

34:13 And how kind of big the thing is.

34:16 It never occurred to me, for example, using Hugo, it didn't worry me too much that I don't know any go and I can't fix it because it's a big enough tool that I can probably make it do what I want.

34:25 But I've got pretty simple needs.

34:27 If I was picking a very fast, something really low level in kind of my previous C 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.

34:40 Because maybe I need to be able to tweak it or otherwise.

34:43 It also depends on what you need the thing for.

34:44 How much does it matter?

34:46 Whether you can tweak it or not.

34:48 It's supposed to depend largely on how important it becomes to your project.

34:50 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.

34:57 I'm like you.

34:58 I don't know any go.

34:59 Not really.

34:59 I mean, I've read like a paragraph of sample code to know what it looks like.

35:03 But that's about it.

35:03 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 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.

35:20 Here's the thing I run on the command line and it either makes the static site or it doesn't.

35:24 So it's not, you know, in the important path of interactions.

35:28 You could swap it out without your website breaking.

35:29 The end result will still be up and live on the website while you're replacing Hugo with something else if you want to.

35:35 Yeah, exactly.

35:35 There's a consideration there.

35:36 Go down the Lucas route and try to recreate the same look and feel.

35:40 Yeah.

35:41 So unlikely it would break and not be fixed by core Hugo devs or like 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 has been forked 7,000 times and has 64,000 stars?

36:04 Like, okay, if it breaks, someone else will fix it.

36:06 Not my problem.

36:07 If it had six stars and it breaks, it might be my problem if it breaks, even though it's not my project.

36:13 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.

36:23 Like things like forks and stars are like vanity metrics for me.

36:27 Like I don't really care, to be honest with you.

36:29 I do care if, you know, it, one, it solves the problem I'm trying to deal with.

36:34 You know, can I submit an issue and get, you know, relatively like within six months, like someone answered me fairly quickly.

36:42 Like I don't want to wait for a response.

36:44 And, you know, is it, is it, you know, are there commits being, even to that too, right?

36:48 Like when I say, are there commits being made?

36:49 You don't need to be making commits like every day and every hour or every week or every month.

36:53 If I see the, like 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 dump into because I don't know if I'm going to be able to get the support that I need.

37:04 Well, you still might take 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.

37:10 So I'm going to use you as an example, Michael.

37:13 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?

37:19 Now you're going to be in a position that you can either learn go or you're going to swap it out and go with something else.

37:24 Right.

37:24 But, you know, like, what do you, what do you do?

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

37:30 Well, see, so see.

37:31 Not that I hate go or anything.

37:32 I just like, you know, I think thinking of just a time effort sort of trade off, you know?

37:37 Yeah.

37:37 So again, for me, it's mainly just about like, how do we like, does it solve the thing that I want to solve?

37:43 And then can I get like some level of support, you know, questions answered and documentation and stuff like that?

37:48 Yeah.

37:48 So when I looked at this, you know, commit last commit yesterday, there's a bunch of issues.

37:53 But if you look at, say, the closed ones, there were issues closed a couple hours ago.

37:58 Full requests, I suspect probably those are linked together.

38:02 Right.

38:02 So there's clearly the life in this project.

38:04 And to me, that probably is enough.

38:06 How about the rest of you?

38:07 Emily, what do you think?

38:08 Yeah, I totally agree.

38:09 I think these are exactly the things that I look at is, you know, are things getting updated or commits getting in?

38:14 You know, if it hasn't had a commit in a year or two, sometimes that's still okay.

38:19 Right.

38:20 Like sometimes you're looking at Django reset password library that like, yeah, it's just, it's continued to work over time.

38:28 And you don't necessarily need new features added to a reset password kind of thing.

38:31 So knowing kind of what you're looking at and what you need out of it, I think is still important.

38:35 But I totally agree.

38:37 You know, forks and stars, even downloads are kind of vanity metrics.

38:40 I also think that something else that I always look at is, what is the audience of the tool, right?

38:45 So Hugo is very much geared towards a community of people building for, you know, mass numbers to use it versus a tool that maybe, you know, Lukash's 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.

39:02 But it's not going to be a tool for the message.

39:05 We have a visual decline.

39:07 Just a, hmm, no, enough projects.

39:10 Knowing what you're getting out of it and knowing like 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.

39:18 This is something that is going to be very opinionated for someone's specific use case versus like Hugo is going to continue adding functionality that would serve a broader group of people.

39:29 And just using that as part of your metrics for deciding if that tool fits your needs.

39:34 One thing that I used to do is I look if the last comment on the thing doesn't need to be super recent, but like, is the build red or green?

39:44 And if it's red and like, I'm like, you know, I don't like seeing red in the last comment on the project I want to use.

39:52 And often if that would be a critical dependency, I would in fact just clone it locally and just try to just build it and see if tests pass on my end.

40:02 And if they do good.

40:03 And if I cannot download some dependencies or like pytest has like 15, you know, failures or whatever else, then I'll be like kind of more skeptical now.

40:12 Because obviously if you are installing a package with pip install, unlike with CPAN in the Perl universe, you run no tests.

40:21 So you kind of only the only thing you know is that the files were put in the right place.

40:26 But whether they are going to work, well, you're just going to find out like at runtime, I guess.

40:30 So yeah.

40:31 So like every now and again, I would just try to build something when I actually depend on it.

40:35 But, you know, kind of that's if it's really critical because all of the dependencies like, yes, like even downloads are a vanity metric because if, you know, 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.

40:53 So like when Emily said that it's a vanity metric, like my heart was, you know, like kind of hit like right in the middle because, yeah, I live by those downloads, man.

41:02 Like it's awesome.

41:03 I have never expected this to go so big.

41:06 So like, you know, it's still sometimes like I would just like sit and drink coffee and just suddenly think, how did that ever happen?

41:12 It's just, you know, it's mind blowing.

41:13 But actually, so 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?

41:22 Like uncompromising code formatter, like it's very clear that it's very opinionated and that a lot of it came from you.

41:29 And, you know, 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.

41:43 So like, again, knowing what you're getting into of 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.

42:01 This is just something that's here.

42:02 If you like it, use it.

42:04 Great.

42:04 But, you know, 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.

42:18 And like, I do relatively little these days, honestly, like there's a bunch of people who are super like, you know, active and they make, they actually kind of shook me out of this kind of psychological block to like, you know, a stable version has to be perfect.

42:34 We will never get there.

42:35 And, you know, like over 2021, we churned out a lot of releases and now like, yeah, Black is stable.

42:41 It's amazing.

42:42 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?

42:51 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?

42:59 You know, like, is there more than one person with the keys to the kingdom?

43:02 Because sometimes if you lose the keys for whatever reason, like it's, you know, very disruptive.

43:08 Like we had a bunch of libraries like that in the Python world where forks were necessary because, you know, the original maintainers like lost interest or life or whatever else.

43:18 So, you know, things, things happen.

43:20 I cannot really say that, you know, I did anything like that, like, you know, kind of, well, like I planned for it.

43:27 Like it mostly happened by accident because it just had like nice contributors that I liked.

43:32 So I just shared the right access with them and they ended up being very trustworthy.

43:36 But, you know, a maintainer should do that at some point because you cannot just do everything, you know, by yourself.

43:43 It's just impossible.

43:44 The bus factor is interesting.

43:46 There was this guy who had an NPM project, JavaScript project, who had done some kind of like 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.

44:04 And it was really frustrated that companies were using the project and not paying for it.

44:09 It was open source under like MIT or something.

44:11 But, you know, that was his take.

44:13 But then had a full on breakdown and got arrested for creating bombs in Queens, New York.

44:18 That's an extreme example.

44:20 But it can happen.

44:21 Something could happen, right?

44:22 Like, or, you know, somebody could just get actually in an accident or they could have a health crisis, right?

44:27 Like, could be a place where it stops.

44:28 So, considering that is...

44:30 On the topic of bus factor for that matter, which, I mean, I think fairly obviously what it means, just in case anybody needs a definition, you know, if you're the guy, if you're the only person who knows how it works and you get hit by a bus tomorrow and you spend four weeks in hospital in the somewhat sanitized version of the theory, can somebody pick it up after you?

44:48 And I think one of the things that does feed into picking tech stacks and tech stacks and so forth is the bus factor on the libraries and so forth is quite important.

44:57 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 suddenly made a bus factor issue there 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.

45:15 There's a consideration there for the complexity of a tool as well.

45:18 Sometimes it's unavoidable.

45:20 Sometimes some things that you have to do are complex.

45:22 But if the tools are...

45:24 If you're constantly picking the hardest thing there is...

45:26 Well, hardest.

45:27 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.

45:32 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.

45:41 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.

45:54 And everyone was like, great, it works.

45:55 I love it.

45:56 Yeah.

45:57 One of the things I think is interesting there, 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.

46:10 Which as technologists, it's just not a thing that we do.

46:12 So again, like the bus factor, right?

46:13 Like something bad happens to the person and now what do we do now, right?

46:18 Like what is the next step, right?

46:19 Yeah.

46:20 Another thing that I've noticed a lot, again, like kind of thinking about like the humanity of learning is a lot of the times people choose things because the person to their right and their left, the person, the people that are in their circle of influence are using that thing.

46:34 Right.

46:34 So I'll give you an example.

46:36 Like, so I go to a lot of like senior design showcases at colleges and universities and so on and so forth.

46:41 And when I kind of look and I say, oh, well, why did you pick this language?

46:45 Or why did you pick this cloud?

46:46 Or why did you pick this framework?

46:48 It's usually because the people around them are doing it too.

46:50 Right.

46:51 And the reason that is, is now, hey, if I pick the thing that like Michael is using or Emily is using or Kim is using, you know what?

46:59 I have people that I could go ask the question.

47:01 You know what I mean?

47:01 So now I'm going to choose that thing, not because of any technical reason.

47:05 I mean, obviously it has to do the thing I want it to do.

47:08 But like the main reason I chose it is because like socially speaking, like I have people that I could go ask the question.

47:14 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, really important factor.

47:20 Yeah, I think this hits the nail on the head because like 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.

47:31 And that person is no longer around.

47:33 And now like we obviously can still, we have access to the code, like we have tests that are passing.

47:39 We can still maintain the code, right?

47:41 We can still mutate it.

47:42 We can still make it to different things if we need to.

47:44 But the one missing piece, which is sometimes needed and we don't have it anymore, is why certain, you know, choices were made originally.

47:54 Because that kind of informs where we should go next, right?

47:58 Like if something is kind of uncharacteristically convoluted and you see this and you're like, oh, I would simplify this, right?

48:06 Like, you know, after a while of core development, you're like, every time you want this, there is a reason behind like every kind of, you know, like weird, weird part that you're going to find.

48:17 But if there's nobody to ask the question to, like that complicates things a lot.

48:22 And, you know, we have a bunch of situations where 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, to kind of make a choice.

48:36 It's definitely a challenge.

48:37 Gareth, were you trying to jump in there?

48:38 Often as well.

48:39 We make decisions because then it sounds cool.

48:42 But actually the best decision you can make around framework or language is the one your team already knows.

48:48 So your default thing should be, don't change unless there is a really good reason to change.

48:53 Because you introduce, you know, I've seen companies have gone, we need to write a thing in Java because the industry does it in Java.

49:00 But all they were was Perl and PHP devs.

49:04 And so suddenly you have an entire stack that your developers can't maintain.

49:08 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 Cecil's thought, right?

49:15 Keep the humans.

49:16 You've got to deal with it in mind, not just the technology.

49:18 Yeah.

49:19 All right.

49:19 I want to move on to another topic.

49:21 We're getting short on time here.

49:23 So maybe I'll throw this first to you, Dan.

49:24 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 we were saying before, or as Kim brought in that to like somebody at the company who has that expertise.

49:37 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.

49:51 So what I wanted to ask you all is how important do you see the open source side of things versus a closed source?

49:59 Like let's say there's some project for a database.

50:01 It's twice as good, but it's closed source.

50:03 Choose it, not choose it, putting money aside.

50:06 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:12 Okay.

50:12 Like is it Postgres, but 2x is fast Postgres or Postgres.

50:18 Right.

50:18 Or is it Microsoft SQL server, but it's still relational and you 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.

50:31 That is definitely a real risk.

50:33 And I have seen that happen with companies that actually had to rewrite their entire code base because they use something proprietary that then was decided.

50:43 Stopped.

50:43 There's one specifically.

50:45 It's not profitable enough.

50:46 So your project stops.

50:48 Exactly.

50:49 Yeah.

50:49 This one, it was called QA Studio.

50:51 It was a finance, quant finance language, actually by Palantir.

50:56 There was a hedge fund I knew that had fully adopted it.

51:01 And then they actually made the reverse migration to Python after the fact.

51:06 How about the SEO?

51:06 What do you think?

51:07 Well, where is that bar that you cross over?

51:10 Yeah.

51:10 I was reminded about kind of somewhat horrifying experience from my own career that Dan's just reminded me of.

51:16 I've seen it happen with the third party software that the company's bought and then it's no longer available.

51:21 But the other time I've seen it, and it ties into what we were saying about kind of picking things 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 4 or whatever it is.

51:34 Nobody knows how to do it.

51:35 It doesn't do what we need to do anymore, but we don't have the source.

51:38 Even if we did have the source, we don't have a Visual Basic 4 compiler.

51:41 Nobody understands it.

51:42 We don't know how he built it.

51:43 Bob is long gone.

51:44 You need Windows 95 to build it.

51:47 How do we get that?

51:48 Well, exactly.

51:48 All those things add up.

51:50 And at the time, it's not to make you sound like Bob was an idiot.

51:54 Bob did what Bob knew.

51:55 Bob knew Visual Basic 4 and somebody said, let's turn out a tool as fast as possible.

51:59 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 it until way down the line, and nobody knows how to maintain the thing.

52:09 So there's an argument to be had for where do the libraries and so forth you pick.

52:13 If you're not picking things that everybody knows, or at least that huge chunk of you know, sooner or later you run out of people who know how to maintain these things.

52:20 But as I say, not to maliciousness, just through, you know, I need it done fast.

52:24 If you ask Bob to do it fast, Bob's going to do it in Visual Basic 4 because that's what Bob knew.

52:27 And that's fine.

52:29 And that might have been a totally decent choice in 1995.

52:31 Exactly, yeah.

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

52:35 And code rots.

52:36 It does.

52:37 Over time.

52:38 So, you know, 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:43 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?

52:53 So you have to rebuild at some point, and so on and so on.

52:55 Exactly.

52:56 Yeah, absolutely.

52:57 That only helps if you kept up with the ability to do that.

52:59 You decided to keep yourself alive.

53:01 Now we need to make it run on 64 bits.

53:03 That's what Visual Basic runtime and WebAssembly is all about.

53:08 Let's get going.

53:09 Emily, what's your thought on this?

53:13 Open source.

53:14 I mean, my tendency, obviously, is to choose it as 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.

53:24 But for me, I think it really comes down to portability.

53:26 If it's something that can be easily swapped out, I'm all for it.

53:30 But I see this a lot more with system architectures, right?

53:32 So if you're going to decide to go with AWS RDX, it's Postpress, right?

53:38 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.

53:47 Whereas if you're going to make the decision to go all in on serverless and you're going to write lambdas, that's definitely something that you can theoretically move someplace else.

53:55 But that barrier to portability is a lot higher.

53:58 So that's kind of where I look at it.

54:01 If this thing goes away or for us, a lot of it's like looking at client budgets, right?

54:06 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.

54:14 Is that something that our client is going to be willing to take on from a financial perspective?

54:18 So yeah, there's a lot to it.

54:20 I try to...

54:21 Yeah, you're sort of touching on another angle that's interesting as well.

54:25 We don't really have time to go into it, unfortunately.

54:27 But even if you have an open source thing, maybe your code is in Python and it's talking to Postgres,

54:33 you can get locked into commercial clouds, right?

54:36 Like RDS or Lambda, right?

54:40 While it might still be running your Python, like you can't, like you said,

54:43 you can't just take it and run it somewhere else without rethinking all the little roots of things

54:49 it's going into to hook into the other parts of the cloud there.

54:53 And that's clearly not something you can take as an open source thing and run with.

54:56 So I'll give you the final word on this and then we'll wrap it up.

55:00 Yeah.

55:00 One way I kind of think about it is, you know, like there's some things that I care that they're open source

55:05 and other things that I just don't.

55:07 Like as an example, like I use MongoDB randomly.

55:11 I've never looked at the source code.

55:12 I probably am never going to.

55:13 Like whether it's open source or not, when I can see the source code or not, like, is it important?

55:18 I don't know.

55:19 Is it the fact that I appreciate that there's community contributions and the discussion happening?

55:24 Maybe that's the important part of the open sourceness that I do care about.

55:28 When I think about smaller projects, when I mean smaller projects, I mean like utility libraries and things of that nature.

55:35 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.

55:41 And I'm like, I don't understand what this means.

55:43 Let me try and navigate through, you know, let me get cloned and navigate through it and see what's happening.

55:48 Right.

55:49 In that case, sure.

55:50 I totally care to this open source because I have a problem and I want to try and figure it out.

55:54 Right.

55:54 So I think it really just depends.

55:55 Again, for me more so, like, I really appreciate like when those utility libraries that I'm using are open source so I can figure out what's happening.

56:02 But, you know, major things like, again, I think about Mongo or RabbitMQ or Redis or anything like that.

56:07 Like, I'm never going to look at that source code.

56:09 You know what I mean?

56:09 I'm with you on that.

56:10 Yeah.

56:11 I appreciate that they're open source, but I'm not going to try to change it.

56:14 Yeah.

56:14 I'll just probably break it.

56:15 All right.

56:17 Well, this has been a great conversation.

56:19 I'm looking at the notes that we all put together to talk and like we're halfway through it.

56:23 We could just keep going and going.

56:24 But we only have so much time.

56:27 So what I want to do is I want to close out.

56:29 Normally I ask about editors and cool packages and stuff.

56:32 I want to close this out with a lightning round on one other thing.

56:34 And this final thought is, you know, how much does it matter that we have like really beautiful, say, like landing pages?

56:41 You know, some of these open source projects like Vue.js or Tailwind, they could be, you know, a high end marketing budget spent on them.

56:49 And even, you know, poetry in the Python space has kind of got like a cool little landing page.

56:52 So we're top to bottom here.

56:55 Final thought.

56:56 Give me a, you know, a couple of thoughts real quick on this and then we'll call it a show.

57:00 Dan?

57:01 I think it definitely helps in terms of getting people involved.

57:05 Not necessarily a requirement.

57:07 And in some cases may mask issues with the underlying library.

57:12 Okay.

57:13 Like, I mean, the only thing I can think of is like profit kind of, which had a lot of Facebook.

57:18 It was very fancy Facebook marketing, but there's been some, I think like the Zillow stories and things like that of cases where it wasn't necessarily appropriately used, but it was very fancily marketed.

57:28 So I think it's just can be an entree even without full evaluation.

57:33 Right.

57:33 It might actually, maybe the effort should just be put to the code or somewhere else.

57:37 Gareth, what do you think?

57:39 You've seen the Tailwind CSS site.

57:41 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.

57:48 So I'm old school.

57:50 So if it's got a man page, I'm probably happier.

57:53 I often find myself looking at them going, that's great.

57:56 I have no idea what it does.

57:58 And I think the fancier the landing page, usually it actually puts me off a bit because I worry that they're putting a lot into it.

58:06 Although I'm paying a lot more in JavaScript at the moment.

58:08 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.

58:15 Kim?

58:15 Sure.

58:15 I'm pretty much with Gareth there.

58:17 It would be hypocritical of me to expect an open source project to have a pretty page before I can use it.

58:22 Because frankly, I can't do that.

58:23 And that's just not reasonable to expect other projects I might consider using to do that.

58:28 The one thing I would agree with Gareth on one thing, what I want to see basically is as fast as possible.

58:33 What is it?

58:34 And how do I use it?

58:35 You know, the marketing dump and stuff is all very nice and well written, but it's less relevant to me.

58:40 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.

58:47 If you have angled your project towards here's a video to show you everything you need to know, that's 10 minutes I'm never going to get back if I decide I don't want to use your library.

58:56 You can't skip it easily, no.

58:57 Equivalent text, exactly.

58:58 I could have read the equivalent text six times in the time it took me to watch your video.

59:01 So maybe that's a personal quick, but that's the thing I don't like.

59:05 Yeah, I hear that a lot too.

59:06 For video heavy, it doesn't work for me, I must say.

59:09 Emily, you probably have clients that come with fancy landing pages that they're going to recommend that you start with.

59:14 Yeah, for sure.

59:15 For me, I think, you know, documentation is paramount.

59:18 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, you know, 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.

59:36 So for me, it's like, yeah, I can look at this stuff in the code if I need to.

59:40 So having something that, you know, is either a playground, quick start guide, how to use it, that sort of thing is really important.

59:47 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?

59:58 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, you know, why it's faster than this thing, why it looks better than this thing, whatever it is.

01:00:08 It at least gives me sort of a starting point for, you know, why would I use this tool?

01:00:13 Obviously, it's all sort of taken with a grain of salt because each tool is going to say that, you know, here are the things that they're best at and kind of hide the things that they're maybe not best at.

01:00:21 I also think, you know, as you're sitting here on this page and you kind of scroll down and you can see all these sponsors.

01:00:27 That does matter. Yeah.

01:00:29 It matters, but it's also something that kind of can make you raise an eyebrow, right?

01:00:34 So like Vue is great because it's very diverse.

01:00:37 It's not, you know, a single large company that is sort of powering everything.

01:00:41 But I do think that that is something to sort of watch for is, you know, who is driving this and what is the reason why it's here?

01:00:49 Cool. Cecil?

01:00:51 Yeah, I think like a lot of other folks on this panel, I am not a designer.

01:00:54 And so I do appreciate the aesthetics of being able to like see things clearly and read them clearly.

01:01:01 I'm not here for all like the marketing stuff and I'm better because stuff.

01:01:05 You know what I mean?

01:01:06 Like I'm usually going to come in and I'm going to look for that getting started button.

01:01:10 I'm going to look for that docs button.

01:01:11 I'm going to look for the little code sample that I can copy, paste into VS Code and run kind of thing for the most part.

01:01:18 But then I also recognize the fact that like really nice documentation takes time.

01:01:22 And, you know, a lot of open source folks don't always have the time to create that, right?

01:01:26 Yeah.

01:01:27 It is a signal.

01:01:28 Yeah.

01:01:28 But is that like a metric that we judge them by?

01:01:31 You know what I mean?

01:01:32 Yes or no.

01:01:32 I mean, is that fair?

01:01:33 You know what I mean?

01:01:34 Like you can 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.

01:01:40 But like, does that mean that this is not a good project?

01:01:42 I don't know.

01:01:43 So I feel like, you know, that's obviously a good opportunity for folks to, you know, contribute and send PRs and things of that nature.

01:01:50 But, you know, for me, like I'm just going in really quickly to see, hey, how can I start the thing?

01:01:55 How could I run it, install it, execute it, Docker compose it, whatever.

01:02:00 And then kind of just get going.

01:02:01 All right, Lukas, 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.

01:02:09 Like it's very rarely hinders the project.

01:02:11 Just look at Python.org.

01:02:13 I'm being unfair, but you know, like in perfect fairness, like the last redesign was like some 10 years ago or something.

01:02:19 So like, you know, kind of it doesn't look exactly like as flashy as like Tailwind or Viewer or whatever.

01:02:26 And it doesn't really matter because it does kind of let us all PyPI is nice.

01:02:30 Like Python.org.

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

01:02:34 Yeah, exactly.

01:02:35 So yeah, like Python.org might get updated at some point as well, but it doesn't hinder us in one bit because, you know, it's a functional Django, in fact, website.

01:02:43 And we use it every day.

01:02:45 It's nice.

01:02:46 I personally like if there was a designer that actually sat on the, you know, on the project and made the website work.

01:02:54 There's a bunch of things that, you know, like until recently nobody thought about.

01:02:59 So all those outdated websites don't have this.

01:03:02 We're like dark mode, white mode, looking good on a phone screen or whatever.

01:03:07 Like those things end up being quite useful to me now.

01:03:11 Like the job I do, like I work with people in different time zones.

01:03:15 So every now and again, they would catch me when I'm like, you know, away from a keyboard.

01:03:19 And if I can actually go and check something, you know, on the phone, it's very helpful.

01:03:23 It's not always possible or it's at least like, you know, complicated sometimes when, you know, like scroll.

01:03:30 A white background.

01:03:30 A white background.

01:03:31 A white background.

01:03:31 Yes.

01:03:32 Or like a white background is going to glare at you like at like 3 a.m. or whatever.

01:03:36 You know, so like I appreciate good design.

01:03:38 It's obviously not something I do personally as well.

01:03:42 Just like everybody else I think here.

01:03:45 However, there are people that are great at it and I appreciate it when, you know, kind of people like this get contacted.

01:03:52 And, you know, those sorts of websites look good and are functionally better that way.

01:03:57 Thank you all for being here.

01:03:58 It's been a great conversation.

01:03:59 Thanks for taking the time and being part of the group.

01:04:02 Thanks.

01:04:02 Thanks, everyone.

01:04:03 Thanks.

01:04:03 This has been another episode of Talk Python to Me.

01:04:07 Thank you to our sponsors.

01:04:09 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.

01:04:20 Find an exciting position that's right for you at talkpython.fm/cox.

01:04:25 Take some stress out of your life.

01:04:27 Get notified immediately about errors and performance issues in your web or mobile applications with Sentry.

01:04:33 Just visit talkpython.fm/sentry and get started for free.

01:04:38 And be sure to use the promo code TALKPYTHON, all one word.

01:04:42 Want to level up your Python?

01:04:43 We have one of the largest catalogs of Python video courses over at Talk Python.

01:04:47 Our content ranges from true beginners to deeply advanced topics like memory and async.

01:04:52 And best of all, there's not a subscription in sight.

01:04:55 Check it out for yourself at training.talkpython.fm.

01:04:58 Be sure to subscribe to the show.

01:05:00 Open your favorite podcast app and search for Python.

01:05:03 We should be right at the top.

01:05:04 You can also find the iTunes feed at /itunes, the Google Play feed at /play,

01:05:09 and the direct RSS feed at /rss on talkpython.fm.

01:05:13 We're live streaming most of our recordings these days.

01:05:17 If you want to be part of the show and have your comments featured on the air,

01:05:20 be sure to subscribe to our YouTube channel at talkpython.fm/youtube.

01:05:25 This is your host, Michael Kennedy.

01:05:26 Thanks so much for listening.

01:05:28 I really appreciate it.

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

01:05:31 Bye.

01:05:32 Bye.

01:05:33 Bye.

01:05:34 Bye.

01:05:35 Bye.

01:05:36 Bye.

01:05:37 Bye.

01:05:38 Bye.

01:05:39 Bye.

01:05:40 Bye.

01:05:41 Bye.

01:05:42 Bye.

01:05:43 Bye.

01:05:44 Bye.

01:05:45 Bye.

01:05:46 Bye.

01:05:47 Bye.

01:05:48 you you you Thank you.

01:05:51 Thank you.