 Hi everybody, I'm Sheetal Poole, I'm an engineering manager at the Home Depot. I work in the store systems team where we build and support the software that our Home Depot associates use in the 2000 plus stores we have across the country. And I'm Dustin Bennett, I'm a manager of several teams at Home Depot including, we kind of consider our software engineer enablement function. So we've got application platforms, legacy and cloud as well as developer tools, ad hub, artifactory, those kinds of things, and a bunch of kitchen sink stuff as you'll find in any enterprise. So that was a great intro, I appreciate that. I usually like opening by asking the question, how many people are planning a Home Depot run this weekend? Okay, for those of you who are hands are still down, there's a non-zero chance that something breaks and you play the game where I need a new one of these, right? So I say that because to the earlier point, most people think of Home Depot, they think of the stores, the sights, sounds and smells, the orange apron, the forklifts and cherry pickers beeping, the blending of smells from sawdust to key cutting to paint and everything else in the store. I'm sure Home Depot is a retailer first and foremost, but we do these kinds of things to show that Home Depot is also a technology company, which is almost as important for us these days. So what we're going to talk about today is our foray into cloud foundry and some open and intersource initiatives we have at Home Depot. We started really in earnest about six months ago and we're pretty ambitious, we're pretty proactive. Our goal was to leap in, jump in as quickly as we can, ended up being a little bit more tentative, waiting, unfortunately, but we're here to share kind of what we've been through, some lessons learned, some good and bad and whatnot. So where we'll go and where we'll start, I'll talk about our foray into the cloud foundry foundation specifically, and then we'll turn it over to Sheetal to talk about some open source and intersource initiatives at Home Depot. But first, Sheetal will talk a little bit about why we're doing this in general. So our customers, right, we always like to contextualize whatever we do in terms of our customers. It could be, you know, folks like you walking into the brick and mortar stores to pick up home improvement items, it could be looking at paint items on our Home Depot app or shopping our Home Depot.com website. So we believe that, you know, providing the most seamless and frictionless experience for our customers, but also our store associates because I work in the team that builds the application for store associates, we feel like moving towards open source, whether it's using or contributing back can only help us improve it, right? Code reuse, improving code quality, decreasing time to market, I think are all things that we get when we get closer into the open source world. Along with the customer focus, one of the things Home Depot is very proud of is its culture and its core values. What you see up here is what we call the values wheel. These are eight anchoring values that have been around ever since Home Depot was founded by Arthur Blank and Bernie Marcus back in the day. Contributing to open source directly ties back to one of our values, which is giving back, right? Giving back to the community, being part of the larger ecosystem. I think it makes sense to a lot of our stakeholders in Home Depot. Okay, so we'll jump into a little bit about how we strategically approached our contributions back to Cloud Foundry. So it's true of hands, who's familiar with Cloud Foundry? Okay, that's a lot bigger than my normal audience. I did this at a GitHub event and it was almost zero. So I'll just briefly overview for those who kept their hands down. Cloud Foundry is an open source Paz. It's managed by the Cloud Foundry Foundation, holds the core source code. It's typically resold and packaged by vendors and sold to end users like ourselves. So we use Pivotal's version of Cloud Foundry as our end product for most of our Paz Cloud Platform deployments. It's a very complex landscape. So if you look at Cloud Foundry itself, yes, it's generally one open source project. But really, there's 30 or 40 orchestrated applications that build the Paz. And anybody who's run or deployed apps in a Paz can imagine. There's a lot of complexity from container orchestration to scheduling, to keeping things alive, to moving droplets around, et cetera, et cetera. So it's a pretty complicated landscape. We joined the Cloud Foundry Foundation back in October as an end user. So part of that was an expectation that we would give back meaningfully to the Cloud Foundry Foundation in terms of code commits. So we had to play a little bit of catch up because I was a little bit surprised when we pitched to join and it was approved. So we had to come up with the strategy of how we're gonna functionally contribute in a meaningful way that's beneficial to both us and the community at large. So we did a little bit of brainstorming. More recently, our chief architect, Barbara Sanders, was elected to the Cloud Foundry Board of Directors. I'm an ambassador for Cloud Foundry on the board staff, which I think just means I have a lot more homework now, I don't really know. But we wanted to give back. So how do we do this? I'll take a little bit of a divergence here. We have an office that's co-located at Georgia Tech's campus in Atlanta, in Midtown Atlanta that we staff with interns throughout the year. Typically we have more over the summer, but we staff throughout the term. So what our approach was is we keep our operations team for our Cloud Foundry platform pretty lean. It's roughly three pairs at any given time, two to three pairs operating the platform. So what we wanted to do is we put together a pitch of taking an intern pair out of the Georgia Tech office, giving them a fairly open-ended problem of generally just get a pull request approved into the code base and see where they took it and ran with it. We were pretty fortunate to get a couple rock star interns, Thomas Olson and Madeline Goebbels, who have really hit the ground running with this. They started in December, which meant there was a little bit of lag due to the holidays around there. But they've had at least two or three pull requests approved so far, which was kind of a reach goal for me starting this. Most of them have been in documentation. But that's not to say we were without pain points as we went along. So what we ran into, we've heard several people mentioned throughout talks here is getting the corporate CLA sign. Frankly, that wasn't as painful as I might have expected. It took us about a week, but we did have to chase down a couple different VPs and corporate counsel and that kind of thing. So it was a little bit longer than we wanted. However, we were able to contribute on individual licenses in the interim with no problem. Another big problem was environments. Unfortunately, our intern office, for some orange tape reason, could not get issued MacBooks, which all of our operations team has MacBooks. So we had to deal with a lot of the imaging and getting things just building and running there. And then documentation. So there's a lot of coming in relatively fresh to a project or a suite of GitHub projects like Cloud Foundry. There's a lot of documentation to wade through that some of it's up to date. Some of it's accurate and accurate with the latest build. So wading through that, and one of the first initiatives that Thomas and Madeleine took on was to basically build a Home Depot playbook for this is what the Cloud Foundry documentation means to us at Home Depot as platform operators, and this is what's important to us and how to ramp up into contributing to open source. And then finally, what to work on, right? Because like I said, there are 30 or 40 projects. We wanted to make sure that our interns were fully engaged, because one of our main goals through that program is to eventually have full-time hires once they come out of school. So we wanted something that was interesting to them and ambitious but not too ambitious that they wouldn't be able to get it done within a semester. So where we landed, there's a Cloud Controller API, which is a bit at the boundary of the system. It's kind of the end API that we use and leverage pretty thoroughly to get information on metadata of applications, users, that kind of thing. So we have a couple specific pull requests that we want to implement that will help us as a company that currently aren't prioritized in the product backlog either within the open source community or at Pivotal specifically. We also want to make sure that we test our hypothesis and iterate. So not only on the code that we're contributing, but is this program overall good for the Home Depot? Are we realizing any value is this good for the folks that are working on it? Is it good for us as a company? And we always try to iterate and improve going forward from there. So best case scenario, if this is very successful, we either expand the intern team or have been talking to a number of folks here about the way that they've built out open source program offices. That's another option, depending on the extent to which this is successful and meaningful for the Home Depot and the foundation. And then finally, we'll be presenting at Cloud Foundry Summit. And Madeline, who's the senior intern on the team, will be coming up to talk at User Days with us. And we'll basically do a similar kind of run through and talk that we do here. So that's kind of an overview of our approach and strategy for how we've gotten into the Cloud Foundry community. I'm going to turn it over to Sheetal here to talk about open and inter-source at Home Depot. Thanks, Justin. So open source, our usage of open source software at Home Depot over the last few years has gone up drastically. And part of it is this large community of people are contributing such a great code that we can pick up and use. So obviously, what's our first motivation for open source? It's free code, right? We have a large community supporting that code base. It's something we can start off right off the bat, focus on our business features without having to worry about some of the underlying plumbing that has been provided for us. So apart from the Cloud Foundry work that Dustin mentioned, we've also recently started starting to figure out what giving back means. We have a CI deployment code base called Flow that we recently open sourced, which kind of leads into the second point of open source software and using it and contributing back is better code, right? Having a more diverse set of folks taking a look at our code base, getting feedback, getting any kind of full request, we're learning a lot from that. And I think that's kind of into the biggest part of open sourcing our software. So we've had a lot of internal frameworks and tools that we've traditionally used at Home Depot. But I think the market scrutiny that we get by being part of the open source community is are we getting enough attention? Are we getting full request? Is there a better tool out there that's up on the rise? Is there a trend that we should follow? So there's a lot of benefits that we're getting from just being part of the community and again, we're making baby steps along our contributions to open source. But the fact that we're using more tools from the open source market also reflects on the fact that we want to be, we get it, we realize the opportunities out there. Learning from the same model and applying those internally. So I personally work with multiple development teams within Home Depot. And as is true of any large organization, we have competing priorities, changing business needs, a lot of realignments that happen. And part of what we've done recently is within our internal GitHub hosting, right, we've started adopting some of these open source principles. What that has given us recently is just this constant realignment that happens. We get autonomous prioritization. So as an example, recently we had one feature request for one of my teams, which is pretty low on the list of priorities we would implement for that quarter, but it was way up high for another initiative, another project. So in a pure open source word, the other team created a pull request. They contributed to our source code. We accepted the pull request. In the process, they got to implement the feature in the timeline they needed. And we ended up with better documentation, better code coverage, and obviously just a better code quality at the end of the whole thing. What we've also realized is when a team is inside a source code, into a code base, day in and day out, the way they look at the documentation and their test coverage and some of the other ways in that code is a little different than an outsider team who takes a look at it. So we've just, over time, we're letting others work code reviews. And in the process, we have better readme's in our GitHub repo. I think that's one of the best things out of our inner source model. So we are continually improving collectively within Home Depot. And we've seen some great benefits out of it. We've also learned a lot from the open source community. We've realized some of the lessons learned over the years, internally how to apply those, having a community leader, having coordination within the leadership, good documentation. A lot of the principles that apply to a successful open source project, we're starting to learn how to adopt those internally and externally when we contribute back now. And we personally have learned a lot over yesterday's sessions and talking to a lot of folks who are part of the open source community. And we'll take back these lessons and hopefully come back with a better picture with that waiting into the water picture you had, Dustin. Yeah, maybe we can start jumping. Yeah, so I think just another thing on our open source and inner source model outside of the value that it brings us to as a company and the value that we can bring back into the community. Customers are our top priority and our customer service and customer experience is above all else, as Sheetal mentioned earlier. But close second to that is our associates. So typically we think of that as our front line associates who are in stores in the Orange Aprons. But that's also our software engineers and software development teams and technology deployment teams who are writing code that runs on the point of sale registers on the website, on the stores. And the engineers that we have on staff and the engineers that we want to recruit want to contribute to open source. They're either already involved in open source projects. They're used to using it. So we're seeing a big uptake in the software engineering community that we're both cultivating internally and looking to hire externally. This is something that they want to be doing, right? So it's a competitive advantage for us to be able to say yes, the Home Depot is proactive at contributing back to open source. If you want to get involved with a project organizationally, we have your back and we're open for that. So that's another big aspect of what we're working on. So whenever PR approves these things, I always have to say we're hiring. So if anybody's interested. And then also, we just want to start painting that picture of Home Depot. Yes, we're a traditional brick and mortar retailer. We've got a huge store footprint. We've got a huge software footprint in the stores. But Home Depot is also a technology company. So thank you for the time today.