 Hello, everybody. Welcome. This is the talk on how Walmart is building a successful open source culture. I'm Andrew Mitry. This is Megan Rosetti. Hello. And we want to share a little bit about our journey at Walmart and building actually introducing and changing an open source culture there over the past few years. Let me start off with what is Walmart? So I know that we're here in Spain, in Barcelona, and there's no Walmart here, at least not yet, but now I'm not going to start any rumors, but I get in trouble. But Walmart is actually the largest company in the world. We are Fortune One. We do about a half trillion a year in sales. It was started in 1962 by Sam Walton. Today we have over 11,500 stores under 72 different banners. So like for the European crowd, as the UK is a Walmart banner, we're in 28 countries and we have e-commerce sites in 11 countries. We have over 100 distribution centers worldwide. And we have over 2 million employees. So we are actually, I think we just moved up to number two, second largest employer in the world after the U.S. military. We just actually passed the Chinese military in terms of the size of an employer. So pretty big employee base. And we have about 80 million monthly visitors to Walmart.com. Just to kind of give you a sense of the scale and size of operation that we're running at Walmart. Part of our culture is that each location is part of the larger community. We spend a lot of time at the culture of our employees, motivation to do the best for your peers and work with the best people. And the reason why we bring this up here, right, is this actually helped us translate into the open source culture. It was almost a natural fit as we started to kind of bring these open source ideals into Walmart. And this is actually our team in our Virginia location. So it's part of our Walmart team. Yeah. So Walmart has a technology presence in northern Virginia, in Bentonville, Arkansas, where headquarters is, in the valley under the Walmart labs, in Silicon Valley under the Walmart labs banner, in Bangalore and in Leeds, UK, as well as quite a bit of remote. So next, talk about a little bit about how we've embraced our open source journey. And so at Walmart, pretty much everything starts with a proof of concept. Small engineering or DevOps team. A lot of times we're, you know, reusing or repurposing hardware. And we have this desire to do something new and potentially beneficial. And to convince management, it's worthy. This is kind of where things kind of incubated and started with OpenStack and with other open source projects at Walmart. This initially started about four years ago at Walmart and the POC was successful. It allowed a wider audience for testing. We made a decision to use OpenStack in production, increased our hardware footprint, you know, productized our deployments and configurations. And we made that decision to run all of our e-commerce applications on OpenStack. And so to give you a little bit of context, today 100% of our e-commerce runs on OpenStack. And what we've now been focusing is actually transitioning our retail back office workloads onto OpenStack as well. A lot of the net new workloads are moving onto OpenStack, not just the traditional web app, right? But a lot of data intensive applications and traditional back office applications as they mature, as they're rewritten, as we bring in new ones, we are moving those onto OpenStack as well. It has become the de facto cloud platform within Walmart. Part of the journey was that this was also management driven, like, you know, incorporating that open source culture throughout the company, right? So it had buy in from the top as well as enthusiasm from the ground up. We've actually recently started to work in, so a lot of larger companies that have been around for a while have awards for patents and other innovation. We actually were able to bring, having company awards at the same level as patents and recognition around open source contributions, right? And so we reward that, we're making that part of goals and really trying to make it so that this is part of, not just something you do in your spare time, but part of your day job at Walmart. And so we also have created an internal community where we provide support for those who work on open source projects, even if it wasn't directly related to their day to day work. And I think having it as part of the overall technology strategy and that coming down from both our CTO and CIO's office and cascading down in goals has been a big help in getting maybe even managers that weren't as familiar with open source saying, hey, well, this is now part of my goal structure. How can I incorporate this into what my team is doing? So certainly it's something we have found is it cannot be 100% management driven. You have to have, if you want to forward, you have to have your teams on board as well. And that has been a large part of our journey. So we've adopted somewhat of a dual strategy, working with both management and also with teams to move this culture forward and make certain that everybody is embracing it. We're really finding that teams are adopting the open source culture. They're getting excited about it. They're getting excited about the work they're doing, getting excited about the products that they're able to upstream back into the community. We've made this a part of our onboarding. So as we bring in new team members, they go through how to contribute training. They go through, here are different projects, different working groups that you might be interested in and here are people within the company that can act as points of contact to help answer questions and help you get over some of those initial hurdles. We include the work within the community that we're doing as part of our day-to-day agile planning. It is part of the workload. So for example, the operations team has their backlog rooming and their agile planning and the projects and the works and the bug fixes and the working groups, whatever that team may be working on at that point and individuals within that team, it is all part of that process. The manager within that team approves and knows what workloads are, what time is being focused on, what workloads and the team has complete transparency into what each other are doing as well, which has been a big win without question. We have also added goals not just on the management level, but also on the personnel level as well. So part of individuals' quarterly goals have open source in them too. And we are seeing an excitement growing, which is really fantastic to see as we're moving forward within this. We're seeing excitement within the teams and we're also seeing how people are getting excited about, hey, I just submitted my first bug fix. Hey, I just got this upstreamed. I were just about ready to release this project and have it completely open source. And that's what's getting really exciting for us. So I think the proof is actually in the pudding. So maybe we talk a little bit about how we've actually been contributing back to open source over the past a few years. So in the past year, our team has more than doubled their open stack reviews and increased their number of commits seventh fold. We have core contributors on OpenStack Ansible and OpenStack Watcher. And so we're providing a lot of feedback in the areas as we're trying to improve what we're doing in OpenStack. Another area that actually one of our parallel teams has invested a ton is that we actually run, I think, one of the largest, if not the largest, puppet infrastructures in the world. And with about 49 million total resources in puppet that are managed through puppet. And we're also even adding Windows nodes and whatnot. Something else that we're doing is we're actually contributing new open source projects. So in the past year, we've open sourced two large projects. One is OneOps. It's our application life cycle management platform. It was a startup that we had bought a few years ago. We took their technology, we improved it, and we've now open sourced it. It's up on GitHub. And if you guys have any questions about that, we can talk about that offline after. Feel free to hit me up. The other one that we just open sourced in the past couple of months is Electrode. It's a universal platform for React and Node that's been getting a lot of good reaction in the community and positive buzz. And I think they did some great presentations over at Osconn in the UK if you want to catch the videos online. Some of the other things that we've been doing is both internal and now external tech blogs regarding the work the teams are producing. And we formed an internal open source team. So I think this before was called a council. We renamed it to a team. And I think we want to make it, one of our goals is make it as seamless as possible and being able to push open source out the door, not some, we do review, we do try to make sure the appropriate due diligence is done around making sure you're using the right open source licenses and whatnot. Not saying that there's no review, but we try to make that as quick and as lightweight for our developers so that they can be encouraged to contribute code outside of Walmart. So this is actually a photo of our team that went to the Austin Summit. And something we certainly found is needing and wanting to support our individual teams. So we have several different locations working on multiple projects. And it is great to be able to bring people together and support them not only at summits but at different conferences. We host meetups presenting at open stack days. Wherever the information really seems to flow and to fit, whether it's something that we have open sourced, whether it's a project that we're working on, but really coming together, ensuring that we have people attending the operators mid-summit cycles, which I know will be changing, but really making sure that we have that support throughout for our teams. So part of this is we've talked about like, okay, we're doing this open source culture, but maybe some of your, some of you are asking or maybe your management is asking like, you know, what do I get for this? Right? Like, well, what is the benefit? There's a lot of benefits to open source. We're big believers, but just want to talk a little bit about the transformation of Walmart because of open source and, you know, some stats that we've released. We run over 170k cores on open stack. That's actually be growing quite a bit soon. 100k of monthly one ops auto repair. So one ops is that application platform. It's basically self healing. The VM is replacing them every month. You know, whenever it needs to move a workload or repair a workload or there's an issue with the VM. We have over 40,000 deployments in our platform. We support about 3000 different applications right now on top of cloud running through our one ops platform. And we take, we package 60 different open source products that we pull in, many of which we contribute back to and make available through our one ops platform that we push out and they can deploy on top of our cloud with relative ease. So this is allowed our development community to become much more agile, work within our governance structures and basically get things out the door quicker, which is what matters. So we're very excited about the journey that we've been taking. This past year, we've seen a lot afford movement, which is fantastic. We're excited about what we've accomplished, but we are not done. We have only just started and we have some pretty, pretty big future goals that we will certainly accomplish. We are working on adding open source to our managerial or yearly reviews for managers. Again, it's one of our key requirements that both management and teams are really involved in changing to this open source culture. And with that, we need that feedback and that review. We've added it into quarterly goals for team members, but we should be able to review managers to make certain that they are upholding those initiatives and helping those teams to move forward as well. We are working diligently to create as much transparency as we possibly can with our open source culture in and amongst different teams. We're working, we're not quite there, but we are working on complete transparency throughout the company to the point of everybody goes through different peaks with work. And if somebody is pulled off of a project to be able to bring in other people from different teams to step in and maybe they've gotten stuck on a bug fix, so they're not quite certain where to go with that. So to be able to tap into other teams and say, hey, does anybody know where I might be able to go with this or how we might be able to resolve that and have that transparency not just with one team, but throughout our cloud environments. And then also being able to have an easy way for the company overall to take a look at what we're doing. So it's making it as seamless as possible and that's part of including it in the day-to-day work, but then bubbling that up into one specific area in which the entire company, if they so choose, can certainly go and take a look at the individual projects, products, work groups, whatever people might be working on at that time. I'm really embracing continuing to embrace the open source first mentality throughout our development and our review process. And that is something that's continually put forward and something that we are constantly going back to. And that's great. Have you looked at open source as well? What have you reviewed on that end? What are your recommendations? Where do you want to go with those things? Looking at growing our participation, we want to make it as diverse as possible, really pull in people from all areas and not just, okay, your day-to-day work is on Keystone, so you'll work on the Keystone project and have that be it. We've found some great success with some of our development teams and our operators working on projects that they had not much knowledge with, not a lot of familiarity with. And we found that some of them got really excited. I'm interested in X. Okay, we'll give you time to work on that. And then they have brought that back into the company to say, hey, we could look at doing deployments differently. We could do automation this way. And that's been pretty successful. But we want to keep building that. We want to keep growing that. Continuing to build out our participation, not only in summits, but open stack days, open source projects with Puppet, with other open source initiatives, releasing projects that are created internally and releasing them open source-wise. And that all goes into the irresistible developer experience, which is the overall ultimate goal. All of this leads up to making it easier and not harder for people within the company to not only embrace this culture, get excited about this culture, but also be able to move things forward rather seamlessly within it. Okay, so some of the challenges. There's never, nothing ever goes as smoothly as the proof of concept seems to be. Some of the challenges we've encountered, choosing the name of a project, easier said than done. You laugh, but it's actually pretty hard, especially when it's going public, right? So yeah. Research, research. Coordinating across not only teams, but also different work zones as well, especially teams that are exact opposite on work zones. Being flexible, you put together one process and it works for one team. That does not mean it is going to work for every single team in every single location. What's your end goal? Focus on your end goal. The process getting to it doesn't have to be cookie cutter for every single step of that. We're still working on that a bit. And consistency. Again, keep that end goal in mind. The process may need to change. You may need to be flexible on certain things within it, but what is your end goal? What do you want to get to at the end of the day? Again, accepting that the process may change, but not the outcome. Embracing the culture change. Much, much easier to put that on a slide and to say that than to actually have that happen. You have to be an advocate within your company and to really help push that forward. Really keep going back to it and talk to people about your wins. What's working? But be honest about what isn't working as well. Not everything is absolutely rosy. You're going to hit some bumps along the way and that's fine. Just means that you need to readjust a little bit. For us, a key part, and this has been both a challenge and an opportunity, is making the open source work part of the day-to-day responsibilities. So when the ops team is planning out their work for their sprint, they're reviewing their backlog, this is part of it. And it's not something that's shelved. It's not something that is, well, you can work on that after hours. No, this is part of your nine-to-five. This is something that we will schedule out. And this is something that we will work and follow through on. We're still working on that one, still going through that. Reviewing teams. Making sure that there's a clear understanding of the complexity. We've all delved into projects before thinking, okay, great, I'll have this bug fixed out. Yeah, a couple of hours, I should be good. I should be done. And it takes much longer than that. So understanding, readjusting as you need to. Diverse community involvement. Again, we want to continue to grow that. We've seen that that's a big opportunity for us. And then also vendor agendas has been, I would say, both a challenge and an opportunity. So sometimes I think one of the benefits we bring is a specific to the open source community, to the open stack community. As an operator, as we're coming in with maybe a little bit more neutral of an agenda when we propose items and bring bull prints in, we have struggled in the past where certain vendors might not want a feature implemented because it conflicts with their commercial add-on offering. And so just navigating that. Actually, that's one of the things where I encourage all operators, regardless of if you're a vendor in a different space, but as an operator of open stack, to participate more in the operator summits and the design session feedbacks and the various feedback. I know that the cores that we bring to the table are extremely valued by the community because they are kind of in that more neutral place and bring a lot of weight and getting things done. I think open stack has matured a lot in that space, but I think the voice of the operator is probably still, there's still opportunity there for more of it to be heard, so that's a really good place to participate and give feedback in those design sessions and as decisions are being made, even submit blueprints to participate in reviews, what not, because that opinion of an operator is valued very highly and sometimes it's not always there. And that's also an opportunity with the product work group as well, putting in user stories. There are many different avenues that people can look at and take to really make sure that their, quite frankly, their input is heard and received. And I actually think that's one of the wonderful things about open stack is that we can provide that feedback, right? It's not some closed loop where somebody's off developing their roadmap and developing their feature set and you don't have an opportunity to participate. We do have that opportunity. It's just a change in how things are done, right? Before you were dealing with a vendor and you'd go and say, I want this and somebody would go lobby for you inside the company and get on a roadmap and whatnot. No, now we have an opportunity to be part of that design process, part of what's going on. So as operators, that's a challenge for all of us is, hey, if you want open stack to continuously improve and get better and do more things for your organization, step up and participate and, hey, you know, and it doesn't always have to be with actually writing code. There's many ways to participate in the open stack community. Both within the user committee and within the technical community, lots of different avenues. We're exploring them. So some of our key takeaways, building an open source culture, not something that happens overnight. Kind of pick your battles a little bit. Start with some small wins and promote. Promote the good things that are happening. Promote the good things that you are doing. You may not have everybody on board at once and that's fine. Start with the teams that are on board and show what works. Show where you can have your wins. Don't focus your time on trying to bring everybody on the same page all at once because it's going to get a little overwhelming. Focus on the teams. Focus on the places that you know you can move forward and then use those wins to show how much can be done. We're not exactly where we want to be, but in a year we've made some really great strides and we are able to use those wins to keep moving forward and to keep showing that this is working. This is successful. It's still an iterative process. We're getting there, but we can still use that. Trust your engineers. Trust them. If they say that they're working on a project and that's what they're focused on, give them that room. We'll let them work on that. It may not be something that directly relates to absolutely everything they're doing on a day-to-day basis, but one of the things we have found is some very unexpected wins from that. It's allowed some people to think in different terms and to bring things back into the company that we weren't originally thinking of. We weren't originally pursuing. Then of course be flexible enough to take that and plug it in where you can. Challenge is an opportunity. Don't be afraid of failure. Things are going to happen. You're going to start down a path and it is going to be great. Then you're going to take that and okay, I've got this process. It works so well. This is fantastic. You go to apply it to another team and it completely falls apart. That's fine. Not a problem. Work with that team. Include them on what you're doing. The minute that they think something is being told to them, this is how you're going to do it. This is where you're going to start and this is how you're going to end. You will get pushback on it. Again, that's part of trusting your engineers. Include them in the process. What do they want to see? Teams take on a lot of different responsibilities. Include them in that. Make certain to seek their input. Nothing ventured, nothing gained. That's another part of the failure side. If you don't try it, you don't know if it does work or if it will fail. Go for it. Then just another one to throw out. Brick walls just mean there's another avenue to take. It doesn't mean that it's a stopping point. Just means that you need to catch a breath, look everything over again, and go down a different path. That runs us through the slides. We do have a booth at A37. We want to open it up for any questions that anybody has in about the 10 or so minutes that we have left. If you guys would see, there's one mic there. We'll be sure to repeat questions, too. There we go. Good afternoon. Thank you for the talk. This is extremely beneficial. My question, you talked a lot about how to fix the culture and how to bring open source culture in. I'm going to take a wild guess and say that everything you guys produce is open source. What are some tips and tricks you guys can possibly provide on how to balance that process of what's closed source versus what's open source? How are those decisions made and then how is it implemented? Sure. So not everything is, there is definitely quite a bit of proprietary stuff. We work on a team that is thankfully open source focused, and that's pretty clear because we work on open stacks. Pretty much everything that powers our cloud infrastructure is open source, but there are plenty of things that are proprietary that we don't. I wouldn't say that we have at least, so as Megan discussed, we're kind of, I would say, relatively new in our journey. I mean, we have a few years in, but there's still a lot of growth that we're doing. Right now, we have, I think, a pretty simple process in that evaluation. One is, it's actually a lot of it is left to manager discretion and leadership. So in the end, if it's a net new open source project, we do require VP sign off. And so we would hope that between the manager discretion and VP sign off, whether the technology is core to our critical retail business and e-commerce business, or is something that's part of a larger ecosystem in the nut core. And whether we want to open source that or not is going to be up to those kind of chains. And also, what's the benefit? When we open source one ops electrode, we want to build a community around it. We are excited to share. And it's not something specific to our business use cases, right? It's something that we're using as a whole within our technology ecosystem and would be useful in a lot of other technology ecosystems. So it's not necessarily mature, but I don't know that we've had a lot of challenges. It seems like a lot of what we've been open sourcing are natural fit and existing open source ecosystems, right? We're not necessarily open sourcing a bunch of tools around proprietary technologies, right? So it seems that they do tend to bunch together a little bit. Not to say, I'm sure as we go through this maturity process, we're going to come across some of those questions, but we just haven't had a ton of them so far. Sorry, it couldn't be more helpful than that. Well, and then on the other side, too, is looking at what you're bringing in open source wives and being able to cloud moves very, very quickly. And what was there six months ago may have completely changed by this point. And encouraging teams not to be afraid to bring that into the review process, whether it's a new project or new build out wherever it might stand, to bring it in and put that in as part of the review process. Why does that look like that would fit now and at this point? It's not a guarantee that it's going to be chosen, but it should be submitted. So actually into that point, one of the things that we do do is we encourage our entire team to contribute, not just necessarily developers that are bringing in the product, but whether it's a DevOps team or we still have some various traditional operations team, we still encourage them to contribute, whether it be bug fixes or documentation or whatnot. So it's a cross org function that we try to bring them back into the ecosystem, so we keep that ecosystem healthy, not just about the code. And even to take it a step further, the business side. So on the active user groups, enterprise workgroup, reference architecture, really working kind of all different facets within the community, not focusing on one end. That was a great question. Thank you. Yes. Hi, good afternoon. So what are the positive impacts or benefits you have noticed on employee development or employee growth by embracing this open source culture? Is this something different processes in how you work with different people, collaboration? What are the top things that you can highlight that you have noticed? So I think there's a few things there. One, it definitely has helped bring in quite a bit of talent that is focused around open source. I mean, actually, Megan and I were both attracted to Walmart because of what they were already doing in open source. It's helped us with retention on several notes as part of the culture change actually even in the past year that I've been there. As I have discussions with management and engineers sometimes helping them pivot and see how what they're doing could be contributed back creates excitement in those engineering teams. And hey, I'm part of a larger community. I'm not just doing this little thing inside this big company that nobody notices. I'm now contributing this code back. I'm reviewing other people's code. I'm in weekly meetings. I'm part of this greater thing than what's just inside because we don't have 10 engineers working on every single project. A lot of these might be small. As big as Walmart is, we still have sometimes only one person working on that, one engineer. And they can go be, but let's say it's open stack Ansible for example. There's still like 10 other engineers working on open stack Ansible in the larger community. And they have now become part of that team in contributing and doing things. And so actually I think it's helped quite a bit in our retention as we've pivoted to say like, hey, we encourage this and we reward this. And they're like, well, I want to be part of a company that has that kind of culture. And even we have an engineer, we're going to be open sourcing a new project soon around IP address management and that type of stuff. And it's a small project, but he got excited. He did a lot of work and investment in doing that with Ansible and managing it. And now he's like, in the previous world, I would do all that work and it would be used just at Walmart. Now he's like, hey, knocking on the door. Can I open source this and do it and share it with the world? And we're like, yeah, that's awesome. And not only that, we're going to recognize you for doing it. And so overnight sometimes I feel like those benefits are even larger than a lot of the more traditional benefits trying to retain employees. It creates excitement in what they're doing and being able to share it and talk about it. And have other people even contribute and make pull requests and use that code outside the company. Any other questions? Sorry. Did you have any fights with your legal guys? Yes. So to be honest, I would say more of the fights were in the middle. We had, I think, good buy-in at the top, a lot of interest at the bottom. But so there are there are a few people that didn't get it. I don't know that it was really fights, but I just didn't understand it. And so the initial answers from them when their engineers would go up and be like, can I open source something? The initial answer was no. And we're being frank. And then we would find out about it and be like, can we talk to you, Mr. and Mrs. Manager? This is why we want them to do what they're doing and why you should encourage it. And to be honest, as far as I know, every time we've actually had, it's really education, right? Every time we've educated somebody on this topic, right? We probably should do some more org-wide initiatives around education, right? But every time we've done at least one-on-one so far, or part of our larger open source team have done that, the responses always ended up positive. It's never been like a long-term quote-unquote fight where it got shut down. It was almost always we educate. They're like, oh, that's awesome. Oh, I get it. Okay, let's do it. But it was usually due to some misconception around open source. I mean, maybe I shouldn't poke at vendors too much, but some vendors do like to paint open source, even till this day, shockingly, as some negative, unsupportable, miserable beast of some sort. And reality is that's not true. I had somebody the other day tell me that NoSQL is not production ready. And I'm like, and what world are you living that NoSQL, Cassandra, and whatnot databases are not production ready? There are a lot of people running it in production, right? So there's still a lot of that myths running around that maybe the vendors and others propagate, or maybe those loyal to those technologies, that really it's just an education thing that you have to work around, which I feel is like with anything new, right? How do you guys keep things coordinated across different offices and different groups so that you don't end up competing versus like, so you use open-stack answer. You also use puppet. They're not necessarily conflicting, but they certainly can be depending on what you're doing with them. How do you make sure that you don't have two teams doing two different things and then all of a sudden you find out you have both of these? I would say that that at times is still a struggle. Yeah, I think so we definitely still have some of that. We haven't fully solved that problem. I think we have a couple groups that like now meet globally across the organization to kind of review from an architecture engineering standpoint what are recommended, what are best practices. I personally like to take more of evangelism approach where we're sharing what we're doing. We're sharing all the teams. That's kind of where the transparency comes and everybody should be sharing what they're doing. Maybe selling is too strong a word, but like I like that evangelism where like say, tell the world about what you're doing and hopefully then it'll be like, well, actually what you're doing in Ansible might work better than what you're doing in puppet or vice versa, right? And let's address the problem that way. And so that's how most of those conversations are happening. Some of the things that we're actually working on putting on is several company-wide cloud days, kind of internal events where we also evangelize so people can get on board with all the different projects that are happening and maybe hopefully get some cross or participation on a lot of those projects. Looking for more participation outside of just the direct, quite frankly, cloud teams or team we're responsible for supporting the project. Yeah. Exactly. Any other questions? All right. Well, we're just about at time. So that is perfect. Thank you guys very much for your time. Appreciate it.