Dear Richard, Dear SQLiters, Thank you, Simon, for sending the link. I would like to offer several comments on the podcast.
1. Why SQLite is popular. Instead of describing how I selected SQLite to solve our DB needs, I will recount story of Sony, its introduction of transistor radio that I read in Innovator's Dilemma by Clayton Christensen. (Very good book and author, I recommend.) First transistor radios were poor in sound quality compared to those based on vacuum tubes. But they were lite (misspelled intentionally), and small. They were bought by teenagers, because they were cheap and portable. The big radio manufacturers did not even consider transistor radios as competitors because traditional competition was based on sound quality, not portability. Over the years, transistor technology improved and all vacuum radio manufacturers disappeared. Richard said: "We do not compete against Oracle, we compete against fopen()." This is true, just like transistors. But SQLite displaced many big DBs and now Oracle etc have smaller market share. If I apply ideas of Innovator's Dilemma, their market share will continue to shrink. (I am not an MBA, I am a physicist, could be wrong but looks reasonable.) 2. Job to do This is related to 1, and to ideas I read in Clayton Christensen books. Many SQL databases are very similar in what they can do, performance etc. Thus SQLite wins, just like Sony's first transistors, because it does NOT compete with them. It can not handle huge write concurrency or optimize for similar requests over history. Instead, it is easy to install and use. Its column types, affinity, makes SQLite suitable for both relational and entity?attribute?value models. It turns out that many "customers" simply do not need the functionality and optimization offered by big DBs. Instead, like teenagers, they need portability, ease of use and set up. This solves the job. Big DBs are overkill for such "small" jobs, requiring a lot of learning and expense. But there are a LOT of these small jobs and SQLite solves them admirably. 3. Code rewrite, robustness, licensing Code rewrite or static linking make the final product more robust. Robustness simplifies support and debugging. Robustness attracts users. We all want OUR thing to work and if our thing depends on SQLite, we want SQLite to be robust. And thus, the SQLite licensing. 4. Fossil and other in-house software Writing your own code is driven by the lack of needed features in available products. In the beginning, Ford had to build its own metallurgy plant to ensure quality of metal. This and 3 above are integration of what is not good enough to make it good together. Over the years, metallurgy industry matured and Ford closed this division. There are many other aspects in the podcast that I would like to comment. Even when Richard tells the story and many elements look accidental, they all fit into the timeline of unfolding disruptive innovation. SQLite was and is a disruptive innovation. SQLite is not a toy. Thank you for making it. Roman ________________________________________ From: sqlite-users-bounces at mailinglists.sqlite.org [sqlite-users-bounces at mailinglists.sqlite.org] on behalf of Simon Slavin [slav...@bigfraud.org] Sent: Saturday, May 14, 2016 4:17 PM To: SQLite mailing list Subject: [sqlite] Podcast with Dr Hipp: SQLite history, success and funding Those interested in SQLite might like to listen to <https://changelog.com/201/> Play on the page or download as an MP3. Unusual information on Dr Hipp's early career, SQLite history, HWACI, and how come SQLite is free but the developers still manage to afford food and somewhere to sleep. Question to ponder before you listen: Many of you know about tiny devices which incorporate SQLite but what do you think the biggest one is ? Simon. _______________________________________________ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
