Re: [hackathon] Open Source Software and network protocol standards

[Maxim Sharabayko <[e-mail]>]

Hi Stuart,

The Secure Reliable Transport (SRT) protocol might be an interesting example.
https://github.com/Haivision/srt
It has become an extremely popular network protocol for a sub-second latency live video contribution and distribution.

It is an implementation-driven protocol built on top of UDP. First created in 2013 based on the UDT<https://datatracker.ietf.org/doc/html/draft-gg-udt-03>. Made free and open source in 2017.
The protocol has gained a notable success because anyone could take the library, easily integrate it in his/her project and have things ready for live streaming in quite a short time. Later the protocol was also included into open-source projects like FFmpeg, VLC, GStreamer, Wireshark, etc. That had further simplified the effort needed to get things up and running.

The  SRT RFC draft<https://datatracker.ietf.org/doc/html/draft-sharabayko-srt-01> followed in 2021 to provide a normative description of how the protocol works, and to serve a reference point for further improvements and extensions.


--
Kind regards,
Maxim Sharabayko

From: hackathon <[e-mail]> on behalf of Stuart Cheshire <cheshire=[e-mail]>
Date: Saturday, 19. March 2022 at 00:47
To: [e-mail] <[e-mail]>
Subject: [EXTERNAL] [hackathon] Open Source Software and network protocol standards
Dear Hackathon crew!

I have a question about the relationship between Open Source Software and network protocol standards.

My intuition is that in recent years Open Source Software has had a significant impact on network protocol standards, both in the availability of easily accessible open implementations contributing to the success of network protocol standards, and, in contrast, the lack of easily accessible open implementations contributing to less success for those network protocol standards.

I suspect that many in the IETF Hackathon community share this intuition, but it would be interesting to back up that intuition with concrete data.

I’d like to build a list of compelling examples.

Can you think of cases where an Open Source Software implementation clearly helped a networking protocol become successful? Was that Open Source implementation driven by the people (or companies) actively working on the protocol standard? Or was it created by an independent community following the standards development process?

Are there cases of a networking protocol that did not become successful where, in retrospect, it seems clear that the availability of an easily accessible Open Source implementation would have helped?

And, of course, counterexamples are also interesting: recent protocols that failed despite having a robust Open Source implementation, or recent protocols that succeeded despite having no Open Source implementation.

I am not the first person to think about the growing influence of Open Source on protocol development. Indeed, the existence of the IETF Hackathon itself is, in part, an acknowledgment of this new direction in protocol development. And others have written about it in the past:

2015: <https://www.ietfjournal.org/open-standards-open-source-open-loop/>
2016: <https://datatracker.ietf.org/doc/html/draft-arkko-ietf-trends-and-observations-00>
2018: <https://www.ietfjournal.org/three-years-on-open-standards-open-source-open-loop/>

Looking back now, in 2022, how have those earlier predictions played out? Do we have clear winners we can point to? Clear losers? This will help inform companies how they might want to engage with Open Source. Should companies embrace Open Source for protocol development? Or should companies go back to the old way, with open specifications and private implementations?

Please reply on the list or to me privately, and I will compile a list of responses.

Stuart Cheshire

_______________________________________________
hackathon mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/hackathon
Unsubscribe: mailto:[e-mail]?subject=unsubscribe



***[EXTERNAL] This message comes from an external organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.***