Cory Doctorow: So we need to think about where the high switching costs come from, and we need to acknowledge that they are a mix of two things. One is countermeasures… So think about that weekend where Twitter said “If we find a Mastodon handle in your bio, or in your stream, we’ll suspend you from the service.” That’s like a technical countermeasure. But then there’s like the legal countermeasures. Because you could just write a bot to scrape Twitter and figure out links to Mastodon, just like make it happen. A bunch of people do that with the API right now, but the API keeps getting nerfed… And so you could do it without the API. You can just do it manually, with like a bit, with a scraper.

And in fact, if there was the potential for a bot to be built without a legal remedy, without being able to go in and say, “Hey, you’re violating the Computer Fraud and Abuse Act. It’s a felony”, blah, blah, blah, when they contemplate nerfing the API, they would have to go “Ah, are we gonna have to pay like 100 engineers to fight bots now? Because they’re all just going to switch over from using the API to using bots. Are we going to have this unquantifiable risk that arises from having to just take scarce engineering resource and devote it to fighting on the blue team, where we have to be perfect and they just have to find one mistake we’ve made? Because we can’t sue them”, because we’ve withdrawn the legal protection that would allow Apple to stop you from doing Apple what Apple did to Microsoft.

So this is why in both Chokepoint Capitalism and “The Internet Con” I get into a lot of detail about what legal reforms would allow technologists to do good, and what new law, like privacy law would stop them from doing evil. Because it’s true, bots and scraping stuff - they can do bad privacy stuff. The answer to that isn’t to say to Facebook, “Hey, guess what? You have unlimited power to wield the state, to wield its courts to stop anyone from doing anything you dislike, because we’re going to use you as our deputies to figure out when someone’s privacy is being invaded.” I mean, just think for a moment of the irony of putting Facebook in charge of deciding when someone’s privacy is being violated. And instead, we would say, “Hey, we have this democratically accountable yardstick that says “This is a privacy-invasive behavior, and these things are not. And if you’re doing this, and you’re an inter-operator, you’re on the side of the law. And if you’re doing that and you’re an inter-operator, you’re violating the privacy and we’re going to come after you, not for interoperating, but for doing something that violates people’s privacy. Not for making shareholders of Facebook sad, but for doing something that harms the public.”

David Cramer: Yeah. So you kind of pick a license. And I didn’t have opinions back in the day, other than I sort of knew what GPL was and didn’t like it. I didn’t like the infection of it, and I didn’t like people’s inability to use your software. We weren’t trying to commercialize anything, it was just like utilities, and infrastructure… It’s just like “Well, you pick a license that people can use, that keeps your name and protection intact.” But it’s not about “How do we force a company to do business this way by using our open source software?” That was never our goal. It was just accessibility.

So when we did that, we chose the BSD license, which is super-free, but it was still licensed; it wasn’t just arbitrary. And if I went back, I would not choose the BSD, I would choose Apache… I think Apache and MIT are kind of interchangeable, ignoring the legalities (there’s minor differences). But these days I would go with Apache or MIT from that perspective… But it was what it was.

Fast-forward seven years, we had started a small business out of it. It was very much a hobby business, running it on the side… We didn’t really know what it was gonna be. We thought it might turn into a lifestyle business… But it was going well. And at that time we thought a little bit more about relicensing, getting off of BSD and onto something like Apache, which was a little bit more understood in legal proceedings, had a little bit more protection around it, depending on which direction we went… And that protection stemmed from like “Well, what if we did end up with patents?” or like “We have trademarks, and all these other things. How can we ensure that a legal entity will understand this and take our side in the things where they should.” But it was still a free license, so it still basically had no consequence to anybody running it.

[04:15] We never wanted to go open core. We never wanted to say “You can only use part of our software.” And I mean this in the way of we wanted it to be accessible, not open source. Open source was a great benefit, and we really much believe in the education that open source brings, being able to look at code and understand how it works, and adopt that code… I think that’s hugely important in open source. But open source means I don’t know how many different things… But to many people it just means free software. To a lot of other people it means software where you can go contribute to it. To some people - and I think actually very few - it means software that you can take and copy and use in whatever way you want. I actually don’t think that’s super-common. And that certainly wasn’t common with Sentry.

Most of Sentry has been built by myself early on, and then over time it’s been built by our company, if you look at the contributor graphs… But that’s only one piece of Sentry. We have a ton of libraries that are on different repositories, we have a ton of other projects that are on different repositories, and those are actually under different licensing mechanisms. And we always had that. We had a mismatch of licenses everywhere.

When we finally said “Okay, let’s redo the licensing”, it was mostly triggered, in all honesty, by an annoyance of other companies. We had this hodgepodge of licenses, we had these companies doing things that we didn’t think were right, and so we were like “You know what, now’s the time. Let’s invest in this. Let’s get it done, rip off the Band-Aid… But let’s do it in a way that we think is right.” To some degree, it was just the evolution of the project, the business, kind of all things combined, but still trying to keep our ideals intact.

Tom Pansino: It’s a lot of pieces, but none of it is particularly proprietary. So we just need to clear that all with our legal team, and stuff. But we’re using Terraform, which is of course HashiCorps’s infrastructure as code language, so the idea being that you want to have the state of your infrastructure captured just as well as your development code is. And our goal is to make it so that basically everything that we push in this layer of this account structure, this platform layer is delivered via Terraform.

So we’ve got our repo inside of our repository, we have a configuration file, which has an array with objects that represent each of our accounts, or all of our domains. It’s really the domains, it’s not the accounts. So it lists out the name of each domain and the types of environments we want to create for each, so a development or a dev, stage or a prod, all of those things. And then when you run it, the Terraform is structured with various modules. If you’ve worked with Terraform, this is going to sound really familiar, but various modules and things, that one of them I think is– there’s an account module, basically, for Amazon. And so it’s going to provision a new Amazon account, it’s to go and do things like set the support plan to be the correct tier of support that we ask all of our production accounts to have, which is I think the four-hour response time or whatever it is, or the one hour. I forget exactly what we use. And so then in addition, it’s also going to New Relic and it’s setting up accounts in New Relic and provisioning API keys there.

We do a lot of work with– and many people who have worked at larger companies are probably familiar with a concept of like a service account user, or a machine user. We call them faceless users. It’s a user who has no face, is how I was taught; sitting in a chair. And so the point is to say, “I want to connect my GitHub actions back to Amazon to let it do deployments.” So we provision a user and a password for that, and we put that password in GitHub, and in a secrets manager, so that people can start using it in their CI flows. So yeah, it basically runs through a GitHub Action, CI/CD, and does a deploy, and then all of these resources, several thousand of them, spring into existence and start doing what the teams need them to do.

Cory Doctorow: Well, I grew up in Toronto and in the mid-90s I started commuting to Silicon Valley to do systems integration for an IRIX shop - Silicon Graphics UNIX shop - and through that became more interested in bringing open source software and network administration. Then, as the web took off, I became a CIO of a web services company and then started a DotCom that did free and open source peer-to-peer search that we raised some money on and that we had an acquisition offer for, and that made our investors see dollar signs on it, so they took all of the founders’ equity and in the ensuing chaos, the acquisition deal fell through and the company just imploded.

While we were working on that, because it was doing peer-to-peer and file sharing, it was really involved with the legal fights of the day, which revolved around Napster, and our best legal advice came from Electronic Frontier Foundation. A lot of our programmers were also members of the Cult of the Dead Cow, which was this amazing hacker group, and CDC hooked us up with the Electronic Frontier Foundation and I got more and more involved with them.

As the company started to implode, I quit my job, quit the company I’d started and went to work for Electronic Frontier Foundation. All this time, I’d been writing novels and stories and they started to sell around this time, as well. I took a job with the EFF overseas, I went to London to be their European Director and worked on digital standards and treaties at the United Nations and then in Brussels, mostly on killing DRM. I was also all this time writing this weblog called Boing Boing, that started off as a hobby that some friends and I put together. It was founded by my friend Mark Frauenfelder and his wife Carla Sinclair, and then it built into a fairly big, significant commercial concern, with 9 million unique readers a month and still going strong. So I was doing that as well, and that was also a useful platform for talking about the political work I was doing and my writing.

[11:38] When my writing got to the point where it was occupying too much of my time to do a proper job at EFF, I did what I always told them I was gonna do - I quit to write full-time, but like literally within seconds of announcing that I was gonna do that, I got offered a Fulbright at the University Southern California to go and teach about DRM in LA, and my wife at the time was working for the BBC. She’s British and she was able to transfer to BBC America, so we came and lived in LA for a year and moved back to the UK in 2007 with my wife pregnant at the time. She delivered our daughter in our flat in East London, and we lived there ever since.

I did some contract work for Disney Imagineering and wrote books and went and spoke to people, and did other bits and pieces, but I became more and more alarmed about the proliferation of DRM. It started off as a harmless folly that was used to lock up game consoles and DVD players, but because it has this law, the DMCA, that says that breaking DRM is illegal even for legal purposes, companies started adding it to cars and tractors and insulin pumps and cat litter trays, and arranging the DRM so that you had to break the DRM to do things like put your own detergent in your cat litter tray, or to broadcast your own seed using the soil density data that your John Deer tractor had gathered while you drove it around your field and the torque sensors on your wheels gathered centimeter accurate soil density data. And because things that are DRM’ed are off-limits to security researchers, because knowing about a defect in a product helps you break the DRM, and because DRM can’t be implemented as free and open source software, because it’s obvious on its face that if you’re a designing programs that treats its users as its adversary, that making that program modifiable by that user is not a good idea from a security model perspective. If there is a flag in the source that says “DRM On = 1” and the user doesn’t want the DRM - which I think universally users don’t want DRM; no one woke up this morning and said, “I wish there was a way I could do less with my music” - then you know someone is gonna just turn that one into a zero and recompile your program.

Free and open source software is antithetical to DRM, so we have this existential threat to flaws and this existential threat to security at the same moment that software was metastasizing and invading the world and moving into our light bulbs and our baby monitors, and I thought this was a terrible thing.

I came up with an idea for fixing it that was built around first launching a lawsuit to invalidate section 1201 of the DMCA which protects DRM, and then going around the world and getting other countries to drop their own versions of the DMCA, and also doing some activism with standards bodies, the W3C, the World Wide Web Consortium is adding DRM to the core suite of web standards, I’m trying to get them to abandon that… So I came up with this plan and I pitched it to EFF, and they said “That’s an awesome idea, but we don’t think anyone here has the bandwidth for it, but it sure sounds like something you’d be good at… Hint-hint-hint!” and so I said I was gonna take a couple of years off from writing books full-time. I’m writing slowly now, a page a day on The Third Little Brother book, and then I would go back and work half-time for EFF on this, which I started doing.

The Director of the MIT Media Lab, Joi Ito, gave us a grant. He made me his Activist in Residence, and so that pays my way there, and this is my gig, I’m gonna kill all the DRM in the world within a decade, that’s my project.

Chang She: The use cases for LanceDB in the community that I see falls into three or four large buckets. One is of course generative AI, RAG, and things like that. And I think there – I think it’s not so much the use of LanceDB that I think is really cool, but it’s the applications that people build with it that is really cool and amazing. And I think a lot of the applications that people build that is cool, that really takes advantage of LanceDB, is things where you need RAG to be very agile, and that you need it to be really tightly bundled with your application. You can call this RAG from anywhere, and have it return pretty quickly, and without too much complexity.

[30:03] And so this was where I see a lot of folks, from your standard chatbots and chat with documentation, to things like productivity tools, where they build things that help people organize their daily schedules, to much more high stakes things in production, like code generation, or healthcare legal, and things like that.

And so there I think typically you see vector dataset sizes, from like the tens of thousands up to single-digit millions of vectors, typically. So production means you really scale up both the number of datasets that you have, and then the number of vectors that you have…

And one of the cool things that I’ve seen, that takes advantage of LanceDB and Lance format uniquely, is there’s a code analysis tool that analyzes your GitHub repository and plugs it into a RAG customer success sort of tool. And what they want to be able to do is say query the state of the database, like “This today, versus yesterday, versus a week ago”, to say “Hey, was this issue fixed or not?” and “What’s still outstanding?” LanceDB uniquely gives you this ability to version your table, and also do time travel. So you can say – any vector database can do “Give me the 10 most similar things to this input.” Uniquely, what LanceDB gives you the ability to do is say “Give me the 10 most similar as of yesterday, or as of a week ago.” And we do that automatically for you.

And then I think the other big buckets are eCommerce, and a search and like recommender engines. This is like the traditional use case for vector databases… And there you tend to see much bigger single datasets, that are, say, “I want to store item embeddings.” Maybe that’s up to a couple of million, up to 10 million. I want to store item embeddings - that could get up to like hundreds of millions. And you don’t have as many tables, but you have potentially very large tables.

And then of course, the last bucket is this computer vision, AI-native computer vision; either generative computer vision, or things like autonomous vehicles, and things like that. And there’s a whole combination of more complicated use cases that enables active learning, deduplication, and things like that… And the thing that is very unique about the use case of LanceDB in there is companies that are managing all of their training data in LanceDB and Lance format format as well. So you can use the vector database to find the most interesting samples, and then you can actually use the tooling on top of the format to essentially keep your GPU utilization high, and keep your GPU fed very quickly during training, or if you’re fine-tuning, or if you’re running evals, and things like that.

Derek Collison: Yeah, so what the audience might not know is that the CNCF was kicked off at a large meeting at the Switch Data Center in Las Vegas, of which I attended. And I was actually part of the founding governing board. So a lot of people might think “Oh, Derek’s role with the NATS project and NATS being a project in the CNCF - that’s kind of the totality of it.” But that’s not the case. And even early on, we were looking at what value CNCF could bring to the ecosystem from a consumption perspective, the users, to the people or the companies that want to utilize that, and then of course, the projects themselves… And then for me, it was like the companies that are driving said projects. In the case of something like Kubernetes, where it’s all of the big boys, so to speak, there’s not a lot that the CNCF needs to do there. It’s kind of taken on a life of its own and it’s marching down a path.

What we started to realize is that as time goes by - because this was, I think, over a decade ago - that both the CNCF and projects can evolve. And where we were at was looking at the question “Are we the best fit for CNCF?” And no fault of CNCF’s per se, but it just felt pretty clear to us that certain projects were at this tier, and other projects were way down here, and we kind of were in the latter category.

In no way were we attempting to relicense the whole codebase. I mean, one, you can’t do it, because once it’s released, it’s AP2, it’s there. That will never change. But the CNCF in early discussions – because we said “Hey, would you be open to letting the project leave if the landing spot made sense?” Meaning we could do a joint statement where it’s like “No, it’s landing in this new foundation, made up of lots of big users and customers or production uses of the NATS ecosystem. Commitment to AP2, X, Y, Z.” And during those early conversations, which started in February, we were asked “Hey, are you considering a license change?” And we’re very well aware that we can fork and do a Synadia version enterprise server, and X, Y, Z, and so we said “We’re considering, just for the server, that we might do like a BSL.” And at the time, the BSL - for us, it wasn’t translated well out into the media… But the reason that we were considering it was we felt that it was the best show of commitment to both OSS and to our customers. And I’ll explain what I mean by that. The BSL has usage clauses that you have to define when you release the software. And one of them is there’s a period of time after which it converts back to whatever language you pick, which - we would pick AP2. And it doesn’t matter what Synadia does, the Linux Foundation does, CNCF does, that is a legal contract that once we release, let’s say, a server with the BSL license, after two years it’s converted to AP2. Even if we don’t actually update the copyrights, or update the license, or whatever. And so we felt that from an OSS ecosystem.

And again, we’ve gotten lots of additional information, lots of additional feedback. Most of it constructive, some of it not. And we’ve been listening. But our initial thought process as we were going down this path was “Hey, this signals really strongly that we’re not going to hold anything back. It will always kind of revert back to generic drug prices.” Some of the good parts of what the patent system originally was trying to do early on. I’m not claiming that the patent system is necessarily good these days. It’s a necessary evil, right?

[36:16] In addition, if you would imagine a two-year BSL window, and let’s say Jerod wanted to be a customer of Synadia - and customers are worried about vendor lock-in, price gouging, all those normal things - you could say, “I want to do a two-year contract, so I have predictable pricing”, and at the end of that, that all stuff that I’m paying for converts to AP2, and I can now use it for free. Or I could say “Oh, I like the next version, too. I want to use that and [unintelligible 00:36:39.10] and do that.

So I’m not saying that it transpired the way we wanted it to, but I think people’s thought process that we’re just evil and we’re just trying to price gouge and be greedy and stuff like that - I don’t feel that that necessarily is correct, at least as we were discussing internally. We care deeply about our commitment to open source. But we are starting to see a very disturbing trend where customers that everyone would recognize - they’re in the Fortune 50 - that are using NATS to power production-level services or functions or products, not only had never reached out for any type of commercial agreement with us, but actually have policies that say “If you’re in the CNCF and you’re incubating and graduating, we’re not paying for it, period.”

Adam Stacoviak: Yeah. The maintenance of that is scary, because as you had said before, back to the hero analogy, as you had said, you have service owners inside of FireHydrant, so you’re sort of identifying these owner stats, as you mentioned. In an ad-hoc scenario, you’re not doing that. So you’re allowing the heroes to be heroes, right? Which is okay. It’s not terrible, but that means that there’s a bus factor there. If that person leaves, then all that manual process and the knowledge of how to do those manual processes leaves with them. And so in a high churn environment, which is engineering, specifically… So if it begins in engineering, but then permeates to the rest of the business world - marketing, legal, whomever else - then that knowledge of how to deal with these things, if it’s ad-hoc, that ad-hocness also leaves. And someone has to relearn, by – how do you learn? By doing. Having more incidents, right? So it’s kind of scary, honestly, in a lot of ways.

You mentioned Honeycomb before, and Christine Yen has been on the show before, and I would call her friend… And one thing we talked about recently, specifically to their most recent fundraise, was observability for everyone. And this sort of like “for everyone” after it seems like maybe teams currently use observability as the smoke signal potentially. Observably is almost the ad-hoc version of incident management. Because observability is like “Did my CPU spike in production? What’s happening in production? Alert me. Tell me. Let me go there and ask questions”, all that good stuff. How do you see, I guess, since you mentioned Honeycomb - do you use Honeycomb? Is that part of FireHydrant’s tooling? Do you use that behind the scenes? That kind of stuff. And then two, how does observability play into the bigger picture of incident management, and then more importantly, reliability?

Shay Banon: Yes, and until you understand the complexity of going through the legal process, if that makes sense. There’s two aspects to it, I think. The first part is, if you go back to open source - and I’m relatively old school open source - a big part of building an open source software was registering a trademark and owning it. Red Hat did it, and others. And the first thing that I did even before I released Elasticsearch was take a loan and register Elasticsearch trademark. By the way, I don’t know if you know, but there’s many different types of trademark… But I actually registered two types of trademark: one for downloadable software and one for software as a service. So even back then, I wanted to make sure that when we build or someone builds Elasticsearch as a service, it doesn’t get confused.

And at least for a while, people respected trademarks. You know, Apache, and Red Hat… And that was a wonderful protection, because you could go and fork the project, you could go and do all of these things, but it’s just a different – from that point on, it’s a different project. I think cloud changed the game. And I think because Elasticsearch was so popular and Elasticsearch was one of the first services that Amazon decided to take and provide - I don’t know, I’d like to think the best of people, and afterwards try to figure out why not… I think they just took Elasticsearch and said “We’ll call it Amazon Elasticsearch.” Maybe they didn’t have experience with open source, they didn’t have experience with these types of things… You know, naively, some product manager takes a product, provides it as a service, and that’s the name. And I think that you can see that they learn after that, because when they took other open source projects, they called them differently. They call it ElastiCache, and they call it Amazon Managed Service for Kafka, versus Amazon Kafka, and things along those lines. But Elasticsearch was one of the first ones, and that name stuck. And that part, I don’t know, for whatever reason, Amazon just refused to change the name, regardless of how much we try to talk to them and try to process through it. And you’ll have to ask them why… Basically, it was kind of like the answer is “I’ll see you in court.” And people think, “Oh, you’re a big company, and you have lawyers, and you can pay for it, and go through the process” and whatever, but it’s exhausting. You have to give testimonials, and you have to do this… And it’s at least a few years of process. And maybe it gets resolved - and we ended up resolving the trademark infringement. By the way, thanks to the fork, because it made it really easy. But it just takes a long time, and it takes a lot of attention. And it never felt right to me. I want to be focused on building great products, not doing lawyer-y stuff, if that makes sense.

Paul Orlando: Okay, so the 12 that I list are technological related ones… So you might be thinking here of like even Moore’s Law kind of examples, or I gave like [unintelligible 00:53:09.19], other types of network-related, bandwidth-related examples… Social and behavioral changes… There’s some social and behavioral things that stay the same across centuries. People love music - I don’t think that’s going away in the future, no matter how long you wait. And there’s other just maybe more cultural effects that do change generation to generation.

There’s regulatory and legal drivers, and some of these function like an on/off switch; it is completely prohibited to do a certain thing, or it’s mandated you must do it. Others are more like a dimmer switch; like, there’s some gray area. And I give, different examples there, like patent protection, where it’s strongly enforced, versus - you know, it could be state by state; say like legalization of different products.

Installed base is another one. So when you rely upon the existence of another product that’s out there, so like the smartphone, or smartphones with the App Store installed… Like, Uber did not need to also develop the smartphone, and then hand that out to all of its customers, so you can rely on an installed base another company invested in.

The crisis one we mentioned… The economic driver is, I think, pretty straightforward. So there are growth times in the economy, times of decline; that might drive different behaviors. Networks we kind of mentioned, but as opposed to the installed base examples. It’s about the connections in a network.

So again, going back to the Uber example - you had people navigating with these old Tomtom devices in their cars, but those were not networked. So if I want to create a rideshare business, I need whatever that device is, whether it’s a smartphone or some other standalone device, I need them to be networked for the communication between the driver and picking up the passenger.

Distribution is another one. So different ways that you can reach customers, resources… Capital access is a big one, especially I’ll say for the last few years, because we went from an era where the money was kind of flowing… Both low interest rates, so you had to look for high-yield, places to invest, but then also COVID era, the first part, when a lot of money was pumped into the economy, and [unintelligible 00:55:38.00] valuations were going through the roof… And then a year, year and a half later that dried up. Huge valuation cuts, startups that were expecting that they were going to be investing heavily in growth, but maybe it was not profitable growth, and then they can’t raise the next round, and they have to shut down.

[00:56:00.13] Organizational drivers… So this is where the organizations themselves can learn internally, and then be more efficient.

Available talent. So what is your access to people that can actually build the thing? Is it that there’s just not enough people with – I guess the joke is I want 20 years of generative AI experience on my team. People don’t exist. Versus “Oh, we are producing these new experts at a good rate.”

And then lastly, demographic drivers. So you might just look at how populations age, or health needs, things like that. It’s a long list, and I’ve figured that any startup is probably really dipping into one, two, maybe three of those… And then to make that process maybe a little easier, to give people some ideas, at the end of the book I include what I call timing patterns. So we see combinations of these in different ways, and what ends up happening in some of those combinations… So that might give you an idea, if you have a tech driver with a capital access driver and a demographic driver - what are some examples of companies benefiting from that or not?

But yeah, I’d say the approach that I would take - because you mentioned Lean Startup, that book changed the way people ended up building companies after that came out… Yeah, what I hope people end up doing as a result of reading this “Why Now” book is they’ve probably already been thinking about the impact timing has, either on themselves, or they’ve seen other startups, other products kind of benefit or suffer because of timing… So they’ve started thinking about this, but this book will give them a bit of a process to follow, that I think is helpful. And then a lot of examples of other companies that either did this really well, or poorly. So I tried to write it in a way that was pretty straightforward… Basically, I want people to be different, and to act in a different way because they’ve read this. And yeah, I think a combination of the methodology, and then all the examples does that.

Dylan Schiemann: Yeah, so over the years Dojo had taken on a number of other projects, including one of yours, and then the jQuery Foundation was founded, and it had jQuery and some other projects… And then I think about three years ago Colin Snover introduced Kris and me. Kris Borchers was being the president or the director of the jQuery Foundation. He said, “You know, it’d probably be simpler if we just had one foundation that we could manage and take care of, instead of two…”, especially since a lot of the projects had strong overlap. So we had RequireJS and Lodash, which were quite popular in the jQuery community, and vice versa. So we merged, and then sort of rebranded and relaunched just the JS Foundation about two years ago.

Basically, the idea is it’s a home that provides support and protection for projects. The idea is not to fund development of projects. That kind of gets into some legal grey area around “Is this an open source foundation or is this a contractor in the middle?” But instead, it’s really just focused on providing the support for open source projects around community and legal rights, and support that frankly most open source committers are not really good at or don’t wanna think about, so it just kind of gives them the support they need around those areas.

You know, my hope has always been that the foundation would encourage projects to collaborate more, instead of reinventing the wheel. For example, with Dojo 2 we leverage the PointerEvents Polyfill, which is a JS Foundation project. We leverage Globalize, which is another project, we leverage Intern, which is the testing framework that’s part of the foundation, and we also use parts of Grunt for our development tooling…

[52:09] So the idea is really not to say “Hey, all these projects should become the same”, but if they have clear boundaries and API approaches, can they be used together in a nice way?

Chris Benson: Yeah. When I was watching the Intelligence Committee hearing that we’ve been alluding to in this episode this morning - that was a big issue, because a great deal of this involves First Amendment rights. For those who are not U.S. citizens, the First Amendment of our Bill of Rights, which is part of our Constitution, is the amendment that allows for free speech and for expression in the United States. There was quite a bit of legal-oriented back and forth. I’m not a lawyer, so much of that went right over my head; I won’t speak to that directly, but they really were talking about “How do you handle this without violating First Amendment protections?”

[48:04] Some good news is that this morning in the House Intelligence Committee hearing that we’ve been talking about over the course of this episode, they did in fact make some recommendations on how to contend with deepfake issues. There were six explicit points that were called out, and I thought I’d just cover not all the verbiage on each one, but just kind of the first sentence or so of each one, which gives you a sense of it.

The first was Congress should implement legislation prohibiting U.S. officials, elected representatives and agencies from creating and distributing false and manipulated content. As an addendum to that, they mentioned that the U.S. government - whatever kinds of statements they make, should always be the truth; the official government statements and policies should always be based in truth.

The second thing was that policymakers should work jointly with social media companies to develop standards for content accountability.

The third was that the U.S. government should partner with the private sector to implement digital verification signatures designating the date, time and physical origination of content.

The fourth one was that social media companies should enhance their labeling of synthetic content across platforms, and work as an industry to codify how and when manipulated or fake content should be appropriately marked.

The fifth was that the U.S. government from a national security perspective should maintain intelligence on adversaries capable of deploying deepfake content, or the proxies that they employ to conduct such disinformation.

And the final one they noted was public awareness of deepfakes and its signatures will be greatly assisted in tamping down the attempts to subvert U.S. democracy and incite violence.

Those were good, and I think the Intelligence Committee heard that. There was some debate about the legal issues regarding First Amendment concerns, but it was good to see them wrapping up with potential ways forward to mitigate the dangers that we’ve been talking about on this episode.

Joseph Jacks: I would say a lot of those things are connected, or sort of inter-related, slightly. Maybe just to summarize a thought of looking at Commons Clause - maybe it’s like a stepping stone or a building block. There’s a useful way of framing this, which is if you look at the problem and then reason up from there, it’s maybe easier to understand all the moving parts, because there’s quite a lot of things happening in this area.

I think the problem can be summarized as “We don’t have commercial open source licensing agreements.” We don’t really have industry agreement around how to implement the protections for products that are built fundamentally on top of a given open source project, or a small number of them… And that’s where we have all this inefficiency, and duplication of effort, and lots of overhead in terms of legal effort we spend.

Commons Clause was really an effort to protect against a couple of things, and Redis certainly has a focus area in terms of their relationship with cloud providers. I’d prefer to hold off on commenting there specifically, given that’s a pretty hot topic.

Chris Benson: [00:05:59.23] So I don’t think you’ll be surprised when I say this, and we’ve alluded to this on some previous episodes… But it is a difficult business concern to navigate. I know all of us who straddle into the AI technical realm are incredibly excited, we’re trying to figure out how to do the models, and put them out there, and everything like that… But if you are not in our shoes, if you’re walking on a slightly different path, and let’s say you work for a legal department, or a compliance department, or other business concerns, and suddenly these technologies are coming at you hard and fast, week by week in 2023, and you’re trying to navigate that, and look at things like licensing on how the data that goes into models is used, and you’re looking at compliance concerns, and you’re looking at protecting your intellectual property… There’s a whole host of challenging business problems with essentially no guidance. This is a brave new world that has to be pioneered through, and so I have talked to a lot of businesspeople in various roles, including attorneys, and this stuff is scary stuff. It is problematic stuff, it is challenging to navigate. And I definitely want to take you down the path today of talking about the space, and Prediction Guard, relative to how you actually get these models out there in a productive way, in a business environment, so that people can take advantage of the technology, and understand what the pitfalls are, and such.

So that’s the big thing that I’ve been hearing… I’ve been getting an earful of it lately, like “Chris, settle down. Stop taking us down this AI thing. We’ve got to figure some things out first”, so I’m coming to you for answers, man.

Rosemary Wang: It’s not a crazy idea. I think there are folks, or whole organizations, with more than one developer, more than five developers, hundreds of developers, doing this. But again, they have a lot of these systems, a lot of fail-safes in place, they have a lot of structures within teams to understand the risk of, let’s say, accidentally doing something they weren’t supposed to do. And I think that’s also dependent on industry, and it also depends on who your user is, right? I mean, I think if your users are pretty tolerant, pretty tolerant of these changes in general, then it’s probably not the biggest deal. But if you’re watching some video and you really don’t want that video to have any latency, you don’t want it to stop, because you’re watching a live concert or something, you’re not going to have much tolerance for when someone pushes that change out and it goes down.

So I think that, again, we put a lot of these gates in place, or we put a lot of this friction in place, partly because there are financial, as well as legal, as well as I think general functional ramifications for bringing down a system, and we’re slowly moving to a mindset where we’re trying to be more tolerant of downtime, as engineers to understand how to debug a system, recover it quickly… And to a certain degree, find out ways to make it more resilient, so that it’s not affecting an end user, and we can still be comfortable pushing to production. But I think it takes a lot of work.

[01:06:13.21] Actually it works okay for a small team, to be honest, pushing straight to production. It works fine. I mean, I have nothing against it. But when you start getting to hundreds of people trying to coordinate changes, really large systems that are supporting things 24 hours a day, seven days a week, really high expectations from a user perspective, that’s where you might need to add a few either pieces of automation, or even more sort of natural control in place just to make sure people are disciplined in the process of pushing the changes out.

Luis Villa: So let me first just start, for those who aren’t copyright nerds in the audience - and why you’d be listening to us if you’re not I’m not sure, but… We’ll start with a little bit – so fair use is this very American concept; it’s not present in a lot of other legal systems around the world… That copyright should be bounded. That yeah, of course, we give authors a lot of rights; it’s very explicitly in the constitution that we give them rights in order to promote the progress of the country. That’s literally the phrase.

There used to be a copyright blog called “Promote the progress.” The idea was that this was something that you gave to authors, and in exchange they made everybody better off. So in part because of that, sort of founding intuition, first the U.S. court system and then eventually it was transferred from – the courts sort of (to put it a little bit in programming terms) prototyped fair use; they sort of made it up on the fly when they ran into some problems… And then the Congress sort of took those ideas that had been floating around the courts for several decades at that point - maybe even almost a hundred years at that point - and Congress sort of refactored it and said “We’re gonna steal a phrase from one court here, and a phrase from another court here, we’re gonna put it together into one refactoring, make it part of the law, and then judges will sort of go on elaborating and clarifying that.”

So this was done in the transition of fair – if I’m remembering my timeline correctly, the transition of fair use into actual statutory law, written down law, as opposed to judges sort of making things up on the fly, happened in the ‘50s. So very much the examples - if you go back to what was Congress talking about, they were talking about things like teachers. So if you want to use a few minutes of a movie in a classroom to teach some point, fair use protects that. Fair use says “The copyright holder can’t just unilaterally block that.” Or another canonical example is literary criticism. If you wanna quote a paragraph of a book in order to prove a point about “This author is an asshole”, then you can do that; fair use allows you to do that.

[24:01] Chris, to your point about it seems like it comes up in court a lot - the whole thing about fair use is that it is sort of “I know it when I see it.” There are some guidelines, there’s a four-factor test that everybody applies… But the fourth factor is sort of like “Yeah, and whatever else we wanna throw in at the time.” That’s because the whole point of it is like “You know what - people may be doing something new and different and innovative with this stuff, and we don’t want authors to be able to block that if we think it’s a good idea.” That’s sort of the core of it. So “We think literary criticism is a good idea.” And important there to note that it’s criticism.

One of the reasons that we have this fair use established is because if copyright holders could block that kind of use, then you would only have positive reviews of books. The authors would be able to say “Yeah, I didn’t really like that review. Take it down.” They would be able to use copyright to block that.

So baked in from the very beginning of fair use, one of the things is you really don’t want authors to be able to just say “Eh, I’ve got a bad feeling about that done.” You want copyright to have some sort of safety valves for “This is really important.” Similarly, news reporting fair use is used all the time, to be able to say “Look, here’s a 10-second snippet of this politician’s ad”, for example. “We think that this politician’s ad is misleading. Let me use this 10-second snippet to set the stage for this discussion of why this politician is misleading you.”

The creators of that advertisement have copyright in that 10-second snippet. They could – if copyright didn’t have the escape hatch of fair use, they could use copyright to take down that news segment, because they obviously don’t like that the news reporter is saying “The politician is lying to you. Here’s why.”

So copyright originally existed for all that kind of stuff. But of course, it was written in the ‘50s. It literally has no concept of software, much less machine learning. So there’s all this settled stuff – like, academics don’t sue over fair use very much, because that stuff was all settled a hundred years ago. Whereas software - it comes up quite a bit, because in fact we have no idea. Congress has never really weighed in on this; courts only weigh in on it once in a blue moon.

A lot of the arguing in Google Oracle over “Is this reimplementation of the API a fair use?” I mean, one of the key cases in that was Lotus v. Borland, which was about whether the dropdown menus on an x86 PC in black and green on your CRT screen - a court found that those menus were a way of operating the spreadsheet in the 1980s… So here we were, 30 years later, and one of the things – Nick, you mentioned about judges, how much tech do they know… We were trying to tell them, “Well, look, the API is sort of like a menu in a spreadsheet in the 1980s… And how is any reasonable person supposed to find a reason –” So yeah, tons of grey area, and that’s where fair use them comes in.

This question has come up a lot recently in these questions of – we joke that you could write an entire casebook… A casebook is like a legal equivalent of a sort of intro to programming kind of thing, where you take snippets around like fair use of these cases, and you say “Well, here’s what a judge found about this. You budding lawyer should learn about the law by reading what the judge says about this.” And we often joke that you could write an entire casebook about copyright just through the lawsuits that Google has been involved in… Because early 2000’s, they were just like “You know what - we’re gonna scrape the whole web. It’s gonna be great. We’re gonna organize all the world’s knowledge.” And average people were like “Yay! Organizing the world’s knowledge.”

Luis Villa: So let me first just start, for those who aren’t copyrighters in the audience - and why you’d be listening to us if you’re not I’m not sure, but… We’ll start with a little bit – so fair use is this very American concept - it’s not present in a lot of other legal systems around the world - that copyright should be bounded. That yeah, of course, we give authors a lot of rights, it’s very explicitly in the constitution that we give them rights in order to promote the progress of the country. That’s literally the phrase. There used to be a copyright blog called Promote the Progress. The idea was that this was something that you gave to authors, and in exchange, they made everybody better off.

So in part because of that sort of founding intuition, first the U.S. court system, and then eventually it was transferred from the court sort of, to put it a little bit in programming terms - the court’s prototyped fair use. They sort of made it up on the fly when they ran into some problems… And then the Congress sort of took those ideas that had been floating around the courts for several decades at that point - maybe even almost a hundred years at that point - and Congress sort of refactored it and said “This is how we’re gonna steal a phrase from one court here, and a phrase from another court here, we’re gonna put it into one refactoring, make it part of the law, and then judges will sort of go on elaborating and clarifying that.”

This was done in - if I’m remembering my timeline correctly - the transition of fair use into actual statutory law, written-down laws as opposed to judges sort of making this up on the fly, happened in the ‘50s. And so very much the examples, if you go back to what was Congress talking about, they were talking about things like teachers. So if you want to use a few minutes of a movie in a classroom to teach some point, fair use protects that. Fair use says the copyright holder can’t just unilaterally block that.

Another canonical example is literary criticism. If you wanna quote a paragraph of a book in order to prove a point about “This author is an asshole”, then you can do that, and fair use allows you to do that. Fair use does – Chris, to your point about “It seems like it comes up in court a lot…” The whole thing about fair use is that it is sort of “I know it when I see it.” There are some guidelines, there’s a four-factor test that everybody applies… But the fourth-factor is sort of like “Yeah, and whatever else we wanna throw in at the time.” That’s because the whole point of it is like “You know what - people may be doing something new and different and innovative with this stuff, and we don’t want authors to be able to block that if we think it’s a good idea.” That’s sort of the core of it.

So we think literary criticism is a good idea, and important there to note that it’s criticism, right? One of the reasons that we have this fair use established is because if copyright holders could block that kind of use, then you would only have positive reviews of books. The authors would be able to say “Yeah, I didn’t really like that review. Take it down.” And they’d be able to use copyright to block that.

[24:30] And so baked in from the very beginning of fair use, one of the things is you really don’t want authors to be able to just say “Yeah, I’ve got a bad feeling about that.” Done. You want copyright to have some sort of safety valves for “This is really important.” Similarly, news reporting fair use is used all the time, to be able to say “Look, here’s a 10-second snippet of this politician’s ad”, for example. “We think that this politician’s ad is misleading. Let me use this 10-second snippet to set the stage for this discussion of why this politician is misleading you.”

The creators of that advertisement have copyright in that 10-second snippet. They could, if copyright didn’t have the escape hatch of fair use, they could use copyright to take down that news segment, because they obviously don’t like that the news reporter is saying “The politician is lying to you. Here’s why.”

So copyright originally existed for all that kind of stuff. But of course, it was written in the ‘50s. It literally has no concept of software, much less machine learning. So there’s all this settled stuff – like, academics don’t sue over fair use very much because that stuff was all settled a hundred years ago. Whereas software - it comes up quite a bit, because in fact we have no idea. Congress has never really weighed in on this courts only way in on it once in a blue moon. A lot of the arguing in Google/Oracle over “Is this reimplementation of the API a fair use?”

One of the key cases in that was Lotus v. Borland, which was about whether the dropdown menus on an x86 PC in black and green on your CRT screen - a court found that those menus were a way of operating the spreadsheet in the 1980’s. So here we were, 30 years later, and we’re trying to – one of the things, Nick, you mentioned about judges, how much tech do they know… We were trying to tell them, “Well, look, the API is sort of like a menu in a spreadsheet in the 1980’s… How is any reasonable person supposed to find a reason–” So yeah, tons of grey area, and that’s why fair use then comes in.

This question has come up a lot recently, these questions of – we joke that you could write an entire casebook… A casebook is like a legal equivalent of a sort of intro to programming kind of thing, where you take snippets (ironically through fair use) of these cases and you say “Well, here’s what a judge found about this. You budding lawyer should learn about the law by reading what the judge says about this.” And we often joke that you could write an entire casebook about copyright just through the lawsuits that Google has been involved in… Because in the early 2000’s they were just like “You know what - we’re gonna scrape the whole web. It’s gonna be great. We’re gonna organize all the world’s knowledge.” And average people were like “Yay! Organizing the world’s knowledge.”

Peter Wang: Yeah, so there’s actually not very much that’s competitive with our package – we call it the commercial license of Anaconda… Because ultimately, what we’re solving is a very unique, but important problem, which is the software supply chain. Now you see a lot of companies – it’s actually shocking to me, because I’ve been involved in open source since ‘95, in the early Linux days, but even today, there are companies that are just starting to understand “Oh yeah, maybe we should figure out how to use open source in a governed way.” They’re starting to have that conversation at the CIO and the IT leader level.

When it comes to ML and AI, the ecosystem moves so fast… It’s a whole Wild West of things out there. Anaconda is basically the only company that is out there as your last outfit, or between civilization and the Wild West… So if you actually want a build of NumPy or of scikit-learn to go and run on your customer-sensitive PII HIPAA data, and not have it just come from some grad student’s server somewhere under their desk, you have to talk to a vendor; you have to have someone who will actually talk to your legal people, sign on some lines… We’re that. We’re it.

So we actually are compatible with a whole host of other – I talk about how our ML platform is competitive with things like Domino, or maybe a SageMaker, or some of these other things… But our package server in our commercial license for the Anaconda distribution is not competitive with those things. It goes hand in hand with those things. In fact, we have a partnership with Red Hat, a partnership with IBM that we’ve just announced earlier this year, where our package server in those commercial license packages - that is going out to the world via those channels… Because again, there’s not much competitive with that.

So what the CIO should be thinking about is “How do I govern the software bits that actually run? This Docker, this three-gigabyte opaque binary that my data scientist intern just handed me - how good do I feel about running that in production? If I want actually some transparency into it, if I want repeatability…” An aerospace manufacturer was talking to me at PyCon a couple years ago, and he said “We have to demonstrate to the FAA that we can run these wing models 50 years. 50 years after the last plane rolls off the line.”

Karl Fogel: Yeah, I think the past ten or fifteen years was a time of experimentation among CLA. For listeners who don’t know, a CLA is a Contributor License Agreement, which is basically like there’s some upstream open source project that you wanna contribute some code - maybe you fixed a bug or added a new feature for them - you send in your changes, but they want you to also send in some kind of assertion, digitally signed or maybe fax in an actual real signature saying that you are giving the project this code donation and all future donations made via the same mechanism under a certain open source license or under certain terms, so that they can incorporate it safely without any fear of legal repercussions later into their codebase. The idea is later if you change your mind and you’re like “I didn’t give you that code to distribute under the GNU general public license, I’m suing you now”, they can say “Well, we have the CLA that says you can’t turn around and do that.”

What some companies started doing - and they’ve mostly stopped now, because this got unpopular, although a few still do it - is they would have CLAs that would say “You agree that you’re donating this code to project XYZ and that we, company Q, which is a major sponsor or the founder of project XYZ, are allowed to redistribute your changes under any terms we want.” That includes the open source project license to the project, but it also means that they could make a proprietary fork of the project. Some of these companies did that in order to retain the right to do a proprietary fork, or sell licenses to, or something like that.

Those kinds of CLAs have gotten pretty unpopular, because a lot of developers just said, “Well, I’m not gonna give you asymmetrical rights. I’m giving you code under the license here, giving the world, including me, code under license. Let’s just keep it symmetrical and not give you rights that I don’t have.” This became objectionable enough that then when a company or a project would set up a CLA of that style, they would just immediately be noise.

What surprised me though - this is something I discovered during the research for the book, and I have to give a shout out to Bradley Kuhn, who follows this stuff; he’s at the Software Freedom Conservancy, and was able to tell me a lot about what had changed in the CLA landscape and point me to examples. It’s that not only have those particular odious kinds of CLAs become less popular, but CLAs in general have become less popular. More and more projects have just said, “Look, as long as you certify that you are the author of this code or that you have the right to contribute it under our license to the project, and that we can redistribute it under that license, then we’re good.” So that’s not really a licensing agreement for the contribution, it’s called more of a DCO (Developer Certificate of Origin) where you assert, and usually an email or maybe a digitally signed document of some kind is enough to just say “You have this code. Here’s my DCO, and now we don’t have to sign anything or have an agreement.”

[20:20] So I think the world is moving more toward DCOs. There are still CLAs out there. Some projects have important reasons why they need a CLA; for example, apps that are gonna be distributed in the Apple App Store but are free software under a copyleft license, there are various things about the Apple build and production process that get things in the Apple Store where the terms that the project has to agree to with Apple are not compatible with the GPL, so the developers who contribute all have to sign a CLA with the project, where that gives the project enough of an exception to the GPL to be able to sign this agreement to get the thing in the Apple Store, but otherwise the project is under GPL.

There are some cases where CLAs are still necessary and many other cases where projects still use them and people generally agree with them, but I do a general move away from complicated or onerous CLAs and towards simpler, more lightweight things like DCOs. I think - although I should stress that this is not legal advice to anyone - my business partner and friend James Vasile, who is a lawyer, has observed some of the same trend and clued me into it, so I should give him some credit for keeping tabs on this as well. Does that answer your question?

Raphaël Simon: Sure, yeah. So let’s start with my who am I. So I’m a platform architect at RightScale. RightScale is a cloud management platform. I’ve been working there for almost eight years. When I started, the whole product was basically a single Rails app, and the platform has grown a lot since then. The last time I counted there were about 52 different services running in production, running on about a thousand VMs. So I’ve helped design, develop and debug a lot of them.

Part of going from this single Rails app to all those distributed services, we felt a lot of pain in having to design API’s the right way. What I mean by that is being able to come up with APIs that are consistent and have standards that are enforceable, so that we can come up and say, “Yep, that API looks good. It follows all standards and we’d be able to integrate that service with the rest of the fleet.”

As you probably know, once an API is alive it’s almost impossible to change it. Once you have customers that start using it or once your internal services rely on it, then that API is gonna be there forever. So it is very important that you spend the time designing it properly.

When we looked at what was available to do that, there just wasn’t much. There were a few tools here and there, but nothing that we felt would be enough for us. So we ended up creating a framework at the time, a framework in Ruby called Praxis, that basically allowed you to write the design code and then the framework would leverage the design in runtime.

Going fast forward, RightScale kind of shifted towards Go, and I thought it will be good to see if we could do something like that in Go. To be honest, I wasn’t sure initially that will be possible. We played around with a few things, and it took me about a year really to come up with something that started to look like it may work. There were two big a-ha moments in that kind of research phase. One was the realization that code generation was the perfect approach for achieving the goal of keeping the design and implementation separate. We were making sure that the design is directly enforced.

[03:51] The second realization was that the design should be written in a DSL, so that the language used to describe the API used the right terms. You want to talk about resources, actions, responses, requests, and you don’t want to have to deal with programming language artifacts, so that DSL will have to be a Goa DSL obviously, so that it could be understood right away, and also so that it’s still possible to use the legal language when it’s needed.

Fast forward a year and a half, I have to say that the result turned out a lot better than I thought it would be, and I think the credit goes to the Go language. The Go language provides a very simple and powerful mechanism to create the DSL. It also has as very good code analysis support, which is essential and a very good code generation package, the template package in particular.

So all of that put together, I think, we end up today with something that is actually very interesting, and we have started using Goa fairly extensively here at RightScale.

Preston Doster: [00:40:08.18] Yeah, exactly. That was a big part of it. Transferring it to like a foundation – again, [unintelligible 00:40:12.03] basement was a big part of it as well… And then also starting to even think about things like data residency, and just thinking about the different legal jurisdictions that we operate in, where we have folks who have data… And it was like “Okay, hey, we’re going to move to the EU very specifically, as a very specific choice, and Germany as a very specific choice”, because of the protections offered there, and the strength of those laws.

Natalie Pistunovich: No, I definitely share this view that this is a great choice, although it’s not the trivial one. And I do think that as AI kind of bubbles into any field, like legal tech or agritech or whatnot - this is all becoming things of how do you serve your AI model. One thing is kind of have it trained and running, but then comes everything else. And there is a wonderful paper by a group of Googlers from 2015 about the technical debt of AI systems, and it’s kind of what happens when you patch up a system that does ML and quickly upload it to production. And it lists over 12 or so pages of everything that can go bad, and all the considerations you should have. And it’s things that, in the past, you may have not thought of them in the context of systems that serve AI, but you just thought of them as kind of general systems, so any website. But monitoring, security, all the additional stuff, like making sure that things are working - all these systems, it’s the wonderful ecosystem of infrastructure that already has the perfect ecosystem inside Go. Everything you need is already there. So plugging those two together is even a better reason for using Go, because Go is really fast for serving your model and also really useful for monitoring everything.

Matthew Carroll: I think the reason that you are concerned is that there’s really no frameworks to automate this, so there’s now this massive legal burden on the data scientist, who is typically not a lawyer, to expound on why they made certain decisions, what data was used, who potentially was in that data, for what purpose. So it’s not just about data provenance any longer, but it’s also what types of activities were taken to ensure that there was proper ethical curation of the data itself before the model is being trained. And then it’s what are the guardrails put in place to ensure that you’re controlling the model as it’s put to production.

[20:29] These are things that – historically, we’ve had guard rails in place through software, through SaaS; they’ve always had these guardrails in place, and other types of software kind of automated a lot of these controls. And now the problem is that the ability for anyone to be a data scientist and use the data and use open source tools - they just don’t carry the rigor that’s required, and I think that it’s not just the GDPR, but we’re seeing now even in the U.S., California is looking at enacting legislation around data privacy… This is something people care about, because what they’re afraid of is the open source community in large organizations like Google, Microsoft and Apple are making it easier and easier for anyone to be able to design these models because they’re incentivized to buy up small little AI companies… So we need to put rigor into guard rails around these pieces of software.

It’s tough, and it’s hard, and people aren’t educated around the law, so that’s what makes it even scarier.

Tracy Hinds: Oh my goodness, okay. So I am the education community manager… I get to wear a bunch of different hats. It’s sort of along the lines of what people – a lot of people don’t realize what the Node Foundation does or what it’s like to work full-time in open source.

A couple things I’d like to say first is that there is not as much coding as you would imagine, and sometimes that’s sad… But a lot of the focus is around people, and sort of working on helping people collaborate together, especially when it’s really tough for them to do so. The other part of that - the Node Foundation itself is this mass of different groups that work together.

There’s the Node Project itself, which is comprised of the TSC, which is the Technical Steering Committee. Under that (I believe that’s the way it’s structured) is the CTC - Core Technical Committee. Those are people who are working on the codebases in different working groups for the code that makes Node run, as well as documentation, evangelism and things like translation.

Then there’s the Community Committee, which is very newly chartered. That is a place that was created that I helped get chartered at the beginning of this year, after we’d worked on it for quite some time, to give voice to community. So that’s really interesting, because a lot of programming foundations don’t have that level of voice.

[36:01] Community is a very weird, ambiguous, handwavy word because it’s communities - it’s a whole ecosystem of groups around the world, and it can be people who are writing npm packages, or it could be projects like Express, or… The TSC is part of the community, as well. Then you have all of these events, like Node School and NodeBots, who have helped keep Node a thing.

When their code isn’t changing a lot or we’re not really hearing a lot from the core project itself, there are people who are still around the world, using this in production, and using this for fun, and they still need to learn this code, so those communities are really helping keep that there.

That’s nice, because advocation also fits in there. As we’re growing the foundation – there’s also the board. The board is this group of corporate members and representatives from individual members of Node, who come together on a monthly basis and work together in between those meetings, to sort of figure out and support the project the way it needs to. Their responsibility is more towards legal, making sure that the foundation is protected - because I think a lot of people don’t realize that as individual programmers, we put license on things for a reason, and part of that is that you can be sued. Some of that liability is provided by the foundation… That and administrative stuff; helping to encourage companies that they should have people who are writing Node full-time in their offices. And that’s really nice, because that means that a lot of us have jobs working in that, because that can be hard to come by in other programming languages, and I think a lot of people take that for granted.