The Changelog: Software Development, Open Source - Why SQLite succeeded as a database (Interview)

Episode Date: April 30, 2016

This episode is part of our remastered greatest hits collection and features Richard Hipp, the creator of SQLite, talking with us about its history, where it came from, why it has succeeded as a database, how its development has been sustainably funded, and the how and why of it being the most widely deployed database engine in the world.

I'm Richard Hipp, and you're listening to The ChangeLog. Welcome back, everyone. This is The ChangeLog, a podcast featuring the hackers, the leaders, and the innovators in the world of software. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. This episode is part of our remastered Greatest Hits collection and features Richard Hipp, the creator of SQLite, talking with us about its history, where it came from,

why it has succeeded as a database, how its development is sustainably funded, and the how and why of it being the most widely deployed database engine in the world. Everyone, we're here today joined by Richard Hipp. Now, Jared, this is a deep topic because SQLite or SQLite, we'll debate that during the show, is such a prolific, widely used technology. This is something you pointed up in terms of this technology that kind of interests you. So maybe we should open up with why it interests you so much.

Why it interests me was basically for the ubiquity of it. It's one of those technologies, I think I've said before on the show, I think it was the Curl show. We're coming to software development around the year, I guess, 2001, 2002, anything that predates my inception into software, I just kind of assumed always existed. And so this is one of those programs that I just haven't thought about in the historical context until I saw someone link an article, I think the Guardian article,

which was actually written back in 2007, but still seemed pretty poignant to this day, and got to just reading about, I knew what the Guardian article, which was actually written back in 2007, but still seemed pretty poignant to this day. And got to just reading about, I knew what the technology was, but reading about the technology and how many, I mean, it's just like in almost every device in the world. And it's public domain, super interesting. So I said, oh, we got to get this guy on the show. And Richard, thanks so much for joining us. Thank you for having me, guys. So usually the way we kick off the show is diving a little deeper, especially, Richard,

to someone like you who's got a deep, rich history of software development, kind of figuring out where they came from, what made them get into technology in the first place. So take us back to as early as you want to, that got your influence, that got your feet wet in technology. What was the first steps that got you into software development? When I was in the ninth grade, I saw a teletype connected with an acoustic coupler, 110-balled modem to a mainframe computer. And I said, I've got to learn to program that. And I went to the school library, and I checked out every single book about computers in my high school library, all three of them. And I read them cover to cover that night. And I got an account on that little computer and started programming away in BASIC.

Saved up my money. Shortly after that, the Apple I came out. And I was about to buy the Apple I, and the Apple II came out, and I bought just the motherboard for an Apple II. Got it. Had to build my own keyboard, my own power supply, soldered it all together. The first board I got didn't work. I called up Apple. They put me through the technical support, and Steve Wozniak answers the phone.

What? And said, oh, yeah, send it back. We'll send you another board. And they sent me another motherboard and that one worked. And that's how I got started in computers, trying to write programs in 4K of RAM. And that 4K included the video memory. And so that's how I got started. Went to university, studied electrical engineering, didn't do anything with computers for a while. Coming out of university with a master's degree, I took a job at Bell Labs. And the first thing they did was sit me down in front of a console running Unix. And I learned Unix in C.

And worked there for a few years, quit, went back to graduate school, came out of graduate school in 1992. And back then, getting a tenure track position was really, really hard. There were hundreds of candidates for any open position and I was not the best candidate. My application was near the bottom of the stack. And so I just started my own company, just developing bespoke software, solving hard problems for people. And that company has been in business now for 24 years.

And in the course of doing that, one time we had a problem where we needed a database engine. We were using Informix. The customer said, oh, the customer specified Informix. And, you know, that's a big hassle to set up and stuff. And so for development purposes, we needed something simple. We used Postgres for a while. That worked well for development.

But it was read-only. The database was read-only. And I thought, why can't we just, why can't we read this database directly off of the disk? And so I just said, well, I'll write my own database engine. And so I wrote SQLite. And that got to be real popular, and here we are. That might be the purest love at first sight type of a story

in terms of technology I've ever heard. Where it's just like I saw it, and I thought, I'm going to go get every book from the library I possibly can, and I'm going to do this. But yeah, that was a lot of fun playing with computers in high school. But I stay away from computers all through college. It should also give anybody that's new, I guess you should say, is the easiest way to say it, some inspiration because you cared so much that you created your own hardware

to access the motherboard that you had bought from Apple. To me, that's determination. That's the purest, simple version of determination I've ever seen. Well, there were no options back then. By any means necessary, you had to. That's all you had to do. And we didn't have computer monitors of any type. You had the video output.

You had to modulate it to RF, into the RF range, and hook it into the antenna wires on a TV set. And of course, limited resolution on a TV set, the whole screen was 40 characters wide and 24 lines long. That's low resolution, folks. We thought it was magic. It was the most amazing thing in the world. Well, take us back to that.

Let's share with us, if you can, Richard, a story of a magic moment then, since it's such magic to you. If you can remember back to those times whenever you were first enamored by this thing, what story can you share that sticks out most to you about something magical? You know, it's hard to say. It's just something magical about making things work. I've always liked building things from scratch and making things work. You know, that goes back in my family. You know, My father's the same way, though. When he builds things, my father's sort of the original maker. You see the makers now. But modern makers, they always have computers built in.

The things my father makes usually involve an internal combustion engine of some sort. But it's the same idea. I just do it with abstractions on a computer screen. Writing programs is a really, really interesting thing because we can build entire worlds

out of just pure thought stuff. We don't have raw materials. It's just pure ether. And it materializes and it becomes a whole other world. That makes me think of a very specific domain where that other world comes into the real world, which I think nowadays is somewhat considered a solved problem. But I think probably you faced,

at least when you were getting started, which is printing. Do you have any memories of the early days of printers? I mean, did you have to write your own drivers? How did printers originally? Yeah, I didn't print things out. It would go up on the screen and you'd write it down. That was faster.

Yeah, it really was. Printing was not an option. I looked at ways of making my own printer. You know, they had daisy wheel printers that would print things. But that was a lot of money and I didn't have any money back then. You think in, you know, 1977, the Apple II motherboard costs $600. That was just the motherboard. And that's $619.77. Jimmy Carter was president of the United States.

And so that would be like paying thousands of dollars today for just the motherboard. And it had 4K of memory on it. Printers were ridiculously expensive. I did manage to get a hold of a used Selectric typewriter and I played around trying to figure a way to get that to be my

printer, but turned out a Selectric typewriter is mostly mechanical. It's not much electrical interface to it. So that didn't work out well. Figure a way to hook up

an internal combustion engine to the Selectric typewriter. Exactly. Yes. Exactly. You mentioned that you went away from computers in college and I read that you got a philosophy degree or you got a doctorate of philosophy from Duke.

Can you talk about your college years and why did you move away from software and why did you move back? Well, as an undergraduate at Georgia Tech, I did electrical engineering. And I stayed away from software because I figured that was easy. I knew how to do that already. And I wanted to learn new stuff.

And so I did digital signal processing, which in the early 1980s was a really phenomenal thing. This was brand new stuff. Now everything is digital. But back then, it was just the beginning of the digital age. And I didn't really, I'd never taken a computer programming class until I went to Duke in graduate school. And I studied in the Department of computer science there it was computational

linguistics artificial intelligence and my thesis was on um a speech recognition system and a dialogue system and i figured really cool ways i devised some really cool things for resolving elliptical utterances and anaphora. So it was interesting work, but once I left, I did that for five years at Duke and left that and never looked back. I haven't done anything with it in two and a half decades. Never to return or maybe eventually? Maybe eventually. Not in any hurry. People get real

enamored by AI and that sort of thing these days but I lived in it for five years and I still think that a lot of the hype is just that. It's hype. Even to this day? Even to this day. The AlphaGo situation, I don't know if you're up to speed on any of that with the AI program beating the Go champion.

That was a significant event. And the IBM thing, the Watson thing, that was significant. These were significant. But still, there's thing, that was significant. And these were significant. But still, there's a long way to go. There's a long way to go. The material available to people these days, compared to what I had, is enormous.

I mean, what I wouldn't have given when I was in graduate school to have this internet full of text that I could study. Just getting a corpus of text to use for analysis was really, really hard in the 80s. Whereas now you can trivially download gigabytes of it. And that helps. It is moving the field forward. But if you read newspapers and magazines, you'll think that HAL 9000 is just around the corner, but I don't think so.

Yeah, I think from those seeing it from the inside, even though, as you said, the major milestones and we are definitely making advancements, but as people who work in software day in and day out, I think we definitely see a different angle at the world of software advancement that other people... We still have trouble getting graphical user interfaces right, let alone something that understands itself and is self-aware. I mean, forget it. Oh yeah, oh yeah.

Self-awareness is a huge, huge thing. So I read an interesting tidbit on your Wikipedia page, which I don't even know if the fact itself is interesting. I mostly want to talk about it because it said there's a citation needed. And I thought, can a podcast be a citation?

If so, we could get one right here. You can confirm or deny this and then we can go and edit Wikipedia when we're finished with this call. It says, he married Ginger G. Weirich on April 16, 1994, changed the name of his company to Hip Weirich & Company, Inc., and signed all stock over to his new bride. I did. She's the president of the company. Turns out I had to buy half of that stock back from her at one point. Oh, really?

Yeah, we were working for a company, and of course I was the prime on that company, and they insisted that I be a significant shareholder in the company. And so we went out to eat. We declared a business meeting, and I handed her a $50 bill and took 50 shares of stock. Ginger is a musician, and so we're yin and yang. But she's very prolific, and all of her stuff comes through the same company. Very cool. But she's the president. I'm head of research.

Is there a reason why? Is it personal? No. It's just... Just why not? Yeah, why not? It's like a fun thing to do. I was excited about getting married.

Right. That's one way to earn trust. It's best met... I thought getting a PhD was hard. Con's one way to earn trust. It's best met, you know, I thought getting a PhD was hard. You know, convincing Ginger to marry me

was the biggest thing I ever accomplished. Wow. Way harder than writing the most widely used database engine in the world.

Well, it's quite an accomplishment then. It is. My proudest accomplishment. I had a similar move but not quite as, I guess, profound as yours when I incorporated my consultancy as well. And you do have to name, you know, just for legal reasons, board of directors and all these things. And I made Rachel my wife, the treasurer of the company.

I just figured there was some poetic apropos-ness to that. But I think president would have won me more brownie points for sure. So that is true. Alright, well, we can go ahead and Wikipedia it and we can add the citation and say refer to this timestamp of this episode.

Since we're on the note of Wikipedia, is there any sort of heading there? I haven't scanned it fully that debates how you pronounce the technology. How do I pronounce the name of the product? I say SQLite, like a mineral. Okay. But I also hear a lot of people say SQLite and SQLite.

And, you know, I don't care. Whatever comes off of your tongue easily is fine with me. Whatever keeps it being used. Just use it. That's the only thing. That's it. But the official correct way is SQLite. Yes.

Like a mineral. Okay. Like a mineral. Were you playing on the word light or were you just playing on the mineral aspect? I was. Many people pointed out to me that I'm not good at marketing. My marketing person would have picked a better name.

See, that was funny because in our pre-call when Adam and I were just kind of talking about this call, I thought you had pretty decent marketing, didn't I, Adam? I said, you do a pretty good job. I even like your little tagline, small, fast, reliable, choose any three. That appeals to me as a nerd. I didn't come up with that. Oh, you didn't? Okay.

No, somebody put that on the mailing list, and who it is is lost in the sands of time. If they're listening, please call me and remind me what your name is. But somebody said, hey, why don't you put that on the website? I said, that's great, and I put it there. So no, that one's not due to me. Do you recall when you put that on there, and has it been any sort of real driving force, or has it been something that just entertains Jared? It's been there for over a decade, and so we haven't messed with it.

Everybody likes it. It's a cute little line. Well, I think we want to talk about SQLite. I'm going to try my best to pronounce it that way for you. I guess I've called it SQLite, just because even SQL and SQL, you pick which one you want to say, I guess. Seriously, call it what you're used to calling it.

Okay. Seriously. I'm just going to call it natural. Yes. But we want to say, I guess. Seriously, call it what you're used to calling it. Okay. Seriously. I'm just going to call it natural. Yes. But we want to talk about it. We want to talk about its history. You mentioned kind of its inception a little bit, but we want to drill down on that.

And then we'll get into the technical features. We'll talk about the ubiquity, the community that you built around it, the business that kind of is there that supports it, all sorts of things. We'll take a quick break and when we get back we will talk about all those things and more. Alright, we are back with Richard Hipp

and we are talking about SQLite. I can't say it my way anymore. I have to say it yours. I can't even make myself do it naturally even though you've told me to do so. He's a rule follower. Let's talk about its origin. You mentioned that it came out of a specific need

in your consulting. We know that it was around the year 2000 was about the time that it became a product. Maybe that was 1.0, I'm not sure. But give us the reason, go deep on the reason of why you started a brand new thing, why it needed to exist. And you mentioned that you had Postgres as an option,

but this made more sense for the particular customer or the circumstance. Give us that Genesis story. So the customer, they were using Informix for the database engine. The problem that I was working on, it was a really interesting problem. We had to solve an NP-complete problem,

which of course we couldn't solve, but we could do really good approximations, and that's what it was about. And it was a really, really cool about. And it's a really, really cool product. And I was a contractor, but I was sort of leading the design. Anyway, we put this thing out in the field for testing and it was in an industrial site. And the people that operated the equipment, they would sometimes power cycle the machine that was running on. And when it would come back up,

Informix database sometimes would not come up. And this was a configuration problem. It was all it was. There was nothing wrong with Informix. They just hadn't installed it right. But when the database didn't come up and the users would double click on my application, I would try and connect to the database

and wouldn't be able to. And I would pop up a dialog box that says, I'm sorry, I can't connect to the database and wouldn't be able to. And I would pop up a dialog box that says, I'm sorry, I can't connect to the database. And of course, it wasn't my problem, but my application painted the dialog box. And so I got the support call. And I thought, this is not a good thing. I'm not in the database business.

Being a database guy is never part of my career goal. And so what can I do about this? And I thought, well, look, the way we're using this database, it's read-only, at least to us. And it's very, very slowly changing otherwise. And if the computer is healthy enough to bring up my application, why can't I read the data directly off of disk? Why do I have to go through a server to get to my data?

There was a funding interruption. I had a couple of months off, and I thought, hey, I'm just going to go and cobble together a really quick and simple database engine that just does a few very simple SQL commands, insert, delete, update, and select. No joins. Wasn't trying to be efficient. All I needed to do was pull stuff off of a disk into memory. And I put it out there. And I've been doing open source for years before this,

putting things on my website. And people would find my thing. Or, well, you know, I'd put things out on my website and it'd get like five downloads per year or something like that. And I figured this would be just another one of those things, but for whatever reason, it really resonated with people. I remember seeing on NetNews somewhere, somebody just had this really exciting post on NetNews about, wow, I this really excited post on NetNews about, wow, I have an SQL database engine running on my Palm Pilot. This is no joke. And of course,

whenever people get excited about your software, an ego boob kicks in and you think, I'm going to work on this and make it a little bit better. And so, yeah. And so that was motivation to kind of work on it

when I had the opportunity. And so, yeah, and so that was motivation to kind of work on it when I had the opportunity. And the first version, it used GDBM as the storage engine, which is the GNU database manager. It's a hashing-based database, which is GPL. And so SQLite version one was GPL, but it's also hash-based. And I wanted to expand SQLite to be able to do range queries. And for that, you need an ordered storage engine, a storage engine that orders the keys, basically a B-tree. And I looked at BerkeleyDB, which was the big thing at the time. And I spent a couple days studying the documentation, and I realized that the documentation was sufficiently vague that I was going to have to write test programs

to find out enough detail to make this work. And I thought, you know, it's going to be easier for me just to write my own B-tree storage engine. So I did. And that was SQLite version 2. And that got to be really popular. When was that then version 2. And that got to be really popular. What year is that then? 2001.

Okay. Yeah, it's, the first release of version 2.0 came out just a couple of days after the 9-11 event. And then, but that got to be really popular. And before long,

I started getting phone calls. And I got a phone call from Motorola. And I don't know if you remember, but back then, Motorola was the world's leading manufacturer of cell phones. And they said, hey, we want to put SQLite in all our cell phones, but we need you to make some enhancement for us. Can we bring you under contract to make these enhancements and to support it? And I said, sure, of course. I hung up the phone. I thought, wow, you mean you can make money off of open source software? Who knew? And I had to figure out some kind of pricing structure. We put together a contract and it wasn't for a lot of money.

But for me at the time, I thought it was all the money in the world. And I hired some people and we made some changes and that went great. And then AOL contacted me and said, hey, we want some enhancements. And AOL needed to be able to handle binary data. SQLite version 2 could only handle text data. So AOL said, hey, we'll give you some money, fix it to handle binary data, and so we did, and once again, I was able to hire some people, and I got Dan Kennedy working for me at that point. He's from Australia, and he's been working for me ever since,

and we started SQLite 3, and I think that was in 2004, about this time, 2004. And once SQLite 3 got out, it got loaded into everybody's products, and it just grew and grew. I was still doing bespokeite for companies around the world. I like that. It's very kind of organic. You go kind of adding big customer to big customer. Each one brings you on a contract to add some features and so the overall product gets better. You mentioned the first version was GPL and it's public domain now. I guess let's put that on hold. I won't talk about it specifically soon. But I want to get to the ubiquity because you said that everybody started, when Motorola came and they

wanted to put it in their phones, that's a lot of phones. And now you have AOL and then you start to add all these other ones. If we go to the website now, there's a page which was the one that I just sent to Adam and I was like, we got to talk about this. Because I knew that it was in every Linux basically. But I didn't realize it's on every Android device,

every iPhone, iOS device, Mac, every Windows 10 machine. So that pretty much covers all computers there. We're using Skype to talk, it's inside of Skype. It's in Skype, that's right. It's in iTunes, it's in Dropbox, it's in TurboTax, it's embedded into languages like PHP and Python have it. Even television sets and set-top cable boxes.

Most of the uses I don't even know about. I mean, people will write to me and say, hey, I was messing with this or that and the other and I found this SQLite database file. Did you know they're using your software? No. I'm glad they are. I'm glad they find it useful.

It's used in most everything. I think, it's impossible to tell, but I think that SQLite is probably, there are more instances of SQLite in use every day than all other database engines combined. Clearly, the other database engines make a lot more money

for their creators, but I get the usage award. And I also think that SQLite is probably the

second most widely used software component in the world behind ZLib. Which is the compression library. Compression, yeah. GZB and whatnot. I haven't world, behind Zlib. Which is the... The compression library.

Compression, yeah. Gzip and whatnot. I haven't been able to identify anything else that I think might be used more than SQLite. So that's got to feel pretty good. Yeah, it's a little bit scary, a little bit intimidating. It's got to make your decisions weigh on you more when you're like, well, this is going to affect everybody. It does.

It changes your whole perspective. The way I look at software today versus the way I looked at it 15 years ago is very different because of that. So let's talk about why. I mean, I think I have a good guess at why it's so widely distributed. But as you said, there's many other database engines out there, many that are very good. Even Postgres, which you say you use as kind of a reference implementation of at least the SQL

stuff. But why is SQLite so ubiquitous? What do you attribute it to personally? I would believe your opinion more than mine. I don't know. I put it out there and people really liked it. I'm flattered that they like it. I mean, the team and I work really hard to make it a solid product that stays true to what it is. And the goal is that it just works.

It should be in the background. It's not something that you have to think about. It's there when you need it, and it's going to work. It's like a utility. You don't think about the people if the water works, and so when you turn the spigot, fresh water comes out. But that's an amazing thing. And we want SQLite to be just like that.

It's just there, and you take it for granted. That's what I think. I would think that, like, just like that, like, my first experience with it was Ruby on Rails. And, like, as soon as you get Rails going, it's using that, and, you know, there's no need for something extra.

You could add it if you wanted extra, if you needed different things. But it came with it. And just the fact that it was so simple, it was a single file. You can copy and move it around as you wanted to. It seems to me like the access and barrier is so low to use it. It's so simple. And everything else has so many hoops to go through. Yeah, we try and keep it

simple. Now, one of our earliest patrons was Symbian. The company made the operating system, and they were bought by Nokia, and that was the operating system on all the phones sold all over the

world, except for in the United States. They never really penetrated the U.S. market. But this was in, I think, 2005. Symbian needed a database for their operating system, and apparently they had a big bake-off where they got 10 different embedded database engines. They told me about this later, and SQLite was one of them, and they competed them. Seven commercial, three open. The other nine,

they actually brought in engineers from the company to help tune it for their tests, but they ran tests on it, and then they said that SQLite won the bake-off. And they called me up and said, hey, can you come over for a meeting?

Sure. And so I flew over, said, hey, can you come over for a meeting? Sure. And so I flew over and it was, we had a meeting on Thanksgiving Day. They don't do Thanksgiving in London, apparently. And- They didn't have the Mayflower. That's a good reason. They were the Mayflower.

There you go. But, but, so, you know, so apparently there was a bake-off and we did well in competition. And I don't know what the criteria was, but apparently we're very competitive against other databases. And more recently, and I won't name this other company, I've heard the same thing about another company, and I won't name them because they're still current and actively using it.

I just don't want to embarrass them. But they also had a bake-off and chose SQLite. So apparently we win the competitions, and I don't know why or how. I don't know, you know, because there's a lot of really good products out there, and I don't know why we happen to win. If it's luck or providence, I don't know. But we do try and keep it small and simple. We solve a problem,

and that seems to resonate with a lot of people. How about the embedded aspect? It's not client-server, which I think plays to its simplicity, as Adam said. There's less to set up, less to get started, there's less moving pieces to break. I think you said that Informix situation where it was a configuration problem

but it was trying to connect to some server or something. As far as I know, SQLite is the only SQL database engine that is not client-server, the other embedded SQL database engines like MySQL Embedded and so forth, they start a separate thread, which is the server. So they don't have a server process, but they do have a server thread as far as I know. And why didn't I do a server thread or something like that? Well, you know, it was easier not to is one reason. Another reason is that, you know, I'm not a database person.

I didn't know I was supposed to. Nobody told me. Oh, that's rich right there. No one told you you had to. No one told me that that's what you were supposed to do. And so, I just sat around and thought, well, how can I do this? And the way I did it seemed to make sense to me. So, that's what I did. Somebody had said before that you stumble on the best things in the world through accidents. It speaks to your curious heart, going back to your original story,

which is how you got into this in the first place, was complete curiosity. And maybe that's a good thing. Yeah. I learned a lot about SQL just writing SQLite, which is kind of scary, but true. It's just humorous in light of how widely deployed it is in the entire world. Especially early on.

I'm not really a database guy. Especially early on when I was writing it and I'd come across something and I went, well, how is this supposed to work? And I have to go ask people, what's it supposed to do when you do this? So we got just a few minutes before the break, but something just dawned on me that given what you had just said, something that a lot of software developers deal with today is this notion of imposter syndrome, where they don't belong.

And given the fact that you never thought you were supposed to be a database guy or whatever the story is, but yet as Jared mentioned and as everyone else knows how ubiquitously SQLite is used, have you ever dealt with or had to get over serious imposter syndrome? Has it ever been something where you're like, I don't belong here in this database world? Well, no, not really. But that just goes back to my personality.

I don't really belong in any little group. I don't fit in very well anywhere. I'm sort of a weird person. Eclectic, we'll say that. Eclectic, that's a good way to say it. Droll. Droll is a good adjective. So no imposter syndrome ever around not supposed to be a database guy, Troll is a good adjective. So no imposter syndrome ever around, you know, not supposed to be a database guy, but yet you have... You have to win on all the bake-offs. So that kind of destroys imposter syndrome when you keep winning all the competitions, I guess.

Well, I meant personally. Less technology, more personal. No, it's intimidating when I'm invited to talk to groups of database experts. And it can be a little bit scary because these guys, they have been studying databases their whole life. That's their passion. And for me, it just sort of happened. One day I was going along as a solving hard problems. And the next thing you knew knew I'm a database guy.

What happened? Well, it's a hard problem. Yeah. All right, we are back and we are definitely going to talk about licensing and the public domain side of this. But before we get to that, I think we could definitely cover some more of its technical merits. We talked about how some of this stuff was providential

or you stumbled upon perhaps some of SQLite's advantages over other database engines in certain contexts. But we shouldn't short come all of its technical merits. I think what our listeners could probably use help with is knowing the clean lines when it comes to comparing and contrasting from a MySQL or from a

Postgres or from anything that you choose, Richard. Could you just enumerate for us a few things that make SQLite different? Well, from the perspective of somebody who's just using a database engine, one thing that's very different is the type system that we use. SQLite really started life as a TCL extension.

TCL being the programming language, TCLTK. The project I was working on was written in TclTk. And so SQLite began as a Tcl extension. And it's a scripting language like Perl or Python where you can put any type of value you want in a variable. So a variable might hold a string, a number, a byte array, whatever. And so I made SQLite the same way where you, just because you've declared a column of a table to be text doesn't mean you can't put an integer in there. Or just because you declared a column in a table to be a short int, why not put a two megabyte blob there?

So what? It'll do that. short int, why not put a two megabyte blob there? So what? It'll do that. And this takes a lot of people by surprise. The way SQLite works, it's completely compatible with other databases. Where it causes problems is that people do their initial development work for, say, a Ruby on Rails app, and they're doing it with SQLite. And they take advantage of this flexibility in typing that SQLite provides without realizing it. And then they get ready to go to production, and they switch over to Postgres or MySQL.

And those systems don't do that, and then suddenly their application breaks. And, for example, they might have declared a VAR card 40, and they didn't realize they were putting strings in there that were longer than 40 characters. Yeah. And people have criticized SQLite about this. They say it's weakly typed, and the other systems are strongly typed. I think those are purgative terms. I prefer to say that SQLite is flexibly typed and that those other systems are rigidly typed or judgmentally typed. But it's a criticism. It seems like a point of contention. It's a point of contention. I can see both sides because if I want this to be a varchar 40 and you let me put anything in there, then why did I declare it to be a varchar 40 in the first place? Like what? You know what I'm saying? Yeah, exactly. If you say it's a varchar 40 and you put an integer in there, it will change it into text. Or if you have a column that's declared integer

and you try to put text in it that looks like an integer and can be converted without loss, it will convert it and store it as an integer. But if you try and put a blob into a short int or something, there's no way to convert that, so it just stores the original. And it gives flexibility there. And this is useful in a lot of cases because sometimes you just have

a miscellaneous column in a table that you might need to store lots of different things in. And in traditional database systems, you actually have to have multiple columns, one for each possible data type, whereas at SQLite, you put it all in one column. So it works well. And for that matter, with SQLite,

you don't have to give the column a type at all. You can just say create table T1, parenthesis, A, B, C, closed parenthesis, and then you've got a table with three columns named A, B, and C, and you put whatever you want there. That's just for flexibility purposes, I assume. Well, it flows directly out of the scripting language traditions.

You don't declare types for variables in Tickle. You didn't used to do it in Python. I guess you can do it some now. You don't do it in JavaScript. You just say it's a var. Yeah, I mean, I guess some of that leads to, from its scripting roots, from the web development perspective,

which is what Adam and I are mostly coming from, and I think Ruby on Rails wasn't my first exposure to SQLite, but it definitely was one of my first using it more than just on the surface. And there's this feeling, or there's this general, I don't know what you call it, a consensus that it's for development purposes, but when you get to production,

it's foolish to use it in production because it's, I don't want to call it a toy, because it's used in production more than any other thing out there. But I think that sense of it where it will allow certain data in that because your users

will put it in which you didn't expect. I think it's probably where that feeling comes from. Do you agree? I have the same thoughts, Jared. Honestly, I thought that because it's sort of a getting started thing with Ruby on Rails, and as I said, that's my first exposure with it. I kind of, and no downplay, because that's why we have this show, and that's why we have people like Richard on this show to come and debunk big myths like this, because someone may not ever think that SQLite is worth anything, because it's just a beginner, just a starter thing. But that was not exactly my thought, but my thought was that it's just for getting started.

No, it's definitely for more than that. Now, for a website where you've got a lot of write concurrency, you need to move to a client server database engine because you need that server process there to coordinate the concurrency. There's just no way to do that

in a serverless database like SQLite. So for so many things you don't have that concurrency. You've just got a single actor or one or two actors accessing at a time. And it's not a factor. And SQLite works great in those situations.

It's where you get into big concurrency that it breaks down. Yeah, I mean, you just take the example of what we talked about earlier, where it's inside of this Skype client. Well, I have my own, and you have your own, and Adam has his own. And there's no reason to have a server in that case. It's completely usable right there. So that plays to its strength. So again, it's the right tool

for the job situation. And with websites. One of our sayings is that we don't compete against Oracle, we compete against Fopen. I like that one too. You got lots of good taglines.

Here's another aspect of it that I think is a technical thing, which is probably pretty poignant considering recent events in the greater JavaScript community with dependencies. It doesn't have any. So listen to this quote from the website. All of the deliverable code in SQLite has been written from scratch. It goes on to talk about how there's no third-party code.

Everything is in there. There's nothing that has a different license besides the public domain, which again we'll get into. Tell us about that decision. Well, it does relate closely to the public domain, which again we'll get into. Tell us about that decision. Well, it does relate closely to the public domain thing. I'm just one of those people, I don't like dependencies. I really like to statically link things because with dynamic leaking,

you just never know what version of the library you're going to link in at runtime. And if you're delivering many copies of this, there will be some users who will come up with a bad version of a DLL or a shared library, and then they'll call you for support. And it's really hard to debug if you don't know what they're running. And then, yeah, with upstream libraries and that sort of thing, there's a dependency there that it just makes life a little bit harder. Sometimes it works better to build your own tools. I know a lot of people say that you should never reinvent the wheel.

The hacker credo is steal the code, don't rewrite it. But, and I understand that point of view, but I've always been sort of the person that I'm more willing to write it myself. So rather than find a different SQL database engine that would work better than Informix, I just wrote my own. And the text editor that I use to write SQLite is one that I wrote myself.

Really? It is. Is it published anywhere? No, I think I put it out there a couple of times. It's nothing. It does what I want. I cannot imagine anybody else. Yes, it does what I want, and I cannot imagine anybody else finding it useful for anything. thing but the uh you know rather than use bison or yak for the uh language parser in sqlite i wrote

my own uh parser generator called lemon when we needed to beef up the development processes for sqlite and and and put more rigor in them it was originally using cvs because in 2000 cvs was just stayed cutting edge state-of-the-art stuff. That was really cool. But we needed to move something better. And I looked at Mercurial and Git and they weren't going to meet my needs. And so rather than try and work around those problems, I just wrote my own version control system. So that, I just tend to do that a lot. I tend to write my own stuff more than other people would. That's either a failing or a virtue, depending on your point of view, I guess.

When you mention your own version control, that's Fossil, correct? That's correct. Yes, so Fossil SCM is a tool which Richard has written and another one that we've had people request us actually to talk to you about. We don't have time for it in that call, but we might have you back to talk about it. Interestingly, it does have a dependency, which is SQLite. That's right.

I guess it depends on if you're writing a library versus an application. So all of the SQLite source code is managed by Fossil, and Fossil uses SQLite. And you can ponder that recursion at your leisure. Right. Well, it shows you can depend on yourself, too, that you're internally trusting, not externally trusting. We eat our own dog food, absolutely.

Do you think that this mindset you have with writing your own stuff, because now, as we talked about the barrier to entry, right? Today, I think people tend to lean on others because they're sort of bootstrapping themselves into developer world. They didn't go to school or they typically didn't go to school or they did go to school. It's like an eight-week boot camp or something like that. And it's not to downplay that whatsoever. It just means that they don't have the breadth of experience that you do. Well, yeah, they've got so much more to learn than I had to learn in 1977. There's just so much information out there.

And I've been doing this for so long, and it seems natural to me, but I've been doing it for decades. And I've been constantly learning that entire time. And so, yeah, I don't know what – if you're starting out, you've got to build on what other people are doing. I don't see any other way to do it. How would you start? Say you wanted to become a software developer with zero knowledge today, and you were looking for a starting point in. What would you try?

Well, I would probably try the wrong thing. But if I were to advise other people, one thing that I see is everybody's flocking toward integrated development environments. And I want to encourage new developers to get real familiar with the command line and the shell prompt. If you're on Windows, well, that's fine.

Certainly get familiar with Bash on Unix. I see so many people coming out of school and they're new programmers and they cannot operate without pointing and clicking. And somehow that limits their level of understanding. I make the analogy of if I go to a foreign country where I don't speak the language, I can go to the market and I can point at things and we can make hand gestures and I can, you know, buy food, eat and stuff. but I cannot start a business or carry on a deep conversation about the meaning of life and the relationship of God and man.

For that, I have to speak their language. And it's the same with computers. If you're just pointing and clicking, that's great if you're a casual observer, if you're a user, and you don't want to spend the time to learn this foreign language. But if you really want to get deep, you've got to learn the language. And once you do learn the language, it's much easier to communicate that way. Much easier.

So I encourage people starting out, go low level and do things from the command line rather than depending on point andand-click GUIs. Well, some good news that came out of Microsoft's Build Conference today is that they have partnered with Canonical to bring Bash to Windows. I saw that. I am so psyched about that. I was thinking right after this podcast, I'm going to figure out how to get that on my Windows machine over here.

I'd seen something, Jared, in our tweet stream, but I hadn't caught that news yet. We tend to stay timeless with our shows versus timely, but why did I do this? I can't speak to their motivation. Why?

It's the new Microsoft. They're embracing open source, they're embracing Linux, they want to be more developer friendly, and so they're having kind of a first party user mode Linux executables in Windows 10. I haven't read beyond that. So all I saw was a Verge article, but everybody is pretty excited just about,

they have purpose to bring the bash command line to Windows and not in some sort of virtual machine like first party user model. Well, that's funny too because I'm looking at our tweet stream because I haven't opened up tweet box on this show with you, right? Recording this and there's one that says, as a response to our tweet, April Fool's. I know that April Fool's is just around the corner, but not that kind of corner.

No, I think this is real. This is real. We've got to be careful on April Fool's Day not to be, because I know we tweeted that out. We need to make sure that our stories are legit. But I'm pretty sure this one's real. We've been there. We've done that. I've got a headache on my face.

Okay, so we've covered the technical, some indecrecy. We could probably go deeper into that, but we are inside the time limit. I definitely want to get to your take on licensing. So you started off GPL, but that sounded like because you had a dependency that was perhaps GPL back in the day. Correct. For a long time it's been public domain. And I think the piece in The Guardian, which said basically the subtitle was Richard Hipp's database is used by some of the biggest names in IT, but he has not made a penny from it. And its whole emphasis was this aspect of you giving it away, not

just GPL or even LGPL, but like this belongs to the public. So tell us your decision behind that and then we'll probably take a break and then we'll talk more about it on the other side. Sure. Well, just to correct the Gardner article, it was correct when it came out, but we've got a business built around this now, just to be clear. And they did mention consultancy in that.

So that was 2007, but it was just, it piqued their interest. Yes. So when I ditched the dependency on the GPL, the GDBM library, and wrote my own, it was all my code at that point, and I could put whatever license I wanted in it.

And I thought I wanted a much more liberal license so people could just toss this into their application and not have to worry about it. And I looked at the BSD license, and I at the MIT license and I thought, you know, really, what's the point? Why not just say, hey, it's public domain and put it out there? And that's what I did. And that was a little bit of a tough decision.

That's kind of, you know, letting your baby go because you're casting into the wind and hope that does well. Also, at the time, I did not realize, having lived my whole life in the United States, which is under British common law, where the public domain is something that's recognized, I did not realize that there were a lot of jurisdictions in the world where it's difficult or impossible for someone to place their works in the public domain. I didn't know. So that's a complication.

And for that reason, some companies started saying, hey, we need to buy a license anyway. And so we made this product available. We'll sell you a license for SQLite. And we do our best to talk them out of it and explain they don't need this. But for a lot of people, it's cheaper to pay the fee and get the license than it is to convince their lawyers that they don't need one. So that's one way that we have for making a little bit of money to fund continuing development. And it's more than just a license, though.

It's also a warranty of title. The document we send them represents and warrants that every byte of source code is an original work that we control, came from us. In other words, they're not bits and pieces that we've just pulled off of the internet that might be contaminated with licenses that you don't know about. And if you are doing a large project with potential legal exposure, you want to make

sure that you really can use this without incurring possible lawsuits down the road. Maybe Google wishes that they had thought more about Java before they put it in Android. And because they don't want 10 years down the road, if their product's a big hit, they don't want somebody to come back and say, oh, that SQLite actually had stolen some code from us, and so now you have to pay a license to us. Right.

So just to protect their portfolio and their product, a lot of companies are eager to pay us that money. So that works well. That's nice. It's a nice little supplement of income so I can hire some people and we can work full time on SQLite and not have to do other things on the side just to keep food on the table. That's excellent. I think we want to drill down on that a little bit more because you have the license. You also have an encryption. You have some extensions that you sell. Interestingly, there's even a test harness, which seems to be an annual thing. These seem to be like their products that exist because they've been specifically requested, right?

And they're not your guys' ideas. But let's hold that off here, Richard. We do have to take our final break and we'll hold that for the close of the conversation. So we'll be right back and we'll talk money and licensing next. All right, we are back. And Richard, before the break, we were talking about the public domain aspect of the project, the fact that you do sell licenses, because oftentimes it's cheaper to buy a license

than to convince your lawyers that you don't need one. And also because public domain isn't recognized in some provinces, which I was unaware of as well. Yeah, I was too. I'm sure that one took you by surprise. As I mentioned, these seem like they're on-demand type of things. They don't seem like fully fleshed out product ideas.

And I would be questionable if you could make a living off of what you have here. You also have some support from sponsors. Can you talk to us about all the different ways that you guys stay afloat? Right, so back in 2007 when Symbian was starting to put SQLite in all their phones, they came to the same realization.

At that time, it was just me working on it pretty much. Dan was helping me sell on a part-time basis, but they realized that if this is a critical part of their infrastructure, they needed to make sure my business was sustainable. And so they said, look, Richard, you need to set up a consortium or a foundation to provide support for you developers so that you can work on it full time. They told me they wanted to increase the bus factor of SQLite. The bus factor being the number of people who have to be hit by a bus to cause all development to stop. And they were concerned about that because I was kind of the only person at the time.

And so we started working out this idea of the SQLite consortium, which would be companies that would sponsor us to keep the project going. And somehow Mitchell Baker at the Mozilla Foundation got wind of this and said, oh, Richard, let me show you how to do this. And so I got with her, and she really – she knows how to set this up. And we rewrote everything according to her specs and started the SQLite consortium. And so companies, which are typically large companies that really depend on SQLite as part of their product, they just pay us an annual fee. We do support them. They can always pick up the phone

and an engineer will be on their side as quickly as possible if that ever comes up. But really the purpose of it is they want to make sure that the product is sustainable and continues to be supported and doesn't become orphanware because they depend on it. And we charge them a substantial fee, but from their point of view, it's half of an engineer.

So it's cheap for them. It gives us working capital and allows us to just go and operate and really constantly improve SQLite. in those funds, we've done dramatic improvements in reliability and performance because we have the freedom to work on it constantly all the time. So the SQLite consortium is what's really allowed us to keep SQLite going and to keep it

current and real and vibrant. We started working the other products you're right are a one time thing for the most part the encryption extension when people buy the encryption extension we actually just give them a password

so that they can log into our version control system and it's forever and they can download the source code whenever they want and whenever they need it and constantly stay up to date they don't ever have to renew. We sell support contracts for people, but that's not a big moneymaker.

Our bread and butter is our patrons, our SQLite consortium members. It seems to be opposite of what I would expect, though. I guess as a foundation, as a consort sourcing, you expect something like that. I mean, a lot of open source businesses build themselves around some sort of support or proversion. And instead, you've built it on the goodwill. And I guess that's what the membership is really about. It's about, as you said, a patron model versus a support driven or support sales model or something like that? It really is more of a patron model. People have built businesses around an annual support subscription or something like that. To make that work, I think you have to have a sales staff. Yeah. Complexity.

Well, and yeah, and plus I wouldn't know how to do that. And then one of the reasons people really like working with us is we are a 100% engineering shop. There's no sales talk. When you talk to somebody at our company, you're getting direct, no-nonsense talk with an engineer. You're not talking to salespeople. And that's different. And that's not to knock the sales aspect of things. I understand that. And you have to do that on a lot of occasions.

And those people work really hard. But we're just doing it a little bit differently. I said, you mentioned, or maybe it was during the break, you quoted something from the article about how people tell me I could have made a lot of money on this if I'd had any business since. And I believe them. I probably could have. If I hired salespeople, I could probably make a lot of money and get rich. But you know what? We make enough. It's not a lot. I'm driving a 10-year-old Civic, but that's fine. That's all I need. Everybody – I'm getting off topic. Everybody has this threshold where they get enough money.

When you have nothing, you want to make money. Everybody wants that. But at some point, you get enough money. So, okay, now I've had enough money. Now other things become more important. Family, free time, working in the community, charities, whatever. And that threshold is different for different people. Some people, they don't reach that threshold until they get into the billions. Other people reach it at a few tens of thousands. Me and the people that are on the team, our thresholds are kind of low.

So we're okay. I'm not sure if you mentioned it directly, but just out of curiosity, how big is your team, your company? What type of a group of people are being supported by it? Right now we've got three other engineers working on it with me. Dan Kennedy, he's Australian.

He's been with me for a long time, and he's written major portions of it. I mean, he's been instrumental in doing all of the full-text search and the R tree and lots of other things like that. Joe Matashkins in the Seattle area, and he handles all the Microsoft ends of things, which is an enormous, enormous job. And then we've got Mike Owens, who wrote one of the books about SQLite. Right now, Mike, he's full-time employed with somebody else, and so he's just handling our website and taking care of all of that and making sure that all that works smoothly for us. But he's still on the team. We did have Shane Harrelson, and he's the guy that invented

the amalgamation. SQLite is delivered as a single great big source file. Almost 200,000 lines of code, but that makes it really convenient to use because you've just got one source file that you drop into your application and compile it with the rest. And then you've got a database engine, but we don't edit that one great big

source file. We have hundreds of individual source files and they, they get pulled together in just the right order to, um, to, to build this amalgamation. And Shane is the one who invented that for us. He, um, he, uh, took a job with another company. He's not with us anymore. We still hear from him from time to time. He's still a big user. So that's the whole team. It's a small team. It's interesting to hear who's involved based on the fact that this is what keeps you, as you said before, employed. And so SQ Lite having this patron model,

it's interesting to hear who's involved because becoming a member, supporting this consortium is supporting those folks, still there or not, in some sort of way to kind of keep this thing doing what it needs to do. Exactly. And it's been a really, really, really fun journey for us. It really has.

We hope to keep this going for a long time yet. Well, since you mentioned a long time, do you have a plan? Like you said in the breaks, you got some sort of long-term plan, but you didn't go into detail. But what's the plan for SQ Lite? What can those who use it now expect 50 years from now? Well, at some point, surely some new technology is going to come along, and SQLite will cease to be an important thing for new products. I don't know when that's going to happen.

It could be next week. It could be in 20 years. I just don't know. For example, people are really excited now about the new persistent memory that doesn't lose power when you power down. And there are various types of that. And that could be very disruptive to the whole database industry. But because SQLite is so widely used, we expect it to be used in legacy for many, many years. And so a few years ago, when Airbus had contacted us and they use SQLite in the A350 avionics,

they asked, we need you to support this for the life of our airframe, which is 40 years. So we said, oh, sure, we'll support it through 2050. So we sort of set up the company with the idea that we're going to try and keep it going through the year 2050.

The expectation is that at some point, the usage will begin to die down and our role will become more of just maintained legacy. But we anticipate keeping it going for another another what is that, 34 years? Why 2050? Just because it's a nice round number? Well, that's 40 years from the date that Airbus contacted us in 2010. And they said their life of their

airframe was 40 years, so that's where we came up with that number. That's a big, big airplane. I don't know if anybody's ever seen that thing in pictures. It doesn't do it justice, but to see it face-to-face, it's ginormous. I wouldn't imagine being the pilot flying that thing, let alone being the database powering it. I don't know what we do inside the – it's the A350, not the A380, by the way.

Okay, okay. That gives a little slack to you then, but that's still big. It's still big. I don't know what we're doing there. I don't think it's in safety-critical applications. I think that they use it to log maintenance activities so that when the airplane lands, the ground crew can just get a printout of what needs to be fixed.

Right. On that note, I mean, is there any other really interesting places where this database is used? I mean, is there any other really interesting places where this database is used? I mean, that's something I didn't expect to hear on the show. So, I mean, is there anything else that any of the places you've seen it used or know about its uses that's just like, wow, that's interesting? Or even ways it's used? You know, if you'd given me a little prep, I could probably give you a list. I hear about this stuff all the time. But nothing else comes to mind. Airbus is a pretty cool thing. That's not a flat question because the Airbus example threw me for a loop

because I didn't expect, I mean, I guess it would make sense, but it's such a well known aircraft that that's a big deal. Sure. Bloomberg, the news agency, and the biggest provider of Wall Street data in the world, all of their stuff goes through SQLite, or at least our parser. They took the front end of SQLite,

the SQL parser and code generator and execution engine, and chopped off the data storage engine and glued their own enterprise scale, massively concurrent, a multi-data center storage engine on the backside. And that's all of Bloomberg goes through that, which I think is pretty amazing. Since you've been in open source for a while, maybe you can help us kind of look back at the last couple of decades. What are some of the most interesting or biggest changes you've seen happen in the community, in open source, in the way software is delivered throughout the years? What are some of the most interesting things that you've seen happen that really got you excited about where we're heading?

Well, back in the old days, they didn't call it open source. I guess it was Bruce Perrins that invented that term. How long ago was that? Was that in the late 90s? Back in the day, we were just handing a software around, and we didn't have a word for it. And so even just coming up with a word, open source, that was a huge step. I think it was Bruce Perrins that came up with that, but we'd have to research it. Yeah, it says that he created the open source, that was a huge step. I think it was Bruce Perrins that came up with that, but we'd have to research it. Yeah, it says that he created the open source definition.

Yeah. So, yeah, that was after Linux started the Linux kernel. So, you know, back in the 90s was when that happened. So that was big. And even, think about it, when SQLite got started, we didn't have broadband like we have today.

Remember one of our early patrons was AOL and they were still sending out CD-ROMs to your mailbox that, you know, get online for, what, $5 a month or something with your dial-up modem.

That's the way the world rolled when this whole thing started. And we lose sight of how much the world has just changed in these past 10 years. Now, everybody has broadband. It's just taken for granted. Now, everybody has a cell phone. When SQLite first came out, there were cell phones, but we didn't have the smartphones that you have today.

That's so wild to think about that. I was just on a separate podcast, not on this one, being interviewed. And I was in retrospect talking about how the iPhone was the very first cell phone I've ever owned because I grew up not very well off. I grew up poor. And so to finally make enough money to own a cell phone, I actually worked for people to get a cell phone rather than buy my own. So I just sort of leveraged that as long as I could. I guess I was just sort of hedging my bets against it. But man, it's crazy to think about when cell phones became prolific, and that's an interesting fact there.

Yeah, and the iPhone just revolutionized the world. It's design, the fact that you had the complete screen, or it had the LCD covering the whole screen, that was a radical idea at the time. I was able to see some of the early prototypes of Android

phones, and they all looked like BlackBerrys with a little tiny screen at the top and a great big keyboard. But when the iPhone came out, that all changed. So now everybody has a smartphone. It's ubiquitous. Everybody has broadband. Wi-Fi is everywhere. And this has opened up a communications revolution.

It's really easy to go online and download whatever code you want. It's really easy to search. We have Google, and people take Google for granted, but you just type things into your search engine, and you can find whatever you want instantly and 20 years ago you couldn't do that at all and that that has completely changed the world and but we've become so you we do it so much every day that we we now take it for granted i guess since we have you thinking about the the future to a degree um because you're an old hat and you've probably got a long list of things that you're really interested in, I'm curious we have a couple closing questions we tend to ask on this show. Sometimes we omit them when we run out of time, but I figure that this one at least is a good

fit for you. So the question is what's on your open source radar? But you can frame it however you like. It could be a technology radar. Given your expansive history, you may rather just write it yourself rather than use somebody else's. But for the odd day that you want to use somebody else's stuff, what's on your radar

that you would like to play with if you had a free weekend and you didn't have to do anything with SQLite? Of course, I wrote the version control system Fossil, and I learned a lot about version control with that. I'd really like to try to follow a system that improves upon it and is kind of a git killer. And I've sketched out a design, but I've had no time to work on it.

I've often said that email, it's everywhere. Everybody depends on it. But setting up an email system is really hard. And the world needs a really simple to use email system that you just drop in place and it just works. And that would be fun to work on. I would definitely say something like that. I mean, because, so you're the right kind of person to do that because one, you're not afraid to just jump into a place where you're not exactly the database guy, as you've said before. So you're comfortable with being in touchy territory. Yeah. And it's true because everyone leans on some sort of cloud service to do it. And everyone I know somehow leverages either Gmail or Gmail for businesses

or Google for businesses or whatever, and that's the way to do it. And there's a lot of people who are ruling their own solution using Ansible or something like that, that they're using somebody else's known ways of doing things to deliver something

that's their own solution to the server. But I would agree with that. However, I have zero technical ability to follow there. I will be a user. I will be a user for sure. Well, I've been saying that for years. I haven't found those free cycles to do that yet. So Jared, he also said something else that piqued my interest

for the future show that we have with the Moan Fossil is that he said, get killer. Can you believe he said that? Kill it. Do you believe he said that? Kill it. Do you mean it, Richard? Git has been a lot of, it's done a lot of good, but I mean, you look at it, Git is the version control system

that everybody loves to hate. I have an extensive collection of people ranting against how awful Git is. And in truth, they're mostly right. And yet we continue to use it. That amazes me. I don't understand why that is. There are better alternatives that exist today.

And it's not hard to design things that are way better than anything that exists today. It's just a matter of sitting down and spending a month or two and writing the code. So answer this for me then. So we're not going to talk deeply about Fossil now because that's a future show, but to tee up some sort of teaser or interest, is Fossil in its current form a Git killer, or can it be given, like you said, the month or two months of additional work to kind of get there and just sitting down and focusing on it? Is it ready to be that now? No, Fossil, in my

opinion, Fossil is better than Git, but the difference is not enough to overcome the additional learning curve of learning a new system that's slightly different. So, it's just an incremental improvement. It's not a disruptive improvement and i think to really overcome because git has huge huge traction now everybody uses it we have github okay and over to overcome that incredible installed base you've got to have something that is revolutionary well i mean even mccurial has had this problem, right? I mean, Facebook gave it the best name brand as a social proof mechanism to get people to switch,

and yet no one's switching in droves. Nobody's switching in droves. So it's a hard problem. And I've got a list of features, I think, that would go a long way toward getting to the Git killer. But it's just a matter of sitting down and implementing them. And that takes time. And something like a version control system really has to be right.

Because if it messes up and you lose source code, people get really upset. Yes. Yes, definitely. Well, that's definitely a teaser for a future show on Fossil. But I guess before we close, is there anything else you want to mention before we tail out? No, I think we've covered a lot of stuff. We could talk for days on SQLite about technical aspects, but in a one-hour show, I think we've covered a lot of ground. Well, it was certainly interesting to hear your entrance into software development technology. I hope the listeners can appreciate how pivotal that kind of story is to have on the show. It's so interesting, too, to have someone like yourself with such deep and rich history and also unaf up to that and be inspired by that and share that back with all the listeners who love this show, that's so awesome.

And I thank you and Jared thanks you, of course, too, for your time to come on the show and share that. And then also what you do with giving back and public domain and all the things you cover in the show. So that's phenomenal. So we'll leave it there. Thank you for having me. Y'all have been great. I really appreciate you.