Uncover the Missing Link
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61983 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2023122 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
Standard deviationMereologySinc functionOpen sourceBitProcess (computing)Open setGroup actionComputer animation
02:01
QuicksortGame theoryMedical imagingGoodness of fitRight angleSimilarity (geometry)Source codeComputer animation
03:11
NumberImage resolutionStandard deviationProduct (business)SoftwareMultiplication signOrder (biology)QuicksortVariety (linguistics)Different (Kate Ryan album)TelecommunicationResultantSingle-precision floating-point formatConnectivity (graph theory)Computer animation
05:15
Standard deviationFile format1 (number)ImplementationStandard deviationMultiplication signWindowDifferent (Kate Ryan album)MultiplicationBitMereologySet (mathematics)Computer animation
06:39
EncryptionOpen sourceView (database)QuicksortDifferent (Kate Ryan album)Point (geometry)SoftwareStandard deviationDynamical systemProjective planeTransformation (genetics)Group actionMultiplication signProgram flowchart
09:40
Open sourceComplete metric spaceUsabilityStandard deviationCodeComputer networkInternetworkingCommunications protocolTransport Layer SecuritySession Initiation ProtocolDynamic Host Configuration ProtocolSoftware developerProcess (computing)Uniform resource nameDisintegrationFreewareStandard deviationRevision controlCodeFeedbackElectronic mailing listEmailPoint (geometry)Open sourceIntegrated development environmentForceBitParallel portMultiplication signIterationWeb pageProcess (computing)Sheaf (mathematics)Vector potentialVapor barrierGoodness of fitGroup actionSelf-organizationSoftware developerInternetworkingINTEGRALInteractive televisionArithmetic progressionCollaborationismAreaFile formatLevel (video gaming)Set (mathematics)Communications protocolDifferent (Kate Ryan album)Projective planeSpacetimeSlide ruleSoftwareMereologyImplementationCharacteristic polynomialComputer animation
18:46
Software developerFreewareStandard deviationGroup actionExecution unitCodeMaxima and minimaComputer networkLink (knot theory)WikiInformationExtension (kinesiology)Polygon meshTopologyRepository (publishing)Identity managementGUI widgetImplementationLatin squareReduction of orderInternetworkingAbstractionData typeInformation managementLocal GroupAdditionUniform resource locatorFile formatFlow separationRoutingDataflowSystem callComputer fontProcess (computing)Software repositoryProjective planeConfiguration spaceType theoryQuicksortInformationTheory of relativitySoftwareMereologySlide ruleAdditionCommunications protocolStandard deviationSoftware maintenanceBitPoint (geometry)Multiplication signStress (mechanics)CodeSurfaceOpen setRight angleMedical imagingWritingWikiOpen sourceImplementationCASE <Informatik>Link (knot theory)Entire functionLattice (order)Greatest elementSelf-organizationInternetworkingComputer animation
27:52
Computer networkOpen sourceCodeInternetworkingCommunications protocolTransport Layer SecuritySession Initiation ProtocolDynamic Host Configuration ProtocolImplementationQuicksortStandard deviationCodeBitPoint (geometry)Open sourceMultiplication signConfiguration spaceoutputProjective planeMultiplicationExterior algebraSelf-organizationProof theoryComputer fileDemo (music)SoftwareComputer animation
31:27
Program flowchart
Transcript: English(auto-generated)
00:05
Charles. Okay. Welcome. Thank you. Great. We get some applause for Charles, please. Thanks for that. Thanks for being here around the lunch hour, too. I appreciate your making a little extra sacrifice, and just thanks for being here as part of the community
00:25
dev room, too, right, and contributing to the discussion here. First, a AV question. Can you hear me okay? Is the audio is all right? Okay, great. Okay, so super excited to be here, and especially because I get to talk with all of you about two things that I'm
00:43
extremely passionate about. The first one is open source, and since you're here in this room, I'm guessing there's a very good chance you share that passion with me. The second one is standards. I really enjoy working with standards. It's a big part of my job. I'm in the standards group at Cisco.
01:04
Hopefully some of you consider yourself a supporter of standards, but all right, we got a few. And what I really want to talk with you about is what I think is an opportunity for the standards community and the open source communities to work a bit better together and to help each other with
01:25
navigating across those communities, because it is very common for for many people to really primarily associate themselves with one community or the other. So anything we can do to help the other community better understand what we're doing, how we're doing it, how to leverage the resources
01:43
we have, I think is very helpful, and that's the subject of my talk. To uncover that missing link, the linkage between all the great things we're doing in open source and the great things we're doing with standards to the benefit of both communities.
02:01
So I was a little late watching this, but I imagine many of you saw Game of Thrones. Is this a familiar sort of image to you? Even if you didn't, the idea is there's on the left-hand side, I guess to your left, yeah, you have Jon Snow. He's leading, he's kind of the lead of the people of the north, and then on the right you have this guy, big guy, Tormund
02:25
Giantsbane, and he's kind of one of the leads of the the wildlings that are even further north. And those two communities are separated first by a very large wall, and they really don't trust each other. They don't understand each other.
02:45
However, during the course of the series, they come to understand each other a bit better and find really some common goals that they have in mind and to work together and to achieve some greater good. And
03:01
I think there's some similarity there with open source and with standards, where by working more closely with each other we can really benefit each other. So first of all, why standards? Why do I think standards is important here? And I think for most industries,
03:23
standards have really played a key role for many, many years. Large players in those industries, they, you know, whether you're talking about telecom or networking or communications, that it's really, it's mandatory to support a wide variety of
03:41
standards in order to to solve equipment or solutions to provide those into that market. You know, and compliance with these standards is important for a number of reasons. And two of them that I want to call out is for interoperability, so that when you have
04:01
components from many different vendors, you can actually get them to work together. And also just to make sure that you never get stuck with a single vendor lock-in where, you know, once you start down the path, you can never use anything from anyone else without prohibitive cost or churn. And as a result of this importance of standards in those industries,
04:23
fierce competitors come together and actually collaborate quite well on the standards because they have a vested interest in those standards in establishing them so that they can add support for them into their products. And it's also important for them to be able to interoperate because many times they'll be coming in that they have some
04:44
product or some solution that they want to sell into an existing larger solution and, you know, their stuff needs to work with their competitors in order to enter into this new market. They can't get the the person buying their stuff to, you know, start over from scratch, right?
05:04
You need to insert yourself in sort of incrementally into it. And so interoperability is super important there to interop with not only your competitors, but your partners. So, you know, that actually works quite well. However, there's definitely challenges with standards and
05:21
one of the main ones is it can take a long time. Just getting a standard from the time you start defining it in a community to the time it's actually a completed published standard oftentimes can take a few years. And then if you think that now once you have that standard, a lot of companies will wait until
05:42
the standard actually exists before they go off and start implementing it. So that's going to take a little bit more time now to add support for it. And then you go and you take implementations from multiple different vendors and you try to use them together and the interoperability isn't there because, you know, these standards are complicated. There's some ambiguity in how you might interpret certain parts of it or which
06:06
feature sets from them you support and how well. So it takes a bit longer to really get that interoperability that was the goal from the start. And sometimes that will even require going back and, you know, changing the standard.
06:21
But in any case, no matter what, it tends to take quite a long time. And, you know, that becomes a challenge because you may not have your standard already and adopted and deployed in time for it to do the thing that you really needed it to do. You might kind of miss that window of opportunity.
06:41
So with open source, I think we see a very, very different dynamic. We see open source fueling the transformation of industries very, very quickly in many cases. And a vast community of people like what we see here at FOSDEM comes together, you know, around some common goals and
07:03
it really can create fantastic software very quickly. And this rapid innovation is so, I mean, it's a very desirable thing. And so I think these industries that have
07:20
mandated or really needed support for standards for many, many years, they're seeing open source as this great opportunity to speed things up. And so they're saying, well, you also need to support open source. You need to understand how to work with it because, you know, in my network or in my overall solution, I'm going to have equipment from a lot of different people. And some of that I really think needs to be open source.
07:43
So how does your stuff work with these open source components? And sometimes the open source can become so widely deployed that it actually will become sort of a de facto standard, maybe before that standards group ever defined anything in that space, maybe before they were able to complete their work.
08:04
So open source is really bringing some great things, but I think we'd all agree there are some challenges. Open source projects, from the point of view of someone who's trying to build a solution, it's really just like, I think of it as a tool set, right?
08:21
There's a lot of different projects out there, but none of them offer a complete solution. And so then what you need to be able to do is understand each of them, know how to put them together. And you know, these are often open source projects that weren't designed, you know, the people working on them really didn't have
08:42
working with these other projects in mind, right? They didn't design for that. They may not have documented it at all, how to make it work with these other things. Or, you know, that documentation may not be great. The other thing is, I mean, in the open source community, it sort of has a mind of its own, right? So
09:02
perhaps you want to use an open source project in a certain way, but if you're not actively contributing to it, you know, it might move in a way that, you know, you weren't expecting or you weren't wanting. And so it may not ultimately meet, you know, the need that you had for your overall solution. And you know, some projects just fade away.
09:23
The community loses interest and starts spending their time on something else that looks even more interesting. So this challenge of integrating open source together with perhaps some other open source projects or maybe even some proprietary stuff, you know, that's a real challenge.
09:42
So where I think there's a lot of potential benefit is by bringing some of these characteristics of standards and open source together. By those two communities working better together, you can really bring some of that, if you could bring some of that speed and collaborative spirit that we see with open source
10:00
into standards. Actually think about creating open source implementations of standards as they're being developed and then be able to feed that back into the standards and improve the quality of them early on, not after they've been published and, you know, after several years, but actually very early in those, when the first iterations of the standards.
10:24
Then when you do have these standards, if you can add support for them into popular open source projects, then those projects suddenly become much more consumable by the industry that's built these built these big solutions around all these standards, right? Now all of a sudden your open source project can
10:44
can interoperate in that larger environment because it does support these key standards. And then also if you have some code that's being developed that implements, you know, either the complete or parts of the standard, then when the standard is actually ready,
11:02
it's going to be much much faster to deploy it if you already have some running code, right, rather than having to start from scratch, implementing just what was written down on a sheet of paper. So I think you can really have time to, you can speed up the time for adoption by having that code available in parallel with the standard. So just one example where I think helps illustrate the opportunity here.
11:27
This is a relatively, it's a little bit dated slide from the Linux Foundation, but I think it demonstrates some of the points I'm trying to make quite well. This is looking at the network automation space, and on the left-hand side
11:43
you can see that there's a lot of open source projects just in the Linux Foundation alone that play a role in this space. So it's kind of layered from like the networking stack from top to bottom or bottomed up. You can look at it either way. So you see the different open source projects, sometimes several of them, playing at the same level of the stack because, you know,
12:06
we allow multiple different projects that do some of the same things to coexist, right? I mean, that's very common in open source. So you have all these different projects. Some of them you may look at and say, hey, that project doesn't even exist anymore. That's an example that I was saying of, you know, the projects, some of them actually fade away.
12:24
So if you're trying to put together a solution that involves these different open source components, even if you're taking them all from the Linux Foundation, you still have a fair amount of integration that you're going to need to be able to do. On the right-hand side, you see similarly going up and down the networking stack here,
12:45
the standards groups that play a role in that space. Well, I think there's the greatest opportunity for collaboration is going east-west across, right? So standards organizations like, for example,
13:01
IETF and playing at the same level as perhaps an FDIO or an OBS or even with Linux, you start to see the opportunity for something that's being done in the standards area needs to be implemented, probably is implemented, in these open source projects. So to the
13:22
point that you can make that interaction and collaboration across these communities better, you can really help both sides. So as an example where I think we're making some progress here, I mentioned the IETF just a minute ago, and that's one standards organization that I'm involved in.
13:43
It's the Internet Engineering Task Force, and it was created back in the mid-80s with the goal of making the Internet really, all of the protocols on top of which the Internet's built. And now today the goal remains to make the Internet, you know, better and over time to refine and add new protocols that are needed.
14:05
So household names like TCPIP, DNS, DHCP, these things that we all end up using every day, those all came out of IETF. And I think IETF is a
14:20
kind of good example here, and that IETF even behaves a little bit, if you're not familiar with it, it behaves a little bit more closely to an open source community, and that when you go there you participate as an individual. There's no like company affiliation. It's free to participate. Anyone can do that, much like you often see with open source. And this quote on the right-hand side I think helps
14:45
pull that out. You see, you know, we reject King's presidents voting. We believe in rough consensus and running code, and that idea of running code was really important to the IETF early on. I think maybe there was a drifting away from that over time,
15:00
and I see there being a lot of potential in getting back to that idea of running code, whoops, sorry, that that's related to standards. So one thing that the IETF did, I think as a realization that it's
15:22
its processes and ways of working need to change, and to try to make it a little bit easier for developers and the open source community to get involved, is just taking a look at the way that standards are actually written and developed over time, and how consensus is built around them. Traditionally, it's been done using a pretty arcane set of tools that have been built in the IETF over time,
15:45
and if you've been working in the IETF for a long time, you're probably pretty comfortable with writing your drafts and XML, and then converting them into this RFC format. But if you're not, that's kind of a barrier to entry, and so there was actually a working group defined to say, hey, how can we
16:05
make our processes work a bit better to meet developers, to make it more developer friendly? And so this Git working group, GitHub Integration and Tooling, what it did was to find a way that
16:20
IETF drafts could be posted and worked on in a GitHub repo, and instead of using XML and having to translate, it could be written in Markdown, something that many developers are pretty familiar with just from writing their own readmes. And so now the drafts, although they're still just really
16:41
text, but they're stored in GitHub, and you have the version control around them, and you can do pull requests and all that. So really, it's bringing, it's really meeting developers where they are, making it easier, more comfortable, straightforward for them to contribute by using things that the developers are already pretty familiar with. And you can see if, maybe a little small, but when you're looking at, I'm showing you what the
17:07
working group page for the draft, there's a section called Additional Resources, and what this takes you here was a newly defined additional resource, which is the GitHub repo, where the draft that people are collaborating on is stored.
17:23
Another thing that's been done, and this is where I've spent a lot of time, is in running the IETF hackathons. And the idea there is to do exactly that thing that I mentioned earlier of speeding up the pace and relevance of IETF standards by implementing them in parallel with defining them,
17:41
and taking the things that you learn from implementing them and putting them, working them back into future iterations of the draft. So I think that that way you end up with a higher quality standard in a shorter amount of time. But another goal is to, again, attract developers and kind of new participants from, say, universities,
18:03
younger people in general, into the IETF by creating an environment that's a little bit more interesting, perhaps, to contribute. Rather than reviewing drafts and commenting on them on mailing lists or something like that, you can actually use tools and techniques and code and contribute in that way, too, and point out
18:23
where maybe there's a problem in the standard or a better way to do it, but by actually implementing it and using that to help build your your feedback. And these are free and open to everyone and very collaborative. Some hackathons are competitive, but this is really about learning, moving things forward, and improving all standards that the IETF works on. So it's
18:46
non-competitive. And on the right-hand side, I just have a chart. You can see we ran the first one, I think back in 2015, and attracted about 45 people, and I thought that was quite successful. Then a couple years later, after having these at every IETF meeting,
19:04
it's now common to have three to four hundred people at one of these. And if you think of an entire IETF meeting being about a thousand people, that's 30 or 40 percent of the people are coming and actually spending the weekend before it to work on code together, which I think has had a huge impact on the IETF.
19:27
So another thing we did then as a result of these hackathons was, well, let's create a GitHub org, and we can store the projects that we work on in the hackathon. We can store them there. So in case the project wasn't already hosted somewhere else,
19:40
oftentimes we'll put the project in this GitHub org, and that makes it a little bit easier than to find code related to standards, because you can go look in this GitHub org. So at least you find some code that's related to standards. You can find it there. So that helps out a bit, too. Another thing we've done is, if you looked at, we always have a wiki that lists the various projects for an IETF hackathon.
20:06
And this is a good example where they've done an important thing where you can see that the key IETF drafts that the project is working on, there's links to them. You may not be able to read them well, but if you can download the slides, I've uploaded them, and you can see those. And then down below, it's talking about
20:26
where the code is that they're writing. And in this case, it's a GitHub repo. They're working on VPP. It's a network processing open source project, and they're implementing these drafts
20:40
in VPP, which is a great example of the type of thing we want to have see. So right here in their project description, they're showing you the drafts and the code, which is, you know, a nice way of linking those things together. So we made progress, but you know, it's not all
21:00
rainbows and unicorns yet, by any means. And there's, you know, so I think there's, we're just scratching the surface here with what we can do. If I go back and I show you this GitHub org that we have, there's like maybe 20 projects there. It's probably 1% of the code
21:21
that is related to standards that, you know, exist in the open source world. So, you know, it you can get a little bit of code that way, but it's really just a few things. And this wiki, the problem with this is, these, if you look closely, you'll see that one of the draft names has even changed over time. So
21:45
they're not maintained. People use them extensively in the lead-up to the hackathon, during the hackathon, and for maybe a week or so after. But they're not maintained. This isn't really a good way to over time find the linkage between code and drafts. So, you know, I think there's definitely
22:06
things that we need to do to improve. So, what I did was, for those of you who work in the IETF, if you want to improve something, what do you do? You write a draft. So I wrote a draft about more systematically going and creating this linkage between
22:27
between IETF drafts and code that's related to them. And to set up a process that, you know, and so that everyone keeps this in mind when they're writing their drafts, and to point out where to find the code.
22:45
So, earlier I showed this additional information that you could have point to a GitHub repo. What we've done now is we added another type of additional resource, and that's a related implementation. And so now what you can do is, when you're writing your internet draft, you have an idea, you can point to
23:06
relevant code, whether it's an implementation of, say, the protocol you're defining. Perhaps it's a tool that helps you, you know, sniff that protocol when it appears on the network, right, to sniff it on the wire.
23:21
So anything that's going to help with implementing, supporting, deploying, maintaining, operating the standards that you're defining, you can point to them here. And all you need to do is you can go and you can edit those resources, and maybe, again, a little hard to see, but the first one is pointing to the GitHub repo where the draft is stored, and the second
23:46
one is pointing to a related implementation, where, in this case, because this is sort of a process document, the related implementation is actually pointing to another RFC, which is about how to run the hackathon. So maybe not the greatest example, but I wanted to show how you use this.
24:04
Now applying it to a more real-world example, I'm going back to that hackathon project I showed you before that has the links to the internet draft, and then it's pointing to a GitHub repo. So you can see here, I'm looking at the draft here that's highlighted in red, this one on draft IETF,
24:27
ops-awg-ip-fix-srv6, and if I go look at it in the IETF data tracker, I can see there's related implementations defined for it down there at the bottom.
24:40
And if I click on that, it'll actually take me to that GitHub repo. So now I'm not relying on the wiki anymore and something that's not being maintained. Now actually, I'm putting the linkage between the code and the draft right in the tooling that's used to work on the IETF draft. So in this way, it's a much more stable, easier to find
25:03
reference for everyone, whether they knew about the IETF hackathons or not. And so I think that's the type of thing that it's starting to gain traction in the IETF, and I'm trying to get it to be much more common. And perhaps even there's better ways to do it.
25:23
So people can also comment on the draft that I showed before, if they have a better idea of how to do it. So I guess my ask to all of you is, I hope that you see some value in creating this linkage between open source and standards, and that you can help do your part to
25:45
create that linkage. So if you're working for me or others in the standards community, if you're working on Internet standards and you happen to know of some open source code, create that linkage, show people where there's code related to the standards. Perhaps you're working on an open source project, though, and
26:03
you know that project very well, and you know you've implemented some key standards in it. Make sure that that's well-documented in your readmeer or easy for someone who's not familiar with your project to see that oh, yes, you do support these standards, because that might make, hopefully will make your open source project
26:21
much more valuable and easier for them to consume and to use for their purposes. So by making this linkage easier for people to to find and use, I think we make, we can make standards much more consumable by developers, and the other way around, the open source community and the things that we build there become much more
26:47
consumable by these industries that have relied on standards for a number of years. So with that, I thank you for your time. I maybe have a couple minutes for questions still. You absolutely have a couple minutes for questions.
27:02
Excellent, I'm on my way. And I'd also love feedback on the IETF draft. If any of you are like, hey, I want to provide comments on an IETF draft, I've never done that before. This is a good opportunity. Thanks for this pitch. It was really enlightening. I think there is really a link between open source and like standards.
27:26
So my question is, in one of your previous pictures, you were showing like standard, standard, standardizing organization and open source, and I've seen that there was like the image of open config on the open, open source.
27:46
Let's see, not this one, right? No. Oh, I think I know. One of the initial slides you were showing. Oh, this one maybe. Yeah. Yep. So I had recently had to develop something related to the open config group, right, and
28:02
somehow they are also defining a standard. So what do you think about this? I mean, yeah. That's a, I mean, that's a good question. So there's, that's an example of sort of a community that's not traditionally maybe considered an open,
28:22
considered a standards group, but they're defining their own standards within it. And it has been a little bit of a challenge, I'd say, historically, because you had some standards being defined in IETF and kind of alternative standards rather than being argued within the IETF and used to influence IETF standards. It's kind of a,
28:44
standards in a similar space, but being done by, you know, another organization now, by open config. And so I guess in some ways it's similar to having multiple open source projects that are trying to do the same thing.
29:01
So, you know, I'd say the one thing is as long as the open config is open to community consensus and taking input, then, you know, ideally we'd have one set of standards, but if we have two and they, you know, they have different communities working behind them, you know, perhaps they each meet a separate need. So it's not necessarily a bad thing. The important thing is that both
29:24
communities are very, you know, open to input from their members and hopefully they collaborate a bit where they can. So you don't see anything against this? I'd say it's not ideal. Similar to two competing open source projects existing, but you can't always force, you know, everyone. That's kind of the beauty,
29:45
I guess, of open source is you can go off and explore different things. And that's kind of what's happened here is, you know, it's like a fork almost. And whether they come back together at some point, I don't know, probably not at this point, but who knows?
30:02
Okay, so we have time for one more question and I see one hand. Great when it works out that way. Yes. Yeah, thank you for the talk. For these implementations linked to a specification,
30:21
would you preferably distinguish between an implementation and let's say a reference implementation? Oh, yeah. Yeah, great point. That's actually one of the challenges we had in the IETF too, that people thought, I guess one of the concerns was perhaps pointing to some code that is,
30:43
you know, it's just a little bit of a science project or, you know, a quick demo maybe even at one of these hackathons as opposed to something that is a full-fledged, hey, I can go off and use this in my mission critical software. So I think the important thing there is in the readme.
31:00
Haven't really come up with a better solution than to say, hey, you know, document what this is. Are you just getting going? Is this a proof of concept? Is this something that you want people to contribute to? You know, then make sure you have your contributing, you know, file there. So it's kind of just, yeah, letting people know through the readme I think is the best way to go.
31:22
Thank you so much, Charles. Very much appreciated. Thank you.