 Okay, so today's session has got a very long title. Open networking in action. SDN, NFV and OpenStack and Cloud, all those things. Wow, okay. Bingo. And we have a very illustrious line up of panellists. None of whom I'm sure need introducing, but I'm going to ask them to introduce themselves nevertheless and to say perhaps a bit about their organisation ond arnyntio gydag ymlaen â'r concept ddechrau'r newid yma. Rwy'n ddweud yw Heather? Nid oedd yn ddweud i'r cychwyn. Dwy'n ddweud i'r cychwyn. Rwy'n ddod o o'r cofnifau. Rwy'n ddweud o'r cofnifau, ymlaen o'r cofnifau i'r peir o'r cyfnodau o'r cyfnodau syniadol. O'r cyfnodau syniadol, bit's coming from some of these gentlemen's organisations, and then we do a lot of testing and then feed features and requirements back upstream to support NFE use cases. I'm Jonathan Brice. I'm the executive director at the OpenStack Foundation, and my background is really strictly in cloud. I started the company that became the Rackspace Cloud and then helped to open source some of that technology to get OpenStack started. a bobl ydych chi'n fyddech chi'n ddim o'i gweithio gweld yn siarad cychwynol yn y cyd-dweud. Mae'n ddweud i'n gweithio tîm hun i'r ffordd o'r ffordd o'r ddechrau cychwynol ac ymlaen i'r rhai gwaith ffasilio'r wahanol yn y tela incerfynol, a i fynd i ddweud i chi'n gweithio ddweud i'r awes ar gyfer y gwir yma, yma sy'n golygu'r ddweud i'n gweithio i fynd i'r gweithio i'r olyf yn ei amgylchol. I guess I'm next. My name is Neela Jacques. I'm the executive director of the Open Daylight Project. If you look back about four years ago, two things sort of seemed true at once. On one hand, I think the entire industry said we need a new way of controlling our networks. On the other hand, everybody had their favorite way. So we had a world in which you had not one SDN solution but 30 of them. And as you can imagine, that doesn't work very well. So I think a number of the industry luminaries said this thought that says, hey, what if we brought all of these folks together? And we could collaborate around a common platform and then everybody can go off and actually build their solutions around that. And the good news is we've gone from a world which was like this down to now just a few solutions out there with Open Daylight being by far the largest open solution out there. The good and bad news about this has been that as we've shown that this model can work, we've actually found an expansion up and down the stack. And so more and more people are creating open source communities and open source projects. And that's certainly great. It means it puts a lot more pressure on all of us here as well as people who aren't here to find ways of increasing collaboration to overcome overlap and other things like that. That's what I'm really trying to focus on more of my time now. And I'm Brian Sullivan. I work for AT&T in the Domain to Architecture and Planning Organization. We're the organization that architects the AT&T integrated cloud and the overall network function virtualization in which we're redeploying all our existing network services over time. And I guess what Open Networking has meant to us and our role in Open Networking has largely revolved around realizing that in order to achieve the agility and time to market and speed and all those things that we needed to evolve beyond what we call Domain 1, the previous thing, right? We had to go open. We had to go open source. And we had to do things in completely new ways. For example, Network on Demand was one of the first things that we did launch in a cloud environment. And that caused us to adopt a lot of new methods and leverage a lot of new tools that disrupted a lot of what we did in the past. But it was a foundational step in the right direction. And now we're expanding that, as Neil said, up the stack in a lot of different ways into the orchestration space as well. Thank you everyone. So I'd like to start. I mean, as we've got up there, we've got SDN, NFV, Open Stack and cloud, all very, very big topics. And I think that for a pretty conservative industry, perhaps for any industry, but telcos have got the reputation of being particularly conservative. Having all these things thrown at them at once is a pretty tall order. AT&T has been, well at least from the outside, it looks like the swan gliding serenely on the domain 2.0 waters. But we'll come to that in a minute. But a number of operators have said to me, you know, these are just so hard. And there are so many moving parts and they're all evolving so quickly. We don't know which ones to choose, the standards aren't there. We're used to standards, you know, and people sort of pontificating over those for two or three years or four years or even five years. This stuff is just too hard. We're not going to be able to embrace it. What's your opinion of that, Brian? Should they just give up and go home or is this something that's really here to stay and they've got to make this leap across a very large chasm? Well, we've been, you know, a tier one operator forever as long as I can remember, right? And so our role in this is different from a lot of other operators, right? I mean, as a member, for example, of the GSM Association, which has hundreds of operator members, right? The things that we do versus the things that other operators can do are quite different somehow, right? But the fact is there's strength in numbers. Even for the tier two and tier three operators or service providers, you have to realize that you have to be engaged because you can only make good choices if you understand. And there's only one way to be truly, you know, have an understanding is to be engaged, right? And then you can, through collaborative integration projects like the open platform NFV, right? You can learn as an end user the things that you need to build a core technical team to make those good choices. Sure. You know, it's a little bit like asking, does an aircraft carrier have to be complicated? And to some extent, yes. Frankly, being able to land aircraft on a moving ship in the middle of the ocean is really difficult and requires tremendous amount of training and specialization among people. And I think there's some element of which to run a tier one telco is really, really hard. And we've got that down to a science now from the last 30 years. Now what we recognize is that the kinds of capabilities that we have today aren't going to be enough for the future. And as we move to the next chapter, we need to reinvent it, but we can't lose a lot of the things that we've achieved over time. So, on one hand, there is tremendous complexity already in the existing system. There is certainly complexity in being able to reinvent many of the different pieces that all must come together. I also think, however, it behooves us to also simplify that inherently in innovation, innovation becomes messy, but you do need to be able to take all that innovation and actually run something that allows all of us to make calls, that allows all of us to have video. And so I think that there's going to be a great learning that's going to continue to happen between the open source communities that are innovating faster than we've ever seen before and the operators that really need to deliver a service and make money on it today, not in 20 years. How many of you have heard of Corba? How many of you still depend on Corba for business critical functions in your company? One. I thought of that because you mentioned about standards and waiting around for standards, and we actually used to do that in a lot more areas of the technology world. But I think what every business is facing now is just this imperative to move more quickly. And even though something like Corba, which was meant to be a standard for communicating between systems for sharing data and application interaction, even that is not completely disappeared, but mostly that we actually have more interconnected systems than we've ever had before, even though we don't have strictly defined standards like that. And I think that the telecom market, what's driving people to do these things, even though it is complicated and painful, is because they're facing that same business imperative to move more quickly and to compete in ways that they didn't necessarily have to 15 or 20 years ago. So it is a little bit messier in terms of, like Mark Collier said yesterday, how the chorizo is made. But the end result is as you go through the transformation to be able to work in that environment, it actually does greatly increase your ability to move more quickly and to adapt and to roll out features. And I think we're kind of in this transitional phase, which is very hard, and which is going to require change from both operators but also from organisations like OpenStack and Open Daylight and just Open Source in general to figure out where the common ground is to make that happen. I think the business imperative is there, so it's hard, but if you take your toys and go home, if you're in business, you're not going to be in a very good business for very long. But I also kind of think about it a little bit differently, which is it's hard, but it's the first time in a long time that the telecom industry has been really interesting and fun too. You can look at change as hard or you can look at it as inspiring. There's so much more innovation that we're seeing right now than we've seen in this space in a long time. And I think the enablement of that innovation and seeing excitement there, we had at our Opina Fibus yesterday, we had people coming up saying that they wanted to be our interns. When I'm thinking college kids, college kids are not dreaming of going to work in the telecom space for the past 20-some odd years. I do the interns who are coming to approach us at our boosting. What you're doing is really interesting and you are the person I would like to intern with. To me is just fresh and new and very exciting, so that's kind of the way I think about it. That's great. And keeping with the business drivers there in the future, there's a lot of hype around at the moment about say 5G, for example, internet things. Are these things in your opinion, Brian, that can be done without virtualisation? Or is virtualisation a precondition for moving to that future vision? Things evolve and we're in the first generation of virtualising what we have. We're learning that it's hard. There's a lot of embedded business around how things have been done for the past 20 years, and that's not going to change overnight. But I've got to get this right because it was extremely important to what Chris Rice said at Open Daylight Summit. I'm going to associate it to an analogy that you know, pets and cattle. We have to move from pets and what Chris called snowflakes. Very special, very focused, one of a kind things that we're living with today to a cattle environment, basically, or legos, where there's nothing special. You can get rid of them. We have to get there because in the long run, the economics of doing all this are not going to work unless we can really break things down and evolve. I think it's an essential thing, whether it's VMs, containers, micro kernels or whatever. That's just technology, but clearly we have to get things more broken down and much faster and agile. I think those are key things that we're going to have to get to. Anybody else want to comment on that? Sure. An example I often use is the last big, great example of the old style service and that unique snowflake thing was IPTV. That was, I want to say, a six-year standards process. We designed this beautiful, perfect network that really was going to enable IPTV. It was great and they had to roll out a new network. People were digging up streets to lay down new things and new equipment. By the time, you first got rolled out, how was everybody getting most of their content streaming? Unicast streaming via Netflix. This beautiful IP-based broadcast television system that we had designed and implemented and rolled out. Fortunately, it's a good internet system that we can roll out services over, but it didn't work. To the point of, we can't regard our services in that way. They can't require these special networks, every single service that we roll. We need a dynamic network. An artist in service. Exactly. The hipsters in Brooklyn will really like it. It de-risks the service availability. Part of the reason service providers move to slowly with services is if you've got to dig up streets and roll a new network for them, you have to have a pretty good ironclad ROI. Whereas if you can just start rolling out new software on a cloud infrastructure, you can start playing. You can de-risk your portfolio and your services economics. Just to add to that, I think that we've shifted in terms of the determinant of winners and losers in our society. It used to be that the guy who figured out first that the automobile was going to be a big thing, ended up being more successful than everyone else. We've moved into a model where now people know what's coming. Microsoft knew that the smartphone was coming. They just weren't able to capitalize on it. The AT&T knew that people were going to stream movies. It turns out that Netflix was able to execute. If it's not knowing what is coming, what is it that determines success, it becomes execution. From an execution standpoint, infrastructure inherently underlays your ability to execute well. If we look at why so many people here at the OpenStack Summit is a cloud, whether it's an internal cloud, a private cloud, a public cloud, infrastructure is inherently needed so that someone who sees, hey, I think the world is going in this direction can very quickly try things out, fail quickly and move beyond it. That's certainly true on the network side and I think on the telcos. They're very fortunate, I think, to have the ability to have a deep connection with all of us and with all of their customers. They have an ability to roll out and win all of these new markets. The question is, do they have the execution ability? A lot of that comes down to the agility of their underlying infrastructure and to answer your question, yes, I think virtualisation is critical. I think it's necessary but not sufficient. So let's move on and then talk about how this transition can happen and why it should really be open source led as it is at the moment. Jonathan, do you have some opinions as to why Telcos should be involved in open source or looking to open source? Earlier, I kind of talked down about standards a little bit, I guess. It's not because I'm against just standards per se or the concept of people coming together to define what things look like. I'm actually completely pro that and we're throwing a giant event here in Barcelona that's oriented 100% around that concept. I think that open source is actually the evolution of how we work together. It's not through standards bodies that then deliver a spec that goes and gets implemented independently by different people. I think that process is kind of all collapsed into something where the definition of what we need to have and what it looks like, how it gets built is kind of all done together collaboratively in the open. To me, that's actually proving out to be the best model for technology development. Now it's different, it's very different and I hear it all the time not just from telecom operators but from other users who are very attracted to certain components of that but they are confused or put off by other pieces of it. I think that if you look at the time to execution, as Nilo was saying, which was a really good point you were making, by focusing on open source and implementation from the beginning, you actually can fail faster and adjust and get to the working iteration more quickly than if you just go through the process of years or decades of product rollout. To me, open source is a really critical component for anything that is meant to be a massively deployed, a diversely deployed technology solution now. Okay, but have they shouldn't telcos lead this to their vendors? After all, that's what they've done for many years. You're setting me up for one of my favorite quotations from Machiavelli the Prince, which is, a prince who depends on a contract army can never be secure. It's one of my favorite lines. I think that really the dynamics of the telecom industry had gotten that way, that the operators were dependent on their vendors for their R&D, which created a very weird dynamic because in a certain way we're not sure if we trust you doing our R&D, so we're going to yell at you a lot, but we're still depending on you to do our R&D. I used to work for a vendor in the telecom space, but I think the operators getting their hands dirty, and by the way Brian is a shining example of this, and really being able to do some of their own development work, not that they're still not going to buy things from vendors, but they understand the sausage making better, they understand the strengths and limitations, they understand the technology being used better, and I think it actually changes the dynamic of some of the relationships in a positive way. I think it also enables the operators to choose pieces that they might want to develop on their own, you know let's say AT&T with ECOM, it allows them to make decisions about what they are going to buy versus what they're going to build versus what they might build collaboratively, and I think it makes the entire process of designing, implementing and operating their networks, I think it makes it better for them, is my view. OK, so Brian we'd like to hear from you as the operator member of the panel, not just about what is the value of contributing, it's not just consuming but it's actually contributing, but also your own views, obviously you're talking about making ECOM open source, so if you could take us through some of the thinking behind that as well, that would be very interesting. Well the value of contributing again to come back to the point is that you have to be educated, and unless you contribute, you won't be educated, you learn by doing. There are many forms of contribution as well, I mean you don't have to be necessarily a code contributor, you can be a user, you can provide feedback, you can participate in testing, you can be part of a community that supports end user communities, etc. Test labs, test labs, various test labs. Test labs, you can provide resources like many people do in opnf and the OSIC does to the community. The role though of everybody in the ecosystem is changing, and the relationship between operators and vendors is changing as well, we're becoming much more partners, collaborators, right? We don't want to necessarily make everything, and even if we do make very substantial things like ECOM, we probably want to partner with people long term in maintaining them, developing and taking them further, and there are many different solutions to these sorts of needs, the overall orchestration umbrella for example, and we don't want to necessarily maintain a point solution, it should be to come back to Chris Rice's point, it should be basically Legos that we use to solve the problem of overall orchestration, etc. In order to do that we have to collaborate, we're going to have partners, we're going to have vendor partners, etc. We're going to have community partners as well. The dynamic is changing for sure, but I think it's a positive change, and if I was in a vendor community I wouldn't really worry that much, because there are many ways to form value as a vendor, and selling a product, for example differentiating on a product is only one way. Nina, we were talking the other day and you were giving me lots of really good examples of what operators are actually doing with Open Daylight. Can you perhaps tell the audience with some of the ways that they're participating and what they're doing, operators? Absolutely, and before I go into writing to the example, I want to say one quick thing which is the big difference in your question about open source versus just going with a vendor is the developer user intimacy that we get in a community like this, you cannot get in a vendor relationship. It's a little bit like trying to collaborate with somebody by sending letters back and forth to Timbuktu. There's just an inherent latency that you get when you have to go through product managers as well as going through technical user advisory groups that exist within corporations. While here, and we've seen this very much with AT&T as an example, that's where I'm going to start with my example, we actually get people who say, hey, I have a need, can you make this better? Are you going to do this? No, I'm going to start it. For example, if we look at AT&T, AT&T is a great example of participation in Open Daylight. On one side, you've got something like ECOMP. AT&T takes Open Daylight, puts it at the heart of their next generation infrastructure delivery platform, puts it in production two years ago while the project itself is still evolving and giving us feedback the entire time. At the same time, you're actually getting little point contributions and participation, not just feedback on the overall, but a, hey, what we need is a yang model authoring tool. Wait, you don't have one? No one's creating it? You know what? I'm going to find a developer within AT&T. I'm going to write that piece of functionality. I'm going to offer it into the community and let Unilla go find other people to join me and help me to do it. And so what we've seen is engagement from AT&T like Chris Rice, who's very, very senior, down to individual developers who I may never know about but are active in the community asking questions. That's a great example of someone doing something like this. We saw the same thing Katie in Korea. One day was talking to me and said, you know, Open Daylight seems a lot weaker than that other project in transport. Why aren't you doing more in transport? You get a little bit defensive and you say, well, you know, the community invested in what it wants to. And you give sort of your stock answer as an ED. Hey, if it's really important to you, why don't you come and contribute and participate? I'll help you to do that. And they go away and you know that nine out of ten times that you never hear about it ever again. In Katie's case, they found a group of developers. They went ahead. They built out the functionality that they wanted for themselves. They deployed and they're in production now using Open Daylight to shorten the time from bid to deployment of their customers. But at the same time, they also proposed a new project in transport and it's in the latest release of Open Daylight. So what you get in Open Source is that ability to not only consume, but also give feedback and also produce. People think when you say developer user, you mean vendor customer. No, you've got developers at both. And you've got users at both, really. Well, thank you. Now, I'd like to get a little bit more specific here. I mean, a lot of people that I speak to when they're talking about Open Source, there's an excuse which may not be entirely true, but it's a little bit valid and nevertheless, which is that, well, can we really run telecoms networks on Open Source software in its current state? And of course, they always point to OpenStack as the example. And I've seen OpenStack make tremendous strides in supporting NFV since I first started looking at it, which I think was round about the Icehouse release. And of course, since then, we've had MacArthur and now Newton, which are really sort of pushing on in very many ways. Still, speaking to a big tier one European operator last week who said, well, OpenStack will never be done. And the kind of subtext was we're not sure ever when we're really going to deploy it. So, Jonathan, what still needs to be done, do you think? What boxes still need to be ticked to make operators really overcome this excuse? It's a really good question. I mean, the statement that OpenStack will never be done is true. But that's actually a good thing. Linux kernel's not done yet either, and yet somehow people managed to use it. And I think that it gets to kind of that cultural difference of we do releases and those end up in downstream products from vendors, which is a really good thing for consumption. But some of that is again that mindset change that needs to happen. At the same time, in terms of specific things, there are differences in some of these telecom workloads definitely from sort of cloud-ready workloads, which is where OpenStack started, enterprise workloads, which is kind of the next step in terms of OpenStack's development iteration and running data networks and voice networks. I think that similar to those other workloads, it's not about when OpenStack is going to be ready to be used in telcos. It's really when is a telecom going to be comfortable using OpenStack for the things that it is ready for. It's not an all or nothing thing. This is a shift like they've been talking about where all of the R&D and all of the packaging doesn't just happen with vendors anymore. What that means is that users of open source software in general, not just OpenStack, they need to be informed and educated enough to know, okay, I can run this workload on this set of tools now. What we see is a growing number of those things that different operators are running. AT&T initially started out with more of that enterprise-type workload in terms of some of their first developments that they were doing with OpenStack, and Deutsche Telecom, similar thing, but they've moved into network workloads now. DT runs a variety of different workloads through different European countries that include some voice, also some security services, things like that. I think that there's never going to be a blanket answer for everyone. You have to invest into... It doesn't have to be code contribution. There are a lot of different ways, but you do have to invest in these communities if you want to use them and get the most value out of it. The minimum level of investment is getting informed and understanding how different technologies align with your needs and your current state. Heather, you're in the forefront of testing a lot of this stuff for telcos. What do you see that could be addressed in terms of making people feel more comfortable? Part of it, as Jonathan was saying, is certainly cultural. From the perspective of... especially that never going to be done, of course not, the world is never done. The Linux kernel celebrates its 25th anniversary and it changes constantly. They release every week. The fact that things are constantly changing means that new requirements are coming in and you're adapting to evolve to them. I think that it is that transition from a, now I have a box that is good enough for me to put here to I have software that's going to continually evolve as my business evolves and as the world evolves around me. I think that is a big cultural shift. In terms of, I think, in our Colorado time frame for OPNFE, I think we really started seeing some maturity around some of the requirements for beginning to run more telcom workloads, some of the fault management capabilities that we saw in the demo yesterday, coming from groups like Open Daylight, some of the Layer 2, Layer 3 VPN capabilities and SFC functionality. This was the first release where we were able to, we had some basic IPv6 support last time but this is the first time you're beginning to see multiple projects in the stack, really properly support IPv6, which is a necessity for operators. A lot of those baseline functions, for us this time in our release, it was a lot of incremental functions necessary to run applications and we saw these definite strides in them. I mean, probably at the end of the day, Brian's a better arbiter of this, how red we are question, but I think we're certainly getting to the place where, to Brian's point, you can certainly start running certain workloads and stuff is, in the just over 18 months I've been in OPNFE, things are quite impressively radically improved in a fairly short time frame. Well, I'm going to let Brian be the arbiter. How they're doing? Well, they're doing fantastic. I think it's, you know, we went from one scenario that in the first release that I think a week after it was released, probably was hard to get running again. To several scenarios in the next release and to like 37 in the third release. This is different combinations of components, which show the flexibility and the openness of the overall project. Come on, come on, bring your resources and we'll prove that it works, sort of thing. But as far as Opistack and its readiness and reluctance, et cetera, to deploy it and all that sort of stuff, it's fundamental. We started out with enterprise workloads, et cetera, but it also runs mission critical, mission critical applications as part of our NFV program. It needs some particular focus, right? And we know it's not done yet for these things. It needs massive scale. It needs not just Opistack, but overall the NFV environment needs really, really good performance to make up for the virtualization penalty. It needs also to be able to scale down really low. For putting clouds inside central offices and it's small cell sites and things like that. Security of it needs to be much stronger because it's going to run our network and it can't be hackable at all. There's a number of things like that. But we'll get there. It's just a matter of recognizing what it needs and communicating as a group like we have this large contributing Opistack operator group that we formed with others. That's giving us another way to get the voice out there into Opistack as to what we really need coming up with it. So if I can jump in, I want to give a little bit of a provocative answer to this. I think the question in a sense is the wrong question. The assumption, if you're asking, is Opistack ready for telcos, positions Opistack as a product. You could ask the same question about Open Daylight. You could ask the same question about any open source. I would argue that when we start to think about open source platforms as products per se, we're shooting ourselves in the foot. Was Open Daylight ready for production two or three years ago? No, but yet it was at AT&T. The truth is we come together to build a platform and that platform is leveraged to build a solution. In some cases, the open source is so advanced that you don't need very much to build a solution. In other cases, you may need to build half the solution yourself. In some cases, the end user is going to pick up the open source bits and build a solution for itself. In some cases, they're going to do that but pay somebody else to do a piece of it or they're going to go to a vendor and buy a solution that's been built on that. But inherently it is the wrong question to ask and to evaluate an open source project as a fully formed solution. To go further than that, if the majority of end users looked at open source projects as full and complete solutions and therefore, hey, this is a really cheap way of solving my problem, you'd completely destroy the business case for the vast majority of the people who currently play the developers to continue to fund the development of those open source projects. Developers aren't free. Other people who work in support aren't free either. And if we lived in a world in which users would pay for 100% of all the development on the open source product, maybe we could have a world in which you basically just look at the open source project as being the primary source of where you are. In the current world where we are, we really need to remember that what we're building is common technology elements and platforms and toolkits that people then are going to leverage to build solutions for themselves. And there has to be money there to be able to fund that development. Well said, neither. OK, so I just want to finish with a question around the overlap between a lot of open source initiatives. This kind of land grab for adjacent areas, which is perfectly, that people identify things, people identify the same things at the same time, but then it's a question of how do you govern that in an essentially ungovernable process where you don't want to kill that innovation. It's particularly striking, I think, with the whole idea of the NFV mano, that very nebulous orchestration layer that sits above OpenStack, but just would like the panel's thoughts starting with Heather as to how can we control this? Because people, operators are concerned about where they should put their efforts and which one's going to win. Maybe it's a legacy of the old standards thinking, but nevertheless, how do we address this problem? So I kind of got two answers. One is which, yeah, so put your efforts in the community that you think you are going to be successful in. You don't necessarily have to play in all of them. Where do you think you will be getting value for yourself and what aligns with your strategy and business model? There are a lot of different groups out there, many of them are parts of an ever-growing stack, and some because they are taking different approaches to some similar piece of the stack like mano or SDN controller or something like that, which I think is fine because we're in early days of NFV in a lot of ways. And so the fact that people have multiple competing ideas about how certain things like, you know, the future of, you know, OSS BSS, which in some ways informs your opinion of what mano looks like. Of course there are different ideas and I think that that innovation is a good thing. So it's not so much that it needs to be controlled. It needs to be, I think, maybe understood and and calmed a little bit, which is, you know, sort of the second part of my answer is that's sort of what OPNFV really does is because we are an integration project because we're not trying to pick winners because it is voting with your feet. You know, if you care about a particular technology are you willing to put time, effort, energy into getting it integrated into a scenario and then when, you know, we run all of our tests against it are you willing to take those bug reports and feed them back in and improve the software based on what our testing has found. So part of what we are part of what we're doing is we're not picking winners but we are sort of enabling that voting with your feet, enabling the sort of seeing how well things do integrate, seeing how well things test and testing with all of them to sort of give them kind of give multiple upstream community sort of a level playing field to sort of show how their meeting needs and being reactive as a community or not and, you know, eventually some things will die and that's fine too. Yeah. So I think that I just want to echo what you said about you didn't say pick the tool or the technology you said pick the community that you think, you know, and did do it on purpose. You know, when OpenStack started there were other OpenSource Cloud platforms that had a technical head start in different areas but none of them had a focus on growing a healthy community and at this point OpenStack has eclipsed them and I think that with OpenSource the community is the driver for access or failure of the OpenSource project over the long term. It might be able to last for a year or two or three in a model that's driven by a single vendor or by a closed team but the only way that an OpenSource project survives and thrives for 25 years like Linux is by being very community driven. To me that's the thing to look for above all else if you're looking across, you know, different OpenSource solutions. The other point that I would say is don't fear the kind of variety in some of these areas because this is so early on and as you go higher up stacks too you're going to have more variation because there are more differences between development languages than there are between operating systems. There are more differences between different kinds of workloads that are going to run on top of those and so I think it's actually fine to have variation and variety over time the market will sort of give people their niche or they will die and go away and it will get settled but what it shows is just how new it is and how much experimentation there is left to do. I was going to say the enemy of successful OpenSource is the desire for control. We see this everywhere when an individual comes in with a great idea that creates the spark that lights the innovation but that innovation will die if they're not able to get other people to work with, to contribute to leverage that code. That is certainly true within an OpenSource project and that's true between OpenSource project and I think you know this is a tough challenge that we all have up here is how do you on one hand allow people to come in and they have something that they want to do and they've got to feel safe that they can come in and this is a good garden for their plant to grow. On the other hand if what you simply do is allow every single person to go in and collaborate with themselves and then collaborate via stapler with a release you're going to fail and we see this every time when people do end up in their own island a lot of my time explaining to people hey I'm not seeing a whole set of people coming to you don't think that just because you made a release vehicle that you've achieved your goals. You achieve your goals when other people join and contribute. You meet your goals when other people take your code and integrate in what they have. You meet your goals when a vendor puts it in their product or an end user actually deploys it to solve a problem and that's actually a lot harder and it requires people who are willing to let go of some control it requires the facilitation of community and I think we spent a lot of time trying to do that. It's hard enough within a project it's even harder between projects and we see situations in which of course each of us is really excited about our own community and our own way of things and we can all, we're all human too we can all fall into that trap and so continuing to invest in saying where does it make sense where should we collaborate if we don't do that we will fail and people will go back to the ultimate non-collaborative model which is proprietary software. So Brian you're the one who's having to place bets what do you think? Well I think it's a natural thing as Heather said this is a nascent change in the market and it's really not a problem that you have multiple you know because of ambition or whatever you want to call it right because it's natural I mean we have a globe right because of culture, because of geography because of ambition because of people following their own goals right and developing things internally and seeing it grow up and saying I want to put this out there we have these multiple projects in the same space coming up and as long as there's enough bandwidth inside the overall market to support them it's really not a problem especially as we had this right after ONS last time we had this meetup of the sort of mano thing but it was about cross SDO information modeling and then there was orchestration right and we got together after ONS across all these projects we said look we've got to reuse as much as possible out of the stuff the fundamental components of what we're doing here so that we don't have to reinvent ten times right as long as these communities get together and they do try to to find out the opportunities for convergence and collaboration we're going to win right and so when we go open with the ECOMP I'm sure the same thing is going to happen at some point it's going to be a give and take and we're going to have things coming in and going out and it's just a natural thing that the market has to work through and in the end if there's four or five different solutions large solutions to the same problem if that serves the market then it's okay I'd just like to say thank you very much to all my panellists Heather, Jonathan, Neda and Brian, thank you Thank you Caroline