Gallery Projects Talks Posts Portfolio CV Contact

OpenSauced Interview

A chat with bdougie, the founder of OpenSauced

🍕 Watch the video on YouTube.

Topics

Transcript

The transcript from out chat is below. Adding this more for SEO juice than for human benefit.

Welcome back to the show. We're about to learn the secret sauce. So Zeke, one of the chatted by your open source journey because you've actually pretty prolific and I don't know if you'd like consider yourself behind the scenes in front of the scene, but like you've done a lot of stuff. So, uh, why don't we start with like who is Zeke first? Who is Zeke? Wow. Okay. Well, in the context of what we're talking about here. Yeah. Uh, you know, of course in my regular life, I'm a dad and I have a family and I live in Berkeley. Um, but for work, um, I mostly work in AI these days, uh, doing this startup called Replicate. Um, but yeah, I've been working in, um, open source software development for a long time. I've been, um, doing web stuff since, you know, the early 90s. I just watched that, uh, Kelsey High Tower. Yeah. Kubernetes talk that you did last month, um, and had a lot of parallels there in terms of like, uh, not going to college, um, but being really interested in computers from a young age and figuring out how to, uh, make web apps, make web web pages and get paid for it. Yeah. Um, so I've just had this sort of like long career of just climbing higher and higher and finding more and more interesting opportunities. Um, and I think part of it is just that I want to be creative and when I find barriers to creativity, I wanna kinda break them down or simplify things. So, I know a lot of people that you have on your show are like, you know, really talented software engineers. I'm not actually a very good engineer. Oh, interesting. Uh, yeah. I am not good at solving problems. I'm not good at fixing bugs. Um, but I am good at breaking things down and making them simple. And so, uh, the last 10, 12 years of my career have been really focused on that. Yeah, yeah. I mean, that's a great way to put it too as well. And like, yeah, because I, I look at the stuff that you've done and I'm like, oh, man, you've like, took touched so many different things. And I've actually looked at your PRs before in the past and been like, okay, I wanna learn from this. Uh, because again, like I've, I've seen your work in Electron. Uh, most recently, some stuff internally at GitHub, like you'd helped build out like that, that, you built out the doc stuff, right? Yeah, I helped internationalize the docs and open source the whole docs site for GitHub. Yep, yep. And, uh, yeah, so I know you from most recently from there. But like what's actually take a, a tour down memory lane and start from the beginning. So, Sure. Like, did you like, what was the interest in eventually like learning the code? Um, I think in the very beginning it was like, uh, there was this product called Macromedia Flash in the late 90s. Action Script. Action Script. Yeah. So Flash was like this program where you had a timeline and you had a a stage and it was sort of like Photoshop in the sense that you could put things on different layers, but in then in addition to the layered aspect, you had this time element where you could, uh, animate or transition things on different layers. Um, but then I realized that you could actually write scripts to do that same thing. Which, and when you, when you take something that's kind of a manual process and turn it into something that's managed by a computer program or a script, you have so much more flexibility. So I spent a lot of time just making crazy fun animations with with ActionScript in the, in the late nineties, early 2000s and that ActionScript was part of ECMAScript, which is the same sort of language family that JavaScript is a part of. So even though I wasn't really doing any legitimate browser coding at the time, I was sort of getting the foundation for being able to write code that would ultimately work in browsers. Um, so I was kind of a scrappy developer for a long time, did PHP and MySQL and Windows and I built my first like shopping cart application in the early 2000s and I wasn't very good at it. And it probably had a lot of like security holes. And I think we were even storing credit card data in a way that was like, you know, not PCI compliant and stuff. But learning a lot along the way. Um, and I worked for a bunch of like, uh, branding agencies and so I got to be exposed to different kinds of like, uh, design, like industrial design and print design, graphic design, stuff like that. Um, which I'm still not especially good at, but I love I love design and I love being part of teams that do interesting design. Um, and I also really love language. So, um, sometime in, I think, uh, right around 2009, 2010, I watched this TED Talk by a woman named Erin McKean, who was the head of the Oxford University Press in the United States. So she was like the Oxford English Dictionary, uh, boss in the US. And she gave this TED Talk about how she was so frustrated with, uh, the state of dictionaries and how, you know, the web is just exploding and that's where all the real sort of like valuable language information is, but then we have these like crusty old books that small teams of people maintain that are supposed to be like this sort of canonical representation of what language is. And she, so she, she was kinda bugged by this. And there was a someone in the audience who, uh, was, uh, sort of a, you know, prolific investor, earlier investor in Facebook and was like, maybe you should just turn this into a startup. So she moved to the Bay Area from Chicago and started this company called Wordnik. And the goal of Wordnik was to build APIs around English language and build the world's largest English dictionary. And so she had this concept of what she called a free-range definition. Which was, um, it was the idea that, uh, when you learn words, you learn them from other people saying them. You don't learn them from opening up a dictionary and reading the definition and being like, oh, okay, now I get it. You hear people saying it. It's like context. Yeah. And you start to absorb it. Um, so free-range definition is basically a word out there in the wild somewhere on the Internet that has enough context around it to define the word. So she hired all these, uh, you know, natural language people, um, linguistics people with, uh, computer science backgrounds to start harvesting these free-range definitions from the Internet and using them to compile this big data thing. And at that time, I was really interested in, uh, Ruby on Rails and I was kind of starting to level up to being like a legitimate software developer like writing tests and, you know, being able to write scalable applications and stuff. Um, but I was so pumped about the idea of working for for Wordnik. Um, so I moved to the Bay Area. I moved to San Francisco on January 1st, 2011 for my first venture capital funded startup job. And that wasn't really when it started to kind of like take off for me. And I started to make a lot of connections and do some really interesting work. Um, ultimately, Wordnik was not a successful business. Um, the idea behind the business was to make APIs that could be used by game developers or educators, uh, to incorporate word data into their apps. But the problem was there's just not, people just don't expect to have to pay for that sort of thing. Like there are other sources for finding that kind of thing. So, um, we didn't have a great business model. But, one thing that we did do well is we built an internal open-source project called Swagger. And Swagger was basically a JSON file or a YAML file that we used to describe the APIs that we had internally. So, we had one team that did like, they maintained the API and they wrote everything in Java and Scala and they maintained a MongoDB database. And then we had the web team, and they wrote everything in Ruby on Rails and they were more interested in JavaScript and there was some really like, cultural differences between those teams. It was like the XML team and the JSON team, like, Yeah. buding heads. Yeah. So it was hard to get the APIs we wanted because the API team didn't necessarily speak our language. So, we created Swagger as this way of having like a shared contract for like, here's the API I want before we even did any development. Just, does this look like what I what you, something you can build and something that I can consume? And it became a a contract that we could use to to design before actually building. But we didn't actually know what Swagger was gonna turn into. So, now Swagger is called Open API. And there's a bunch of like, you know, politics around why they got renamed. Basically some company tried to, Like, own the trademark. Own it and everyone was like, well, no, it's actually just like this open-source thing. So we're gonna fork it and call it Open API, which I think is awesome. Um, Swagger was a good name, though. Yeah. So the the reason, the name came from there was a thing called from Microsoft called the Web Application Description Language, which was like an XML thing. So people call it WSDL. So the idea was my idea was like, why why WSDL when you could Swagger? Okay. Did you name Swagger? I did. Oh, wow. Okay. Yeah. You heard it here first. Well, I don't know. I honestly had no idea, but yeah, I've been using Swagger open open API for like a very long time. Nice. Uh, so cool. Yeah, it's really hard to not say open AI, or open API. But yeah, API.opensauced.pizza is Swagger. Yeah. And, uh, you can go test and get endpoints and data and see our future features before we get UI on it. Yeah. Uh, today, which is a lot of my conversations are like, hey, here's an endpoint or here's the API like link directly to the form. This authentication you're good. Yeah, it's amazing. Cause like if you actually just hand over an Open API schema to developers, that's actually often what they want is just like, I don't want all this like ceremony around what your API can do and all this documentation and tutorials and stuff. Like those things are good, but sometimes you just want the raw reference data and the Open API schema is like the closest thing you can get to just like, this is what this API does. Like, And, uh, later that became a project that I worked on at GitHub, but that was that was many years later. Excuse me. But yeah, fascinating. So, like, quick, like, take a step back, like, so Aaron started Wordnik and it didn't work out. Yeah. But what's interesting is like, that natural language processing is a thing that's like, it's common knowledge and folks are doing it now. So, I was curious like, did Aaron go back to the well, or anybody ever solve that problem? Yeah, so, um, one of the really, we used to have these like sort of hack day, 20% time kind of things where we would just do like experimental stuff at Wordnik. And one of the people who worked with us, uh, named Will Fitzgerald, who, um, came to us from Power Set, which was this very interesting search company that was, it was basically the predecessor to Bing, like Microsoft bought them and then they became Bing. Um, they had this like, I think it was a, it might have been a Google N-grams thing, it might have been Bing. I can't quite remember, but they made a story generator, which used this concept of N-grams. So, um, a bigram is a pair of words, two words together. A trigram is three words together. I don't know if there's a word for a tetragram, maybe, for four. Um, pentagram, I guess. Although that means something else usually. Anyway, arbitrary number of words paired together. Um, so, you can imagine if you're scouring all of the text that's ever been written by humanity, you could start to collect these pairs and these triplets. So, when you're doing like a Google search and you start typing something and you get the auto complete, it's telling you suggesting the next word, that's based on the statistical likelihood of that word following the words that preceded it. Yeah. So, um, this guy Will made this story generator where he gave it, you would give it the first four words of the story, or the first five, and then it would just ramble based on that, moving one token over at a, one word over at a time and generating the next word. And so, it didn't make any sense, but it read like one long continuous sentence because all the previous four words for every word always made sense. So, it didn't go anywhere, it didn't, it was kind of meaningless, it was just an experiment, but it, I found it really fascinating. And now we are, here we are 12 years later and we can dig into this. But, we have this thing called, you know, we have these language models and most of them are based on this idea, this thing called Transformers. And, credit to the three, three Brown, one blue, YouTube series. I think that's what it's called. Yeah. It's got the little funny animated pie character. They just did a, a video about how Transformers worked that is so helpful cause I've been trying to figure out how this actually works for a long time and I'm starting to understand it, but the gist is, um, the way a language model works is, it's doing that same thing, like based on all the data that I've consumed, the most likely word next is and there's a, you know, there's like a list of probable of, uh, suggestion of possible, um, words. But the thing that is crazy about Transformers is that it is also looking at the surrounding previous words in the context to know what version of that word you're talking about, or contextually what is the most relevant word. So, it's the N-gram thing plus contextual awareness. Yeah. And that's basically like how language models work. And like, that's the sort of like fundamental piece of all of this like really amazing innovation that we're seeing in AI right now. So, for me, it's really cool to see like, the, like, really rudimentary version of it that was happening 12 years ago that was like state of the art. And that was a five word context window. And now we have like, table stakes is like 200,000 word context window and then Google Gemini has a million or whatever. So, yeah. And I'm getting off on a tangent here, but like thinking about the sort of arc of my career, like it's pretty interesting to see these things come back around after all these years. And it's like, I mean, it sounded like, because like we'll we'll get to other things as well, but like you've kind of been seeing the earliest like, like ActionScript, ECMAScript. Uh, you also got into Node, so like you you mentioned Ruby on Rails. Yeah. But I know you, I know you from the Node community, so like how'd you get from, okay, now we have the Swagger stuff. Um, like how'd you get in the Node ecosystem then? Yeah, so, um, JavaScript's been around since the 90s. Um, there was like a brief time where Microsoft made a sort of competitor to JavaScript called LiveScript. And there was this sort of tenuous moment where we didn't know what was gonna happen and people had to write two different versions of the front end code to make their web app work. We didn't call them web apps in those days, but like. Um, then like, uh, Netscape kind of folded and they managed to like, you know, as they were going down in flames, they managed to like set up this new protected entity called Firefox, which was this like new open source browser that was like gonna come out of the ashes of Phoenix or whatever it was called, that was uh, Netscape, the like engine. I forget all the terminology, but Firefox sort of like crystallized this thing of like, I don't know, maybe it was like 2005 or something. It kind of crystallized the idea that JavaScript was going to be like here to stay and that it was going to be powerful and useful. Um, but that was still years before Node. So, um, I was doing Ruby on Rails development in the like 2007, 2008, 2009. And of course, if you're building a web application, of course you have the back end. But if you want anything to happen inside the web browser, you have to write some JavaScript. And so when Node came out, I remember having this feeling of like, oh, that's like what the cool kids are doing. And I'm still over here doing Ruby on Rails stuff and I'm kind of missing out. Although it was still really early, it was like, that was like Node 0.4. Yeah. And it was just kind of like this this infantile project. But I could see the promise of it because it was an opportunity to write code that would have shared logic between a server and a web browser, which is like great. Now we don't have to have like, kind of back to like the Swagger Wordnik problem. We don't have to have like the team that owns the API and the team that owns the front end because we can write the code in the same application using the same, you know, in the same language, using the same tools. So, to me it was like, obviously, everyone's gonna go in this direction. But then I went to work at Heroku and, um, I sort of joined Heroku out of spite because at Wordnik, we didn't have the opportunity to deploy production services unless they went through the like Java, they had to be part of this like Java monolith, basically. And I didn't want to write Java. I didn't want to figure out how to write Java. I wanted to write apps in whatever language I wanted to use and deploy them on Heroku. But they, at the time, Heroku was sort of seen as like a toy or, I mean, it still kind of is seen as a toy by some people. But, Yeah. salesforce.com. Um, so I was so interested in Heroku and how they made it really easy for sort of not very good web developers like me to be able to build an application, easily deploy it, scale it, connect databases and logging services and email sending services and stuff to it with like very minimal configuration. So, I went to Heroku kind of like, with this feeling of like, I actually don't like doing this stuff. I'm not interested in like, I'm not like a systems developer. But I just love how great this product is and how it's made me able to be like a full stack developer even though previously I was just making web pages. So, I I assumed that when I got to Heroku, all those Ruby developers would be like, yeah, Ruby's actually not that cool anymore. We're gonna start doing everything in Node. But that was not the case at all. It was either, everybody was still loving Ruby because it had this beautiful syntax and was just so, you know, such a humane programming language to look at with your eyes and interpret. Um, but everybody was moving to Go because Go was like this really fast, um, safely typed, easy to test, hard to break programming language that could, you know, outperform, you know, it was like kind of Ruby and Go were sort of on the opposite ends of the spectrums in in terms of their like performance capabilities. Like Go is really, really fast and Ruby's really slow. So, all these people who were working at Heroku building the actual foundation of Heroku were really stoked about Go. And I was like, okay, Go is cool, but I don't want to write that because I want to write web applications. I want to build web apps. So, uh, Heroku initially was a Ruby platform, but they had started to pivot into being a polyglot platform, meaning that you could run any kind of code there. So, there were like these things where if you pushed, if you did like Git Push Heroku Master, and your code had a package JSON file in it, it would be like, oh, that's, that looks like a Node app, that's not actually a Ruby on Rails app. So, let's send it to this other build process. And so those things were called build packs. And those were open source. So, I was like, well, we have this Node build pack that this really talented developer David Dollar had built as like a prototype, but it wasn't maintained and there wasn't any team maintaining it. So, even though I wasn't good at that stuff, I was like, this is a huge opportunity because like Node is blowing up. So, I I became the maintainer of the Node.js build pack at Heroku. So, that that meant I devoted like a year of my life to getting good at Bash scripts, basically. Not web apps. Not web apps. No, like I keep getting kinda farther and farther from web apps, which is interesting. But, um, that got me really connected to the Node community. So, we had like, and it was one of the most sort of like fulfilling times in my career because I was working on a project that like people internally didn't care about or weren't really precious about because it was still like Ruby was still like dominating. But I could see the writing on the wall and it was like, we had something like, I don't know, 5,000 deploys an hour of Node apps on Heroku. And so, I could change one thing about the build process and then all this data would pour in and I could see how much I was like slimming down the build times. And then thinking cumulatively, like, wow, okay, so it's like 5,000 deploys an hour if I like save, if I shave like a minute or two off of each of these builds, it's like, that's adding up to a lot of developer time, like a lot of time that is no longer wasted. So, I felt like I had this huge lever for being able to like, really improve developers' lives. Um, and it was going really well for me. And I had this kind of like private little niche at Heroku where nobody was, I was like the Node guy, which was kind of a problem too cause I'm like, well, I'm actually not very good at this stuff. I just think it's cool. You know, like, I'm not an expert. Um, but meanwhile, the Node and npm ecosystem were kind of falling apart because NodeJitsu had not been a very particularly organized steward of the project. And this was the IOJS time? Yeah, exactly. Well, just before that. So, so, the npm registry was maintained by a company called Nodejitsu. Yeah. And they were based in New York. And they had this kind of, they were trying their hardest to keep the registry alive and it was filling up with lots and lots of, uh, npm packages. And the traffic was just getting out of hand. And they had this sort of bespoke database configuration where they had this database called CouchDB, which was a really sort of interesting project that was kind of very web-forward. Um, but it was a little bit like a house of cards in terms of the way the registry was designed. And the the registry was going getting so insanely popular because of the ease of using npm and publishing packages with npm. Um, that something needed to happen. So, Isaac Schlueter who was the, uh, creator of npm, uh, turned it into a company. He raised, he raised capital and started npm Incorporated in Oakland. This was in like 2014, I believe. Um, and I was like, okay, well, that's the place to be because like Node is the, you know, at that time, I just felt like npm and Node are sort of at the epicenter of web development. Like that's where it's all happening. Everybody's typing npm blah, blah, blah all day long, every day. Um, so even though I had this really good thing going at Heroku, I just felt like I have to chase that opportunity and see where, see where that leads. And ultimately, working at npm was not a great experience for me. It was tough because, again, it was sort of like the Wordnik thing in that there was no business model. Like the idea was, okay, we'll sell private packages. But GitHub had already kind of, people had already kind of solved the problem of creating npm private packages by just putting their code on GitHub. Like still to this day, you can, you can type npm install bdougie/pizza and that's just gonna like go straight to Git and install that as if it were an npm package right from your GitHub repository. So, that's always been part of npm. And so, when people wanted to use a private package, they would just point it at a repo or a branch in a repo where the build of their stuff was and as long as they have a secret configured so that, you know, the npm and Git client can authenticate to that, then you don't need private repos. So, the whole like basis of, this is how we're gonna make money, didn't actually make a ton of sense. Meanwhile, usage of npm is growing through the roof and, and it just didn't make a ton of sense. And actually, I want to talk there's like a, there's a corollary here I think with Hugging Face that we can get to at some point. But, Yeah. Yeah. I mean, it's funny at Heroku, there were so many static web apps that people were deploying on Heroku. And it was like, so we're running a server just to like host this like rinky-dink web page when we could actually just be, you know, putting it on a CDN somewhere and Yep. pointing a, you know, Apache or something like that and not having to actually run any servers for this. So, Yeah. Yeah, at that time, was that, did you leave post, uh, Salesforce acquisition? No, I actually started after the acquisition. You started after the acquisition. Okay. So, I was there during a time when everyone was sort of in this celebratory now we don't have to do anything kind of mode. Yeah. Like there was, there was still no management. I don't I don't know what this means. There were, it was just like a flat organization even though there were like, How epic was the company then? close to 100 people or something like that. I think I was like the 85th person, 86th, or something like that. Wow. So, yeah, at that point, cause I know post Salesforce acquisition, things kind of felt like it hit like a wall when it came to Heroku. So, very interesting timing. But yeah, anyway, I wanted to share the context of my life during that time. Yeah, totally. And, um, I also joined Netlify a couple years after that where I remember the Heroku build pack, like for for Node, it it worked at the time when I was like building like Node apps and eventually React. But then it didn't like quite need, like you kind of did too much for like a React app. Uh-huh. Uh, so then Netlify started. And Netlify and Vercel and Ziet and a bunch of other stuff, like, uh, Surge. All built like these build tool agnostic, um, deployment platforms, which like completely shifted course away from needing the run build packs on on, at least for Node apps on Heroku. Yeah, totally. I mean, it was funny at Heroku, there were so many static web apps that people were deploying on Heroku and it was like, so we're running a server just to like host this like rinky dink web page when we could actually just be, you know, putting it on a CDN somewhere and pointing a, you know, Apache added it or something like that and not having to actually run any servers for this. So, Yeah. Yeah. And it's like, it it's getting better. Yeah. Yeah, it's getting better really quickly. So, we'll we'll see what GPT, uh, GPT, uh, five is going to give us. But, yeah, the meta stuff, uh, the Lama stuff is like, looking pretty good. Mama three is really, really good. Um, yeah, I know there's like, there's like a contentious topic. But, you know, there's, uh, Andre Karpathy, who was the head of AI at Tesla and then went to Open AI. See, I'm doing it now. Open AI. Open AI. A couple times back and forth. Um, he has this pinned tweet, which says, you know, the hottest new programming language is, is English. And I totally subscribe to that thinking. It's like, um, a lot of my work now involves starting with writing a Markdown file that outlines my intentions for building something. And the more clear I am in describing this thing, the more likely a language model is to be able to produce exactly the result that I want. And, a lot of people are using these sort of like chat-based interactions where, uh, you ask a language model to write you some code and you say, oh, no, can you like, do this a little differently? And then, you know, it's like this back and forth that goes on and on. And ultimately, sometimes the language model starts to forget things about the earlier part of the conversation because the context window is too short. So, they become forgetful. So, I have kind of a different approach to building those things, which is I write the README file, I write the Markdown file, I run it through the language model, I see what it produces. If it's not what I like, I don't then have a chat with it. I go back to the Markdown file and change it to make sure that it doesn't make that same mistake that it made the first time. And I just end up with a document that is ultimately more and more clear about what my expectations are. And then I run that and it generates code and from there it's like an application that I'm, that I'm using. But it's just getting better and better at that. Like, Yeah, you might have described GitHub Copilot Workspace. Yeah, totally. It's it's basically what, what they're, what they're shipping now. But like, not, not meant to be a plug for for that, but try it if you get access. Yeah, I did get access. I got a little bit overwhelmed when I saw the UI because it has sort of like this idea of like, I was like, strategize, plan, execute. Something like that. And I was a little bit like very Jira. Yeah, it was a little bit like I don't know what this means. I get the gist of it, but, uh, haven't yet jumped in and actually gave it a try. Cool. Yeah. Well, I'm still waiting for my access. Uh, but speaking of which, uh, yeah, let's, let's wind this down. Appreciate you coming up, uh, all the way from Berkeley and Oakland. And, um, folks, stay saucy.