 All right, good morning. Thank you for welcoming me here today. So as Rich said, I am involved in PIG, Hive. I've helped mentor a lot of Apache projects, but I'm really talking here more as my role in, as part of Hortonworks today. So for those of you who don't know, at Hortonworks, we contribute to a number of Apache projects. We have, I've actually lost account, four or five product lines now, several of which are based around Apache Hadoop and Friends in its ecosystem, but also some based around other Apache technologies, such as Kafka, Metron, and others. And I'm sure I forgot some on this slide. But the point is contributing to Apache and supporting Apache projects is core to our business. It's what we do every day. So we started almost six years ago now with 25 people. All those people knew Apache. Most of it, everybody in engineering was already a contributor to Apache. I believe we were already all committers even. Today, we are a worldwide organization of over 1,150 people. We've grown very, very quickly. Now, what works at 25 doesn't work at over 1,000. So early on, as I said, all our employees, even people who weren't in engineering, understood Apache in the Apache way. And for those who didn't, we could do that by osmosis. That's why I picked the Luke and Obi-Wan here. It was kind of the old gray beards, I guess, giving the amazed new people the technology. But it was pretty easy to pass on when you have a critical mass there. But what works at 25 doesn't work at 1,150. You have to start to switch your thinking as you grow. And how did we know this? I mean, part of it is just when you say it outright, it's obvious. What works at 25 doesn't work at 1,100. But what did we see? We started to see some mistakes internally. We saw people do some things that they weren't supposed to do. And just to be open about it, we saw some other companies make some mistakes where we're like, we don't want that to be us. We don't want to do that. So how do we go about preventing that? What do we do? We realized we needed to become more intentional. So we switched from the Obi-Wan and Luke to the Dead Poet Society here where we're going to actually teach. Yeah, sorry, you have to be old like me to get many of my movie references. Though I did shave this morning so I don't have the gray beard. But we decided that the best way to take this on was to develop a curriculum for our teams to go through. So we developed a curriculum, and I'll talk about what's in there in a minute, that we took first all our engineering team through. We started with Devs and QE, then went on to Docs, product management, support, all of those groups, and ran them through this. It's really about 45 minutes of content, and we leave lots of time for discussion and questions. And we do it in smaller groups. We targeted 20 people or less so that people feel comfortable asking questions, bringing up issues. We wanted people to feel free to say, hey, I'm seeing something else in my group. Or, hey, what about this? And those small groups encouraged that. We also added a scoped down version of what we call our boot camp. When we hire new employees, we put them through an entire day of training for Hortonworks. We put together a scaled down version of this into our boot camp so that all of our employees, even people who aren't maybe touching Apache on a regular basis, at least have some understanding of what Apache is, why we choose to work with it, and all that kind of stuff. And also, we have an ongoing cooperation with our marketing PR and conferences groups to help them review their material, because they don't always know what they can and can't say. Those are kind of the forward face of our company often. And we want them to make sure they're in sync with Apache and how it's working. We want to make sure we don't end up saying things like Hortonworks Hadoop or something like that. And so that's something where we work with our marketing team to help them go over their material. So what exactly is in this training? What have we put in there? We started out with just really basic stuff. What, you know, the structure of Apache? What roles do people play there? And one thing we stressed in this roles that I would encourage you to take back, maybe to your companies if this is applicable, is you don't have to be a coder to play a part at Apache. There are many things that Apache needs, right? We need people that write tests. We need people that help others on the list. We need people that want to do legal things or all those sorts of things can play a role at Apache. And that's something that we put in our training. We do talk through the Apache way, openness, collaboration, meritocracy, no corporate affiliations, all those things that you all know from being part of Apache, we go through that. We talk through the Apache license, particularly for our engineers to help them understand how that plays with their code and help them understand if you're bringing in code from another source, what do you have to be aware of? What does that mean? All those sorts of things. We spend time on why does Hortonworks choose to work with Apache? We, of course, have choices. We could now, some of that's obviously historical. Many of the projects we contribute to are already Apache projects, but we have also helped initiate a number of Apache projects. When other people come to us and say, I want to do open source, we often, not always, because sometimes it's not a good fit, but often we recommend you should look at Apache. Why do we do that? So we talk through that. We talk through what it's like to be both a Horton worker and a part of Apache. How do you balance that? And, obviously, I can't go into all that here because I don't have time, but to sum up, we try to show that 99% of the time our interests align because Hortonworks is so invested in Apache and the projects. We strive to minimize times that you have to go, okay, how do I resolve this? We give people a lot of practical tips. What have we found that works? What are mistakes we've seen that we want to avoid? Things we'd rather not see again. And then we talk through trademarks. How do we make sure and respect Apache's trademarks? What does that mean? What do we need to do? So we started this last fall. We have now run almost the entire engineering team through it, all the support team. The feedback has been pretty much universally positive. Kind of some of the most common comments we got were, I knew a bunch of this stuff, but I didn't know how it all fit together. I knew the random facts, but I didn't understand the structure, kind of. So that was good. One of the most common things we actually got were from people who were not writing Java code day to day. They were very glad to hear that they could have a place at Apache too, that it wasn't just for coders. It's something that, at least internally, we hadn't done a good job making clear to people. And it's kind of something we learned that we need to get better at is, how do we include all those other people and make sure they can have a place here too? And then interestingly enough, one of the most common things I got is, can you do this for my group too? We actually just started with Dev and QE and product management. I wrote them in. The docs team, the UI team, the support team, all came and said, can you please do this for my group as well? And we're then glad when we did it. So it was more popular than I actually expected it to be. I honestly kind of expected this to be treated the way people treat a lot of training. You have to do in a corporate environment where you're just like, really, I have to sit through yet another training. And there was some of that, but by and large, the feedback was very positive. Now to be clear, this is a journey, right? It's not one step. It's not like, okay, we did this, we're done. Good, cool, away. As new engineers come in, we're gonna need to continue training. As I already said, we put this in our boot camp so everybody's gonna get at least some background. But even for people who've already been through the training, what's the next step for them? What do we need to do for them? One thing that became clear as we went through this is we need to be able to answer people's questions going forward. So part of that is simple, putting together an FAQ, a lot of which I, well, I haven't done this yet, so it's on the to-do list, but a lot of it, I think, will be just pointers to the appropriate Apache documentation, right? I have a question about trademarks. Well, there's this page on that. I have a question about licenses and is this license okay? Well, there's a page for that. But of course, some of it will be questions internal to Hortonworks that we need to have answers for there. And then a suggestion that was made to me that again, I haven't implemented yet, but I like it, I think I will implement it, is building an internal mailing list that the Apache members that work at Hortonworks are subscribed to and where people can ask questions and say, hey, I don't understand, is this okay? Or I just, I have this question about the sort of that or the other thing. And sometimes the answers to those questions are gonna be that's a good question to ask on an Apache list. It's a good public question. Sometimes those are gonna be internal things that we need to hash out first and that's a good place for us to do it. Now, in the good open source spirit, we are, I've uploaded these slides on my slide share. Well, a scrubbed version. Some of the things were Hortonworks specific, but I've scrubbed out that stuff, put it up there. I warn you, that's version one. I haven't yet worked through to get version two. I'm going to do that sometime soon because having given this training more times than I care to remember now, I've learned a few things. I need to clean up the slides. You will need, if you wanna use them, you are more than welcome to use them. You will need to adapt them. There's a lot of stuff in there that's specific to the way we think about it, like answers to the question of why does Hortonworks choose Apache? Obviously, for you or your company, that you may have a different answer than we have to that question. But please feel free to take those and use them as a starting point. We're also working with the community development team inside Hortonworks to do a meetup with me doing this training and then do a YouTube recording so that others could watch it as well. At first, I was like, really? Seriously, you think anybody will care? And then somebody said, well, if you do this, you can quit giving the training because we can just show the recording. I'm like, all right, I'm on board, done. So that, I encourage you to, if you find this useful or helpful to take this and start working with it as well. Now, if you're interested in this, I wanna give a call out to, there's a whole track tomorrow in ApacheCon on the Apache way where people will be talking about some of these things as well as some other interesting parts of the Apache way, much more in depth. There's a couple tracks, or a couple talks in that track that I saw that were focused on, how do I balance being a Horton worker and a member of a company and what's it mean for a company to work with Apache? Encourage you to take a look at those for a good source of yet more information on this. And I too was fast, so thank you very much. Thank you.