 Okay. Hello everybody, welcome to the lightning talks at foster. I want to introduce Charles with a talk about open source killing standards organizations or saving them. Okay, well thank you very much. So yeah, my name is Charles Echoll. I work at Cisco. I'm a developer advocate there, which means I get to work with developers. A lot help them understand our APIs, our integration points. I'm also a developer myself, so that helps in that role. Within that space, I deal a lot with open source and with standards and really where Cisco is contributing significantly to open source projects or where we're helping define new internet standards. And then we're using those open source projects in our products and solutions or adding support for those standards within our products and solutions. And to me that really serves as sort of an API or an integration point, right? Because you can work with us in those communities and the standards and the open source. So I kind of very passionate about not only open source, but also standards. And so I have a bit of a bias here in terms of this question. Open source, whether it can or is killing standards or helping them. I think typically when we think of standards and open source, actually most people don't think of them together. However, I do. I don't see them as being opposed. I don't see them as being really close friends maybe at the moment. But what I believe is that they should have a really good relationship together, that they can actually help each other out. And by bringing open source and standards together, I believe it could be mutually beneficial to both communities. So why standards? I mean we're here at an open source conference. Why do I talk to you about standards? Well, I deal a lot in the networking space, working for Cisco, a networking company. And standards have really played an important role there for many, many years. It's really our customers, they demand standards, standards compliance, so vendors are really pushed to support these standards. And we tend to work together quite well actually to define new standards, a little bit like people coming together in an open source community. And that's really kind of driven the market and how well you define and support the standards has really been key there. Now, the standards process, for those of you who aren't that involved in it, the way it's tended to work over years is that it takes, unfortunately, usually a couple years at least for a new standard from the time. You start working on it till the time it actually gets completed. Then companies go off and finish adding support for that into their products and then take them to market. And then you have these products from different vendors that support the same standards but don't necessarily work together because they implemented the standards a little bit differently, they interpreted them differently. So then there's an interoperability period because that's really the goal, right, is to have interoperable solutions. And so then there's some time that we go through that. And eventually it's great because we get interoperable standards-based solutions out there. But the problem is, as you may have guessed, it takes a lot of time. And that time was something we could afford before, but with the way kind of the pace of technology is increasing, that's become more and more of a problem. So then open source on the other hand, we see open source coming in and transforming complete industries very, very quickly. Certainly in the networking space, this has been the case. There's just a vast community that we see here at FOSDEM, right, when people come together, can actually innovate and come up with new solutions very, very quickly. It's very, very agile. The pace at which people work together and move things forward is really, really fantastic to see. And just some examples on the right-hand side, you know, Open Daylight was probably one of the first ones in the networking space that I was really familiar with. And there's been others, OpenStack, OPNFE, I've seen talks about that. More recently, a lot more attention to Kubernetes and FDIO really changing the way the networking industry works. And this is a great thing to see. However, there is some complexity to open source and open source-based solutions that I think the more standards-based solutions probably dealt with a little bit better. When you're putting together a solution based on open source, it's usually not like you just take one project and it does everything for you, right? You need to put pieces together and there's some system integration work that's needed. And sometimes that's really, really complicated because these open source projects are moving on different directories, different paces. There's different goals of the different open source projects. They're not necessarily looking to work well together, although that's what perhaps you as a system integrator needs. So, you know, that can be very daunting not to mention the fact that oftentimes there isn't good documentation to help you with that challenge. So there are some things I think with open source that tend to be a bit more difficult, especially when you look to take things into production. And if you think about the environments in which these standards-based solutions really play, that's usually the case. So, you know, my belief and hope here is that by bringing open source and standards together, we can really get something better than just the combination of the two, that they can each help each other out to make each other more relevant and stronger. The idea being that if we are implementing code at the same time that we're developing those standards, we could really cut down that integration time in that kind of ambiguity time of us looking at a spec and implementing it differently. We can find holes in a standard well before it becomes a standard. And maybe more importantly, we also have some code that we can put in the hands of developers to help them start implementing the standard. And in the best case, even be using the same code to support the standard in multiple different vendors' implementations, right? Because then it's going to work much better together. So there's a lot we can really gain by bringing these two, you know, communities together and working more closely together. So one example that I want to talk about a bit where I'm quite familiar is with the ITF. And the ITF stands for Internet Engineering Task Force. Really historically has been, main purpose has been to define all of the protocols on which the Internet's based. And I think we've benefited from all the great standards that have been defined there over the years. And networking standards are no exception. That's a key focus area for the ITF. For those of you in the networking space, some things, you know, TCP, IP, DNS, HTTP, TLS, these are things that you're probably using every day, even if you're not a system administrator. As an end user, you're certainly, you rely on these protocols every day for your access to the Internet and things that you do. All defined within the ITF. So the other thing is on the right-hand side there, we reject Kings, presidents voting, believe in REF consensus and running code. For those of you not familiar with the ITF, but with a mindset or some thoughts of what a standards organization might be like, that may not be what you were thinking it would be like. You might think like big corporate membership fees. The ITF is actually very open. There's no membership required. You participate as an individual, much like an open source. And there's a lot of collaboration. You can see REF consensus being the goal. The whole nature of it is for people to work together. The problem, however, is I'd say within the ITF was there was a bit too much focus on this REF consensus and arguing over drafts and not as much of an emphasis on running code even though it was in this kind of motto or charter, people kind of strayed away from that running code aspect. And that had some real problems. What was happening in the ITF was things were very slow as I talked about earlier, very slow to develop. The community of people working on these things tended to be the same people that was working on them 10 years ago. People coming out of school who were talented network engineers and developers didn't really find it an exciting field in which to work, you know, this slow standard stuff. So they weren't getting involved. So that tended to make things go even slower and being done by fewer people. And, you know, maybe this was a good thing. Open source I think in many cases started to overrun the pace of the networking standards just because we had open source solutions that people were developing to their problems quicker than the standards could be finished. So even if the standards may have had the promise of resulting in a better overall solution, it just wasn't available in time and therefore, you know, what wasn't relevant, right, wasn't useful. So what ended up happening then was starting these ITF hackathons. And the goal there was really to advance the pace and relevance of ITF standards. And the way to do that we thought was let's get more code. Let's get more software developers. Let's implement things as we're standardizing them. Let's test things out before we go too far down the standardization route. Let's find problems early. Let's bring what we learn from coding a draft back into the working group and say, yeah, this works great. No, this is a problem. These are things that were ambiguous to us and we had to guess. If we can bring that in to the working group, then we can really reduce the amount of time it takes to arrive at a full standard. And not only that, but at the time that we reached the full standard, we have a lot of useful code that we can leverage to help with adding support for those standards into products and solutions. Things that are very handy to developers, right? And in the ideal case, we even get a lot more developers involved in the standards process from the start. And that grows the community. It makes this whole interaction between open source and standards much easier and much more natural when you have the same people working in both communities. Also, these hackathons, they're free to everyone and that really lowers the barrier. They're very collaborative that when you hear hackathon, you often think perhaps a bit more competitive going for prize money. This is nothing like that. It is basically people with an interest in standards working together to try to help the standards progress faster. So it's a very friendly, welcoming, kind of collaborative environment. And what we've seen is that the first one was about five years ago and there were only 45 people there, but they did some interesting projects, enough so that we decided to continue. And the next one was a bit bigger and over time, more and more people have gotten involved to where now the hackathon happens the weekend before, the week of the IETF meetings. We've had as many as 400 people show up. If you think about it, the meetings have maybe 1,000 to 1,200 people. So it's 30 to 40% of the people that are actually participating in the hackathon and writing code the weekend before. That has a profound impact on all the work that the IETF's doing in terms of standards. We're also seeing more IETF work happening in a kind of developer-friendly, developer-relevant kind of way. We're using GitHub. We're putting code out there. We're collaborating on that rather than using, say, some proprietary tools that have been developed by the standards organization specifically for their work. So this makes it much easier for a developer to come and get plugged in and start contributing. There's even a working group now within the IETF to talk about how to use tools relevant to developers more effectively. So it's changing the processes of the IETF so that they are more developer-relevant and developer-friendly. And maybe just one quick example. I showed Open Daylight before as an example of an open source project in the networking space. This is, don't worry if you can't see all the blocks. What I'm just going to light up in green here, these are areas where, at least just by name, they're adding support for IETF standards. You can see it's all over the place. And there's probably a lot more standards involved in other places that I didn't make green. But to me, this is a real great success story because it's showing how support for key standards are all embedded into Open Daylight. And that's one of the reasons for its success and why people are finding it great to use in the networking space is because it's open source yet it supports these key standards. So that's really a case of, I think, a good example that I'd love to see more of. And along those lines, my call to action to you would be to get more involved in this kind of collaboration between open source and standards. One way to do that, the next IETF meeting, it's in March in Vancouver. We'll be doing the hackathon. If you can go to that URL or this is the QR code for it, find out more about it. Like I said, it's free. It happens on the weekend. Maybe traveling to Vancouver is rough for you, but if not, very easy low barrier to attend. And then the next one is in summer in Madrid. So maybe that one works out for you better. So just, you know, the goal there being that in the end we'll make open source more usable by the networking industry because it has support for key standards. And we'll make those standards, you know, more valuable because they're in open source projects. So I think I exhausted my time or I have one minute for questions. Great. One minute for questions. Anyone have any questions or comments? I love either. Have you thought about creating online communities in order to handle that? I mean, I work in the SSID and blockchain space and what happens is people develop stuff and there are no standards and no standards bodies. So I've been thinking about how we can create online platforms which wouldn't be so difficult like arriving in a place and could be more inclusive. Online platforms like for related to the meeting or related to... To create standards to take the things that work in a room of people and translate that into code and create an app. That's part of what, yeah, great question and great thought. I think that's part of what this work is just one piece along those lines of... Here it's using tools that are related to Git and GitHub and to use that for collaborating on the standards. A lot of people are finding that much easier and better than email threads. And one small example, but yeah, definitely trying to move more into that. And virtual meetings are going to become more popular. We're experimenting a lot with that too. Any other questions? I think we have finished. Thank you for your talk. Well, thank you.