Charles.
Okay.
Welcome.
Thank you.
Great.
Thank you.
We get some applause for Charles, please.
Thanks for that.
Thanks for being here around the lunch hour, too.
I appreciate you're making a little extra sacrifice.
And just thanks for being here as part of the community dev room, too, right?
And contributing to the discussion here.
First, AV question.
Can you hear me okay?
Is the audio 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 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.
Hopefully some of you are consider yourself a supporter of standards.
But all right, we've 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
other with navigating across those communities.
Because it is very common 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 we have, I think is very helpful.
And that's the subject of my talk.
To cover 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.
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 on the left hand side, I guess to your left, yeah, you
have John Snow.
He's leading, he's kind of the lead of the people of the north.
On the right, you have this big guy, Tormund Giant Spain.
And he's kind of one of the leads of 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.
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 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, standards have really played a key role for many, many
years.
Large players in those industries, whether you're talking about telecom or networking
or communications, it's mandatory to support a wide variety of standards in order to solve
equipment or solutions to provide those into that market.
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
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 a 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, 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 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 person buying their stuff to,
you know, start over from scratch, right? 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 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 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 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.
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.
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 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 mandated a 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.
So how does your stuff work with these open source components?
And sometimes that 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.
So open source is really bringing some great things, but I think we would 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?
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 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 perhaps you want to use an open source project in a certain way,
but if you're not actively contributing to it, 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, 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
and maybe even some proprietary stuff, you know, that's a real challenge.
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 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,
the first iterations of the standards.
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 big solutions around all these standards, right?
Now all of a sudden, your open source project 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 part of the standard,
then when the standard is actually ready, 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,
this is a relatively, it's a little bit dated slide from the Lenox 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, you can see that there's a lot of open source projects
just in the Lenox 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 bottom to 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, 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.
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 Lenox 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,
the standards groups that play a role in that space.
And where I think there's the greatest opportunity for collaboration
is going east-west across, right?
So standards organizations like, for example, IETF,
and playing at the same level as perhaps an FDIO or an OVS
or even with Lenox,
you start to see the opportunity for something that's being done in the standards area
what needs to be implemented, probably is implemented in these open source projects.
So to the 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 standard organization that I'm involved in.
It's Internet Engineering Task Force,
and it was created back in the mid-80s with the goal of making the Internet really,
all the protocols on top of which the Internet's built.
And now today, the goal remains to make the Internet better
and over time to refine and add new protocols that are needed.
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 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 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 pull that out.
You see, you know, we reject Kings, 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.
And I see there being a lot of potential in getting back to that idea of running code,
sorry, that's related to standards.
So one thing that the IETF did, I think as a realization
that 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.
And if you've been working in the IETF for a long time,
you're probably pretty comfortable with writing your drafts in 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 make our processes work a bit better
to meet developers, to make it more developer friendly?
And so this GitHub integration and tooling, what it did,
was to find a way that 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 and marked down,
something that many developers are pretty familiar with
just from writing their own readme's.
And so now the drafts, although they're still just really 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 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 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,
what the draft that people are collaborating on is stored.
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
and taking the things that you learn from implementing them
and working them back into future iterations of the draft.
So I think 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,
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 where maybe there's a problem in the standard
or a better way to do it by actually implementing it
and using that to help build 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 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 of years later,
after having these at every IETF meeting,
it's now common to have three to 400 people at one of these.
And if you think of an entire IETF meeting
being about 1,000 people,
that's 30 or 40% 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.
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
and we can store them there.
So in case the project wasn't already hosted somewhere else,
oftentimes we'll put the project in this GitHub org.
And that makes it a little bit easier then
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 look at, we always have a wiki
that lists the various projects for an IETF hackathon.
And this is a good example where they've done an important thing
where you can see 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 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 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 a nice way of linking those things together.
So we made progress,
but it's not all rainbows and unicorns yet by any means.
And so I think we're just scratching the surface here
with what we can do.
I go back and I show you this GitHub org that we have.
There's maybe 20 projects there.
It's probably 1% of the code that is related to standards
that exist in the open source world.
So 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 if you look closely,
you'll see that one of the draft names has even changed over time.
So 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 I think there's definitely things that we need to do to improve.
So what I did was, for those of you who work in the ITF,
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 ITF drafts
and code that's related to them.
And to set up a process that you could think of becoming
a standard way of doing this.
And so that everyone keeps this in mind
when they're writing their drafts
and to point out where to find the code.
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 relevant code,
whether it's an implementation of, say, the protocol you're defining.
Perhaps it's a tool that helps you sniff that protocol
when it appears on the network, right, to sniff it on the wire.
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 one is pointing to a related implementation,
where, in this case, because it's a 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.
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, OpsAWG, IPfix, 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,
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 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,
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,
but you can help do your part to 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 you know that project very well,
and you know you've implemented some key standards in it.
So 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 hopefully make your open source project much more valuable
and easier for them to consume and to use for their purposes.
So by making this linkage easier for people to find and use,
I think 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 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.
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's really a link between open source and standard.
So my question is, in one of your previous pictures,
you were showing like standardizing organization and open source.
And I've seen that there was like the image of open config on the open source.
Let's see, not this one, right?
No, I think I know.
One of the initial slides you were showing.
This one maybe.
Yeah, so I recently had to develop something related to the open config group, right?
And somehow they are also defining a standard.
So what do you think about this?
Yeah, that's a good question.
So that's an example of sort of a community
that's not traditionally maybe considered a standard 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 standards in a similar space,
but being done by 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.
So I'd say the one thing is, as long as the open config is open to community consensus
and taking input, then ideally we'd have one set of standards,
but if we have two and they have different communities working behind them,
perhaps they each meet a separate need.
So it's not necessarily a bad thing.
The important thing is that both communities are very 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 competing open source projects existing,
but you can't always force everyone.
That's kind of the beauty, I guess, of open source,
is you can go off and explore different things.
And that's kind of what's happened here.
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?
Okay, so we have time for one more question, and I see one hand.
Great when it works out that way.
Yes, thank you for the talk, for these implementations linked to a specification.
Would you preferably distinguish between an implementation and, let's say, a reference implementation?
Yeah, great point.
That's actually one of the challenges we had in the IHF too,
that people thought, I guess one of the concerns was perhaps pointing to some code
that is, you know, it's just a little bit of a science project,
or 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.
It hasn't really come up with a better solution than that,
than to say, hey, 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,
to make sure you have your contributing file there?
So it's kind of just letting people know through the README, I think, is the best way to go.
Thank you so much, Charles. Very much appreciated.
Thank you.