Domen Kožar: Alright. Well, there’s quite a lot going on behind the scenes, so let’s go through each step. If you say “nix install firefox”, Nix will first of all try to see where you’re trying to install Firefox from… And by default, it will use Nix packages, which is the official, one of the sources it can install from. But it can be anything, so we’ll skip that part for now; by default, it will use Nix Packages.

Then there is a top-level file in Nix Packages called all-packages. You can imagine this – you know Nix language is kind of like JSON with functions… So in there you’ll see a key Firefox, and it will point then to a file, which will import that file.

Inside the Firefox file (firefox.nix, wherever it is), there is a description of how to build Firefox. In the Nix language there is a primitive called derivation, which is kind of like the core of the whole concept. In the Firefox case, it will say – you know, there’s a bunch of dependencies, you have to run make with these flags, and a bunch of other things. And this derivation function is really the core of it… And what it will do is it will first go through all of the dependencies and build those, of course… You know, all to the bottom of it, which is something we call the bootstrap, where we build the minimum possible environment. Then it will build the minimum possible environment. Then it will build all those dependencies up to Firefox. And all of those dependencies go through this derivation function.

What happens in there is the derivation function gets a bunch of inputs, which you can imagine as like key-value pairs, essentially… And it passes that to a builder, which is some kind of an executable. By default in Nix all the builders are done in Bash, but you can have an executable as a builder, essentially, and pass all the inputs to it.

This builder, once it will be executed, is run in a sandbox environment; you can imagine this as something like a Docker environment, where it will not have access to the internet, it will be completely isolated from the file system, and so on.

The idea of this sandboxing is, of course, for the build to be reproducible, and only dependent on these inputs. That is one of the core design decisions. And as I’ve previously mentioned, all these inputs are then calculated – there is a hash calculate out of these inputs, and this uniquely identifies how this package was built, and what is the source of this package. So not just the source, the binary of the thing, but also all the instructions for it.

So the builder will take care of the building part, and this is where I previously talked about evaluation and building separation kicks in. When you will install Firefox, it will find a Firefox file, it will evaluate this first… So it will evaluate the Firefox derivation, and then everything up to the bootstrapping bit. And then once that’s done, it will start to build.

[24:14] And the building phase is not that interesting. There’s essentially two parts to it. One is that it will use these derivation files to call this builder, as I’ve mentioned… But before it does that, it will also check with this hash if there exists a binary package for it, and it will substitute it if there is one. And if not, and if not, then it will go and build it.

How that works is that when the package is built, as I’ve mentioned, Nix will put it in the /nix/store/, and then hash and the name of the package, and then everything goes in there. And the same for all the dependencies.

So let’s assume now that Nix downloaded some binaries as a dependency of Firefox, and then it builds the Firefox. Now it just has a bunch of folders in /nix/store, and now it will link those into something we would call file system hierarchy, which is the standard you’re used to in Debian, for example, so /user and /opt, and so on. And it will just layer these things essentially together into something Nix calls profile. And this profile is really just one snapshot of when you installed a package, or a group of packages completely linked together.

So that’s how Nix goes from this global store into an actual file system hierarchy that we’re used to. It’s one big assembling farm, the way to imagine it… This is then how you go through – if you install something, it will install all the packages you had before, and then this package on top of it. So it’s kind of like immutable; you build up these things. That’s how I like to imagine this.

And the same when you uninstall, it will not remove the Firefox from the /nix/store directory, but it will just create a new profile version without Firefox linked in. And this is very typical in memory management, where you essentially just allocate, and then you garbage-collect when you want to. Nix works in a similar way. So then actually deleting packages would be an explicit garbage collect operation, where you go through these profile versions and you can say “Oh, keep just the last one”, for example.

So that’s the garbage collection bit… But let’s go back to installing. Now we have this profile where Firefox was installed in, and Nix will activate it, which means that the specific snapshot of the profile is now the activated one. And these profiles can be stacked one upon another as well, and there is like the user profile, so each user can have a profile; each user can install their own set of packages, and then on NixOS, the distribution, there is also a system profile, which is the actual OS profile, that then represents the environment that you access, and then Nix exposes in a typical package manager Firefox in the path variable, for example.

Abe Heifets: Significantly better. But actually, let me walk you through an example here… And here’s the important part - because it’s not just a question of cost, it’s not just a question of speed, it’s actually a question about making the impossible possible. Something that not a lot of people appreciate is in the human genome we’ve only ever had medicine, FDA-approved medicines for 4% of human genes. And there’s another 16% of human genes that have good evidence implicating them in human disease that we would want to be able to target, and we’ve never been able to target. So this is like four times the entire farm industry is waiting for us to figure out a way to get medicine for those. So there’s huge opportunity. But to do what’s been impossible, you need technologies that have never existed; that’s why we’re out there inventing. So that’s what we’re working on.

Let me give you an example. This is joint work with professor Ron Viola at the University of Toledo, and there’s a disease called Canavan disease. This is an ultra-rare neurodegenerative disorder. If you’re pregnant and you’re doing a genetic screen, it’s one of the things that they test for in genetic screens…

[40:02] Basically - I won’t get deeply into the biology, but you’ve got a molecule in your brain called NAA (N-acetylaspartate). And you have a system that makes it in your brain, and you have a system that clears it out in your brain. And these kids lose the ability to clear it out. So this NAA builds up in the brain, and basically the sheath around your neuron, the myelin sheath starts to degrade, and these kids stop hitting developmental milestones. It can be fatal, there’s really no cure for it, so it’s a pretty tragic disease.

But there was some mouse data that shows that having lost the ability to clear this NAA, if you slow down the synthesis, you could burn the system back into balance, and the mice live a full lifespan. So that gives the idea that we could develop a drug for the synthesis side. But that N-acetylaspartate synthesized is a classic undruggable target, and I’ll tell you why. It’s inside the neurons; so it’s in the central nervous system, it’s inside the neuron, and your brain’s protected by something called the blood brain barrier, so it’s like an armor around your brain. So it’s very hard to get to.

That protein itself is membrane-associated, so it’s stuck in the membrane, inside the cell, and that makes it very finicky to work with, very hard to work with. Difficult to express, difficult to purify… Just getting enough of it to run large experiments, which is - as we discussed - the state-of-the-art pharma today, you couldn’t get enough of the protein. You couldn’t get a crystal structure for the protein. I don’t know what AlphaFold 2 can do, but experimentally, we had no way of designing molecules based on the shape of that protein, designing that monkey wrench which would block up the protein.

So basically, all of the standard doors for drug discovery were closed. You couldn’t run a big physical screen, you couldn’t design [unintelligible 00:41:42.26] there were no molecules drugs, molecules which were known for this protein, so you couldn’t build a machine learning model specific for that protein… Human medicinal cabinets didn’t have anywhere to get going from, to start working on. So basically, all the standard doors were closed, until we worked on it.

So what we did was - with these machine learning techniques, empirically they are more robust, and so you can use distant-homology models; the kind of thing that AlphaFold 2 produces - we can use that, rather than having to have an experimental X-ray crystal structure, an experimental 3D structure of the protein. So we used a very distant protein, a bacterial protein, so separated by three billion years of evolution, and only 20% of the immunoacids were identical, so very, very distantly related… But we used that as a homology model. We screened 7.2 million molecules - and for context, a big pharma company might have 3-5 million molecules in its corporate collection, so this might be twice the size of a big pharma corporate collection.

Out of 7 million, we pulled down to 60 that we felt we’d test, and five of the 60 (so quite a high hit rate) were actually accurate, with the best one being more potent than what you would expect from a physical screen. So that’s not a drug yet; we have to continue working on it… But where all the doors were closed, now we’ve opened the door to doing drug discovery.

Marcin Jakubowski: Yeah, it’s called Factor-E Farm. It’s not a Factory Farm, it’s a Factor-E Farm, where E is the exponential number. It’s about transcendence.

L Körbes: I mean, it did happen in a farm, but I can’t say what it is.

Natalie Pistunovich: It’s all the farm animals in one. It lays eggs, it has wool, it has milk, and it’s a pig.

Rajiv Shah: Like a lot of early folks into data science, I probably have a long, meandering journey… But partly, I started off as an engineering undergraduate. I didn’t wanna do engineering, I went off and studied Law, ended up with a Ph.D. in Communications, where I ended up studying just that intersection between technology and people. It was just really interesting, and solving a lot of interesting research questions… And I used various methods, both qualitative and quantitative methods to solve these problems. At the time, the internet was booming, so there were a lot of interesting questions around that.

I did that for a while, kind of moved out of Academia… I was a sysadmin for a number of years, so I worked in IT, and then this data science thing came around, and I was like “Hey, wait a minute…” I have a bit of a background in math, and my social science background had taught me how to ask interesting research questions and kind of probe them… And then the nice thing is Andrew Ng made these wonderful courses, and I was able to kind of skill myself up on some of the newer algorithms and approaches that I hadn’t learned… So that was kind of my introduction into data science, and landed my first data science job at State Farm. I worked there for a couple of years, I went over to Caterpillar, I worked there as a data scientist, and now I’m over at DataRobot.

Adam Stacoviak: [36:29] Right. Do you know much about how much caffeine you get out of the beans? Starbucks isn’t saying – maybe they are saying, I don’t know; I’m assuming that they’re using the same kind of bean, to some degree, that everybody else can get off the shelf, except for they probably own the farm… The bean being the coffee bean; it originates as a cherry, it has a process to become the bean that you can actually grind up and turn into coffee by doing a process of [unintelligible 00:36:56.19] and all this stuff to get the coffee out of it, whatever - all that science; you may know more about it than I do. I’m just speaking as a coffee geek. But the point is that there’s ways you can extract the coffee out of the bean, that extracts maybe more of less caffeine. Are they just doing a process that gets the maximum amount of caffeine, or is it just by nature that espresso is naturally more caffeinated?

Darren Murph: Well, I caught a rural pocket of North Carolina home, and I love it. I’ve been to all 50 states, more than 50 countries, but this is still home… And you’ve gotta fight hard to stay here, because there’s a lot of farm animals, and farms… And pretty good internet, believe it or not.

Daniel Whitenack: But then there’s also your device, and maybe you’re running at a farm, or maybe you’re running at a factory where the connectivity is not that great, so it’s a connectivity to the cloud thing… And then I hear like a third set of things, which is like latency. You’ve got your algorithm at the edge, and it’s really fast, and you don’t have to wait for things to come back from the cloud, or whatever… So from your perspective with clients, what are you seeing as the driving factor there?

Jason Warner: No mistakes. And it was an interesting period of time… And how I got into tech - I like to tell the story - is I fell into it. I was not destined to be in tech. I grew up in farm country, Connecticut. My grandparents were farmers, my parents were farmers; my parents escaped farming to become other things. My dad was a construction worker, and my mother was a typing teacher who went on to become a high school teacher… I fell into tech because in my high school IBM was in the town, they wanted high school co-ops… I applied because my auto shop teacher said I should, because I was the only kid that he knew that didn’t have a computer and/or a car… Whatever I’m supposed to say in that scenario where you live in a very rich town, and you’re not that same thing.

IBM basically said “You don’t know anything about computers? Great. You just carry these things around. But you’re the type of kid that should get this job, because that’s what we’re after here.” So I kind of fell into it.

So to just go from there, in the mid-‘90s to a 7,5 billion-dollar transaction that you’re primarily the architect of is kind of amazing. There’s an emotional high that comes with that, and there’s this weird kind of other side of it too, which is like “Oh wow, I’m 40…” at the time, I think it was…

Adam Stacoviak: Very well spoken, very well spoken. There’s another one in the Bible that basically says “To plow a straight row you can’t look back.” So if you’re trying to go to a certain point, the analogy essentially is – and obviously, somebody who would be gardening or developing their farm, they’re gonna be using a plow to make straight rows for their planting, for their process… So in order to make that row straight, you have to have a vantage point far enough in front of you that you’re fixated on it, because that’s how you keep the plow straight. And if you’re constantly looking back - well, you’re not gonna plow a straight row.

Adam Stacoviak: [47:41] Okay, so… Slight back-story on that, too… So Wynn and I both met this guy named Josh Copher, who was starting a nonprofit. He actually met Wynn first. Wynn and I were both freelancing, as I mentioned, and doing The Changelog podcast as a hobby, fun thing just to do… And when Wynn was building his team for Pure Charity, this nonprofit that Josh Copher was forming, to be a place for nonprofits to coalesce, to get information on how to best fundraise, how to lead their charges, how to unify their followers, their supporters (for a lack of better terms), Wynn was like one of the first picks.

I was the second hire after him, so I guess I was the first pick… He was like “Adam, do you wanna do this kind of thing?” So next thing you know, we’re working for this nonprofit called Pure Charity. Wynn was CTO, I think I was UX designer, or something like that; I don’t remember what my title was. It doesn’t matter. The point was we were just sort of like fleshing out our careers a bit more, and about two years pass and the majors call. Wynn is in the farm club, at Pure Charity, the majors, GitHub calls and says “Hey Wynn, do you wanna come out to San Francisco? We’ve gotta talk to you about some things…”

So long story short, he got called to the majors. He couldn’t say no. We both loved what we were doing at Pure Charity, but he couldn’t say no to it. And like any podcast, it’s just a hobby. You only have so much love for it and so much time for it; when you have family, you’ve got your career, you’ve got other things… So Wynn was like “Hey, I’m out of time, I just can’t do this anymore.” I think that was around September 2012. I was kind of bummed. I’m like “Hey, I get it. I don’t have a lot of time for it either…” And then I sat in this sort of lull for a while, just thinking like “You know, it’s not worth much, but would anybody wanna buy it? Should I keep it going? What should I do with it? I know what it means to so many people, and what it could mean if we just keep it going…”

So I was just really in this whole space where I was just questioning whether it made any more sense for me. Because I’m definitely more on the design, front-end side than the developer side… And Jerod has to remind me all the time to drop my impostor syndrome and say “Dude, you’re a developer…”, because – even right now, I feel less developer than I had been before, but I was always more on the front-end, user experience, sort of like biz dev side of things, relationship side of things; how it should look, how it should function, how can we deliver it… Than the follow-through, that the doing part of software. And I’ve worked with great people, but it’s just not where I shine. I can do it, but I shine better in other areas. So I was like “Am I an impostor by just keeping this thing going? What can I do?”

Daniel Whitenack: I was just thinking while you were talking about it - the application is definitely interesting and valuable, but I also think it illustrates… I get asked all the time, and maybe you do as well, like “What should I start working on to get into machine learning, or get into AI? What kind of problems should I start looking at?” And I think the best thing that you can do is start working in an area where you have some connection or where you’re passionate about. For you, this was a connection between what you studied at university and worked on in research along with your family, in engineering, along with this hobby farm, and the connections that you had with the veterinary school… So it made a lot of sense to go into that vertical.

That’s what I think people should consider - just try something out that you’re passionate about, because those are usually the things that you would stick with long enough to learn and to experiment and to level up.

Yaw Anokwa: There was no Twitter when we started, so I think it’s [unintelligible 00:27:27.07] From my perspective, and I think the early founder perspective is that a lot of the folks that we were working with in the very early days didn’t necessarily have technical expertise. The user that we’re dealing with is maybe a health organization who doesn’t have a lot of funding; the people who are going out to collect the data are maybe a subsistence farmer who hasn’t at that time seen a smartphone before. So you’re given – I think at that time the initial devices were $600. We gave $600 devices to folks who don’t have any experience with smartphones.

[28:09] Some of the early problems that we were running into are, for example - and this is a podcast, but you should look at your hands, and if you feel your fingertips, they’re like these soft, squishy fingers; and those work really, really well on smartphones, because you don’t have any calluses. If you do have calluses, if you work on a farm every day, your fingers don’t really work on touchscreens the same way. Probably either have contacts or glasses, most of our early users didn’t have corrected vision. So that’s sort of the user base that we’re working with - organizations that don’t have a lot of technical capacity, users that aren’t very technically experienced. So easy was the only way that we could ensure that folks would use the tool.

So we spent a lot of time - and continue to spend a lot of time - in the field, working with folks, just watching how the user stops when making those adjustments.

Easy to use means that the average country office or the average person who’s doing the survey can design the surveys and get them onto the device, an enumerator is how we call the people who collect the data. An enumerator can take the tool with a very little amount of training and can go out and collect the data. So that’s sort of the “easy to use, easy to try” part.

The scale is really critical, because a lot of these projects, once they get going, they generally have a ton of momentum. I think at this point, if I look at the mobile app, over the last year we’ve had about 2.5 million users use it, and a lot of those users are in Nigeria, or India… So these projects start very small, but they scale up very rapidly, where they have thousands of people on the field, collecting tens of forms a day… So it just get really big, really quickly, so we wanna make sure that the software, while it is easy to try, that once you ramp up and once you go to scale from your pilot, it just kind of keeps working.

And then modification is also really important, because you can’t predict everything. We’ve never wanted, especially since we were just grad students, working on an out-of-town, very small project, we didn’t want to be the blocker on some large project or some small project. If you wanted to take the software and it wasn’t what you wanted, you could just take it and modify it how you see fit, and get your work done. And all these things – it’s been good and bad. It’s been good in the sense that our focus on ease of use, with a little bit of flexibility, has gotten the software to really get out there, and a lot of people use it… But it also made maintaining and evolving it also a nightmare many times.

There’s an old xkcd comic where there’s a guy who’s fixed a bug, and a user complains that “This bug is critical to my use case.” I think the bug is something like “My fans go up to 100%.” So I fix this bug, performance is back to normal, the fans don’t pick up anymore, and then somebody writes in and says “I use a temperature sensor on my computer to run this command, so you’ve broken my workflow” Just add up. A lot of ODK is like that - there’s many things that are easy to modify, and easy to scale, but the process of maintaining and evolving the software sometimes adds up. But that’s just software.

Jerod Santo: The farm league, exactly.

Jennifer Marsman: Yeah, great question. In particular on the Ai for Earth space, a lot of the problems revolve around computer vision. A lot of things just seem to reflect, “Okay, given this data…”, maybe there’s cameras in a farm, or something, and we want to recognize pests on leaves, that sort of thing is one example. Or we’re trying to recognize in camera trap – I should mention, I haven’t defined camera trap… What that means, for those who aren’t familiar, is mounted cameras that are usually enclosed in water-proof casing, that may be mounted in trees, or other remote places. We’ve worked with snow leopards, for example, and those guys are so elusive, they’re so quiet, they’re so hard to spot…

There’s one researcher that devoted his life to snow leopard research, and he was up in the mountains, living in the area, and only saw a snow leopard twice in 11 years.

Jerod Santo: That was very, very cool. And lots of different uses for developers. Like you said, CI, you could have a build farm, especially if you’re building for iOS… You can off-load your compiles and different Xcode things to Mac minis. Of course, there’s live performances, you could use them for your home media server… Of course, the Apple TV plus Plex may have rendered that – or could you just run Plex on your Mac mini, Adam?

Eryn O’Neil: Very no. When we first started dating, I was like “Okay, just so you know, I’m not getting married for five years. That’s not happening. If that’s a problem for you, I’m saying it this early because I don’t wanna presume that that’s where this is going… But I wanna tell you, if that’s a problem for you, you should leave, because it’s not happening.” And he was like – he basically always thought he’d be married by 26, with babies, and we started dating at 25 or 26… So I think that partly for him, he had to be like “Okay, well, I guess I have some time to kill.”

So it has been a little frustrating for me, because he is not naturally the kind of person that has thought about what is his career gonna look like, because family and that sort of thing has always been so much more important to him, and he just sort of was like “Well, I’ll get a job. It’ll work.” Whereas I have been thinking about college since I was in fifth grade… I’ve just always known that that was my deal, even though only one of my parents even went to college. I grew up really blue collar, but I was just like “I’m a nerd, that’s what we do. We go to college.” So I’ve always been super-focused on “I’m gonna succeed, dammit. I’m very ambitious in that way.”

There have definitely been moments where I’ve been like, “Well, you need to figure some stuff out. Joe, you need to be your own person, and I’ll be over here while you’re figuring that out, that’s cool, but you don’t get to just say ‘Family’, and that’s your whole personality. I’m not standing for that.” We clashed, for sure, especially when I was like, “Well, I’m gonna live in the city. I’m gonna never live in the suburbs, and I’m gonna never live in a rural part of town, and we’re never gonna live on a farm…” and he was like “Oh, okay…” And sometimes I’m like, “I don’t know why you stayed, but I’m glad you did!” [laughs] So it worked out. Now it’s all compromises.

You can walk into a relationship and be like “These are my criteria. These are my deal breakers, these are my boundaries, this is what I want out of life”, and interacting with another person like that makes you realize that there are some things that are maybe more negotiable than you realized.

We came to these decision points where it was like “Well, I want A, and B is the thing that has to happen for this relationship to continue.” And five years ago I would have told you that anything less than A would be compromising. Or not compromising, but like selling out; it would be selling myself short, it would be not giving myself the fullest life I wanna live. Now I’m realizing that in the face of, you know, this life we’ve built, and this relationship that we have, and you’re pretty cool - actually that’s a big thing to give up, but I’m gonna do it and I’m fine with it.

So I think both of us have had a series of those, where we had these moments where we just had to very consciously be like “Yeah, we’re gonna stay together, even though this seems bananas.” And now we’re like – I mean, I think all relationships kind of have ups and downs over the long course of it. We’re very much at an up right now; we’re so sickeningly in love, it’s wonderful. Hopefully we stay there, we’ll see. I’m not naive. But I think there are definitely moments where you just decide. You’re like, “I’m just deciding that we’re still together, because that’s what I have to do right now.” And so far for us it’s worked.

Kevin Ball: npm has started doing some of that tree stuff for security, though it’s going the other way; it’s saying “What do I depend on?” and traversing down each of those packages and understanding “Are there security vulnerabilities?” and things like that. This would be kind of inverting that and saying “Everything that depends on my library - let’s go and run all their tests with this…” You’d need a massive server farm, essentially… Like, kick everything off; okay, go run an AWS for three hours, come back and show me pretty graphs.

Any other JavaScript libraries you wanna – I wanna throw one out… We talked about this once on an episode and I just wanna pit you two off on combining WebUSB with WebTorrents, because I think there’s some really interesting things we could do there… Particularly getting around the setup problem and how do we make this something that’s truly distributed, or other fun stuff. Do you have any ideas?

Latifa Mrisho: Yes, it is, because you can lose the whole farm, and people depend on cassava for food or to sell to get income for their livelihood.

Alex Sexton: Yeah, it would be cool to be in a world where you could have a render farm for your JavaScript-built stuff, right? You press a button and 9,200 AWS servers all calculate one equation and send back the results…

Brian Ketelsen: [28:23] Yeah, and really that’s our farm team for GopherCon. So go practice at the meetups and get polished well, so you can come and present on the big stage at GopherCon.

Adam Stacoviak: When he said recompiler earlier, that’s what I was gonna ask, before I was getting interrupted. Chris, didn’t you mention something about recompilers a farm or something like that earlier in the call, that we didn’t go into?

Travis Jeffery: Alright… This question’s always a little funny. I grew up on a farm about two hours North of Toronto, Ontario, Canada, middle of nowhere. My parents were both entrepreneurs; that left me with a lot of time to watch movies, play video games, read books. They put me in a daycare called Teddy Bear daycare, and I’ve never slept as much as a normal person, so what the people that were on the daycare, what they’d do is they’d stick me on a computer, which was like a Mac 3, and that’s what I’d do while the other kids were sleeping.

When I was around 12 I picked up a book - I think it was The Pro Book, and the second book was a C primer book, and then I got “Hacking: The Art of Exploitation”, because I thought I was gonna be a hacker.

Thomas Watson: Yeah, I agree. That would be nice. It’s a very difficult problem to solve. I’ve had many hours of unpleasant customer interactions dealing with problems with binary modules. In fact, our app metrics module, our node monitoring - we pre-build it for all supported platforms, all Node platforms, and we package it up with all of those binaries, so there is no compilation needed for it. But it wasn’t easy; that’s not rocket science… You need to build farm, you need to build it on all of those things, you need to collect all of the binaries together, you have to package them all together… But it’s a fairly significant piece of work, and it’s hard to push it into the npmjs, into the backend.

In theory, npmjs could organize a build farm and they could do it, but they’d also have to have all the libraries… You know, that’s a separate problem; it’s a big problem, and it’s hard to solve. Bert had suggestions for that, actually. I don’t know if you saw that Chrome has an intermediate compiled format; basically, the C++ gets compiled to an intermediate platform-independent performance format, and then (I’m pretty sure) LLVM at runtime can do the final compilation down to machine code, and Chrome’s using it… It’s significant levels of programming wizardry and effort required to get that kind of stuff into Node.

Anna Derbakova: [07:46] Yeah, so many… I gave the example of supply chain of pork, in China, farm to table - how many people change hands between actually growing something and actually going through storage facilities, or some kind of processing facilities, and people who deliver the goods… Who actually has it, who tampers with it, what temperature is it under, where is it stored - all of these things… There’s a big question mark, right? So by the time it gets to a table, you don’t know who handled it and how. Blockchain is one of the solutions some of the bigger companies are looking to to implement something that would essentially record every time a transaction takes place, like an exchange of an asset from one party to another - you would record it as an asset transfer, and you would record the specific information that matters, like temperature, or how it’s stored, or whatever is specific to the asset you’re exchanging. Then you can’t really tamper with it afterwards; it’s kind of hard to cheat on the blockchain, right?

Brendan Eich: Sure. Actually, Tim Berners-Lee keeps moving the date when he started browsers back, so I don’t know if it was ’89 or ’90. I became aware of them in ’93 and started using Mosaic around then. I think I then used Netscape when it came out in the fall of ‘94. That was super hot and took over the browser market. I joined Netscape in early April 1995. That’s when I did JavaScript, notoriously in ten days in May, and I worked the rest of the summer getting it embedded and having a sort of primitive DOM so we could interact with the page elements, and shipping in Netscape 2.0.

Those were the days, right? Browsers were big, we were doing secure socket layer, so-called HTTPS, now TLS (Transport Layer Security) so you could have your credit card number flying around to various sites without worrying about snoopers stealing it.

JavaScript was kind of a toy then, but it was also in the browsers, right there on the page; you could write it, integrate it with your HTML… You could do very sweet, single-page application tricks even in 1995; without bugs and without XHR, you could do a lot.

So the promise was there… Java was supposed to be the big thing, but eventually it was just a plugin, I think. It always was inside this rectangle, it always was a complex language for people to learn if you weren’t a professional programmer, so the whole Java, JavaScript, Netscape+Java takes down Windows - they didn’t really happen.

[02:58] I got Microsoft’s attention and they did IE. Bill Gates did his famous Internet Tidal Wave speech, because he had a bunch of people he had to whip into shape who thought they were just gonna take down AOL or Compuserve or something, and they were building a proprietary dial-up content system, and I’m sure it would have sucked. Instead, they pivoted and bought Spyglass, built up IE, embraced Netscape-pioneered standards like JavaScript and extended them. We worked together, standardized JavaScript, and eventually Netscape got extinguished - that’s the 30 after embracing Extend.

I founded Mozilla, because I was done standardizing JavaScript; it was 1997 toward the end of the year… I remember going to the Paris sales office of Netscape and I realized, well, [Jim] Barksdale has been telling us Microsoft is taking the price of the browser to zero, because at that time Netscape actually sold the browser for money to enterprises. It was free for students and family, for home use, but it was still making money. Microsoft not only made Internet Explorer free, they bundled it with Windows 98, which was a monopoly operating system. So they did stuff that just was guaranteed to kill Netscape’s business.

Netscape had also gone public in ’95, well before being profitable, but it was a super hot startup. The stock zoomed up on the first day, and that kicked off the dotcom era of crazy startups. And it gave Netscape a war chest to buy companies, which hardly ever works. Mergers and acquisitions rarely work. In this case, they bought a bunch of startups which were all not really taking over the world as Netscape had, and they tried to bet the farm on them or build up a server-side business that never really took… They bought a sort of groupware Windows client company called Collabra, and because the original Netscape browser team was kind of fried and because of this ambition to take on Lotus Notes, they gave that company the sort of keys to the browser kingdom, and that just made things worse. Netscape 4 was late, and initially only on Windows, and buggy as all get out.

Jamie Zawinski’s got some old articles about this, if you wanna read about that era. It was not fun to go through that, but the only things that I remember being positive were getting JavaScript standardized, and then founding Mozilla. Mozilla was meant to be an escape pod, right? In Star Wars episode 4, A New Hope, this escape pod gets out from the rebel ship that’s been tractor-beamed and docked by the Star Destroyer crew. And the Star Destroyer crew, slackers that they are, don’t just blow it up for target practice, they let it land, and of course the droids are in it. [laughter] Microsoft must have been like those sloppy imperial gunners, because they didn’t think anything was gonna happen… Who knew?!

[05:59] It took four years to actually get the code in decent shape, which was many more years than some of my friends, the principle engineers who were working on it told their management at Netscape, so Netscape kept missing the mark with things like Netscape 6, which was a terrible release… Black-and-blue colored user interface with circular buttons; it was very buggy. Mitchell Baker and I told Netscape management, “Don’t do it…”, everybody in the rank and file engineering staff said “Don’t do it”, but the executives who sold themselves to AOL as able to turn Netscape around in some sense said, “No, we’ve gotta do it for morale.” [laughs] So they forced it out - that was in 2001 or 2002, I can’t remember. It was terrible, and it bombed, and I think some of those executives got their heads handed to them and replaces.

By 2002, Mozilla code was actually getting good. We were doing builds initially… Jamie Zawinski said, “Don’t do builds… You have to be a developer, you have to have a compiler, you have to know what C is. Do your own builds!” and it limited testing and limited reach, so we started doing QA builds of Mozilla, which were like Netscape without all the AOL, ICQ, AIM buttons that people didn’t want anyway. Those things were like AOL Instant Messenger, and ICQ was another instant messenger.

So Mozilla builds were cleaner, and they actually got fairly popular. I think at some point they were actually more popular than Netscape. But after we did Mozilla 1.0 in 2002, we said “Now the code’s good enough we can build something.” We already had a pirate ship called initially Mozilla/browser, then Phoenix, then Firebird, and ultimately Firefox going. That was a small group of people inside Netscape initially, lead by Dave Hyatt who was senior and Blake Ross who was junior - he’d been a high-school student intern at Netscape. They’d created this lightweight – just a browser off of the Mozilla code, where Mozilla was still doing a suite, because you did suites in the ’90s; you were trying to take on Lotus Notes, or you wanted to have Outlook-like mail, so you did a suite.