Last week our featured guest was Carol Barrett, who not only works in data center planning at Intel, but is also a leader in the OpenStack Community. She's deeply involved in the Product Working Group, the Enterprise Working Group, and the Women of OpenStack, which means she's got a lot of insider knowledge about what is going on at this moment with OpenStack, and what's going to be happening down the road. If you missed the live podcast, check out the recording to hear Carol's thoughts on:

• How being a woman is her competitive advantage in the tech world
• How the OpenStack Product Working Group is speeding innovation
• Who the "hidden influencers" are and why it's important to get them out into the open
• What the Enterprise Working Group is trying to achieve
• Why enterprises are so tight-lipped about their use of OpenStack
• Why Intel is so involved with OpenStack

https://www.youtube.com/watch?v=hxSTeyyaJDs

Have a show idea? Tweet Jeff and Niki at @openstackpod

See past episodes, subscribe, or view the upcoming schedule on the OSPod website.

To see the full transcript of this interview, click "Read more" below.

Jeff Dickey:                All right, we're live everyone. Hi, I'm Jeff Dickey from Redapt.

Niki Acosta:               I'm Niki Acosta from Cisco, and we have an awesome guest, another awesome woman in tech so I'm super thrilled to have Carol Barrett with us today. Carol, introduce yourself.

Carol Barrett:            Hi Niki, Hi Jeff. Thanks for having me here today. My name's Carol Barrett, I'm with Intel Corporation and I work inside of our open source technologies center specifically on open source software for the data center, which puts OpenStack front and center for me.

Niki Acosta:               Fantastic. We typically like to introduce our guests and always ask how you got into tech.

Carol Barrett:            It was sort of a last minute call for me as I was getting out of high school. I'd always been really strong in math and was looking at different career options. Then my senior year in high school I needed to go ahead and fill out some electives, and they had one on, I think it was computer programming basics. It was a little Honeywell system, a 2100A, and you walk into the room and it filled the entire room. I know I'm dating myself. We actually had paper tape that we would use to go ahead and create our hello world programs on and then put it through the system to actually load it up and make it run. I thought it was just absolutely fascinating. I really appreciated the structure and the logic around it and the way it played with my math background.

Then I started looking for colleges that had computer science or computer technology or computer engineering programs, and I eventually went to Rochester Institute of Technology in upstate New York, which was one of the ones that was sort of leading in the development of programs like that in the late '70s, early '80s at that point in time. I didn't really know what I would do with that and going through the first couple of years of school, it was just all the basics. I still really didn't know what I would do with it as a career or how it would manifest itself out in the world. Then I went and did a co-op for 6 months with General Dynamics, the electric boat division in Groton, Connecticut. I worked on weapons systems on the USS Ohio, the first trident class submarines. That really gave me a strong sense of, "Okay, there's a big world out there of ways you can use computer technology," and that I could start to really identify usages and application areas a lot better after I had that experience.

I continued to become more and more fascinated by it and eventually when I did graduate, I started working in embedded systems because I really found that that interaction of software and hardware that would instantaneously make something happen, was really exciting. I developed all types of different instrumentation and hardware development devices for a long time before I actually moved further down into end user type of software applications. It just amazes me as I look back now on how mainstream technology has really become. It just always, always amazes me and delights me quite honestly because I could never imagine it when I started in technology 30 plus years ago that it would get this far.

Niki Acosta:               Speaking of 30 plus years ago, I can't imagine at that time, you can correct me if I'm wrong, but that the number of men versus women in college period was much higher than it is now. Women are more dominant at this time, but I suspect that there were very, very few women in that program. What was that like?

Carol Barrett:            I think it was probably even accentuated because where I went to was a school that was really primarily for engineers of all different flavors. That was going to reduce the number of women that were going to be there anyhow, besides being in just computers alone. It was interesting and at first, it was intimidating. I'd say actually through most of college it continued to be a challenge to still be willing to give my thoughts voice and speak out in classes and in small teams where I would be the only woman in there. To go ahead and say, "Well, I think we ought to do things differently." When I got out into more of the professional world, I actually discovered that being the only woman in the world was my competitive advantage, because I thought differently than the majority of the other people in the room.

I had a different viewpoint that was unique and that if I had the courage to go ahead and speak up and express it, that people would generally be open to hearing it and it would cause them to think. Then that whole process of merging the different viewpoints so a better overall analysis or design emerged, really came to be. I would think of it that way when I would go into a session where I knew I was going to be the only woman. It's like, "Okay, that's my competitive advantage. How am I going to go ahead and use that to contribute something to the meeting that I was getting ready for?" That was a learning point for me, was discovering that competitive advantage piece.

Niki Acosta:               That's awesome. Taking something that could be maybe a little intimidating and turning it into something that's advantageous. That's really cool. Carol, you've been doing a lot of work with the product working group and the Enterprise working group, and just before the show you talked about how those two things dovetailed together. For those of you who are watching the live video of this, Carol wanted to share a couple slides. If you're just listening in we'll do our best here to kind of explain as we go through these slides since you obviously won't be able to see them. We will make those slides available for viewing and we'll post those through the Twitter account, through the YouTube video, and through the blog once we get the blog posted with the transcripts of this. Carol, I'll turn it over to you to take us through the product working group overview and talk about the good work that you and many other people from many companies are doing to drive OpenStack forward.

Carol Barrett:            That's great, that's a great topic actually. I'm going to start with the last piece, which is who are the folks that are involved. What you're looking at here is just a representative sample. It has obviously, Intel's involved, but we have folks from Cisco and Rackspace and Mirantis and Red Hat, and Dell, and VMware, and EMC, and just a really large group of folks have come together. The focus around the product work group is looking to actually be a place for aggregation for the different use cases, sometimes we call them, requirements sometimes we call them. It really represents the needs of different markets or users that they have for being able to go ahead and deploy OpenStack in their environment. Whether it's Enterprise, whether it's a high performance computing installation, whether it's a Cloud service provider, any of those.

Really looking to be that place where we can bring all that information together, identify the commonalities across those needs, and then be able to provide that information into the technical community. Whether it's the project team leads, or the developers, or the technical committee quite honestly, to be able to bring more information ideally in some type of a ordered format as another input into the design summits, and the specification of what will be included in the different releases of OpenStack. The goal there is to make sure that all of the development resources that are going into OpenStack have visibility and or are working on the features and function requests that are most important and will help us to increase the adoption and deployment of OpenStack throughout the community. We'll get more feedback and we can continue to really grow and have a vibrant ecosystem.

What we've done today is, in preparation for the summit, we really worked on two things. One was, "How can we put together a starting point for the roadmap?" Looking to be able to publish out a multi-release roadmap that would be able to communicate outside to operators and users of what they directionally can expect in the upcoming releases of OpenStack. Then inward to the community to be able to be a tool for detailed tracking of where we are or in implementing these capabilities. I think one key point of that is, a lot of these capabilities are cross-project. I think more and more we're seeing inside the community that the capabilities that users and operators want do indeed cross projects. That's a complicated management and coordination process inside of OpenStack. It's tough inside of most companies I think actually, that are building up complex software solutions like in OpenStack.

Certainly inside of our community it's a challenge and I think that that's an area that the product work group is really looking to provide support to the PTLs and the development teams, so that we can go ahead and have a better visibility on the cross project activities and where we stand with them, and how we keep them aligned so that the resources invested in each of the projects result in a meaningful increment in the capabilities and functionality around OpenStack. We put together three different views of the roadmap and this would be one of the things that would be really interesting to get more feedback on from folks who are either watching or listening to the podcast. The first view is really high level. We call it the 30,000 foot view and it really talks about the themes that are the focus areas for the different projects inside of OpenStack. As we looked at what was planned, this started before Kilo was out, so Kilo, Liberty, and then the end release.

Really we saw a strong grouping around scalability, resiliency, manageability, modularity, and then new functions coming into the projects. We would be able to go ahead and look at this, and I'm going to put it in presentation mode, and by looking at it we could see certain trends emerge around different releases. We could see a strong focus in scalability across Nova, Neutron, Glance, Keystone, some of our more mature projects inside of the community. We could go ahead and see for other projects that there was a strong focus on new functionality inside of the Kilo release as well. It allows us to see at a pretty high level the trends of the different projects.

Niki Acosta:               How are you finding those trends? Is it through co-contributions or is it through just anecdotal collection of data?

Carol Barrett:            We sort of do a combination. We would go ahead and look at all the available data that we could find from all the different projects in there. Blueprint repositories and in-spec repositories, and then from listening in on different IRC meetings that would go on. Then we actually did a divide and conquer within the product work group to actually meet and have a conversation in whatever form, with all of the PTLs. To go ahead and confirm what we had heard, see if there was anything that we had missed, and get their thoughts also on Liberty and at that point in time because it's hard to find a lot of information in the repositories that go that far out today. We did it in multiple ways and we got just really outstanding support from all of the PTLs in talking with us and sharing their thoughts and visions, and where they thought their teams wanted to go. Even equally important I think, is how can the product work group help them? Right? What can we do to make their jobs easier, make the work for their teams more clear, and easier for them to go ahead and move forward and coordinate with the other projects?

Jeff Dickey:                It seems like this is almost a grading system for it. Has there been any push back?

Carol Barrett:            Yeah, surprisingly there hasn't been any. We all were very tentative quite honestly, when we started on the work of this work group, sort of trying to bring some type of input into the planning process that would be more structured and coordinated. We were concerned that that would be perceived as trying to be overly influential or try and dictate directions. What we've heard from all of the PTLs, I think I can safely say, is that they welcomed the input. Being able to get more input from end users and marketplaces in a consistent form, and from one central location actually will make it a lot easier for them to understand it, internalize it, and then map it to what they're doing or what they may consider doing as they go through the design summits. That was really heartening and really encouraging for everybody in the work group, and really put a lot of energy behind the activities that the team was doing.

Jeff Dickey:                Yeah, and under manageability, is that the upgradeability piece?

Carol Barrett:            Yes. I put upgrades in there as well as other types of basic capabilities interacting with the modules as well. Modularity generally is an internally focused theme, that is what we see. In the case of Neutron, it's the modularization of Neutron, we see there'd be a similar type of thing you'd see around Nova, breaking it out into different pieces so that it becomes more manageable from a project point of view and from a reviewer point of view as well.

Jeff Dickey:                Yeah, it looks fantastic.

Carol Barrett:            [Crosstalk 00:15:23] interesting to see it all come together. Then we actually took it down another layer and where on the 30,000 foot view you can see all the projects on one slide, here we actually broke it into three different slides covering five projects per. What you start to look at here is more, instead of a trend you start to look at it more from a release by release point of view. What is Kilo shaping up for across these five projects? What is Liberty shaping up for and what is the M release shaping up for? Here we start to get a different view and a different type of takeaway from looking at this information on a slide. We found that some people thought that this would help them to figure out how they would stage their deployment or how they would go ahead and stage their application onboarding onto their OpenStack deployment by being able to look at it from this view. Then we provided one more view, which was what we called the 30 foot view which is a project by project basis providing more detail of what specifically would be implemented in that project.

I think from a developer point of view that this was one of the ones that was most important because it helped them to see the collaboration points they had across projects, and where they could get involved based upon their areas of expertise. I think maybe the other slide, just to talk a little bit about it is, as being the point of aggregation for requirements, or input, or use cases. This is a slide that actually was first drafted by Tim Bell, who leads the user committee. What we're really trying to show is how all of the different elements of the community can come together, both from teams that are looking around specific marketplaces like Telco and Enterprise, or whether it's working groups inside the community who are looking to build with certain capabilities like standard longing or ops tools or monitoring. How these different funnels of work can come together and allow us to be able to look across then these different requirements and be able to feed that as sort of a one voice if you will, or one set of information that's unified into the development organization. This is the larger view from a community point of view and how we could all work together.

Niki Acosta:               It sounds like you guys are just creating a really good feedback loop. Is that accurate and even diving into specific use cases and maybe verticals, to streamline development so that it's a little more focused. That's great for everyone I think.

Carol Barrett:            Yeah, I think being able to have information from the folks who are actually trying to use OpenStack and then about what they need. What are they trying to do with that full contextual information, I think that just makes it a lot easier for the developers to be able to really understand what does that mean in OpenStack? What do I really need to put in place because they have that full rich description and ideally, could even go back to that where was the source of the use case for more discussion, and maybe even being able to bounce ideas off of them. If we implemented it this way, is that going to meet your needs?

Maybe they're some of the things that didn't come in in the use case that are other requirements that wouldn't get met from that approach. Being able to bring that information in, I think allows the developers to make better decisions and to have a better design. I think all of that just leads to faster innovation, more capabilities coming out to the market that are more usable just right out of the gate by the developers. I think it's going to be a collaboration of taking that input and figuring out how do we capture it in a way that it's actionable by the developers? How do we provide more input to that process so that they can have a sense of relative priorities ideally around these capabilities.

Niki Acosta:               I really think this is the right approach and I say that because you have feedback from developers, you have feedback from users, you have feedback from operators, and you're getting end user feedback ultimately back through the loop because I think, every company out there who's running or offering OpenStack as a vendor definitely feels the demand coming from their customers in terms of what they need or what they want to see, depending on their use case. This seems like a really good way to organize all of that and provide direction. I commend you and all the great folks working on the product working group. It's really cool that Intel lets you have the freedom to go and do this, to better OpenStack. I think that's really awesome.

Carol Barrett:            Thanks. There's a lot of great people who are really backing and causing the product work group to move forward. I think that notable mentions on that are really around Sean Roberts, and Rob Hirschfield, and Alison from HP who started the original conversation about the hidden influencers. The product managers inside of most of the companies that contribute to OpenStack who are defining priorities and have strategies and roadmaps for their teams. The conversation of how do we get those to be more visible and how do we drive some type of alignment around those so that the community can actually work more collaboratively and more in the open?

A large part of the folks who are participating inside of the product work group are those type of folks like me, who go ahead and define road maps for Intel developers who are contributing to OpenStack around priorities. Our priorities for Intel as well as the other product managers, come from the customers we're looking to serve. By going ahead and all of us talking about that in the open, I think that the real advantages to the project technical leads, which is being able to align development resources to a capability for a release, so that there's more confidence that the implementation's going to happen in the time frame that the PTL is expecting it to happen, because the resources are really committed to it.

Niki Acosta:               If someone out there is listening and they want to get involved in the product work group or follow along what's happening, what is the best way for them to do that?

Carol Barrett:            Go up to OpenStack.org and go ahead and search for product work group and you'll find our Wiki page. You can go ahead and sign up to our mail list from there as well where we go ahead and post all about the meetings as well as some of our different work items through the mail group. We meet every other week, it's on Wednesdays at 4:00 Pacific and it's IRC pound OpenStack meeting. Come on in and join us there. You can also go ahead and find the link to all the previous meeting logs and information as well off the Wiki site.

Niki Acosta:               You all met in Vancouver as well, correct? Were any of those sessions recorded?

Carol Barrett:            Yeah, I think two of them were. There was one that was a glimpse of the OpenStack road map and then the other one was the state of product management. I think both of those were recorded and should be available off of OpenStack.org.

Niki Acosta:               Then there are off cycle meetings maybe? I heard of a meeting that took place in California, some kind of product summit if you will.

Carol Barrett:            Yeah, we did have basically a mid cycle meet up during the Kilo development cycle. That was hosted at VMware site. We're talking about and trying to figure out when we want to do a mid cycle during the Liberty development. Because we've continued to learn more and more, we're now thinking that we want to try and co-locate our mid cycle meet up potentially with the ops mid cycle meet up, so that we can continue the cycle with the feedback and use case development, and aligning on priorities. Potentially be able to go ahead and align it with some of the other working groups, whether it's the Enterprise work group or the Telco work group's going to have a mid cycle meet up. See if there's an opportunity to try and align with some of those folks who really are collaborators in the community for bringing about use cases and creating a road map for OpenStack.

Niki Acosta:               Aside from having an excuse to going to California, I'm tempted to show up. It sounds like a really cool thing, especially if you can co-locate with operators and with the product managers and other folks doing the work. It's interesting to note too, because I had a panel with some of the folks on the product working group, [Shamel 00:25:01], and Jim [Hasselmeier 00:25:01], and some folks from EMC, and Andre from Blue Box. It's amazing to see the different perspectives that come through and hear about the different use cases, and also hear about customer requirements. It varies so widely and to be able to have the ability to focus on something that will have the most impact, I think is only going to accelerate OpenStack as a whole, which is good for everybody.

Carol Barrett:            Yeah, I agree with you. I think by accelerating the capabilities inside of OpenStack it allows us to accelerate the deployments, which accelerates the ecosystem, and all of that really just becomes a reinforcing cycle for innovation across all of the products and all of the markets for everybody inside of the community.

Niki Acosta:               That was the product working group. Did you want to talk a little bit about the Enterprise working group and the work that's happening there?

Carol Barrett:            Yeah, I'd like to. The Enterprise work group was formed I guess, coming up on about 2 years ago now. It was really focused on identifying and removing the barriers for Enterprise IT managers to deploy OpenStack today. Not what they would need in 6 months or 12 months, but why couldn't they drive it and deploy it today? A large group of folks from across the community came together and focused on this area. We went ahead and broke into a series of sub teams where we focused on where we could just segment and start to get bite-sized pieces that we could understand, put action plans around, and then go ahead and execute to. It's really been great to see everybody come together and really make progress. At this point in time I think we've got 4 teams that are formed, and it's sort of morphed. After each summit we would look at, "Okay, we made this progress, we have more Enterprises deploying. What are the barriers today to the folks who are not deploying?" Then we would align the work group to those different types of challenges.

Today we focus around deployment, so what are the challenges to onboarding traditional Enterprise work loads into the Cloud, into OpenStack specifically? We have a business and marketing team that's been doing a lot of work around the perceptual barriers or the awareness barriers to Enterprise IT deployment. Then we've just combined a couple of teams to create a top 5 ISV team. What we hear from Enterprise is, "I have a series of current applications that I use to manage or interact with my current IT installation in the Enterprise. I want to be able to continue to use those as I stand up an OpenStack cloud next to that, but there's some issue somewhere with it." Maybe they just don't know how to do it, maybe there's actually some gaps in the inter-operability with those applications.

This last team has identified what are the top 5 apps in about 6 different categories, and then are starting to work through the engagement with those ISVs so that they can have inter-operable solutions within OpenStack Cloud, and we can have all the information and documentation for Enterprise IT so that they could stand it up and [inaudible 00:28:30]. Really just trying to knock those barriers down. I think that the Enterprise work group is going to start to dovetail and flow more information into the product work group as we define use cases around each of these different ... Whether it's the inter-operability of an ISV, or whether from a deployment team point of view, it's rolling upgrades with zero down time, then feed those into the product work group so we can identify those commonality of requirements across other segments like HPC, or Cloud service providers so that as the development community implements these capabilities, that we do it in a way that it serves all of the markets. We can get a capability that allows us to advance the OpenStack deployment much more broadly than just Enterprise.

Niki Acosta:               One thing that I've been battling, and I've certainly felt this at the OpenStack Summit a little bit because one of my panelists was from Sprint. We couldn't talk about what they were doing other than Rob Lindross from Sprint was on my panel. Why is the Enterprise so reluctant to talk about what they're doing? I know for a fact that there are many Enterprises that are using OpenStack but we're not hearing about them. Why do you think that is?

Carol Barrett:            I think there's a couple of reasons, but one of the ones that I hear most frequently is they really are very protective of the resources that they have assembled that are experts in both OpenStack and their infrastructure and their architecture. If they're too loud and public about what they're doing, people will come and poach their resources because there's a need in the marketplace for people who are OpenStack experts. That's actually one of the top reasons I hear that Enterprises are not willing to be so public about things.

Niki Acosta:               I have not heard that, but that makes complete logical sense. Hey, if you want a job just put OpenStack on your LinkedIn right? You will get offers.

Carol Barrett:            I don't know if there was any booth at the OpenStack Summit in the marketplace that did not have a we're hiring sign up, right? Everybody was.

Niki Acosta:               Yeah, the recruiters were definitely there in full force, no doubt.

Carol Barrett:            Yeah.

Niki Acosta:               Interesting. You said there were two reasons? Did you say there were two reasons?

Carol Barrett:            Yeah, well I think there's multiple. I think that that's a large one, I think the other one is that competitive advantage or business advantage. I think the way that the companies are deploying it, are providing them some advantages that they don't necessarily want to signal out to the market yet. Right? It allows them to either deploy things more quickly or to manage more effectively, which is going to allow them to deliver new value out to their customers, and they're just not really ready to give their competitors more information about how they're doing it so that they can copy them as well. I think competitive advantage is another big reason that we hear it as well.

Jeff Dickey:                We have a hard time getting end users on the show, and most end users want to and they do really want to talk about what they're doing, but it's kind of a PR issue. They say, "Yes, I want to do it, let me check," and then it's