Why write open source code and when you should start. If you’re interested in Python, John’s found just the man, Nick Coghlan of Red Hat joins John to discuss open source, python and how a casual interest can turn into big part of your career and your life.
Transcript available
Welcome to Pragmatic. Pragmatic is a weekly discussion show contemplating the practical application of technology. Exploring the real-world trade-offs, we look at how great ideas are transformed into products and services that can change our lives. Nothing is as simple as it seems. This episode is sponsored by Sapient Pair's awesome app, Shopee. Shopee is a collaborative shopping list app that's simple and easy to use with great features like pocket lock, smart ordering, and real-time collaborative updating. A shopping list is a special to-do list and Shopee addresses that use case very well. It's free on the iOS app store, so check it out at sapient, that's S-A-P-I-E-N-T dash pair, as in two, .com/pragmatic for more information. This episode is also sponsored by ManyTricks, makers of helpful apps for the Mac. Visit manytricks, all one word, .com/pragmatic for more information about their apps, Butler, Kimo, Leech, Desktop Curtain, TimeSync, Usher, Moom, NameMangler, and Witch. If you visit the URL, you can use the code pragmatic25, that's pragmatic, the word, and 25, the numbers, in the shopping cart to save 25% on any ManyTricks product. I'm your host, John Chidjy, and I'm joined today by my guest host and old friend, Nick Coghlan. How you doing, Nick? - Very good, thank you, John. - Thanks for coming on the show. I wanted to, apart from an excuse to catch up, 'cause we haven't caught up in ages, since, yeah, 'cause for the listeners that don't know and couldn't be bothered going through both my, and actually, do you have a LinkedIn profile, Nick? - I do have a LinkedIn profile, and that does go back to Boeing and SPSS and all that good stuff. - Oh dear, yes. Oh, the good old days. Well, that were the old days. Were they good? I don't know, good-ish, old-ish, days-ish. But anyway. - I learned a hell of a lot. - Yeah, well, so did I. Yeah, so did I. So did I, it's true. But anyway, yeah, so Nick and I go back to then, and we also played on a cricket team together, which we were just briefly discussing before the show. So, yes, but we've sort of gone our separate ways and chased down different careers. So I thought it'd be nice to get him on to talk about some open source software that he's messing with, But before I get to that, just quickly, once again, we are live streaming the show. And if you do want to join in, there is an IRC chat room on freenode.net. If you go to the URL techdistortion.com/live, you can access the live stream there, or you can use the embedded IRC chat box to join in. I also have a basic show bot now running. It's a clone of, well, clone, it's a fork, I should probably more accurately describe it as of the KC-LiS's accidental bot, which is running Node.js on the Tech Distortion server. And it is only a partial show bot. It currently accepts show titles and that's it. So feel free to add those in the chat room with exclamation mark, lowercase S, and then your title suggestions. And you can then vote on them after the show at techdistortion.com/showbot. But it's been a little bit of work to integrate it because Casey's used Handlebars, which is a JavaScript add-on that I'm not able to use because it uses the same curly braces that Statomic uses, which is what I'm using for tech distortion. So to integrate into the website's been a little bit more painful than I would have liked, but that's okay. The backend is fine. So anyhow, yes, there you go. Not much else to add there. So, right. - Computers, how do they work? Oh, wait, they don't. - Oh, of course they work, Nick. We make them work. Oh, no, we fake it really, really well. Sometimes. Is that what we do? Okay, well, fair enough. Oh, dear. All right. One could call me a technology cynic. I've ceased to be surprised when computers break, and I'm pleasantly surprised that they ever work at all, because I know too much about what goes into that sack. Yeah, it's a bit like that, isn't it? Sometimes I look at a computer and I just smile to myself and I I think it's an absolute goddamn miracle that it works at all. - Yeah, exactly. - There's so much stuff that can go wrong, but anyhow. So, all right, I think Nick, we should probably start 'cause with a little bit about what it is you do, because I know what you do, but listeners may not know who you are. So tell me a little bit about, first of all, what your primary role is at the moment and where you're working. - Okay, so I work for Red Hat. so most well known for Red Hat Enterprise Linux. - Yes. - But also these days, moving out into more general, general infrastructure software with like middleware messaging, Java application servers, platform as a service, infrastructure as a service, pretty much all the buzzwords you care to name around computing infrastructure. We sell something in that space. And so what I actually do is I work for one of the large internal tools development teams that actually the software we actually build isn't stuff we sell, it's the stuff we use to make the stuff we sell. So like all the open source review tools, hardware integration testing environments, software integration testing, the Bugzilla bug tracker that powers bugzilla.redhat.com, and yeah, so we do a lot of the development work for all of that, but that in itself becomes a thing of, well, we have to deploy all of that software so Red Hat can use it, and so my job is actually taking all of that stuff that we sell to customers to say, "Hey, here's how to run your your infrastructure software. And at Red Hat, well, we need to run our own infrastructure software. So my job is saying, well, okay, here is how we're going to use the stuff we sell to actually run our own business and do all that. So that's actually pretty interesting. Yeah, that sounds really interesting, actually. A little bit jealous, actually, sounds far more interesting than my job. So okay, but that's one of the things that you do that one of the other things that I see you're also involved with is you're heavily involved with Python. So can you tell me a little bit about what it is you do with with Python? Yep. Okay. So with Python, basically, a bit over 10 years ago now, so getting up towards 12, when we were still at Boeing, I was looking for a hardware integration testing, sorry, software testing system to run, to power the control the hardware integration tests for the digital signal processing stuff I was doing at the time. Which you ended up doing a lot of the hardware work for. Yes, indeed. But we will not talk too much about that, otherwise, you know, ASIO may track us down and shoot us in the head or something horrible. Horrible, horrible death or whatever. But anyway, so needed to do some testing, didn't have any budget for a test system, but we were using Python for system management stuff. And so it was like, oh, okay, I'll use the unit testing features of Python to actually write my DSP test on it. And that was pretty cool. And I ended up joining a bunch of the Python mailing lists and ended up on the core development list and that was just a fascinating place to hang out and hear from a bunch of really really smart people about how they built a programming language interpreter. And then there was just an interminable argument that had been going on at one point where was just about this really really simple feature that everybody liked and just to make the thread go away because I just wrote the patch to actually implement the feature everyone was talking about, submitted it and it got accepted and it was like oh this is fun and so yeah and so from there I kept contributing. I had a three-month trip to the US in late 2004, where I needed something to occupy my time, spend a bunch more on the Python core development stuff, and then became a core committer in 2005 and have been doing that ever since. And so it's a very One of the things I'll sometimes say is if you're looking for a hobby, do open source and then you can have two full-time jobs, only one of which you get paid for. Nice attitude, I like that. But yeah, it's been a heck of a lot of fun and provided an awful lot of opportunities that I wouldn't have had otherwise. the Red Hat geek has a lot to do with the work I've been doing on Zpython. So, okay. So, thank you for that. That's sort of, I did want to make sure that people understood sort of your background because, and one of the reasons that I wanted to get you on the show was to talk about open source software. And you just mentioned that. And one of the things that I've sort of struggled with the concept of open source software, and I struggle with the concept. I mean, I mean, obviously I understand the concept, but I sort of struggle with motivation, influence and control. And those aspects tend to be very different in a commercial environment. And we've both worked in, obviously, in a commercial environment, with the military contracting, obviously, of Boeing. I've also developed a lot of software over the last 10 years for control systems for different companies, manufacturing facilities, oil and gas, water and wastewater treatment. And all of that is software that a client will come to me and say, here's a budget, go write me code. When it breaks, go fix it. And oh yeah, by the way, it's mine when you're done. There's the door, see you later. It's very contractual, it's very come in, write this code, see you later. It is not open source, it is not posted anywhere. It is completely proprietary. And it is very stark contrast to open source. So I guess you work for Red Hat and obviously, and I'm actually right now, this is streaming on a CentOS 6 running on a VPS with DigitalOcean. And that obviously has, that is a RHEL, I believe. - Derivative, yep. Now a sponsored project of Red Hat. So they, yeah, exactly. So as you can see, somehow it's quite possible that there's something that you've worked on that's within that server, perhaps, possibly. I don't know, maybe. - Absolutely, Red Hat doesn't boot without Python. - So yeah, well, there you go. So, all right, so I can blame you when it crashes. That's all I wanted to know. - You can definitely blame me if it doesn't install because the install is written in Python. - Fine, okay. Damn it, well, okay. You know what, it installed fine. So I'll have to get you somehow else. Anyway, that's all right. So, okay, I have to admit that one of those things that I've taken some code that other people have written, I've tweaked and modified it, and I've sort of put it up on GitHub, and a few people have looked at it, and that's pretty much been it. In terms of me contributing to open source, I will fall on my sword and say, I haven't really done that. But I guess let's start with, I guess the business model behind Red Hat or Enterprise Linux, how is it possible that you open source, you've got a bunch of engineers, software developers programming something that is massive and open source, and yet you actually have money to pay those people to write something that is essentially given away. I just need, if you could just walk me through how that business model works. So this is something we obviously spend a lot of time thinking about, because there's always the-- in addition to the battle of buy our stuff instead of the proprietary competitors, there's also the battle of don't use the free stuff, unless you're prepared for the consequences. And the thing people-- what I've basically narrowed it down to is that there's two very, very different styles of communication for a software development community. And the one you get with community open source is, funnily enough, the one I call community communication. And the thing about community communication is it's very, very cheap to produce because it's what happens just by doing what you're working on. So to take Python as an example, if you looked at all of the traffic in the hash Python dev IRC channel, all of the traffic on the Python dev mailing list, all of the traffic on the Python ideas mailing list, all of the traffic on bugs.python.org. That's an absolute fire hose of information. If you actually take the time to pay attention to that and filter all of it and actually see what happens, actually gets checked in to CPython, you will know exactly what is coming in the next release and you will know why. It will also take you about 40 hours a week to actually do it. And actually then you'll add disutilsig as well to get all the packaging stuff. Yeah, it's very, very high volume, very, very in-depth and a lot of it's just noise. Like it's the case of people making suggestions that get kicked around for a while and then we go, "No, that's a bad idea. We're not going to do it." But when the conversation starts, you don't know that that's where it's going to end up and it takes a lot of takes a lot of time, takes a lot of expertise to actually filter that stream of knowledge. But the thing is because the people, because we're all participating upstream for our own reasons, we're kind of contributing there for a whole variety of reasons and those reasons don't necessarily include the interests of potential commercial users. And so commercial users can actually get very very frustrated when they try to consume community open source directly because they'll be going, "Wait, wait, but I'm using your stuff to run my business. Why can't I get anybody to listen to me?" And "No, no, no, tell me what that means. What does this mean for my business? I don't understand. Please explain." But the thing is because meeting their needs is not the reason anyone in particular is participating they're like going, they can get very, they don't necessarily have the time they need to actually build the expertise to understand the firehose of information and the implications for them. And so it really only makes sense for people who are highly invested in that particular project to be trying to keep up with those data streams. And essentially... - Sorry, I just wanted to just interrupt you just for one second, is that ultimately, you've got requests coming from all across the board, from people that use it to run their business, like you say, and of course, from individuals and so on. And in terms of balancing what you implement and what you don't, 'cause you've obviously, you've got a fixed amount of funding available through whichever means, which we'll talk about, I guess, a little bit in a little bit, But the actual decision, how do you decide what goes in and what doesn't? Is it more about what you will internally believe is best for the platform? Or is it about, is that the driver then? Yeah, so CPython is one that works on, we work on the benevolent dictator with lieutenants model. Right, okay. Oh, sorry, lieutenants. I've been talking to Americans too much. Oh, it's okay. A large percentage of the audience of this show are North Americans, so they will forgive you. That's fine. That'll be puzzled by the correction. Oh, well, possibly, yes. Oh, right. So Benevolent Dictator. So Guido van Rossum's the guy who created Python in the first place. Yeah, that was in the late... '91. Yeah, '91. It was, I think they started, he started working in the late 80s, I thought, but it wasn't released till '91. Is that The one he released was like 0.9 or something. Yeah, yeah, that's right. But yes, he had been working on it for a while. And so anyway, so he's still benevolent to cater for life. If anything really controversial is going to happen, it's pretty much because Guido said, "Yes, that's a good idea." But he only has so much bandwidth, even he can't keep up with all the traffic. And so there's maintainers for the various standard library modules, domain experts in different parts of the interpreter. And so basically, we have a lot of autonomy to say, if a proposal is in our area of expertise, then we can say, yes, that's a good idea. Let's accept that change and merge it in. And basically, it runs on that kind model of the people who do the work make the rules to a large degree. So we have this thing called the Python Enhancement Proposal Process which is used for big complex changes or particularly controversial changes which is basically formalized arguing on the internet. Oh nice okay it's formalized so that makes it better. It works better than it sounds. Okay good I'll take your It's not necessarily the most pleasant process, but it works surprisingly well. Without having experienced it, I wouldn't have believed it either. Fair enough. Cool. But yeah, it's basically a case of get a bunch of passionate people who all really care about something, get them all to yell at each other for a while, politely, mind you. It's very much a matter of argue the idea, not the person. And that can vary depending on the open source community, but it's certainly one we aspire to in the Python core dev. And so yeah, so it becomes a matter of, yeah, there's a thing called the Zen of Python, which is just a basically bunch of design heuristics about what's likely to fit with the design of the language. And then, yeah, we basically are trying to go, okay, is this any major change we make has a big ripple effect on the ecosystem? And so we have to say, is the long-term benefit of this change worth the near-term disruption? Our users don't always agree with our judgments on that front, but we basically, yeah, that core basically comes back down to the core development team, and ultimately down to Guido. So Guido is still heavily involved as either the head of it, is he? Yes. Python Software Foundation. So he's not, he's the president of Python Software Foundation, but the actual day to day running of that is down to the board of directors. And so, so yeah, so we're, yeah, we're pretty much governing most of the the grants to the Python Software Foundation, all that sort of stuff. Okay, so because you're on the board of directors for the Python Software Foundation, yes? Yes. How many people? Yeah, and it's only been a relatively recent thing. How many people are there on the board then? nine I think, maybe 11. So yeah, so it's yeah, it's that's actually one we're doing a lot of work on is trying to change the way the PSF runs a bit and at the moment we kind of, the boards, we're running a lot of stuff ourselves which is not really the way you want a foundation to be running. You want to get the executive staff in there so the boards pretty much only having to to get involved in strategic stuff, but we're not there yet. We still have a lot of work to do. So. OK, cool. All right. So I just want to circle back quickly to the funding model behind Red Hat, specifically Enterprise Linux and development of its core functionality and core tool sets and so on. Not just Python, obviously, which you're heavily involved with. But just to sort of make sure that it's clear, where does the money come from? Simple question. Yeah. Oh, yeah. OK, so this goes back to that communication thing of that when you are consuming software for commercial reasons, like you're not interested in the software itself, you just don't care. What you're interested in is what can it do for me? What does this mean for my business? Why is this useful? Why should I be using it? What assurance do I have that it's still going to be here next year, in five years, in 10 years? And so basically the thing Red Hat realized is that if you're in a position to provide that additional level of high touch communication, that clear, to basically play that filtering and curating role of being able to tell people this is the stuff that is important for you to care about, this is the stuff that matters to your business, you can ignore the rest of it, this is what's important for you. That's actually a really valuable service and this is actually something we we see, we actually see it in a lot of industries. So we're seeing it in, we're seeing it in video, we're seeing it in music, we're seeing it in everything else that the publication is so easy that people's inherent urge to create stuff and publish it, they're just doing it for all their own reasons. And so there is actually an entire cacophony of open source software out there. So just as there's tons of videos on YouTube and tons of music on SoundCloud, there's tons of software on Bitbucket and GitHub and SourceForge and all of these software repositories that people will write stuff and publish it because they're not commercializing that software directly. And some of it will be written by people who are actually contractors. from their point of view pooling their resources with a bunch of other people doing similar contract gigs and building a common set of tools which they all then go in and deploy for different customers and customize like that. So like for instance there's lots of stuff out there for building e-commerce portals and the reason is that when you're a company who wants an e-commerce portal. Well you don't really care what it's built from, you want an e-commerce portal that is specifically for your company. And so for the people who are building those e-commerce portals there is so much work to be done that there is no... the idea that you don't necessarily need a secret source of all we can we have this special ability or these special tools that nobody else has like there's so much software development work to be done that you just don't need that edge it's the case of that there's so much demand that the that sharing the tools and bringing the cost down of building the tools means that people can focus on the actual custom stuff. What Red Hat does as a redistributor is a bit different. What we're basically, the business we're basically in is taking the noisy messy upstream, tidying it up, putting it in a package, wrapping it up with a nice neat little bow on the top, and then saying to customers, "Look, here is the stuff that we've checked. This it basically works. You can do stuff with it. It's not going to set your servers on fire." And that filtering and curation process, it's a case of if you don't go through a vendor, then you end up having to do it yourself. And most customers just don't have that kind of time. they're just not. Or in-house knowledge, they don't have the in-house knowledge either. Yeah, yeah, yeah. So, and so it's that thing of, if you have the time and you have the expertise, consuming upstream directly is a really good way to go. If you don't have the time and expertise, then your choice is either build it yourself or outsource the task to somebody. And essentially, what Red Hat subscribers are doing and saying, "Okay, well, we're going to outsource it to you." And say, "Okay." And we basically become their open source consumption arm of keeping an eye on where's the technology going, what's interesting things are happening upstream. Because essentially Open source is just the biggest and best R&D department on the planet. Because it is basically full of very, very smart. There's a saying that no matter how many smart people you have working for you, most of the smart people in the world are somewhere else. Just because the world's that big. And so the beauty of open source software is that it becomes the case of you can have people who are very very passionate about a particular problem area, they can come up with a solution, publish it, and then other people instead of having to try and like reverse engineer a design paper or figure out from a patent what they were talking about, they can just say "oh there's some executable knowledge online there, I'll just download it and run it" and so it just becomes this extraordinarily efficient system for sharing knowledge where in a way you can take stuff that you don't yourself, you don't understand it well enough to build it yourself, but you can put it together and create something bigger out of it. It's kind of the that holy grail of software reuse that we've been aiming for in aiming for in software engineering since pretty much forever, open source actually achieved it and they figured out that the way you achieve it is you actually take the walls down and share it with anybody who's interested. And then what you do with the way you make your money is you employ the people who are the serious experts for a lot of the stuff that's upstream and you say, "Right, you're now working R&D, just do it, publish it, make it as awesome as you can." And then you have a large productization pipeline which is basically trying to bring like open source is awesome but it can get really chaotic at times and that a lot of people are like it's that classic early adopters curve for market adoption, which is that open source people directly involved, it's an inherently early adopter environment, and that once you get in order to get it out of that early adopter environment and package it up and make it clean and consumable by everybody else. That's a time-consuming and expensive process. But the thing is that it's also a process that people are willing to pay for. And so yeah, and so that's kind of the... there are other business models people have built around open source, but the particular one Red Hat's built is that one of bringing order to to the chaos and saying, look, here's the neat, tidy, somewhat cohesive bundle. Okay, cool. All right. So it's essentially your job to go through and filter out all of the stuff, or the contributions that are perhaps, what's the word, dodgy? Yeah, it may affect stability. Yeah. So one of the ways I put it is that we filter for supportability, because we have very strong support commitments around the idea of we ship it, we support it. And so one of the consequences of that is it means we're very, very well aware of that if we let stuff in that is too unstable, and just not ready for primetime, then we're going to pay for it on the back end of increased support calls. Absolutely. Okay. So companies that are doing mass deployments, let's say, or it may not even mass deployments, but a deployment of some significance will come and say, look, you we want you to support this and we want a build that is as stable as possible with the following features or whatever else and that's something that then Red Hat provides. Does that summarize it? So generally speaking a lot of what we do is actually around providing standard versions of the software with sustaining engineering. So it's like obviously one of the big things with particularly stuff that's exposed to the internet, is security fixes and making sure those can be deployed as quickly and easily as possible without bringing in... basically what people want is the ability to deploy just the security fixes without bringing in anything else. And so that's one of the big things we do with our stable platforms is is that we give people that option of just deploying the security changes. And so that's kind of the way a lot of stuff gets consumed and a lot of that gets sold through channel partners as well where other big consulting companies will go into a customer and be doing a... they'll be doing the systems integration deployment and then Red Hat will be part of that solution. But then yeah, we do also have our own consulting arm that will get called in and do more of that tailored deployment type stuff. But as far as possible we try to keep everything as clean and consistent as we can because that makes life easier for us as well. It's always that classic thing of the more customizations it has the harder it becomes to support. - Okay, cool. Well, we might just pause there for a second and talk about our first sponsor. So, Sapient Pair have decided after years of being annoyed with existing to-do list apps when they were shopping to create an iOS app for the iPhone that's called Shopee. Now, there's a ton of to-do list apps out there and I've used lots of them over the years. But going shopping is a very specific use case for a list. If you're shopping for more than just yourself, then Shopee really can begin to shine. The best way to describe Shopee is a fully collaborative shopping list app that's simple and easy to use. I picked it up and figured out how to use it immediately. It's not cluttered with options, it doesn't presume you live in a specific country or present you with hundreds of different options for milk or butter. You just type in what you want to remember to buy in a list, enter the amount or quantity if you want, that's optional, and there's your list. It remembers what you've entered for future and it even remembers the order that you bought, that you mark them off and order them in. So as you walk through the supermarket and remembers it for next time. Now that's cool enough but when you share, you share your list by email or message and so on to your spouse, your partner, the kids and hopefully they don't just add chocolate or ice cream to your list but you know they can add, mark off, reorder items in the list as they want to. So actually on second second thoughts, don't share it with the kids. But anyway, I've tried this in real time between two phones over 3G and the sync happened in less than three seconds. It was really, really good. I also love the pocket lock feature. If you're security conscious like me and you've got a passcode set, there's nothing more annoying than having to lock your phone, slip it in your pocket and then get it back out again at the end of the aisle just to unlock it again and look at your list to see what else is on it. The pocket lock disables the screen when it detects that it's in your pocket and re-enables it again automatically when it's removed. There's no passcode, no fuss and it works really well. So here's my scenario. My wife goes shopping, opens up Shopee and indicates she's about to start shopping. Then the geolocation detects the store she's shopping at and on our shared list I will get a notification on my phone that she's about to start shopping and remember "Oop, I need shaving cream" so I tap the notification, get into our shared list, add it really quickly. It appears on her list wherever I put it and she grabs it while she's there. Brilliant. There's no more of these last minute, "Is there anything else you need, darling?" kind of phone calls. So they've all gone away. Anyway, it's free to try for the first month with no ads. After that, it just becomes ad supported. There's no risk, no loss of functionality, none of that. So if you want to help out the developers though, there is an in-app purchase for three or 12 months to remove the ads for $1.99 or $4.99 US respectively. So if you want to check this out, and I suggest you should check it out, please visit this URL, sapient, that's S-A-P-I-E-N-T dash pair as in two dot com slash pragmatic and follow the links to the app store from there and that will help out the show. You can search for the app in the store of course, but if you use that URL in your browser of choice, it will help out the show. So thank you to SapientPairs, Shoppy app for sponsoring Pragmatic. So, okay, now I'm sort of at the point where I wanna go a bit broader with this discussion. I've focused a lot on Red Hat and I know I sort of steered it that way and that's fine, I guess. But ultimately, one of the other things you said is that open source is, it's great to be able to contribute to open source because you end up with the ability to sort of develop some of your programming skills. Maybe I'm paraphrasing me too much, but developing your programming skills and having a hobby that can also end up at some point being something you end up being paid for as a job, which I think is sort of a path that you may have gone down a little bit, right? - Yeah, yeah, absolutely. - So when it comes to that program is a lot of them sort of say, oh, you should do open source, you should open source your code just cause. And I sort of think to myself, well, there's a bunch of good reasons for doing that. But what I'm interested in is your take on beyond just it could lead to something more interesting. What else is it about open sourcing the code that you're working on that you see as big advantages for developers? - Yeah, okay. So, yeah, one of the big things for me is a case of doing that kind of thing Writing open source software because somebody else told you you should is something I actually consider to be a generally not a good reason for doing it. Because it's the case of if you open source code just for the sake of it, then nothing much is likely to come of it. the case of there's a whole lot of open source software out there that if you're open sourcing code assuming or expecting that you're going to get contributors or you're going to get feedback from other people, that's just not the most likely fate of the vast majority of open source software. Like the runaway successes like Linux and OpenStack and Docker and even Python itself, they're the exception rather than the rule. Vast majority, it's very much a hit curve kind of thing like music or movies. That obscurity is the far more likely fate of the vast majority of open source software. But what it basically provides you is, so in particular these days, there's actually an awful lot of services out there that provide their services for free to open source projects. So if you start your idea as an open source project, you can actually get free continuous integration services, free code hosting, free documentation hosting, pretty much everything you need to build an absolutely awesome software development workflow is actually available completely for free so long as your stuff is open source. So that's actually one concrete personal reason for doing stuff is open source which is that you can just you just get better tools for free. Like with that there is online software as a services industries companies that do this stuff and the reason they do it is that when people are doing their free projects on their free offering then it becomes the case of when they go to do their corporate software they're like oh I actually really like this workflow I'm going to use it for my professional stuff as well but my professional stuff I'll need more concurrent users or private repos or some other feature that that a lot of these service providers are pretty good at figuring out you're only going to need this if if you're a company. And so that's a really good way of segmenting your market because companies tend to have money, hobbyists less so. Or if they do have money, they're less inclined to spend it on their hobby. Yeah, right. And so it becomes that thing of when you can tap into that market of what developers are using in their free time, that then becomes incredibly powerful marketing for what they want to use professionally. So a classic example of that is the Australian mob at Lassian. They're a proprietary software company, but they provide Bitbucket for free to open source users. And they make their Jira bug tracker, they do free licenses for open source projects as well. Yeah, but hang on just on that point, they only got they only bought Bitbucket. What was it nine months ago, 12 months ago was only recent. No, they bought Bitbucket. They were, they're Atlassian Bitbucket folks at PyCon 2010. I'm pretty sure. Okay, my mistake though. I just They bought them quite some time ago. Okay. But that was a case of that, yeah, it got them, that, but yeah, it's that thing of a bunch of these. So that's one of the reasons, is that it's a purely self-interested reason. When people release their stuff as open source, it gets them free things. The other one is that quite a few companies these days, where they're actually making money, is on a hosted software as a service offering that they, and so what people are actually paying for them, paying them for in that case, is they're actually paying for run the service for me. Red Hat actually does this a bit ourselves where we've got the OpenShift online, even though we release that whole thing as open source, you can download it and run it on your own servers. But it's that case of when you run on somebody else's software as a service platform, they take care of the hosting for you and when you're a small company no ops team that can be a very attractive option and so for those companies they're not geared up to actually do package software because that's a whole like getting software to a state where it's good enough for you to run it yourself because you wrote it that's one level of difficulty. Getting software to a level of quality and stability where you can give it to somebody else and they can run it without knowing it intimately inside and out, that's a whole nother level of difficulty. It's much much harder. And so what you see is some companies they go for the model where they do release all their software as open source because their business is actually the hosting. And that then becomes a case of those companies often do get contributors, because people will want to run their own for whatever reason, they need it inside a company firewall, this, that, and the other, that they don't want to use the hosted one. But then they run it internally, they'll find bugs, they'll fix things, and they'll often contribute those back. There was actually a great... Walmart actually released some interesting numbers recently where they'd actually release a bunch of the stuff they used to run. What did they use to run? Some aspect of their business, sorry I forget exactly what it was. But what they'd actually run the numbers and they basically figured out that every, I think it was something like every five startups was equivalent to a junior developer, every 10 large companies was equivalent to a senior developer in terms of the return on investment they got in making that software open source. And so certainly and then in the case of Red Hat, in this case if you look at a bunch of our software projects and like Red Hat Enterprise Linux, so you look at the Linux kernel and it's like the Linux kernel is an amazing piece of software, an amazing piece of technology, we're like around 10% of the contributions. OpenStack, another amazing piece of technology, we're about 30% of the contribution. And so it's like our R&D department is great, but by participating in these collaborative projects, we get to... it's that rising tide lifts all boats kind of thing. So it's sort of a, almost an institutional self improvement program. Yeah. So cool. Okay, actually, so that does that, that does, that does touch on the interesting, I've mostly been talking about, if you're starting a project, why make it open source? And there's a different question, which is why join an existing open source project. One of the most obvious ones is because if people are using it then joining the development process can actually really deepen your understanding of how the product itself works which can then help you use it more effectively and that kind of thing. In the case of CPython I actually joined the call list just because it was interesting but it meant that I had the opportunity to learn about binary floating point from Tim Peters and Mark Dickinson, so a couple of people who are really really good at this stuff, so things about IEEE 754 that you just don't want to know. So Tim Peters, one of the CPython core developers, invented a sort algorithm called TimSort, which is the sort algorithm in CPython. But it is so good that it was actually used as the sort algorithm for, it was actually adopted as the sorting algorithm for Java. - Wow, nice. - Yeah, so yeah, it's that. And then, so yeah, then learned far far more than I ever otherwise would have about Unicode which then becomes a case of that people who speak English who've been trying to ignore the rise of Unicode for decades because like ASCII ought to be enough for anyone but yeah it really is one of those fundamental transitions in computing that we need to get to this model where computers can understand every language in the world all at once. And we're almost there, but we still have a bit of a way to go. So yeah, and that's just a, that kind of one, it's the case of if you've, if I've got the time to spend, and this also gets into the, it gets into that idea from martial arts, which is if you really want to understand something, teach it. Oh sure, absolutely. And so this is where the mailing lists... So when you start on a project like CPython, you're going to be pretty much in the... usually going to be pretty much in the mode of mostly learning, asking why is this like that, why is this like that, I'm trying to fix this but I don't quite understand what's going on. And generally it's worth hanging around on the lists for a while to see what the culture of a particular communities like but certainly in CPython it's the case of if people are genuinely trying to understand and actually trying to say I'm trying to help with this then we're very happy to explain why things are the way they are and all the different factors that can impact on a decision and then over time if you spend long enough doing it then that actually just kind of sticks and eventually you get to the point where you eventually end up on the other side of those discussions where you're saying, "Oh well, no, we can't do that because for this reason and that reason, but we could potentially do this other thing that might solve the problem in a way that actually fits with all the other parts of the language." And so, it was, it's just an extraordinarily good education in an extremely wide range of topics that I otherwise never would have touched. But yeah, it can become, it can be really quite very, very interesting. Okay. So, I guess... You okay? Yeah, yeah. Okay. Yeah, I was just gonna say is to the point where I actually just wrote an article recently about the rise of Unicode and how it's affecting the design of Python because there's a lot of people who are very upset with the way it's affecting the design of Python because they're going but I don't care about Unicode. I don't want to have to learn it. Well, they're gonna have to. So all right. Cool. All right. So I just it's just curious do you do much development outside for non-work purposes at all? Well so technically technically all of my Python development is not directly related to my day job. So there's it's it's not specific it's not specifically something that Red Hat pays me for it's something I was doing anyway even before I join them. But they support your going to all the different PyCon? The nice thing now is that I get to count conferences as work time which is a huge bonus. They cover your expenses and everything when you go to the different conferences around the world? Depends how persuasive I am in saying that no no no No, really, this is work related. Okay, one of those situations, all right. Yeah, but it's a... Usually I can make a plausible case, but occasionally I'll just go, "Yeah, you know what? No, there's no business reason for this one. It's ironic." But even then, it's the case of getting to do that on work time is still very, very cool. So how many of you actually given talks at now it's it's got to be it's quite a few now, isn't it? Oh so Every pike on Australia except the first one. So that'd be three Three years at four by now won't be four by now LCA a couple of LCA said Linux that I you earlier this year and in keynote at the Scientific Python Conference in the US earlier this year. And then another keynote at PyCon New Zealand coming up next month. Wow. Cool. So, yeah. All right. Fair enough. Fair enough. OK, so I guess one of the other things I just want to do to ask your thoughts on, if you're a young developer and you're getting into programming, if you have a choice between developing your code in the open or developing it behind, essentially behind closed doors on your own private repository, and it's not open for anyone else to see, which path would you choose? I kind of figure I know the answer, but more importantly, why? So for me, it's the case of the fact that I can get access to things like GitHub and Bitbucket, Travis CI, the Python package index, all of these facilities for storing, managing your code, testing it, publishing it, distributing it, all for free is really, really compelling. And that in return you get access to all of this other software that you can build on and just basically the internet is prepared to give anyone an apprenticeship in the craftsmanship of software development. So all the stuff they don't teach you in an academic degree about how to actually develop and evolve and publish software that you can actually get an apprenticeship in that. One of the things I tell with Python is that one of our release managers is actually younger than the language. That we made him a core committer before he finished high school and then he was a release manager when he was at college. But it was, yeah, so it becomes one of those things where you're like, oh okay, he actually has, it was just the case of those he had really good, demonstrated really good judgment about risk management in terms of changes and that's kind of the main thing you need in a release manager. Yeah, I saw you tweeting about risk management and how much fun it is just recently actually, you're having a rough day managing risk I take it. Oh, I don't even remember what that was about. That's all good. I think I've been having a conversation with somebody about that people get excessively paranoid about the risk of change, and so they lock everything in stasis and say "we're not going to change anything, and we'll just, this system is perfect, we'll just leave it and not touch anything." And then in the meantime, the world is changing around it. And then you suddenly look at it five or 10 years later, and you go, this doesn't work anymore. And you're just and the world, because it stayed the same, the world's changed around it. And you're just like going, Oh, we can't fix it. It's too expensive. We're gonna have to throw it out and start again. Well, see, it's funny. Sorry to interrupt. Sorry. Last week on the last episode I actually talked to Guy English about this and you know my take on it is it's perfectly okay to lock stuff down and not mess with it it's just that if you're gonna start messing with something you know start started as a new project don't just keep rolling more and more changes into something that has been battle-tested out in the field for a long period of time just cause you think you can write the code better I mean if you're trying to achieve something new and different then make it something new and different that my issue is that people will come in and they'll mess with the code, try to make it better, or say, "Oh yeah, I can write this code more efficiently, more effectively," or whatever, "I'm just going to mess with it because I can." It's like, well, if it's been out in the field, it's been out there soaking for a while in use and anger, then I always tend towards leaving it. I'm not suggesting that you should leave it there for a decade just to rot, obviously, but during that time, one would hope you'd start a new project designed to embrace new technologies, in which case that would be something new and separate. That's my take anyway. Yeah. And for stuff that's really expensive to update, so like particularly if you're putting it in vehicles and it's not connected to the internet and can't easily be updated, that certainly can be a way you have to go. You may not have a choice. there's a different kind of risk management that applies in very dynamic environments that are changing really really fast, which is that if you try to lock something down and leave it, then it's going to be wrong not in years but in months or even weeks. And that if you try and stick your head in the sand and say no no no we're going to ignore the changes, we're going to where or we're going to try and stop the environment changing so fast. That's just not necessarily possible because the forces that have that have the forces of change may be beyond your control and so there's been a lot of a lot of work on how do you build systems such that they can actually cope with a constant rate of change without being constantly unstable. And one of the causes is automate, automate, automate, whereby it becomes one of those things that if your testing is automated to a point where it can be done by a computer, then you get to a situation where you can actually fully test stuff. So OpenStack is a classic case of this. This is OpenStack's infrastructure as a service system for spinning up VMs and all that sort of stuff. And they have this wonderful gating system called Zool where every commit, every patch that is approved for inclusion in the project, Zool actually picks them all up, puts them in a queue, and the entire integration test suite runs against every individual patch before it's allowed to be merged. And this is all fully automated, that the humans just go, "Yep, patch looks good, all looks reasonable, approved for merge." But the actual process that does the merge is a computer and it runs the tests first and it becomes the assist and so what it means is that the main line of development for OpenStack is always in a state where it's passing its full regression test suite and so public cloud providers will actually just grab, because they know everything's been through its regression test, they will actually grab the trunk, run their own tests on it, again automated, and then just roll it out. And so it makes it possible to do this rapid feature development and rapid delivery of improvements to these systems. And it's a very, very different way of doing software and it's a very, very different way of doing risk management, but it is vastly more responsive to change than the model of build a system that's good for today, use it for a few years, then rinse and repeat. It's designed to be a continuous stream of small changes, so that you just build everything around the notion that change is a constant and that everything you build is around this notion of a changing environment. Now obviously this is a really radically different way of approaching software development And, and we read that makes an awful lot of money, gently bringing people closer and closer to this idea. But, but yeah, it's one of those things that it's not appropriate for everything. But but it lets you it lets us tackle problems that previously were basically not manageable, because the rate of change was too high. Okay, very good. Cool. Okay, there's one more thing I just want to talk about. Just before we get stuck into that, though, just to talk about our second sponsor for this episode, and that is ManyTricks. And ManyTricks is a great software development company whose apps do, well, you guessed it, many tricks, as the name suggests. Their apps include Butler, Kimo, Leech, DesktopCurtain, TimeSync, Usher, Moom, NameMangler, and Witch. Now, there's so much to talk about for each app that they make. So what we're going to do is just touch on some of the highlights for four of them today. So which you should think about which is a supercharger for your command tab app switcher which is great for and is very popular with X Windows users like myself. If you've got three or four documents open at once and in any one app then which is beautifully simple pop-up quickly lets you select exactly the one that you're looking for. With Name Mangler you've got a whole bunch of files you need to rename quickly and efficiently and in very large numbers, well, NameMangler can extract the metadata from files and use it to rename those files. With search and replace functionality, you can create stage renaming sequences. And if you mess it up, the great bit is you can just revert back to where you started and try again. MOOM, it makes it easy to move any of your windows to whatever positions you want. Halves, corners, edges, fractions of the screen. And then you can even save and recall favorite window arrangements. So if you've got an arrangement for work, arrangement for home or different projects that you might be working on, and there's also a special auto-arrange feature when you connect and disconnect an external display, like you've just arrived at work or you just arrived at home. It's awesome. I love it. I use it every day. Usher, it essentially can access any video stored in iTunes, Aperture, iPhoto, any connected hard drives on your Mac, allowing you to easily group, sort, tag, and organize them in one place. If you install Perion and Flip for Mac, then there's no need to convert anything into an iTunes format to watch it. So if you've got a video collection scattered across different programs and drives like I do, then Usher can help you straighten it all out. And that's just four of their great apps. There's still five more to check out as well. All of these apps come with free trials and you can download them from manytricks.com/pragmatic and try them out before you buy them. They're available to buy from their respective pages at manytricks.com or through the Mac App Store. However, if you visit that URL before the 15th of September, yes, they have extended the coupon code, so thank you for ManyTricks for doing that. You can take advantage of the special discount off of their very helpful apps exclusively for pragmatic listeners. Simply use the code pragmatic25, that's pragmatic the word and 25 the numbers in a discount code box of the shopping cart to receive 25% off. This offer is only available to pragmatic listeners for a limited time. As I said, it's been extended the 15th of September. So take advantage of it while you can. So a big thank you to ManyTricks for sponsoring Pragmatic. So Nick, I just want to wrap up shortly, but I wanted to talk about some of the different repositories that are out there. And you mentioned some of them already, you mentioned GitHub, Bitbucket, SourceForge, I've come across CodePlex. There's actually quite a few more than that, but I think those are some of the bigger ones. If you were going to be approaching that, which one, I guess, what would your preference be and why? Okay, so from the point of view of the one I actually use myself is Bitbucket. That's because I use a version control system called Mercurial, which GitHub doesn't support. In terms of the one which the most other services currently integrate with, and which has the most other users on it, GitHub is currently the king of that. The risk with both of those is they're actually proprietary software as a service, like they open source a lot of their back-end stuff. And one of the advantages of open source, from a risk management point of view is that there's very little vendor lock-in. The advantage both of those services have is that even though the source is closed, your data is very open. It's very easy to get your source code out because it's a version control system, that's what it's designed to do. and it's also reasonably easy to get your issues out as well. So yeah, it's a case of, yeah, it's unfortunate that the big ones are currently proprietary, but for folks that are starting out and don't have a strong ideological commitment to open source infrastructure stack, the advantage is that stuff integrates with them. There's certainly lots of other options like Gatorious and GitLab and that kind of thing. And so yeah, SourceForge, Allura, RoadCode. There's a variety of options out there if people are looking for something that's actually open source under the covers. But yeah, unfortunately those big ones are currently proprietary services. So. Okay, fair enough. Well, my sole repo that I've got for my open source stuff is GitHub. But, you know, it integrates with the, you know, with Git, funny. Yeah, it's basically the reason the reason they're dominant is they do user experience very well. And so and so it becomes a case of unless somebody has. So Git itself does user experience terribly. It's written by kernel hackers for kernel hackers. But one of the upsides of Git's usability being so terrible is that in sheer self-defense, the internet is overflowing with good Git tutorials. So whereas some of the others which are a bit easier to use out of the box, you can't actually find good tutorials for their advanced features because like with Git you need to learn the advanced features in sheer self-defense. - Yes. - Whereas Mercurial is a bit safer out of the box and so people are, that the dangerous features are locked away a bit and so people tend not to discover them. - Okay, fair enough, cool. Alrighty, well, I think we might wrap it up there, cover the stuff that I wanted to quickly run through. So if you want to talk more about this, you can reach me on Twitter at John Chidjy and check out my writing at techdistortion.com. If you'd like to send any feedback, please use the feedback form on the website. And that's where you'll also find the show notes for the episode under podcasts pragmatic. You can follow Pragmatic Show on Twitter to see show announcements and other related material. I'd like to thank my guest host, Nick Coghlan, for coming on the show. And what's the best way for people to get in touch with you, mate? - Nkoglundev on Twitter. - That's Nkoglund_dev, isn't it? - Yes. - Yes, very good. And you write occasionally at that blog? - Curiousefficiency.org. - Yeah, I love that name too, by the way. So much better than tech distortion. A little bit jealous about that, there you go. I'd also like to thank the two sponsors for this episode. So thanks very much to SapientPair and their iOS app, Shopee, for sponsoring Pragmatic. If you're going shopping and want a great collaborative shopping list app, then Shopee can help you out. It's ad free for the first month, so want to check it out at sapient. That's S-A-P-I-E-N-T dash pair as in two dot com slash pragmatic. I'd also like to personally thank many tricks for sponsoring pragmatic. If you're looking for some Mac software that can do many tricks, remember to specifically visit this URL, many tricks or one word dot com slash pragmatic for more information about their amazingly useful apps and use a discount code pragmatic 25. That's pragmatic, the word, and 25, the numbers, for 25% off the price of your order. Hurry, it's only for a limited time. So that's it, and thank you very much, and thanks for listening, everybody, and yeah, thanks again, Nick. - Thank you, John. (upbeat music) (upbeat music) [Music] (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) [Music] We've actually had a few questions come through during the show. In this particular case, I've counted three so far and they're all from Tristan, a long time fan and listener of the show who lives in Toowoomba, I believe. So first questions first. So what is the deal with Python 2.7 and 3.0? Yep. So, back in 2006, Guido van Rossum, the creator of Python, decided to start a project to address some of the design flaws in Python 2. So, several of them were also design flaws in Python 1, but Python 2 inherited. And so, the approach we decided, or he decided to take to that, is that Python 2.6 and Python 2.7 were actually released in parallel with Python 3.0, 3.1 and 3.2. So that for about four years we were actually maintaining, or actually producing feature releases for two different versions of the language. And the reason for this is that the Python 3 change, the Python 3 dropped a bunch of long deprecated features, but it also made some changes that Guido wasn't comfortable making with through the normal deprecation process. Like the most significant one being the shift from in Python 2 the assumption is that there's an 8-bit string type which may be either binary data or text depending on what you do with it. And in Python 3 that's a very, instead a very strict distinction that there's a string type that can hold arbitrary Unicode data and there's a pure 8-bit binary data type and that the separation between those two is much much stricter and so as it turned out this caused a lot more problems than we expected it to because this was part of the thing of that okay the for a program to actually be ported to Python 3 it actually needs to get its Unicode handling right. Now we made some genuine mistakes in the migration plan whereby some programs that did have their Unicode handling right still needed significant changes in order to be ported and that was just an outright mistake and we're making various changes in Python 3 to make it easier for those applications to port. But there's a fundamental barrier there for a lot of applications where they like going well but we don't care about getting our Unicode handling right because it's not a problem in our environment and our answer for those users is that well that's why Python 2 is in long-term support mode that that we'll be supporting it upstream out till 2020. Red Hat's released Python 2.7 as part of RHEL 7 and that's so that's supported out till 2024 but it's the case of long-term support releases are never going to be as exciting as new feature releases and so people are going but we liked our feature releases, we want to benefit from the feature releases and but in order to get there we have the like going we want to migrate to Python 3 first and that's that it becomes one of those things because the if they're in a business context they may be like going but I can't make the business case for migrating to Python 3. So I'm kind of like going I'm still running Python 2 apps for production. So it's like that that's what long-term support means that's why we do it. So yeah, it becomes that thing of, and it's also one of those things that there's, like Python's used across a huge variety of domains, so like people do use it for network service programming on Linux, but it's also used for data analysis across all of Linux, Mac OS X, Windows, it's used for system orchestration again across all of Windows, Mac, Linux, it's used for games programming, it's used for education, it's used for all these different things and so in a lot of those roles and particularly the educational roles, the Unicode changes in Python 3 were absolutely essential, that Python 2 will not teach you good Unicode habits, whereas Python 3 will teach you Unicode the way it's meant to be done and in a way that actually works across all the major platforms. Whereas Python 2 struggles as soon as you take it off Linux in some ways. But it becomes one of those things where if people are mostly operating in a specific one of those, specifically in the Linux network programming or Linux web service programming, a bunch of the changes we made in Python 3 just seem absolutely incomprehensible. It's like why would you do that? And it was in a lot of those changes and so I've been spending a fair bit of time lately explaining the broader context of a bunch of those changes as to well look if you just look at this narrow niche then sure what we did made no sense but if you look at the broader context of the entire industry and the education role and all that sort of stuff then it potentially starts to make more sense. But yeah it's one of those things that nobody is ever going to be happy with you for breaking backwards compatibility no matter how good your arguments are. Oh yeah absolutely that is always a problem and it's not a problem you can ever really solve ultimately you just end up creating more rods for your own back that hampers your own advancement of the platform and then what have you done really nothing. Well, no, so we've made a fundamental state change in the level of comprehension of Unicode is the aim. Oh, sure, sure, sure. So, but... Sorry, Nick, that's actually the next question. Well, there's two more questions from Tristan, but this next one relates to... The question is this, okay, how does the Unicode revolution affect Python? So the reference for the Unicode question is an article I wrote just this week on the rise of multilingual programming and that's basically that Unicode was again one of those things that the idea of it started in the late 80s, the initial version of the standard was released in 91 and then version 2 in 96 and the one in 96 is basically Unicode as we know it today. And what it basically started was this idea of a universal model for encoding scripts like human scripts is the ones we actually read and write rather than computer ones as a single unified coding scheme so that the computer could always deal with any human language and it could deal with mixed language text, it could do all of this stuff, so like translation and all this stuff that previously the previous approaches around Windows code pages and linux locale, posix locale encodings, they just couldn't handle these use cases properly because they could kind of only talk English plus one other language at any given point in time and that Unicode is basically about trying to reduce that centrality of English that that get computers to a point where regardless of what your native language is you can still use computers to their full capacity and like English is always going to be there are under the covers just because of historical reasons. But yeah, try and get it to a point where the computing, the operating systems and the computing platforms are actually truly global systems, that they will actually work for anyone, not just North Americans, Europeans and Australians. Cool. Very good. I think that's answered those two questions. There's one more left and then we'll wrap up the Q&A at that point, unless there's any further questions. And that is, what are the bigger risks? And I'd like to sort of paraphrase that a little and change that word out to what are the biggest risks in Python releases, in other words, releasing new versions of Python. So, thoughts on that one? Yeah. So for so, well, yeah. So the two points where things go wrong is when we find gaps in our test suite, where there's just like whatever particular combination of libraries or that people were using is just not something that the regression tests cover. And so that can just kind of happen with any release that sometimes we try to avoid it with maintenance releases, which we're just by being very, very conservative in what we change in those. That's our normal approach to maintenance releases. We've had a... the long-term maintenance of Python 2.7 has actually been a bit of a bit of a learning experience on that front in that there's certain libraries that we found we actually have to be add new features to them, which is the SSL networking library. So the one that does the secure socket layer and transport layer security, we actually just upgraded that in Python 2.7 so that the next release of that is actually pretty much a full or close to a full backport of the the SSL module from Python 3. And that's just because network security, it's the case of it evolves too fast that we can't continue with a network security library from 2010 when it's 2014. And so that's going to be an interesting one to see how that goes. We actually got that into Fedora Rawhide, so that will hopefully at least thrash out the Linux issues before 279 goes out. But yeah, so that one's going to be interesting to watch. It's a much, much bigger change than we like to make in a maintenance release, but it's one that we think is genuinely necessary in this case. The other thing where things can go wrong is we've got a continuous integration system called BuildBot that continually runs the Python test suite across Windows, Mac OS X, Linux, FreeBSD, a few other platforms. And that pretty much makes sure it's unusual for major bugs to get through. It does happen sometimes and it's usually a sign of a missing test somewhere. But the one thing that is actually genuinely hard to test is the installers. just because in testing those is difficult to automate and so it isn't. Yeah, it's a good point. And so those it's the case of those it's a case of the we do the alpha beta release candidate cycle with those. So try and flush out the installer issues in those releases. And so at that point it becomes a matter of doing that kind of change in a way that people get the opportunity to test. So yeah, it can be an interesting... Yeah, those are the main things that happen. Maintenance releases, as I said, we try to be very conservative with. And then the feature releases, it's generally will be where the bigger changes will get confined to. And so it will sometimes be the case where we'll go with something that's like, okay, yes, technically that's a bug fix, but we're still not going to do it in a maintenance release just because the fix is too invasive. and so we'll punt on it to the next feature release. So yeah, and that's kind of where we do a lot of our risk management, is in deciding where to fix something. Because people tend to do a lot more testing when they're changing between major versions, we'll put any of the larger changes, we'll just postpone until the next. So like at this point, for example, Python 3, Python 3.4 is in maintenance. So that's the feature release we did earlier this year. And then Python 3.5 will be at the end of next year. So any bigger changes and any new features will all go into Python 3.5. And only the small non-invasive bug fixes, docs changes, all that kind of stuff is what will go into 3.4. Cool. Well, I think Willem truly answered those questions. So that's awesome. No, thank you. Thank you for that, Nick. I appreciate it. And thanks for the questions in chat room, Tristan. And thank you, everyone in the chat room for participating. Really appreciate it. I know it's been a quiet night because we're recording at an unusual time. It's not the usual recording time. And I guess I'm just being selfish because Nick is in the same city and hence time zone as me. So hey, you can sue me later. It's all good. - Works for getting a hold of me as well. - Yeah, well, that's right. I mean, normally I record at four in the morning. So, you know. Yeah, you wouldn't have got me out of bed at four in the morning. No, no. I remember watching what time you used to come into Boeing, mate. Jeez. 4am like hell. I'm worse now. Red Hat's far more relaxed. Oh, seriously? We used to come in at 10 in the morning and leave at like, like what, 11 o'clock at night? Jeez. Actually, no, okay. So, I didn't remember I ever shifted my schedule that much at Boeing, but yeah, okay. You did. I guess I haven't changed the time. I just like, "Oi, where the heck's Nick?" I'm like, "Oh, yeah, that's right. He's not awake yet." Anyway. It's all good, mate. What do you mean normal people don't work ten till seven? Oh, well, I'm sorry. Far be it for me to ever refer to myself as normal, but anyhow. - Yeah, we know that's simply not true, but anyhow. So, all right, cool. If you want, there's a show bot, I don't know if you've come across 5x5 or any of their shows, they have a live show bot and accidental tech podcast. I alluded to it earlier, there's a guy called Casey Liss and he's one of the three people on ATP and he put together this, it's essentially two JavaScripts that one runs in Node.js in the server side other one served up to your browser and it allows you to... it hooks in basically an IRC bot and anyway so the the URL is techdistortion.com/showbot and if you go to that URL you'll see a table with a list of titles in there and you can vote on those titles so I don't know if you've had a chance to check that out at all Nick but I just if you'd like to jump on there and vote for whatever ones you prefer and I'll try and I'll try and I'll try and pick the ones that most people have voted for, because up until now, I've been the sole gatekeeper of titles. Sort of a chance to sort of do that, I guess. You did just remind me of one of the reasons why one of the other reasons why people do stuff is open source. Oh, yes. It's one of those things of that when your business is not software development, but you write some software to solve a problem for you, what you actually find is a lot of these online communities, so like the podcasting community, it's, there's that culture of, there's a culture of it being a community and it's a community that helps other members of the community. And so just like people doing, people who are into homebrew or cooking will share recipes about how to make stuff. So podcasters will say, "Hey, here's this tool I built to make doing my podcast better and easier. Maybe it'll work for you as well." And so it becomes that thing of people sharing the stuff they've put together. And so then instead of everybody having to solve that problem independently, one person solves it well enough for themselves, somebody else goes "Oh, okay, I can take that, all that works for me, but I'll add this extra feature and contribute it back." And so then everybody kind of ends up with this better, it becomes this thing of they're the non-rival parts of the system, they're the things that people, the things that just need to be done. So people that can actually do do the bit they're interested in. And that it's the, the free online infrastructure has got to the point where that, that sharing is so low friction, that it's actually worth doing because it becomes the case of well, even if nobody ever uses it, it didn't cost you anything to do it in the first place. And it may have saved you something. So - Yes, it's the sort of thing, yeah, absolutely right. And to completely agree. And the great thing about this particular show but when I read through it is that, 'cause I've been playing with JavaScript on and off for ages and it's the sort of thing that I can pick up very quickly. And I look at the code and it doesn't take me long to get my head around it. Could I have written it on my own? I think eventually, probably yes, but it would have taken me a lot longer 'cause I'm not a web developer. So it's easier for me to look at someone else's open source project and they've done a lot of the stress testing and you know, so yeah, they've got all sorts of IP address filtering and you know, like multiple connection requests. People try to break the thing essentially because that's one of the great things about being on a show like ATP that has, you know, unlike our chat room that's been hovering around the 10 people mark for the whole episode, yeah, which is fine. Unusual time to record. You know, there's like hundreds in their chat room and there's some people in there that just, you know, take it upon themselves to be jerks and they will try and crash the show bot and say, "Hey, I crashed the show bot." You know, it's just jerks. But anyway, but the thing is that then leads other people who are sympathetic to go to the open source. So, they have a look at it and they have some, you know, pull requests and say, "Hey, you know, this will solve this problem and and this will solve that problem. And the community sort of bands together and you get a much more solid end result that now I can take the result of all of their efforts and essentially tweak it for my site, which is what I've done. And I'm not finished. There's still more to be done. And I'm also adding a few features as well, myself, which I may contribute back later, but some of them are specific to the show. So we'll see what happens. But anyway, You did remind me of two other phrases I've used to describe open source at different points. So one is as executable knowledge sharing and then the other one is creating opportunities for serendipity to happen. So yeah, it's that thing of does releasing your stuff as open source guarantee that other people will find it useful and help you improve it? No, it doesn't. But I So I can tell you one thing that will guarantee that that doesn't happen, which is not releasing it in the first place. You can't definitely ensure success, but you can certainly prevent it. *Gasp* (video game music)