 All right, thank you everybody and welcome to the service provider panel. We've put together today called the good to bad and the ugly of open source We've got a couple of our esteemed guests here tonight to talk about this about this really interesting area from various telco service providers So if you all could introduce yourself tell everybody a little bit about yourself and and Kind of what your Involvement at open source open source networking, etc. Might be Catherine. You want to start? Yes, thank you Tom. So I'm Catherine Lefebvre. I'm working for AT&T In particular in the space of a network system common framework and services and in addition to that I'm representing the own app community service as their chair So maybe Lucas you want to continue? I'm Luca Martini. I work for a traffic communication mostly focusing on network automation and automation systems and also network automated management systems and I rely heavily on open source to build those systems and Go ahead Thanks to go I'm Mohammed Zabetian Like look, I work for charter communication my responsibilities around the network function visualization and infrastructure and edge cloth I'm part of the city office and be driving the next session technology for charter Fantastic So I let me ask you you guys a question and then you know Feel free whoever wants to take it first and we'll kind of go around the go around the wheel And get everybody's kind of take on this, but I wanted to start things off with maybe a little bit of a controversial question potentially Have we gone too far? In in developing Our own distributions and products and and that's to say to put a finer point on that is Should we be buying distros of various open source projects from vendors or should we be rolling them on on our own? So what do you what do you all think about that? So maybe maybe I can make a start so so I think we need to dissociate the type of open source that we're Referring to I think first of all you have open source like open daylight doppers and cubanities Where we really take as a carrier's the commercial version of it We rely on it and that's what we need and then in addition to that we have open source like owner Whereas a carrier we would like that we contribute to a common platform That we define together that will Somehow meet different priorities And feature needed for all the carriers reported by authority part 30 party vendors and integrator And later on we can build with our third-party vendors services Adding our secret source to make the key differentiator between carriers and third-party vendors So that that's my feedback to you, but maybe Mohammed or Lucas you have different opinion Well Open source is sure they do Yes, just sort of an extent open sources is open source, but it's not free So there is a cost of maintenance and integration whether we do that in-house or We buy it from somebody That is still working needs to be done. And so I think Personally, I will look at all options and basically make a business decision on based on the complexity of Supporting a specific a piece of open source into my final system or buying the support form Somebody who distributed like red hat and so forth, right? So I make a business decision on what the cost is and it all depends So if a vendor comes along and wants to some the open source and it's incredibly expensive that this it doesn't fly, right? But for certain, you know more reasonable These when you get a reasonable support That then it's definitely I will buy the support from somebody Yeah I think the lookup experience favor like a dream the point the major difference in my money is First thing are we gonna console open source or we're gonna buy a you know And then you but constant open source You might be able to buy support from third party or you completely buy it this row from the third party I think they distinguish between all three of them, you know In my mind, it should be a balance based on the risk and the value of that open source And the change returns of ease of the integration or we know make it deploy globally That that's gonna drive a decision. Sometimes you just want to open source You don't want to mend that is true But you want to support for that the pen source and I think a lot of times we end up to do that and the catnip Which is a very important way my own app Conversation we we won't be able to influence. We won't be able to drive it and then add our indication point or So to elaborate if we needed and there are other example of that It's not just one of the other example in the different part of the industry we do that So just to take off on on what you were just saying so so the key is finding a partner To to either support and deliver that you can trust and rely on or you have to You're gonna have to do this yourself and there's I guess Luca made this point, right? There's no free lunch you somebody has to do this right and Really one of the things Really this boils down to two is another interesting thing around what's happened in in open source now working in other places, too but Really what we're talking about is the disaggregation of software, right? then you're no longer buying everything in a tin can from one vendor, right and The point I've been making talking to customers for a couple years now is there's no exactly what Luca just said There's no free lunch. Somebody has to reconstitute The the thing after it's been been ripped up into different parts and that integration You know, I've I've built some pretty complicated products with Luca before for example That is a huge amount of of resource effort to make that work, right and getting these components to work together is complicated So like Catherine, I think you you had a Finer point on that like you were talking about own app versus other projects What do you would you have examples of you know one or the other or or the many different? Examples where you think like you would you you as an operator would try to pull this off on your own versus what you'd like to buy Yes, and that's that's mainly what we did so as you know AT&T was really The fundator with China mobile of own app so we we had a chance to have our own That's not the case of all the carriers and we hope we Contribute our code or internal code and then we start to build on top of that So that was really a great experience because we were not only You know typically we just contribute to an open source community But here we were also sharing what we were doing and progressing with key partners as well as our other order carriers, and it was a great experience because we Finally build this common platform and they are still a key role for computers and third-party vendors if you look at the ecosystem of one app It has been really booming over the last two years And it's to support indeed the carriers who have not the chance to have an A&E They're probably test her and excellent people working and knowing their network But they still need to integrate all this component together with their OSS VSS System as well. So that there's a back-end integration to yeah, that that has to happen anyway Yes You need to do this productization. We try to do with the community some You know looking after the non-functional requirement Which is key for the carriers as well as the security But these are some gaps that an integrator can fill up completely when they do Productization and the other example you were mentioning is open daylight in the context of AT&T But we were relying on an integrator to do this commercialization to do this integration for us Inside of product as well. So that's that's really key To have an integrator partners with part of the adventure So they understand our needs and then later on we can rely on them and get support in production Because the end goal is really production readiness Called it Malwa look at do you have a take on that? Like do you have do you have specific projects that you know upstream projects that? Kind of to compare and contrast against own out for example that you would feel comfortable deploying Versus ones that she wouldn't and maybe why So maybe I could say, you know Staxform has a fairly good support behind it and a fairly lively community Which is you know something I consider a fairly well alive project open daylight on the other hand I'm not sure who's left to support it because all the company did that When bankrupt so of course you still have a protection because it is open source You can still keep going a little bit, but without a commercial entity behind it I'm not clear what the life of that project is going to be a long term So that's one. I would you know keep a very close eye on Now do you have a no I think the boy Look I'll cover this subject payroll at the end of the The problem it tries to solve within the search for the environment normally very complex own app or other tools they actually Influenced the challenge and the and in place we need to go to actually indicate different open source to give the solution of it I mean if you look at the own app, it's not just one big monster. It's a lot of pieces together to get to that point Yeah, and starting and at first of all understanding The landscape of that monster is is is the you know is a challenge in itself I mean which we pick on own app. Have you looked at Kubernetes lately? I mean, you know, there's a map. There's a there's a group of people that maintain the map because there's so many pieces parts to that project But but Luca you touched on a really important part, right? Which is the the commercial life cycle of the different projects, right? And you know like I that's one thing that I've been curious about like you you all as operators How do you sort of insulate yourself against that? I mean companies? You know, I mean here's a here's a practical difference between a startup that's producing a distro And it might meet your criteria is that you all talked about the beginning might be price, right? Supported well, etc. What if they just run out of steam? You know and and all that I mean how how do you you know? I'm sure AT&T is a different way to do this thing than charter to handle this So I'd like to you know kind of explore that a little bit How do you kind of insulate yourself around against that happening? It definitely happens, right? Like against, you know, the demise of projects versus, you know, you left, you know You're in production in a product in a upstream project just goes poof, you know, and so first of all Some time for the project to completely die In general what you end up is they there's some kind of commercial entity Behind it that eventually fades and disappears and then the project is open source of the community Keeps going for a while. What I've seen in a couple of Projects we've had some components of our Automation system that they have died over the past few years and it takes At least a year after the commercial entity has gone for it to completely die So you have some time to move off to somewhere else again, there's no free lunch So you have to invest into maintaining this This components and so if a component dies You have some time but you have to make a plan to move off of it and move somewhere else in our case One of the databases that we were using Was a spin off of a different one and it died and so we took a while and then we moved on to to Different one and now we're off of it completely. So You know, again, I think the difference between the open source and the startup is in the startup You have, you know, maybe more focus than more Quicker support, but there's a much higher risk because if it goes bankrupt Then you know, yeah, you put the code in a scroll that's what service providers do and and they receive the code but Who maintains it? on project right and and even if you hire some of the people that work on the project you fill in the code of a dead project and so Again, I think that's a little higher risk in fact than open source because it can You have to move off of it and you have to replace it Then I believe you would do if it was open source Cool Catherine. Do you have a No, I think I'm aligned with what lucas said Um in the sense that with open source because you start also to bank under code Into a third party integrators or vendors somehow you you create your safety net Because at one point your third party vendors Can take it over because all the source code was available and can build what you need So you can move from off the shelf Product to again customization if an open source is no more Supporting you in that case We start up again We we have seen in our process with escrow and and noticed So we can reassess the market and see what other player Will be part of your next generation of architecture So that's how we fix the problem typically Cool and I think I think I agree with both of Catherine and lucas when we're talking about the startup if especially when is the Not open source. It's just you know, they're telling us actually their product You want to if there is something here the thing that the problem is going to be sometimes they come with the idea Nobody else has it and it's very valuable At that point you're going to try to throw a slow roll with that Organization feel what's going on see the value But it's going to be a very slow movement to the production or or depend building dependency within our environment And make sure it's not just us And there's a there's a larger group of the companies. They have a same interest You know, it's kind of come down to the due diligence But the problem as you say and I tell me there's a high risk with those companies at the end of the day So we we're going to try to partner with other larger companies to see what we can do or not I I believe as a look at a open source is a lower risk engineering term than those companies start up But it's just my perspective Yeah, I guess it's yeah, I mean that's that's a good way to look at it. It's You know the pros and cons, right? I mean like with startups service providers typically require them to be indemnified right by some other larger partner right to support it and carry on but Why is that that's in some ways? It's not any different than if it's a closed source startup, right? I mean, it's it could go poof. Maybe you have more sources to work on the software if the project continues But it's still a it's a due diligence situation. You have to have a plan, right? um And in fact, it's the same thing If You're working at like, you know, katharine's, you know, on-app example 18 t's, you know It's publicly stated. They consume on-app etc etc And they use the project if the project dies You know someday down the road Somebody still has to maintain it. So you you better have a plan, right? I mean to Carry on with that at some point or You know diverge on something else, but In some ways, it's really is that any different than a than a vendor? Uh thing you buy into tin can Depends, right I guess and and that leads us to the next question, right is is um You know, we've had a series now of cycles in this space now in the last I don't know whatever 10 years You know six years where we've had some pretty significant projects We've had open stack for example, which is still here, but it was a pretty massive project at the beginning It's kind of on the other side of the curve and it's tapered down to kind of a maintenance stability situation But it's still here. There's there are vendors that sell it And it works and all that But that's still going to have a taper at some point off into into nowhere and so you need a plan but You know my point is we've seen a bunch of these now and and so like is your conclusion as operators You know, should we go back to a vendor led situation where they're Providing the whole integrated enchilada for you or are you you you folks still okay with Kind of what we've been talking about That one is going to be more costly costly in my mind because when you go fully when they're driven and In reality you you are in you you have limited more you have limited options after that And that's the most the change when you are completely single vendor or Like you have a hold on enchilada to save from one vendor that that's It might be a very large vendor and at that point, you know, maybe the risk of when it goes down or go bankrupt or poof is lower, but Your influence to get what you need as a safe way to actually drive your business and And do the different evolution of that Product it's going to be very much tied to the vendor roadmap and what's the vendor is going to commit to you to deliver to you So but there's still a risk. You're saying in every situation. Yeah, it is And I actually sometimes it became a bigger risk because it's going to impact your agility and Move forward Yeah Catherine lucas Yeah, I was just thinking that typically you don't bank only on one vendors You probably have a larval scope and then you will define the suitable vendors for for building your entrance scope But you will not only rely on one vendors to avoid typically the problem that we are raising here so We know that most of some of the vendors are playing in the same area So you you will start to negotiate with all of them And well, if you look a little bit what we did With our cloud when we decided to Run away from private and move to the public cloud For the non network workload We look at azure. We look at ibm. We look at amazon, but we will not only rely on one cloud provider Uh, that's just an example But typically that's what we do also for the solution to support our network or solution to support IOT we we have a selective third-party vendors We are used to work together and we are building solution in this space together cool lucas I don't have much else to add to this particular one so So Catherine, let me ask you a follow-up on what something you just said right and this is for you guys to on luka You brought up a good point right the multi vendor thing that used to be a form of insulation right you would have a Lead vendor and then a secondary in case they screwed up or you could pressure them for prices and all that right the usual thing So I guess the the question is like And i'm i'm encountering this kind of from the other side from you know, i'm i'm running a an integration of a source like this and i'm interested to hear is is is that really A viable way to do this in the open source configuration In a sense. Do you really need multiple vendors or does it make it worse? You know, and I'll give you an example like like the 5g verand stack today You can You can start at the bottom and say okay, I'll have two hardware vendors that's easy then I but Suddenly you get to the point where like, you know, how many platforms do you need underneath that? You know, how many kubernetes? Do you need say? And then the workloads on top of that, you know, how many workloads do you need up here too? You know to get the service that you're trying to sell so that's you know, I mean i'm interested to hear what you guys think about that Yeah, I think from the infrastructure Uh Even if we have the multi vim concept, right? What it is important is that the solution become agnostic from your vendors somehow because we we are running away from Premises we we have been moving to the virtualization. No, we are speaking about the containerization So we have disagreemented the white time we moved to white box this recommended the network um, so this level, you know This transformation running away from premises vended by a particular vendor and moving to this virtualization and our containerization have opened door and I think we have somehow There are still some vendor looking for some solution, of course, and that's why sometimes carriers are locked to them but we It's so more open now that we have a a bright range of opportunities And if we look at the on-app we can see the vendors are working together in the 5g area We we see with the nokia rixon working teaming up We saw also this type of teaming up with with intel ibm in other space and oran as well So they are really teaming up That's how they appear to us. They are teaming up and they provide some 5g Services and they know which one they will sell it Uh independently, but we will teaming up because they are The open source is a prototype of environment. They can try working together and also working with us So so having this experimental environment before selling us their commercial version of it It's also key because they can taste what will be your name needs Before really we move to the commercial version so I think this evolution from premises Uh, virtual is to cloud and having the virtualization to internalization Open really a new way of building a business Fantastic, yeah Look i'm up So what are you guys thinking in that in that space? So i'm going to go back to actually probably with your original question the way I see it when when we talk here about Functions multi multi tools for the same function, which is quite this way. Uh, when we're talking about like Orchestration or Veeam even if you look at the NFVSX so we might have a is it makes sense to have a Three three different themes or three different a stack of kubernetes realities Every time you add One new vendor or or Open source tools in the same function. What do you do is you immediately? increase your complexity That's that's given, you know Because you you're going to have it in hand you're going to have a more a new set of the vulnerability Other just I mean bog other things as far as it was more than one right and they may not be the same version all the time And they all of these messy details right and integration together Just a chance. So so before that I think anybody wants to do that You need to access that set of rules like how you communicate for to for that function The the acceptable set of set of apis or whatever is your manner of the communicating to that tools to that function Because regardless of the tools If you can get that and that communication method communication to that function for Regardless of what is on their line They can talk about having more than one if you are ready as the organization to Accept those changes within that the multi tools for the same function When there are open source for that function It's a business decision and it's that's the risk management, you know, you and you decreasing the risk of the Open source or when it goes belly up With having multiple but in the same time but you have to manage it is what you're saying You need to imagine you need to be able to build an interface to communicate to different ones And also you need to accept the fact you have more set of The bugs other things might happen Because it's not let me ask you this question kind of you both had have hit on the same kind of thing Are operators taking on the role of of software integrator? Going forward with open source. Is that really what we're talking about or or do you have to outsource it? but should this be a It sounds like it because you guys are basically saying this but should this be a defined role that the operator now has to Explicitly spell out somehow actually So let me put it this way I there has to be a value a business value brought by open source and a business value brought by a vendor If the system i'm trying to build Requires me to do 80 of the code Right, there's very little value brought on by you know, 20 percent of the code out of a project, right? so whether it's so in that case Open source might be able to fit because the the support costs for that particular piece Is going to be limited and I have to invest heavily Not I wouldn't even say integration. This is not integration. This is custom code built on specific platform, right? Integration, you know, if it's done well, it's easy. I mean, I wouldn't go and put linux together I would just go get, you know, some linux that's rebushed, right now But when but I I end up with situations where It really doesn't work when a vendor comes along and goes my platform does anything you want just code it And okay, but now I have to invest heavily in a proprietary because what are you paying for at that point? Not only it's very expensive sometimes They but then I have to do all the coding and I was like no You know, that doesn't work if that's the case That means your platform does everything but it doesn't do anything useful do anything useful for you That is actually a perfect comment. Look I made There is a vendor sometimes come and say we do everything and they can't do anything really, right? and back to your question Yes, we end up to a lot of Stuff for integration or code integration because the reality is we are building puzzles There's a blueprint as to deliver the certain function at that point You're going to build that puzzle and you need to indicate those pieces there to deliver that what you intend is at the end of the Anything if you're talking about there's an intent for doing it and we need to go deliver that the intent and I I might not be educated enough, but I haven't seen anybody can deliver our intense as a one vendor solution We have a lot of pieces. They need to behave on work together to to do that intense regardless of the What is that intent? And that's a change But I come back on what Luc has said since the beginning you need to understand the return on investment and assess buy versus build building yourself And what you want if you make this assessment for any solution you want you to buy or build then you know Where you go? So buy versus build it's probably what the any carriers is doing Um just to be sure because at the end they are they have a clear idea of what they want But the solution there are so many on the market And you can also build yourself So the return on investment is a key word So the business the business angle is really critical to this, you know and and and the details really There's there's another there's another angle. I want to invest my development cycles into unique things that will give me an edge or against the competition In the market So I don't want to suddenly go and do Things like create something I can go buy off the shelf, right? It's faster for me to go do that Uh, I want to invest where it goes innovation in service and in You know fulfilling cost real value as opposed to no, but reproducing. So so that's another side As well, which we heavily consider in you know a build versus buy situation Yeah, so it's it's got to add real value to the to the party or you know, what are you doing, you know Just just building it because you can doesn't mean you should right? Cool. Yeah No, go ahead mo And the problem is for most of us, uh, we don't have a lot of Programming or software people we have to use them As why is they we can't just through resources at the problem when we can solve it as well. Yeah, they're expensive. Yep. Yeah No, that's cool. Um So we're we're up against the uh, the the half hour here Do you do you just kind of want to go around the the uh, the Brady bunch squares here with any closing thoughts? Um, Catherine, do you want to go first? No, I think that what I would like to highlight. It's really we it's a partnership at the end It's not the the carrier is skiing and the vendor is telling their solution Everything had to happen with with our partners and that's how we we are able to build the the best solution To deserve orchestras Cool. Mo you have any closing thoughts? At the end of the day our goals and most of time aligned with our partner, which they are our vendors or uh, which we work with our vendors They're always going to be challenged, which is part of the you know Having they're having a lot of peace to put together and relationships. We have it without everybody but I think At the end of the day the goal for everybody is to be able to deliver Value to their companies and to the service for why they're Okay, so um the closing thoughts are You know open source has a cycle a life cycle, but there's also part of the life cycle is the uh quality of the seniority of the coders behind that particular project You know, I it doesn't necessarily mean that you know that we used to start out with zebra And then we went to quagga and then we went to bird and so forth in you know Mentioning one particular about the project It doesn't mean because you know, everybody goes over to the next one that it actually is better I have situations where I actually have some of the best people That used to work on pieces of linux, which are fairly important They're working for us a charter now And those pieces of linux are not improved since they quit They uh, you know, so I would say one of the things that's very important is the governance of a project a they a lot of people want to go there and make a Mark, but it doesn't mean that that project is uh is So that's something that really I would uh look at the major open source integrator like red hat to Uh keep a close eye and on the governments on this project so that we Get we move forward and we don't you know move backwards. Well, it's like you said, right? So we have projects that do stuff that's useful not just do stuff You know Cool fantastic. Thank you Well, thank you everybody and um, I want to thank thank our esteemed panelists today and uh Um, and thanks for ronica for helping to uh facilitate the