GitUp and the UX 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 join this call to talk about Git and his new open source project, GitUp. But we had to go so deep into 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, we start talking deeply about Git, GitUp, and Git UX, and why you might love, hate Git.

We'll see. Well, we have four awesome sponsors, CodeShip, ImageX, DigitalOcean, and Sentry. Sentry is a new sponsor for us. Love those guys.

Thank you so much for supporting the show. Our first sponsor is CodeShip. CodeShip 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, TheChangeLogPodcast. Again, that code is TheChangeLogPodcast. 20% off any plan you choose for three months.

Head to codeship.com slash TheChangeLog 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 on to 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. 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've 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'll 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 my accent.

And I've been doing software development, 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 drivers, like those 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 if it's for free.

So I'm not counting little safe projects done on the side, those 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 years 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 of 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? I do. So one important 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 those sort of things. And the logical evolution at the time was starting to do things with a 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 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, 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 learned a bit of Pascal.

And then I started creating things. And then I started creating software-based 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.

Although at the time, that was slightly before internet when my first software was distributed commercially. It was just borderline when internet was starting to be mainstream and to an extent. And it was still a time where you had to put your shareware 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 sort 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 commercially, well, not a professional software distributed by an official publisher in stores and those sort of things like Photoshop, for instance. But if you were doing sharewares and you wanted 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 conditions. 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 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 a Japanese magazine, a Mac magazine, you know, I was in France coming all the way from Japan because they had put your app on the CD that came with their magazine, which is, but it might have been two, three months later, 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 this, you know, like, let's say a slow paced world as a software developer, just kind of butting up back then. That's been, you know, 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 the desktop and apps are self-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 quality of your software and 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're 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 an example, ComicFlow, 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 One of the few ones that did not have the 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, you know, what was the state of it?

And in 2009, based on Wikipedia, because 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, you know, 10 million monthly connections is for a population of 17 million people, close to that now, which is probably around 25, 30 million households, is extremely 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 time frame when the internet began for you, 95, 97, somewhere in that time frame 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 it?

What was the app? I'm not sure I recall. This is a while back, right? We're touching 20 years ago.

Right. We're definitely tapping into the deep brain here. Yeah, yeah, yeah, yeah. 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 as tiling 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. It wouldn't have been enough memory to necessarily store the entire photo, for instance, filling the entire screen. Or if it would have been possible, then it would have used too much memory anyway to leave enough available for the other apps and these sort of things. 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 value CDs and all of that. That's interesting too, coming back to the CDs aspect you mentioned. Being in France, getting a magazine from Japan or something like that and it having your software on it.

And how did they deliver it? What was, well, I guess what was interesting about that? Was it like, was it like having a book published? Was it like the momentous moment?

To an extent, I think it's a fine analogy. It's 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 SCP server or a mirror of it somewhere in the US on the MIT when you're in France. And then crossing your fingers and putting a little text file with it describing the app, describing the some sort of license, something like that, just to say, you know, what were the conditions under which you allowed to do 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.

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 the CDs or before the CDs, because it needs to go further than that. They were coming with little floppy disks, right? You mean not, 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. It's like you get your magazine once a month and then what apps am I going to get with it? And type of freeware and shareware and all of this.

And they have to be very small because they have to fit on 1.5 megabytes or whatever it was, less than 2 megabytes for a number of these little apps. So that was pretty exciting. And you are correct using the analogy that it was equivalent to being published. And then later on, you had, I think it was download, well, CNET something and then download.com and it started to be the places where you had to be to, I 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 or 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.

Well, we had an Apple II actually, to be correct. We did have an Apple II. And I mean, I have photos of me as a toddler, next to the Apple II and these sort of things. So that's how I kind of recall.

But we did have a Mac Classic later on. And I guess 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, if you don't have an accent and no poking points, what's that?

I think you're saying Atari. Yes, 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. Well, Pierre, let's pause there for a minute. Since we talked 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, obviously. But we'll be right back. ImageX is a real-time image processing proxy and CDN. And let me tell you, this is way more than ImageMagic running on EC2.

This is way better. It's everything your front-end developers have dreamt of. Output the PNG, JPEG, GIF, JPEG 2000, and several other formats. And if you're like me, 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 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, ImageX 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 1,000 websites in the world trust them to serve their images. Now, when it comes to performance, ImageX operates out of data centers filled with top-of-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 ImageX 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 ImageX 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, your dad, yourself, were Apple. You got a picture of yourself next to an Apple Mac Classic, or it was an Apple II.

It was an 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 There were executives that sold on Apple, and then they were really, really interested in the stack, and they ended up acquiring all the technologies, the IP, and all these things, and I joined Apple and then I built the 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 1, was running it for a number of the animations. The Apple Stores, reservation system at the time, like all the animation with the QLS stuff was running it, really like 5, the pro motion, like a bunch of places were leveraging its power, and big clients of it were internally the Edgei team, which is the human interface team, and they were using that as a replacement for Director, MicroMedia 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 today, even today, you know, 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 yeah, it ended up being used, you know, really all over the place. The most funny or original, I should say, example I heard of it used was after the iPhone launch and official presentation by Steve Jobs, the director of the graphics and imaging group kept me and said, Oh, I learned that the whole display system to, you know, display the iPhone on the gigantic screen on stage and all of that was actually built on Quartz Composer, which I thought was cool. Obviously, I wasn't in the know at the time for these 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.

That'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 are at Apple in a pivotal time for the company, which was when they launched the iPhone, and that was in what, I think it was 2008 or was it 2007? It wasn't 2007.

I think it was announced in 2007. I don't remember exactly. Yeah, like it was at least teased. It wasn't released.

I think it was 2008, it was released. Yeah, there was a gap of a few months 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 the iPod and consolidated the product lines, and it 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.

A lot of salespeople. When I joined, it was just before the Apple Store, if I'm not mistaken, or barely. So now Apple is a ton of salespeople, huge workforce, merged a lot of engineering teams and all of that. But, you know, it's the department I was at, graphics and imaging, was actually very small.

It was about 50 people and minus, you know, the people who were managers. Even though engineering managers, like I was, were definitely coding a lot, not just managing, but still not coding as much, shall we say. A couple of QA people, administrative assistants, 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 3D graphics would have been quartz, all in PDF, all of that. That means all the hardware acceleration, all the window server, all the 3D graphics, all the color management system, all the image capture, all the printing, you know, everything that touch pixels. And so a very small team. Yeah.

I mean, Apple 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 in the software engineering division, in terms of productivity for engineers. 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, my couple example, my immediate neighbor office space wise was the creator of Core Animation, which was the foundation for UI kit, which was the foundation for the whole UI for the phone. And it would not have existed without it. Right. And it's that's it.

That's one person extremely talented, of course. My other neighbor was the the engineer behind Core Video. And again, which was 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 of these things. Absolutely critical.

He was also the 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 course engine for 3D rendering on OS X.

And that's it. It's things like that. So 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 weird groups at Apple to have access to a lot of prototypes because, you know, when your 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 this. So we would have access to them. Or when the camera was eyesight was added to Max, like all this sort of things. And you have to build things for that.

And guess what? It's graphics. When you have a new app, if it's a new iPhone or a new iMovie, well, guess what? The leverage a lot like Quartz Composer and any other techs.

And so you need to view it as well because you need to work with them. So that was a great place to be exposed to the gadgets and things that were going on and also learn because I was one of the youngest in that team at the time. A number of people were coming from Next and were 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 the ability to learn. And it's very, it was very unique on a number of levels. And I have not seen that to this extent at other places afterwards in my, in my career.

And I don't know if that's still the case at Apple today because, you know, people move on and then now it's much bigger, a lot more engineers. The recruiting bar might have been lowered because, you know, 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. Those sort of things.

When you say Painter, do you mean Corel Painter? Yeah. Well, before it was bought by Corel. OK.

I think it's just interesting to see that, you know, a budding software developer decides to really get interested in 2D and 3D graphics, tinkers, as you said before. And I know that Ticker means a lot of things to a lot of people, but ultimately created PixelShox, 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 on 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 So I joined the iPhone team and helped with the SDK on the media side of things and graphics and whatnot. And after the SDK release, I ended up leading and well, 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 views and blocks and so on and so on and animate them and have hardware acceleration for that. So CSS transforms, 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 it took us a while, joined the Scholary 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, another way of browsing and exploring, really, Wikipedia, done for iPad, launched very soon after the iPad was launched. And the main idea there was that what if we take the Wikipedia content, which is encyclopedia content, so therefore kind of boring, and make it like a magazine and very nice presentation, lay out 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 that was a very interesting experience for me. I was in Japan at the time for a couple of years, so I worked with a Japanese designer to build this app and they bring a completely different perspective on design, as you can imagine. Very, very interesting experience.

We built some, yeah, I mean, the templates, the style of the app and so on. Now it would look seriously dated because, you know, it's six, seven years old. Right. It was a different thing.

I mean, yes, yes, but on the original iPad, you 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 magazines, which became quite popular afterwards. That was, this app was part of the, like, Flipboard of really kicking the trend, I guess, or was it the right time at the right place to an extent. And so, yeah, I built a few, I mean, a couple of iPad apps and some other stuff for Colaris. And then Everpix happened, yes.

Well, cool. Let's pause there for just a minute. We're gonna touch a bit on Everpix when we come back and dive deep into GitUp and the troublesomeness, I guess, of the user experience of using Git from the command line. But we'll be right back, so hang on.

I have yet to meet a single person who doesn't love DigitalOcean. If you've tried DigitalOcean, you know how awesome it is. And here at the ChangeLog, everything we have runs on blazing fast SSD cloud servers from DigitalOcean. And I want you to use the code CHANGELOG when you sign up today to get a free month to run a server with 1GB of RAM and 30GB 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 at DigitalOcean.com to sign up and tell them the 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 when you were on vacation. 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 Gitup 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 company.

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 far. Different time frame, too. Yes, yes, absolutely.

Very, very different. 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 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, is 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 services at the time.

That's back in 2011. So obviously the big ones like Flickr and to a more historic one. 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 I 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 the first thing I wrote was really an efficient syncing system between iPhoto and, I mean, Aperture.

I was using Aperture at the time, and the cloud. And, you know, even things that, little utilities that were attempting to do this at the time with to send all your iPhoto library to Flickr and things like that. They were far from doing it as efficiently as the approach I have taken. Like, for instance, I was doing some reverse engineering of the iPhoto and Aperture databases to directly grab everything efficiently rather than requiring people to kind of export 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, okay, well, that's pretty cool. I want to keep going with that.

And then Kevin Cunnison, who I knew from my time at Apple because he was on the CoreSculpture team, turned out to be 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 saw a designer and I met Wen Fan, who was at a turning point in his career and looking for the next opportunity. And so the three of us were pretty interested in that, interested in the space and decided to, you know, 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 to our surprise, in a way, we got selected. And so they have hundreds and hundreds, if not a thousand, I don't even remember, startups applying and they specifically picked 10 or 11. So 100 to 100 and they picked 10 or 11. Yeah, it's even more than that.

And now that's why I'm surprised, not because you were really awesome, but because there were so many. Well, you know, we're very early. And yes, there were so many. And we were kind of rushing to do the application.

And in any case, it was selected, which definitely gave us a boost and we compared with the company and rushed before the event to make sure everything was aligned and transfer the IP and all of this and raise a little bit of money. And then from there, you know, we were able to present it, starting 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 people, 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 other devices. That was actually just the prerequisite to tapping and addressing the real problem. Let's say Instagram and whatnot.

And Everpix 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 pooled in in the same bucket as a bunch of other startups. And so how do you compete? 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 while some little photo app might have like a million active users, we had like 50,000 something registrations and signups and all this. And even if all the reviews were really, really good on the app store, like all over the place and people absolutely loved the product and the press and we got a really high amount of press coverage, as a matter of fact. And it was it was just not enough to alleviate the concern of of large investors when you're at the Series A stage where you typically raise like at least five million. And we raised by then like two point five million.

But, you know, the money was gone. It was spent on payroll, on infrastructure and all of these things. And so Everpix was kind of cut short and we never know if it would have become something very, very 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 in the company had to shut down about six months, eight months at most after, you know, one point it was really released.

And things were starting to pick up if you, you know, a lot of the 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 have to redact a few of those things for obvious reasons, that there is no data whatsoever from the users, as you can imagine. 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. I did all our metrics, all the data, like a ton of data. And because nobody had done that before, like to that extent, like no startup not making it at release all the data raw edited 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 2015. It was, yeah, it was very, very popular in the startup world and discussed because like I said, it had not happened before to see suddenly inside having such an inside view of all the all the data. And before there had been a very good and well-written article and pretty much unbiased on 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 factors, the VCs and all of that.

And that was also an article that got very, very popular in the startup world because it was an inside look at what exactly happens when a startup fails. Like how do you get there where you get so good reviews from the 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 run 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 PhotoSpace. And, you know, if you look at Google Photo, for instance, today, it's it is extremely close to to whatever it was at the time. And of course, they do a number of things better.

And we had a thing that we're doing better, but it is it is very, very close. A number of concepts, you know, the Dropbox, whatever our key feature was called flashbacks and Dropbox a year later released a feature that is the same thing and called flashback after Everpix shut down. We released what was called a stem feature, right, what was called inside highlights. It took us some time to find the term and everything.

This idea of using the 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. It was all dynamic in the in the iOS app and things flying around in a very intuitive way. And, you know, three months later, like Google Photo came up with what was called Highlight and to define 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 four to five X settings in terms of space at the same quality perceptually right on screen.

And so a photo that used to be one megabyte was now on average, 200, 200, sorry, kilobytes. And these are massive settings of storage cost. That's the size again. You said one megabyte, four to five X settings at full resolution, the full resolution and, 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 one of the other thing we did is that, well, photos are taken in JPEG. JPEG is a very old technology based on, you know, fast Fourier transform and all these things and goes back dozens of years and we can do much, much better today. So we built everything on top of volume of JPEG 2000 and Weblight and all custom conversion pipeline, all these things.

And the results, you know, spoke for themselves. We had the fastest syncing by the factor of four to five X compared to the competition and our storage costs were four to five X lower. I mean, like I said, we have 400 million full res photos. It's insane.

And for a very reasonable storage cost. And, 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 were 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 to the free tier, they cap to 16 megapixels and they optimize the photo, which means recompressing.

And so it's going to be the standard because it's not scalable otherwise in terms of storage costs and so on. So we suddenly did pioneer a number of ideas. And as a matter of fact, Google Photos released in a few days ago, something the equivalent of flashback Excel. They called that photos Tuesday.

I don't remember exactly how to phrase it, but it's exactly what flashback was doing with Everpix, 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 or anything like that because there are a ton of other factors. But it's, it's 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 I executed 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, 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. And, you know, on Twitter or if 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%, whereas others had 3% subscription rate, you know, on the free tier. But there's a, there's a separation of, of advancement in technology, which clearly you're good at. And there's an advancement on on a product, which is what investors are actually investing in. Right.

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 sorry A tiny bit more advanced, you go to Stack Overflow, you enter your query, and so on.

And so that's a fact that among the five Stack Overflows, 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 Git questions, four basic stuff, like how do I edit a commit message, how do I undo a commit, or this sort of thing. Really, really basic.

And I think it's clear by this time, the people behind Git, truly owning Git, like the Git project, are not gonna 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 gonna 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 Mercurial 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 loss of 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 gonna go bother that person every time there is 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 I figured, you know, the way, what's very interesting with Git is that 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 gonna 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 to do that, and then that other operation, and so on.

And you see what I mean? And then the person goes, 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 commits that shows you roughly what's happening and so on. 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, I select the commit and I hit delete, and it works.

If I want to edit a commit message, I click on the commit, and I somehow trigger an edit option and edit the commit message, and it works. If I want to do a rebase, I can see visually what's happening. If I want to do a merge, I understand it, you know, those 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 just tried 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 frustrating situations 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 that gets 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. 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 commit are done, the trees, all of that, the database format, like it's designed to be one of these technologies where the beauty is 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 Windows apps, pretty much the state of things.

But the existing GUI 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 the repository option and you put some nice Polish on top of this and make it look clean. But that's really just the peak to be brutal. It's not solving anything, you know. And you're just compiling problems.

Now 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 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 used by, you know, all apps embedding it. And so LibGit2 is a C API and everything is very clean. It doesn't do everything, but it does a number of things really 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 it just uses LibGit2 for, say, commit parsing and the merge engine and the diff engine and these sort of things. And, but everything else is built 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, it's not to respect 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 hickups and et cetera, et cetera. So you really need an abstraction layer, in my opinion. And so that, you know, the GitKit in a way, that's what I called it, is this.

It's like a subset that's very solidly LibGit2 and rebuild everything on top of it in terms of Git functionality from checkout to merging branches and all of that on top of the subset. And then add a bunch of layers to do unique features like unlimited undo redo, which no other Git client has, to, you know, snapshots like time machine for a Git repo, which is very, very cool and life saving. And other features like splitting commits just without touching any file on this. You select a commit, you can split the commit and the lines between these files, like in a completely fluid way and then just commit the result.

And it's done. Or, you know, 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 use, you just deal with the Git database directly and then it solves a gazillion things. And so it is built.

Yeah, yeah. I mean, it's not simple when you describe it like that. You just deal with the database directly. That's a big deal, I think.

Yeah, yeah. And so it doesn't try to call the command line. It doesn't. I mean, GitHub works even if you don't have Git installed at all.

It doesn't run Git. It doesn't touch it. It doesn't mess with your config settings. It's a very, very safe app.

I know this and now open source. You can see how it's done. So you can have even more trust in a way. And so GitHub 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 through 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, and it's still modern, right? And it's completely And that was released early this year. I think it got up to the top of hacker news and then was featured by product 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 it, you know, a certain category of people, I can't, I don't, it's a bit tricky to measure the adoption. I got a rough idea of a number of downloads. It's around, last time I checked, around 50,000, 58, 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. And but it's not a million, right? And yeah, it has definitely thousands of active users for sure. At the bare minimum and a very good feedback on Twitter.

It resonated to a certain category of Git users for sure. I don't know where the project is 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 all go bigger.

It's very, very difficult to say. But we'll see, you know, it's, I'm pretty happy with where it's at. I got help in terms of design and some of the user interface with Winfram, who was my co-founder at Everpix and a designer. And I also worked with Jason Everly, who was my, who was our web engineer at the time at Everpix and he helped me 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 were gone 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 ImageX was actually a sponsor of the show and Jason works at ImageX.

And I was a contributor to the ImageX.js library, which helps those repositories, you know, that that's a library there to work with the ImageX API to allow your app or site to work with the ImageX API and deliver responsiveness on your, on your app or your site. Yeah, absolutely. Yeah, well, you know, that's one of the things you, you have in 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, when you arrive because it takes a long time to build connections unless you're at the right time at the right place.

Right. But that's probably what happens to that too, that Jason was part of this. And when I was doing my research, I'm like, ah, it's cool. Jason was a part of this.

Yeah. And I mean, 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's this, this, this mathematical proof that people are only six degrees away or seven. I don't remember, but in the 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 there's really an ecosystem there.

It's 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 pass 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 we painted during the 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, I feel like it was really important to sort of dig deep into your past to really get an idea of, of how serious to take GitHub. You know, 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, right? And a lot of, 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, I'm going to go back to my notes here, the GitHub kit that sits on top of this, the interaction directly with the Git database. You know, I think that you're taking some really unique approaches towards solving this problem.

And maybe you're not far enough now. So for listeners out there thinking, ah, this is a pretty, you know, a good UI. I love how it works. It 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, but it, it has the, it implements the concept I had in mind to a truthful degree in terms of user 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, or Course Composer and whatnot. But you know, it's through the years, obviously, like in any trade, you, 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, et cetera. So some of that hopefully does reflect in the way it works and, and the way it's built. And, but it is, yeah, it's 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 call it better, at least for my pattern of work, my workflow with Git. And then figure out, well, okay, it helps other people, interest other people. Can you make a business out of that?

Of many people is that going to be, and then you weigh that against the amount of work that's needed and, and support and all those other things that come along and the 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 lets, it gives, 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 write on your own. So it's not going to go away and disappear. And, um, and you can judge yourself, uh, 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 the, um, and for free comes with this thing that I called, um, very innovatively, you could say a GitHub kit to rapidly find them. Right. So, uh, which is just all the pieces to make your own GitHub. And, and if you look at the repository, there are a couple of examples in there, uh, that show in, um, in a few lines of code, really like 20, less than a hundred lines of code.

So how to build like two little, um, Git clients, uh, that leverages all the power of the pieces that GitHub has in terms of undo, redo, in terms of, uh, it has its own text, uh, sorry, different rendering engine based on cortex with speed, like a lot of, a lot of work went into performance. Um, the deep rendering is very fast. It's directly on top of cortex, for instance. Um, and, and that makes a difference when you deal with, uh, reasonably large defense close to them.

Like all these sort of things, it's, um, quite faster than alternative, uh, 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. Um, 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, um, I go far with that. I'll give you an example. Um, the, there are a number of dialogues, right?

Model dialogues in GitHub. 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 off the top of the window, right? The title bar.

This sheet stack, I, the animation is like half a second Well, there is a view called GI BodyView and that's the lowest level thing. It just renders a view within a view and then you have to put it in your own scroll group to scroll and all 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 GitHubKit to demonstrate how you actually can build with. And GitHubKit actually has some directory inside of GitHub. So it's easy to dive deep into that code if you want to. It's not scary.

It's easy to find. You know, the only question I have, I guess, turning towards the close of the show, and this is not prompted from the feedback I got from you on the show, but beforehand, so some assumptions come from this question. And that question is, will this, and this being GitHub, 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 open source projects that are actually paid. I'm sorry, that are sold or have in-app purchase like ComicFlow is one, and it's not really open source.

So if you 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 hypercomplicable. But today, I don't see a reason to monetize GitHub right now or in a way that would not be artificial. The ComicFlow was an app 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 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 C++ project which is called GCD Web Server, which is probably now the most popular web server for iOS and Mac apps. And it's open source and BSD or something equivalent, so not even GPL, so all good. But I figured, you know, that's a lot of work, so I'm going to make that an in-app purchase, and it was, I think, $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 this thing.

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 questions. I'm only going to ask one. I know I gave you four different options, but we're going to ask one. And 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 GitHub, and to GitHubKit, and what you're doing with that, what is a, 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 want 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, go and explore and try out an experiment to change the way people interact with Git.

And see if it's fit for you and make it become big 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 valid.

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. So there's nothing else like this. It's a completely unique way of interacting with the Git repo.

There's no client that does this, from the way it's built to the way it's used. I can remember talking to, I'm trying to 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, on this show, to just dive deep into your history. And I think what you're working on is very, very interesting. So for those listening, GitHub is also repo, but it's also a web address.