 Good afternoon, everyone in Vancouver. And good afternoon, good morning to everybody who is actually online right now watching us on the web. Today's presentation is about open source innovation and how do we empower a telco to own their destiny. And I have the privilege to present this with my fellow colleague, Steve. So I will introduce myself first. I'm Sana Tarek, the principal technology architect. I have been working on cloud and service orchestration for the last six years. I'm one of the founding members of TELUS Ospo. And I have the pleasure to work in the project nephew as vice chair of the TSC and a chair of the SIG Automation Group. And I'm also representing TELUS in TAC LFN. The next presenter who will share this talk with us this evening is Steve Danock, who is director of TELUS Digital Chief Information Office at TELUS. And he's also the head of developers platform, design systems, and publishing. He was one of the founding members with myself in the TELUS open source program office, and he's representing finance committee in LFN. The agenda in a glance, we'll first walk you through the journey of cloudification. What has happened over the last five, six years and how telcos have transformed to become very agile in cloud-native in its entire technology stack? Next, I'll walk you through some foundations, how we laid out the open source program office at TELUS, how we became members of Linux Foundation, and what we are doing with our membership benefits. And I'll also walk you through Project Nefu, not through the technical details, but to walk you through the miracle that the open source can serve in solving some of the most complex problems in the industry, which are not solved by one vendor, which are not solved by one standard, but which can be solved by collaboration of everything coming together with our open source. And the next few items on the agenda will be covered by Steve. He will walk us through the operationalizing of the open source program office at TELUS, and he'll also walk you through some of his open source ventures. Let's dive into it. The very first slide I wanted to do a level set on helping us understand where the value chain in the telecommunications business is shifting. Over the last few years, we have changed that how the digital transformation has changed, how we are living our everyday life. So the apps that are represented in the top tier of the stack are actually changing how we walk, how we wake up in the morning, how we are traveling, how we are eating, how we are shopping. Every walk of our life has been transformed by these digital apps. And that's where the customers exist. That's where the brands exist. And that's where the customer relationships exist. So TELCOS have to create all these digital apps as moving forward and constantly innovate in the services layer to be able to maintain their edge in the competitive landscape. And if we don't do that, we will eventually be reduced data pipes where someone else will bring in their brands and their customer relationships, and that will own that space. So the value chain is shifting to constantly innovate in the services layer. And how do we make it happen? The technology stack that serves that is actually underneath that. Our core, our REN, our transport, and everything has to be open, agile, software centric. We need to transform our organization to be very DevOps focused. And we need to write software. We need to embrace open source so that the agility can drive the innovation in the layers above. And that's where the focus of the TELCOS is increasingly becoming prominent. And we can see how this talk will actually help you understand what are we doing in TELCOS to own our destiny and how are we working with our partners, our vendors, and the open source projects all around to maintain innovation and software competitiveness. TELCOS have come this far. If you look at the slide, all these transformations have already happened and happening for over the last four or five years since I have been working. You can see how standards are actually being adopted and how incorporation of open source and standards has happened. The DevOps transformation across the organizations have been shifting tool sets, skill sets, mind sets, how we are working and how we are interacting with our everyday lives. The time when I joined TELCOS, we were barely understanding the concepts of NFV. And people were so naive at that time that they couldn't even understand the difference between NFV and SDN. Arpit is laughing at this. And see how far we have come. We have the most sophisticated public and private cloud strategy where everybody has the skills to basically use cloud, to evangelize on cloud, to create new open source projects, to use the existing projects. And that skill set has been growing over the last few years and it's going further right now. If you look at the application modernizations, we had physical network functions, which actually became the virtual network functions. I remember we had a workshop in the same location a few years ago when myself and Arpit and some other members of the community were actually talking about the ideas of CNF. Today that's mainstream. Our production traffic is in CNF right now and we are talking about how to make it more cloud native. So the application refactoring modernization has been happening for so long right now. The adoption of open source and software has been a biggest realization at TELCOS and of course across the industry, which has been very exciting. One thing where we have not made success is that a lot of automation that we do today is in the file and forget mode. So we deploy something and then we have not been able to reach a stage where we can actually achieve the life cycle management of that. And here's why I'll present some of the work in the upcoming slides that can actually walk us through that. And what are the challenges presented in the existing standards and open source and how we are going to solve it again through open source is what is going to be very interesting. In this particular slide, there's one more element that I wanted to describe and that will actually refer back to our press discussion, how the vendors and our partners and our partners relationship is constantly changing. So in the legacy world, when TELCOS who are heavily reliant on some vendors to provide them software for delivering their critical services, it is extremely dependent on standards and RFCs because that's how we have been evolving to achieve interoperability and to achieve the quality of our services that has five lines reliability, which has been fine. But one thing that has still not changed and which probably needs to change is the commercial models. Those vendors or partners who have been providing us the software would come in a form that would be a black box in the older times. And there are two types of prices attached to that black box. Number one is the price for the black box itself and number two is the price for operating the black box. And I think with the world of open source, with the understanding of the common skill set that is basically a part of the stack that is building that black box is now basically changing the status quo. We are at a stage where we need all the questions answered. We can look at the black box, we can identify what's inside that. We need the right to basically understand the software, be able to write more software on the top, interact with ourselves and be able to deliver services on the top through our own software that we can build on top of it which is basically changing the status quo on those commercial models. Another aspect that is happening in the open source as well as as we would see happening very soon, the software and the code writing will become drastically simplified. As we can see the chat JPD, we will not find value in just the ability to write code. I think we would need our partners to help us find value in writing code that actually enables us to basically embrace open source. And that's another shift that I'm expecting that open source will bring about in how our commercial and cost models would start to drift and change to make it more open and to make it a partnership that is actually helping us move forward in the direction that we want to move forward into. Something that we are all looking forward to. I'm now very excited to share a story with you that actually walks you through the powers of open source, how open source can address and change things that otherwise are extremely difficult to solve in industry. And I will walk you through my own personal experience of working on Project nephew. So I've been working with the service orchestration space for about five, six years. And in this time, I actually happened to realize that at a stage when I felt that there is so much fragmentation in the industry, I looked at all the open source projects. I looked at, see what has done. I looked at 3GPP. I looked at the vendors products. Everything alone is actually working perfectly. But now when you put everything together, now I'm giving you a perspective of a service provider's lens. Each and every network function deployment has its own story. It has its own proprietary way of deployment. It has its own proprietary way of configuration. It has its own proprietary way of lifecycle management and writing policies. So when you bring it all together, the left-hand side on the diagram expresses the situation of a brown field. Now look at the people actually responsible for operating that type of a model. And imagine the TCO that has been increased for us over the last few years to a level which we were not anticipating that that would happen to us when we go to cloud. All these CNFs are like pets. We have to have a different deployment method, a different template to make this happen. And I understood the fragmentation in this world is actually not something that one vendor can solve or one standard can solve alone. I have been working with Google on Project Nephew since inception. And about three years ago, when we were working on the ideas on how to solve that and how to deploy our network functions to Google Cloud, I think the idea of Nephew came out. And as the idea of Nephew was starting to materialize, I was worried about the fact that maybe that's the missing piece of the puzzle. But how would this take flight? How would so many players in this larger ecosystem actually follow the idea that is a simple idea of Kubernetes-based deployments through CRDs and operators, replacing all of the existing Brownfields and how we deploy our network functions today? I was worried about the fact. But over this last one year, I have seen 70-plus organizations joining. And I see that they can see the simplistic idea that all the other objects on the cloud, which cannot be expressed by native Kubernetes, can be expressed through CRs. We can write CRD on the top to define its ideal state. And we can write an operator to basically stitch that with the infinite closed loop to achieve our day-to-plus management and operations. It's a simple idea that has always existed in Kubernetes. But how do we make it real? Is the power of open source that the project Nephew and the idea is heard, it's seen, it's understood by so many players in the industry right now. And that project, which is actually writing the back of Kubernetes, which itself is a very big miracle of open source right now, is going to do standardization across all this heterogeneous ecosystem where public cloud providers, everybody using Kubernetes, all the telco network function providers who are using Kubernetes for deploying CNS can actually use one model of standards-based, Kubernetes-based deployment, which is definitely going to solve the problem if it's done right and if, of course, the project gets to the state of maturity and adoption for which we are envisioning and hoping that that would happen in a few years from now. But the beauty of open source is we can bring everybody together on one platform and we can accomplish things that we have not been able to accomplish otherwise, and which can drive standards, which can drive vendors, which can drive service providers all together through this standardization. Working in open source and especially working with the project Nephew, I had a passion for open source for quite some time and about a few years ago, three to four years ago, Steve, myself and some other fellow colleagues in Telus were brainstorming on ideas. We have had so much opportunity in open source. What can we do in Telus for open source that everybody can use open source, consume open source, contribute back into open source all through a very safe way and we can build a platform internally with in Telus so that we can bake that in our corporate strategy. We can change that to shift our culture. We can change everyone's mindset to be able to look into the open source world of the things and be able to do our job function better. So we laid out the foundation for Telus Open Source Program Office where we built a framework of contribution and consumption. We laid out policies. We built a culture within the organization on giving everybody a credit who is working in the open source. We built a framework in how developers within the community can actually talk to each other and how to network externally and this project was funded by our CTO and all the VPs actually loved the idea and we were regarded for doing the work that we did in the open source program office. Having laid out this foundation a few years from that, we actually were able to become Platinum members of Lennox Foundation. I remember the days when we were trying to convince our leadership to become silver members of Lennox Foundation but I think we had done so much work in the open source by the time we were ready to make a decision, we went straight at Platinum level of membership and we are really enjoying the benefits that we have received as Lennox Foundation members. The biggest benefits are actually helping promote our OSPO vision further. We received trainings with 50 plus licenses which we are operationalizing through OSPO. We are incorporating the Lennox Foundation benefits into our fabric of OSPO right now through our internal channels, through our internal Slack channels and websites to make sure that everybody can understand and follow how to work through those benefits. The biggest thing that has happened with the membership for us so far is basically our industry reach and collaboration. We have built new networks. We have received new projects. We can have the visibility to work with other service providers like DT and Orange and learn about their challenges and share our work with them and to be able to share our voice to drive the vendors and their roadmap in a direction that is actually able to solve problems for all of us. And last but not the least, Lennox Foundation membership has actually given us a seat at the table to be able to share our voice on the next critical technology to have a voting power in one of the TSEs where we can actually change the direction of some of the projects in favor of our businesses. And all the verticals and tell us are actually consuming our membership benefits right now. We are at a stage where service providers have a very critical role to play. Through our open source contributions, we can actually influence standards, we can work with cloud providers, we can work with other telcos, and we can work with our suppliers, network function vendors to actually change the roadmap and actually influence the direction in the future to be able to accomplish things that we want them to accomplish. And open source is actually driving this all and it's in the middle of everything. I would now invite my fellow colleague, Steve, to please come on stage and walk us through the operationalizing Ospo journey within Telus. Thanks, Steve. Just a quick note, I'm just really, really grateful to be talking to you from the unceded territories of the Muscovite and Squamish slave-tooth people and thank we get to work and speak here on this land. So let's go back four years ago, 2019, you're a member with similar times. And let's talk about what the answer was if you want to talk about open source at Telus. It was no. Can I contribute? No. Can I use it? No. Are we using it? No. And of course, this is not at all true. It was everywhere. Even in 2019, the vast majority of the internet ran on open source. We were heavily using open source. It was everywhere. There's a real head in the sand moment. I know, but you really spoke to it, right? Telco was very proprietary. It was a little bit older, a little bit slow to adopt. And that was really the state. And when I think about most of what I'll be talking about is the journey from this slide to where I am today at this podium, talking about how we changed. And so this is sort of that where we got and how we did it. And I think what's important is how we got there and the kind of work we did. And I want to talk about where we started. So in 2019, this was the landscape of open source that we were already using at Telus, right? It was a lot. It was everywhere. There was no part of the company that wasn't already actively consuming and what we discovered secretly contributing to all of these projects. And this was a really core statement. I joined Telus in 2018. I'll talk about it a little bit later. And one of the reasons that I joined Telus was in fact the promise of open source at Telus. Little did I know what I was getting into when I joined. And I want to talk about how we founded the open source program office because Sana, myself, and a couple of others, we were all solving very personal selfish problems at work. Like I had a whole bunch of developers who were working, who were secretly in their spare time trying to figure out whether they could in fact legally contribute to open source. Our employment contracts in 2019, it was entirely unclear because the language said Telus owns everything, which is not unusual. But that makes it a pretty gray area if you want to meaningfully contribute back work. We had a lot of really great software that we were building, particularly on the cloud side that we would have liked to contribute out that we didn't have a model for. And this was actually driving a real concern. My focus at work is developer experience. I lead a developer team. I was hired as what we call architects. Most companies call us staff engineer. And my job was to improve the developer experience of working at Telus Digital. How we ship the joy of being a developer at work. And what I heard loud and clear as I talked to people in 2019 was, can you solve this for me? Can we do this? This is cool. I had this idea on the side. How do I do this? And then we ran into other things where we'd be buying software from vendors and they'd tell us about how it was great. They had this great open source backend. We could do all this work. It was extensible. And we're like, but how do we do it? What happens if it breaks? And this is the sort of concern that we'd hear over and over again. What's the accountability? If something goes wrong, who do I talk to and hold accountable at the end of the day? And it was a real fear talking to our leadership about open source. So we liked to buy proprietary technology that never quite worked out of the box. And we'd spend a vast amount of money to customize it for Telus. Because Telus is big enough that nothing works out of the box. And it turns out that open source actually sells a lot of this because almost by design in our, but you talked about this, you have to build with it. You have to work with this. It's not just plug and play and it's not meant to be. And that's the culture we were building. The other thing that happened around this time at Telus was a real, from leadership on down, it changed to a company that again builds things. We had been a company that bought things and integrated things, but there was a real signal change in 2019 that we wanted to be a company that builds things. One of the reasons I joined Telus was, I want to build things. That's my background. That's what I love to do. And it became the sort of, again awkward space where we just didn't have it. So here's my first advice if you want to do this at work and you're having problems. Find your co-conspirators. So Sana has been an amazing co-conspirator. We worked with this old man from procurement. This is not a worry to the org that I know anything about. I have never been in purchasing, but it turns out that this is a real problem for procurement as well of how do you safely consume open source? How do you make sure that their support agreements? How do you make sure that we have understanding if there's dependency chain attacks? Who's responsible? And so this is a real problem for them. We had someone from our security side who we were really, really worried about viral licenses sneaking their way into our code base and we had no idea what to do about it because we weren't paying attention. And so we all came together solving these very disparate problems from across the organization and just thought, you know what would really help? We had one place we could talk about this and we started to work on it. And here's my next advice, start small. We didn't just go up and say, let's open source everything a tell us that wouldn't have worked. Even the first conversations are a lot of, could we at least get out of just shouting no, right? Very simple statement. Let's just not shout no anytime anyone asked for anything. If you think about the great work that Sana has done, projects like nephew would have been impossible, right? We simply wouldn't have done it because the very idea that we would commit so much brainpower, so much activity, so much money to something that we weren't immediately owning and in fact, not wholly patenting was foreign to us at the time, right? But we all solved very small problems. I had a problem in which I had a team member who had been actively contributing to Node and he just wanted to make sure he wouldn't be fired for it, right? Like that was the worry. Now, would he have ever been fired? Probably not, but this was the problem we had. I was like someone who really was actively contributing to the Node project, wanted to keep doing it and we wanted to make sure that we could just bake that into his day job. Seems reasonable. We were getting great value. We use Node everywhere. That's our primary code divider for what we're driving on the front end and it was important. Likewise, we wanted to make sure we didn't have any viral licenses in our code. We wanted to make sure that anytime something was being installed on an appliance, it would stay there, it would be fine. We wouldn't suddenly realize that we had to unleash everything. So, small problems, but dream big. In every one of these instances, we thought about sort of that dog-fruiting aspect. If we can solve this for us in a way that we can do it ourselves, can we make it repeatable? Then we spent a lot of time gathering data. We spent most of 2019 and even early 2020 just figuring out what was there. We ran a bunch of surveys interviewing developers. We used procurement to figure out what we'd purchased and of the software we were purchasing, what were its dependencies. We had totally absolutely started scanning all of our repositories across GitHub. We had many, so GitHub, TFS, GitLab. There may have been others at the time. So we had a very broad way of where we were using software and we just had no idea what was in there. But we started to build it. And this really, really painted the picture which was Telus, actually relative to a lot of our competitors, was pretty advanced already. We just didn't know it. We had nearly 30% of developers in Telus Digital, which is where I work, had committed something to an open source project in the last year. Another 40% would be doing it at work if they could and they just weren't sure. And this is the state of the world that we're in. Nearly every single piece of software in our day-to-day stack was already open source. We had logged bugs, we had logged issues, but we hadn't done much because of that lack of clarity of could we? And this all certainly gathered, allowed us to show to our executive leadership that the reality was we were already an open source company, we just didn't know it. And then the conversation turned quite dramatically from like could we, should we? To okay, we are, how do we do it? And it really changed the conversation. When we had that flat, we had a big presentation to executive leadership probably late 2019 after the first set of this. And this really changed the conversation of then how do we do it? And then so our pitch was, we were gonna make an official policy, we were gonna make a self-serve process so that rather than know, we could get default to yes and everyone could safely make choices about how and where to open source. That was the pitch. That simple, just ship a policy. Four years later, we think we've shipped it. But... So here's a little bit about what we talked about. And almost all of this came back to that conversation of risk versus reward, which is almost always the conversation when you're barking upon culture change. Because more than a technical change, more than a legal change, this was really a cultural change. And so I just wanna talk about a few of the concerns that we heard and how we addressed them in case you have to do this again yourselves. So first and foremost, IP concerns versus the opportunity. So by default, if TELUS builds IP, it wants to own it, it wants a profit from it. This is not an unreasonable statement. IP matters for a whole lot of things. People invent things and wanna benefit from it. But what we wanna make sure of is that there's also a great benefit to sharing IP for the greater good. And I think everything that LFN does is a great example of how sharing IP helps everyone else. That we can compete on different matters. We can compete on service delivery, not on core technology. We all benefit from better core technology. And I think one of the things that we've really seen is actually the vast majority of the work that happens, there are exceptions, it falls into that category. One of the things we're able to do is make sure that we're well connected with our patent office, with our IP council, with our legal group. So there's a clear process. If you're a developer or a product manager at TELUS, you're like, is this valuable IP that we wanna share or not? There's a clear process you can self-serve this. And just answering that. Not that it's yes or no, but that there's a process to determine yes or no. That weighs the risks of financial benefit, weighs the risks of actual accountability and risk. These are all the things that help, mean that we can sort of just push the conversation off and just provide a process to make everyone comfortable. And that way everyone can keep moving forward. Employee interaction and retention. So one of the concerns we heard was if we have all this open source work, we will sort of bleed employees to projects. This is not true. If anyone has worked a lot in open source, it tends to be volunteer. Some products are well funded, most aren't. But what it does mean is that people were spending time on open source anyway. And if I started to look at how much time 30% of developers had contributed to open source in the past year, none of them had officially done that at work. So either we were already sponsoring a whole lot of open source unintentionally or they were working extra on the side that maybe they weren't, they were even more tired out. And it turns out that giving opportunity for this is actually a really great attractor. I'm actually very much an example of this. One of the reasons I joined TELUS was because of what we had open sourced rogue before I joined. And being able to contribute that as part of my job was what partially drew me to TELUS itself. There's a great example. I worked with a developer on my team. He started off, this is when I joined, he was sort of a junior developer. He was really, really interested in telemetry. So he got really interested in some of the open telemetry projects. We work with a project called Backstage, our tool that we use a lot as Dynatrace. He spent two and a half months building a Dynatrace plugin, released it, it's one of the most used plugins. It's a great example of how we can just give opportunity to show someone how they can do that work. Everyone has benefited. There's nothing about Dynatrace or about Backstage that TELUS has any IP interests in, but it meant that this developer who was kind of like, eh, what's my next challenge? Was rewarded and had a great thing to do at TELUS that we all benefited from. And having that conversation has really, really helped. And we've seen this already. The more that we have people out talking about the work that we do, great examples like SANA being out and present in the world attracts more great software developers. If we wanna be a company that builds and ships great engineering, we need to show it everywhere. And there's nothing better than just opening the books and showing everybody your code. License and dependency chain risk. This was a really big one. This remains a really big one. Today, dependency chain risk is very well known in 2019, less so, but the security people were very concerned about this. And so we were very worried about, again, if we were using all open source and we had no control of dependencies, how would we know if it was safe? Of course, the answer is the same with whether we're using open source or not, we wouldn't know. One of the unexpected benefits of us having done this work is over the past couple of years, because in 2019 and 2020, we spent so much time in this space, we already have really great tools for dependency chain scanning. So we're already starting to work with S-bombs. And so as these attacks have grown, we've actually been really well positioned to already be fairly covered. Now, there's tons of threat vector here. There's a ton of work to do here. But by investing in open source, by being out in front, by thinking about the fact that we're gonna be incorporating sort of public software endlessly, we've actually changed how we work. Our development practices are more secure because we know that we're gonna be using open source, because we have tools that scan our dependency chain already in place to de-risk ourselves to allow open source, we've become better positioned as a company. It's been really, really helpful over the past six months in particular. We've seen it just skyrocket. Finally, idea of regulated versus deregulated access. And this is a little bit sort of the prohibition argument. It was clear open source was happening whether we wanted to admit it or not. But what we wanted to be able to do is talk about it and celebrate it. We wanted to make sure that it was out in the open. Because again, it's one of the better ways to make sure that people are doing it right. We want TELUS to be a well-represented brand. We care deeply that it is good work. And I want people to be able to put TELUS's name with pride behind their work that they do. And if they're gonna do it anyway, let's celebrate it. Let's make sure that we know about it. Let's make sure that we have some review process, some quality control. Because if it's not off the side of the desk, that wasn't always happening. And this argument of simply let's accept reality and embrace it, regulate it, make sure we know, make sure we know exactly the work is happening. Again, it just de-risked the idea of everything's gonna be open source and could be a total wild west. And this conversation, again, like whether real or not, it's a valid fear, right? It's a valid fear of anyone's gonna release anything all the time, anywhere. But giving people a process that they can self-serve that is largely automated that lets us know that gives us an audit trail really, really helps this conversation. We're a regulated company. We work in a regulated industry. We're used to regulations. We're used to having process control. And adding a little bit of process control here really helps split the difference and make sure that both the developer has a great experience shipping work and that our admin, our finance, our legal, they all have feel good about what they can infer about the work being done. Last but not least, champion innovation. And I think, again, I'm just gonna point this on, it's like the Nephio project is a great example. I want Telus to be leading in every space that we're involved in. This is a great place to be. There's so much exciting work that we can be participating in that if we said no to this, we couldn't. And it turns out that that was actually such a great draw for leadership. Everyone was bought into the idea. We want to walk with swagger through the world, right? We want to be good. We want to be seen as good. And we want to be a company that has people do that. And so championing innovation and making sure that we're investing in it is a really important part and was a really big part of making the pitch to make sure this is official. So these values are hard on screen. You don't necessarily need to read them. When I joined Telus Digital, in fact today, we had these nine core values of how we worked at a team. Telus Digital is this pseudo-shadow IT part of Telus. It's sort of been a little bit separate. We used to refer to the rest of Telus as big Telus. We don't anymore. We're much more integrated now. But it's really had this value of sort of being a quasi startup inside of the larger enterprise telco. And that was intentional because we needed a space where Telus could sort of reinvent itself for the modern world, for this world of cloud first, to be cloud-native, to be highly agile, to do things different. And this really spoke to me. So I have run a bunch of small companies. I've done a lot of consulting work for large companies. I had never worked in a large company before. And I was very, very hesitant to work at someone like a telco. And when I came in 2018, Telus really sold me, there's two pieces of what happened. One, in GitHub. Our reference architecture was public. I could see exactly how he built all our starter kits, all our pipelines, all of our opinion of what good looks like to write software. So long before I joined Telus, I could kind of get an idea of what I was walking into. And seeing that in the public was a really, really big deal for me. I spent a ton of my life working in government, which does not like to talk about anything. And this was such a nice change of pace. And then I saw these values, which likewise were in GitHub and were also on our website. And again, just that openness really attracted me as a person. Now I'll admit when I got to Telus and I realized that this was rogue, this was not the normal. It was a bit of a shock. But it also meant that, I joined in 2018 by 2019, we'd started this project. I was committed that we were gonna make this reality. And I think one of the great values of Telus Digital is that, it's take risks, it's be lean, it's be an owner. So I was like, okay, so this isn't true everywhere, but I want it to be, what can I do? And the great thing about it has been we can. But these values have also really, really helped Telus Digital be a place where we've done a lot of work with open source. We've had a lot of time to interact with Node with React, we're a Node React shop. We spent a lot of time with backstage very early on, which is a great sort of software catalog project. Everything we do, we've been opening. We built our first design system and we open sourced it. Again, before we really had a process. But we wanted to make sure that we could do this. And I think these particular values that I've sort of bold faced here. So take risks and be lean. That's a lot of open source, right? Kind of do it small, take risk with it, but be smart. But build for quality and reuse, right? One thing I definitely feel like, if I know that anyone in the world can read my code, I pay a little bit of attention to what it looks like. I focus actually a lot on code readability when I'm writing code, I'm gonna open source. And I think that matters, right, that value. And I think the structures that you get with open source governance actually lead to better code writing. Because you want to think a little bit about like that. I think we've all been guilty of, I'm gonna build this and I don't have to care about it ever again. That's not really true. Most code, you're gonna spend 5% of its life building it and 95% of its life maintaining it. It'll probably be people you have never met maintaining it and that's really, really true with the open source community. And then this idea of strengthening our communities around us. This has been a core value that has attracted me to tell us as a company. And when I think about the value that we can play in open source, to be someone who sponsors work, to be someone who supports other work, to be someone who invests in open source, that is the technical community around us. And it really has shown true in Telus Digital. And it's partially why we're able to do a lot of this work. This had, so since 2019, we've seen, I think it's 75 contributions, so not a huge amount, but a regular steady drip of work happening long before we had a process. And all of this has really helped show the type of company that we want to be and where we're going. And it's also helped show the rest of Telus that it's safe to do this. That this is a place that we can do it here and we can bring it everywhere. So I'll wrap up. So the real value of open source for Telus. So one, is that already, engineering brand. If you think of great engineering companies, Telus is probably not at the top of the list right now, but it could be, right? And it should be. And this is something that we want. And this is a place that we think that we can really help. When I think of the great projects that we're seeing in LFN, when I think of the work that we're doing that's in CNCF, when I think of the work that we're doing to open source and where else we can go, this is a place where we can really play. And it's a place where we can really show. Canada is a fairly small country in many ways by people, by number of companies. And it's a really great place for the differentiate but amongst our peers. Improving reliability. This one, I'll admit, this came as a surprise to me. We, I didn't expect to see a sort of a linear relationship between the more open source, the more we thought about and worked in an open source way, the better reliability we had. But then again, there's a little bit of, you know, many eyes may call bugs shallow. There's a little bit of let's choose boring software. One of the great things about a well-established open source project is that it's in many ways really boring. Everybody's already agreed it works. Everyone's already constantly working on it, right? And that helps our reliability. And whether it's shipping containers or the networking space, that choose boring software idea really, really works. Investing employees. Keep people space and time to go think, see what they come up with and now they have a place where they can take it to the world. If you have a great idea, tell us about software. We have an entire process. You can bring it to the world and let the world vote if it's good. And that unlocks so much innovation from the ground up. I never even have to know about it. You can just do it and it's amazing. Technological honesty, I like this one because one thing we discovered when you're doing sort of our data gathering is we were using open source everywhere just we didn't know about it. Our vendors weren't always telling us about it because we didn't have any process and in fact it was a bit problematic. But we have much more clarity than the entire end to end of our stack and we're open about it. I can very happily say what we're using everywhere. And it doesn't matter that everyone knows what's in our stack because everyone else is using the same stack too. And that type of sharing through is such a great cultural mantra to have. And then finally, cultivating contributions. I think this is really the most exciting. We spoke to a bit about investing in employees. The idea that you can invest bottom up is such a great powerful way to grow what you're thinking about that anyone in any team can have great ideas. It's amazing who I meet at a company of 30,000 with crazy backgrounds that they can bring into a project. And we have a path to unlock that. So let's talk about how it's going. So now we're at yes, which is great. It's a nice place to be. And I think, so this is the most stock photo we stock photo I could find. It's very corporate. It's celebratory, but that's kind of what open source is now. And I think it's a great thing. It's totally great that this is a very corporate mainstream normal thing to do. It's not on the table. It's not hidden. We're just celebrating that we can do it. And I think it's been such a great story the past four years of progress we've made. The fact that there is now a clear open source policy and we have regular contributions. I have an employee whose dedicated job is to contribute to an open source project. A full-time job that I'm paying them. That could not have happened a couple of years ago. So there's much more to go, like the future. It's not evenly distributed across Dallas yet, but we're getting there. Thank you. I need questions. I do, I do. I do think there's a little bit of, I'm going to call it. Oh, sure. So the question was, is it sort of become the norm that if you're not using open source, it's harder and harder to attract talent? And I do think so. I think there's a bit of danger that can be some shiny chasing there. That's always going to happen. I think the flip side is, if I choose a very common open source language, I can in some ways lessen my costs as well, because there's going to be more developers who have familiarity. If we use the same stack everywhere, I'm a big believer in engineering platforms. If we use the same stack, everyone can move about and it's cheaper to have internal movement. In fact, unlocks internal movement, which is great for employee retention as well. So yes, having well-known open source software makes it easier to attract talent. It makes it easier for them to use whatever we have, because again, it's kind of boring and standard. Anything else? All right, thank you very much. Oh. We can never figure out who is deploying. So we can't brag about it all. Because the other is the PCO challenge, which is nobody's going to come and say, I redeployed 20 people into this. So I have a tool like back-end tool that helps you justify that financially this is a win-win for you. Like is there a process or is it just like, hey, I used to have five renders with five EMS systems and 10 people supporting it, and now we're in two. What's the metric to do? It's a little bit of that. So there's been a couple of places where we can see it directly. So where we have taken out a very well-known CRM tool that has quite a high license fee, and then we paid to customize it on top of that. And we just removed the license fee part, right? We didn't have to hire anyone else. In fact, we had more developers who could work on it because we suddenly were using standard software. So we know that we can eliminate license fees here and there. We also know, so we're doing it. I may be able to tell you more in a few months. So Backstage, which is a software catalog, has a lot of competition with other systems, and we're going to try and remove those other systems. And it's specifically about cost of ownership that we don't need to develop our team. And I think Sana has some really great examples of this, too. Now, good. So, Albert, to your example, I think I have a couple of data points that I can share. In the beginning, like I said, when you're deploying a network function, and if it is very proprietary, then what comes with proprietary? Proprietary means that you have to pay extra to each vendor to give them professional services. And for one network function deployment, the professional services were around 70K, 80K. And give you an average. Now, when you're working with Kubernetes and open source tools and open source projects, it means that we can just get random contractors. We are not paying heavy professional services to vendors who actually has that knowledge of proprietary interfaces, which means that we can bring the cost down to 20K per network function. That's how we are reading numbers. And it's actually putting together the TCU of the tools, the maintenance of tools and professional services to all different types of discrete vendors, putting it all together, can actually lead to savings of millions of dollars per year. And we have more data that probably I can't share right now, but we definitely see a lot of benefit and where the benefit is coming from. Less tools, less proprietary work, which means that you're not paying all those individual vendors extra money on professional services. And when you're doing it with open source, one unified tool, common skill set, and you can find that skill set commonly across industry to basically get more work done in less time, which means lower TCO and faster work in deployments. Yeah. Did you move, and if you did, how did you move from like people contributing to random projects where they like to contribute to the organization have a plan what they would like to achieve and your employees are doing contributions to realize that? So there's a couple of things that we don't admire. So one, I give, we have the idea of 20% time. Professional development Fridays. Spend your Fridays, however you like to do, as long as it's something that you can argue is gonna make you better at your job. So contribute to whatever you like. We see people doing that. What I ask people to do is talk about it. Within our backstage product, we have a tech radar that just surfaces reality of what people are working on. And so we can actually start to see this and people can start to share. What we found is people are finding communities and that itself of other people that tell us who are interested and that's starting to actually shape where we're going and what we're using. Conversely, I'm very opinionated on what the good looks like and I'll be like, I wanna invest in this. So if you wanna come work with me, we're gonna invest in this. And that's been a pretty great draw. So it's both, it's sort of the answer. And I think that balance, right? I always want that bottom up. I never wanna stop someone from trying something out. But I also wanna make sure that if you'd like to, but you don't know where to get started, that I can point you in that direction. So, TELUS has one of the best auspices. Like I see auspices globally, right? Across so many foundations. And not because they are here, but... It's okay, it is. The reason I say that is, they have a very structured way of doing things and not just becoming members in a foundation to kind of just do work, but they are pushing it down to the business units. They're pushing it down to the developers and being the partners to kind of train them, educate them and getting them to the next level of competency, right? With webinars and speeches and whatnot, right? So, if you do that, that's when the culture change happens, right? We see a lot of other companies who join. They have five people who contribute and then those five people contribute, no problem, but it doesn't penetrate to the entire organization, right? So, you're moving a small boat, you're not moving the ship. And I think that's what ASPO does. So, clearly, we can see that, right? Yeah, yeah. I think one more thing. I'll just point back at the slide. We have a core value of deliberate outcome over an output. Now, everyone's a little bit guilty if you're a developer of some resume-driven development. You just want to try something out. But this is a real value of you don't just build something because you get a hand. You're building it for a reason and that's also really helped that as well. So, even if it's not my preferred stack, if you're delivering an outcome that makes things better for a customer, go for it. And that really opens up that world. How much of Talus is focusing on open versus open source? Because in open cases, right, you can bring your vendor partners with you to which ultimately helps the open source community. Yeah, I think that's a really good question. I don't know that I have a great answer. I don't know if it's on a few. I have a good answer because recently the discussion sparked in one of my town halls last week when I was in Toronto and people were fighting about the idea of open-ran. So, what do we want from open-ran? We want from open-ran openness. Is it open source or openness? What is it? So, the current offers that we have on the open-ran right now are all extremely closed because it's just one vertical solution in the open-ran which is supportive of the open-ran interfaces right now but it's essentially coming from maybe single suppliers at the moment which proves that the open-ran is a closed-ran. So, we had a big debate about that and we were saying, what do we really need? Do we care about the openness or open source? I think both. By openness, we mean that we should have commercial models that can actually go to the situations of win-win like not get black boxes to which they will charge heavy professional services but actually allow us to operate and allow us to build on top of it. That is openness, it's not open source but we need that. We need that collaborative behavior in which our wins can be their wins and we can shift those terms of agreements with them in which they write more software to drive value rather than just write software once and take money on it forever. Like, that's not gonna happen. So, that is openness. Probably, we need both. Openness and open source. Maybe our pit add more to the open source terminology. Actually, this is a very good question and it is actually relevant in the context of ran more than anything else because if you look at the SDN world, what did we try to do? We tried to say, what was the mission? I wanna buy hardware separately from software. First part of open. Then we say, yeah, but what if I have open flow? Then I can buy control plane and data plane separately. And so that went on that way and then everything kept opening up all the way to the stop of the stack. So, the way we have looked at it and US government actually and Oran Alliance and others have been very active on this is attack the problem in phases, okay? Because on the ran side, like if you look at the Oran open source software penetration on the core, there's huge amount. I mean, you can practically get almost everything open source. On the edge, 50-50, okay? On the access, 90-10, okay? 90 is still closed. So the way we are attacking this is in stages. Minimum requirement, the bar is open APIs. So O1, A1, E1, all the interfaces specified by Oran Alliance better be open, meaning I can interchange modules from different commercial players. The insides of those are still closed, okay? But that's a minimum requirement, right? So open interfaces, step one. Then you get to open source. So out of the seven components from Oran that exist today, if you look at the architecture, right? Four of them are open source. SMO is possible, RIC, NFVI, O-Cloud, right? Those are possible in terms of open run, right? Oran SC is there, the ONAP based SMO is there. There's projects inside ONF that do this, et cetera. So we can start using that. CUD, are you? No, okay? And are you? Absolutely no, right, hardware. So there's work going on in research and in the Alliance and with Lennox Foundation on how to get there. We're not there yet. So for that, I think the organizations, like the end users are trying to keep it to at least get us to the APIs, because that allows the mix and match and get the first step going. Okay, I know it is a long answer, but I know this is a very important. That's the next one year. We'll see a lot more focus. Just like 10 years ago, we did the SDN. This is now SDN on the RAN side. The comment was you will need a lot more automation and a lot more interoperability as you keep breaking us down. The right answer is yes. That's where the blueprints come in. That's where solutions come in. That's where interface testers come in, right? The testing environment is very important. Yes. Yeah, I remember my GMP last day. So I had O and I, or Sienna. Okay, so the comment was this is why open specifications, open testing, all of those have been always deemed important by the open source community. So keep in mind, high-level open networking and then you have open APIs, open interop, open testing, open scripting, open documentation, and then open source software, right? So it's not always open source, but you want to show a journey to that. Great question, yeah. Yep, go ahead, please. Oh, backstage, absolutely. Yeah, I just, yeah. Can you share your use case with backstage? Yes, I think the easiest way is backstage is a pane of glass onto software tell us. So I want to know what exists. I want to know who owns it. It allows us to interconnect. It itself doesn't really own anything, but allows us to see and connect a whole bunch of other tools. I found it a really great way to be as an interconnect between a variety of SaaS tools to be a variety of our own work. And so it just lets us know who owns it, who shipped it, who's accountable to it really again. It's also a great source of entry for documentation and other uses. So we've added things like a status page, so you can get a status of all our systems in our backstage view, because you're going to be there anyway. Right now we're actually experimenting with using that as a lightweight way to do release management. So because we have, we want an audit trail, your works in GitHub, we already know you're there, push button, we keep starter templates, right? So if you, it'll set up your repo, it'll set up permissions in your Google project, we'll do it all. And so the goal is to have that increasing sort of focus point of, you know, sort of a homepage for a developer. It's a great view for, if you care about reliability, you can get an aggregate report on everything. And just to sort of reflect reality. So just be that pane of glass on what the work is happening. Both. So we have built our own plugins, we have used plugins, we're not using their paid plugins, but we both use third-party plugins. We've contributed back to third-party plugins and we've built our own that we've contributed out. So I'm a big fan of backstage for particular use cases if you're so inclined. Okay, thank you very much.