 Good morning DrupalCon! I hope you had a fantastic Tuesday night in Nashville. I'm Rachel Lawson, I'm the Drupal Association's community liaison. I only started in January so I'm still learning everybody. And although I've been in the community for a decade, this is my first DrupalCon North America. I don't know whether that means I actually get extra points in the trivia tomorrow night. I wanted to just take a couple of minutes to talk about community and particularly a phrase that keeps coming up that we all try to live by, come for the code, stay for the community. Now I did come for the code for Drupal about 10 years ago and I used Drupal for a little while and then just to make my life even more complicated, I started to get involved in the community right at the same time as very publicly coming out. Now the first time I went to a Drupal camp, I was scared. I was scared because I was different or I felt I was different. I wasn't sure whether I would be welcomed or anything like that. I didn't know these people. It was Drupal 7 Camp in Leeds in the UK where I grew up. It was amazing. The people in there were so welcoming to me, even though I felt different. People like Dan Smith at the front there from my security team, people like Andrew McPherson a bit further down the line sat next to me when I used to have longer head dark hair before I started coloring it. Andrew McPherson is one of our accessibility maintainers. They made me feel welcome and it mattered to me. I kept coming back. I went to more Drupal camps. This is actually Frontend United in Copenhagen where I first was welcomed and encouraged to take part in Drupal contribution by amazing people like Lowry Eskola I think is here and Christina Chimales. They helped me feel that I could do this. I didn't think I could do code commits. It was like no way. Absolutely. They made me so that I could. It mattered to me. It mattered to me so much that even when I was unable to go to an event Frontend United in London it mattered to me that the organizers of that event in London people like Justine Pocock and Karen Leach actually came into the hospital while I was otherwise indisposed and brought me cakes and flowers and most importantly they brought me freebies of the camp t-shirts and stuff. It's one of my favorite t-shirts even though I never went to the event. It mattered. It made me feel welcome and it matters to me now being able to get involved in helping mentor others which I got involved in first of all at Drupalcon Amsterdam was really important to me. It matters to other people how we welcome them and encourage them in our community. I was invited to be fair I did hassle them a lot beforehand but I was invited into the Drupal community working group to help with the community and making sure that we can help resolve differences and so on. People like Adam Hill there and Jordana Fung and George Demet and Michael O'Neill and Emma Carriannis who run that do enormous amounts of work to try and help our community. It matters that we make people feel welcome and don't turn people away. So even though I started off in this community as somebody who just thought whoa I'm probably not going to be welcome here I was and it made a difference. We keep hearing this week and quite a lot actually about ambitious digital experiences. Well for me we only make digital ambitious digital experiences when we all are ambitious about how we welcome encourage and celebrate each other and we need to celebrate our successors. It really matters it matters to me and I hope it matters to you that's all the time I get to talk about things. I'd love to talk about the community more and more and more. I want to be able to talk to all of you but as well as community we are doing some amazing things. We have this promote Drupal campaign and some individuals named there and many companies so far have already raised 54,000 and nearly said pounds then 54,000 dollars of our $100,000 target to actually make Drupal be in front of the people's minds who we needed to be there. I would love to see us hit $100,000 very very soon. Get your checkbooks out. Anyway, some housekeeping because it is the start of another day. Coffee will be in the usual place. I severe a very kindly sponsoring coffee today. Lunch, please remember to eat and drink. You know good to us otherwise. 12 till 2. Usual place. There are some schedule updates. So getting real about agile presenters, Kelly Olbrecht and Sean Eddings takes place at 1045 in room 103B and the camp organiser survival guide presented by Joseph Derbenig at 345 is in room 101E. We couldn't run a camp. A camp? I can't. You can't run camps either without sponsors but cons too. You can't run without sponsors and we're so thankful to all these sponsors and it is a long list and we're very thankful. My goodness it is a long list and supporting partners as well who help us do things like actuallymakedrupal.org. I'm looking forward to meeting some of these people today. That is a long list. We can't do anything without the contributors making code, documentation, all the different things. Contributing is not just code. I need to get back on this list. I've been off this list. I need to do something about that. Okay. And special thanks to our top business contributors of which yet another long list which is great. I mentioned Dan Smith earlier on. Thank you again to our security team. Who's in the security team today here? Oh yeah we've got a few. Okay. Well what I'm going to do now is I'm going to hand over to Lynn from Acquia who's going to introduce you to our keynote speaker. Thank you. Thank you Rachel. Good morning. Morning. Hi I'm Lynn Kaposi from Acquia CMO. Very proud to be a sponsor, one of the sponsors of Drupalcon. And I have a couple of things to tell you this morning. First of all thank you to those of you who joined us at Tequila Cowboy last night. So it was fun catching up. And if yes, excellent. And if you did get there and you may be in need of some assistance this morning I'm happy to announce that we have Acquia Survival Kits. You can stop by the Acquia booth around this. So it's really everything you need to survive a Drupalcon. So there's some there's a little bit of vitamin C. There's hand sanitizer. There's Advil. And some band-aids just in case it didn't go so well last night. So feel free to stop by our booth. But I do have a couple of other reasons for you to stop by our booth. Please come by and say hello. We would love to chat with you. We have a couple of new things going on that we'd love to have you come talk with us about. We also have Drupal certification that's going on. And we so stop by our booth and we can tell you a lot more about that. We have the certification events that are going on. So please join us for that. We also have something new in the booth which is called where we have a this is like a proof of concept that we have from our professional services team. And it's a decoupled starter kit for React. So please come by. Basically it's a way for as a Java front-end or Drupal front-end developer to hook to a Drupal backend. And so it's a new kit that we've created, especially for developers. So please come by. We're just in the process. Again, it's proof of concept but love some feedback. So please make sure you come by if you're at all interested. And I know a lot of you a lot of there's been a lot of interest around decoupled. So please make sure you stop by and talk with us about that. We also have some new things going on from Acquia including our journey product for journey mapping for customer journey mapping. So please come by and ask us about that. We would love to see you and talk with you about that. And we have a giveaway for an Apple Watch. So if the survival kit isn't enough, if the decoupled starter kit isn't enough at least come by and talk with us and and drop your name in for the giveaway for the Apple Watch. So I'm also proud to be a sponsor for what Theresa announced yesterday around the Drupal effort around promote Drupal. Thank you. I was going to say marketing but I don't want to use that word. So around promote Drupal, proud to be a sponsor for that. And I would invite others to participate and sponsor with that as well. So just a quick commercial. At this point I'd like to introduce Steve Francia who's an open source leader and I'm going to let him give his background as it comes up on stage. Please welcome Steve. Okay. We are having technical difficulties. This is not where it should be yet. It's it's changing there but it's not changing what I see. Casey it's not changing what I see yet. I printed it out just in case I can go off my paper. Maybe I should start with that. We'll give him one more minute to try. Always be prepared. That's the secret of my success. That's right. Could you tell me when you do that because I want to go like this every just let me know. It's working. So Drupal has survived and thrived for 17 years because of one simple fact. It has embraced change. Although every open source project is unique there's a single evolutionary journey that all successful projects must go through. I've been fortunate to have been a critical part of the journey of five of the largest open source projects in history. I'm currently at Google as one of the leads on the open source strategy team responsible for the Go programming language. Today I want to share my journey through open source with you. I'll share the lessons I learned, the mistakes I made, and the role Drupal has played through all of it. It's far more autobiographical than I'm comfortable with and I hope you'll stay with me as we experience this journey of open source together. My story begins in the mid-1990s. Janko Jeans and Buffy the Vampire Slayer was the backdrop. I was still in high school and one of my hacker friends had gotten me a job at an early ISP that stands for internet service provider working as a UNIX administrator. This really was the dawn of the modern internet. Netscape 2 was a big deal. It's like 20 years ago. It's not a big deal. It was a big deal because it supported animated GIFs. The central server that ran our entire business was a digital alpha server with a 64-bit processor. This was 64-bit at a time when 16-bit was the norm. Digital Equipment Corporation was successful in their marketing gimmick of creating a search engine just to demonstrate how powerful their systems were at the time. Altavista running on an alpha machine could index the entire web and here I was barely shaving and responsible for running one. I remember that it was nice to look at. Visually similar-ish to Windows 95 which was recently released. I also remember you couldn't change anything. The code was all closed and controlled by Deck who sent periodic updates in the mail on CD-ROM. It was also crazy expensive. Each machine cost north of $25,000 and then there were software licensing fees of over $10,000 per year. That's $60,000 per server in today's money and we had two of them. Some time later we decided that we wanted to add Usenet support to our offering of web email and dial-up for our customers. For those of you too young to remember Usenet in the 90s was pretty much the reddit of the day but like most things at the time it was decentralized. Because Usenet was decentralized we needed to house our own Usenet server and I was tasked with setting it up. Without knowing the demand we couldn't possibly go with another expensive Deck alpha. Instead we decided to explore the free offerings. After reviewing the offerings we decided on running on free BSD running on an Intel x86. Since it was an additive service we felt comfortable taking the risk on free software which at the time was relatively unknown. As an aside we also considered Linux and Laft at its poor networking and overall immaturity. I worked at the ISP for four years and I learned a ton. I learned that Shift ZZ was the best way to exit VI. I learned that Unix admin people weren't that different from the plague from hackers. I learned that well experience matters in a new space everyone has to go through the same process of discovery and learning. Lastly I learned that free software could work just as well or better than proprietary software. In 1998 I stepped away from schooling and computers for two years to do missionary service in inner city Los Angeles. When I returned the world was a different place. Ska left as quickly as it came and was barely a memory for most people. Are you clapping because it came or because it went? I'm not. Free software had a new name. It was called open source. Google had changed the landscape with both its search as well as its approach to scaling using free software on top of commodity hardware. That's really what Google ran on in the 90s. Lamp had emerged as the stack for the internet. During this time period I enrolled in a computer science program at Brigham Young University. I started a software development company. I got married. I had a child. My wife told me not to put the picture in. I said every father or mother in the room knows exactly what's going on with me in this picture. So I did it anyway. I created the first object-oriented PHP framework and I also created an e-commerce CMS product. As the framework wasn't essential to our revenue I open sourced it and called it ZOOP. This was many years before anyone else was doing web frameworks and we struggled to communicate its value to others. I also didn't know how to run an open source project. We struggled to market it though somehow we ended up getting a decent size user base in Asia. I'm glad some people find that funny. We called our CMS super site. It was a mix between Shopify and Squarespace with some very advanced features including block-based drag and drop layout creation. We licensed it to some Fortune 100 companies but ultimately struggled to gain adoption. I'll blame this on my complete lack of understanding how a company should run. I followed what I call the field of dream strategy figuring that if you build it they will come. I built it and they didn't come and I struggled watching inferior products get more attention. Around the same time period another student built a similar CMS also using the LAMP stack. He called his CMS Drupal and unlike super site Drupal was released as open source. Drupal adoption group rapidly. I learned technology changes quickly and if you aren't willing to change too you'll be left behind. I also learned that it isn't always necessarily the best product that wins but the product that is able to reach the greatest number of people. Promote Drupal, right? Then it'll be the best and the most popular. Finally I learned that timing is critical. It's entirely possible to be so far ahead that the world isn't ready for it yet. In 2004 I graduated from college with a degree in philosophy and headed back east. To raise my family which was now four I took a job at a few startups in New York City. In 2006 I joined the second of these startups Portero, a luxury e-commerce company. It was at Portero where my path in Drupal's crossed for the first time. We built a beautiful website powered by Magento for the e-commerce portion and Drupal 4 for the content portion. We actually built decoupled Drupal long before that was really a thing. I built my personal website on Drupal and it turns out archive.org thought the content was important enough to keep but not the style so it looked kind of like this but with my content. I also set up my Drupal.org account and created a Drupal.org plugin and I was both amazed and horrified at the hook system of Drupal 4. I was impressed with Drupal.org and how much development and conversation happened there. I remember thinking that Drupal was pretty powerful and how many things it enabled you to do. I remember wondering if there would ever be a day when people would be paid to work on free software but nobody outside of academia was really paid to do open source yet. I left Portero and joined another e-commerce company, OpenSky. Initially the mission of OpenSky was to create a platform to empower content creators to monetize their following via authentic product reviews and sales. We did all of the sourcing, sales, and shipping while they curated the products they loved and placed an embedded checkout right there in their blog. I actually received a patent for creating the first online distributed checkout. We knew that people loved reading and hearing about what their favorite influencers had to say about products. We thought that if we removed the extra steps it would enable readers to purchase we would do right for everyone. Ultimately it was a flop. We discovered that people wanted reviews but not when they felt like they were being sold. The authenticity, well real, felt artificial when sales were introduced. A few months into the role we needed to pivot the entire company. They had outsourced all of their development previously. It was built on Magento and in spite of a relatively small amount of traffic it was unable to keep up with the load due to a data model that compromised performance for flexibility. Isn't that a perfect gif by the way? The pivot gave us an opportunity to start from scratch. It was a huge bet for the company and most of it rested on my shoulders. I decided we needed to move everything in-house which meant I needed to quickly build out an engineering team and also figure out which architecture to use. A lot was changing in the world. PHP 5 brought true object orientation to PHP. Drupal 5 was released which I upgraded my personal site to and Ruby on Rails was released and all of a sudden web frameworks were in vogue and for the first time since the 80s there was a movement to build an alternative to relational databases. I had the idea to use open source as a recruiting tool as in hiring experienced open source developers. I reached out to Nate, a fellow PHP developer and New Yorker and one of the primary authors of the cake framework. We went out to lunch. I didn't know it at the time but this lunch changed the entire course of my life. During this lunch he told me about his new framework, Lithium. We also discussed these emerging databases and I told him I was pretty seriously considering using Cassandra or Tokyo cabinet. Nate told me about an even newer database that he thought I'd like, MongoDB. We ended up building our platform on MongoDB in Symphony 2. We were very early adopters of both and the first company to use PHP with MongoDB. I hired a very capable engineering team including two of the core members of the Symphony team, Chris Wallsmith and John Wage. MongoDB was quite immature when we started development and we found plenty of bugs. Fortunately MongoDB's office was across 18th street in New York City and we frequently met with their engineers to work through issues. I still really didn't understand open source. I had created a handful of open source projects which never attracted a community of contributors or users. I had exactly one successful-ish open source project of my own which happened entirely by accident. This was my personal Vim configuration which I decided to put in a Git repo to make sure changes in one place replicated easily. I published it online in whatever we used for things like this before GitHub and since it was online people discovered it. Because it was well documented people started using it. Over time more and more people adopted it and today it's still one of the most popular Vim distributions. It was at OpenSky that Chris taught me my most valuable lesson in open source up to this point. Symphony had attracted some really talented people who volunteered their time on open source and I wanted to know how. I asked Chris how did he how did you get involved? He told me about when he went to a symphony conference to learn about it. Afterwards the creator of symphony Fabian was meeting with a few people about contributing. Fabian asked if anyone wanted to manage the release. Chris raised his hand. That was it. I couldn't believe it. It seemed like magic to get people to contribute all you had to do was ask. I also discovered it was possible to be employed to work on open source full time and not just as a hobby. I still didn't know how to go about it but John and Chris clearly did and I was a bit jealous. That's how I keep you wanting more. It was now 2011. I had four children and four less than successful startups under my belt. I decided to leave OpenSky and see if I could make working full time on open source a reality. I knew that MongoDB had transformed our development and I felt that it had the potential to fundamentally change how applications were going to be built forever. I met with the company leadership and they offered me a job. It had a salary but no title or role. I was very excited about the opportunity to work on open source full time but I was scared. I was throwing away my career. I took the offer in faith that everything would work out. Two weeks into the job I was feeling very out of place. Virtually everyone else there was a C++ programmer. They already had a manager of that team and I was glad it wasn't me. I spent time trying to get to know everyone and mostly that made everything worse. I had even less in common with them than I thought. More confused than anything I asked the founder, my boss, why he hired me. He told me that he hired me specifically because I was different from everyone else. I still felt out of place but at least I knew I had a purpose. I thought this might be too cheesy but people said no way the Drupal community is going to love it. As time passed I settled into the role of overseeing our user community, our drivers, our integration, our documentation. I was responsible for the user experience of MongoDB. The challenges we faced were overwhelming. At the time I joined we were the 40-something most popular database trying to overcome 40 years of inertia. This was easily the most established decision in technology. Nobody considered whether or not to use a relational database only which one. At the opposite side of the ring facing us was Oracle with their piles of cash and legions of salespeople and we had mugs. Not only were we trying to succeed in the space we're literally none had before but we were also trying to succeed as an open source company. To this point there was exactly one truly successful open source company and loads of unsuccessful ones. To make matters worse, the one success story Red Hat had taken a very different approach than we had as they were not the owners or creators of the software they sold. Questions kept going through my mind. Can we create a product that companies would be willing to pay for? Can we attract a significant user base? How would we distinguish our free from our paid offering? I felt overwhelmed and worried I wasn't up to the task. I knew that if we could create an experience that people loved then we would be successful. As a small startup the only way to do that was to go after developers and we did that by meeting developers where they already are. This meant finding places where developers were already building solutions with MongoDB and amplifying their efforts. It meant taking the good things that people had already built and trying to add on top of it instead of replacing it with our own built here solution. It also meant physically going to where our developers were and spending time with them. And too we needed to build delightfully idiomatic experiences collaboratively with our users. This meant trusting our users that they knew their language experience better than we did and we knew the database better than they did. Only together could we build something delightful. As part of this we decided to dog food everything as much as possible even if it was painful to do so. Any pain we experienced our users would have felt far more severely. My boss asked me to take over the responsibility of the website. Per our dog food policy we had already built our own CMS on top of MongoDB. It was functional but very hard to use for the marketing department. In all honesty it was hard for everyone to use. It also made no sense to create our own CMS. Our competency was in creating databases. What's worse it actually worked against our strategy of meeting developers where they were. We would be much better off taking an open source CMS and extending it to support MongoDB. Not only would we have a better CMS for our team to use but the CMS would gain functionality and scalability. After considering all the options there was only one viable one for us. Drupal. A quick search on Drupal.org turned up a plugin that someone had already written. It showed promise. I reached out to the author Chicks and decided to sponsor his development of the plugin and any related core work. I met with Chicks every week or so and we talked through his progress and worked through his challenges. We discussed that we would need to hire more people from the Drupal community to build out and maintain our site and Chicks suggested that I come to DrupalCon where I'd be able to meet him and the community. I thought it was a good idea and asked him when it was. He said it starts tomorrow. So I bought a plane ticket and I was on the next flight to Denver. Most weeks happen and you come out the other side a little closer to death but every once in a while every once in a while you have a week that changes your life. For my first DrupalCon was one of those weeks. I didn't know a single person in the Drupal community other than Chicks. I knew the name Drees but really nothing else. I met up with Chicks and he started introducing me to people. He introduced me to a bunch of people including Angie and the other core contributors. Later Chicks and I were discussing the entity field query design and he took me to another room and brought in David Strauss and the three of us whiteboarded out a solution. At the time I still had no idea that Chicks was a big deal in the Drupal community. I also had no idea that the people he was introducing me to were pretty much the inner circle of Drupal. What I did know was that DrupalCon was like nothing I'd ever seen before. I looked around and I was amazed at the excitement. I couldn't believe how many people there were. I couldn't believe the quality they'd put into the presentation of the conference from the banners to the stickers and decorations. I couldn't believe how many discussions were happening around architecture, strategy and culture. It might have just been the people I saw but it felt like everyone was part of something greater and felt responsible to make sure it was successful. That night I led above. The room was full of Drupalistas who wanted to talk about the opportunities MongoDB held. People were excited to hear that a module was in development and those who had used MongoDB in the past spoke about what advantages it offered. That night I went to bed exhausted with my brain spinning around what I just experienced. Nothing prepared me though for what happened next. I went to my first Drupal sprint day. I couldn't believe it. I still have a hard time believing it. I saw a giant room full of tables all surrounded by people engaged and hacking together on Drupal. Hundreds of people self-organized into pods to work on some of Drupal's biggest issues. What's more they were including and mentoring new people in large amounts. This trip was already one of the most valuable experiences of my life and yet I still hadn't accomplished the very purpose I'd come for to find someone to hire to build out our MongoDB website. I scanned the room and I saw one person who was wearing a MongoDB shirt. It must be fate I thought. Nervously I walked up to the table where she was sitting at. We began talking and I learned she was working on her Drupal distribution for conferences. Codd. She had her own distribution so clearly she knew her Drupal stuff. I described to her the project for MongoDB and she seemed genuinely interested. I started asking her questions about specifics and she suggested we start working on the website theme right there. In turn I asked her if she wanted a job and she said yes and I hired her on the spot. That's a true story too. To date that's the only person I've ever hired on the spot. Over the next few years I would learn a lot from Emily. Not only was she a fantastically talented engineer but she was also a Drupal superfan. She embodied the values of the Drupal community and her contagious enthusiasm was exactly what I wanted to create for my projects. Once I had seen what a successful open source community could look like I could never forget it. Drupal had opened my eyes to what open source could become. A vibrant engaged community with distributed leadership all working together towards a single overarching goal. A community where people felt like they belonged so much that it was family for many of them. From that day forward I made it my goal to Drupalify. I don't even know if that's a word but it was my word. I was going to Drupalify any project I was part of. I'd also made it my goal to give back to Drupal as much as I felt like I had gained from it. I was waiting to see if people would get it. Very good. Inspired by Drupal I returned to New York City energized to build out a similar community. MongoDB's biggest challenges were we were a commercial company first and an open source project second. And our open source license was less friendly than others. AGPL. It's important to recognize that each open source project is unique. I was inspired by Drupal and the potential I saw for MongoDB. However I couldn't just copy what Drupal did as it wouldn't have had the same effect in our different situation. We quickly learned the developer community's form within programming languages. This meant that our community didn't really know each other at all. We had influencers in each language but no one knew anyone else. If we ever wanted a community like Drupal we needed to bring them together. Inspired by the Microsoft MVP program and the Google GDE program we built out a similar program which we called Mongo Masters. These were community leaders who had created drivers, applications, businesses, etc with MongoDB. They had caught the vision and they were excited to share it. I'd learned from Drupal the value of people coming together in person. I scheduled the time and flew everyone to Silicon Valley where we had a two-day Uncon-style summit. The main goal was just having people meet each other and realize there were people in other languages doing the same thing they were. It was a complete success and our community had started. Over the next three years the enthusiasm around MongoDB exploded. It was web scale after all. Oh, that died. That was complete dead. Maybe this was a video it made us very famous. Maybe you all missed it. It kind of went viral. I took advantage of the fact that we had exploded as much as possible. I focused on hiring the right people who were already passionately doing the work that we needed done. Since our user base was diverse and varied, spread across dozens of languages, both human and computer, I knew our team needed to be too. I built out a team of around 80 people, most of which I hired directly from the community, including people from Drupal. With developer engagement, an all-time high and a business plan that hinged on developer adoption, we went out to meet our developers where they were. We held MongoDB Day's conferences all over the world. In these we tried to emulate the community feel and developer-centered experience from DrupalCon as best we could. We also sponsored and spoke at many external conferences, including DrupalCon. The next three years is a bit of a blur. MongoDB had grown phenomenally. It surpassed our wildest dreams. It was now the fourth most popular database behind Oracle, Microsoft SQL and MySQL. Major companies had adopted it for critical projects and the company was highly profitable. The business could not have been in better shape. The community had gone through an evolution. MongoDB needed a strong community at the beginning to establish momentum and take on the enterprise market. Once MongoDB stabilized, there wasn't anything to keep the community leaders engaged. As our business grew, our community shrank. We went from a couple of conferences to over 25 in one year and now we were down to a single annual conference. The conference audience had shifted to the enterprise, indicative of MongoDB's next phase. I knew I was the right person to have led MongoDB for those first three years. I also knew I wasn't the right person to take it to the enterprise. Leaving MongoDB was one of the hardest things I had to do. My passion was in building the community and creating the user experience. I succeeded in doing both and built up an amazing team who felt like family. As the company shifted to focus entirely on enterprise, I knew it was time for me to find a new place for my passion. I stood in front of my whole team and cried as I told them I was leaving. I didn't know where I was going to go next, but for the first time, I knew what it felt like to be a part of a successful startup, one that disrupted the industry and I knew I wanted to do that again. Permit me to rewind the story a bit. As part of my role at MongoDB, I was responsible for determining what languages and frameworks we supported. I had experienced personally writing seven of the languages. I prided myself on being a polyglot and commonly did code reviews and co-wrote design docs in all the languages we supported. I also kept a close eye on emerging languages. One language in particular caught my eye. It was created at Google by a trio of language luminaries. We adopted Go as our 12th language and it didn't take me long to realize I didn't want to be a polyglot anymore. Go had spoken to me in a way that no language ever had. To me, it just made sense and write and go made programming fun again. I spent my free time immersed in learning and writing Go. I've never been the kind of person to learn only by reading books and besides, there weren't any books written in Go yet anyway. I decided I needed a project. By this point, I had switched my vlog over to WordPress and while I liked the simplicity of the authoring experience, there was a lot of things that bothered me. I was frustrated how expensive hosting it was. I couldn't stand how often I had to apply security updates. I actually calculated it. I spent more time doing security patches than I spent vlogging. I hated how inefficient my static content was dynamically rendered for each visit. I decided I would switch to a static site generator and try to handful out. There were things I liked about each of them, but I couldn't get over the fact that they were all so slow. Since I was going to learn Go, I needed a project and I figured Go had to be faster than Ruby or Python. So I would learn to write Go by writing a static site generator and Hugo was born on the 4th of July in 2013. The following year, a pair of community members founded Go4Com, the first Go conference in Denver. I presented at the conference on MongoDB and Go, along with Gustavo, the lead author of the MongoDB Go driver. I arrived there a day early and walked around to see what was going on. I found the organizers and some friends stuffing Goody bags. I jumped right in and helped them. The next day, the organizers were up on stage and struggling to MC while also coordinating everything. Another community member jumped up and offered to MC for them and did so masterfully. Over 700 Gofers came to that first Go4Com. Here was the fledgling community that had the potential to be my Drupal. Like Drupal, there was there were people who saw the need for something and they jumped right in and volunteered. In fact, it had a lot of the same characteristics. Brilliant founders, commitment to inclusion and diversity, a product that solved problems across a broad space, and it had enthusiasm, lots of it. I was one of only a handful of people who had experience leading a successful company based on an open source project. Go's breakout application, Docker, approached me to help them try to achieve the same kind of success. I thought this would be a great chance to immerse myself in the Go community and apply everything I learned at MongoDB. As it turned out, I could not have been more wrong. Other than being open source, MongoDB and Docker had almost nothing in common. MongoDB entirely controlled MongoDB, Inc. entirely controlled MongoDB. Docker, Inc. was wrestling for control over their own project against industry titans, including IBM, Google, and Red Hat. At MongoDB, we struggled to get external contributions. At Docker, our biggest issue was that our very small engineering team was overwhelmed with contributions. The problem was so bad that any engineering they did was on their free time. Their day job was consumed with reviewing patches sent by others. There was also a secondary problem that while we received many patches, mostly from large corporations, the number of active contributors was actually shrinking pretty rapidly. Once again, I found inspiration in Drupal. Drupal is one of a very small number of projects that has figured out the secret to distributed leadership and contributor scale. Decisions are made by a distributed group of individuals. Innovations happen on the fringe before eventual adoption into core. Contributors are mentored and grow into more significant roles over time. DrupalCon and DrupalCamps provide an ideal nurturing environment for people to join the project. There's not another open source project in history that has been able to do this at the scale Drupal has. Taking inspiration from Drupal, I initiated three major efforts. First, we held a contributor summit in person. In spite of working together for over a year, virtually no one had ever met anyone else in person. We picked the 50 or so most active contributors and had everyone gather in San Francisco for an in-person summit. I created and ran the Docker birthday party. This was an ambitious event with the purpose to leverage the excitement around Docker to reverse the trend of shrinking contributors. Our contributors were normal sized and they stayed that way, but the number of them shrunk. It was entirely designed to replicate the DrupalCon sprint experience. We couldn't attach it to DockerCon, which was mostly a sales adoption vehicle rather than a community event. Instead, we leveraged our meetup network and held 26 parties in cities all around the globe. We flew a Docker engineer to each location and they joined with local leaders to teach people go and help them make their first contribution to Docker. Recognizing that we are a commercial company as well as an open source project, I wanted to reinforce the contributions to the project benefited everyone. For every contribution we received, we would donate money to a Wildlife Preservation Association. If we received 250 contributions, that would be enough to adopt a whale who we named MaliDoc. We ended up with over a thousand attendees, over 75 new contributors, and we received hundreds of contributions and MaliDoc has been part of the family ever since. At Docker, we constantly struggled with our tooling due to the simple fact, I'll keep talking now, due to the simple fact that GitHub was built for small projects. Of the many issues, perhaps the biggest one was that there was no way to collaborate on a pull request. We could either merge it or reject it. It was rare that a patch was ready to merge, yet rejecting it would have a very negative impact on morale. We wish there was a way to collaborate. We ended up defining a new term called, which we called carrying a PR or pull request, which is when we merged and then fixed up the pull request. We also built a ton of tooling around GitHub which helped to mitigate some of the scale issues but never came close to the collaborative workflow that Drupal.org has achieved. I was only at Docker for about one year. There was constant friction between myself and the leadership. I knew the only way our company would succeed was to give up some of the control of the Docker container engine and pivot towards the orchestration piece. They were unwilling to budge and we finally came to an agreement. They would agree to do things the way they wanted and I would agree not to work there anymore. After I left Docker I was feeling burned out. I'd been at six startups before they were even called startups, since before they were even called startups and I'd barely taken a vacation. So I took a few months off to spend time with my family to write more code. A couple months passed and things had taken a turn for the worse. By Thanksgiving I knew something was very seriously wrong. I was diagnosed sorry I've never talked about this in public before. I was diagnosed with two life altering and potentially fatal illnesses, Pobesia and Bartonella. These illnesses affect your blood and consequently every part of your body that depends on blood. I also had three very successful projects that I had started. Hugo, Cobra and Viper. At the time Hugo was the fastest growing project in Go, powering hundreds of thousands of websites. I felt like I owed it to my contributors and my users that I should work on the project. The illness prevented me from doing so. It was very hard for me to admit that I was no longer able to work on the projects that I had started. Telling the Hugo team that I wasn't able to work on it anymore was one of the hardest things I had to do. I had to step aside and give the reins to relative strangers. Thankfully people stepped up and filled the void. In particular a saxophone player from Norway named Bjorn took over Hugo and Cobra. Altogether I spent a year out of work during which I experienced great fatigue and depression. I was broken in so many ways. My body was broken with illness and my spirit was feeling like I had no worth. The only way I got through it was thanks to the support and love of friends, many of whom I had made through open source. There were four people in particular who stood by me and cared about me even when they had nothing to gain from me. You're already starting to cry I can tell which means I'm going to start crying. It's not going to be good for any of us. So the first of these was Megan who stood up on the stage yesterday. She gave me perspective at a time when I needed it the most. There was Sarah Novotny who gave me courage and hope and she's my mentor today at Google. There's Ashley who gave me friendship and support and let me be her mentor. There's my wife Winter who gave me everything. I got napkins so I won't pull up my shirt and show you all my stomach. Winter gave me everything and stood by me the most when I was at my worst. With their help I was able to rediscover my worth. I can't do that so I put her up. It was like maybe I could but not after the previous four slides. Through this experience I learned something I hadn't been able to learn through my entire career. I learned that sometimes happiness means giving something you love away. I also learned that life doesn't always go according to plan. After a year of being sick I was finally well enough to start looking for a job. I was very fortunate to have a number of companies interested and I narrowed it down to two large banks in Google. The banks offered me VP roles with very compelling packages including a nice salary, first class travel and even an expense account. I was very tempted to accept these offers yet I felt something missing from both of them. I'd gone through a rough patch and my friends in the open source community got me through it. The banks offered more money but I couldn't imagine life outside of the community. My heart was with go and that's where I needed to be. I took the role at Google and didn't look back. This was a big transition for me. I was used to running a large portion of the companies I'd been at. Additionally I was a co-organizer of two Go conferences and the creator of some of the most popular applications and libraries in Go. And I felt that I was pretty well known in the Go community. Let's just call it what it is. I thought it was a big deal. At Google I wasn't a big deal, like not even a little bit. I now found myself working alongside people who were truly big deals. I was starstruck and intimidated. I saw an older gentleman walking around the New York City office wearing a corn t-shirt. I thought it was kind of strange to see a person from that generation liking the metal band. My co-worker whispered to me, that's David Corn, the creator of the corn shell. One day at lunch we ate with Brian Kernigan, the co-creator of AUK. He's the K. He wrote The First Hello World. He's also the co-author of The Practice of Programming, among many, many other books. He also named UNIX. The Go team was especially intimidating. I had looked up to so many of them for as long as I could remember. I now sat next to PJW, one of the other creators of AUK. He's the W. And the manager of the team at Bell Labs, when C and UNIX were created. I was invited to a weekly meeting with Rob Pike, the creator of Plan 9. UNIX's successor. UTF-8 and Go. Robert Griezmeier, who is responsible for V8, which is the JavaScript runtime engine that powers Chrome and Node.js. He also is responsible for the Java virtual machine, Hotspot, and one of the co-creators of Go. Ken Thompson, who had created BC, UNIX, UTF-8 and Go, had retired by this point. It also had Russ Cox, the Go team lead, Ian Lance Taylor, one of the new compiler leads, without which we wouldn't have Linux, Apache, MySQL, or PHP. And finally, Brad Fitzpatrick, who created Memcache and LiveJournal. I don't think I said a word in that meeting for the first couple months, and often wondered why I was in that meeting at all. I was at Google for about four months, and Rob Pike asked me a question. Me. I couldn't believe it. In doing so, he also conveyed why I was in the meeting. I understood something that none of these luminaries did. I understood the Go community. From that point on, I focused on helping the Go project evolve to become more like Drupal, and often use Drupal as an example of what Go could become. So these slides, these next few slides are from an actual presentation that I gave to Go team. It's just a sample, because it's a sample, because it's a long keynote. Oh, no. It's good. So this slide here I used to demonstrate the shape of the Go project. If you notice, the Go project is, the Go team is in one place, and the community is in a completely different place. I called this open, but not inclusive. The next slide I modeled after Drupal. Although you have more circles, the shape is the same, where the Go has a small team for Google outside of the community, but the Go team itself is embedded inside the community. There's many sub-teams which have distributed leadership. I based this on Drupal as demonstrating what a scalable project could look like. Jumping forward a few months, things were going well with Go. We had just run our first ever contributor summit and our first contributor workshop, which both exceeded expectations. It was clear that other open source teams at Google were also struggling with the same sort of things. I partnered with the strategy lead of the Kubernetes team, and together we went on to draft the playbook for open source. As it started to take shape, we invited a handful of collaborators, including Angie, from the Drupal community to help us. This work is ongoing, and we are proud to have published the first section on opensource.google.com. While we were drafting this playbook, open source had a watershed moment, which caused us all to question our approaches to codes of conduct. This led us to seriously evaluate the effectiveness of all open source codes of conduct. We discovered that while most were well written in their declaration of values, most had no guidance on what to do when a conflict arose. Once again, Drupal was a leader in regard with its community working group and code of conduct. Looking at Drupal as inspiration, Google published our own code of conduct, which we based largely on the contributor covenant to unify all of Google's over 4,000 open source projects. Perhaps more importantly, we also published a universal conflict resolution policy, again inspired by Drupal, for all of Google's projects. In the year 2050, when we finally figured out flying cars and hoverboards, our grandkids or great-can kids, or who knows, our clones, may discover that we were part of Drupal in the year 2018, what will they ask us about? Will they be asking us about Drupal to CMS? Or will they be asking us about how Drupal enabled business? I believe, above all of these, they will be asking us how Drupal pioneered modern software. I could say open source, but in 2050, there will only be open source software, so they just call it software. So Drupal has taught the rest of us what open source could be. Of the many things Drupal pioneered, I want to focus on three of them. Distributed leadership. Drupal pioneered distributed leadership and stands alone as the most successful project to truly spread leadership out across the community. In Drupal, leadership is expected of everyone in the community. From the earliest days, Dries emphasized that this was a shared responsibility and welcomed leadership from everywhere. Drupal owes much of its longevity to the way that it has fostered and mentored new leaders. Two, collaborative development. The biggest lesson I learned from being in those weekly meetings was it's always worth the time to get it right. As they say, no is temporary, but yes lasts forever. This requires tools that encourage open and collaborative reviews, keeping a history of modifications to a proposed change and the ability to have others propose changes to a proposed change. My projects didn't have this prior to coming to Google. Drupal's had this for a long time thanks to Drupal.org. I love seeing how many revisions and proposals are made on a single issue inside Drupal. Drupal pioneered the idea that everyone should take part in the review process. This not only distributes the review load, but also mentors people on how to do better reviews. Most projects today are bottlenecked by only having maintainers review code. They consequently have no pipeline in place to alleviate the problem. Drupal set the standard for distributed collaborative development, a standard that is still unmatched today in open source. And third, community engagement. I know of no other project that has been able to match the spirit, friendliness, and inclusivity of the Drupal community. This is why the first Drupal con was so life-changing for me. I've never seen anything like this before. It is truly a family to so many of us. You care about each other as you work on the code, helping each other in issue cues or with sprint mentoring. What is even more important is that you support each other in life and create truly meaningful friendships. Without Drupal, the world of open source would be a very different place. So the road ahead, 2018 and beyond. Drupal now finds itself in the position where no project has ever been. No other community in open source has ever survived this long. And there's a reason for this. For 17 years, Drupal has pioneered open source. At each stage of Drupal's evolution, you have risen to the occasion and pushed the boundaries of what is possible. You saw the need and without any examples to follow, boldly went where no project has gone before. So my message to you today is don't stop. Don't stop stepping up. Don't stop being courageous. Don't stop asking the hard questions. Don't stop innovating. And don't stop caring. I can't tell you what comes next. All I can tell you is we are watching. What you do matters. It matters to Drupal and it matters to open source. You are showing us all the way to go. Thank you. So we have time for a couple of questions. So I thought I would start with one about your journey, right? Early you mentioned that Zoup was technically ahead of its time, but it seems like your career success came when you incorporated those softer skills and really started to focus in on both strategic decision making, being involved in strategic decision making and people management. How did you build those skills? Honestly, a lot of those skills came when I was doing missionary work. The furthest thing away from a computer, where I was forced to actually only interact with people. And it also happened through college. I took a bunch of classes that I didn't think would ever matter, like public speaking. You know, and one of the things you didn't mention is that you've served on the Drupal Association Board for the last few years. And you know, bringing this kind of perspective, this outsider, insider perspective has been very valuable, but one of the most visible roles that you've had while you've been on the board was as a member of the Technical Advisory Board. And you were, many people, I don't know if you know this, but you were focused on modernizing those collaboration tools for Drupal.org. So I wondered if you could talk a little bit about what you see as the future for tooling on D.O. Sure. I think we're in an interesting place. I think, as I said in my talk, there are features on Drupal.org that are so invaluable and lacking in most other places. And we've met with GitHub and GitLab and others, and they don't even understand what those tools, why those tools are important, why those features are needed. But you understand why those features are needed because it's what powers this great project. I think what we need to do is figure out a way that we can modernize what we have and bring it forward just like we did years ago when we moved from subversion to Git. And if that means partnering with someone else, maybe it does. But we can't lose what makes us who we are and what really makes this run. And I think we're in an interesting time. Lots of different tools are emerging. I know Google has tools we use that are pretty similar to this. And they're also kind of clunky. But they give us what we need to for the review process. I think if you had one thing that you could recommend to everybody today in terms of how they can help Drupal kind of maintain its secret sauce, what would that be? Other than like the whole keynote? Well, yeah, the whole keynote, yeah, pretty much. Could you say that again? Don't stop. I really think that's it. I think keep trying, keep showing up. Everything in life goes through different cycles and there's ups and there's downs and every project goes through that. I was talking to a board member yesterday. I remember when JavaScript was a dirty word and nobody wanted to touch it. And now JavaScript rules the world. And so everything comes in cycles, continue to push, continue to go. And like I said, we're all watching you. Okay. Well, thank you very much.