 All right, so we'll go ahead and get started. Thanks to everybody who joined us on Thursday morning for the 9 a.m. slot to talk a little bit about open-sourcing communities. We'll try to make it as exciting of a topic as we possibly can. If anybody needs to step out and get coffee, completely understood. We've had to do that a couple of times ourselves. So my name is Rob Wilmuth. I'm a principal architect for Red Hat, focusing in the telecommunications vertical. So this will be somewhat telecommunications focused on the presentation. Alicia? Hi, good morning. I'm Alicia Vella and I'm an assistant vice president at AT&T with the title Inventive Science. So I am in the research organization. So I hope to share some of the experiences that AT&T and specifically my organization has had in open source over its very storied history throughout this talk today. So what are we gonna talk about? We're basically gonna go through a brief history of where the open source movement began, how it got its start, why it got started, little bit about today, where things stand, how everybody's kind of collaborating, working together, what the service provider industry is actually using open source technologies for, what the ecosystem looks like, and then finally, how to actually get involved, what you wanna do, what not to do, how to work within a community ecosystem because it's much different than working in a proprietary ecosystem. So where do we begin and why did this whole thing start? A long, long time ago in a galaxy far, far away, users wanted more control. They wanted to be able to actually look at the code, get under the hood, see how things work, what makes them tick, and really understand and have the ability to influence what the technology is doing. From a training perspective, it's a much better ecosystem to be able to get your hands on things, learn how it works, what makes it tick. Security through obscurity is something that we've all heard of and we've all seen in the industry. This open source movement took that out of the equation. From a stability standpoint, we're at OpenStack Summit. It's on its, I don't remember the release number, but it's been released several times. We've seen the benefits of it becoming more and more stable throughout the releases. Innovation. Again, we're at OpenStack Summit, I think that pretty much goes without saying. So just to tell you a little bit about the history of AT&T with open source, it really dates back decades. If I look back at like the 70s or so, we were giving away UNIX to research and government institutions at no cost. However, in about the 80s or so, we actually were charging for UNIX patches when we actually delivered it. And so it's safe to say that the model for open source within a company such as ours has definitely evolved along with I think the industry as a whole. And so it is really most recently that we've gotten onto the bandwagon of realizing that open source is really the way to move technology forward, to be leaders in an industry, to be able to put our hands around how do you create something that is massively challenging from a technological perspective when you know you can't do it all yourself. No one organization or development group can do it alone. It needs the millions of lines of code that the community can generate and the thousand people days that go into it if we are to be successful. So it's interesting really also to watch AT&T's involvement in this whole push towards disaggregating software from hardware because also historically at the time when we were selling some of this software like UNIX and patches to it, there was also this software and hardware that were competing and hardware manufacturers were producing software products that were bundled. And now we're also disaggregating software from hardware so that we can get to the point where we're here today being able to offer up software to the community. So just a quick timeline of events. You can kind of see that as Alicia alluded to, this has been going on a long, long time. The transition is what we're kind of focusing on today. How do you actually transition from being a standard organization that's working in either a proprietary model or as a consumer of open source technology and look at that transition into being a leader in the open source community or a leader of communities depending on how your organization plans to work. So where are we today? Why are people continuing to do this? Why is OpenStack Summit? Why is the Linux Foundation? Why are all of these things so powerful within our industries? The amount of innovation and the fact that you can actually get something from thought concept all the way into something that is reasonably stable as a code base and as an application is really what is driving this whole thing forward. How do you work with other organizations within your industry and other industries to achieve a common goal? The business process. So what we mean by that is what we wanna do is actually take a look at how individual businesses are leveraging this technology from a time when maybe even just as short as five or 10 years ago we had issues with legal teams that said, no, we can't use open source. We can't have it in our walls. We don't understand it, we don't know what to do with it. We don't want to take on the liability of the risk. So you have businesses emerge such as Red Hat that are actually mitigating that risk by providing these enterprise features, enterprise life cycles around it and really giving you the value that comes along with open source. As far as popularity goes, you know, again, we're at OpenStack Summit. 325,000 plus project on SourceForge, 10 plus million in GitHub. We're actually seeing situations where there are so many different projects that there are actually project consolidations going on. Trying to figure out how do these two things, even though they're just about the same compete, why not just merge them together? Let's go ahead and get all the resources focused on a common goal. So one of the other notions that we're finding is that a lot of these technologies are actually landing in key areas, whether that be cloud, applications, systems management, networking, storage, infrastructure. And then we're seeing different things kind of fall out of those that bundle them together and give you everything else that you're actually looking for as far as a business process and business design. So another thought that I'd like to introduce is the idea that there are actually multiple different types of communities even within an individual project. If you think about it, you have this upstream development community that is separate, not necessarily mutually exclusive, but separate from an enterprise community where the goal is to get things stable, performant, but not at the cost of bleeding edge brand new features. And then you have somebody like AT&T that is kind of in that gray area, blurring the line a little bit, trying to do pretty much both of them. That's right. We actually recently decided that it was obviously very important to be able to contribute back into the community, not just be consumers of the open source technologies. And so that means we've had to really shift the way we appropriate our resources and the work that they do. So we've actually hired people who sold job it is to upstream into the open source community because we recognize that that's really the best way that we can help lead and change the industry and contribute to that open source community and be a good partner there is by having people that are dedicated to that. Otherwise, if you start to have that same individual do upstream but also take care of the business and develop the AT&T, in our case, specific services and technologies to deliver our services, that's gonna be very difficult and then the upstream process will just become slower. So we recently decided to really build up a team of folks that are dedicated to just doing that upstreaming. We then have, obviously we also want to ingest what's out there in the community and so we have also processes for ingesting what comes out of the community and then adding the secret sauce if you will of what we need to then develop that enterprise grade services and products that we need to offer. So we've made a conscious decision to really dedicate resources to the upstreaming process and then have good processes in place to ingest that technology back in at the secret sauce so that we can give the customers the services they need. The other thought from this particular notion is I get asked all the time, hey Rob, the community's not doing what I want them to do. How do I actually get the community to do what I want them to do? Well, the short is you don't. Just because your company or your organization or you personally have paid in to a Platinum membership or made this investment with engineering resources, whatever that may be, it doesn't necessarily entitle you to come in with an iron fist and say, no, this is how it's gonna be, this is how it needs to be. If you look at an organization like Red Hat, for example, we are Platinum sponsors or the primary contributor to tons of different projects. And at the same time, obviously I would love to be able to tell my customers, yes, you can have that feature on such and such day because we are the primary vendor involved but at the same time, we still have to be good community stewards. We still have to be good community citizens and actually let the community find its own direction. Now, if the community's about to do something that's gonna cause a fork or something along those lines, yeah, we'll step in and try to mediate but we actually have individuals within Red Hat's payroll very similar to what AT&T was just describing, what Alicia was just describing, that their entire job is to work in the community and make sure that the communities are staying together. We have community managers that is an entire team at Red Hat that keeps all of that rolling and keeps it all together. So what you'll find is you have this upstream community and then somewhere in the middle, you've got to take what's coming out of that upstream community and get it ready for your enterprise environment. You have to make sure that everything is validated, make sure everything is tested. If that's not gonna be your organization like Red Hat provides that value, shameless plug, you're in a Red Hat given presentation. If you didn't expect that a little bit, I'm sorry. But by the time you get to deploy, you wanna make sure that everything's pretty well where you want it to be. You wanna make sure that you're not injecting source code straight into your production environment unless it's to fix a critical bug or security updates or things like that. So a couple of things to keep in mind. Open Source Lock In does in fact exist. Just because something is open source does not necessarily directly equate to open standards. I see a lot of heads nodding. Sounds like some of you have some lessons learned here. The other thing to keep in mind, especially when it comes to open source is just because you can do something doesn't always mean that you should. I guarantee you that everybody has attended at least one containers talk or seen something on a big screen involving containers since you've been here. If you haven't, where were you? That being said, you're not necessarily gonna always try to cram an Oracle database in a container. Again, just because you can doesn't necessarily, well, that's a whole different conversation that probably will need to involve alcohol. Open Frameworks and Open Standards do lower the burden of this concept, but you can still get roped in. There's a lot of organizations that I've worked with in the past that actually jumped to OpenStack too quickly. They really needed something that was more of just a framework to manage their virtual environment in because somebody had heard a buzzword somewhere, they jumped in with both feet and now they've put all this investment in, now they're kinda locked. So you have to make sure you have a plan just because something's in the open source community doesn't mean just go grab it and start using it immediately. The other thing to keep in mind is that as open source innovation continues pushing forward, your legacy environments are still gonna be around. Anybody who thinks that the idea of containerization is going to reduce complexity in your environment is probably not terribly accurate. That's the nicest way I can put it. We know that there are legacy Unix systems laying around that are still generating revenue that you don't know what to do with because the guy who wrote the application left. If that doesn't resonate with you, I don't know what does. So you still have to make sure that as this innovation drops forward, you can manage everything in your environment in a cohesive manner or you at least have a plan around it. If you don't have a plan around it, you're gonna flounder a bit. So again, we're both focused on service providers. Sorry. Realistically though, this applies to pretty much every industry out there. This is one of those more market texture type things. In 2016, this was the survey of the top four things that everybody was trying to do. Open source, being in a community, being a part of a community and being able to allocate organizations to these communities is something that is going to help with these four things right off the bat very, very quickly, very, very easily. So everybody's gotta evolve. And one of the big evolutions that we're seeing is organizations such as AT&T moving from a primary open source consumer model to an actual open source leader model and an open source contributor model. Yeah, so one of the things I wanted to share with you was some of the trends that we were seeing as a company coming along that really inspired us and motivated us to join in the open source community. And that was really the level of network data traffic that we were handling. So since 2007 till today, we have had an explosion of 150,000% increase in that network traffic. We handle on our network 117 petabytes worth of data a day. And we realized as a company that in order to keep up with the enormous demands of our network, we needed to be innovative, we needed to innovate quickly, and we knew we couldn't do it alone. This kind of scale that AT&T is dealing with required massive collaborative effort, the kind of collaborative efforts that exist in an open source community such as OpenStack. And so that's when we made the deliberate decision to go the software defined network route, go the network virtualization route and choose to use OpenStack as our foundation for creating our AT&T integrated cloud environment for which we can then deploy our network functions and create the services that we want to be quick in terms of technological innovations to meet these customer demands and to do it at scale, because that's also very important. And so we used OpenStack to build out our AT&T integrated cloud as a result last year. We won the OpenStack Super User Award of which it was a great honor to have that happen to us. And it's a testament to the team and to the communities for that work. We're also a large contributing OpenStack operators group we're a member of that group as well. So we really take this notion very seriously of not just being consumers of the open source community but contributing back into it. We understand the importance of that because we cannot do it alone. As I said before, no organization could do it alone. If they try to, it'll be suicidal. And so we've really made a concerted effort to move in that direction. I don't know if this is where you'd want me to talk also about ONAP or a little later on we'll save that. Yeah, go for it. Okay, go for it. Okay. So the AT&T integrated cloud is more of an example of where we were predominantly initially big consumers of the open source community and we're kind of now making upstream contributions. But a few years ago, we also in this whole push towards software defined networking developed a platform called ECOMP, Enhanced Control Orchestration Management Policy. It's a mouthful. And think of it as a network operating system for developers to build network applications. That's what ECOMP was. And we developed it. We, our own folks internally, we put it into production. It's been in production for about two years. And then we realized that again, we can't do this alone. This has become bigger and the interest for it has also evolved. We were getting other service providers and systems integrators asking us to open source it because they also realized the value of being able to use this to help jumpstart their involvement in the SDN and NFE world. And so we in fact decided to do just that. And the team was told that we were doing this sort of in the fall of last year and we just released it into open source in April. So you can imagine the teams were, they couldn't believe the timeframe we were given to do this. And there were definitely some lessons learned from that experience. We have since deployed it. And we had internally called it OpenECOMP but then we partnered with OpenO. So this is an example that Rob was mentioning earlier about projects coming together. So ECOMP and OpenO got together to form ONEP. And that is the Open Network Automation Platform. You can look it up, you can become members, you can contribute, you can use it, you can download it. There's real source code out there. In fact, more than five million lines of code that we put out there in ONEP. And we want it to be a healthy, vibrant community. It's the only way we're going to affect the industry. But lessons learned for us in that process, not just the fact that we were wanting to do it quickly and get it out there fast. But remember I said that we started this as an internal project, which meant that we didn't think about open source from the get go. And I think it's very important when you're thinking about doing something kind of big. That you think open source right from the beginning. That the code is written in such a way that you can put it out there very quickly that you don't have a lot of proprietary service-specific guff in it. Because that'll just make it that much more difficult to disentangle it. So we had a little bit of disentanglement that we had to do in order to put it out there so that we would take out stuff that was service-specific. So that was sort of one lesson learned. And one of the other things that is important for any corporation that wants to put things out there in open source is to have a process that makes that easy. We've had a process for open sourcing for as long as I can remember. And I've been with the company for 22 years. There's a simple process for anybody who wants to open source some technology. It's basically a template, you fill it out, your manager approves it, it goes to legal, they approve it, it's very simple. That's also a way of encouraging folks to contribute to open source. So we've had now the experience of being big consumers of open source, wanting to contribute back, merging open source projects together to help lift the industry so that we can keep up with the pace and the demands that our industry is demanding. So most of this shouldn't come as a surprise to interview, but just kind of a quick recap of who's actually consuming this. You're gonna find open source pretty much throughout your entire organization, or you can't, depending on how you proliferate it, how it looks in your environment. If you take an organization like AT&T, you basically can't go anywhere without hitting some type of open source combined with a proprietary solution somewhere in the mix. What use cases, pretty much everything. We're seeing SD, well, software defined just about anything. I mean, I'm pretty sure somebody's gonna come out with a software defined shoe in the relative near future. So what is being used, how is it helping? These things range from very simple monolithic applications, doing internal IT functions, whether that's some type of HR system or just your internal corporate email, all the way up to things that are incredibly complex, chained microservice applications that are providing core and critical business functions. We're seeing them in pretty much every industry out there today, from railroads, financials, telecommunications, to the mom and pop shop down the street that happens to have a website with an Apache server running in the guy's basement. I've definitely been that guy before. So what actually makes a community work? It's not just the fact that a whole bunch of people will get together and say, hey, let's write some code and then we're all gonna use it. It's the fact that every single member has a responsibility to not only use that code, but also report back their findings. If you don't have a heavily technical organization where you don't feel like you could be a contributing member from a code perspective or an engineering perspective, that's perfectly fine. I am personally not an engineer that writes code. You don't want me near your code. I promise I've seen me try it. It's bad. That being said, I do have experience doing documentation for upstream and open source projects. So getting involved, doing a quick YouTube video or how to, my work here at Red Hat has lent me to how to get involved if you're not a technical user. We have a lot of people within the company that are very passionate about things and wanna get involved, but may not necessarily know how. So grab a piece of software. There's a couple of, for my personal stuff, there's a webcam monitoring solution that's open source that happens to run on a laptop sitting at my house so that I can buy dirt cheap webcams that are like 30 bucks, and then I get an enterprise solution out of it because the open source software is behind it. So what do I do? I do the documentation on the cameras. To make, basically I grab a camera that nobody has ever tried before and say, okay, does it actually work? Half the time it ends up going back to Amazon. But then I can mark it off the list and say, no, don't buy that one. So there's a lot of different ways to get involved, both on a personal level as well as on an enterprise level. What you really wanna do is tend toward the consume, test, and report. If you don't have the capability of fixing it, at least making sure that somebody knows that a fix is necessary, whether that's something as simple as a configuration error in the documentation or something as complex as the whole thing broke and now my wife can't watch Netflix. So are they successful? I believe, given the fact that we are all in this room today, yes. Yes, the answer is yes, and yes again. And when I was preparing my thoughts for today's talk, I was trying to think about what is sort of one, one reason why you or companies such as large or maybe as 18-tier smaller, should get involved in open source. And one thing came to mind and that is complexity management. That was sort of the term that I thought kind of captured what we're trying to help with open source and getting involved in it. From my perspective at AT&T, we have this enormous customer base. We have the complexities of having to deal with reliability constraints that are very strict. We have customers that are demanding innovations constantly. We have that big network data traffic that I mentioned. And we must be able to contribute and consume from the open source community in order to gain all the eyeballs that are looking at that code, all the skill sets and the resources that are available out there. We have a certain amount of resources and we have certain people with certain skill sets. And we make sure that those resources are appropriated in the right areas, but we don't have all of it. And so coming together as a community to contribute helps everybody to reduce their complexity and in the complexity of building these large enterprise grade sort of systems, or even smaller ones for that matter. It's always a good thing to have other eyeballs looking at it. I was recently talking to one of my colleagues and asking him about open source and why that's important and he prides himself and he is an extremely good developer. And he will admit that even though he might think that his code is really, really great and that he's gotten and plugged in all those security holes in it. When he puts it out there in the community, somebody will undoubtedly find a hole in it. And that's one of those beauties of being able to participate in that open source community. You have that, that somebody else is looking at over you and somebody is also keeping track of your back. And so from that perspective, it's very important to continue to evangelize the collaborative efforts that are required of building the kinds of services and systems that we want for the future. So a little bit about ecosystems. One of the things that we've seen a huge trend with recently is not only enterprises getting involved in open source, but also these partner vendors, the people who are actually providing the solutions. They're building their solutions either with open standards on top of open frameworks. They are leveraging not only Red Hat's open source, but AT&T's open source to try to provide best of breed solutions that are customized to industries and to other organizations. The real interesting part is when you get in some of these organizations and you find that your competitor is actually working on the exact same project at the exact same time. Red Hat does a pretty good job of playing Switzerland in a lot of these arenas. But even we end up with OpenStack's a prime example. We have other competitors here doing talks. I mean, you're little lanyards, obviously. So based on that, you have to understand that within these communities you want everybody else to be successful too. You just want to be able to do something slightly different with it once it's come out the other side or you wanna provide a different value or you're trying to do something ever so slightly tweaked to differentiate yourselves. So what are we actually paying for? So when you buy a commercially available open source based solution, you're not necessarily paying for somebody to say yes, you can have whatever feature you happen to want. It doesn't work like that. What you are paying for is the engineering services. You're paying for the stability. You're paying for the scale. You're paying for the additional consulting services. You're paying for certifications because those are the types of things that you do need that third party organization to come in and provide above and beyond just a piece of software or an application that is going to end up running in your infrastructure. So how to get involved? We've already talked about a few different lessons learned. Now let's talk about the lessons learned of the first time you actually stick your toe in the water and say, hey, this is a new community. I'm gonna do this thing. I'm gonna join the mailing list and I'm actually gonna respond to somebody. So we already talked a little bit about the actual model of consume, test, report, fix, et cetera, et cetera. So try something new, respond to somebody. Worst case, you're wrong. The best part about being wrong in an open source community is somebody's gonna correct you really, really fast. Engineers hate it when somebody's wrong. I will actually admit that occasionally I will respond to somebody and be ever so slightly wrong just to get somebody else to correct me and give like 17 more paragraphs of detail than I ever could even come up with. It works really well, just don't do it a lot. Give feedback. If you're not giving feedback and you're just consuming and something doesn't work, it's never gonna get fixed. You can't assume that somebody else is gonna do it unless you see a bug report already open and then you can flag a me too on it and at least they know somebody else wants some help as well. Be open if possible with how and why. Obviously your organizations have, treat cigarettes, enterprise, security, things that you have to keep close to your vest. But if at all possible, if you can give additional detail about the use case that you're trying to use, what you're actually trying to make everything do within your environment, that's gonna be tremendous for the developers and engineers going forward. Don't fork the code unless you have a really good reason. We're seeing so many projects out there and we're already talking about the consolidation of projects. We already talked about one example today. If code continues to fork and people end up on separate streams, it becomes incredibly hard to maintain those separate streams, especially when you eventually, potentially want to bring them back together. Remerging a set of forked code is incredibly hard. Red Hat helps our customers do it all the time. It's never simple. It's never a one-off. It's always, okay, we gotta bring it back and then we continue finding things that got tweaked ever so slightly in the process. And then do definitely engage with the community, even if you're just monitoring the mailing list on a weekly basis. It could be a project that really only has a couple of updates a week or it could be something as big and powerful as ONAP or Nova or Neutron or Open Daylight or something like that where just keeping up with the mailing list could potentially be a full-time job. Any closing thoughts? Yeah, so there was one thing that came to mind when we talk about open source and I've gone through several talks here at the OpenStack this week about culture in an organization around open source. And it's very important, especially in large organizations like the one I'm in, to get alignment from all of the senior leadership and management members of the team, rallied around open source, making sure that they're educated and understand the value, the business proposition as well of getting engaged and involved, especially if you haven't done so before. It's important to get that buy-in, that realization because you're gonna need their support as you go through this process because as you've heard already today, it's not easy. It does take effort. But, and so you need that understanding and support from senior management. So that was just one thing I wanted to put out there because it's certainly something that I spend a lot of time doing is just doing that kind of education internally within the organization. So finally, I think in closing, I would say that it's, for us, it's certainly been imperative to get involved in the open source community because we can't really take on the level of technological and industrial undertakings that we have been taking on over the last several years without getting involved in the open source community as contributors, as partners with folks like Red Hat and others. It is a must if we want to innovate in this technologically fast-paced environment that we're in today. Okay. Awesome. That pretty much wraps it up. I appreciate everybody attending. If you've got any questions, don't hesitate to approach us afterward. Thank you. Thank you.