 Howdy folks, and welcome to how open governance influences open source and inner source at GoDaddy. My colleague Jonathan and I today will be talking about this subject. For those of you who don't know me all that well, I've been doing Node for over a decade now. And I've written many, many open source libraries that you've probably written. In another life, I was the founder and CEO of a company called Nodejitsu. And we were acquired by GoDaddy in 2015, which is the beginning of our story, which I'll talk about in just a minute. During that time at GoDaddy, I have been the founding board member of the NodeJS Foundation and most recently founding board member of the OpenJS Foundation, both at the gold tier. Now, as I mentioned, Nodejitsu was acquired by GoDaddy in 2015. And one of the things that really became poignant to me during that time was something referred to as Conway's law. I won't spell it out for you here, but it basically means that software system will start to resemble the organization that it was created within. Or, as Drucker puts it, culture eats strategy for breakfast. So without going into too many details, as I've talked about building software elsewhere and other talks, we're going to talk a bit today about how open governance works for our internal groups, such as our open source working group. Now, this was created very shortly after I joined GoDaddy. And one of the things that was really poignant about it was that we wanted to push decisions to the engineers, the subject matter experts, as a voice to sending content into a black hole or to get approval from some set of approvers that you may or may not know. We actually have a simple release process that allows for a set of reviewers that is all engineers to decide whether or not something is fit for release. Obviously, there are a trademark and other implications that need to be reviewed by our legal team as necessary. But it's really been a very successful group internally at the company. Now, this went on for a few years before something else started to emerge. And that is emergent open governance more broadly. Specifically, what started to be clear is that the volunteers, because this is funded as an employee resource group, as my colleague Jonathan will talk about shortly, was that once they became motivated, they stayed motivated because they understood the mission of the working group that they operated in and wanted to keep going and go deeper. Now, right around a few years ago, we had an engineering blog turnover. Prior to that, our engineering blog had been managed by a single person with a single approver, which took quite a bit of time, because as a large engineering population writing content, having a single reviewer is simply not enough. We had a few employees who wanted to organize the engineering blog themselves. And so this emergent open governance became true open governance, i.e., the flattening of a pyramid structure with a single approver into a graph or a network, pushing the decisions down just as we did with open source. Now, the real key here is direct action. And really, it's this essential thing that says you're not going to wait for someone else to do it for you, you're simply going to do it. Obviously, if you read a bit more about direct action, you'll see it come up in some anarchy literature. But it is very poignant here. And to talk a little bit more about where we went with this, I'll hand it over to my colleague, Jonathan. Thanks, Charlie. As our internal and external community engagement grew, so did our need for structure and governance. So we created GD Open. GD Open is GoDaddy's nexus of technology and community. It provides a model for open and formal governance that's extensible and repeatable, and it's fostered and supported by leadership. Structurally, GD Open is fairly simple. There's a top-level steering committee that handles chartering working groups, spinning down old ones and supporting programs across them. But the real work happens inside those working groups, which are focused on driving one or more business and or community needs. GD Open was modeled after the Node.js working group. Working groups go through a lightweight charter process to align on purpose and processes and agree on a set of metrics to target. Starting a working group is easy. We provide a GitHub template that includes a base charter and metrics statement, as well as process docs to help keep things consistent between the working groups. We require at least three members to form a working group to make sure there's enough massive interest in the space. Membership is documented in the working group repo, so joining is just a pull request away. Since GD Open has managed as an employee resource group, these working groups fit into existing funding models and have access to corporate resources as needed. So let's get to what working groups are. Working groups are bodies meant to drive business outcomes or policies around internal and external technical communities. They're often formed across disciplines. For example, our engineering blog working group brings together engineering, PM, public relations, and even recruiting. They range across a mix of technical and non-technical areas. Charlie touched on the history of the open source and blog working groups, but I'd like to tell you about another one. A couple of years ago, I helped co-found the interviews working group to help concentrate efforts to hone our engineering interview process to try to make it more of a delight for candidates and the interviewers. Driving this process through GD Open gave us visibility into other parts of the company working towards the same goals. In fact, our head of recruiting is a member of this working group today. Now I wanna dig in a step further and talk about guilds. Inspired by Spotify's model, guilds are groups of people who rally around a technical topic, be it a programming language, technology, or tool. They're for sharing best practices, discussing new developments, and fostering a community of practice, but we're also careful to define what they're not. Guilds are not for tackling business goals, setting standards, or managing infrastructure. They're communities for folks to come together to learn, share, and grow. On the left is the initial set of guilds that were formed. Over time, the list grew, new languages, new technologies, new communities. Because the bootstrapping process is so lightweight, folks felt empowered to start up a guild whenever there was common interest. Guilds made a home for tech talks, demos, and collaboration. Guilds have kept forming, some starting as just a Slack channel and eventually becoming more formal. While the early guilds were primarily made of engineers, some newer ones are being formed across disciplines. For example, product managers across teams came together to form the navigation guild to share best practices and new developments in wayfinding and information architecture. The desire for community was always there. The guild model simply provided the scaffold for these communities to flourish. GD Open also serves to manage our external technical community engagement. This includes participating in standards track organizations, trade groups, and external open source. For example, GoDaddy is a member of ECMA and participates in TC39, the committee that specifies the JavaScript language. Engineers at GoDaddy have championed proposals such as ES modules, optional chaining, and null coalescing. And we informally participate in other standards track bodies such as what WG and W3C. We also participate in various trade groups and foundations including the OpenJS Foundation, Domain Name Association, and we were founding members of the NodeJS Foundation. GD Open helps us coordinate these investments across the company. GoDaddy is a big believer in the open source model. We frequently release projects to open source. Here are just a few. All of this is managed through the GD Open open source working group, the code review process, license and documentation standards, and the nitty gritty logistics of posting code to GitHub. And by managing this process in GD Open, it sits close to other relevant working groups such as our engineering blog group so it can announce these releases broadly. GoDaddy engineers also contribute frequently to existing open source projects. Here are some of the larger contributions over the last few years. Our open source working group manages the processes to contribute code externally and ensures that folks feel empowered to pitch into the community. We've shared a lot about our models so far but this is a hard problem. We don't have all the answers. We've got some ideas to keep growing like sponsoring open source projects both at a company and individual level and formalizing a process for engineers to safari on to open source projects. I hope that this talk gives you some ideas on how to bring open governance and structures to the technical communities in your organization. We'd love to hear your ideas too. Reach out on Twitter to start the conversation. Thanks so much.