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)
[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)