 Hello, everyone. So today I'm going to tell you the story of an open-source network protocol and how we brought SRT from a proprietary software to an open-source success. So who am I? My name is Olivier Cayet. I'm the Multimedia Domain Lead at Collabra, where I've worked since 2007. But I've also been an open-source developer since 1999, first working on a GNOME. And since I've been an active developer of the distribution community, I'm one of the core maintainers. And there's something I've been doing for over a decade now. What are we going to talk today? Something called SRT. So SRT stands for Secure Reliable Transport. And it's a generic protocol to send streams reliably over the internet. It was designed to transport and pay transport streams with low latency, but good quality with encryption for security. And it's been designed for use by broadcasters. So SRT is a protocol, but it's also a library implementing it. And I would say it's first and foremost a library. It was created as software before actually being defined as a protocol in English. This library is now open-source and this is what we help bring to the community. It's multi-platform, Linux, Windows, Mac OS, Android, iOS, TV OS, everything. All of the major platforms are supported. So where did we start, right? SRT originally was developed by a company called HiVision. They developed it as a proprietary protocol. It was a differentiating feature of their products compared to the competition. And they had deployed it almost across their entire product line. So if you used a couple years ago, if you use HiVision products, you could send SRT from one HiVision to another, but nothing else obviously, because it was proprietary to their company. So who are the players here, right? The first player is HiVision. So HiVision created SRT and they're a good company. They have a very solid engineering team, but like most software companies, they're not really into open-source, right? Then they used other open-source. They have all of their products, which are actually running Linux inside and have a lot of open-source software inside of them, but everything that they did themselves, they had the very traditional mindset that it has to bring like value and, you know, if the open-source is not going to get any value, etc., etc. So they didn't really know how to do open-source. On the other hand, there's us. We're Collabra. We're an open-source consultancy. Everyone at Collabra is an open-source developer. We all have open-source expertise, and we've been doing multimedia almost since the beginning of the company. So we helped HiVision make SRT into an open-source project, an open-source successful project. And I'm going to tell you this story, right? How we and HiVision together made SRT into a really successful open-source project. So before we start the project, we have to go through a couple steps, right? So the first step is asking ourselves, why are we doing this? For us as open-source people, we think like this is the most stuff we didn't think in the world. If you do something, it's going to be open-source. But for many companies, they need a justification. It's not the default yet. And for HiVision, the main reason they wanted to make SRT open-source at first was to have adoption. They wanted video over the internet to work and to work reliably and to work interoperably amongst all the devices that you can buy from different vendors. To not have to have like so that their customers and all the users don't have to have devices from one vendor that they can mix and match, but that they would have interoperability and have good quality of transmission. They also wanted to raise their profile. So they wanted to raise the strength of the HiVision brand and they thought that by developing a protocol and a system that everyone would use, that would make their brand much more known. And they wanted to make the ecosystem more open, right? So increase interoperability there. One of the things that we also have to ask yourself when you develop a new open-source project and what are non-goals, right? What's not an actual goal here? That's almost as important as doing what your goals are. And in this case, one thing that was not the goal was to increase contributions. They felt that they had the development in the end quite solidly, so they were not trying to get like more developers for the product. They were really trying to get people to actually use it. Then we looked, what else is there? What's the competition? Is there any open-source alternative? And we looked and we couldn't find anything else that was really at the feature set that the broadcast industry needed. There are things like WebRTC that are developed for low latency, but didn't have the kind of quality and the simplicity that they need for broadcast users. But there were a number of proprietary solutions down there. Among them, Zixin Astera, which come as SDKs, but their actual product is a service. So the SDK is free, money-free, but not open-source. But to actually use it, you need to pay these companies for the service, to transfer the streams. And then there were a bunch of vendor specialized protocols, like high-vision SRT, but a number of their competitors had similar features and functionalities with different homemade protocols that were all incompatible with each other. So there was really nothing out there that was like a direct competition. So as I said, almost everyone in the market had a similar solution. And in a way, SRT and all of the others kind of work the same. The underlying principles are the same, the street transmissions, maybe for their work correction. There's like no great magic there. So SRT's big differentiator that we saw was that it would be open-source. That means it's easier to integrate it. You don't have that's for permission. And but also you can use it for a thing that it was not originally designed for, right? Since it's open-source, it will be open-source. You can actually do whatever you want with it. Use it for things that the original developers do not think of, which is often much more difficult with proprietary software. So SRT is a network protocol. And when people think network protocols and open, they think open standards, right? So we asked ourselves, maybe there's no software, but maybe there exists a standard out there that's open that we could just use instead of having to create a different new software. And for video transmission, a lot of the low-latency protocols out there are based on RTP. It's possible to do everything that SRT does with RTP-based protocols, but there was no grouping of RTP specifications that people could agree on. And that would just give the required functionalities for broadcast without bringing much more complexity. In many ways, we kind of concluded that RTP-based stacks were not there for what they needed. So next question is why publish an open-source project, right? Why not just create a standard, get around there with other companies and say, hey, we're just going to write a document and everyone can implement it? There's multiple reasons for that. And one of this is to have basically something that is usable on day one. And by having a shared implementation that's open-source, then everyone can cooperate on it. And it also means that you have good interoperability from day one, right? Because it's the same code, right? So it will integrate with itself. And also it encourages people who want to enhance it to actually work together. Instead of, you know, if you make your own implementation, then there will be a lot of pressure from management to create value by having something a bit different from the center, a bit improved, that you can go around and say, hey, you can't interrupt with anyone else. But if you use our product on both sides, it's going to be so much better. In that case, we wanted everyone to really have the highest level of interoperability to not have like two grades, like open-source grade and then the better proprietary grade. That was kind of an empty goal here. Then it's a project, right? Open-sourcing something creating an open-source project is a project in itself. And a project needs a timeline. Our timeline here was quite short at the beginning. So we were aiming to release SRT by the NAB conference in April, which is the big conference in the broadcast industry in the US. And we started this project in February. So we had only two months. Those are quite a short timeline. And then we gave ourselves some time after that, right? We said after the initial launch, if we don't get some traction within 18 months, then it's not going to work too bad. And the second deadline was after launch, if after three years, we would like have a checkpoint and say, has this been a success or a failure, right? If it has not been a success in three years, it's not going to succeed. But one of the other things that was very important is that we said, you know, this might not happen on day one. You have to be able to be in it for the long run. If you want adoption, you have to let people know that you're in it and you're going to maintain it for years, right? That it's not just going to be a thing that you throw over the wall. So for an open source project, one of the most important things to make it successful is to have a governance model. So who are the stakeholders in this governance model? One of the important ones are the developer, right? As this is software, developers are really a key constituency. But since this is software that's really designed for business use and to price use, the management of these developers are also a key constituency, right? Their bosses are very important too. And then we need to think also who are the users. Since this is really a library, users are actually other developers, right? They're developers that write applications or products and that will use these library in their product. And these are mostly corporate developers, right? These are not hobbyists that are our key target. So now that we know who the main stakeholders are, we also have to think what other roles are in this project, right? To create a successful project, you need many different things. You need people who will write documentation. You will need to help the users actually use it because remember adoption was our goal. So we thought that helping users is a really, really important part. You need someone to set a direction, both the technical direction and the non-technical, more on the business side of the project. You need to do marketing, right? So that people actually know about this and will adopt it. And then you need to write code in the end. Next question really is how much control are you ready to give up? Open sourcing something always means that you're going to give up some control. And the amount of control that you give up really is balanced with what your other goals are. In this case, the goal was adoption. And so we don't need to seize too much control because we don't actually require other developers to join or something like that. We just want people to use it. So we can really not like have a model where we have like complete external governance. We can keep the governance very much where it was originally. So we know it's a decision making process, right? This is making process and different projects vary a lot, both for technical and non-technical decisions, right? It could be a board that can be elected or appointed. You could have like a one person deciding like a dictator, a benevolent dictator like Linus, or you can have something much more add up, right? This is not a huge project. So maybe something very structured is too heavy and you might want to have something much more add up, something in between. And since this is really not that big of a project, maybe you don't even need a real structure, right? You might really go with something very with the flow. Since it's open source and one of the things that kind of binds open source communities is the license. We thought that the choice of the right license was very important. So licenses can go, you know, from permissive licenses, MIT, BSD style, all the way to very strong copy left licenses like the GPL v3 or AGPL v3, or somewhere in between. One of our goal here was adoption and one of the key places where we wanted it to be adopted was in mobile applications. So it was very important that whatever license we choose would not be a problem for app store users. But we also wanted to kind of discourage proprietary forks to have really interpretability at the highest level. So we tried to find something that was able to satisfy both goals. And for this project, we ended up choosing the MPL because of its different clauses that really make it easy for both sides. So now we've taken care of like the people aspect and the governance aspect. Now we need to take technical steps to actually make it a good open source project. Many projects that operate and originate from the proprietary world are often developed in the idea that there's only like a very small group of people who actually matter and that it doesn't have to follow standards that everyone else can follow. But it's important if you want to open up something that everything is clear and easy for you to spread one. One of the first things that people do when they get an open source project is to try to compile it. And many projects that originate from the corporate world, sometimes you just stuck at that step. What you really want is a build system that people already know that is standardized and that is high quality. There's many different or good high quality open source build systems, things like CMake, Auto Tools, Meson, and there's a couple more. But I would not go with something exotic really. You want something that is common for the language or platform that you're using and that other people will know. In this case, it was already CMake, whoever you're looking. A lot of corporate projects I still have like really bad things. Sometimes just random make files or maybe very complex made files that rely on a complex infrastructure that tie up with the company's internal build systems. And that's really, that's bad. And what's even worse is just a bunch of shell scripts. So if you have that, you have to delete everything and restart with a standard one. No one wants to see your internal build systems. Then once you have it building, then you need a place for people to cooperate. Cooperation requires different tools, right? Issue tracking, you need the source code hosting, you print something like a wiki or somewhere where you can put text and documentation, build instruction, etc. All these kind of things. These days, by far the best way to do it is to use one of the GitHub or GitHub, right? There's, they've really cornered the market. My personal preference is GitHub because it's open source, but in this case we went with GitHub because that's what they were already using. Then we need a way for people to talk to each other. To really support users, I feel that you want both something like a mailing list that is slower and more longer text and a chat system like REC or Slack. In this case, we have a Slack channels where people can go and discuss whatever is happening with SRT, get help with installing it, using it, developing it, etc. All the developers are there. So it's a really good way to actually communicate. So how do we start like these tools? One of the kind of important things is that there are, these have to be tools that are familiar both to the existing developers so that they're not going to waste too much time with them, but also to potential contributors and potential users. So the advantage of using very standardized tools is that everyone already knows them and you don't waste time learning them and they don't become a barrier. So the goal is to reduce the barrier to entry and by using tools that are well known and well established, the project doesn't become about to build tools or about the compression tool, but really about the project itself. The next step is that we need to market it. We have a good project, we have a good governance, we have good source code. Now we need to let everyone else know about it. Since this is a library, an immediate transport library, the way that people actually use this is often that they will use it through something else, a bigger library, either something like ffmpeg or gstreamer that will provide the encoding, the decoding, all of the other steps that we need in a media pipeline. So one of the first things that we did when we decided to make this open source was to figure out which are the important other libraries that they should integrate with and go upstream and send them patches offering them the integration with libSRT. Since libSRT had been open sourced by that point, it was much easier for them to accept integration patches. So we quickly integrated in both ffmpeg and gstreamer and another thing that we asked is what do people use to test in your industry? How do they test if a stream works? What the tool did they use? And they said, well, they're not special, they just choose VLC like everyone else. So one of the things that we did very early on was to submit patches to the VLC community to add support for SRT so that you could just type SRT around and VLC and it just works. And all of these communities like VLC, gstreamer, ffmpeg were very helpful and we could get our patches integrated really quickly. It was a surprise how easy it was so considering it's completely new for our fall. So very quickly we had the SRT support in all three and a bit later we also had it integrated in OBS Studio which is a great create content, create a live stream and send it to an SRT receiver. So now that we had it integrated, easy to use, sometimes as easy as just putting the URI in, then we had to create awareness. So there's two parts of creating our S1 is for open source developers. So part of it was to talk to developers of other relevant projects that we've already talked about and make them aware of SRT, what's its strengths, what's weaknesses, what is for, what is not for, so that they can do marketing for us in a way. And the other important group we wanted to talk to is business people. Since we're seeing that most of the target users here are corporations that are people building products, we decided to create a business alliance. So that's an alliance of companies that use SRT, promote SRT, build products around SRT and this has been a really important element of the effort. So has it been a success? The answer is yes. So I've done the presentation similar to this one a couple of months ago and I was seeing there were over 250 members in the alliance. Today I was told there's over 400. Last time I said there were 88 company shipping products. Now there's 129 if I counted correctly on the website. And according to GitHub there's 67 contributors. So even though the goal was really not to gather contributors, we gather contributors anyway because if you have something that people actually use they will contribute to it. So that was really really successful. I was really impressed at how quickly this picked up. When we announced it within a couple of weeks companies were lining up to join the alliance. They really brought something to their industry which was lacking. There was really like a need for this. And immediately we had a lot of updates. So that's been a really really great success for high vision and also for open source. So thank you. If you have any questions you can ask me on Slack of the conference or you can always reach me directly. I'm all over the internet so you can google my name and you will find me easily. So thank you very much and have a good afternoon. Hello everyone. I guess it's time for questions. Just a quick shout out. If you need any help with bringing anything to the open source world and you don't know where to start we're happy to help at Collabla. I guess we don't have any questions but if you want to continue the discussion you can come on the Slack channel and we're already chatting about this. Oh yeah I have another question. Have other industry members started taking a bigger role in the governance? For now the answer is really no. High vision are really doing the governance themselves in a way. So it's not something that really they try to get more people on. Now another question from Samantha Logan. Can you discuss how we should adapt these things when you're running a service? That's a very good question. I guess if the service is software right because that's what services are these days. You basically publish your source code and all these things are kind of the same. I don't know what else I can say. Well services wait for other questions. I guess we're going to soon run out of time anyway. Is there a quick G-streamer by a plan that you can share to test G-streamer? SRT yes there are. So we've made a blog post on the Collabla website on SRT and G-streamer with some examples but basically you use SRT sync and then you put the URI. So it works and you feed MPEG transport stream into it. So something like you know video source encoder MPEG transport source moxer and SRT sync. Or you can use a source right SRT source. You can even play SRT URL just with the play bin if you're a familiar G-streamer. Mark's asking how many panels and similar activities have happened in the public? I don't know. I'm not sure where the question is. I guess thank you very much everyone.