The Changelog: Software Development, Open Source - GitUp and the UX of Git (Interview)

Episode Date: September 5, 2015

Pierre-Olivier Latour joined the show to talk about his history as a software developer - everything from creating Quartz Composer, working at Apple, to his new project GitUp and the user experience of Git.

Welcome back everyone. This is the Change Log and I'm your host, Adam Stachowiak. This is episode 172 and on today's show we're joined by Pierre-Olivier Latour. We dive deep into Pierre's history. We joined this call to talk about Git and his new open source project, GetUp. But we had to go so deep in his history to fully appreciate what he's done and where he's going. So we go back to his history at Apple, back to his product he developed called EverPix, and went through all of that. And then at the tail end of the show show we start talking deeply about get get up and get ux and why you might love hate get we'll see but we had four awesome sponsors code ship

imagix digital ocean and century century is a new sponsor for us love those guys thank you so much for supporting the show our first sponsor is code ship coach hip launched a brand new feature called organizations a few months back everyone's been loving it now you can create teams you can set permissions for your specific team members and you can improve collaboration in your continuous delivery workflows you can maintain your centralized control over your entire organization's projects and teams with this new feature. It's super awesome. And you can save 20% off any premium plan you choose for three months by using our code, the changelogpodcast.

Again, that code is the changelogpodcast. 20% off any plan you choose for three months. Head to codeship.com slash the changelog to get started. And one more thing I want to tell you about. Sean Devine is doing an API workshop called API First Training. And guess what? He's going to use Codeship as a demo tool. The URL to learn more about that API training is in our show notes. So check those out. But now onto the show. Everyone, we're here today with Pierre Olivier Latour. Everybody in this entire world knows that I'm not the best with French names, Pierre, but how did I do? You did pretty good. Hello, Adam. Thanks for having me with you today.

So, Pierre, we've been chatting quite a bit here before we actually started hitting the record button. And I've kind of gotten a little bit familiar with your past, your passion for software development. You got a deep history, everything from Apple to companies you've started, from ideas you've had while on vacation to, you know, you name it. But what I love to do is sort of start the show off with going deep into your history if we can. But before we do that, can you kind of give the

audience who may not know who you are a brief introduction to who you are? Sure. I'd be happy to. So like you mentioned, I'm actually French. I'm not sure how relevant that is, but I might explain some of um accent and um i've been doing software development uh all aspects of it really from writing code of course a lot of that in multiple type of languages but software development of mobile apps of desktop apps of server-side code kernel kernel drivers, like this sort of things. I've been doing that for a little more than 15 years now in a, you might say, professional way. And what I mean by that is writing code that is for products that ship to consumers who pay for it, right?

Or to an extent, sometimes use it for free. So I'm not counting little safe projects done on the side, this sort of things. And I live in San Francisco, in the Silicon Valley, that is, very close. I've been working at some large companies in the Valley, some startups. I had my own startups over the year and so on. And yes, my big thing is software in general, all aspects of it, which I'm very interested in.

And I think when anybody looks at your history and sees this 15-year professional software development, as you said, they're going to see names like Apple on it. And Apple obviously turns heads when anybody sees them on their resume. So not to camp out there, but how much further back in your life do we have to go to kind of figure out where you got this itch of software development? When did things begin for you to become a software developer? background, I guess, information is I've always been tinkering to an extent with, you know, electronics when I was a kid, building radio-controlled airplanes, like all these sort of things. And a logical evolution at the time was starting to do things with the personal computer. My parents had a Mac Classic, a very old machine, right? And then I had some Atari, which was reasonably popular in France. There was also the some Atari, which was reasonably popular in France. There was also the Amiga, which was pretty popular at the time.

And, you know, what you do on a computer is rapidly you want to create things. And so I played at the time quite a bit with, I think it was HyperCard, and then started learning BASIC, which we had actually at school to an extent. We had some programming lessons already at that time. We were learning, if I recall correctly, some basic, and then we did learn a bit of Pascal. And then I started creating things. And then I started creating software based on ideas.

And then, you know, what I would like to do for me and then started distributing it. And that's how the whole thing started. A lot of the time that was slightly before internet, when my first software was distributed commercially, it was just borderline where internet was starting to be mainstream and to an extent. And it was still a time where you had to put your sharewares and applications on things called, if I recall correctly, the InfoMark Archive, something like that, which was done by the MIT.

And, you know, storage was very expensive at the time on servers to store the binaries of the apps and so on. So you had all sorts of FTP mirrors and you had to distribute your software on CDs that came with magazines and lots of hoops to jump through that we don't have to do today anymore, of course. But so this is kind of how it started. I just looked up the Mark Archive on Wikipedia because I got fast fingers. And it says it's a computer-related mailing list archive.

Does that ring a bell? Yes, yes. That's how, at the time, if you were doing not a professional, you know, commercially, well, not a professional software distributed by an official publisher in stores and this sort of things, like Photoshop, for instance. to reach out to people. This was how it was happening. You had to send somehow your compressed file of your little app to that server and with a special text file where you were giving the right to that archive to redistribute your file under certain condition. And then magazines around the world

would grab that file if they liked the app and put it on their CDs, which was coming with the magazine. And it was like i said jumping through hoops but it was pretty cool because it you did not have instant gratification like you might have today it was really deferred you put your thing in there and then you don't know what's going to happen and then one day you receive um a japanese magazine a mac magazine you know, I was in France coming all the way from Japan. And because they had put your app on the CD that came with their magazine, which is, but it might've been two, three months later or who knows. And so this type of deferred

gratification was pretty nice at the time. I think your mention of the instant gratification is certainly a talking point because in today's world, we really are instantly gratified with likes, with tweets, with followers on GitHub, with forks, with issues. There's something, there's like instant feedback loop to whatever we put out there, whether it's the smallest thing to the biggest thing, whether it's professional work or if it's side hobby, fun stuff. What was it like to be in, let's say, a slow-paced world as a software developer, just kind of butting up back then? That's been quite a few years. I think it was, it teaches you patience. You could not easily update your app. Like today, most apps are auto-updating.

By definition, it really started with the iPhone, and then it rolled on a desktop. And then apps are self-auto-updating, even if they're not part of the App Store. And this is the way to go. It's obvious for multiple reasons. But at the time, you did not really have that. The latency between a new version and the fact people would have it would be significant. And so you had to, I think, pay a lot of attention to the polish of your software and the quality of the code and all of this. Now, at the same time, I think the software world was moving slower, which means it was less likely that things would move very

fast under your feet, meaning the OS would not be updated as often. Technologies you were relying on would not change as often and so on. Well, today, you know, it's impossible. I think that's one of the challenges with today's development is it's impossible to keep anything constant. So you might have, you know, I'll use as an example, Comic Flow, which is an iPad app I've done a few years back, which is still, you know, quite popular today. It's an app to read comics. And this is the same code base that was written, I think, five years ago for the original iPad, if I'm not mistaken, the exact same code. And the problem is when iOS 7 was released, the whole UI changed.

And it's not a big deal because your app still works on it. But if you want to fix one little bug because there was suddenly a change in behavior in the OS and your app, even if it works almost the same, there's a little thing you need to fix. Well, now you need to take your app and build it against the latest SDK. You have no choice. Otherwise, Apple does not accept your app into the app store. So suddenly you have to build your app against iOS 7, even though it was built originally and designed around iOS 5. And just the act of

building it will expose a bunch of things that will break because they've changed the name of functions. They've changed the behavior of things. They've changed how the UI worked, a bunch of things that will break because they've changed the name of functions, they've changed the behavior of things, they've changed how the UI worked, a bunch of... And so what would have turned into fixing, and I'm not necessarily exaggerating, a single line of code is now a whole project of changing your app. And the thing is, you don't have a choice

because if you don't do that, then your app is a little bit broken. So things are changing under your feet. And I would say it's even worse, in a way, on the server side of things, because you can write a beautiful piece of server code that is fully self-contained, very clean, and so on. But guess what? Now it's written in Python.

A new version of Python comes out. You might say, well, that's okay. I'm going to stay on the old one. But then your whole software stack, which is on Amazon, is running, obviously, their own servers, and they have their own security rules and policies. And they say, well, guess what? You cannot run that version of our OS anymore because it has security issues and we need to update. And now it's been X number of months, we're going to force update all the machines.

The version of Python you're relying on has to be updated as part of that. And so you haven't changed anything on your side, but things have changed underneath you. And then suddenly a bug appears while there was none before. And so, you know, it's, um, it's a bit like Sisyphus in a, in a way, right? You keep pushing that, that, that, um, boulder above the mountain and it falls and then you have to do it again and again and again. Um, it was nice, I think, at that time, because the pace was much slower, and when you were riding something, you were pretty confident it would stay the same for a couple years more, and so on. It was a different time.

Now, obviously, today's time comes with its own set of advantages. It's not all negative, of course. You said you're a Frenchman, and you said that back in this day, let's sort of not just paint the history, let's sort of paint some timelines. You said when the internet began, when did the internet begin for you?

Yeah, that's a completely fair question because it was very different in Europe and in the US. Internet to me began when, I guess, I cannot recall how it happened, why it happened, but we did buy a modem, which at the time was probably 25 kilobits per second or something ridiculous like that. And it was pretty expensive because you had to pay on the phone lines.

And that's how I started using internet. What year was that, roughly? I'm thinking personally it might be like 95, 97, but I, 97, but yes, that's what I would say. That's what I would say. My gut feeling would be 95, 96. Because you're around my age, I'm 36. So I think you're roughly the same age. Yeah, I'm 35, same thing.

And I would say for me in France, it was around 95, 96. Yes, that's the best guess I can do. Now, I did go to the U.S. a number of times when I was a kid and then later on. And in the summer of 97 or 96, I was in the U.S. And yes, you could see, I mean, going to a summer school there and the school slash university was very well connected on internet and so on, more than what I had access to in france now france you may be aware of i had this whole thing which was kind of pre-internet before internet right they called the minitel which was a computer networked on top of the phone system with little computers that a lot of french

households were having with a little keyboard and kind of a text-based display, but able to do graphics and whatnot. And that lasted, if I'm not mistaken, that was the 80s to early 90s. And then it disappeared when internet happened. But it was definitely omnipresent in the French household. And it was the distributed network of network terminals. It was surprisingly ahead of its time in a way, but way more limited than internet because it did not have the big thing

that the hypertext was and HTML and all of this. But so our home did not have that, however, one of the few homes that did not have this system. So, but we did get a modem and all of this later on. So for those who may be fellow Frenchmen listening, they may go back in history and think a little bit, man, when did Minitel kind of end or what was the state of it? And in 2009, based on Wikipedia, because I got, again, fast fingers here,

still served roughly 10 million monthly connections back in 2009. But ultimately, in June of 2012, they decided to retire the service. Yes. And the unit, as you mentioned it, 10 million monthly connection is for a population of 17 million people, close to that now, which is probably around 25, 30 million households, is extremely littered. At its peak, I'm sure it was quite more than this.

It was really present in the vast majority of households. It was very interesting. So we mentioned roughly the timeframe of when the internet began for you, 95, 97, somewhere in that timeframe there. And you mentioned getting a professional app, which you describe as something that someone buys. You mentioned delivering something pretty early. I think you even said your childhood, if I remember correctly.

What was the first thing you built? What was delivering it like? What was the app? I'm not sure i i recall um this is uh this is a while back right we're touching 20 years ago right um we're definitely tapping into the into the deep brain here yeah yeah yeah yeah um it would have been utilities like little things little apps that would do one single function. And I'm trying to remember, I think one of them was to do patterns that you would use to edit patterns or combine them, I don't remember exactly, that you would set as desktop backgrounds. Now, it may sound strange today, but on computers at the time, they had very limited video memory and regular memory, as a matter of fact. And so you weren't

going to use a full image for your desktop background. You were going to use a small pattern that you would simply repeat. There wouldn't have been enough memory to necessarily store the entire photo, for instance, filling the entire screen. Or if it would have been enough memory to necessarily store the entire photo, for instance, filling the entire screen. Or if it would have been possible, then you would have used too much memory anyway to leave enough available for the other apps and this sort of thing. So I remember working on something like that. And one of these utilities being the first app I would send to this archive of software.

And then that ended up on various cds and all of that well that's interesting too the coming back to the cds aspect you mentioned being in france getting an a magazine from japan or something like that and it having your uh your software on it and how did they deliver it what was well i guess what was interesting about that was was it like having a book published? Was it like the moment of moment? Well, to an extent, I think it's a fine analogy. The type of gratification is very different. Like today, there are millions of developers on all sorts of technology stacks.

The most easy to use, widely used tech stack is obviously the web tech stack, right? And you can do a website, an interactive website, and then that's it, it's online. Anyone in the world can go see it. It's instant. It's very different from at the time, suddenly writing a piece of software, uploading it super slowly to the FTP server

or a mirror of it somewhere in the US, on the MIT, when you're in France, and then crossing your finger, putting your little text file with it, describing the app, describing some sort of license, something like that, just to say, you know, what were the conditions under which you allow it to distribution on CDs and things like that. And I think I might have put something along the lines of please send me a magazine at this address if you distribute it but some magazines would do it anyway um and and then just wait and cross your finger and hope but at this point you know i'm not sure anyone at the time i

can't say for sure but i would be skeptical A lot of people would necessarily go into the archive and just browse. The way we got apps was through these CDs or before the CDs, because it needs to go further than that. They were coming with little floppy disks, right? I mean, not floppy, I mean the 3.5, the small disk. I'm looking for the exact term in English, but not the floppy ones, the smaller version, right? And, you know, it was exciting.

So I could get your magazine once a month, and then what apps am I going to get with it? And type of freewares and sharewares and all of this. And they have to be very small because they have to fit on 1.5 megabytes or whatever it was, or less than two megabytes for a number of these little apps. So that was pretty exciting and you're correct using the analogy that it was equivalent to being published and then later on you had um i think it was download well cnet something and then download.com started to be uh the places where you had to be uh to i'm i will just want to be clear by the way that i'm talking about

the mac side of things, right? I cannot speak for the experience of publishing, distributing software on the Windows platform or Amiga or Atari or any of these. I'm glad you made that mention because I was going to ask you about that. Because it seems like you said the very first computer that your parents had was an Apple Basic, right? Mac Classic. Mac Classic, sorry. Yes, yes. Well, we had an Apple II, actually, to be correct. We did have an Apple basic, right? Um, uh, Mac classic, classic, sorry. Yes. Yes. Well, we had an Apple two actually, to be correct. We did have an Apple two. Um, and, and I mean,

I have photos of me as a, as a toddler, like next to the Apple two and this sort of things. So that's how I kind of recall. Um, but, but we did have a Mac classic later on and I guess we, we were from the start an Apple house in a way. And then when Apple was kind of losing some steam, for some reason we had an Atari and then went back into the Mac later on.

And just for the English speaking out there who don't have an accent and no poking funs whatsoever, I think you're saying Atari. Yes, yes. Okay, just making sure. Atari, yes. Okay. Just making sure. Atari, yes. And it was a big deal in France, along with Amiga. I love the Atari.

I mean, who didn't love the Atari, right? I mean, that's when the light bulbs went off for so many people. Yeah, yeah. Well, Pierre, let's pause there for a minute. Since we're talking about Apple, I do want to dive a bit into your Apple history. But let's take a quick sponsor break. We'll come back and we'll talk about Apple for you and some things you've did in the Apple space and continue to do, obviously. But we'll be right back.

ImageX is a real-time image processing proxy in CDN and let me tell you this is way more than ImageMagick running on EC2. This is way better. It's everything your friend and developers have dreamt of. Output to PNG, JPEG, GIF, JPEG 2000 and several other formats. And if you're like me and you've ever argued with your boss or a teammate about serving retina images to non-retina devices, you'll appreciate their open-source, dependency-free JavaScript library that allows you to easily use the ImageX API to make your images responsive

to any device. Now all of this takes a platform, and the ImageX platform is built on three core values – flexibility and quality, performance and affordability. When it comes to flexibility and quality, Imgix has over 90 URL parameters that you can mix and match to provide an unlimited amount of transformations that you need for your images. And they take quality very seriously and because of their commitment to quality several top 1000 websites in the world trust them to serve their images now when it comes to performance imagix operates out of data centers filled with top of the line mac pros and mac minis and they're set up for a completely streaming solution. This means your images never hit the disk.

Images are served by the best SSD-based CDN for delivery around the world anywhere extremely fast. And while we're talking about speed, almost all the image processing happens on GPUs. This means transformations are super fast when compared to competing virtualized environments. And lastly, it's all about affordability. Everyone wants to save a buck.

That's how the world works. Because Imagix processes close to a billion with a B images per day, they're able to make certain optimizations at scale and pass those savings on to you. To learn more about Imagix and what they're all about, head to imgix.com slash changelog. Once again, imgix.com slash changelog. And tell them Adam from the changelog sent you.

All right, we're back with Pierre Olivier Latour, an awesome French software developer with a deep passion for some really cool stuff. And Pierre, you said your household, your mom and your dad, yourself, were Apple. You got a picture of yourself next to a Mac Classic. Or it was an Apple II. Apple II. Apple II. So, I mean, as a toddler, not too many people have that kind of history with computers or even software development. So you kind of go really, really far back.

And if anyone scans your history and learns a bit about you, one of the things they sort of notice pretty early on is that you're an Apple guy, of course, but that you also had the joy of selling a company or a product. I'm not sure how you really phrase that to Apple, which ultimately became Quartz Composer. Can you speak to that a little bit? Yes, yes, I certainly can. I think it's important to have a little bit of history for the context. While I was, so I've always done, um, as you mentioned, a number of software projects, some of them personal, some of them commercial. And, um, towards the end of, um, university, I guess you would say that I was going to

an engineering school in Switzerland at the time. Um, I was working on, um, a video game startup that I co-founded with a few other people and mostly a lot of graphic designers as a matter of fact I think we were six graphic designers and a couple programmers and plus marketing and this sort of things and so we worked more than two years on a video game that that we published and distributed in Europe and all of this. And it was actually a real-time 3D video game. And that was the result of me starting to experiment a couple years before with the real-time 3D graphic chips that were starting to appear on the Mac. And so you might remember at the time companies like 3DFX,

which were starting to build these cards you could plug into your PC and suddenly you were able to do 3D rendering in real- incredibly faster than doing it on a cpu of course and well on the mac you know it took a long time before 3dfx was compatible with the right drivers and whatnot but there were definitely ati chips starting to appear on some of the laptops and so on and there was what was called quick Draw 3D at the time. And some games starting to appear real-time as 3D, etc. And to me, that was a very interesting field, how you actually create 3D graphics on a computer.

And so I started learning a lot about this and doing wireframe rendering and all software rendering, then starting to learn how to write real-time 3D rendering, but using the low-level drivers of the hardware acceleration cards, video cards. And all of that led one thing to another and starting to build a game and having people join, et cetera, et cetera. And so one of the things I did during these two years was obviously gain quite a bit of experience of building real-time 3D graphics. And one field I was always interested in, another field, I guess, was, you know, just real-time graphics in general and music visualization and just creativity. And I just wanted to experiment with that and poking around and what you could do and how you would create motion graphics in a more intuitive way.

And there were a number of products, obviously, in this field at the time, but they were all to complicated to use or felt not approachable at all. You know, like this type of clunky, very technical UI and so on. And the second very important limitation is they were all software. And so the rendering was, as you can imagine, very slow or it had to be small windows and so on. And I'm talking on the Mac platform, but the PC platform was not much better. And so I started building prototypes of a 3D motion, sorry, a hardware-accelerated motion graphics engine that was very, very flexible based on OpenGL at the time. And it was highly modular, combined with an interface that was node-based,

where you connect, you know, nodes, each node doing a single function and this sort of things, and then writing 100 or so of these nodes and starting to have interesting creations. And that was called Pixel Shocks, and it was distributed as a public beta. It had a website. It had a community, motion graphic artists,

you know, artists in general, people doing installation website, it had a community, motion graphic artists, artists in general, people doing installation, people in the video industry, people doing animated graphics during shows, DJs, this sort of events. So a niche community, you could say, but very interested and active around such a product that was really unique at the time and enabled a lot of creativity and freedom and creativity. And somehow this got up to the attention of various people at Apple in graphics and imaging and all this sort of things. And it happened that at the time, I was lucky to be doing my master's thesis at Stanford, which is about a 10 minutes drive away

from the Apple campus in Cupertino. And so I met with various directors, executives, and so on at Apple. And then they were really, really interested in this tech. And they ended up acquiring the all the technologies the IP and all of these things and I joined Apple and then I built a team there and that product became Quartz Composer which was the and still to an extent the standard way of doing motion graphics on OS X. So the technology was distributed with, I think, well, every Mac since 10.4,

which OS X 10.4, I mean, which was in 2004, if I recall correctly. And yeah, all over the place, wherever you needed motion graphics on OS X, if it's simple things like screensavers to iTunes visualizers, to all the effects in iMovie, in iPhoto, in the original Time Machine, some of the Apple TV, the version one was running it for a number of the animations.

The Apple stores reservation system at the time, like all the animation with the QoL and stuff was running it, really like Final Cut Pro, Motion, like a bunch of places were leveraging its power and big clients of it were internally the HI team, which is the human interface team. And they were using that as a replacement for director, micrometer director, because it let them be a lot more creative and do things in real time. And so a lot of the prototyping for the OS X user interface was done on Quartz Composer. A lot of prototyping for the iPad, you know, the iPhone, like this sort of things. And then today, even today, companies like Facebook still use it extensively for prototyping and creating interactive mocks of their products as well as IDEO to an extent and so on.

So it ended up being used really all over the place. The most funny or original, I should say, example I heard of its use was after the iPhone launch and official presentation by Steve Jobs, the director of the graphics and imaging group kept to me and said, oh, I learned that the whole display system to display the iPhone on a gigantic screen on stage and all of that was actually built on course composer, which I thought was cool. Obviously I wasn't in the know of the time for this sort of things, nor did I have to be disclosed on this, but I thought it was kind of neat that it was also used for that.

It's so interesting to hear this kind of history. I think that one of the things I love doing about this show is that, you know, just to paint a little bit of the future of the show we're doing here today is, you know, we're having you on here to talk about GitHub, which we'll get into much deeper later. But as I started to dig into who you are, I was like, wow, this guy's got a lot of history in software development.

And you were at Apple in a pivotal time for the company which was when they launched the iphone and that was in like what i think it was 2008 or was it 2007 it wasn't yes i think it was announced in 2007 i don't remember exactly uh yeah like it was at least teased it wasn't released i think it was 2008 released yeah there was a gap of a few months uh before the announcement and then the official release. Six months, maybe. I don't recall exactly. Yeah, it was certainly a very interesting time.

It was a great time to be at Apple. It was after I joined in, I think it was June 2003. So after the turnover had started, Steve Jobs had joined a few years before. He had done already the iMac and then the iPod and consolidated the product lines. And he was starting to get, you know, the seeds were in place. But it obviously significantly accelerated later on with the iPhone and the App Store and everything else that came along. It was, yes, a very, very interesting time because Apple was not too big.

I think when I was there, it was about 14,000 employees total. Now it's probably 30,000, 40,000. I mean, don't quote me on that, but I think these are the numbers. Right. A lot of salespeople. That was when I joined,

it was just before the Apple store, if I'm not mistaken, or barely. So now Apple has a ton of salespeople, huge workforce, much larger engineering teams and all of that but you know it's um the department i was at graphics and imaging was actually very small it was about 50 people and um minus you know the people who who are managers even though engineering managers like i was were definitely cutting a lot not just managing, but still not coding as much, shall we say.

A couple of QA people, administrative assistant, and so on. So maybe 45 effective engineers, and that small team was responsible for all graphics and imaging on the OS, excluding QuickTime, which was a separate team. And that means all the 2D graphics, so that means Quartz, all, and PDF, all of that. That means all the hardware acceleration, all the Windows server, all the 3D graphics,

all the color management system, all the image capture, all the printing, you know, everything that touched pixels. And so a very small team. That's so crazy, man. Yeah. I mean, the Apple. You have such a hand in their history.

It's, yes, it's unheard of. And in terms of productivity, right? And Apple was, I can't comment on how true that still is, having been out of the loop for some time. But Apple was exceptional in terms of, and a software engineering division, in terms of productivity per engineer. It was, the results were there. So these are facts, right? You look at the number of engineers, you look at the output and the quality of the output

and the creativity and all of this. To give you an example you a couple of examples, my immediate neighbor, office space-wise, was the creator of Core Animation, which was the foundation for UIKit, which was the foundation for the whole UI for the phone. And it would not have existed without it, right? And that's it.

That's one person, extremely talented, of course. My other neighbor was the engineer behind Core Video. And again, which was a foundation for all the video tech, all the modern video pipeline that was done on OS X and the phone and all the QuickTime 10 and all done on OS X and the phone and all the QuickTime 10 and all of these things, absolutely critical. He was also writing a number of drivers secretly for OS X running on Windows boxes. It was a different story.

And so it's just that. It's just like you walk 10 feet and you're in the office of the person who writes, you know, like the two people who write the entire quartz engine for 2d rendering on OS 10. And that's it. It's things like that. So the,

the, the magnification is the leverage magnification was just insane between people and output and the ability to learn and so on. So that was a very, that was a really good place to be at this department specifically because graphics are everywhere. So we were having prototypes, one of the wear groups at Apple

to have access to a lot of prototypes because, you know, a new Mac comes out. Well, guess what? It comes with a new hardware video card. That's pretty much always the case. And so, well, guess what? New drivers, things to test and all of this. So we would have access to them.

Or when the camera was, iSight was added to Macs, like all this sort of things, then you have to build things for that. And guess what? It's graphics. When you have new apps, if it's a new iPhoto, a new iMovie,

well, guess what? They leverage a lot, like Course Composer and any other techs. And so you you need you're disclosed because you need to work with them um so that was a great place to be exposed to gasoline things that were going on and also learn because um i was one of the the youngest in that um team at the time and a number of people were coming from next and we're definitely veteran of the industry, right? Another neighbor of mine was the creator of Painter, for example. You know, that very big painting app, like about 10 years ago or so, 10, 15 years ago

on the Mac and then PC. So it's like you were tapping into a body of knowledge that was just phenomenal in terms of ability to learn. And it was very unique on a number of levels. And I have not seen that to this extent at other places afterwards in my career. And I don't know if that's still the case at Apple today, because people move on and then now it's much bigger, a lot more engineers. The recruiting bar might have been lowered because there's no miracle. If you want to hire a thousand engineers, you can't be as selective as if

you want to hire a hundred. When you say painter, do you mean Corel Painter? Yeah. Well, before it was built by Corel, if I remember correctly. I think it's just interesting to see that a budding software developer decides to really get interested in 2D and 3D graphics. Tinkers, as you said before, and I know that Tinkery means a lot of things to a lot of people, but ultimately you created PixelShocks, which was renamed to Quartz Composer, and then you have this history at Apple in one of the most pivotal moments of their history.

And I'm assuming only just based on what I see of your resume that it could have been a pivotal moment in your history as well. But I think why I say that is that there's so many listeners out there thinking, well, here I am tinkering on X, Y, and Z. Here's something I'm interested in whether whatever it might be and to see your life and the way that your career has played out and who you worked for because of just some true passion and some true interest and you and you followed it and ultimately it got you to the places you've been in that time period i think it's just so interesting and so also so inspirational to those out there who are like, I'm tinkering on this little thing here. It's probably nothing. And it's a big deal.

It could be a big deal. It could be a big deal, but we all have to be to be honest here. Commitment is of the utmost importance or importance. most important or important and um you know i think we'll start by tinkering on things and software programming is especially a fit for this it's a lot easier to tinker and experiment obviously in a non-tangible world than trying to do that in hardware and so that that enables a lot of creativity and there is pretty much no cost in terms of money if you scrap a project, right, and cancel ship it, and then get it to users, and so on and so on. Philips Health Shocks was discovered by Apple to an extent,

because it was public at the time, and it was functional, and it was a piece of technology, truly. It was not a uh, a few things put together like that. There was an engine layer and it was an editing layer and it was clean separations the way it was built and a bunch of things that I learned through years. And of course, after I joined Apple, I rewrote the whole thing. I think it was twice at least. Um, because you learn a lot more and you're like, Oh, it's suddenly it's a big deal. It's a system technology. It's going to ship as part of every freaking machine that Apple ships.

So you have to be careful when you were opening your Mac for the very first time and you booted the very first time. There's this thing that appears that's called MacBuddy, which is that setup assistant. And the very first animation MacB Mac buddy is running Course Composer. I can't say if that's still the case anymore, but it was the case for a number of years, for instance. So you have to make sure your thing works. And when you start having a piece of technology that is pervasive among all these products,

well, you know what they say, with great power comes great responsibility. So I learned a lot of things there in terms of not what to do when your technology is everywhere and not modifying this piece of code too fast without being careful, like this sort of things. But the main point I was making is that tinkering and being enthusiastic and all of that is the start. After that, you do need to follow through and just bring the project to completion. That's very important. Yes, to me, that's critical because otherwise,

the various opportunities that I had through the years would not have had the you know the substrate to to appear if each product had been like half done or not really functional or not well defined or this sort of things it's a ton of work for each of them well this is a good chance to to take another pause when we come back i want to talk about everpix it's not exactly the next thing uh unless for some reason you would like to talk about the very next thing in your lineage and your resume, Cool Iris. I want to jump into some of the things you did at Everpix when we come back from this break. Is that cool with you? Do you want to go from there? Do you

want to talk about Cool Iris a little bit to kind of wrap up some some timeline for yourself um you know Kudaris was a couple years after um after Apple um I left Apple in 2009 um so I worked on the built and and led the course composer team at the time we did a couple releases um as part of the US then I figured you know, I'm pretty happy with things that wanted to tackle something new. The iPhone had just been released. Um, the SDK was announced by Steve Jobs out of nowhere. Um, I, very few people knew about that at Apple. So it surprised a lot of engineers like, Oh, by the way, in six months, there's going to be an SDK for people to write native apps with. And so it was kind of scrambled, putting engineers together, starting to put that SDK together. And at the time, like I said, it was roughly after I think 10.5 had shipped or 10.6, I can't recall exactly. And I figured, okay, well, that's a good transition point. And the iPhone's

going to be big. I should probably do something in that space. And so I joined the iPhone team and helped with the SDK and all the media side of things and graphics and whatnot. And after the SDK release, I ended up leading and managing a team that did the web technologies and specifically hardware acceleration in the web browser, which was very new at the time and that appeared originally on Safari, on mobile Safari to be precise. And, you know, this idea that you can take your HTML divs and blocks and so on and animate them and have hardware acceleration for that. So CSS transform, CSS animations, hardware acceleration. And so that was a dedicated team, very senior team. And so I managed that team for a year or so, if I recall correctly.

I learned a bunch of things about the web. And then I figured, okay, it's been six years at Apple, five and a half, something like that. I would like to do something else. And I took a sabbatical, joined this cool startup for a couple of years. That's where I started building mobile apps the one that some of your listeners might have used at the time was called discover which got pretty popular it was an interesting way innovative way of browsing and exploring really wikipedia done for ipad launched very soon after the ip was launched. And the main idea there was that what if we take the Wikipedia content,

which is encyclopedic content, so therefore kind of boring, and make it like a magazine. And very nice presentation, layout, the whole thing dynamic. And it was completely different from any other Wikipedia clients who were just taking the web pages and possibly styling them a little bit with CSS and that's it. It was built from scratch and doing a number of interesting things in terms of innovative, in terms of user experience and search abilities. And so yeah, the app got pretty popular for some time. And so it was a very interesting experience for me. I was in Japan at the time for a couple

years. So I worked with Japanese designer to build this app and they bring a completely different perspective on design, as you can imagine. I'm sure. Very, very interesting experience. We built some, yeah, I mean, the, the, the templates, the style of the app and so on. Now it would look seriously dead because, you know, it's six, seven years old. Right.

It was a different aesthetic then. I mean. Yes. Yes. But on the original iPad, you've got to imagine like this big screen that's tactile. And for the first time, you have something that looks really, really pretty.

And Flipboard was launched roughly at the same time. Like I think it was just after or just before. And it was, you know, this idea of presenting content on tablets as magazine, which became quite popular afterwards. This app was part of the lag flipboard of really kicking the trend, I guess, or was at the right time at the right place to an extent. And so, yeah, I built a few, I mean, a couple iPad apps

and some other stuff for Claris, and then EverPix happened, yes. Well, cool. Let's pause there for just a minute. We're going to touch a bit on EverPix happened, yes. Well, cool. Let's pause there for just a minute. We're going to touch a bit on EverPix when we come back and dive deep into GitHub, the troublesomeness, I guess, of the user experience of using Git from the command line. But we'll be right back, so hang up.

I have yet to meet a single person who doesn't love digital ocean if you've tried digital ocean you know how awesome it is and here at the changelog everything we have runs on blazing fast ssd cloud servers from digital ocean and i want you to use the code changelog when you sign up today to get a free month. Run a server with 1 gig of RAM and 30 gigs of SSD drive space totally for free on DigitalOcean. Use the code changelog. Again, that code is changelog. Use that when you sign up for a new account. Head to digitalocean.com to sign up and tell them that changelog sent you.

All right, everybody, we're back once again. Pierre, it's been so much fun having this conversation with you. Obviously, we're here to talk about some of your deeper roots, Everpix being a recent company that you started based on an idea that you had while you were on vacation. And I'm glad you mentioned your stint in Japan because that sort of led you to some travel and whatnot. And that's where this idea came from when you were on this trip. But also I'd love to dive deep into GetUp and what's happening there. So let's talk a bit about Everpix.

I mean, what was this idea to you? What was it like? Was this your first company that you built? Or I guess kind of, but not really? It wasn't your first company? No, it was the second of but not really it wasn't your first no it was it was the second company yeah the very first one was that game company i think i mentioned a little bit earlier which lasted i think about three years back in 98 or so and yeah that was a completely different type of company different product by by far. Different time frame too. Yes, yes, absolutely. A whole different world. Yeah, and

completely. I mean, the other one, we did raise some money, but it was not, it was completely different. Everpix was a true startup as you would define it in the Silicon Valley, right? In terms of how it happened, in terms of how it was capitalized, in terms of what happened at, in terms of how it was capitalized, in terms of what happened at the end, in a way, all these sort of things. So Everpix, I guess the easiest way to open this one up is how did it come about? You were on a trip, you were taking photos, sharing photos.

What was the situation? Where did this idea come from? Well, you know, like a lot of people when they start projects, and I'm no exception, do it because they have a frustration. And Everpix started from that. And the frustration was very simple. We were traveling quite a bit while in Asia and I just wanted to have all my photos in one place on the cloud, obviously, and having a really good way to browse them and share them. And, you know, really basic, basic stuff. And I figured I tried all the service at the time,

that's back in 2011. So obviously the big ones like Flickr and two more esoteric ones, and they were not working, period. If you wanted to have your photo collection online and it would work magically, to use that overloaded term, then there was truly nothing. Everything was a massive pain. Everything had to be done by hand, one photo at a time,

like all these sort of things and um figured okay well in 2011 with the technology we have and the powerful computer we have we can do much much better than this and so first thing i wrote was really a efficient syncing system between iPhoto and i mean Aperture I was using iFoto at the time, and the cloud. And even things that little utilities that were attempting to do this at the time to send all your iFoto library to Flickr or things like that, they were far from doing it as efficiently

as the approach I had taken. For instance, I was doing some reverse engineering of the iFoto and Aperture databases to directly grab everything efficiently rather than requiring people to kind of export to the XML and all of this. And it was a lot more reliable and transparent. And so a simple problem that you solve, right? And what happened is I figured, OK, well, that's pretty cool. I want to keep going with that and then kevin connison who i knew from

my time at apple because he was on the course composite team um turned out to be um not only brilliant in terms of image analysis and software engineering and all of that but also be pretty interested in this problem and then i searched for a designer and i met um when fan who was at a turning point is carrying away and looking for a next opportunity. And so the three of us were pretty interested in this space and decided to iterate and start building something more advanced. And that's where, like when I said earlier, it's a typical, in a way, Silicon Valley startup is that then we applied to TechCrunch Disrupt, which is one of the big events to

big startup competitions right and um uh to our surprise in a way we got selected and um so they have hundreds and hundreds it's not a thousand i don't even remember startup supplying and they pick like 10 or 11 and um so hundreds and hundreds and they pick 10 or 11 yeah it's it's even more than that but that was why you were surprised not because because you were really awesome, but because there were so many. We were very early, and yes, there were so many, and we were kind of rushing to do the application,

in any case, it was selected, which definitely gave us a boost, and we comported the company and rushed before the event to make sure everything was aligned and transfer the IP and all of this and raised a little bit of money. And then from there, we were able to present it,

start getting attention, raise more money, iterate, learn a lot, and so on and so on. And to not dive too deep into the story, the startup lasted a couple of years and a half. And it's not a pivot, but we all gained a ton of understanding about the photo space from a consumer perspective. I would say a lot more than the competition at the time. And we realized that there was a lot more than just a syncing problem and having the same photos everywhere on all your devices. That was actually just a prerequisite to

tapping and addressing the real problem. And the real problem, as we discovered it, was what we later called the photo mess. And this idea that people have tens of thousands of photos now, at least 10,000, it's close to that. That was the matrix at the time. And, you know, suddenly they're all over the place among your computers and mobile phones, et cetera, et cetera. But it's not, it's, they're a mess because people don't organize them anymore and you can't blame them for that. You can't organize photos. There's too many photos out there. I mean, my iPhone has 16,000 photos on it. I don't organize those things. Right. And it's not, but so it is a mess. And if you say, well, sorry.

I like that term, by the way, photo mess. Yes. Well, it took a long time to figure out that term. We had to work with a pretty talented marketing slash positioning expert for that. And to really put, because to you as a founder, it's clear what you're trying to do, but you have to convey these concepts to not only the consumers, but the investors. And they have all sorts of patterns and bias and whatnot. So it's very important to position your product properly.

And in any case, a lot of startup, pretty much all startups, they were just looking at the surface and say, well, okay, it's a mess. We'll get that. Let's put everything together in one place. But now you have one mess instead of multiple messes and you haven't solved anything. And so the photo mess to us was more than that is it was the lost opportunity of having this incredibly valuable treasure of emotion that connects to you personally, because it's your photo life to a degree that nothing else can touch,

and not Facebook and your friend status and post and photo. No, it's your life. And having that scattered and out of reach on all these devices and whatnot and not connected to you anymore. And so the big thing that Airpix focused on is having a very, very advanced technological stack in terms of image compression, in terms of syncing, in terms of image analysis and semantic understanding of the content of photos and things that were really advanced at the time.

But that's all tech. And so what you do with that is that lets you have very efficiently the entire live photo collection of each user in the cloud. And that lets you understand what it is made of to a degree. Like these are photos of this, you know, these are photos of people, these are photos of trees, these are photos taken in cities, like all of that based on image analysis, not even metadata. So a lot more powerful and combined with insanely accurate deduplication algorithm so that you never see twice the same photo independently of recompression artifacts and color shifts due to color space changes between Facebook and the original photo and all of that. But what you do with that is you now have this unified live photo collection and you

can understand, you can understand it and you use that knowledge to surface the photos back to the user. And this is where the power and this is where it clicked for people. And this is why Everpix had such a high rate of subscription. Typical freemium products are happy when they get, you know, 3%, 4% of conversion. We had 12. So vastly out there. Three times.

And yeah, that's why the product definitely was a hit with a category of the market. And because suddenly you had all this photo life uh being connected i mean it's not exactly the best term because i'm technical but it's uh you are recreating these emotions when people see again their photos and you can only do that you present the right photos and you have the interlife photo collection etc etc so the technology stack you need to have underneath to achieve this simple result is is massive and. And it took us, you know, a year and a half to build everything, um, to the scale that it could handle what we were building because we had the live photo collection of each user. And that was unique at the time. Um, the average user had, you know, 10,000 photos. Like I said,

that is massive. So every pics when it, you know know shut down at the end had 400 million full resolution photos um we were having peaks um at at i think it was eight million photos a day like regularly things like that and to give you an idea like flickr was getting at the same time around four million photos a day according to their their own numbers so you know a small team of like six engineers was handling a huge amount of photos combined with state-of-the-art semantic analysis running on like, I think, 80, 100 servers. I mean, massive stuff to build that. And it did resonate very, very well with a category of the market. The trick thing, the tricky thing is that it is a highly,

highly competitive space where success is measured in millions of users. And especially, which you can only attend if you have virality. If you look at, if you think photo space, people are going to immediately say photo sharing, and they're going to immediately going to say Instagram and whatnot. And Aeropix was absolutely not a photo sharing. I mean, you could share photos by definition, but it was not a social photo sharing app system. It was very personal. So it's a different thing, but you get pulled in with the same, in the same bucket as a bunch of other startups. And so highly competitive, the bar is very high and so on. And it was very difficult for us to convince investors

that we were onto something that would go really really big because they would say well yeah all your metrics are incredibly impressive except one which is the total number of users and and while some little photo app might have like a million active users we had like 50 000 something uh registration and signups and all of this and And even if all the reviews were really, really good on the app store, like all over the place and people absolutely love the product and the press and we got a really high amount of price coverage as a matter of fact. And it was just not enough to alleviate the concern of large investors when you're at the Series A stage, where you

typically raise like at least 5 million. And we had raised by then like 2.5 million, but the money was gone. It was spent on payroll, on infrastructure and all of these things. And so Aeropix was kind of cut short and we would never know if it would have become something very, very big big or it would have kind of stalled at i don't know 100 000 users or something like that because it never really had a chance to really fly after it was built the product was i mean the company had to shut down about six months eight months at most after you know 1.0 was really released and uh and things were starting to pick to pick up if you you know, a lot of the data,

pretty much all the data related to the startup was released as open source data on GitHub. You can just look for Everpix Intelligence. That's the name of the repository. And it's all in there. Like every freaking data set reports, like it just, I had to redact a few little things for um obvious um reasons i think there is no data whatsoever from the users as you can

imagine uh but there is things like the raw feedback from all the famous investors and vcs in the valley except i don't give the names but it's all in there unedited all our metrics all the um um all all the data like a ton of data and um because nobody had done that before like to that extent like no startup not making it had had released all the data raw unedited for people to make their own opinion and look at it and so at the time in the startup world like when i did that i think it was very early 2013 um it was um yeah it was very very uh popular in the startup world and discussed because like i said it had not happened before to see suddenly inside um having such an inside view of all the data. And before there had been a very good and well-written article and pretty much unbiased on what happened with Everpix on the verge, which was actually the writers and journalists

were a fan of our product. And, you know, telling the story in a very interesting way, talking to the various actors, the VCs and all of that. And there was also an article that got very, very popular in the startup world because it was an insight looked at what exactly happens when a startup fails. Like how do you get there where you get so good reviews from your users and you raise that money and you get great investors and this and that. And then suddenly it's like, well, it's not going to work.

You know, we have to shut down in two months because we ran out of cash. And so that was, that was definitely a very interesting experience. The team was very happy with the product and all the insight we get on the photo space. And, you know, if you look at Google photo, for instance, today, it's, it is extremely close close to to whatever pics was at the time and of course they do a number of things better and we had a things we were doing better but um it is it is very very close a number of concepts you know the um dropbox um whatever our key feature was called flashbacks and dropbox a year later released a feature that is the same thing and called flashback uh after every picture down um We released what was called, same feature, right?

What was called, sorry, highlights. It took us some time to find the term and everything, this idea of using all our semantic analysis of the photos to provide a summary of your photo life and so that you can navigate very fast and then dive in. And it was all dynamic in the iOS app

and things flying around in a very intuitive way. And, you know, three months later, it was like Google Photo came up with what was called Highlight. And they defined it as finding the most representative photos, which was exactly the same thing. It was pretty funny.

And same definition, same word, three, four months later, whenever that was when they announced Google Photos. So we were definitely like... On the right track. Yeah, yeah. And a number of things, like we're the first one to recompress photos. And all the VCs were freaking out.

Like, you can't do that. People are not going to understand that. And because we are our own image compression technology that let us do 5x, close 4 to 5x settings in terms of space at the same quality perceptually, right, on screen. And so a photo that used to be 1 megabyte was now on average 200, sorry, kilobytes. And these are massive settings of storage.

I said the size again, you said 1 megabyte? You know, 4 to 5x settings. Okay. At full resolution, the full resolution one five you know four to five x settings okay at full resolution um the full resolution and and and uh you know complete color correctness everything and you had to really look at more than 100 to see the differences on the edges and so on because you know this is one of the other thing we did is said well photos are taken in jpeg jpeg is a very old technology based on you know fast for your transform and all these things and

goes back like dozens of years and we can do much much better today so we build everything on top of a variant of jpeg 2000 and wavelets and all custom conversion pipeline all these things and the results you know spoke for themselves we had the fastest thinking by a factor of four to five x compared to the competition and our storage cost were 4 to 5x lower. I mean, like I said, we have 400 million full-res photos. It's insane. And for a very reasonable storage cost. But at the time, people were very concerned about this. But the truth is, none of the users cared

because we weren't hiding it at all. We're saying, you know, we're optimizing the photos and so on. But suddenly they were able to have the entire photo life in the cloud which was not even possible before unless you were willing to wait an entire month for them to upload and google photos does exactly that today they optimize your photos they don't tell you how but by default with the free tier they cap to 16 megapixels and they optimize the photo which means recompressing and um so it's it's going to be the standard because it's not it's not really scalable otherwise in terms of storage cost and so on so we we suddenly did pioneer a number of uh of ideas

and as a matter of fact google photo released uh in a few days ago something the equivalent of flashback excel they call that uh photos to this day or i don't remember exactly how to phrase it but it's exactly what flashback was doing um withpix, you know, at Everpix. So we were definitely on the right track for a number of these things. And that doesn't mean it would necessarily have been a massive success on a thing like that because there were a ton of other factors.

But at least that's a good outcome that we did understand where things were going and had built the right insight as a team, right? And managed to execute on a lot of that. So that was a really good experience and people are very happy with the outcome, even though it's a bittersweet outcome for obvious reasons. It's clear to see that you're a pioneer. That's for sure.

I mean, I'd love, love, love to dive deeper into Everpix, but I do want to move on here in a minute to some other topics. But just to tap on that topic just a bit is, I feel like you've been a pioneer in so many different ways. And what I gathered, and hopefully the listeners may have gathered this too, on Twitter or if you're a member in member chat on Slack, chime into this as you're a member in member chat on Slack, chime into this. But as you're listening, but I'm thinking like there's a separation between technology and product. Right. Like from a technology standpoint, we're kicking some major butt.

And also on a product side, because you had 12 percent, whereas others had three percent subscription rate, you know, on the free tier. But there's a there's a a separation of advancement in technology, which clearly you're good at, and there's an advancement on product, which is what investors are actually investing in. They don't always see technology, and they're not always excited about technology. They're excited about product and sales and millions

and metrics and money and revenue. That's where the big money is. It's really on technology, only on technology. I mean, it does happen, of course, but it's often you have to package it into a product and to solve a problem someone has. Well, this is episode 172. For those listening out there, we do have a link to the Everpix Intelligence GitHub repo. Everpix, E-V-E-R-P-I-X is the GitHub user or the GitHub org.

So we'll have links to that. We'll have links to the Verge article that you've mentioned, Pierre. And we'll also link up, I kind of like even the sparse EverPix.com site. And I think it's kind of neat. I think this is a really graceful, beautiful way to fail, I guess. And not in a bad way, but hit an end of a road and leave the community, the consumers, whomever might come after it with a link to a very clear story from The Verge and also all this business data on GitHub. I think that's a really classy way to do it, and I commend you on that.

Let's go ahead and take this opportunity to give one more pause, hear from an awesome sponsor. When we come back, we're going to dive deep into the heart of this conversation, which is Git, UX, GitHub, this cool new tool that hopefully it seems like it's your future. We'll see what you say, but let's take a break. When we come back, we'll dive deep into that. So here we come back. Sentry is logging the way it should be.

A brand new sponsor here at the Change Log. We met these guys at GopherCon. Love what they're doing. They're dogfooding their own product, and they're doing some awesome stuff. Well, Sentry is a real-time error logging platform that gives you the insight you need into the errors that affect your customers. It surfaces your errors, helps you gauge severity and frequency, and then gives you the information you need to get them fixed.

It works on nearly every platform, including JavaScript, Ruby, iOS, Go, Python, and many more. And the best part is Sentry is open source. You can install and host it yourself, or you can make your life easier and start a hosted plan at GetSentry.com. Once again, that's GetSentry.com. All right, we're still here with Pierre. Pierre, I feel like I can call you a brother, man.

I feel like I've learned every bit of history I could from you, and I thank you so much for this deep dive into your history. I mean, everything from you as a toddler next to an Apple computer all the way to your history through Apple, being there when Steve Jobs announced the iPhone and the SDK that all the engineers were surprised by, on through to creating a startup and sadly failing at it, but in a graceful way. Now what you're doing, what are you doing now? I'm assuming what you're doing doing, what are you doing now? I'm assuming what you're doing, but what are you doing now? Yeah, so after Everpix,

I worked for a car actually startup. So yet another, still related to software, of course, but a different space within software called Automatic, which is building extremely interesting devices that you plug in your car and the whole platform behind it

to get the metrics and the real-time data and do analysis on that and help you become a better driver and so on. So that's a big deal because cars are not connected to the cloud as of today, or barely. And so these are computers on wheels that are not tapped into internet.

And there's so many things you can do there. And so that startup is tackling that big space problem, big opportunity problem. And so I worked there for some time, helped them with engineering, this sort of things, product and all of this. And then for personal reasons I quit because, like I was saying, on a personal level we were going to have our first child and I wanted to take a bit of time off before

that with my wife, travel a little more, like this sort of things, and then be having certain peace of mind when she was born, etc. But that said, I have a problem in the sense that it's very difficult for me to stay idle. And so I always poke around with things and look at projects and this and that. And one thing that did puzzle me for some time, both as an engineer and as a manager, is Git, which is fascinating because it is the standard obviously to do today to do uh version control systems and it has won the war for the time being until something better comes which is probably going to be five ten years away at least and um so it's it's pervasive but it's it's tough for a lot of engineers.

They really have problems with Git. Engineers who might be junior or engineers who might be very senior and they get stuck on these things because the way you interact with Git is very puzzling to say the least. You want to do a certain operation. It's one command. You want to do the exact same operation but with a slightly different variation it's complete a completely different command or

things are not symmetrical or it's it's weird it's really strange and so you have to build muscle memory and it takes some time and if you don't use git for you know a few months or whatever you might forget how do i do again this this specific I want to achieve? And then you don't remember. And so to me, Git is kind of the Stack Overflow version control system. Because what people do in practice is, apart from doing a commit and pushing and maybe fetching, every time they want to do something a tiny bit more advanced, you go to Stack Overflow, you enter your query, and so on. And so that's a fact. Among the five, Stack Overflow is obviously the one place where

programmers exchange knowledge in the entire world by far. And so it is very representative, in my opinion, of the state of things. And so among the five most voted questions of all time on Stack Overflow, three are good questions. Four basic stuff, like how do I edit the commit of things and so among the five most voted question of all time on stack overflow three are git questions for basic stuff like how do i edit the commit message how do i undo a commit or this sort of things really really basic and i think it's clear by this time the people behind git truly owning it right the git project um are not going to tackle this. They add, when you type a command and it's not very clear what it does, or it's a bit confusing, they add various prompts and guides and help to tell you, maybe you mean this, or if you want to cancel this operation, you just did enter this command,

but they're not going to touch the way it works and rename the commands, for example, and do a clean pass and make it a lot more consistent in terms of what the verbs are and how they work and the options and all of these things. And McRule is a lot more consistent in that aspect, for instance. And so I understand if you were to do something like that, not only do you need the right people to build a new type of command line interface, but you need to deal with breaking, in a way, the compatibility with everything else. And so I certainly don't throw a stone at them for not tackling a challenge like that.

But the fact remains that this is far from an ideal situation, and there is a lot of wasted time, from my observation, with Git. And that results in lost productivity for engineers. And that results in frustration. And that results in having typically in the team, you know, one person who's very good at Git and everyone's going to go bother that person every time there's a problem, which is often.

And so to me, this is frustrating. And I was thinking we should do something better in the way to interact with git and so um i figured you know the way what's very interesting with with git is that the the the way people tackle a problem when they're stuck in the repository is they ask that person who knows git on the team and that person is very often going to go on a whiteboard and draw the thing the state of thing with the branches and say you are here and you're trying to do this so you need to do this operation we're going to do that and then that other operation and so on and

you see what i mean and and then the person go you know do it applying the commands and it works like okay that's cool and then the next day the you know, do it, applying the commands and it works like, okay, that's cool. And then the next day, the same thing happens and cannot possibly remember anyway because the commands are so esoteric. So back to square one. But the point is, it's about a visual representation. And so, of course, every Git client comes with,

you know, little branches on the side next to the list of commit that shows you roughly what's happening and so on. And, but that's not the same. So my idea was, okay, instead of manipulating commits per se, let's manipulate a graph. So you see the graph of the repository, which is its topology, right? And how the commits are related and the branches and all of that. And if I want to delete a commit commit i select the commit and i hit delete and it works if i want to edit the commit message i click on the commit and i somehow trigger an edit option and edit the commit message and it works

um if i want to do rebase i can see visually what's happening if i want to do merge i understand it you know this sort of things and it's a lot more intuitive because you see the branches. You see what is happening before and after and so on. And so I figured, well, that would probably work. I guess that would work. I should try to build that thing. And it should make it a lot easier because a number of times on my own personal project, I ended up in a frustrating situation where I know exactly what I want to do with Git in terms of merging this there and rebasing and whatnot.

And I have to then decompose the result into all these command line operations where it would be so easy to just have the graph, click on the commit in question and do that thing. Yeah, so much of Git's magic and beauty is hidden behind a, I don't want to say just complicated, but in some ways just very mysterious way of doing things from the command line. It is. And I want to be very clear on one thing,

which is the Git architecture and design is extremely elegant. It's very simple and extremely elegant. The way the references work, the way the comit are done, the trees, all of that, the database format, like it's designed to be, it's one of these technologies

where the beauty is it's in simplicity and that's why it's really successful and pervasive, despite, you know, the terrible command line interface. And then the existing Mac apps can come on, well, actually Windows apps

pretty much the same state of things, but the existing guy clients, what they do is they take the command line interface and they just wrap it anyway, which means you take the clunkiness of the command line interface and then you wrap it into a bunch of dialogues and you expose every possible option and you put some nice polish on top of this and make it look clean. But that's really lipstick on a pig to be brutal. It's not solving anything, you know? And you're just compounding problems. Now, not only do you have the clean efficiency

because of the way it's designed, and then you have all these dialogues and checkboxes and things. And sometimes you look at these clients and they ask you a question. Do you want to enable this option when you do this operation? And you don't even understand what the heck this means

because it's not using Git proper terms and it's not clear either. I mean, so to me, it was just not solved. And so that's why I started working on building this concept, this proof of concept, if you wish. And there is a really really really good open source project called libgit2 and it's a c implementation of core git because git itself is not designed as

a library you can embed it's a bunch of it's a bit of c code and a bunch of shell script on top of that and it's not really designed to be to be used by you know all apps embedding it. And so Libgit2 is a C API and everything is very clean, doesn't do everything, but it does a number of things pretty well and provides a great foundation to build on top of that. And so GitHub is built entirely on top of a subset, actually, of Libgit2, where I just use Libgit2 for, say, commit parsing and the merge engine and the diff engine and this sort of things. But everything else is rebuilt on top of that subset, which gives me a much better, I would say,

consistency in the way things work. Because libgit2 is an open source project that's been going on for a few years. So it's not truly specced, if you see what I mean. So you have some parts that work a certain way, some other parts that work slightly differently, and some things that should really be subclasses of other things from a hierarchy perspective actually not, and so on and so on.

It has a few esoteric things and some little HK bugs, etc., etc. So you really need an abstraction layer, in my opinion. And so that, you know, the GitHubithub kit in a way that's what i called it um is is this it takes a subset that's very solid of libgit2 and then rebuild everything on top of it in terms of git functionality from from checkout to uh to to merging branches and all of that on top of this subset and then add a bunch of layers to do unique features like unlimited under redo, which no other Git client has to, you know, snapshots with like time machine for a Git repo, which is very, very cool and lifesaving.

And other features like speeding commits just without touching any file on this, just select a commit. You can split the commit and the lines between these files in a completely fluid way and then just commit the result and that's done. Or unified reflog and a bunch of things

that become suddenly buildable because you have the right foundation there and you're not limited by the binary Git tool that you're trying to wrap. You just deal with the Git database directly and a number of gazillion things. Yeah, that's a big deal there.

Yeah, I mean, it sounds simple when you describe it like that. The database directly is a big deal, I think. Yeah, and so it doesn't try to call the command line. It doesn't, I mean, Git works even if you don't have Git installed at all. It doesn't use Git, it doesn't touch it, it doesn't mess to call the command line. It doesn't, I mean, GitUp works even if you don't have Git installed at all. It doesn't use Git, it doesn't touch it, it doesn't mess with your config settings. It doesn't, it's a very, very safe app.

And now that it's entirely open source, you can see how it's done. So you can have even more trust in a way. And so GitUp was a bet in terms of saying, what if you write a Git client that is dealing directly with the database, not adding the overhead of going to the Git command line interface

and the clunkiness, and has an interface that lets you manipulate directly the topology of the repository, right? Would that make it a lot easier to do all these common operations and people understanding what is happening? And of course, you know, the whole thing has unlimited undo redo, like I said, would that make it a lot easier to do all these common operations and people understanding what is happening? And of course, you know, the whole thing as unlimited undo redo, like I said, and it's

built modern, right? And it's completely live. So you can work in a common line tool alongside a get up and then your changes. So show in the graph within like one second latency. You can use them. You can use the two in parallel. And in fact, you can sort of like, yeah,... Yeah, so that's a very important point that you raise, which I would consider myself a Git power user.

And the last thing I would want is, you know, a PlaySchool type of app. It is not what it's about. It's a tool done for professional Git users that is as fast, if not faster, than the command line. If you do rebase in GitHub, it's actually very if not faster than the command line if you do rebates in github it's actually very often quite faster than the command line and um and um faster than the command line very reliable and it just gets out of the way at the same time and it doesn't

forces you to adopt the whole thing it's not a full buying experience so you can use github purely as a viewer of your graph so you can use GitHub purely as a viewer of your graph. So if you use the command line all the time, you open the window next to your terminal, you can see what's happening in real time in your repo, you do your operations, and you can verify at a glance that you're doing it right. And if you did it wrong, go to GitHub and roll back to the previous step just by using a snapshot. The whole thing is, you know, it's very friendly. You can use it as little as you want to as much as you want. And I also spent a lot of time on building the, designing the commit view for GitHub. And I really wanted a commit view that was faster than the command line.

And so I spent a lot of time figuring out a good layout, taking abuse inspiration from existing clients and whatnot but also making it very fluid in terms of it's completely keyboard driven so you can very fast select lines and press return and stage them and then option returns commit the whole thing and it sounds simple like that but it's it's really fast um in terms of of workflow and if you look at the at the feedback on twitter i guess that's the primary channel for that but git up it's uh it's been really really positive because a number of people realize oh it's really fast and it gets out of the way and that's pretty neat and it gives them a little

more comfort the fact they can see all these things visually and of course it's not a tool that should do every possible thing in git but it should cover the vast majority of of usage scenarios and uh and let you switch to it if you want to or as like i said earlier as much as you want which is pretty neat you can or even also a little more complex operations where you're like man i gotta google that again going back to yeah like you don't have to worry about that or something if exactly you want to edit a commit message you select the commit you type e edit the message return you don't have to worry about that. Exactly. You want to edit a commit message, you select the commit, you type E, edit the message, return, you're done. I mean, it's like, it beats everything else.

Like it's so faster than the command line. There's nothing. And so that's very different. Like I said, it was a bet in terms of user interface, in tech to an extent, how it was built. So I realized it, I think, publicly slowly at the beginning of the year, if I'm not mistaken. It took quite a lot of time to write. There was a lot of code. GitHub, if you look at the source code, is about 30,000 lines of code, first-party

code, which means, you know, I mean, I'm not counting third-party libraries and any of this. It's just code written for the app exclusively. It's significant. There's a ton of things to write in terms of foundation layer and technology stack and all of that stuff to manipulate the commits and build the undo-reduce system properly and atomic transform of the repository references and whatnot. So a lot of experiment back and forth, a lot of time making the graph very fast.

It is. GitHub is not designed. That's one of the things where it has clear limitations. If you try to use GitUp on a massive repo, which means repo with like hundreds of thousands of commits and dozens of thousands of branches and 80,000 files or whatever per tree, it will be slow. It is absolutely not designed for that um i designed the app for um for the typical repo and uh with a usual like an order of magnitude margin which is usually how i do technologies meaning if people uh have like in the case of aeropix the average photo collection is 10 000 okay we're going to design a technology and our stack to handle 100,000. And that gives us plenty of margin and we're fine. And so, yes, and someone who comes in and has a million photos

is not going to work that well. Although at Everpix, we did have someone with 700,000 photos and it worked fine in a few extreme cases like that. But still, so the vast majority, yeah, yeah, it's fine. So, you know, a basic rule there, we learned actually, discovered in a way, but obviously not the first ones at Worldbuilding Everpix was you just look at the distribution and you take, you say, I'm going to shoot for the 75th percentile of repos is definitely around a few thousand commits, less than 10,000 for sure. And so by far.

And so you build an app that can handle 100,000 commits, which is what GitHub is. And the 75th percentile of branches is going to be maybe 100 at most. I don't remember the exact number at the top of my head, but it's not like thousands. And so again, if you have a repo, uh, with a few thousand branches, they're going to start getting slow at a few places and, and so on and so on. So it was designed to be really,

really, really fast for the 75th percentile of repos, which is the vast majority of them. And, um, and, and, um, that was released early this year. Um, I think it got to the top on Hacker News and then was featured by Product Hunt and things like that when it got a little bit more mature. People were intrigued by it and so on because it was definitely a departure. And a certain category of people, it's a bit tricky to measure the adoption.

I have a rough idea of the number of downloads. Last time I checked, around 50,000, 50, 80. I mean, it's more than 50,000, but I don't know exactly because it's with caching and CDN and all of that. I only have like a baseline. But it's not a million, right? And yeah, it has definitely thousands of active users for sure at the bare minimum, and very good

feedback on Twitter that resonated to a certain category of Git users, for sure. I don't know where the project's going to go in terms of adoption. You know, is that going to be a big thing? Is that going to kind of find its sweet spot and remain at a user base of dozens of thousands or something like that and or go bigger it's it's very very difficult to say um but we'll see you know it's uh i'm pretty happy with where it's at um i got help um in terms of design and some of the user interface um with uh when fan who was my co-founder at everpix and designer um and i also work with jason eberly who was my um who was our web engineer at the time with everpix and he helped

with some of the website and all of that so it was a bit of a collaborative process but not as much as something like everpix of all the projects that work on because it was still a very personal project when i've done the vast majority of the coding and stuff. As like I said, first of all, as an experiment, but also really a tool that I wanted to have for myself, a way of dealing with Git repositories. On a side note of mentioning Jason, it's kind of funny because we don't do the reads for our sponsors live when we actually do this show recorded with you but

imagix was actually a sponsor of the show and jason works at imagix and absolutely was a contributor to the imagix.js library which helps uh those repositories you know that that's a library there to work with the imagix api to allow your app or site to work with the Imgix API and deal with responsiveness on your app or your site. Yeah, absolutely. Kind of interesting. Yeah, well, you know, that's one of the things you have in the Silicon Valley as a whole

is it is a small world. It sounds like cliche when you say that and you don't necessarily believe it when you arrive because it takes a long time to build connections unless you're at the right time at the right place. That's totally by happenstance too that Jason was part of this. And when I was doing my research, I'm like, ah, that's cool. Jason was a part of this. Yeah.

And I meet people, you know, and it's always, you end up meeting people you met years back again under completely different circumstances. And you realize people are, you know, there is this mathematical proof that people are only six degrees away or seven, I don't remember. But Silicon Valley, I'm suspecting it's like two, because you always end up talking to people who are one degree away from people you know and this sort of thing. There's really an ecosystem there. It's fascinating. And Pierre, that's exactly why I thought it would be interesting to like this show is probably a little bit different than our normal shows, but

just dive deep into our guest past because I think it paints a really unique position to get up and what you're doing with it because of your history in software development. Like everything from all the history painted during this show to to now that this is your interest you know so given the success that you've had in the past given the bets as you said on technology um i feel like it was really important to sort of dig deep into your past to really get an idea of how serious to take GitHub. Because, sure, there's Git tools out there that promise things like the Git interface you've been missing all your life has finally arrived. That's what you say for GitHub.

And a lot of people could promise that, but you've got the history to say that you can truly make that statement for GitHub. And the fact that you've got, let me go back to my notes here, the GitHub kit piece that sits on top of this that interacts directly with the Git database. I think that you're taking some really unique approaches towards solving this problem.

And maybe you're not far enough now. So for the listeners out there thinking, ah, this is a pretty, a good UI. I love how it works. They could use some work. thinking, ah, this is a pretty, you know, a good UI. I love how it works. They could use some work. Well, you just started in November, you know, so it's not like you've been doing this for a very, very long time. Yes. It's a, it's a very young product. I mean, absolutely. And, uh, but it, it has the, it implements the concept I had in mind to a truthful degree, um, in terms of user of user experience and how it's built.

And yes, it's not, you know, this is in terms of complexity, in terms of engineering and whatnot, this is like one, two orders of magnitude smaller than something like Everpix, of course, and or Quartz Composer and whatnot. But, you know, it's through the years, obviously, like in any trade, you learn and you learn how to do things better and more efficiently and so on. So GitHub is, yes, I apply a lot of years of learning in terms of software development and all of this.

So it is much better code and architecture than what I would have done, you know, 10 years ago, etc. So some of that hopefully does reflect in the way it works and the way it's built. And, but it is, yeah, it is hopefully going to help. That's also what I figured, you know, open source is probably the best for that. I was debating for some time, is that a product you can build a sustainable business around it and so on and there are some examples so it is doable but what's going to be the scale of it and so on and it's something where I did it you know selfishly for me obviously first because I wanted to have something

I would qualify better at least for my pattern of work my workflow with git and then figure out well okay it helps other people, interests other people. Can you make a business out of that? How many people is that going to be? And then you weight that against the amount of work that's needed and support and all these other things that come along and opportunity cost, et cetera. And I figured, you know, I like the product how it is.

I'm going to keep working on it, but I want to do that in my spare time without pressure because I'm pretty happy with it. So open source is probably the best because it's an active open source project. It gives a degree of confidence to people that they can use the app because it is open source and you check it out and you build it and you run it on your own. So it's not going to go away and disappear. And you can judge yourself how well it's not going to go away and disappear. And you can judge yourself how well it's built or not according to your opinion, and you can customize it and all

of that to a reasonable degree. And for free, it comes with this thing that I called very innovatively, you could say, a GitHub kit to rapidly find a name, right? Which is just all the pieces to make your own GitHub. And if you look at the repository, there are a couple of examples in there that show in a few lines of code, really like 20, less than 100 lines of code. So how to build like two little Git clients that leverages all the power of the pieces that GitHub has in terms of undo, redo, in terms of it has its own diff rendering engine based on Cortex for speed.

Like a lot of work went into performance. The diff rendering is very fast because it's directly on top of Cortex, for instance. And that makes a difference when you deal with reasonably large diff and you scroll through them. Like all these sort of things it's quite faster than alternative

Git clients in a number of places and because to me that was you know it's always satisfying of course to make things go faster but it was also required because you want the tool to get out of the way you don't want to have to wait for it and I'll give you an example there

well yes but I go far with And I'll give you an example there. Well, yes, but I go far with that. I'll give you an example. There are a number of dialogues, right? Model dialogues in GitOps. Like if you say, I want to create a branch, it needs to prompt you for a branch name. Now, every possible Mac app is going to show you a dialogue where you enter that branch name

or so that it looks proper in terms of ux you know um a sheet that falls down of the top of the window right the title bar these sheets take i the animation is like half a second to say whatever by the time the thing is actually on screen you can start typing it's not too far from a second and so to me this is this is friction that brings nothing and then you need to wait another half a second or so for the sheet to just close. And so if you look at GitHub, the model dialogues are actually completely custom.

So they're in line in a way. So if you type B to create a branch or E to edit a commit, you have an inline view in the map that appears instantaneously without any animation and you type directly there and you hit return and you don't so it's in and out extremely fast uh to me that was that's a small thing but it's it's representative of uh the philosophy in terms of user interface behind github it's like get you want it to get out of the way really it's like

go do your operation spend and immediately get it you get it wrong you can undo you can redo and then go back to your code this is where you should be spending time right creating things building things not fighting it um which is which is the case for an unfortunate number of of engineers um and so um of course some very advanced people do not need anything like this or, uh, do not, won't see the point or some other people, uh, would prefer a very polished interface. Like GitHub is still a pretty rough interface because I did not put time into, um, it's

clean, but it's not polished in the sense that it doesn't have like nice, um, uh, very polished icons and, and, um, um, you know, pixel perfect things all over the place. It's pretty much flat plain colors and so on because I put function over form there. And there's definitely room to do a pass to make it up to par with what you would expect from a modern Mac app in terms of polish in the UI layer. But that cannot come at the expense of the UX, which is the speed and the intuitiveness.

So yeah, there is room for things there. And some people might definitely prefer something that's more polished, even if it's slower, because it makes them feel more comfortable or more Mac-like app and so on. So it's not for everyone. I would certainly not pretend that. But it has found its market fit so far for certain user base.

And so we'll see where that goes from here. So it's open source. And I guess anybody who may fork it and contribute back needs to know that it's GPL version 3. So anything you contribute, for one, it's being used by a lot of people, which is a notice you give in the readme. It's being used by a lot of people, so keep in mind that any contribution you make can't be breaking.

And then also any work you contribute is GPL version 3. I think it was kind of interesting for us because we run a email that we ship out nightly so every single night we are shipping out top star repositories and basically the um you know the things that are happening on github um jared says on steroids i said on crack uh the last episode accidentally but you know get a change log nightly is essentially what's happening on GitHub every single night. Top star repositories and GitHub has been on the top star repositories for us on the charts since August 19th. That's the first time I noticed it. So that was that was what hit our radar.

And I say that because there's so many people that listen to this podcast and there's so many people that might hear us week to week talk about ChangeLog Weekly or ChangeLog Nightly being our open source radar. And in fact, that's where this show came from. And that's where everything you just heard this last hour of me and you talking came from us monitoring our own emails, you know, so change all nightly was every bit our open source radar when it came to finding GitHub, finding you, diving deep into your history. And I think it's interesting also that just your history and what you've done for software so far and the fact that Git is your next focus, I'm kind of encouraged by it because I'm expecting big things from GitUp. I think it's interesting that you also have the GitUpKit framework where anybody out there listening could go and build their very own Git UI on top of this. Now, I didn't see that the GitUpKit had its own repo.

Is there a plan to break that off into its own repo anytime soon? Not at this point. I mean, I'm always worried of moving things around for the sake of moving them around or splitting things and whatnot. It's not at this point. I mean, if it becomes like ridiculously popular or something like that, it might make sense. But today, I mean, there would not really be any benefit except now you have two repos, you have to look for things in two places, and you have dependencies and submodules or subtrees and all of this. It's like, there's no real benefit, honestly.

But the, yeah, the GitHub kit is kind of a fun thing. It's like, well, guess what? You don't like how the commit view is structuring in GitHub? Well, you can build your own. And it's not rhetorical, you know. You know, it's often like that with open source projects where people say, well, you can build your own. And it's not rhetorical. It's often like that with open source projects where people say, well, you can always go and modify it. Yes, but sometimes it's pretty hard to get in.

And GitHub Git is designed as a multi-layer thing where you have some very low-level components and then you have medium-level components built on the lower-level ones, and then you have high-level components. So you can just use the component at the level you want. If all you want is a div view that display, or a stash view that display all the stashes,

and it's all live and everything, just want to put that in some UI for your Git repo, it is literally a few lines of code because it's just UI, I mean, GI stash view controller, and just instantiate that, add it to your window, add the view to your window, and you're done. And it's all live and it works and everything. But if you want to dive way lower and

say, I want to, you just use the diff rendering component. Well, there's a view called GI raw diff view, and that's the lowest level thing. It just renders the diff within a view. And then you view, and that's the lowest level thing. It just renders the div within a view. And then you have to put it in your own scroll view to scroll and all of these things.

And so that's a very flexible approach where you can just rearrange some high level views or dive as low as you want. And so the two examples that come in the repository in the examples folder show some of that. They use different levels of GitHub kit to demonstrate mini apps you can build with. And GitHub kit actually has some directory inside of GitHub. So it's easy to sort of dive deep into that code if you want to. It's not's not hidden it's easy to find you know the only question i have i guess turning uh towards the close of the show um and this is you know not prompted from the feedback i got from you on this show but but beforehand so some some assumptions come from this question um and that question is will this and this being

get up will this turn into a paid product or will it remain free? Will it remain open source? What is the stage? What is the plan for this? It will remain open source. I cannot imagine a reason why it would change. I have a number of projects that are open source. And to me, it's a philosophical commitment

when you do that. I've never turned an open source project into a closed source one. I have never turned an open-source project into a closed-source one. I have open-source projects that are actually paid. I mean, sorry, that are sold or have in-app purchase, like Comic Flow is one, and it's entirely open-source. So if you don't want to pay for it, you can always download it and build it yourself,

as well as a couple of Mac apps on the Mac App Store and so on. These two are not, however, incompatible. But today, I don't see, um, a reason to monetize get up right now, or, uh, you know, in a way that, that would be, um, not be artificial. Um, the comic flow was, uh, not, that's quite popular on iPad to read comics and exists. Like I mentioned, it has been existing for a few years, was free for a long time because I built it for myself. And I figured, well, maybe it's going to help some people.

And that's it. At some point, however, it gained quite a bit of traction and I rewrote a big section of it. All the web server stuff, which was a core component of the app so that you can connect to your iPad, running a web server, and upload files, and it has WebDAV and an interface, so you can do it from your browser as well if you don't want to use WebDAV client. It was a significant piece of work, and that became a separate project.

It was called GCD Web Server, which is probably now the most popular web server for iOS and Mac apps, and it's open source and it's BSD or something equivalent, so not even GPL. It's all good. But I figured, you know, that's a lot of work, so I'm going to make that in-app purchase. And I think it's $3 or $4, I don't recall.

But it was a much better web server than before. And the entire app is completely usable without buying the same. You just copy the comics using iTunes directly or through Dropbox or something like that. So it's not crippled where, and it's just a little enhancement that makes your life a bit easier.

And then it's an in-app purchase. So maybe something like that will happen one day for GitHub. But there's nothing like this on the roadmap whatsoever at this point. All right. Well, we're definitely coming to the close of the show. We have a couple of questions. I'm only going to ask one. I know I gave you four different options, but we're going to ask one.

I think this one is going to resonate a lot with the listeners, which is if they've listened to your thoughts on everything through your history on now to get up and to get up kit and what you're doing with that. What is what we call a call to arms? What is if you have the ear, the listenership of the entire open source world right now, and you wanted to say, hey, this is what I'm working on. If you're interested in this, here's how you can contribute. What would that be for GitHub? I think it would be, come explore and try out an experiment to change the way people interact with Git.

And see if it fits for you. And make it become Bing by continuing to iterate on the initial concept. And I think it would be like this, really. To me, it's still an experiment in a way. I mean, if it were to reach a large user base, then the experiment is validated. It is validated right now to an extent because it has a user base,

but it's not validated at scale. And yeah, so that's why I define it still as an experiment because there's nothing else like this. It's a completely unique way of interacting with your Git repo. There is no client that does this from the way it's built to the way it actually is used. I can remember talking to, I can't remember, it was Tim Caswell, I believe, and if you go back in our archive,

I'm going to find, I can't recall it right now, but I'm just going to talk about it quickly. There's an episode. It was the most recent episode because we've had Tim on the show a couple times where he was talking about a Chromebook app that he was building that worked with building basically a better IDE for Git and software development, a better code editor, basically. And it was editing the Git database directly. And the conversation we had reminded me a lot of Tim Caswell's work. So I wouldn't doubt that Tim's done some things

or is doing some things or has some interest in what you're doing. So it'd be kind of interesting to see if you guys end up collaborating somehow. Big fan of Tim and his work. But yeah, man, I mean, it was such a great time to have you on this show to just dive deep into your history.

Yeah, it was a pleasure. Thank you. What you're working on is very, very interesting. So for those listening, GitHub is also a repo, but it's also a web address. So if you go to get G I T up.co, you'll, uh, you'll find a website with a 90 second video that encourages you to try get up for free. This is open source.

It's free. Uh, this 90 second screencast kind of goes through some three core features of get up that, that everybody really uh has questions on which is editing incorrect commit messages who doesn't do that like you said it's the number two stack overflow question of all time undo redo i wish every single day i had undo and redo on git and also snapshots and then also articulating perfect commits because the ui is uncluttered you're able to highlight certain lines of code you like to commit and stage and it's really really interesting so if you're

if you're out there you're listening to this go to get up.co there's a nice little map there and then down at the very very bottom of the page there is a button that says download latest release and uh maybe you can speak quickly to this which is this right now and obviously you're a mac developer you've been you've said this the whole show not a windows developer any plans to make this available for those windows folks or linux folks or anybody else besides those who are blessed to use an apple product um i not personal plans um but obviously you know the concepts are not rocket science. Right.

And so if they catch on and get good traction on the Mac, then I can certainly imagine there's going to be some iteration on the ideas on other platforms. GitHub itself is not in practice portable. It's like I was saying earlier, there's about 30,000 lines of Objective-C code, except the lower level, highly tied to the way the Mac UI works and core graphics and all these things, so the rendering and Cortex and a bunch of things. So it's one of these things where it would probably take as much to rewrite it from scratch than just trying to port it.

And so it's not going to happen on Windows, unfortunately. It was not intended to be built as a cross-platform app using a toolkit like QtKit or this sort of things. It would not have made GitHub possible as a matter of fact, I think, because it's a really performance-sensitive app when you use it. And, you know, all these little things matter. And so you really have to sit on top of the native, on top of the metal, right? The lowest, the low-level graphic API to, you know, if you draw a graph with 10 branches and 100 commits, it doesn't matter what technology you use.

It's always going to be fast. But if you wanted to handle a graph like, I don't know, the Git repo, 40,000 commits and so on, and everything loaded in memory and rendered, and 60 frames per second when you scroll in all possible directions, all of this, it starts to matter. Unless you want the Git Hub to be only usable if you have a tower with an octa-core GPU or these sort of things. So, unfortunately, no.

No plan for a Windows version of GitHub as is. Okay, well, I figured that that might be the exact answer you'd give, but I had to ask, of course. And given that this is an experiment, and this is still, like you said, an experimental stage, it makes sense to have that answer. But, Pierre, I know this has been a long time to sit here and grill you on your history and get up and all this wealth of software knowledge you share with the world.

I thank you. The audience thanks you. The sponsors of this show thank you. Those sponsors are CodeShip. I mentioned earlier Imagix, a new sponsor of ours. DigitalOcean and another new sponsor of ours, Century. Definitely thank you for your time to sit here and chat with us.

For those out there listening, you can subscribe to this show at changelog.com. We're on iTunes. We're syndicated through 5x5. We have an awesome weekly email called Changelog Weekly and another email called Changelog Weekly and another email called ChangeLog Nightly. You can get both of those respectively at changelog.com slash weekly

or slash nightly. Subscribe to those emails if you want to keep on the open source radar as we do. But Pierre, is there any closing thoughts you want to share before we tail off to close the show? I think I ran out of things to say at this point. You've been very thorough in your questions and everything. Well, thank you very much for having me. It was a great experience. It was my first

audio podcast as an interviewee and so it was really a pleasure. Thank you. No problem at all. Well, we do have a ton of links for show notes. So if you want to learn more about Pete, uh, Pierre, his work, his past episode one, seven, two, go to changelog.com slash one, seven, two. We publish all the links, all of our notes there.

So don't feel like you have to pull over a wreck if you're driving or whatever to get the links. They're all on the web for you or right there in your podcast client. But check that out. Thank you so much, Pierre, for joining us. And at this time, let's go ahead and call it an end and say goodbye. So goodbye. Goodbye. you