 I don't know, my mic's not on, or is it? I think it is. Oh, it is now, okay, good. Well, welcome, and thank you guys for coming to our talk, AT&T's Upstream Journey, Open Source Within a Fortune 10. So my name's Darla Ailert, and this is Steve Wilkerson. We work for AT&T as part of AT&T's OpenStack community team. We're both applications developers on our team. And we've actually just started AT&T in June of 2015. So just a little bit over a year ago, we were hired onto AT&T as part of our college hire program. This program is actually a really cool program because it allows you to potentially work in many different areas of the business. And we had the opportunity to start working on AT&T's Integrated Cloud, or AIC, in July of 2015, just shortly after we started with the company. And as you can imagine, AIC uses OpenStack as its cloud platform. So whenever we first started on AIC, we started to look into the different teams that they had. They had a lot of different scrum teams that were focused on different areas of OpenStack. And we couldn't seem to quite fit into any of those for some reason. And it ended up being a really good thing that we didn't, because then we were able to actually create our own team. It was a very small team that was just focused on getting the idea of Open Source out to our company, out to our leadership, fellow employees. We wanted to just change the way that employees thought about Open Source, and we wanted to change the way that leadership was thinking about Open Source and get them to back us up with what we wanted to do in the future. So this eventually turned into what I just said was the AT&T OpenStack community team. We presented in Austin actually just a brown bag session. Very quickly we were able to talk about why our team exists and what's important to us and all of that. So just to recap really quickly, it's really important for AIC to start catching up to the community. Or at least get as close as possible, because as of right now, we're a couple releases behind. And we've also created a lot of technical debt. So each new release, we have to carry that technical debt into every new release, I should say. So each release, we're pushing new features that we've created in our own internal code base into the new release. And as you can imagine, this takes a ton of time and a ton of effort. And then the amount that we have to push into each new release only continues to grow because we keep making new features. So we needed to change this. We needed to start using features that were already built within OpenStack instead of just bringing that down into our own internal code base and editing it from internally. So one goal behind our team is to reduce the technical debt as much as possible. And that way it's easier and easier to upgrade with each new release. So we wanna do this by either finding preexisting features that accomplish what we need them to, or even taking some of the features that we've created if the community wants them, pushing them out to the community and really start contributing back. So we know that if we really want to change to an open source mindset, we have to do just this. We have to contribute back. We can't just be the company that takes everything without giving something back. So that's what we've been working on. Our team is 100% focused on contributing to the community. We do have a focus around some high level areas like containerization, upgrading, scalability, hardening the platform, those sorts of things that we're focusing on. But we do want to just help the community and contribute back to the community as much as we possibly can. So just to kind of give you an idea of where we came from and where we're at. In August of 2015 is when our team was officially started. There were just three of us. It was myself, Steve, and then a coworker, Darren Shaw, who unfortunately wasn't able to make the trip. But we wanted to build this team. We wanted to build it with fresh minds, people that would be excited to work in the open source world, people that would realize how awesome of an opportunity this is because it doesn't happen very often, that especially at big companies that you get to go out and work in an open source community for your company or on behalf of your company. So we thought, who better than people like ourselves? People fresh out of college, the ones that haven't been in any sort of big business or big company, they're getting in, they're excited to work in general. And then whenever we say open source, they get even more excited, those types of mindsets. So AIC paired with the college hire program that Steve and I are in, and we are able to continue to build our team up over the past year or so. As of right now, we have about 35 team members total, 30 total developers, 18 of which are first year developers. So over half of our developers are fresh out of college. We also have five leadership type positions like associate director, scrum masters, things like that, which are actually really important to engineers like us because those are the roles that keep us focused on development work while they deal with all the other stuff that we don't really care about, which is nice. So the end goal of our team is to obviously contribute to the community first. We have some people that are currently working on AIC scrum teams, because right now it's two separate teams. So we have AIC and then the community team. So we have people working in AIC scrum teams that are essentially paving the way for where we want our team to go. And we're working very closely with them because they're contributing everything to the community first and then bringing it back into the AIC code base. And this is exactly what we want. We want to be those type of developers that put everything into the community and then bring it back to where we need it. So eventually we want to be one big blended team. So like I said, we're two right now but our goal in goal is to just be one big AIC team that contributes to the community first and then back to AIC as I said before. So along with that we have a lot of others outside of our team that are also contributing to OpenStack. And kind of another goal behind our team is to be able to help coach people, show them the different ways of an open source world, get them in the open source mindset, teach them how to contribute. Anything we can do to basically help our entire company, not just our team, become open source contributors, we want to help with that. So of course I have to throw some metrics up here, right? These are contributions that we've made over the past few releases. And I grabbed these beginning of last week so I'm sure if you looked at Stack Letters right now it would be a little bit different because I'm sure we have really hard working team members back at home just contributing as much as they can. But so just a quick side note, this is just our team. So even if you went out on the same day that I grabbed these metrics from and looked at AT&T it's going to look different because we have a script that the third presenter Darren Shaw actually wrote that uses the Stack Analytics APIs to grab information that we need like specific people. So of course we have people all over AT&T contributing to OpenStack but we want to be able to look at just our team members and also see how our team is doing outside of the entire AT&T Stack Analytics. So this is for like I said, this was grabbed with just our team members but you can see that there's a general upward trend obviously minus Okada. But a couple of important things that I think are really cool, Liberty. We had one commit and 98 reviews and then by Newton we've gotten up to 267 commits and 692 reviews. So this is exactly what we want to see. We want to see ourselves contributing more and more as time goes on. And then the same on the right hand side are our drafted and completed blueprints. So we had six drafted blueprints and three completed blueprints and Newton when in Liberty we had absolutely no blueprint contributions in any way. So these are the types of things that we want to see. We're really happy with the progress that we've made so far. We think we've done a good job at easing ourselves into the community especially having all junior developers some of which who had never even had open source experience before, let alone OpenStack. I don't think anybody on our team had OpenStack experience prior to joining our team. So there's a very steep learning curve whenever all of these developers joined our team. So just to point out the blueprints that we did complete or helped complete in Newton, we have Keystone, Heat and Cola. So in Keystone we helped with the honoring schema validation everywhere blueprint. Basically the schema validation was only enforced for the V3 API and it wasn't enforced for legacy Keystone or V2. So this blueprint enforces it in those areas. With the heat we were able to draft and develop the blueprint that enhances heat orchestration over glance metadata. Basically just adds additional tags in the metadata which allows for more fine-grained control at the orchestration layer. And then in Cola we drafted and developed a blueprint which was a VMTP container. So VMTP is a small Python application that runs in network testing and it can also run diagnostics on your cloud's network activity. So these are all three features that we were able to contribute to and we're really excited about being able to actually start on blueprints because we started mostly on small commits and reviews prior and we wanna start making really good contributions and not just the low hanging fruit type of contributions. So over the last year we faced a lot of challenges throughout this journey of ours. Changing the culture of a Fortune 10 company is no easy task. We want to change the entire mindset of our entire company, not just our team. So getting leadership to back us up was easy in some cases but very difficult in some others as you can imagine. And then once we were finally able to get their approval we ran into a lot of more roadblocks like company standards, funding, things like this. And Steve's actually gonna tell you a little bit more about those. Yeah so the way I wanna approach this is kinda give you an idea of where we started and then look at where we're at now and look to where we're going because all three time periods there are very important because it gives you an idea of kind of where we've been and the growing pains we might have felt and look at opportunities. And this is something that we like to reach out to other people, whether it's individuals or other large corporations or even small companies that are involved in the community and try to get those lessons learned too because there might be a lot of similarities and there might be some aspects there that we can look at that maybe we hadn't considered. So those are all very important. So the first thing I'd like to talk about is some of the company culture stuff. Darla touched on this a bit like she said, changing the culture of a company, especially a large one, isn't going to happen overnight and it might not happen even over the course of a year. You know, it's something that's, you know, a common theme I've heard is that a lot of these larger corporations kind of feel these same growing pains so I'm not really surprised looking back that this is kind of what we're experiencing but that's a good thing. So the first thing I'd like to touch on a little bit is our Chief Strategy Officer, John Donovan, laid out this ambitious goal for the company to start adopting and contributing back to open source projects. The theme in Austin was that OpenStack is extremely disruptive and that's a good thing because it's changing how the industry's working, it's changing the technology and we really wanna be a part of that. We can't not be a part of it just because if we're not involved and we're not contributing and we're not staying in tune with the community, we're going to get left behind and with a huge technology that's as disruptive as OpenStack, we really wanna be there and I'm really excited to be a part of a team that's really on that path right now because it's a lot of the other, my peers that I graduated with who are in similar programs, I explained to them what our team's doing and what I've been able to do and participate in as part of this team even over the course of a year, just blows them away and it blows them away even more when they kinda look at it and they're like, what, I never thought AT&T would really participate in something like that, how did that happen? And kinda laying all this out, it really, it's fantastic seeing people's reaction. So where we're at now with that is our team in particular is really focused on open source first. So if we identify a problem with our team whether it's metrics gathering, how we're wanting to approach a problem, how our team's communicating, we're always looking for open source solutions because that helps reinforce the mindset of how we're working. And we don't want to be a team that's working on open source projects and trying to participate in a community if we're not really looking there first. So it's really kind of a habit and culture thing at the individual level as well and our team's doing a fantastic job with that. As far as the AIC scrum teams, at least when I started, it seemed that a lot of those teams were more like component or area focused, which is why it was kind of difficult for me in particular to find a home whenever we were considering joining internal AIC scrum teams because I couldn't, I didn't know enough about each of the components to really figure out where I wanted to be in the future. And when you're asking a new developer who's coming on, they're like, okay, you have all these options, which one would you like? It's like, well, I don't know. This might take a while because me personally, I need to look at each one and kind of identify where my interest is. So where we're at now, the scrum teams within AIC are, it's not just those silos anymore, they're cross-functional teams. So you've got people who are looking at a particular problem from various different angles and identifying how the features that we're looking at or what we're wanting to adopt affects the platform as a whole, which is fantastic because I'm not a huge fan of knowledge silos. And whether it's something like AIC or any other team, I feel like knowledge silos are very detrimental because it kind of compartmentalizes that knowledge within a subset of people. And whenever those people leave or you're trying to consider a new way of approaching a problem, it can be very disruptive in a bad way to your organization. The last point for company culture, this one, for me, I always get a good laugh out of and I put it on here hoping that some others might feel the same way as, you know, this is not just an AT&T thing, right? Like a lot of these companies are going out with all these buzzwords, like open source, collaboration, agile, you're doing all these things. That's great because that stuff drives change, but how are we acting on that? Like how is this changing our culture as a company because it's not a one-size-fits-all solution, right? Like smaller startups might look at how they collaborate and approach co-location issues or agile issues in a different way than a large company, especially telecom, like AT&T. And our team has actively been trying to drive that change, not only within our team, but our college hire program and some of the other teams that are peers in this college hire program are a part of, so it's not just our organization and AIC's organization, it's these other organizations across the company. For example, one of these, like I love agile processes, like huge process nerd, favorite process is Kanban. And I know some people like, you know, everyone's got their favorite and the Kanban one speaks to me, you know, a lot of the shops I interned at and worked in before AT&T were Kanban shops, but some of our fellow AT&T college hires talking with them that like, yeah, could you tell me a little more about this? So like sit down and talk with them and I get really geeked out about it and they've actually taken it to their teams and they come back to me, they're like, yeah, we're gonna try it, like really excited to see how it turns out and it's really awesome being part of a team that's driving that change, you know, not just within our organization but across the company. All right, so I wanted to talk about leadership support and this one's a big one for me because without support from your leaders whether they're directly or at the executive level, you're not going to get very far and it makes driving these changes that I mentioned even more difficult. So where we started, we actually had passionate backing from our immediate supervisors and AIC. So that's our director, Andrew Lisik, that's our executive director, Ryan Van Wick, very passionate about this community program because they saw the value in driving these changes and getting involved in the community because without doing this, in terms of our long-term goals, this is where we needed to be and they had that clarity and they're like, this is where we're at now, this is where we need to get, we'll figure out how to get there. So where we're at now, we actually have executive backing and buying for the goals for our team and that goes, you know, our assistant vice president, Greg Stiegler, we've got our senior vice president, Sorb Saksiner are all, they are passionate about this team and they're helping drive this team forward not only in the ways that we're approaching our work and how we're changing the way we work but also laying out the goals in the roadmap for our team. So it's not just, hey, we're going to unleash you in the community and you're gonna do whatever you want. You know, they are actually guiding us to where, you know, we need to end up as a company but also where we need to end up as individuals because, you know, a lot of first year developers, we're not going to have the foresight to really understand the business value of why we're doing this down the road but thankfully with all of those people tied in together, whether it's our immediate supervisors or, you know, our executive leaders, like they are helping, it is, like I said, I'm so geeked to be part of this team and this is just another reason why because we have people who understand it and are helping us mature as a team and driving us towards our goals. And here, full disclaimer, I'm not a lawyer, so, but I do want to kind of touch on some of the legal funding and standards concerns that were brought up with this team when we started and where we're at now. I remember when I started, one of the big issues that was kind of being floated around was how do we handle contributing changes upstream, whether it's something that we're doing that's a new feature or if it's something that's already been developed and that we want to try to release upstream to the community. Because that does present a challenge because traditionally a lot of people can probably know where I'm coming from. It's, if you're working on something at work with work materials on work time, traditionally it's the intellectual property of whatever organization or company you're working for and that's completely understandable. But how does that fit with open source software and a team that's dedicated solely to working on open source software? So that was kind of, there was that framework that was started whenever we started there, so there's things like the CCLAs that you have to sign for open source projects if you're contributing on behalf of a corporation. But it seemed like that wasn't enough from my perception. It seemed like there needed to be some further hashing out on the legal side with that. Like I said, I'm not a lawyer, so I can't really speak. I might be off base, but I think that's the way that this was approached. Where we're at now with that is that we actually have approval to contribute not only to OpenStack, but there are other open source projects that we can contribute to. So for example, recently, I think it was a week even before we came here to Barcelona, we were actually approved to start working on Kubernetes. And it's been a very common theme of the summit, Kubernetes is another very disruptive open source project that's really gonna shape the way that not only OpenStack runs, but also how applications in the future are going to run. So it's really exciting that that framework's there to approve our open source developers to actually contribute to that as well as some of the other projects. So that's fantastic. From the funding aspect of that, I know this was changed recently and I'm not super in tune with the funding aspect, so I don't wanna touch on this too much and maybe explain something the wrong way, but I know that there was an issue with how the open source development that we were doing was approached from a funding perspective. So with a large company, the financial stuff is a huge part of that. And I totally understand that. I totally understand that the way, some of, I don't wanna say roadblocks, but some of the issues that came up whenever we were working, I'll just say that I'm happy that they were revisited because it seems that the way we're going now in terms of how that's looked at is actually going to be beneficial for our team in the long run and not just our team. It's any open source development that's occurring within AT&T, which is fantastic because that aligns with the vision that I mentioned earlier with John Donovan laying out our path going forward that we need to start contributing and utilizing open source software more. And finally, I wanted to touch on standards a bit because standards are always a thing that corporations and companies are considering. And sometimes maybe your corporate standards, the way your approach development doesn't necessarily align with the community. There might be some common themes there, but you can't always expect them to line up perfectly. And especially with OpenStack because each project is gonna have different ways that it approaches how you're doing your development standards, your testing standards, how the tests are run. So it's kind of a, I don't wanna say a challenge, but it's a learning experience trying to figure out how we can apply our standards at AT&T to the community standards. And that's a good thing because it's helping us see the bigger picture and maybe trying to identify opportunities where we can maybe drive some change in the community or the community can drive some change into the way that we approach standards internally. And finally, this slide is very near and dear to my heart and I know growing pains at a glance seems like, it might be a negative connotation, but it's growing for a reason, right? So I'm a firm believer that if your team's not feeling these growing pains, you're not given the drive to change because if everything's working just fine and you're not experiencing any difficulties or these growing pains, then why change, right? The first one, balancing business needs and engineer preference for projects. This is huge with OpenStack because there's so many projects within this ecosystem. There's, we have people who are interested in Trove. We have people who are interested in the networking aspect. I personally, I'm very interested in the COLA project and infrastructure in general. We have people who are interested in Keystone, Nova. We had people who were interested in Minasca. So how do we balance all these personal interest of our engineers with the business, the goals and strategy for the business? And this was something that originally we kind of had a growing pain with because of course, whenever you're working with something really cool and all-encompassing like OpenStack, you're gonna be drawn to what interests you because that's what's going to motivate you to succeed and kind of, yeah, that might also present opportunities for you to take those lessons learned and what you're really passionate about and try to drive it back into our platform internally. So where we're at now with that is we kind of, we found a way to balance that. So instead of approaching this from, we really need these goals in this one specific project, we kind of have these overarching concepts like Darla mentioned. So we have security, hardening of the platform, there's upgrades, there's deployment, scalability and we can kind of tie in aspects of a few projects under one of those umbrellas, which is fantastic because it allows our engineers some flexibility while still helping drive those strategic goals for the business. Giving leadership insight into work without being disruptive and I don't mean this in the way that our leadership was being disruptive and trying to gain insight into the work we're doing. I'm saying that our engineers originally were responsible for kind of speaking on the message of what they were working on which is to be expected but once we started growing our team and started working on more projects that could become a little cumbersome which is why we started including some of the leadership roles in our team. This also comes into the metrics gathering and this is something that Darla touched on a little bit with the original way we gathered metrics was we would run a simple bash script that was using PyStackalytics, which is just a Python wrapper for the Stackalytics API and running this manually which was an improvement over what we did initially which was going through Stackalytics and finding people's name that worked on our team and writing the tally on a window above my desk because that's how people could look at a glance and be like, okay, that's where you guys are at that's fantastic. I see you guys are actually driving forward, you're making some change but we needed something more to tell that story. The solution past the Python script was actually creating an internal dashboard that would pull those metrics and create almost like an internal Stackalytics for our team but I'll freely admit I was one of the people who was skeptical of this approach because like Darla mentioned, the purpose of our team was to reduce technical debt among other things but creating an internal Stackalytics dashboard was creating technical debt to show we're working to reduce technical debt and after a while I was like, yeah, this might not be the best approach, it's better than a Python script that we're running manually but there's gotta be something better. So fast forward to, I guess this is about seven weeks ago we just, well one of my team members, Brandon Joseph, discovered keen.io and it's actually really cool, it's almost like analytics is a service, you can create these events that are triggered, you can trigger them manually, you can set up web hooks and GitHub repositories and that was actually great because we could just feed this information to Keen and you can set up, it will set up a dashboard for you that you can just take a glance at and you can set it up however you want so you can put whatever information that's meaningful at a glance without being too disruptive and requiring too much additional work from the team and this is great for those times that people are like, oh hey, how are we looking since the last time I approached you about a week ago, are we improving, are we stalled on something and this simple dashboard, they can just take a look at it and it'll show these metrics over time, you can show PyGraphs, you can show just a flat box with a number showing that you've increased and it's like, this is great because now this reduces the disruption not only on our developers but also our leadership roles so they can actually get this information in a timely manner and focus on selling our message and kind of relaying that information instead of how they need to get that information. I'll touch on the scrum process here, as I mentioned, huge process nerd, love Kanban. After a while we kind of realized that maybe scrum wasn't the best fit for our team and that's AT&T's a scrum shop so we assumed that that would be the process we would use but the more we looked at it, it really didn't fit because we could still divide up the work into chunks but in terms of time-boxing that work it was kind of difficult because we're not focused to our developers' work anymore, we are focused on how are we interacting with the community, what's required to drive these changes forward, do we need to go through this and review it and code review again? So we figured Kanban would be a better fit here because we're still dividing up that work in meaningful chunks but instead we're not going to time-box it, we're going to order it by priority which scrum also orders by priority but we felt Kanban, like I said, would be a better fit because then we weren't forced to time-box things and we could focus solely on prioritizing our work and also identifying how we could move that work forward if we noticed it was getting stuck and that was fantastic it's actually been a huge help for our team and I'm really happy to have been a part of that I brought in one of my fellow team members, Larry Rinsing on that, he was also very instrumental in that because he came from another company that was a huge Kanban shop and it was very successful for them and they felt a lot of the same process pains that we were feeling so it was fantastic and that's like one of my favorite accomplishments that I've had on this team also how to mitigate the effects of budgetary constraints you know it's no secret and this is, you know, across the industry is that companies from time to time are going to feel they're going to have to revisit their budget and for us that could mean we might not get as many developers as we had planned on it means things like attending the summit and mid-cycles might be a little difficult and those are huge in, you know, working in this community and driving these features and contributing and everything else thankfully our team has been able to strategically determine how to work with what we have and get the most value out of it so instead of focusing on well this is unfortunate because we can't go to the Barcelona summit and meet with the community and drive these changes forward instead we're always trying to find ways outside of the box so that's whether, you know, traditional IRC stuff we've recorded a lot of the sessions for our team members we've kept them in the loop at the end of the day kind of, you know, for example some of the COLA stuff some of the neutron stuff any project that we have engineers working in we're trying to send that message back home so there's not that latency of us being here wrapping everything up, going back home presenting to them and then worrying about it we actually have people looking forward and this is, you know, it's been very successful for us so I mentioned I wanted to talk a little bit about where we're going I know I've been talking a long time I haven't even looked at the time, I'm sorry but this is kind of lays out where we started where we'd like to be and further down the road we really want to go so first whenever we onboard individuals and whenever our team first started it's, we call it housekeeping issues and I, our housekeeping I don't want to say issues but housekeeping I don't, yeah housekeeping and this was getting people familiar with the projects that they would like to work on that align with our strategic goals by you know, contributing via low-hanging fruit items on the project that's a great way for individuals to get started with the project and be able to contribute something to that project without feeling like they're in over their head we also look to try to collaborate on existing blueprints as much as possible a lot of projects out there have a lot of work especially this time as the summit's wrapping up all the projects are kind of aligning on their items for their road map before the P-release so this is a great place for us to try to get involved with some blueprints and then also just building the foundation for contributions so that's building those relationships the biggest takeaway I've had from Austin and this summit is that the connections that you build with people are like one of the most important drivers in this community and it's not I don't mean that in the way of driving features upstream but just being able to participate in this community you can't I mentioned before that I don't like silos and you can't be a a silo as an individual in this community because then if you're not communicating with people and you're not putting yourself out there and you're not volunteering for taking on these tasks whether it's bugs, reviews, or blueprints or whatever like you can't you're not gonna have much success so that's really something we try to instill in our engineers early on following that really the end goal is to just get these people in these projects and help them build that expertise and build those relationships because that's how you become a more active member in these communities that we're part of it's really difficult to say it's really difficult to I don't like to say gain influence but it's really difficult for your voice to be heard if you're not actively contributing you know we don't want to just throw people in there and say well we really want to see this happen with the project and then have them ghost away like this is an investment for our engineers and they really need to own that and finally we really you know not only as AT&T but as individuals we really want to help drive this platform forward simply because we've seen how disruptive it is and we want to be a part of that like I said we don't want to not be on this this path forward with OpenStack because if we're not we're gonna get left behind and that's not what we want as individuals and that's not what we want at the company level so it's very important for us to be involved in these projects in the long term and that's all we have we have our contact information here if you have any other questions I'm not sure we have seven minutes if anyone has any questions I think there's a mic thank you for the presentation it was really awesome to hear that going upstream can be so fast my question is that if you find some bug in your system which is really really affecting your production how do you handle that? you want to fix it there but you also want to follow the upstream first strategy so how do you solve this issue? so if it's affecting production I would imagine since our team focuses solely on the upstream work so it's a little difficult for me to answer that but I'll answer it the best the way that I would approach it so if it's something that is actively affecting production it needs to be fixed however that being said if we notice that it's affecting production in a way that's extremely disruptive it's also important to take that to the community because maybe that's something that another company's feeling so a lot of these problems that individuals and operators see in OpenStack is not relegated probably entirely to their organization, their company and their way of operating OpenStack so for example being a telco maybe some of the other telcos that we are actively in contact with or who we might not even be aware who are involved with OpenStack yet we can take it to the community and say hey, this is something we've noticed this is how it affected us and here's how we think is a good way to mitigate that and that's part of being a great community contributor is not just taking that knowledge and that lesson learned and keeping it internally because that's very detrimental to driving OpenStack as a platform forward Just one technical question that you create an upstream solution for that but you maintain your downstream until it gets merged and get to the next version, right? Yeah Okay, thanks I don't exactly have a question but I want to congratulate you when I started at AT&T out of the new hire program we had some workstations on the desktops and one of the first things I did was try and convince people we should put Linux in place of these some workstations and there was no acceptance whatsoever of open source in any way, shape or form it was going nowhere and we've made tremendous strides and then when I was at the Vancouver OpenStack Summit I can't tell you how many times I spoke to people saying look, we want to contribute but I have no developers I'm an architect, I know how to do code I don't have time to do code we're trying to figure out how to get people to do these things but right now I'm just telling you what AT&T needs we don't have the resources so I gotta thank Andrew and Ryan and Greg for their support and you for starting this team and really driving it forward because now I can have conversations with people and I don't have to be constantly apologizing for the fact that we've got this long list of requirements and we have no resources and now we have those resources and that is a terrific improvement over the time since Vancouver Awesome, thank you Thank you, this was very enlightening especially hearing that you started up this new small kind of nucleus of a team I'm curious to know is your primary purpose to serve as kind of an incubator and a sounding board for other parts of the business or do you have specific projects that you're developing that again you keep looking back to the strategy the business and the focus from your chief strategy officer so I'm just curious kind of what your principal role is and is it mostly kind of evangelizing OpenStack and assisting other teams to achieve their goals Do you want to take that one? I think right now I think our sole focus is OpenStack or at least our main focus but as Steve's mentioned we just got approval to start working Kubernetes and I think that that process is going to continue I think that we're going to continue to add more and more open source projects to that list of projects we're allowed to contribute to and I know that we do want to be advocates for open source in general right now of course, like I said our focus is OpenStack because that's what we're working on but we want to be able to go out to the entire company and just promote open source in general Does that answer your question? Thank you You guys did a fantastic job I know you were both at the last summit Did you go and see the purple squirrel chasing purple squirrels? We were not We're taking it a little too literally here, I think, Stephen but we did find a bunch of our purple squirrels which has been great Can you speak to maybe the contingency here about how we've approached different models of growing talent? We've started with, as you said, STEM talent right out of college with no mentors We've introduced mentoring in different regions and then we've, with depth of OpenStack and we've introduced mentors with just general engineering backgrounds and Steve and Darla, I know you both can speak to this because you've both done both Yes, so I mean, like you said we originally started our team based solely on STEM talent We do, we realized in the process that we need more senior developers to help us, right? And we were able to go out to other aspects of the business For example, Steve mentioned Brandon Joseph He's an awesome guy He was in a different part of AT&T but we were able to grab him and snatch him and bring him on our team and he's been a huge asset to our team and I know that we're going to continue to do this We want to get more senior developers more senior engineers, architects just reaching out to anybody within AT&T and even outside of AT&T that can help us grow as individuals and as a team Yeah, the mentoring aspect is very important So I believe it was in Austin Rackspace had a presentation on how they approached their training program for community engineers and one of the things that really stood out to me is they have this solar system model where they consider their son to be a more senior experienced OpenStack developer In a particular project, it might be multiple projects but then they align new community developers around them So the idea is that is they're working with these individuals they're kind of growing that talent themselves and not only learning more about OpenStack itself but developing the engineering practices that allow them to be successful in the community whether that's the soft skills or the harder engineering skills and I think that's fantastic I think that's one route we're starting to go on this team as we get more senior people on the team and even just in the few months that we've had those more senior individuals on the team I feel like the team as a whole has really kind of gotten a better idea of where they need to go forward in developing that talent Looks like we're out of time Thank you all so much for joining our session