 Hi everyone. Welcome to this afternoon's keynote speak, the last day of the Drupal conference. My name is Greg Anders. I'm from a company called Ice Media. We're a digital services agency, full service agency, kind of based in Brisbane. None of our clients are based in Brisbane or virtually none. So we tend to work with people all over the place. It's been a good way for us to attract really good talent, people who want a lifestyle but want to work on some good national accounts. So that's enough talking about Ice Media. I'm going to introduce this afternoon Neil Drum. Neil's going to give the keynote speech. Neil is a Drupal.org architect. He's been a member of Drupal.org for the last, or for at least 16 years. Over the last 12 months there's nearly 200 fixes that Neil's committed. And he's going to talk about how Drupal.org is built. And I think it's going to be really important for everyone because without Drupal.org, we probably wouldn't any of us be here at today's conference. So Drupal.org, a couple of interesting stats. 20 million plus page views over the last 12 months per month. So even more impressive, 140 million which is they. And 2 million unique visits per month. So that's pretty impressive stats. So Neil's going to talk about how Drupal.org is built. And I'd like you to give him a warm welcome to the stage. He's here from the States. Thanks. Yeah. Talk a bit about what I do at the Drupal Association. So yeah, my job is to work on Drupal.org. I started getting involved with Drupal.org probably around 2006 or 2007. That's, I was interested in api.drupal.org. And my thinking was, you know, you have a big database of code. Could probably do something interesting with that. But then ended up rewriting all of the parsing because it was a pile of regular expressions before. And at some point in the mid 2000s, Drees asked if I wanted to have SSH access to the server. I think it was just one server at the time because he was going skiing for a couple of weeks. So nothing went wrong. I didn't have to do anything. But I had SSH access and kept that since then. And that was all volunteer. I was contracting and working on various sites at the time. So I started getting paid to work on Drupal.org as a contractor in 2009, 2010. The board had done a redesign of the site, worked with Mark Bolton to redesign the site. And it turns out if you have 10 mockups of a website and tell volunteers to do it, they don't just magically do it. So the association started contracting with a few people, including me. And so we got that launched in 2010. Also was upgrading Drupal.org. I think it was upgrading to Drupal 6, maybe 7 at that point. So now we have four people on staff on the Drupal association engineering team. There's also Tim Lennon, he's our CTO. Brendan Blaine, goes by B-man on Drupal.org. He's a developer, does kind of all that IT support like orders people, people laptops. And we're all remote, so he can be something about people's Wi-Fi problems. But he can't really go to everyone's house and fix their Wi-Fi. And he does support as well. So if you email help at Drupal.org, there's a good chance he's going to be the one answering your question. And Ryan Aslet, mixologic, he's a developer services engineer in myself. And we also contract with Tag 1 Consulting for infrastructure support. They help us with configuration management, provisioning servers, that sort of stuff. Mostly, Narayan Newton is our contact there. Have a couple other people at Tag 1 who help out as well. And Michael Hess has done quite a bit of volunteer work, even set up our Gira installation for our kind of internal organizing. He's also on the infrastructure working group and security working group. So yeah, we build Drupal.org. There's all sorts of volunteer contributions, of course. But it's not really, it's not just the one site, one Drupal site, it's eight websites. Association.Drupal.org. Right now it's mainly used for the board elections, the community seat on the board, a couple community seats. API.Drupal.org, the API reference events.Drupal.org for the Drupal cons and groups. That's still on Drupal 6. So we need to get that upgraded at some point. We have a job board for hiring Drupal talent and getting a resume out there. Localized for translating Drupal software itself, so translating core and modules and distributions. And security.Drupal.org for coordinating security issues. It's kind of a separate issue tracker for contacting the people who can responsibly disclose things to us and then we go to the module maintainer, whoever's responsible and communicate that and hopefully they fix this issue. And there's more than that. We also have services. Drupal.org is, Drupal sites will come to Drupal.org for downloading Drupal itself. Downloading contributed projects. Composer endpoint. So Drupal projects are not, they predate composer or so. Getting everything posted to a packages like thing that we host. Translation files, if you want to download the translations from localized.Drupal.org, run them on your site. And developer tools. So the GitLab migration earlier this year and stuff like Drupal CI. And then we're adding a couple more things on top of that work. Drupal steward. That will be a kind of a web application firewall to help protect your site from vulnerabilities that are being disclosed. And when there's somebody announced, so you don't have to update your site right away, if it's the sort of thing that you can lock with a web application firewall. And iMac updates are in heavy development right now. There's a few Drupal.org dependencies for that. So I'm personally working on iMac updates quite a bit. I'll get a little technical about the sort of things that we're providing for iMac updates. So first of all, you want, we want sites to be able to choose when they want to update. So kind of the main goal initially is if there's a big security issue coming up. Something highly critical like that. Code injection that's easily exploitable or SQL injection rates highly critical by the security team. We always do a public service announcement beforehand to help people. You probably should actually stay, stay awake this Wednesday, whatever time zone you're in. And but yeah, those things, that's a prime target for iMac updates. The whole system will, of course, work for any update, but maybe you want to do other updates on your own time. And so we're building API to make that public service announcement machine readable for the automatic updates client. So the main work here was done by Michael Hess. I reviewed and deployed it, did a few fixes. And yeah, basically it's a Drush command that will pop something like this out to a file and clear the CDN cache of it. So now that once your site knows there's an update coming up, we also want to know if your, if your site actually can be updated. So there's a few readiness checks. One of the big ones is you want to know if your site has been locally patched or has any changes. Because those things, this initial version of automatic updates, they won't be able to carry your patches forward. So we're building an API that's basically the shot sums of every file and every release. So you can, your site can determine if any patches have been applied, if anything doesn't match those shot sums of all the files. And it'll let you know if, if your site, it won't update your site if there are local changes. And we're also signing all of this data. So David Strauss, Peter Willanen and Mike Baton, Banton, they came up with a change signature format. That's the first seven or eight lines of this. And it's basically based on BSD's signify. So we're not inventing our own cryptography, but we're adding a intermediate, intermediate key kind of like, like X 509 or something. I'm not cryptographer, so I don't know the exact details. And they also implement a PHP library to do the verifying this signature. So all of that, that header that goes onto the data, that will be a new VM that only does that to keep it isolated from the rest of the infrastructure. We'll get some HSMs, hardware signing modules to keep the root keys, we keep those off the internet, and keeping everything isolated from each other. So that's, that's what I'm working on pretty much right now. Do a little bit of investigating on that yesterday. Mike Baton, again, wrote some software to automate this that we can set up on the VM that we have ready now. And yeah, since it is intermediate keys, the root keys sort of offline, we'll be able to rotate it every quarter, whatever we, whatever seems safe. And then the actual update itself. Once the site knows that there's an update coming up, and your site is in the state that can be updated. This phase, we're having it download just the changed files and a list of the files that have been deleted from release to release. So this initial one is for people who just have files on a server somewhere. If you have a deployment workflow, you know, storing stuff and get a blank via composer, this isn't for you that we're kind of targeting the sites with less, less infrastructure around them. So those are the ones that don't get updated. So yeah, I'm building, I built the service, which packages these steps, signs them with the same, same signing infrastructure. And yeah, basically the Drupal.org will give you the zip file of all of that for any combination releases for any project. And then the iMac updates client will download that. And the client is a Drupal module right now for seven and eight. Lucas heading is doing all the work on that. Thanks to him and the European Commission for sponsoring it. It just got to beta a few days ago. And yeah, right now, you know, it is very much in beta. It's only works on if I haven't done the infrastructure to generate all those hashes for all the releases yet, because we have test keys, this HSMs are in the mail. But yeah, it's in a testable state. And if you have a site that's not Composer managed, or doesn't have any other deployment workflow, testing it would greatly be appreciated. And the next phase will be Composer support. So something along the lines of blue, green deployments, you know, have two code bases built out with Composer and something to switch between the two when the new code base is ready. Another project I've been worked on quite a bit a couple years back is the issue credits. So, you know, we've always been, Drupal's pretty much been crediting people from the start, that really strong I could find. You know, used to be in the commit message still isn't the commit message. But, you know, we wanted to know a bit more about where those commits were coming from. And, you know, commit message is also just code, not other contributions as well. So, yeah, we wanted to find out if people were doing things on their own time, or if organizations were sponsoring their work, and what organizations were leading contributors. So, project maintainers credit people on each issue. And then people who are doing the work on the issue, commenting on the issue, attribute that credit to organizations if they'd like. Vendor line implementation, it's all pile of entity references. And the way they implementation went is each comment is a good place to kind of hang the attribution as you work. So, probably seen on, if you have updated an issue on Drupal.org, there's a couple fields to say which organization it's for, or if you're working as a volunteer. And then since the organization data, that's all associated with comments, the actual credit that the maintainer grants is stored as entity references to each of those comments. So, the project maintainer ticks the check box to credit someone underneath the actually stores, you know, all of those comment IDs. And, you know, so if someone switches their attribution halfway through an issue, you know, switch from volunteer to working for an organization or to organization to a different organization, everything gets aggregated to credit everyone in your organization. So, there's a couple more bits in the field storage, like the story, the check box store, if it's a volunteer or not, and a reference field, another entity reference field to call out if the organization was a end customer. So, it makes some fun queries for reports. This is one of the smaller ones I found, just the last thing that was in my command line history for the MySQL. And since to this issue of credit rather than something on a get commit, it's ended up people figured out they can use it for crediting noncode work. So, seeing conferences, credit all their speakers, organizers, and people working on organizing, communicating, documenting things, need recognition, too. And we totally didn't plan on this use of the issue of credit system. It's just something people figured out in the last year or so. And there's a page on Drupal.org, Drupal.org slash metrics. It has a couple, has a few graphs like this and some of them are less useful than this, like it has a graph of how many users were created by month. And that doesn't really say a whole lot. Because honestly, most of the users register for Drupal.org are spammers and it's a massive over count. But this is stuff like issue credit that gives us a chance to count up what's like an actual tangible someone did something and maintain or recognized and said this is good. So, yeah, all of these graphs can be found on Drupal.org slash metrics. I just added this one two days ago, I think. And yeah, basically shows which region of the world contributions are coming from. And in 2018, we added privately sharing if you were a member of an underrepresented community. So, stuff like if you're, if you're a racist minority in your field and location or if you're a woman and male down in the industry. Also, you know, there's 10 categories there's someone that you would not think of as diversity right away like age and socioeconomic status. So, these are all self reported on your Drupal.org profile. This is probably no undercount since it was just added last year. But yeah, we've always had kind of superficial stats like how many people identify as women are contributing, but this lets us get into more detail. And of course, it's all kept confidential. There's a little bit of rounding that goes into this graph. I'm pretty careful about reporting to make sure no one can reverse engineer the data. And finally, the actually how much contribution is from organizations. So, you know, looking to encourage organizations to contribute in constructive ways. You know, Dries has his blog post about makers and takers, more makers. And you know, of course, contributions to organizations get shown on your organization page on Drupal.org. With a few other factors, that's how we rank the marketplace listings. Those used to be alphabetical. So, even if the system we have now isn't perfect, it's not alphabetical. So, yeah, looking for promoting organizations making time for their employees to contribute back and show they're a good place to work. And right now, we're working on recognizing more types of contribution. It's usually code contributions. Stuff like tagging releases, more formally recognizing the time it takes to organize an event. It takes a huge amount of effort to get put on an event like this. And, you know, just one commit credit is not, or issue credit is not really enough. Running initiatives and other working groups, those all deserve credit. And we're thinking about how doing some weighting, some contributions are more impactful than others. And the weighting, that'd be mostly if all four ranking organizations were not in the business of ranking people, making a leaderboard of who does the most. But organizations, yeah, we can have them being a leaderboard and do a bit of competition. And, yeah, my boss is working on the contribution recognition committee to kind of be a independent-ish board to review these change additions and the weighting, so it's not just the association doing something. For example, the Drupal cons, that's the session selection. That's not done by the association directly. That's volunteers figuring out which sessions are selected for Drupal cons. I'll quickly go through a couple other things that we're working on right now. The upcoming Drupal 9 release is promoting some work. Composer support, getting that actually fully into core and making packages releases. Composer ready. My co-worker, Ryan Mixologic, he's the lead on that. So, yeah, look for the Composer Initiative. They got a lot of good stuff done. Semantic versioning for contrib. So, Drupal modules, Drupal themes, they're not just compatible with Drupal 8 or Drupal 9 anymore. Drupal 8 modules today can be compatible with 8 and 9 or like 8, 7, 3, 2, 9, 2. There's not that first bit of the version number. That doesn't matter anymore. So, we're taking that away and at the same time doing semantic versioning. So, adding the last patch version number. So, hopefully, we'll get that launched probably next quarter at some point. Issue for King. That's something I made quite a bit of progress on that and then the Drupal 9 stuff. We realized that was more important. But, we have this working on dev and staging. Basically, a button on the issue to make a fork for the, for working on that issue. And the thing that'll be unique about the forks we do on Drupal.org as compared to GitLab, the main site, and GitHub is, from the start, it'll be collaborative. It's not just one person working on one merge request. It's anyone with access to, anyone who's agreed to access agreement will be able to clone it and work on it and push to it. So, we have the forks ready and all of that access control, Git makes it easy to overwrite each other's work accidentally. And just saying like use the ref log is not an adequate answer for if someone's lost their work. So, figuring out all the permissions this next step. And we have to update all these sites to Drupal 8 and Drupal 9 at some point pretty soon. And we still have groups, the Drupal 6 site. Right now, we're looking to clean up some of the technical data. Stuff like the Drupal 9 landing page, the kind of thing we use to market Drupal, actually the Drupal 8 landing page built a whole separate theme for the landing page for Drupal 8. So, we have two themes that look pretty much like each other jobs. This is a separate theme. So, maybe you can reduce our debt there. And it will be much easier to migrate stuff when there's less of it to do. Another example, the association site, that's really just old blog posts. The new blog posts all go to a section on Drupal.org itself. We just use it for the elections. And maybe you could use a third party service if we find one we trust. And just get rid of the whole site. And then we don't have to migrate it. Oh, and for Drupal.org itself, last time we did an upgrade, it was a 24-hour downtime. We don't want to do that again if we don't have to. So, we'll have to figure out some sort of incremental migration for Drupal.org to make that kind of like the GitLab migration. The GitLab migration was 10 minutes of downtime when it was an incremental migration. And then we flipped over to GitLab. And there was one project that had committed in the last five minutes that hadn't been updated. So, we got that moved over and switched everything on. It works pretty well. So, that's some of the work I'm doing, that my team is doing around the Drupal Association. There's also all the day-to-day stuff. Like this morning, I cleaned up a little bit of spam. All my co-workers who might do that are on vacation for the holiday. I'd be synced to Gitrepositories commits to Drupal.org. Drupal.org has a database of all of the commit data, which is useful for queries and integrating everything. It looked into provisioning AWS service for helping out with the signing server for automatic updates. And, yeah, it all doesn't come free. I'm a full-time employee. My co-workers also get paid. We have all these services we use. A lot of these are free. A lot of them, they've given us a deal as a non-profit. There's a few we just pay for, because they're worth it. Stuff like Datadog for monitoring and logging. Slack and Zoom, because we like talking to each other. And Zendesk for help at Drupal.org. And all of this runs on 11 physical servers. Probably more than that. We have a few that are just kind of hanging out. They've been powered off. They're pretty old. But I think 11 or more active ones, they're at the Oregon State University open source lab. I haven't needed to buy any in a few years. They've got these provisions pretty well. And, you know, PHP updates keep making things faster. My school updates keep making things faster. And everything's on virtual machines except for the database and media servers. Media servers are the files directory. So we're relatively portable for moving stuff around. If we ever need to migrate to the cloud or anything, we should be relatively ready to do that. And, you know, we have the hardware. It's free for now. Essentially, the open source lab. They charge a few data center fees, but they give us a pretty good deal as an open source project. And there's the rest of the team. So we're four people out of the 17 on staff of the association. We also produce Drupal cons. Sorry, we haven't had one close to Australia lately. But the Amsterdam was a bit of an experiment with handing over a lot of the responsibility for conference organizing to a company called Quoney. And, you know, up until the event, we were honestly not sure about it, but turned out pretty great. So now we know a bit more about the effort we need to put in for having a third party organized in the conference and conference. And we could do more of them potentially. And, yeah, go more places outside of North America and Europe. And we're doing stuff like promote Drupal. So coordinating Drupal branding and marketing. They have a whole initiative to build decks and marketing material. So I believe that's in the state where they have a pitch deck for Drupal and are looking to get that translated to more languages. So the ways to support us, membership is easiest. The way to support us financially is either as individual or organization. It starts pretty affordable rates can pay as much as a scale for membership. And organizations, the supporting partners, their budget or money we get from supporting partners, that's directly your market for supporting Drupal.org. So that's the way to support. If you're an organization with a, that relies on Drupal, or obviously for more supporting partners, thanks previous next morph catalyst. Those are the ones I saw from the region. And there's other benefits like increased visibility around Drupal.org, a boost in the Drupal.org marketplace rankings. So thanks. Yeah. If you have any questions, if there's something I work on, I'll be around. You can use my contact form on Drupal.org or find man's slack. And thanks. Thank you, Neil. You've forgotten your prize. Thanks. Thank you very much. And I think Neil may win the award for traveling the furthest to get here. Even if it's not the longest, he came all the way from Brooklyn to Tasmania. So thanks for showing us under the hood of Drupal.org. As I might have mentioned yesterday, I've been lucky to have been appointed to the Drupal Association Board, which I just started last month, taking over from all the work that Donna Benjamin had done previously in this region. And I think the exciting thing is there's a lot of work now happening at a global coordination level. There's Rachel Norfolk, who's the community liaison manager, who's starting to get us as local associations talking to each other, sharing best practices. I found myself sitting on the phone to Columbia the other day, sharing what we've been doing at Drupal South and how that might transfer across to them. And likewise, we had some great interactions with the Drupal Association Netherlands and ideas that are directly translatable here. I have also been appointed to the Revenue Committee, so I'm going to reiterate what Neil said around individual and organisation membership without Drupal.org. We would not be all working together and being able to contribute and collaborate. And all of that money does go straight back into the project. And also as supporting partners, it does mean that your profile within the Drupal.org marketplace does get enhanced. And what I would like to mention as well, we do have DrupalCon Minneapolis coming up in May 2020. If you like Prince and Drupal, there's a Venn diagram for that for you to come and attend. But session submissions for Minneapolis close on December the 4th. And if you do need travel assistance to make your way there, there's a very well-structured scholarship program to help fund getting you over there. I know Soochie Garg made it to Amsterdam on one of those scholarships. So that's definitely available for all of you. And there will be another DrupalCon Europe, which will be announced shortly, most likely towards the end of 2020. A little bit of housekeeping again, all of the sessions that have been completed, they have a little feedback form at the bottom of them. Like I said yesterday, that feedback helps people get an understanding of how their talk was received and improved for future times. Lightning talks will be having them after the second keynote today at about 4.15. And there's still a box available there if you want to submit one of them. And after the keynote this afternoon, there's going to be an after party sponsored by Pantheon at the Shambles Brewery in Elizabeth Street. And again, I just like to thank Greg and Ice Media for sponsoring Neil to come all the way here to give his talk today. And one final fun thing, because we had so much fun doing a photo yesterday, we're going to do another one. So this time we've worked out how to actually get onto the balcony outside. So I'd like you to all get up, go out to the escalator, down the escalator and turn right onto the forecourt where the flags are. And there'll be someone on the balcony directing you so that we can take another group photo. Thanks for your patience.