Okay. Hi everyone. I'm just testing to make sure the mics are working and the visuals are coming through. Let me know that. Maybe pop it in the chat. Perfect. Great. Thank you so much and thanks for coming. Today's webinar is about using the OSF as an electronic lab notebook. I'm Nikki Piper. I have my colleague with me, Sarah Bowman. We're both on the product team here at Center for Open Science. So Center for Open Science, if you're not familiar, is a non-profit mission-driven organization. Our mission here is to increase the transparency openness and reproducibility of research. The objectives of our webinar today are to sort of introduce the reasons for using the OSF as an ELN, demonstrate some of those essential features that the OSF encompasses and how they can be applied for the use case of an ELN, and to also give you some additional resources that you can take after this and go do some exploration of how this can be applied into your workflow. So quickly, we're going to talk through an overview of using the OSF. For those that may not be super familiar, if you are, I'll keep it really brief so I'm not spending too much time on it. The OSF is a tool that is used throughout the entire research lifecycle. So at the beginning of your research, where you're doing search and discovery all the way through data collection and finally publishing a finalized manuscript, today we're going to focus in mostly on the areas where the active research is happening, where you're working through development of an idea and collaboration, designing your studies, working through materials and data collection, even storing your data, analyzing it and interpreting your findings. So some of the key advantages that the OSF offers, besides the one I just referenced, which is that it's an all-in-one tool for your research lifecycle. It's cost-free. There's no cost to the researcher. It's open source code. It offers public and private use, meaning you can start in a private mode and do all of your collaboration there, but at some point when you're ready to maybe publish your work or send it out for peer review and you want to give some private link access or public access, you can do that very easily. It encompasses provenance tracking, including activity logs for all of the actions that are taken by all of various collaborators. It's also a very collaborative workspace where you can add various contributors and give them different access permissions all the way from admin, the full control down to just read access where they can see private content but can't change it. Also, there is a nice structure within the OSF that allows you to build hierarchies of a project where you can break apart different pieces and get those controlled accesses as needed, and you can even turn on a feature called request access, where somebody may have access to one aspect of the project but want to be more involved in other aspects that they can just ask you through the interface. Okay, so now we're going to jump into more of a live demo, so as you know with any live demo situation, there are opportunities for things to go slowly or not work. We've practiced and tested everything, so hopefully that won't be the case, but if it does, please just bear with us or use that sort of downtime to put some questions in the chat and we'll be sure to answer them. Okay, so now I have to figure out how to, okay, here we go. Beautiful, okay. All right, so here is a private project. We made it public, so you can actually access this on your own if you want to explore while we talk through some of these cases and features. This is a project, obviously it's created for demonstration. Some of it isn't actual or factual, but for our purposes today we'll pretend that it is. So I'm going to see if Sarah wants to kind of talk through some of this as just an intro into how an OSF project is structured. So this is from the perspective of a user that is logged in and has created a project and is now beginning to work with others in their lab to collaborate on a research project. Thanks, Zinke. Yeah, this is an example project to give you something to look at and understand how you might know about structuring your own project for your own research. So what I've done here is created a top level project that states my particular research project. I've added Nikki as a contributor to the project. You can add all of your contributors and to the project and give them particular permissions depending on what type of access you want them to have. You just want to be able to read, for them to read the materials, you want them to be able to edit the materials, and if you want to give them administrative access, which would allow them to add other contributors and manage public-private setting. So I've added Nikki to my project, created a number of components for the project to try various parts of my research. So I've got one component that is my lab notebook. I've got a component for my microscopy images. I've got a component to manage my reaction data. I've got a component. Maybe I'm at the end of my project, and I'm ready to write this. So I've got a component just for all materials related to my manuscript. And then I've got another one related to my protocols. So each of these components can have different privacy settings. So maybe I want others to be able to discover that I am working on hydroxy methylpheryl oxidation, but I don't necessarily want to share my reaction data just yet. So I can leave my top level public so it's discoverable, but keep my data private until I'm ready to share it. I can store all kinds of different file types in my project, and many of them will render right in the browser. I can store them natively on OSF storage, or I can connect a number of different add-ons. So for example, maybe I'm collecting reaction data on an instrument that is connected to a computer, and it dumps all of the data directly into a Dropbox folder for me. I can go into this reaction data component and go to the add-ons tab and connect my Dropbox folder. So it's a couple clicks of a button. You provide your authentication token to Dropbox, and you connect a particular folder, and then you'll see all that data directly in the files browser. And it just pulls that right in for you. There's a number of different add-ons. The most popular ones are Dropbox, Google Drive, or Fox. It's also worth noting I'm a collaborator with Sarah, but it's not my Dropbox folder. But because I'm a contributor on this project, even though I don't have access to that specific Dropbox folder, because she's provided the token, I can see all of those files here, and she doesn't have to add them to her Dropbox just for that. So let's pop into the lab notebook component. And here I'm using the wiki as my lab notebook. So do you want to talk about... Sure. So where we thought we'd jump in is in a use case where perhaps I'm a PI running a lab, and I've got several grad or postdoc students that are going to be working with me for the next few months, and I want to make sure that I have good visibility into their day-to-day and make sure that everything that they work on is captured here so that the next students that I bring in can pick up this work and continue on. So what I've done is simulated a situation where the notebook is a component that then I would add these various students to. I could also have multiple components within this lab notebook component for each of those students. It's flexible to work with whatever the situation may be, but in this case I've just provided the daily lab entries for these staff to sort of look, and this is very basic, but you could imagine much more elaborate if needed. But basically here I can describe what I want to see in every entry from this point forward. So I want them to give me some description, some experimental setup and design information. I want any data collected here either in a table, which I've sort of simulated a table where they could list out some characteristics that we saw. We'll get into a little more depth in ways in which you could provide data here in context and annotate that data. And finally, I just want basic conclusions. So that's sort of the template for working, and this is something you can make as sort of a home wiki so that everyone coming from here can just copy and paste this into each wiki entry to make sure that it follows the necessary information that everybody expects to see. A question, can the wiki content be duplicated to work like a template as in for my next project? You can duplicate an entire project which would template everything within it. So you could set up basically a component that you want everyone to copy. Or I think it's, yeah, it's not built yet. That's not doing specifically what you're asking for is not possible, but that is a great feature. Yeah, I will make note. Thank you. Okay, a couple details just to talk through about how the wiki functions. Right now you're just looking at the view of what I've already entered, but what you can see is that I obviously started working on this and made several different iterations. And so if you wanted to go back and see the first version of this and that was a version you wanted to go back to, then that's simple to do. You can also compare versions where we can see what's changed from one point to another. This might be useful if one person who started this research project sets a template and then down the road somebody has iterated on that. It's easy to kind of follow that track and know what's changed when and by whom. If I wanted to go in and edit this, this is where we can get into very simple understanding of how the wiki functions. It is using markdown language as the syntax, which is really simple to understand. But if in case that's not something that's needed to your workflow, there are buttons in the UI that allow you to quickly sort of drop things in. So if you wanted to interpolate the list for your report findings, you can just start working that as you'll see on the left side, it's in real time. So things that you want to put in here, you can just add an item or discussion, and you can keep adding more and more. And then you can quickly see those reflected and save that version. So that's a quick understanding of how you might be able to work with a template for setting the stage for the entries that you want to see. If that's applicable, that's how you would go about it. If not, we've kind of carried that theme throughout. So all of the entries in this particular lab scenario are using the prescribed template that we came up with, which is very basic. But here's an example of day one, October 1, 2019, where there's some initial work done to describe what the protocol is that's going to be used and some specifics about the experiment. Yeah, we just used a template from the other page. And then I think here we have linked to this protocol that is stored in another component, but we'll show you in a few minutes how you can actually embed files in the Wiki as well. And we've used the numbered list and the bulleted list and markdown to describe each of the steps that we took to produce this solution and then also dropped in an image that renders right in the right in the Wiki. If that's part of your workflow, it's easy to put those things in along the way. Yeah, and real quick, let's open up the edit page. You kind of see how this is constructed and you go. Obviously the markdown headings and the numbered lists are here. I don't know if you want to talk about how the image was actually put into the Wiki, but I think people would want to see that. Yeah, I actually just dragged and dropped that from my desktop right into the Wiki and then it uploads that file into a folder on this component called Wiki Images and renders the image right there on the screen. Okay, I'm wondering if I might have something quickly. This is nice, I think, because like in this example, if I were in my lab making this solution, I'm just taking a picture of what it looks like. It's not something that I'm going to take lots of images. It's not microscopy images. It's just something to say like, this is what it looked like at this point in time. It's easy to just drag and drop in the Wiki. I'm not really going to do a whole lot more with it and organize it in any other way. Okay, let's jump into a little bit more of the details that we were sort of living to earlier, which are ways in which you can describe more specific things that are happening in other places in your project and bring them right in here so that you don't have to bounce around. One item might be that your experimental setup is actually easier to describe by just providing the video. So the Wiki supports video embeds of multiple video types. I chose to just drop in a YouTube video, but it's a very simple syntax. You just, here it is right here, use the at symbol YouTube and drop in the URL. Then you can describe different pieces of that. You could pull out screenshots, still images from specific stages that are happening in that experimental setup and drop them right in and actually describe them for anyone else who needs to come in here and understand exactly what was done at that time. If we move on to the next iteration that we wanted to show you is around the ease of just sort of embedding files directly into the Wiki space. So this is going to show you a protocol file that was embedded directly here and it's rendering as just as it would in the iFrame in the browser. So you can scroll if there are multiple pages you'd be able to scroll. You have all the functionality that you have here where if there's any more pages, I mean everything is easy to sort of see in one place right here. So the way that you would do this, it's a very easy syntax. You just use the at symbol, the osf, and then you put the GUID for the file. And then you can carry on with describing and annotating. You could do multiple files. You can make this as long as you need to or you could break it apart into multiple Wiki's. Another aspect that is pretty neat is that if there is another project that you want to reference in your specific research project, you can do that just as I did previously, which is to take the GUID of a file from another project and drop it in. This is what I have done here. This is another project public on the osf that has to do with tumor cell images. And I have used the same mechanism to just use the GUID of this particular file and embed it right here into the Wiki. And one of the features that you can use on just regular file rendering within the osf that also actually carries over into the Wiki is for these really high res images, you can zoom in and pan across the image to see specific areas. So I'm going to try to demo that for you real fast. What you need to do, one, there's this really handy helper function here, but you can zoom in by clicking on the image and scrolling. And then you can move your mouse left or right to pan. I think there's a lag. I think you're seeing this. Hopefully you are. But I encourage you to go try it out too. This is really nice because a lot of times these images are really difficult to bring into an interface when there's so much high resolution data there. And just to clarify one point, Nikki kept mentioning the GUIDs for files. Those are those five character IDs at the end of the URL. So that's all you need to know to be able to embed these images. So this is the file that I pulled in in the project. And I just captured this five character GUID that references the file to persistent identifier OSF. So I'm able to drop that in. And it recognizes that. Let's see. What else? So a couple more details that I don't think we gave a whole lot of context to, but I'm happy to do that. Is that files support tags? So you can tag those files if they're probably for easy discovery. The recent activity logs on this project specifically that Sarah and I are collaborating on shows what actions I've taken and when I did them and what general updates I've made. So that's really helpful if you've got a multi multi collaborative project where you've got different people engaging. If you want to just if you're not necessarily part of the day-to-day but you want to come in periodically and check the activities that are happening. It's really easy to scroll through the daily entries to see who made changes to what and when they did them. I think that is a good introduction. I can switch back to the slides. There's a couple more examples besides the live demo, but before I do that I actually want to pause and give an opportunity for any questions that you might have in mind that we didn't show or you want to see again or that we didn't give all the answers to your questions. In the live sort of demo before I give you some references and look at those together. So does this mock-up have a dmp or remade.txt to describe how to name the files, file formats for the data in this demo? That's a really good question. We actually do not have in the example project, but that's a really good suggestion. I think a really good thing, probably at the top level project would be to add a file that would be a data dictionary that might describe what the columns are in all of your files, a data management plan that describes. You generally produce these when you're applying for funding, how you're going to manage the data, and so certainly including a copy of that in your project would be a good suggestion. And then file formats for the data. I'm not sure if you're asking the OTSS supports any file format and then it will render all of the most common file formats in the browser and they can't be rendered in the browser then you'll just see a message that says you can download the file format. And then with another question, could you show again the way to add the high resolution image to the wiki? Sure can. So if I go over here to the project where I pulled the first image, I will actually choose a new image to embed and I'm going to click on it so you can see it here, which will also give me the GUID so that I can take this and I'm just going to copy it right out of the URL. And I'm going to go back to the, let's see, pick a wiki and go into the edit page for the wiki and show you how. So here, this is how I did the first one, that's the first image you saw. So if I did this again, I would take at a US square bracket, OSF, and then put in parentheses and I just paste it in the GUID for that second image. And it should start to show up, yep, there it is. So it's the second image that we pulled off of that other public project that had some prostate tumor cells I think. And then I can save that and in the same way you can zoom in pan for high-res feed. We have other questions coming in yet. Do you know if OSFDLN is comply with US government FDA regulations? I do not know the answer, but I might be happy to follow up. I would be happy to sort of explore that and follow up. I'm not sure that we have your information, but if you could provide that, we'll certainly look into that. Okay. Is that all the questions we have for right now on the live demo? Thanks, Aspect. Anything else to show? Okay. There's a couple more that I wanted to point out. So this is a project also public on the OSF where someone has actually been using the OSF as an ELN. And these are examples from their entries within this lab group. So their taxonomy for naming within this sort of ELN component was each person in the lab puts their last name and then the entry for their lab notebook for the day. And so it looks like they've certainly got a lot more code-specific things that they're putting in. They seem to be having the same sort of template that we were using or something similar. And so you can see how that is applied sort of across the team for each person. Took the template, copied it into their entry, and then filled it in. So here's a really good example to sort of complete your awareness of opportunities that exist out there. There's also another project on the OSF that's public or Cambridge did in the ELN pilot. And so there's a lot of examples in this and also I think a video that demonstrates a lot of what we show today. So we will certainly are recording available so you can do that. But if you want a second recording that you could take and show to others or make part of your resources if you're within an institution or a lab that you want to share with others that may want to see some examples. Okay, but we're happy to continue to follow up our questions that come to mind after we finish today. There's also a really good there's also a really good help guide that breaks down with pictures and a lot of great text of how to use the wiki in those special syntaxes that we showed you today. And obviously we're always available if you have questions just reach out to us at contact at www.seagulls.com. Okay, thank you very much. We appreciate it.


Όλοι, το next talk is from... or wise and it's about Python RPC and it pops up over web sockets. It's a pre-recorded talk and we will play the video and then the Q&A starts with our... Here as well and you can ask your questions to or about his presentation. First of all I have to say that I am amazed that I have to host the session from home and have a great talk everyone. Hi everyone, I'm really happy you are joining me in this talk. We are going to be talking about Python RPC and it pops up over web sockets. I'm more wise and founder authorizing it previously at Rookout. I come from a cyber security and development software engineering background. And I love Python probably just like all of you guys and I love building things with Python. And I'm excited about sharing what we've built here with you. So before we dive into the open source packages that I'm going to share with you and I'm going to go into their design and into their concepts and also how to use them. Before that I'm going to talk about the problem space itself. So as you all know the cloud is growing, the edge is exploding, more and more elements of software are kind of eating up the space and becoming more complex, adding more elements. It's no longer just running a simple server on one machine, it's multiple instances, it's multiple services in the cloud, third parties interacting with one another. It's edge devices, IoT compute devices that are deployed across the field. It's things running both on-prem and on the cloud collaborating. Obviously crazy scale of stuff like Kubernetes and serverless where it on the fly changes the amount of instances that you have and obviously things that are going towards the edge. With all of this complexity, our software is becoming more complex and we need to connect all of these elements together. We need to keep them in sync. We need to find a way to share data between all of them. At the state that we have on the on-prem sync with the cloud and what we have at the cloud also sync to the edge. And the obvious question that remains is how do we do that? How do we connect and scale everything with this ever-growing complexity? So that's what we're trying to solve with these packages. This is what we'll be talking about both with RPC and Popsup while using WebSockets. Before going into the specific packages themselves, let's look at a specific example. And I brought the example that brought me to develop these packages. An open source project called Opal, which you can find at opal.ac. Opal deals with the world of authorization. So let's say we have an application and we want to control who can access it, the different roles, permissions within that app. A modern way to approach this today is to use something called OPPA, Open Policy Agent, which is essentially a microservice for authorization. The application can query it at any moment in time to understand if it's allowed or not allowed to perform an action. But as our application scales out, we are confronted with a problem. How do we keep the state of the application and the state of the authorization microservice and also the state of all the other relevant data syncs that we have, our billing service, our sales management, all of those different elements that comprise our solution. How do we keep them in sync with our authorization layer as well as with our application? So this is where Opal comes in. It's essentially a layer to synchronize the application and the authorization layer. It uses both a server for main management and a client that sits next to each policy agent filling it with the data that it needs. And it does this through a WebSocket Pups of channel, which we'll be talking about in a minute. That channel allows Opal to keep OPPA in sync throughout time as the application progresses. And with every little interaction when you're adding a new user, when you're inviting someone new, it will integrate that information into OPPA instantly. If you're doing or you're building authorization for application, by the way, I really recommend that you look at both Opal and OPPA. So this is one key example of how we need to have something that's spread out, our entire application with the different sidecars of authorization. We need to keep all of those in sync with things that are running on other clouds in addition to ours. So let's break down the challenges or requirements that we have here. So first of all, we need this to be real time. We can't afford to have a polling solution. We can't have everything delayed. When you apply an action in a modern piece of software, we expect everything to apply in real time. For example, in the Opal case, if you invite a user in, you expect the user to be able to access that application immediately and not that the next deployment or when the next polling interval hits. In addition, we want it to be bidirectional. We want both components to be able to share data with one another. The concept of a server and client, when you're talking about cloud-native infrastructure, kind of deteriorates. Both sides need to trigger one another sharing data. An updated one layer at the authorization component, for example in our, in the Opal case, can affect a different client or a different server. We need all of those to constantly be in sync, so they need to be able to trigger one another bidirectional fashion. We need easy networking. So we already mentioned this. We're looking at the cloud, we're looking at the edge, and we need all the different components, no matter where they are, to be able to communicate with one another. So we'll be traversing the entire internet. We'll be traversing firewalls, we'll be traversing routers, we'll be entering VPCs and on-prem networks, and we need it to be, no matter where those software elements are deployed, that they'll be able to communicate with one another in a bidirectional, real-time way. So we need something that enables us to go with easy networking, to traverse with ease. We need something in addition that is durable. Because of that widespread area and a lot of different connections, a lot of those connections might be severed at one point on another. So we need a system to be durable. We need it to be able to survive and reconnect as things change. And lastly, we need it to be scalable, especially if you want to run this on Kubernetes or serverless or anything of modern scale today. It always ends up relying on the ability to take one instance and scale it out to many to support higher worklines. So these are all their requirements that we have. And now let's look how we can use the different elements of architecture to approach them. So we'll be looking again, RPC, PubSub, and WebSockets. So for the real-time bidirectional aspect, WebSockets are really a good way to start. First of all, they create a bidirectional channel. While they rely on HTTP, they enable both sides to trigger a conversation on an ongoing channel. So unlike general HTTP or restful HTTP, where you trigger a request, get a response, and often terminate the session, WebSockets stay up constantly, and both sides can trigger queries or requests on top of that channel. WebSockets also contribute to easy networking. Because they're based on HTTP, most routers, most firewalls would be very forgiving for them. And also they save us a lot of friction with creating an easy direction. So clients can trigger an outgoing HTTP connection, going easy through the firewall. But after the connection is established because it's bidirectional, now the server can also trigger requests on that existing connection. Durability and flexibility we're getting from RPC. The basic concept of RPC is just being able to call remote functions. So you'll see what we'll be doing is exposing specific Python functions to the other side. By exposing functions, we're essentially connecting the two Python interpreters, enabling any element of code to be shared between them. So we can add more functions as we need to get to both the durability that we need to kind of maintain that, and also to add more capabilities. Lastly, PubSub, the ability to subscribe to events and publish events and have those reach all of the subscribers, will really enable us to take this to scale. So in a minute we'll see, we'll be taking a one-to-one RPC channel, and then we can create many of those. On top of that, through the extensibility that we're getting out of RPC, connect it to a PubSub channel, then move from a one-to-one kind of relationship to a one-to-many kind of relationship. So let's dive in, and we'll start by looking at the design of the first package that we've built, FEST API WebSocket RPC. It's called FEST API, by the way, because one of the fundamental building blocks that we used is the FEST API server, which I'll elaborate more in a minute. So first of all, the basic component of our RPC connection is the RPC channel. Essentially, it's a JSON-based channel that provides the ability to pass both requests and responses for functions. Our request will be targeting a specific Python method that we exposed, and in the end it looks something like this. As you can see in the screenshot here of the code, we can see we have a server that inherits from RPC method base, and it exposes specific methods. For example, in this case, we can see it exposes a concat method that takes two parameters, concats them, and returns the string value. On the other side, we'll be calling these methods for an interface that looks something like this, other.method and calling that method. So in this case, we'll be doing other.concat and passing the two arguments that we want to concatenate. So to build this, we'll be using asyncA. As you can see, our functions here have the prefix async to define them as async functions using core routines. This will really enable our code to be suitable for real time. Things will be running concurrently within our RPC server and RPC client. Obviously, as we mentioned, we'll be using WebSockets for having it bi-directional, and we'll be using Pydantic to get serialization. Pydantic really works well with Fest API. It's a native library that Fest API uses, and we'll be using it to define our RPC messages, both for requests and response, and we'll be using Tenacity, another cool library, to maintain that durability that we mentioned. So first, let's look at a key piece of code in our RPC server. When it receives a WebSocket connection, it reads JSON content out of it and uses Pydantic here with RPC message to parse the data, and then we get basically a Python class code message, and we can check, is it a request or is it a response, and then trigger the behavior accordingly. So that's really the basic functionality that we have, to pass on a serialized message, have it target a specific functioning with the specific parameters and have that invoked, wrapped into our response, and then sent on the wire as a response where the other side can wait on it, and then receive the response, parse it, and pass it to the calling component. Within the RPC client, which is triggered via a async with call, we have our basic wrapping using tenacity. Basically call our connect method, wrapped with retry, and we pass in a configuration telling it to constantly retry. So if it fails, if it throws an exception, if it gets disconnected, tenacity will take care of reconnecting for us. Tenacity provides flexible configuration. We can literally go into it and tell it, we want some exponential backup. We want you to wait ten minutes before you try again, stuff like that, and we can expose that. FestAPI WebSocket RPC exposes that to the user. So you can also use it directly yourself from there, but it also comes with exponential backup of some randomization just as a good best practice. So that was RPC. Now let's see how we take it to the next level So RPC enabled us to do a kind of one-to-one conversation. Now we want to go and enable the one-to-many. And we want to leverage RPC to do so. So the basic component that we've built within the FestAPI WebSocket PubSub package, which you can find here on GitHub, is the event modifier. It essentially registers subscriptions for callbacks. And you can see this is basically the signatures of the main methods of the event modifier. And you can see the main one that I've opened here to your callback. It literally picks up the subscription that's passed to it when you call notify, and it just calls a callback function. So that will really work well with our RPC implementation, because RPC, as you remember, is just about calling functions. So on the subscribing side, using RPC would just be accessing the RPC channel, going into other and calling the subscribe method. So we're literally calling subscribe, the same logic within the event modifier on the remote component. And when we publish an event, it works the same way. We call back into the remote component and say, hey, publish an event for me. So just by relying on the RPC's callback architecture, we were able to plug in something really simple that just remembers who subscribed to what, who subscribed to which topics, and then just call callbacks onto the remote side. So in that fashion, we moved really quickly from having a one-on-one interaction to a one-to-many interaction. Lastly, we need to be able to not only scale out on the clients, so imagine now we have a PubSub server and we have many clients serving it, but we may want to also synchronize with multiple server instances, because remember, we want to be able to run this with multiple workers. We want to run this on Kubernetes with multiple instances or on Lambda serverless with multiple instances. So now we need to sync those multiple instances. So in case we have one client connecting to server one, but server B is the one that's triggering the notification, it will propagate to the right server and then through that to the right client. For that, we're using another library called Broadcaster, which is also really cool. It enables you to, in an abstract way, to interact and use both Redis PubSub, Postgres Listen Notify, and Kafka. All are classic, basically, message queues that we can use, and we use them essentially as a backbone PubSub. So our own PubSub relies on the backbone PubSub to propagate messages between the different instances of the server. So this has a key advantage of shifting the workload. First of all, deploying, let's say, a new Kafka instance can be rather heavy. By shifting the workload to the WebSocket PubSub, we basically enable most of the work to happen at each server node, and only when we have to propagate it to the Backbone PubSub. So we can then utilize less resources. Unlike our first API WebSocket PubSub that we're describing here, Kafka, even RabbitMQ, they require more resources, they require memory, they require storage on disk, they require more redundancy. So we can save a lot on those resources by only passing what we need between servers to those there. But still, we can connect to them really easy with the broadcaster interface with our FastAPI WebSocket PubSub package. So let's have a quick review of our stack. So we're using FastAPI for the basic server infrastructure. We're using WebSockets for the clients WebSockets, because FastAPI, while it's great, their client implementation has some hiccups. We're using PyDentic for serialization, both for the subscriptions that we're passing on the wire, and obviously, as we mentioned, the messages both for RPC requests and RPC responses. And we use Tenacity, as we mentioned, for the durability factor for the ability to reconnect when things fail. And we're using Broadcaster to expand our PubSub in servers, if we need. So now when we have a basic grasp of what these two packages are and what they deliver and how they address the problem, let's see them at work. So we'll start with the RPC side, and we can see here two simple examples of both the server and the client using the package. Let's start with the client code. We can see that the client is running within an async IO loop and essentially just calling concatenate on the other side. So we have client.other.concat, and we're passing the values that we want, and then we wait for it until we get our response and we print a response out. In addition, we have the server side where we can see that we expose one method. We can expose that concat method, getting those two variables and concatenating them and establishing that into our FEST API server via a RPC endpoint, just pass to our concat server definition, exposing those methods and running this via UVCore. So let's just run this and see how it behaves. So we'll start with the server so it can wait for the connection. So the server is up and waiting and now when we trigger the client, we can see it run and we can see that we got our concatenated string. It essentially ran on this interpreter, went to the other side, called this function, got the value, got it back and printed it. We're ever straightforward, but still a pretty cool response and it works smoothly. Now let's move for a slightly more advanced example, bi-directional interactions. In this case, it's not only the client calling functions on the server side, but also the server calling functions on the client side. And we'll be also using those for synchronizing between the two sides, between the two components. So you can see here that in addition to the server exposing the concat method, now the client also exposes methods. And we have two, we have allow queries, which is essentially a function that signals an event within the client, telling it that it can start sending requests to the server and we have allow exit. So it will tell the client to wait a random period of time and then exit. The server essentially controls the interaction with the client. The client here does just as we described, it connects to the server and then waits for the server to trigger it via calling that method and setting that event. So it waits for that event to be triggered and otherwise it doesn't continue. It then calls the concatenate method just as before on the server side and prints the result and then waits on the server to let it know when it can exit. So let's run this, oh, one more thing, the server side, in addition to exposing the concat method, it uses on connect to tell the client after it waits for a while to trigger its queries and when the query of concat, when concat is called, it also in addition to returning the value, it also in the background triggers the allow event for exit. Okay, so let's run these examples as well. Again, starting with the server. So we're running the bidirectional server example. The server is now waiting and we'll run the matching client and you can see that both sides interacted and then now after that delay, the client exited. So we saw that exact flow and of course also the concatenated stream that we wanted. So you can see we can have both server and client triggering methods at one another and also using those for synchronization which is really great when we're working at scale. Let's take it a step further and now let's talk about our Popsub client and server. Here we have a slightly more advanced example where we'll be combining, in addition to Popsub we'll also be combining a classic RESTful API server with FastAPI. So let's start with our server example. So our server just as before in its FastAPI and exposes instead of an RPC endpoint, a Popsub endpoint and it exposes a regular HTTP route at slash trigger that sends event through the Popsub. We can see the function that is called, it waits a bit and then it publishes the events for guns and germs. It waits a bit then it publishes an event for germs and then finally it publishes an event for steel and adds data. This is a reference to a book that I like just by the way and this is the offer of that book. On the client side, we have that mirror image of a client initiating and waiting for events for both guns and germs having a callback to on events. So we'll be seeing this print happening when that callback happens and we'll also have another later subscription to steel where we are calling a different method where we'll be printing these information, these information points and also terminating the client which is kind of similar to our allow exit kind of behavior before and obviously running this as async AO. So okay, let's run this again. We start with the server just having it up and running. We'll have the client running and nothing will happen here initially because everything is waiting on our trigger event. So now let's go and approach our server locally and so we triggered the server and we see that in addition to the browser we're asking for the Feb icon which is interesting, the trigger went correctly and it triggered the events on the client side as well as the final event triggered by this goal also passing data. Awesome and now if we had we can have multiple clients subscribing here. You know what, we can actually do that and you know why it's not interesting. So we can have multiple clients subscribing here and all of them receiving the updates at once running in parallel. So we reviewed the codes and now you know if you want to use these packages you can go in, fetch them from GitHub or from PIP, you can just PIP install them. PIP install can do PIP install FEST API WebSockets RPC and PIP install FEST API WebSockets PubSub and they're ready to go and you have those code examples also available in documentation on our GitHub. Really easy to start. So that was our session, I hope you enjoyed it. I invite you to stay a while and listen a bit forever and ask me questions in our breakout room which you'll be getting a link to in the chat right now. And of course you're welcome to look at these packages that I've shared with you as well as other projects that I've built that use this. Authorizing that I've built with a soft coin which also leverages OpalAC which is a solution to manage your authorization and OpalAC that I mentioned that is synchronization layer that uses FEST API WebSockets PubSub to make sure that the data reaches into your open policy agent and also Rookout which is a previous company that I created that while not using these packages uses a similar pattern to enable you to set breakpoints on the fly in production. So those breakpoints when they're triggered they're triggered through a WebSocket connection that runs within your code waiting for you to set that breakpoint. Cool. Thank you very much. I hope you enjoyed this talk and look forward to hearing your questions and getting your feedback and both here on PyCon as well as on GitHub you're welcome to open board requests, issues, requests and I'll be happy to chat with you. Thank you very much and enjoy the rest of the convention. Hi, Or, how are you? Great. I hope everyone enjoyed the talk. Unfortunately the talk was a little bit longer but I have I think we can cut one question which is why would you use PubSub over WebSockets on Message? Over on Message? So why would you use PubSub in general? So the PubSub channel will give you the kind of scale instead of having one you can have many instances at once and with the PubSub solution here explicitly you can also scale it out and then mention the talk through our PubSub solution so you can also scale it out on the backend side. Hope that covers the question. Okay. Unfortunately I have some connectivity issues. If that's okay. I don't think that we have more time for another question but you can always reach our room. Also if you want to check with me longer time you can find me at OpalAC there's a link to a Slack channel there happy to answer questions all day long. I have to say that this was a great talk for me. I hope that you liked it and I hope everyone enjoyed it. Thank you.


So welcome everybody. It's early, I suppose, in the conference. What are we? We're a day tree, I suppose, but really, the kick-off start today. So I hope you're all having a great time. You're enjoying Vancouver. Vancouver is definitely one of my favourite places around. It's just the views, I think, and the way we're looking over the the Convention Centre is fantastic, I think. So today I want to talk about, you know, climbing that mountain from valley of force becoming a contributor, you're making that first contribution, and then getting up to the Zenit of Maintainership. I suppose, when I started out in open source, I heard a lot of phrases, and we'd go through some of them as we go along, but one of them would be, you know, chop wood, carry water, you know, look at the good first issues queue, you know, make yourself known in the community, you know, just get involved. But these are all great phrases when you know what they are, or you've been part of open source communities before. But if you're new to a community, they might make as much sense to you. And being able to understand these things are very important because we need to be, I suppose, more inclusive for folks, so they have a better understanding so we can grow our communities. So maybe rather than thinking of phrases like that, we should think of things like, where can I get started? Where is this first issue queue? Can you help me get introduced to people in the community? Maybe I'm kind of shy, and I'm not really the use of going up or talking to people or putting things out on Slack or whatever. And how do I find out how I climb that ladder into my next role? So if I make my first contribution, how do I build on that? And then eventually, is it achievable for me to get maintainer? So I'm going to talk through some of this today from my experiences, and mostly around the Helm community, which in the last few years, I've built up my contributions and gone towards the maintainer and onto the TOC. So who am I? So my name is Martin Hickey, and I work over at IBM. I'm a maintainer, as I said, in Helm, and I'm also on the TOC committee of the techno oversight committee of the Helm community. I've also made contributions to Kubernetes, open telemetry and other communities. And really, open source is a huge part of my life. And it's something I've really, really got a kick out of doing it for the last number of years, even more so than anything I've done previously in different jobs. So this is just a kind of overview of what we're going to cover today. So let's get started. So hands up here, who's a tea person? We've got hands. Sorry. Hands up for coffee folks. Okay, so, you know, I don't want to get into the whole debate of coffee, tea, snobbery here, like, but let's be fair about it. There's a wide variety of tea out there than just coffee. Okay? And as different variations, and if you're a tea person, well, you know what I'm talking about. But on a serious note, I think one of the first things when you get involved in open sources, like your tea, picking the right one for you is really, really important. And why do I say that? Because I think when things start getting difficult in community, and things will always get challenging as you go along, when you pick a community that you're really into, or technology you're really into, you have a better chance of staying with it during the difficult times. Now I've put in last tricks here because sometimes that's out of our hands. Sometimes our manager or company says to us, right, we want you to go over to that project and work in that project. And that can work out sometimes. But if the option is there, think about it.  You can always change. And an example of this is a person I was mentoring a number of years ago, because they were using tecton, and they want to get involved in open source, they said, right, I want to go into tecton. So first of all, they came to me asking me about helm because helm was my area. But one of the first things I pushed back to them and said, before I give you the details how to get involved in helm, I want you to write down your five top projects in order of preference. And when they came back about a week later, they probably thought I was mad because it was the first minter session and I was already pushing them away to come back. But when they came back, would you believe helm was number five and tecton was number one? So over the next year, they got involved in tecton, they started making some contributions. Well, what I noticed after a couple of months was they didn't start going to the next level of doing reviews of PRs, triaging issues. I didn't see it building. So after about a year, I said to the person, I said, no, what's wrong? And I forced them a bit reluctant and then they came back and said, I don't know how to say this, but I don't enjoy working in tecton. And this is not because it's tecton, it's just themselves. It wasn't what they felt they wanted to do. So I said, that's okay.   I like serverless. I want to try Knative. So they got into the Knative community. And I'd say within six months or a little bit more, they suddenly were a committer. The next thing within about nine months, I'd say they were a maintainer on the project. They just blossomed and they've grown from there. They're on the TOC committee and that person has really, really found their feet. So choice is very important. So here's the one that, you know, a lot of hands up here who don't, who doesn't like writing documentation. Yeah. And I'm glad many police end up there because I know he definitely doesn't like writing documentation. He always gets someone else. You know what? I was in both camps, but I'm a strong believer in documentation as we go along. And you know, for people maybe that haven't worked in open source communities or use open source communities, you'd be surprised the quality of documentation in open source communities, not all of them, but when good quality docs are there, they suppress any product documentation. And you're probably asking why? Because the reason is they have to cover the full life cycle of the project. They have to show how people to get. First of all, use the project, but then also to become contributor and move up along. So if when you come into open source project, that documentation isn't there, you know, go and help to make it better. But why do I say read the docs? Because when you have a community that has put good documentation in place, it should cover everything. And this is from using the product, setting up your development environment, contributing how to make your way up the ladder from basically contributor up to maintainer. It should all be in there. But also by using the documentation, it gives you a great starting point to understand how the project works. And also, it's a great place to find bugs, which I'll talk about in a while. Because if you're using the documentation, you cannot do what you want you to do, then you know that you can already start pushing PRs and help make new contributions in communities. So it's a nice way of getting you started in a nice, easy fashion. Also, it'll tell you about how the meetings and where the slack channels, et cetera, are that you can start getting you involved.  And do everything from the basis of the documentation forward.  And it really gives you a nice way to understand the project and ramp you up in a kind of silent fashion. So if you don't want to get out there straight away, it's a nice way to where you can play around with things, see how things are going. And as I mentioned earlier, if you find any issues with the process or with the documentation, you can start pushing changes already and raising issues.  But it's a nice way of getting your confidence up, you know, when you're starting out. So become invisible. This is always a hard one I deal with because, you know, people always say to me, you know, you're very outgoing, you're very, you're very friendly. You know, I have to work on that as well. And one of the things I found the hardest is when I first went out to open sourcing, it was an open stack was someone said to me, okay, go out into what was IRC at the time. If you don't know what IRC is, it was the precursor to Slack today is a communication channel. And, you know, so I went in my first day and I said, hi, I'm Martin. I'm going to work on here on this and I'm really looking for it. I mean, like it was tumbleweed, not in comeback. All right. So I said, okay, I wasn't unperturbed. I said, I give it a week. So a week later, I went out and did the same thing. Nobody came back again. And what was worse was, there was people definitely that channel that knew me and they didn't even respond to me. You know what I mean? So I was thinking of getting some in my family on IRC to respond at least. All right. But I'm joking about this, but this is what happened. And I went, flip and hell, this is going to be hard going, you know. And it is tough when you're trying to start out. And the idea of being common visible isn't that you have to be up there and, you know, doing crazy presentation or a keynote speaker or doing so many amazing stuff that folks do in the communities. But it is a case of getting to know people. And, you know, no matter what technologies we bring in in this world, it's people that make these technologies.   It was great to see him like and some of the folks that I haven't seen for a while as well. Like, you know, this is what it's about. It's getting to know people so that when you're working on a topic, and there's a misunderstanding maybe over a digital communication, you know, you might meet in the hallway here at the conference and say, right, look, this is what I'm trying to do one day. I go, oh, yes, that's what you're trying to do. I thought you're trying to do this. No, no, nine times entertaining. It's a misunderstanding. And you can work together to get it there. So that's where the visibility is important. And so many things that I mentioned earlier about is, you know, finding those little PRs at the start, you know, I know people say go to the good force issue, but hands up, who's ever gone to a project, good force issues and actually found something that wasn't stale or already done. You were saying you did, Nigel? What community? Okay. There'll always be one that'll ruin your pitch, you know. Okay. Thanks, Nigel. But more often than not, and this is not going to do with the maintainers in the project or project itself. It's just good force issues are hard to keep good force issues going. And what I'm kind of looking at here is how'd you get around that? And as I said, which a documentation, that's the first place to go. And it's funny in the Helm project when we released Helm 3, which was a big change from Helm 2. We changed the underlying infrastructure. There was no longer a service inside the cluster and all that. So it was a big change. Yes, the API kind of stayed the same, but there were certain changes. You didn't have to initialization anymore. We put it all out there. We have the documentations up there. We talked to Kucan San Diego saying, right, I went docs, docs, read the docs. For the next year and a half, people kept asking questions, how do I need to serve us again? And you know what? It's not about putting the URL out there saying, look, here it is. It's about talking to the person and saying, okay, yeah, we don't have to do that anymore. Here's a link to the documentation. But it's just a good way of getting in there. Also as well, and I found this hard as well, is coming on to the meetings because, you know, people come on to the meetings and everyone looks so assured and so confident and they're talking about how the project is going and you're this noob that joins, you know? But it's nice sometimes to come on to it, maybe turn off your camera and just listen in the background. And after a while, you know, what happens is one day you'll have something you want to put forward. The Slack channels as well is very good way because for two reasons. Number one, you learn a lot like the meetings, what's going on. And then over time, you might see someone that has a problem that you saw and you can help them with. And that ability to help somebody is just brilliant in life. It makes you feel good about yourself, but also it brills up your confidence. And all of a sudden, slowly but surely, you're getting there without having to go out and say, hi, I'm such and such. Everyone say hello to me and then everyone says nothing. Okay. So it's a nice way of getting going bit by bit.   But over time then, when you get it, if you can get a chance to come to some of the conferences, then you can get to get to know people in person and talk to them by their name. Okay. So before we move on to the next part, this first part I was looking at is when you're making those first contributions and trying to get involved. And the key parts that to take out of that is picking your project is so important. Don't ditch the docs. Nice alliteration on the D's there. I'm happy with that one. You know, try things out and slowly but surely you'll start making yourself visible. And I don't like the word visible, but I'll use it here because I can't think of any other better word, you know, because it's not about being visible in life, but it's get knowing because it's like everything in life is when you build rapport with people, then it's a better chance of you being able to push in your PRs and make changes, etc. So now we're going to look at going from making those early initial contributions to become what I call, you know, a committer or a serial contributor. And this is what we look at next and it's building that respect as you go along. Has anyone ever heard the phrase don't be a drive by contributor? Okay. So I'm trying to get rid of those phrases again and really all it means is contribute regularly. Okay. And like you can see here the folks on the roof here, you know, they're all working together to build, to put the roof on this house. And that's the same in the community. No one person can do it. And if log4j had taught us anything, you know, you cannot let it on one person to do everything because they just can't. It's just a part of life. And if we've learned anything as well from COVID over the last few years is, you know, we're not solitary people, we need to talk to people, we need to, you know, we need to communicate with people, we need people to help us out in life. Okay. So getting involved and pushing PRs. And like, you know, if you start off forced and you don't, you don't have the confidence or whatever, as I said earlier, look at the PRs that come in, you're learning so much from that. That's the start. Maybe I did it at the start in a lot of projects I joined in, especially in OpenSec where I literally just look at the PRs, he'll eventually I confidence to make a comment. And don't worry, you know, everyone gets a comment wrong. Maintainers get things wrong from time to time. We put a comment in and some guy, what do you mean? This is what I mean. And then you go, okay, sorry. You know, I miss interpreted. It's the same that if every community should have respect for you, that even if you put in a comment, and maybe, you know, it wasn't exactly the right thing to say, people give you constructive feedback. Okay. Nobody should show that you will give out to you because you got something wrong. Everybody gets something wrong. Nobody knows everything. Okay. Michelangelo always said, I am still learning. We are all learning in life. And that's the nice thing about it. So if you want to build up your trust in the community and get known where you're moving towards the next phases, which is towards maintainer, here is where you build it up by working on things and being there regularly and making the contributions. Also to the triage of issues is really important. And maintainers really like people who do these things like triage of issues because we as maintainers do not always get to it. But somebody who's willing to come in, even if you don't know what the issue is, but you're willing to take the issue and try and reproduce it. That's the fourth step because that's what we do. We have to take you to and foresee, can I force you to reproduce this? And if you go and do that and at least put a comment in go, sorry, I tried that, but it didn't work. Or I was able to do this in such and such a fashion. That's fantastic and give the feedback. Now, if you can reproduce it, reach back to person, don't go, oh, I don't think that's an issue. You go, well, I tried it this way and it doesn't work. Can you give me more feedback to troubleshoot this? And this is usually the stage where you go, you always assume, I always assume people know more karate than I do. And when someone comes in with an issue, you have to take them in good faith because they believe that's an issue and it's something that's affecting them. So the first thing is take the person seriously and do due diligence. And if you can reproduce it, reach back and whatever. And you'll often have that back and forth with the OP person who raises it. But that's a nice way as well if you want to get involved is that you can try that and you're working it because we as maintainers will see that. We'll see such and such in that handle. They're great. They always come in and try things out. They always see if it's an issue or not. And then sometimes then if you have the confidence in you might say, do you know what, I'll push the PR for this because I think I can fix this. So yeah, that's the process and getting involved with that builds you up bit by bit. And suddenly this is where you'll see because remember here, contributions aren't just pushing code, their documentation, the triage in bugs, their reviews on PRs. These are the fundamentals that keep the community going. Features and everything else are lovely. Okay, but really it's the core part of it. You know that when you have a stable project, you know it's keeping that project stable is important.  Okay, so like life, be authentic, be sincere and be kind. And the last one kindness and compassion are the most important things in life. Okay. And if you know stuff has ever come to your door where you have somebody who hasn't been well or maybe it's coming to the end of life, kindness and compassion is the greatest thing you'll ever show anyone. Okay. And it's the same open communities. Okay, it's not about being right. It isn't about being shielded from the big bang. You don't always have to be right. You know, we can leave it go. Okay. And unfortunately, there's always someone who is just that person who decides not to be nice. And just if you feel you're going to, you know, for anyone that's older that thinks, you know, you can behave in a certain way in open source communities, this is the beauty of open sources. The ability here to basically say, right, we're all one people. We're all trying to work together. This is what we expect the behavior of people that if you behave in a certain way, you will be called out by the court of conduct. If you keep doing that, you will be blocked temporarily. And then if you repeat again, you will be removed from the community and I've seen it happen. So be nice to people.  Be nice and help folks. And we see that as well from a maintainer perspective as well is we often get comments that you know, are a little bit over the top. I remember someone, someone, they had something in, you know, I put a comment back saying, well, this is the way whatever they misinterpreted and came back in a bigger and then you just stand back and say, okay, this is what I meant this way meant. And in fairness to person on, okay, then, you know, and when you hear, okay, then that's kind of an apology without the apology, would you know, they're back in down and stuff. And it's not about me being right or wrong. It's, you know, we're trying to work together. So the famous chop wood and carry water. Have we all heard of this phrase? Okay. The way I look at this always is, has anyone ever had to clean the drains in their house? Okay. I was shown my son lately about cleaning the drain. Honest God, I've never seen anyone go so gray so quickly in my life. He was appalled. And that's just the drain in the shower. If I take him outside to the main drains, he wouldn't really like it. Okay. If no one likes doing the job, but it's one of the most important jobs anywhere. Okay. And it's the same in communities.  They always want to do the shiny ball feature that's going in the big thing that's going to be massive and it's going to change the world. It's the other stuff that changed the world. It's the simple things we do the same as in our houses or apartments or wherever we live.  The little things keep the harmony and peace in the house, the same in the community. Okay. Look at it that way. And hands up here, anyone here who volunteers for stuff? Okay. Does someone want to be, say, all right, hands up anyone that wants to tell me why did you volunteer many on a serious note? And isn't it amazing when you volunteer, even if you're having a bad time, what you get back from it? It's just like, I teach a group of young boys soccer. And I remember their start of the season, their last year, the season that's coming to the end. I remember going, I had a session, I didn't want to go on the first session of the season. Things were just too much going on. But after the end of the session, I was in great form because they just came back with the energy and enthusiasm and the whole lot and it's lovely. And that's the same in the community. Volunteer, volunteer, volunteer, go out there and help because afterwards, if you're boss or anyone's asking how you're getting on that community, when you're volunteering, you're driving forward. You're doing the stuff, you're willing to put your hand up and say, oh, I'll host the next weekly meeting. All right. Or you become the bulk triager for the week. There's nobody that wants to be the bulk triager for a week. Definitely, especially in the middle of the summer, when everyone's on holidays, because you're going to get trashed. But it's the important part in the community and it's what drives communities forward. One other thing I'd say around that is doing stuff that you might want to do. So when I started a number of years ago on OpenStack, it was in the Neutron Project, which was the networking project. Now, I wasn't a network engineer, but so I was going in there cold, more as a developer than even assistance person. And I'd worked on this particular issue, a bog, and I was just getting going. And someone just mentioned, the maintainer mentioned, all right, well, you're in that area, we actually have this piece of work we need to do. And it was a mandatory piece of work for every project in the community. And it was that instead of having static config files, they generate the configuration through annotations in the code. Now, the minute he, the person mentioned on IRC, I went, oh, no, no. Like I've been around the wild programming. I knew what was involved. It was trawling through thousands, thousands of lines of code and files, finding the places doing the insertions. And I went, oh, no. So I went straight away and I was like, of course I'll do it.  I did it because I needed to do something. And I knew that I needed to be helpful. And I wanted to be helpful. But what it meant was, every maintainer in the project had input on that. It was a piece of work that was mandatory. That was sitting there. No one wanted to do it. Because they were too busy with other stuff, number one and number two, I'd say no one wanted to do it because it was so manual. But afterwards, we used to have these meetups in between the conferences called midterms or midcycles, I think they were called. And I went to a one in Rochester, Minnesota. And I didn't know I needed folks, you know, and I kind of just went, but folks came up to me, are you such and such with that handle? I said, yeah, thank you so much for working on that. And he went to even outside the project into across the whole community, because he got involved and how the builds of the projects and stuff like that would be. And it helped me so much. And he brought me that kudos. And I respect that people said, you are winning to go out and do stuff. And they said, they really liked the fact that no matter what comments came in to me, I didn't take them personally. I just said, okay, I'll fix that. You know, because 99% of the time they were right, you know, and yeah, maybe I prefer to do it some other way, but it doesn't matter. It was about getting the thing done. So, yeah, it helps that way. And the last thing I'd say, I suppose is, you know, mindfulness is a big thing that we talk over the last number of years. But to me, mindfulness is being there in the moment. Okay. Whatever that moment is, and I'm beginning to slow myself down that when I meet a friend for coffee, I'm talking to that friend.  I'm with that person at that time. And it's the same in the hallway tracks. If you meet someone, be with the person, you know what I mean? Talk to the person, you know, get involved. And it's the same in the community. You know, we won't always be able to work 100% of the time in community work. We do get paid by a company, and we have to work on company stuff as well. But when you have that 20% or that 50% or 60% of the time you're in the community, work on that stuff while you're there and be there. Because that's how you're driving the project forward. And that's how you're driving your respect as well. Okay.  And a lot of this really is about helping and volunteering and being there. You know, earning your strikes, making yourself be known. Because when you come to this stage of then that you, this was your goal or your zen itigoto, you know, you're pretty much already there. And I suppose it's akin to, or similar to getting a promotion at work. And I've heard it said before, and I never understood it, you know, initially was, you know, sure, you're already doing that job. No, obviously, that's an Irish way of saying it. No one says, sure, you're already doing that job.  And I think it's the same by the time you come to a maintainer, you look to become a maintainer, you're already doing a lot of that already. Yeah, maybe you don't have the access rights and eventually you get the keys to the kingdom. Do you know those lovely, when the email comes in, GitHub has now given you access rights and repo such and such, you know, click on the URL. Yeah, that's always beautiful.   So the next phase then is probably the nomination process. And that's going to differ from community to community or project to project. So in some communities, it's in the mail to the maintainer list to say, I'd like to move towards a maintainer. In other communities is the maintainers themselves would raise a nomination and say, we want to do a vote on this for this person. And then they'll reach out to person and say, would you like to be a maintainer?  You've shown time over time, you know, what it is to be a community member and so forth. Or in other projects and time gone by, maybe it was the project technical lead would, that person would raise a promotion. So it depends on what it is. But, you know, that's where the documentation is coming in again. Is the ladder, is it documented about the ladder and how you go towards that? And you can ask about that. Also, some communities as well, I know, in open telemetry, to even become a member of the community, you have to show X amount of contributions and so forth. And the same as well, when you went into Kubernetes SIG and Kubernetes. Wait, I like spider-man. So I just put that in as well. So I see today that NGDS, Rob, my phrase like with great power comes great responsibility. Now, unfortunately, he didn't know, seemed to know where he came from, which I'll have to say, I'll have to call him up on that. But on a serious note, like Peter Parker's uncle, it is important when you get to a maintainer, that, I suppose, first of all, you realize of why you're there. It's not for you to have this badge and go around, I'm a maintainer. Look at me. It's about, you know, we're kind of slightly switching roles where you're now going to become what I say is more a facilitator than to be driving loads of functionality into the project. So where now you're looking at, helping other people get stuff in, you know, helping with those reviews, those triages, etc. Really doing the core parts of the project, like, you know, maybe the security work that has to be done. So I suppose in the science community, we've been pushing the fuzzing from the community in the last number of years on our projects. So working on that. And I did some work on that in last year for the help project.  But I always think the key part is helping people and facilitate them to drive forward in the community.  And that's what it's all about is it's lifting the rest of the folks back up like you were lifted up or helped when you were on your journey. Right. So I've done this talk at Open UK, and it was an interesting part at Open UK was around sustainability was a topic that the community asked you to bring in your talk. Now I was a bit confused because sustainability has so many different connotations in my head between, you know what I mean, energy and how we do things, you know, with a compost and everything else up to, I wasn't sure about the community and I don't know if I got it right or wrong, but I'm going to go with what I put up.  Okay. But for me, I suppose it's twofold when we talk about sustainability. On one hand, it's what does open source give us? And on the other hand, what do we need to give to open source? So if I start with the first one, well, open source brings us. And this is something way back when I first went to an open source conference, which I think was in Atlanta, open second land in 2014, I'd say, was the collaboration. All these people who's going to rooms collaborating to get it from different projects, you know, from all over the world, different types of people, you know, arguing and discussing, you know, we're trying to go towards one goal. Yes, you're trying to do things for your company, which are also trying to drive the community forward as well, and finding that balance, you know.  Yes, you might get to our party libraries and build on that. But generally, most companies build products and even companies build similar products. So there was a lot of hell of duplication going on. Yes, they were saying, oh, my one's different to your one and so forth. But the nob of it was the same, you know. And the great thing about open source we've seen over the years is now we're working to be more sustainable, to be more less duplication and more collaboration where we can now build stuff in the community and our products can build up on top of it. So we're not creating the stack and duplicating the stack, we're using the one stack and putting our value on top. And this brings around increased productivity, but also brings over knowledge sharing. Because from what I have seen and what I've experienced is I have learned more in open source communities than I've given back, I'd say, you know, I'm always learning from someone, you know, and I think we're all the same. And we bring that back into our companies or wherever else, because we learn when we're out in the communities. The lovely, the next lovely part of it is that if you've, if you're, if you've a device and you've access to probably GitHub and you've get, you can work in any open source community.  And you're only judged by your GitHub handle or whatever else. No, I don't mean you have to have the lovely panel with greens all over the place to say, geez, I've made three and a half thousand contributions last year. That means you need to get away from the computer and get a life because you're, you're doing way too much then. But on a serious note is you can be anybody. And that's the beautiful natural, sort of organic inclusivity and diversity of open source communities. But, you know, that's built on as well by the great people that work in, in the groups to keep that inclusivity and diversity as well. So it's not just on its own, I'd like to say. And the last one then is our own shared environments and stuff that we can build it. And in fairness companies have been good providing systems and servers like that. The foundations have been very good that we've grown on where we have free CICD and stuff like that. And we can, you know, when we put a project out there with GitHub actions or whatever we use, CircuitCI, you know, it's given for free and we can build our projects on it. Flipping on our own, what do we need to do? Now, this is a phrase that was coined by a former colleague of mine, Chris Ferris, around the free puppy that open source is not a free puppy. So when you get, you know, if you get a free puppy, it's not just for Christmas walks. Just in January, when you're tired of the puppy, you can't put it in the side of the road and leave it there. The puppy needs work or any other pet you may have, you know, you need to feedback into that community. You can't expect, you know, to build your product on a series of open source communities and give out then when you find a bug inside the community, oh, look, there's a bug in there or you need to go and fix it. There's no ye. You know, if you're looking at GitHub, you obviously have access to GitHub. You've got it, you know, you're using it, go and make the fix or do the contribution. If you don't know how to do it, ask how you do it. So this is about giving back into it.  The next thing you have to become a security major, a PhD in security and understand S bombs and other kind of bombs and everything else, do you know what I mean? You know, we're most of us are just hardly Joe soaps. Everyone of us is just hardly Joe soaps. So we don't know to do everything. And we can't be expected to know to do everything. I know I saw that when we were working on the fuzzing and someone reached out as well from a security tag in, in the CNCF about she asked me, like, you know, what, you know, what's your feedback when you worked on the fuzzing? And I said, there's a lot of knowledge you have to pick up around, you know, CBEs, how do you do the advisories and GitHub? You know, how do you do the fixes? How do you do the release? And it's sort of, there's knowledge and we're lucky we had knowledge of that in the project and we could share it. But nobody can be expected to do all that.  The other one around stack and license and I suppose this one is around where, you know, sometimes companies decide they want to open source their stack.  They take the stack, they build on top and they're making loads of money off it and they go, hang on here a second, we didn't expect someone to take our stack.  That's not always the company's fault because sometimes when they're putting out there, maybe they didn't realize what they were, what they were putting out there. So I suppose if you're going to put something out there into community, I suppose know what you're putting out there, your stack, know that once it goes out there, it's, you know, free for anybody to build on it and, and, you know, maybe they will find a nice product off it. Maybe that's just, that's just the part of life.  So I suppose all around there, you know, when you use stuff, give back in a nice way as well.  Yes, they'll be ups and downs. Yes, it's not all roses.  How am I going to get involved? Everyone goes through that.  Nobody is that confident. I don't care who you are.  They have to have self-doubt as well. But it's working with the community, making those communications, building yourself up. And then naturally, that'll bring you towards the maintainer if you want to get to maintainer. And after that, when you get there, giving back and helping the other people that come forward on it. And I think, I think, yeah, that's, that's it for me. So do I have time for questions or are we over time? Does anyone have the time? Oh, it doesn't. Okay. Before I go forward, actually, now they're reminded. There's a follow on talk here from Dawn, just here at the front. And she, she's actually going to go forward with the right, a really nice talk. She, the correct pronoun. Yeah. Yeah. Day, sorry. And day is going to go forward with a really good follow on talk where, you know, walk around the maintainer and how to be maintainer and, and also how to, you know, you know, keep maintaining the projects and keep projects going. So that's going to be a very good talk going forward. So hopefully you'll wait on for Dawn. All right. So anyone with any questions? Yeah. Do we have just one second? We might need to get a microphone made. So just one second. Samuel is just getting it back. Hey, here we go. Very nice talk. Thank you for that. So my question is, how do you identify such community where you will be just as welcome in a sense that let's say I am new to this, I'm undecided. I have a number of projects I am passionate about and I would like to contribute. I don't know anybody on these communities. For example, you're like ground zero. What science should I be looking for to know, oh, this community seems like a better fit for me than this one besides just reading and issues and people being, okay, the language they use is a bit kinder. So maybe this is better. What should be the science I should be looking for? I suppose first thing is what are you interested in, you know? Is it that if you're going to be doing a part time, is it a particular project that's part of your product you're working on? You know, because then it gives you a better opportunity if you're working with your manager or whatever else to say that maybe, can I use percentage of my day or week on this project because we use this and we depend on it. That'd be the first thing. But really it's what you're interested in. Second thing is I suppose is to look out in the project and probably something I didn't cover is an inclusive community. So is it owned by a foundation or is it owned by one company or one what we call benevolent dictator that may turn not so benevolent?  Is it a diverse group of people from different companies, etc? Things like that I think is what you're looking for. And our reviews taken seriously are PRs reviewed in a nice, you know, within an ice timeframe or they just spread out. Things like that I think is probably a good first step for you. And then, you know, a lot of stuff is online. So if you check online, there's probably comments somewhere, someone saying something about the community, you know, if you're here and kind of, I suppose like TripAdvisor, maybe, you know, if you're here in comments that aren't so nice of our community, maybe that's a right flag for you as well. Also on the license and is the last thing, is it a nice permissive open license where, you know, any contributions you do or if your company's building on top of, you know, will they have to give over the farm if, you know, they're requested to. So I think things like that start to note and what field do you get from it as well when you reach out? Anyone else? So we'll finish it up. So thanks very much for coming folks and I'll see you in the next video.