 Let's start with our first keynote. I'm just going to quickly introduce the folks here. The keynote has become an open-source service. Let's give people a few minutes to enter. Oh, yeah, absolutely. This is amazing. We're having DevCon again. Door closed. Door closed. I think that's a sign, right? Okay. We'll be talking about open services. And this is an interesting group of people because we have folks who've been with the communities in different projects for a while, who've been in different positions as well, right? Dealing with customers, dealing with developers, doing some real work and developing the services. So it's something that we're all passionate about. We'll be talking about this topic for a while, also during the conference. So not only at the keynote. I think we should do a really quick round of introduction for people who don't know us. My name is Rade Volkal, and I'm currently working at Redhead as the product manager for a set of services that we call Insights. I've been at Redhead for almost 20 years now. It's a little crazy. And, yeah, Steph, I know you for ages as well. I've been involved in open-source for over 20 years. This is not my real hair in case anyone's wondering, but if I don't wear it, I get boot off stage. I need a lot of their rel engineering, Linux engineering, satellite teams. So many people that I have joy and pleasure of working with are here as well. Over to you. Thank you. Hi, I'm Simon, and this is my real hair. So, yeah, I've been working in open-source for something like 15 years, and I've been at Redhead for two years, and I've had the amazing opportunity in these two years to work with a very talented people in the Image Builder team. And, yeah, we are the first service of this HMS Insights Groups rail services to be available publicly, and we're very proud of that, and working to make the service even more open going forward. Hello, I'm Roberto Carattala. I'm a cloud services black belt, even though I don't know a clue about Kung Fu or anything else, and I'm working for Redhead for more than seven years, almost eight, and a pleasure to be here inside. Hello, I'm Tomasz Tomeczek, Radek, and Ondra Vashi hired me actually 11 years ago. At Defconn, right? Oh, yeah, at Defconn. And I never thought that I would be doing a keynote here, and I like to make short introductions. Thank you. All right, so let's give you guys a first, like, introduction, right? So why are we even talking about open source services? Why do we care? Why do we care about this? I mean, come on. We've all been part of a massive monumental change that has made the world better. We have brought open source into every corner of software development. I mean, proprietary systems is now assumed that somewhere in the stack is a component that someone in open source has worked on, someone here, there's open source services systems, operating systems, everything you can imagine that has open source permeated throughout everything. And this has brought humanity much further than proprietary software could. So when you walk into a readout office and you see one of these signs from Mahatma Gandhi, you can easily assume that, okay, we won. We're done. This is great. We have now Utopia. It's all wonderful. Let's go home. And we are here to tell you that this is not the case. There is a challenge ahead of us. There is a challenge to open source that if we don't address and we don't adapt to, we'll become a threat. And I'll explain to you why that is. Think back on your first open source change that you made to a component or something you were running. Now, for many of you, this has been around for maybe the whole time you've been working on software. But for some of us, it blew our minds. Think back to when the first time you could actually change something, change the behavior of something on your computer, and you finally put in, maybe you changed the color of something, maybe you put in a printf, maybe you logged something and you changed the output of a command. It just blew my mind that this was possible. I'm surprised you found my first patch. This is your first patch. Very good. I couldn't find my first patch. I mean, I didn't keep it. It was garbage. It was changing, I forget, something to pig latin, and it was in fetch mail, I think. But think about what makes this actually possible. What makes this possible is that you have a copy of the software running on your computer. This is what made this possible for me. And the source code was shared in a way that I could actually change it. I could rebuild it, and so on. And the problem that we face is a lot of people, a lot of us, but a lot of people in the world no longer actually want to run a copy of the software. They want you to run that crap that you wrote. They don't want to run it. And they want to experience the output in the form of a service, in the form of an API that they call, in the form of infrastructure as a service. In one way or another, they want to use the software without actually having to run it, much less make a copy of it themselves. And so we run into a paradox here, a conundrum that we need, and I'll walk through this with you. The first thing is that open source thrives when it can convert some small percentage of the people who are using that software into contributors. Now, some projects, this happens a lot. This happens at a fantastic pace where half the people become contributors, maybe developer tools or things like that. In other cases, it's a small fraction, but there's some function here of people who are using the project actually decide to make a change or help in some way. And conversely, it starves when that can't happen. So if you prevent that function of users becoming a contributor to the software, open source starts to atrophy, regress. But our open source practices, most of them require that you operate a copy of the software in order to change it, in order to even get the idea that you could make a change in order to play with it, in order to introspect it, in order to understand what's going on. But at the same time, the users of a service literally chose not to run the software themselves. They're using the service mostly because they want someone else to run it, or in some cases, it doesn't make sense to run this thing in another place. It makes sense to run it in one place. So they're unable, unwilling, or just doesn't make sense to copy the software and operate the software. So we're at a paradox, a place where when we put all these things together, it doesn't add up. It is very hard to contribute to open source services. It's not natural. And the mechanism that we use that underpins much of open source licenses copyright is about copying software. And therefore, and in services, you don't need to copy a service in order to have that software be successful, that software be used. So although all those ingredients, we can still use them. We're not going to throw away open source licenses, for example. But they are not sufficient to solve this paradox. And so I want, imagine a world, we're not there yet. But yes, imagine a world where you can actually go and look at what's running in the service that you're using. You can see the code. You can see the software. Imagine when you call the API, you can understand what the hell is going on under the hood. You can see the same way you can with a stack of Python or Node.js on your own machine. Imagine you could make a change and experience that change without operating it yourself. You can make that printf or that change or you could translate it into Pig Latin or you could change the color of something in a service and you can actually see the behavioral difference. That is a world where open source actually works with services, with software as a service. So... I think we need some guidelines, right? We actually... Yeah, well, exactly. And this is real today. So that's what we're here to talk about. It's not about, we wanted to introduce the challenge, the paradox, but what everyone, what we are doing is to start to address this problem. And so many people are involved, so there's so many different ingredients to this. One of them is that together we figured out what are the basic requirements for an open source service? It's not just an open source license. It's not just sharing the code, although that's important. The first requirement is that you do share the codes, the same with a project, that all components and all the assets in the service are shared under an open source license and available to the public. That's fundamental, of course, but it's insufficient. The second fundamental part that we need is that others can contribute in the same way as a team working on the service can. Whatever that mechanism is that you use to work on the service, to deploy, to review pull requests, to accept those changes, to run tests and so on, others need to be able to do it in the same way. And by meeting these basic requirements for an open source service, people can then take it further. They may not take it further, but they can take it further to perhaps operate it somewhere else or add capabilities and ways of working that people... This is all great, but is someone already doing all this stuff? Yes. Really? We're going to blow your mind about it. This is happening today. I mean, it's not all perfect, but we need to work on it together. So... I think Tomasz is actually working on something. He raised his hand immediately when we start saying someone is actually doing this for real, right? This is the slide. Yeah, we definitely need to make it and get it further. Okay, so I think you might be confused while looking at the slide, so don't worry, that was my intention. But my colleague said that maybe I should explain what's in there. So I tried to collect a few techniques we are using in our open-source services and explain. So on the bottom you can see that's my favorite, it's database dumps from production. And they are super helpful for everyone on the team and especially for the outside contributors. When you are working on your change locally, you can load it up with the production data and see how the change will feel in the production. That's really amazing. Just one pro-tip. Don't forget to remove all the passwords from the dump. And the whole top is filled with documentation and I can't stress it out how many times this saved my butt when I was trying to work on our service and I didn't know which OpenShift command I should run or how to access this or that and then I open our documentation which is really perfect for deployment and for the architecture and I immediately knew what I need to do to keep the production service running and don't trash the secrets or something like that. So it's really essential especially when you are struggling or there is some problem and you need to solve it as soon as possible like make sure that your deployment documentation is flawless. Yeah, on the top right sorry that shouldn't be there Simon will talk about it. But what Steph said so the minimum requirements are all the assets are open and everyone in the public can contribute and it's really just minimum I mean when you meet that when you open source your code and collaborators start piling in like that's the beginning for you and there are many things you can do for example in our service one thing that really helped us was opening up our planning process because we would always get these questions like so what are I working on next or what's the current epic or even within the team we sometimes didn't know what we want to work on and as soon as we made Kanban board on our GitHub namespace and everything's open all our epics what we are working on right now it makes so many things much easier. So before I hand out the microphone I'd like to challenge everyone and think about what should be on this slide because I collected a few screenshots here and now that I kind of see it on the little screen I know there are many things missing and I would really love to see more solutions and make it easier for everyone to for as Steph said so I can experience a change I'm working on and I don't need to deploy anything someone will do it for me some system so think about that and maybe when we do this in one or two years this screenshot this slide will be so full that you will only able to see anything right and Toma this sounds way too easy, right? I think there must be something missing it's not just about the code of the service you have to still run it, deploy it somewhere what are the things that we're missing? Roberto help me out When we are talking about software as a service it's not only about the code itself the service itself is much more than just the code it represents for example service represents the tip of the iceberg for example we have much more value in the service rather than this if you show we have the best practices that represents and manage the different service at scale we have the automation and the infrastructure that are running as well we have the operational processes the interconnected services and all of these components and pieces are backed up by open source projects and repositories that you can enable the users to influence and to make contributions in order to make changes to the software and the services that they are using for example, Azure Red Hat OpenShift is a jointly designed service that runs in in Azure itself and is designed by Microsoft and Red Hat and it's open source, so you can go there, you can contribute you can open issues and influence to the different software that you are using at scale So Roberto, I have a challenge so I know that there's a bunch of services out there, I'm running some of them I'm using some of them, how can I tell that this is an open source service and I can just start contributing to that Simone, you have an answer, right? Yeah, I mean that is a very, very good question a very valid one because it sort of ties into all the other things that were said before me, like the thing that Steph said we're sort of used to a a certain way of working with open source software we know, we download a software package we have an idea of where's the source, I mean we've just downloaded it there is a disconnect though with services where we don't necessarily know where the source is or we don't know where the documentation is or we don't know how to find the standard operating procedures or the best practices of the specific team that designed this very service But you don't even know that the service is open source Yeah, exactly You might not even know that a service is open source that's even more fundamental and the only way you can do this is by embedding something in the service that guides the user to how to introspect the code or that shows it at the first glance oh, this service is open source the same way that a fork me icon on github tells you oh, I can fork this code I can actually work with it, it's open and this is I think something that we really need to work on that we're sort of piloting on some of the services that are open already as you can see in the screenshot and the idea is to really sort of connect the two dots, you know the running service to first of all inspect the code and understand why an API is maybe not behaving the way that you're expecting or that the documentation told you it would behave or even how you could change it and how you could maybe introduce some typing or something into the API and make sure it doesn't break but I mean one thing that we haven't really addressed is why should any business care about this like why should anybody invest money into this so here's the thing so at the end of the day the services that we're all working on and that we want to open source someone wants to monetize them someone wants to benefit from them and I have an observation as a product manager about services that from my perspective are becoming successful and there's a component that we didn't mention here and I want to highlight here a lot of these services and things that you see here are actually opening up their ecosystem for further contribution something I would call a midstream where you can build extensions, integrations plugins, different connectors and this allows different people to pick up these services pick up these projects and extend them for their specific use cases and different purposes extend them beyond what the initial authors of the service even thought about if you look at some of these examples you basically realize that these are projects that were very much focused on a single use case at the beginning single purpose again but because they thought about again plugin infrastructure extensions and additional things these became hugely popular and again this midstream idea where different people can contribute on top of the service they have access to APIs they have access to sort of a playground mock data and these kind of things is a huge thing and again that's where I see the services being successful but also then solving problems and solving challenges for some of my customers that again the initial authors of these services haven't even thought about so I think that's something that we should all think about as well how to not just open source the service itself how to open source the ecosystem around that so others can easily contribute on top of your service within your service as well we've talked about a lot of things here and we've touched on these things right but we need to go deeper and because of that we actually have couple sessions during the DeafConf and we welcome you to join these and challenge us and tell us how wrong we are or whether you're already doing something else that works for your community your use cases let's do really quick introduction about all these talks that we're going to be doing so Toma, you and Neil are doing the first one right? We spoke about open source services right now for a few minutes and you can actually experience the contribution process tomorrow time 15, I don't know which room but the title of the talk is up there so we have prepared a workshop for you when you can try contributing to your open source service it will be just the front end not the back end and yeah, we invite you there for any successful contribution we have prepared some nice presents for you and for the people who will come there we really would like to challenge and think about how can we even extend the process to the back end for example so that it's so that anyone can make the contribution very easily and not build thousands of Docker images or whatever and try to set up themselves so please come by perfect, perfect, I see Neil over there hey Roberto, you're doing a talk with Marcel here Torsten as well right, you're joining the session too no, just Marcel what is your talk about? Yeah, if you are wondering how you can start contributing in these open source services focusing for example the cloud services, well Marcel Held and I, we will be talking about how much open source is in the cloud services and we will analyse and discovering the different open source projects that are using in real production managing the different managed clusters that Red Hat cloud services manage across the world and we also present these different repositories projects that you can get you can influence on them and get inspiration in your own projects so you can get some ideas in order to make it better perfect, perfect Simone, you're talking into more details about this small icon right? Is it just about it or is there more? Yeah, that's it, so my talk will be very short, it will last for a few weeks Yeah, so my talk is on Sunday afternoon so the first challenge of course is for you all to be there because it's Sunday afternoon So people don't know that your service is open source many of you run open source services no question, you meet those requirements people can contribute and your code is shared but everyone who's walking through that it is open source they don't know what code you're running and they don't know how to contribute so come to Simon's talk Thank you, yeah, very much so What are you doing? Okay, I will make it longer than two minutes but it's not too long but the idea is of course figure this out, we have a proposal we're piloting something already you could see it in the screenshot it's real, it wasn't a mock up and I'm very interested to hear your thoughts and stuff the important thing is that during the conference you'll find some other talks I was going through the schedule I found these interesting talks from a lot of Nikolas you guys should join these David, I see you over there you're talking about some of the services as well I've seen some other people here who are passionate about this topic as well so go grab them as well join their talks challenge them as well and that will be we've thought about doing some sort of a competition about you contributing to open source services I think we should still at some point do this that we'll love to see your contributions as a result of DEF CONF so after DEF CONF if you contribute to any of the open services here you want to send us your patch we might actually send you something some gift if you do so as a result of this keynote exactly let's not pretend that this is easy solving this paradox is hard but we do hard things and we do them amazing well and at scale we have changed open source wasn't an easy thing either we all worked hard to make that true this challenge is an exciting one but it's difficult and when you believe this is a problem that's going to prevent this from progressing for example with accessing data that one comes up a lot that just tells us that we need to work together to solve that problem join that workshop start to figure out with Tomas and with Neil how to solve that aspect bring an idea work together on this and we will be able to solve it together we'll solve this paradox perfect, perfect I'm going to say these are the famous last words so again join us in these sessions if you have any questions right now we still have couple minutes so bring them up okay there you go just yell it and we'll repeat it so the question is how do you solve the development environment problem where you can quickly bring up your change and not have to wait days for an environment that that you can run it in I would say we already have the solution it's containers, we have the recipes we build them, so create them and then use tooling to get them all together and hopefully even with that production data inside and you can have the development environment locally like for me this is already solved I know that can still be improved over time in future but for me it's done so I'm really curious what everyone here thinks about it so feel free to approach me about it alright right so truth is that as you mentioned some of the services are too huge to be run on your laptop you need a playground, you need a testing environment so join this workshop because that's literally the thing that needs to be solved and that like Tomasz said already has a working solution for the front end but we really need a deeper solution that is literally the nut to crack totally agree and I'm glad we're working on it together here alright I see one more question in the back first I'll get to you Lukasi someone was raising hand so it works for some projects that's good to hear okay Lukasi perfect thanks Lukasi anything else and if last oh there's more hold on I'll hand over the microphone to you thank you I noticed that licensing didn't come up as much during the talk do you think there's a perception that licenses for open source services are maybe not so effective if there is a perception like that should it be changed how could it be changed how do you think open source and free software licensing fits into the picture that you're painting here this is a good topic so how the challenge that we have is not that open source licenses don't work they work fine FOSS licenses work GPL works for services there's many licenses that even are even more aggressive like the AGPL on services but they are insufficient that because you don't copy or you don't need to copy the code that's running in software they are not the enforcing mechanism they're not the thing that actually underpins open source services anymore and that is the problem so they're good but they're not sufficient for what we need to pull off here I think that part of the challenge is also you need to be able for someone who contributes I'd say live to a system let's say the contributor is a banker or something like that and they want to really make sure that what they have contributed is actually what is running on the other side so I think that if you want to do that correctly you also need to have a really good chain of trust all the way I'm not trying to advertise for the talk that I'm going in one hour but just in case so chains of trust are important I think we're starting to know how to build that at the VM level at the workload level etc I'd like to advocate for building that in the programming language themselves and that's hard don't get me started on that but that's really something that we need to put some emphasis on so really integrating that at the low-level API level when you have an RPC mechanism that this RPC mechanism can just send data over but send a proof that the other side of the API was this version that it executed in this environment and it gives you a cryptographic proof that this went well otherwise it fails spectacularly and you know it failed okay thank you so this was very good thank you very much thank you for solving one of the challenges yeah data security, data residency these type of things those are all challenges for services and yes we do have some additional talks about this type of problem here as well folks anything else any other question if not we'll let you go right now grab some coffee it's going to be exhausting I can promise that and thanks a lot you've been a great audience